1

I am working on an implementation based on the Disco library, which itself is based on Noise and strobe framework. The goal is to do bilaterally entity-authenticated key agreement with perfect forward secrecy. Disco already implements Noise_NNpsk2 but does not offer Noise_NKpsk2. I at first considered using Noise_NKpsk2, though the more I think about the the more it seems like Noise_NNpsk2 might work too!

Situation:

Consider two entities A, B, where B has a key printed in a spot which we can guarantee is only visible to A. Entity B is computationally much weaker and cannot take any pre-messages. Concretely, A is a local server and B is some IoT device without any possibility of user input.

Assume A wants to initiate a handshake with B. If we consider the differences between the two schemes Noise_NNpsk0, Noise_NKpsk2, the only security-relevant differences are that in Noise_NKpsk2 A has the extra authentication measure of the static public key of B. As we assume that the PSK printed on B can only be seen by A, I reckon that the extra assurance of the static public key of B doesn't add anything!

Hence, my question:

What are motivations to go with Noise_NKpsk2 over Noise_NNpsk0 given the assumptions of the "hidden" PSK only visible to A?

iMrFelix
  • 111
  • 2

1 Answers1

1

If I understand your setup correctly, you have a device, whose owner can authorise other parties (e.g. server) to connect to this device by sharing some information with that other party over a previously established channel (between the owner and the other party).

When you are using Noise_NNpsk2, the owner is sharing a secret password known to the device and printed on it. You get:

  1. The device authorises connections to it using the password (“anyone who knows the password can connect to me”). It does not authenticate the server.
  2. The server authenticates the device using the password (“the device I am connecting to knows the password that the user shared with me, hence it is the device that the user wants me to connect to”).
  3. Forward secrecy comes from the use of ephemeral keys.

You’d like to compare this to Noise_NKpsk2, but let’s compare to Noise_NK instead. In this case, instead of reading and sharing a password printed on the device, the user will read and share its static public key. What you get:

  1. The deviсe authorises connections as “anyone who knows my public key can connect to me”.
  2. The server authenticates the device as “this device knows the secret key corresponding to the public key the user shared with me”.
  3. Forward secrecy as before.

Of course, it is a little bit... unconventional to authorise someone based on their knowledge of your public key, since we usually assume that public keys are known to everyone, but that’s in theory; in practice, though, a public key printed on the device is not that different from a password printed on the device, if you think about it? Just don’t publish the list of public keys that you generated for devices that you manufacture (just as you wouldn’t publish a list of passwords printed on them).

Anyway, what did we gain? Well, the server now authenticates the device differently. Namely, previously, anyone who knew the password (took a picture of it at the factory, at the store, when visiting your place, etc.) could not only connect to your device, but also impersonate your device to the server. With a public key, it is no longer so. Bonus: if you want, you can establish the authenticity of devices that your server connects to by issuing certificates for their corresponding static public keys at the factory.

If you feel uncertain about the idea of authorising access to your device based on the knowledge of its public key, or if you are worried about the long-term security of public key crypto (), you can just throw a symmetric password into the mix, that is, Noise_NKpsk2.

kirelagin
  • 206
  • 2
  • 7