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

21–30 of 49 posts

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

#21

Post by cobratbq »

a1369209993 wrote: post #4
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.

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

See also my other comments. The device is tillitis TKey. There is a True RNG (source of entropy) but not recommended, i.e. not cryptographically-secure. However, together with Blake2s (in firmware) or another hash-function, you can at least approximate a source of reasonably secure randomness. Needs to be part of the your user program (to be loaded onto TKey), so you can make this as complicated as you like. You can indeed use the input-data as entropy/seed-bytes and hash it with other data and entropy from TRNG.

I haven't tested yet how fast the TRNG refreshes. Right now, I take 4 bytes (1 collection) of TRNG entropy to be hashed with a static byte-buffer.

The RNG would be used for (sk_device,pk_device). So 'identity' keypair for authn, 'device' (ephemeral) keypair for key-exchange.

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

#22

Post by cobratbq »

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.

I get that Verifpal is not perfect, doesn't do everything. I have considered switching. However, a significant part of proving the mechanism is having correct definitions for all of the needed primitives. If Verifpal tackles the right, correct definitions of the primitives, that is already a significant step, right? Considering the protocol is not complicated, or trying to be, one might try a less complex solution to start with. I am not planning to "gloss over" and there is a bigger pictures. But, feel free to make any missed dimensions concrete. (Note, you might want to check some other comments, as I explain a bit more about the device.)

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

#23

Post by cobratbq »

LVB wrote: post #17
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.

Thanks, much appreciated. I'm not claiming to know everything, far from it. However, given this simple but interesting device (see other comments for details) I prefer to keep things simple. This is my attempt at simple-but-correct. :-)

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

#24

Post by cobratbq »

pclmulqdq wrote: post #16
cobratbq wrote: post #15

Earlier quoted context omitted.

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.

To check: did you realize that you plug this device in your USB port, then send a program to it, then start using the device with that program loaded? (This is at run-time, every time, right?) Because the secret is generated for this specific combination, different programs will also have different secrets.

I get that you would want to authn the hardware itself. If that is your point, sure, you're right. However, that aims to address a slightly different problem, because then the certificate chain is tied to the hardware only. Note that part of the charm of the _identity_ generated in the program, is that the identity changes if only a single byte of program-binary is different. So it protects from malicious binaries too. (But not bugs in the program itself.)

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

#25

Post by cobratbq »

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.

I understand the "roll-your-own-crypto" comment. Note that I am taking the perspective of the protocol here, right? So, sure, vulnerabilities in the program are definitely a possibility. (See also other comments explaining more details about the device.) This is part of an experiment to see what can be accomplished with the TKey, which offers an interesting combo of security features.

Feel free to pour me an avalanche of missed attacks. I would be interested to know if your attacks are on the protocol level or in other ways. C programming risks are obviously there. RNG risks are obviously there. You are right that there are plenty of considerations in the program too. They are just not part of this post. (I also commented on the RNG remarks in other replies.)

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

#26

Post by cobratbq »

jonahbenton wrote: post #2

This seems to be the use case for a user communicating with a confidential computing/enclave abstraction.

You're right, mostly. I am not sure if TKey is officially considered an enclave. See more details here: https://news.ycombinator.com/item?id=39834820>

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

#27

Post by cobratbq »

thadt wrote: post #7

On 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

Yeah, thanks for reminding me. That is a nice suggestion.

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

#28

Post by cobratbq »

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.

You're right. I wanted to abstract away from specific hardware and express that in the requirements. I definitely failed at that. See other comments for specifics and details on the device.

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

#29

Post by crotchfire »

This is Noise NK, possibly with differences in the hashing details which I did not check:

https://noiseprotocol.org/noise.html#interactive-handshake-p...

I encourage you to use their hashing details. They're battle-tested.

Wireguard uses Noise IK, which is NK plus a static public key for the initiator which is encrypted to the agreed-upon-session-key without adding additional round trips. Your protocol and Noise NK omit the parts related to the initiator's static public key, because it has none.

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

#30

Post by crotchfire »

thadt wrote: post #7

On 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

https://news.ycombinator.com/item?id=39835927
Post reply on HN