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

31–40 of 49 posts

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

#31

Post by crotchfire »

cobratbq wrote: post #18
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 w…

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.

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

#32

Post by phlip9 »

cobratbq wrote: post #18
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 w…

I don't know much about the TKey, but it looks like they have some kind of remote attestation protocol available? (https://github.com/tillitis/tkey-verification/tree/main/cmd/...). That's usually how you avoid TOFU.

(1) the tillitis CA certifies your TKey device platform. You can now trust that it's running a specific firmware version with some platform pubkey.

(2) Your custom software is running and derives a keypair from it's derived secret + program binary hash.

(3) Somehow your custom software's pubkey gets locally certified by the platform's pubkey from (1). (not sure what this looks like w/ the TKey)

You now have a chain of trust from (1) the tillitis CA -> (3) the TKey device platform pubkey @ some specific firmware version -> (2) your custom software pubkey @ some specific version.

Now that we have a trusted pubkey for our service, I would open a secure channel to it via Noise IK or something (https://noiseexplorer.com/patterns/IK/). The TKey platform definitely looks a bit anemic so getting this working might be a challenge...

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

#33

Post by notfed »

> The use-case is a user and a “service-provider” (of some kind, in my case a device). The device only responds to requests, performs computations in a separate computing environment and is, in this particular case, connected by USB port. There is sensitive information involved. The device, however, does not have storage capability...

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.

> Device gets authenticated

> The device, however, does not have storage capability

These two requirements are contradictory. How do you "authenticate" a server that has a different identity each time you interact with it?

> [The protocol] is built on top of a Diffie-Hellman Key Exchange

Why not just use Diffie-Hellman? What else is this offering?

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

#34

Post by pclmulqdq »

cobratbq wrote: post #25
pclmulqdq wrote: post #12

Earlier quoted context omitted.

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

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

#35

Post by cobratbq »

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.

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

#36

Post by cobratbq »

notfed wrote: post #33

> The use-case is a user and a “service-provider” (of some kind, in my case a device). The device only responds to requests, performs computations in a separate computing environment and is, in this particular case, connected by USB port. There is sensitive information involved. The device, however, does not have storage capability... I think you're over-describing your use case, to the point that it's unclear what y…

> 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 from the fact that I had a specific device in mind, but failed to describe it.

> These two requirements are contradictory. How do you "authenticate" a server that has a different identity each time you interact with it?

Not necessarily. So how TKey works: the hardware contains a preprogrammed device secret. The hardware does not have storage. Upon each power-up it expects a program to be loaded. Upon loading that program, a secret is computed for that specific program: `blake2s(device-secret, program-binary, user-secret)` (user-secret is optional). The secret is generated deterministically, but unpredictable because we don't know the device-secret.

> Why not just use Diffie-Hellman? What else is this offering?

Given that there exists an "identity", which is the same every time the program loads, this identity can be used for authentication. The identity is different for every program, but after acquiring it once, a client application can perform a key-exchange that finishes with the signature proving the authenticity.

If 'device' or 'program-binary' or 'user-secret' changes, the secret changes. So if the secret is the same, you have quite strong guarantees that nobody screwed around with your device or program.

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

#37

Post by cobratbq »

crotchfire wrote: post #31
cobratbq wrote: post #18

Earlier quoted context omitted.

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

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.

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

#38

Post by cobratbq »

phlip9 wrote: post #32
cobratbq wrote: post #18

Earlier quoted context omitted.

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

I don't know much about the TKey, but it looks like they have some kind of remote attestation protocol available? ( https://github.com/tillitis/tkey-verification/tree/main/cmd/... ). That's usually how you avoid TOFU. (1) the tillitis CA certifies your TKey device platform. You can now trust that it's running a specific firmware version with some platform pubkey. (2) Your custom software is running and derives a keyp…

> I don't know much about the TKey, but it looks like they have some kind of remote attestation protocol available? (https://github.com/tillitis/tkey-verification/tree/main/cmd/...). That's usually how you avoid TOFU.

There is a tool to verify if the device is genuine by mechanism of a signature. You're outlining most of the process. The question is whether avoiding TOFU is the goal, right? I'm thinking, with the physical device in your hands and during first use, it's quite reasonable to establish the identity for your 'program' + 'user-secret'.

> You now have a chain of trust from (1) the tillitis CA -> (3) the TKey device platform pubkey @ some specific firmware version -> (2) your custom software pubkey @ some specific version.

This does mean you make this a global + centralized effort, right? (Also, it creates a dependency.)

> (3) Somehow your custom software's pubkey gets locally certified by the platform's pubkey from (1). (not sure what this looks like w/ the TKey)

With the specific firmware version: this requires a (possibly centralized) certification-process if only for a keypair, or qualification effort (if any) for the program?

To conclude: I am not convinced yet that TOFU is necessarily a bad thing. However, I do appreciate some ability to authenticate over many uses / longer stretches of time. (Hence the key-exchange + authn.) It seems there is a trade-off here, TOFU can be eradicated but requires other properties/effort. OTOH, the program-specific secret makes for a very strict form of trust. I'll take your comments into consideration, but it seems whichever way one chooses, there is a trade-off to be made.

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

#39

Post by mike_d »

cobratbq wrote: post #25
pclmulqdq wrote: post #12

Earlier quoted context omitted.

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

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

#40

Post by notfed »

cobratbq wrote: post #36
notfed wrote: post #33

> The use-case is a user and a “service-provider” (of some kind, in my case a device). The device only responds to requests, performs computations in a separate computing environment and is, in this particular case, connected by USB port. There is sensitive information involved. The device, however, does not have storage capability... I think you're over-describing your use case, to the point that it's unclear what y…

> 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, resulting in shared_session_key

- client also verifies device's long-term public key is correct (a simple equality check)

At this point the client and server now have a shared_session_key, and you're in standard territory.

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

- generate fresh a ephemeral keypair

- encrypt using the shared_session_key (with a random nonce)

- perform another Diffie-Hellman exchange

This results in a shared_ephemeral_key. This key can now be used to communicate securely, but you'll need to use incrementing integers as nonces for each message in the ephemeral session to prevent replay attacks. None of this needs storage.

Post reply on HN