A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
1–10 of 49 posts
Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
#2This seems to be the use case for a user communicating with a confidential computing/enclave abstraction.
Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
#3I think this depends on a lot of assumptions about the capabilities of what is otherwise described as an absolutely dumb featureless device.
If the device lacks access to storage it cannot store any state. How do you ensure the RNG isn't initialized to the same value every time? I'm not sure how that impacts some of the assumptions about security here.
Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
#4I think this depends on a lot of assumptions about the capabilities of what is otherwise described as an absolutely dumb featureless device. If the device lacks access to storage it cannot store any state. How do you ensure the RNG isn't initialized to the same value every time? I'm not sure how that impacts some of the assumptions about security here.
> the RNG isn't initialized
Or used.
sk_identity is static over the lifetime of the device, so doesn't need new entropy.
sk_device is generated after pk_user is recieved, so can use HASH(sk_identity,pk_user) as entropy. This results in the same pk_device for every session with a given pk_user, which theoretically enables traffic analysis, but the security model implies traffic analysis is out-of-scope.
signature and enc_sig might need entropy as well, but can still use HASH(sk_identity,pk_user).
Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
#5I think this protocol is correct-ish* when you make the strong assumptions you have made about the device, but I also don't know why you would use it. Normally, you would prefer to both have unique device public keys for domain separation (preventing re-use of IVs, etc.) combined with the ability to verify that the device public key is actually the public key of a legitimate device. Otherwise, you could have a non-legit device conduct a MITM attack by running this protocol (if you trust the device to provide its identity PK) with the user and the device separately or you could have a counterfeit device created when sk_identity is eventually exfiltrated (if you set the identity PK as the same number for all devices at the factory - see what happens with DRM). Using some sort of device ID with a database mapping IDs to PKs also doesn't give you counterfeit protection the way a certificate does - a counterfeiter can re-use an ID. You also can't rotate your identity keys if you use this scheme.
Most cryptosystems today offer flexible-enough primitives that you can come up with a lot of different possible ways to do things like this. Whether they are useful is a different story.
IMO you should probably do something more normal, and just store the certificate chain with the device programming.
*After about 10 minutes of analysis, so YMMV taking my word for it.
Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
#6This seems to be the use case for a user communicating with a confidential computing/enclave abstraction.
Why wouldn't you have your enclave carry a certificate instead of doing this?
You may eventually need to rotate its identity key, and if you want to do that, you need a certificate system.
Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
#7On a cursory glance, this looks rather quite a bit like a Noise [1] pattern. One rather nice aspect of Noise is that there is a good reference chart for which security properties one should expect from different combinations - saving time on proofs.
Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
#8On a cursory glance, this looks rather quite a bit like a Noise [1] pattern. One rather nice aspect of Noise is that there is a good reference chart for which security properties one should expect from different combinations - saving time on proofs. [1] https://noiseprotocol.org
While we're talking Noise, I'll plug the excellent Noise Explorer [1], which visualizes handshakes, enumerates security properties, and offers Go + Rust (+ wasm) implementation downloads.
I used this (and the NNpsk0 handshake [2]) as the basis for an E2EE chat app.
Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
#9I think this protocol is correct-ish* when you make the strong assumptions you have made about the device, but I also don't know why you would use it. Normally, you would prefer to both have unique device public keys for domain separation (preventing re-use of IVs, etc.) combined with the ability to verify that the device public key is actually the public key of a legitimate device. Otherwise, you could have a non-le…
Yeah, from the requirements it’s not clear why you wouldn’t just use TLS.
Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange
#10I think this depends on a lot of assumptions about the capabilities of what is otherwise described as an absolutely dumb featureless device. If the device lacks access to storage it cannot store any state. How do you ensure the RNG isn't initialized to the same value every time? I'm not sure how that impacts some of the assumptions about security here.
> the RNG isn't initialized Or used. sk_identity is static over the lifetime of the device, so doesn't need new entropy. sk_device is generated after pk_user is recieved, so can use HASH(sk_identity,pk_user) as entropy. This results in the same pk_device for every session with a given pk_user, which theoretically enables traffic analysis, but the security model implies traffic analysis is out-of-scope. signature and…
You could... but I guess my bigger point is that wasn't even addressed.
This is my first time seeing Verifpal, but it looks like a huge foot gun in the wrong hands. Here the author was lead to believe there was some sort of formal validation of his roll-your-own crypto, while glossing over obvious potential implementation flaws.