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

41–49 of 49 posts

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

#41

Post by cobratbq »

notfed wrote: post #40
cobratbq wrote: post #36

Earlier quoted context omitted.

> I think you're over-describing your use case, to the point that it's unclear what you're really saying. I read your "Introduction" section several times, and I don't understand if you're just saying "the use case is an authenticated key exchange" or something different. That makes it hard to judge the protocol. Okay. I indeed failed to abstract away from the device properly. I'm guessing that the confusion comes fr…

> `blake2s(device-secret, program-binary, user-secret)` Ok, I think this is still a fairly standard situation. I understand it that the above quoted text represents the device's long term private key? If so... You can do this: - device derives a long-term public device key from the long-term private key - client generates a fresh public/private session keypair - client and server perform a Diffie-Hellman exchange, re…

I'm not sure if we're talking about the same things. I am not confident that I understand your comment well enough to confirm/reject, so I'm going to clarify for that reason.

> I understand it that the above quoted text represents the device's long term private key?

The device owns an internal, inaccessible long-term 32-byte key called UDS. (I called it "device secret" in other comments.) The device contains fairly minimal firmware, primarily there to initialize the device and accept the bytes that are the program-binary.

When a program-binary is sent, it is written to memory. Then a secret is derived for the program, called CDI. Then device-firmware passes over control to the firmware-binary by jumping to the entry-point (IIRC).

`CDI = blake2s(UDS, blake2s(program-binary), 32-byte-user-secret)`. (Note: this is done in device-firmware and only the CDI is exposed to the program.

> You can do this:

I think here we're on the right track, but I'm guessing you're suggesting an rough idea. So, yeah, from the CDI one can derive a key for identity.

So the current protocol describes using that deterministically generated identity for authentication, and generate random bytes for deriving an ephemeral keypair for the key-exchange.

The client only needs an ephemeral keypair so relies on proper randomness only. (And it keeps a record of the identity public key, to verify its proof.)

> Next problems are replay attack prevention and forward secrecy. The two-birds-with-one-stone for that is for each side to:

I think these are not possible. Assuming (for this discussion) that your client is honest, you start off every session with proper randomness in your (unpredictable) ephemeral key. So from the first message on, replays are not feasible. Forward secrecy should be covered given that the whole session key, as it is established, is based off fresh input from randomness.

This, of course, leaves open the discussion on long-running sessions that keep using the same key without rotation. This is not addressed.

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

#42

Post by cobratbq »

mike_d wrote: post #39
cobratbq wrote: post #25

Earlier quoted context omitted.

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

> Feel free to pour me an avalanche of missed attacks. Sure. Based on your other comments you are using a USB device that explicitly provides no security guarantees when someone has physical access to it, so any attempt to secure the communications between the host and device are moot.

I'd love to respond to this, but your comment "... that explicitly provides no security guarantees when someone has physical access to it, .." is too abstract for me. I'll make a few guesses.

- Is the device hackable? AFAIK not at this moment. The firmware is minimal. It is a relatively new device, so maybe I am not fully informed.

- Is the device stealable/swappable? Yes. However, it isn't possible/easy to access the internal device-secret (UDS) therefore, swapping it out leads to different secret for the program, cascading into the identity, therefore authentication would fail. (Also, if you steal it, then it's gone. :-P)

- There are protections against opening it up. I'm not an expert on this, so I cannot reliably reproduce from memory the ways it is resistant to this. However, it already means your destroying hardware in the process.

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

#43

Post by cobratbq »

pclmulqdq wrote: post #34
cobratbq wrote: post #25

Earlier quoted context omitted.

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

I think if you read the comments aimed at this protocol, we're all saying that if this is a fun/school project, it sounds good, but if this is a commercial product, use something that has been proven to work. No protocol exists completely separate from its implementation.

> No protocol exists completely separate from its implementation.

That's a fair point. I am well aware of this.

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

#44

Post by crotchfire »

cobratbq wrote: post #37
crotchfire wrote: post #31

Earlier quoted context omitted.

Why not buy a TKey Unlocked instead? https://tillitis.se/products/tkey-unlocked/ Then you not only have access to the device secret, you can even choose it yourself.

That's fine. It is indeed possible to perform a check for genuine hardware. (I'm not sure it qualifies as "attestation".) It does not protect you from malicious program-binaries and swapped devices.

Protecting against "swapped devices" is simple: put a secret key in the device, ask it to produce a signature, check it with the public key. Any device other than yours won't know the secret key.

I'm not sure what attacks you refer to when you say "malicious program-binaries". I'm having trouble imagining something fitting this description which is thwarted by the vendor blowing the programming fuse but isn't thwarted by you blowing the fuse yourself.

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

#45

Post by crotchfire »

cobratbq wrote: post #35
crotchfire wrote: post #29

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

I will have a look. I checked quickly already, so if I understand the notation, I also leave out the last transaction. (2 messages vs 3 messages) Presumably because the authentication is one-sided. Will investigate further.

You have misunderstood the notation; Noise NK is 2 messages, one round trip.

Exchanges above the dotted line are one-time key distributions; see this link: https://archive.li/bU5Me#selection-3667.0-3671.36

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

#46

Post by mike_d »

cobratbq wrote: post #42
mike_d wrote: post #39

Earlier quoted context omitted.

> Feel free to pour me an avalanche of missed attacks. Sure. Based on your other comments you are using a USB device that explicitly provides no security guarantees when someone has physical access to it, so any attempt to secure the communications between the host and device are moot.

I'd love to respond to this, but your comment "... that explicitly provides no security guarantees when someone has physical access to it, .." is too abstract for me. I'll make a few guesses. - Is the device hackable? AFAIK not at this moment. The firmware is minimal. It is a relatively new device, so maybe I am not fully informed. - Is the device stealable/swappable? Yes. However, it isn't possible/easy to access th…

> Is the device hackable? AFAIK not at this moment. The firmware is minimal. It is a relatively new device

It is just a package around an inexpensive FPGA chip. Published and un-published attacks against it exist. For these reasons the TKey developers call out "[a]ll physical and electrical attacks applied to the board [are out of scope]" in the threat model.

https://hackaday.com/2018/09/27/three-part-deep-dive-explain...

https://github.com/sylefeb/Silice/blob/draft/projects/ice40-...

> There are protections against opening it up.

I'd love to see photos if yours is any different than what is on the website.

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

#47

Post by cobratbq »

crotchfire wrote: post #45
cobratbq wrote: post #35

Earlier quoted context omitted.

I will have a look. I checked quickly already, so if I understand the notation, I also leave out the last transaction. (2 messages vs 3 messages) Presumably because the authentication is one-sided. Will investigate further.

You have misunderstood the notation; Noise NK is 2 messages, one round trip. Exchanges above the dotted line are one-time key distributions; see this link: https://archive.li/bU5Me#selection-3667.0-3671.36

Yeah, sorry, I realized that later. I forgot I posted the comment already.

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

#48

Post by cobratbq »

mike_d wrote: post #46
cobratbq wrote: post #42

Earlier quoted context omitted.

I'd love to respond to this, but your comment "... that explicitly provides no security guarantees when someone has physical access to it, .." is too abstract for me. I'll make a few guesses. - Is the device hackable? AFAIK not at this moment. The firmware is minimal. It is a relatively new device, so maybe I am not fully informed. - Is the device stealable/swappable? Yes. However, it isn't possible/easy to access th…

> Is the device hackable? AFAIK not at this moment. The firmware is minimal. It is a relatively new device It is just a package around an inexpensive FPGA chip. Published and un-published attacks against it exist. For these reasons the TKey developers call out "[a]ll physical and electrical attacks applied to the board [are out of scope]" in the threat model. https://hackaday.com/2018/09/27/three-part-deep-dive-expla…

You're right. I misremembered; read up on a lot of things in last months. Doesn't really matter, because we're discussing a protocol anyways.

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

#49

Post by cobratbq »

crotchfire wrote: post #44
cobratbq wrote: post #37

Earlier quoted context omitted.

That's fine. It is indeed possible to perform a check for genuine hardware. (I'm not sure it qualifies as "attestation".) It does not protect you from malicious program-binaries and swapped devices.

Protecting against "swapped devices" is simple: put a secret key in the device, ask it to produce a signature, check it with the public key. Any device other than yours won't know the secret key. I'm not sure what attacks you refer to when you say "malicious program-binaries". I'm having trouble imagining something fitting this description which is thwarted by the vendor blowing the programming fuse but isn't thwarte…

The comment is meant to separate the hardware from the protections possible in software. TKey provides a unique secret per device, that transforms into a unique secret per (device + program-binary + user-secret). So, protection against swapped device is possible, just not if you simply check if the device is genuine.

Programs are loaded every time the device is connected by transmitting it to the device. So, you could swap the program binary on the computer, and have it send a malicious binary. Again, a unique secret is assigned to a byte-exact program-binary, so this is detected in the process.

(edit: I'm assuming the device contains the original firmware. I'm referring to programs loaded onto the TKey once programmed. Just to check/avoid confusion.)

Post reply on HN