!jNACPcjUkhjzSAaLLl:matrix.org

SoloKeys Development

21 Members
Development discussion of the SoloKeys project. See the community for more rooms: +solokeys:matrix.org7 Servers

Load older messages


SenderMessageTime
29 Mar 2021
@partyu:matrix.org@partyu:matrix.org joined the room.18:57:56
14 Apr 2021
@da:esclear.deDaniel joined the room.17:25:21
22 Apr 2021
@timcappalli:matrix.orgTim Cappalli changed their display name from timcappalli to Tim Cappalli.12:53:15
26 Apr 2021
@robin-nitrokey:nitro.chatRobin Krahl joined the room.11:11:36
@robin-nitrokey:nitro.chatRobin Krahl Nicolas Stalder | SoloKeys: I don’t have a debugger yet, so I can currently only tell you that the FIDO2 responses seem to be invalid (tested with nitropy + webauthn.bin.coffee) and that we previously had similar errors when the attestation certificate was missing. So if FIDO2 should work out of the box, it’s probably best that I try to debug the issue first and then get back to you with more information if I cant’t fix it myself. 11:37:38
@nickray:solokeys.comNicolas Stalder | SoloKeys The intent at least is that a vanilla build uses a public attestation certificate and "just works".
We did breaking change a bunch of stuff around certificates recently; you may want to use --feature format-filesystem to get rid of stale stuff.
11:52:39
@nickray:solokeys.comNicolas Stalder | SoloKeys * The intent at least is that a vanilla build uses a public attestation certificate and "just works".
We did breaking change a bunch of stuff around certificates recently; you may want to use --feature format-filesystem to get rid of stale stuff.
11:52:52
@nickray:solokeys.comNicolas Stalder | SoloKeysBut it's also possible there's an actual issue. Planning to integrate a custom RPi4 runner connected to an actual device into GitHub Actions soonish :)11:53:32
@nickray:solokeys.comNicolas Stalder | SoloKeys.11:54:02
@nickray:solokeys.comNicolas Stalder | SoloKeysI think I should also make a proper announcement: We open sourced the missing firmware pieces over the weekend. Visit https://hackmd.io/@solokeys/solo2-getting-started for more :)11:54:24
@szszszsz:nitro.chatSzczepan Zalega (nitro.chat) joined the room.12:06:04
@robin-nitrokey:nitro.chatRobin Krahl
In reply to @nickray:solokeys.com
The intent at least is that a vanilla build uses a public attestation certificate and "just works".
We did breaking change a bunch of stuff around certificates recently; you may want to use --feature format-filesystem to get rid of stale stuff.
format-filesystem didn’t fix it for me. I’ll try to figure out more details and report back.
12:08:42
27 Apr 2021
@partyu:matrix.org@partyu:matrix.org left the room.20:03:37
28 Apr 2021
@robin-nitrokey:nitro.chatRobin KrahlI saw that you were asking about the Rust packaging process for Debian in https://github.com/solokeys/solo-python/issues/110. I’m not an expert but I have some experience from packaging nitrocli, so I might be able to answer some of your questions.07:08:45
@robin-nitrokey:nitro.chatRobin Krahl Nicolas Stalder | SoloKeys: Regarding the FIDO2 issues: I can now confirm that the attestation key is missing in Identity::attestation (state.rs). Could you point me to where it should be generated? It seems that the identity generation is commented out in State::new (and the implementation is missing). 17:31:12
29 Apr 2021
@szszszsz:nitro.chatSzczepan Zalega (nitro.chat) Robin Krahl: I think you need to supply the attestation data now by yourself, and the identity generation code you mention is probably the idea for making the unique attestation certificate per device (for the generated key origin verification) 05:26:45
@robin-nitrokey:nitro.chatRobin KrahlStoring the certificate works. But as far as I see, I can no longer inject a P256 private key using the Trussed client.08:58:51
@istankovic:matrix.org@istankovic:matrix.org left the room.15:14:27
30 Apr 2021
@florian:web3.foundationFlorian | W3F I just added some general info how to set up a development environment using Nix to the HackMD. Let me know if I should add the flake.nix I use in a PR. It allow you to build the runner with a simple nix develop --build as long as you use a recent unstable nix. 00:13:02
@florian:web3.foundationFlorian | W3F By the way, is there a reason you are using the eabi and not the eabihf toolchain? 00:15:18
@nickray:solokeys.comNicolas Stalder | SoloKeysYeah you should never (have to) inject private keys at runtime, as this circumvents the guarantee that clients don't fiddle with secret material. The idea is that there's a manufacture step before secure boot is enabled, with a separate setup firmware. Will try and document this, but might take a moment. There's an exception for symmetric keys as this sometimes is necessary in practice (TOTP). This is trait.CryptoClient.html#method.unsafe_inject_shared_key There's also the possibility of implementing Wrap/Unwrap for trussed::client::mechanisms::p256.14:19:51
@nickray:solokeys.comNicolas Stalder | SoloKeys
In reply to @robin-nitrokey:nitro.chat
Storing the certificate works. But as far as I see, I can no longer inject a P256 private key using the Trussed client.
*

Yeah you should never (have to) inject private keys at runtime.
The idea is that there's a manufacture step before secure boot is enabled, with a separate setup firmware.
Will try and document this, but might take a moment.

There's an exception for symmetric keys as this sometimes is necessary in practice (TOTP).
This is trait.CryptoClient.html#method.unsafe_inject_shared_key

14:20:07
@nickray:solokeys.comNicolas Stalder | SoloKeys * Yeah you should never (have to) inject private keys at runtime, as this circumvents the guarantee that clients don't fiddle with secret material. The idea is that there's a manufacture step before secure boot is enabled, with a separate setup firmware. Will try and document this, but might take a moment. There's an exception for symmetric keys as this sometimes is necessary in practice (TOTP). This is trait.CryptoClient.html#method.unsafe_inject_shared_key There's also the possibility of implementing Wrap/Unwrap for trussed::client::mechanisms::p256.14:21:37
@nickray:solokeys.comNicolas Stalder | SoloKeys
In reply to @florian:web3.foundation
By the way, is there a reason you are using the eabi and not the eabihf toolchain?
It's mostly just that we don't do any floating point.
For production firmware you could check if there's any advantage in switching it on, I haven't investigated this.
14:22:20
@nickray:solokeys.comNicolas Stalder | SoloKeys

You're right; we should still definitely also have an easy path for development (that installs fallback keys + certs).
To clarify the "expected" keys/certs:

  • there's U2F/FIDO "batch" keys (P256, SoloKeys specific) + certificates, and
  • Trussed device-unique keys + certificates (both P256 + Ed255).

All of these for real keys are prepared during manufacture,

  • batch FIDO is injected
  • Trussed attn keys are generated on device (after enabling secure boot), public keys extracted, certificates generated by a vendor-specific CA, and then placed on device
14:25:28
@nickray:solokeys.comNicolas Stalder | SoloKeys
In reply to @szszszsz:nitro.chat
Robin Krahl: I think you need to supply the attestation data now by yourself, and the identity generation code you mention is probably the idea for making the unique attestation certificate per device (for the generated key origin verification)
*

You're right; we should still definitely also have an easy path for development (that installs fallback keys + certs).
To clarify the "expected" keys/certs:

  • there's U2F/FIDO "batch" keys (P256, SoloKeys specific) + certificates, and
  • Trussed device-unique keys + certificates (both P256 + Ed255).

All of these for real keys are prepared during manufacture,

  • batch FIDO is injected
  • Trussed attn keys are generated on device (after enabling secure boot), public keys extracted, certificates generated by a vendor-specific CA, and then placed on device
14:25:37
3 May 2021
@robin-nitrokey:nitro.chatRobin Krahl
In reply to @nickray:solokeys.com

You're right; we should still definitely also have an easy path for development (that installs fallback keys + certs).
To clarify the "expected" keys/certs:

  • there's U2F/FIDO "batch" keys (P256, SoloKeys specific) + certificates, and
  • Trussed device-unique keys + certificates (both P256 + Ed255).

All of these for real keys are prepared during manufacture,

  • batch FIDO is injected
  • Trussed attn keys are generated on device (after enabling secure boot), public keys extracted, certificates generated by a vendor-specific CA, and then placed on device
Thanks for the explanation! So to get the current fido-authenticator version to work, I have to inject the keys into the firmware image?
07:36:29
4 May 2021
@nickray:solokeys.comNicolas Stalder | SoloKeysWe do it with an unpublished provisioning firmware. I think I might dump a copy of a data section that could be used to get started quickly. The Trussed attn part is a bit unstable still though.19:57:34
12 May 2021
@tmosey:matrix.orgtmosey joined the room.13:14:54
@prcrst:matrix.orgprcrst set a profile picture.13:34:15

There are no newer messages yet.


Back to Room List