Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

dannyvanheumen.nl

Post reply on HN
Print view View original

11–20 of 49 posts

Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

#11

Post by mike_d »

layer8 wrote: post #9
pclmulqdq wrote: post #5

I 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.

This. Even if TLS is the wrong answer, it will always be better than anything you roll yourself.

Shout out to https://www.trustedfirmware.org/projects/mbed-tls/

Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

#12

Post by pclmulqdq »

mike_d wrote: post #10
a1369209993 wrote: post #4

Earlier quoted context omitted.

> 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.

This is how roll-your-own cryptography often works out. You set the parameters of the attacks you want to defend against, defend against them perfectly, and ignore the practical realities of what attacks are actually coming.

If you are great at it, you will come up with something very efficient that defends only against the attack surface you need. If you are not great at it, you will have an insecure system.

Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

#14

Post by mike_d »

pclmulqdq wrote: post #12
mike_d wrote: post #10

Earlier quoted context omitted.

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.

This is how roll-your-own cryptography often works out. You set the parameters of the attacks you want to defend against, defend against them perfectly, and ignore the practical realities of what attacks are actually coming. If you are great at it, you will come up with something very efficient that defends only against the attack surface you need. If you are not great at it, you will have an insecure system.

https://www.schneier.com/blog/archives/2011/04/schneiers_law...

Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

#15

Post by cobratbq »

pclmulqdq wrote: post #6
jonahbenton wrote: post #2

This 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.

The device I primarily had in mind is tillitis' TKey. Essentially a general purpose (slow) processing unit. The secret is 32-bytes long and given no storage, that's essentially all you work with. However, the secret is dependent on device + program-binary + 32-byte-user-secret.

A certificate is also a secret + certified public key, right? So, if you cannot store the certification on the TKey (no persistence) than you're left with the same construction. Right now, I'm skipping the complexity of certs (PKCS11, IIRC) etc. The identity being persistent is in order to authenticate the device.

Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

#16

Post by pclmulqdq »

cobratbq wrote: post #15
pclmulqdq wrote: post #6

Earlier quoted context omitted.

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.

The device I primarily had in mind is tillitis' TKey. Essentially a general purpose (slow) processing unit. The secret is 32-bytes long and given no storage, that's essentially all you work with. However, the secret is dependent on device + program-binary + 32-byte-user-secret. A certificate is also a secret + certified public key, right? So, if you cannot store the certification on the TKey (no persistence) than you…

> However, the secret is dependent on device + program-binary + 32-byte-user-secret.

If this is for anyone but yourself, you're going to need a certificate chain. An FPGA like the TKey can also store a significant amount of data in a ROM and you should have no problem storing it.

Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

#17

Post by LVB »

dzdt wrote: post #13

Rolling your own crypto routines of any variety is in the same category as representing yourself in a murder trial.

Yet https://cryptopals.com exists...

Given that this is a person interested in cryptography trying something for an experiment, I don't think it deserves the "don't roll your own" hammer.

Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

#18

Post by cobratbq »

pclmulqdq wrote: post #5

I 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…

The device I have in mind, primarily, is tillitis' TKey. The TKey does not have persistence, and offers a 32-byte secret value that is deterministically unpredictable (Blake2s) depending on hardware + program-binary + user-supplied-secret. Because of this, you will need TOFU, because you can only know its identity at first run, or its unique secret for that matter. (Of course, if you rely on the device+program, you would need to store the identity public key for subsequent connects.)

Do you still see an opening for a MitM if you assume TOFU works? There is authentication, just not on first connect. I'd be interested in your view on what I missed.

The exfiltration is of course a concern. Part of the prototype I'm doing, is looking into how much we can protect against this. (See also feedback I left to tillitis regarding access to the assigned secret, https://github.com/tillitis/tillitis-key1/issues/186>.)

Concerning rotations, absolutely correct. Consider though that any change of program-binary or user-supplied secret or device brings its own secret. Note that because of the lack of persistence on the device, a client would store a data, even if only for use within the device.

Note that the secret is determined at every execution as the program-binary loads. The device, TKey, itself is a general RiscV processing unit with device-firmware that initializes a little bit of device and memory, takes the program sent to the device, then starts executing at the program-binary's entry-point.

Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

#19

Post by cobratbq »

mike_d wrote: post #11
layer8 wrote: post #9

Earlier quoted context omitted.

Yeah, from the requirements it’s not clear why you wouldn’t just use TLS.

This. Even if TLS is the wrong answer, it will always be better than anything you roll yourself. Shout out to https://www.trustedfirmware.org/projects/mbed-tls/

Thanks for the feedback. See also comment https://news.ycombinator.com/item?id=39834820 Note that this device is general purpose security device with no persistence. So the requirements were really specific for that reason.

Re: A simple, (as-of-yet unidentified) asymmetric Authenticated Key Exchange

#20

Post by cobratbq »

mike_d wrote: post #3

I 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.

Thanks for the input. See https://news.ycombinator.com/item?id=39834820> for more details. The device is the TKey, so essentially only 32-byte secret value that is determined at program-load-time. (See more details in other comment.) The RNG is not really there. There is a true RNG (i.e. source of entropy) but not cryptographically-secure. However, you can use this and other data with the Blake2s (from firmware) or your own hash-functcion, to attempt to approximate randomness. So you essentially need to initialize it yourself and can go wild if you want to.
Post reply on HN