TIP 001: Device and User Authentication via Noise Protocol

[nickray]

I am currently implementing Noise_NK to check for "device authenticity"; sketching the plan here for publicity and feedback.

Opinion: Noise is great, I think we should use it a lot for core functionality (vs. re-inventing the wheel or using older approaches).

Context: The intent for "Trussed certified" devices (besides having "good" crypto, storage encrypted at rest, reliable TRNG, etc.) is to have both a signing key and a key agreement (Diffie-Hellman) key that is unique per device, giving it both a cryptographic identity and a means to open a secure (encrypted) channel.

For SoloKeys Solo 2, this is implemented in Solo 2 PKI, and even with two "cryptographic families". On the one hand, we have a P256 key (which can both sign and key agree). On the other, we have an (Ed255, X255) pair covering (sign, agree) together. In principle, RSA would work too (cf. #18 for why we don't have RSA currently).

For instance, a Solo 2 device of mine with serial number F8D88A9617DB97529213FD39A33174FE has an associated X25519 key, with a certificate https://s2pki.net/s2/F8D88A9617DB97529213FD39A33174FE/x255.txt, which ties back to our SoloKeys root of trust R1 (RSA-4096) over an intermediate Trussed authority T1 (Ed25519) via a certificate chain: R1 -> T1 -> this X255 key

What I am doing: Implementing Noise_NK_25519_ChaCha8Poly_SHA256 handshake, where the K (known) key is the Solo 2 X25519 key above.

Outcome:

• The handshake completing means that the device controls the key
• The certificate chain means that SoloKeys vouches for the key
• taken together: the device is authentic

Ditto with P256 or RSA (or post-quantum... 🤪)

secure channels

The actual output of the handshake above is AEAD keys, which can be used as a secure channel to the device (with unauthenticated initiator).

user / admin PIN

Spitballing, but an extension of the above to authenticated initiators:

• user PIN (which can also be a password, passphrase...) converts via hash-to-curve into an X255 key; ditto for an admin "PIN"
• by setting a (factory) default, the device can have two known initiators
• now, user or admin can perform Noise_KK with the device, after which both sides are authenticated
• once done, the authenticated user or admin can be allowed further operations (use of restricted keys, change of "PIN", updated of firmware, reset of device, etc.)

Ditto with P256 or RSA

X509 certificates / attestation

Semi-related, the intent of the signing key is to perform attestation such as "this key was generated on the device and is not exportable". There is a related WIP to generate such X509 certificates on the device; after which there'd be certificate chains R1 -> T1 -> device Ed255 -> generated key (or, for the NIST/P256 cryptofamily, R1 -> T2 -> device P256 -> generated key).