4 ms·

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

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-legit device conduct a MITM attack by running this protocol (if you trust the device to provide its identity PK) with the user and the device separately or you could have a counterfeit device created when sk_identity is eventually exfiltrated (if you set the identity PK as the same number for all devices at the factory - see what happens with DRM). Using some sort of device ID with a database mapping IDs to PKs also doesn't give you counterfeit protection the way a certificate does - a counterfeiter can re-use an ID. You also can't rotate your identity keys if you use this scheme. Most cryptosystems today offer flexible-enough primitives that you can come up with a lot of different possible ways to do things like this. Whether they are useful is a different story. IMO you should probably do something more normal, and just store the certificate chain with the device programming. *After about 10 minutes of analysis, so YMMV taking my word for it.

layer8 3y ago
Yeah, from the requirements it’s not clear why you wouldn’t just use TLS.
- mike_d 3y ago
  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/ https://www.trustedfirmware.org/projects/mbed-tls/
  - cobratbq 3y ago
    Thanks for the feedback. See also comment https://news.ycombinator.com/item?id=39834820 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.
- cobratbq 3y ago
  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.
cobratbq 3y ago
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 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.
- crotchfire 3y ago
  Why not buy a TKey Unlocked instead? https://tillitis.se/products/tkey-unlocked/ https://tillitis.se/products/tkey-unlocked/ Then you not only have access to the device secret, you can even choose it yourself.
  - cobratbq 3y ago
    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.
    - crotchfire 3y ago
      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.

layer8 3y ago

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

mike_d 3y ago
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/ https://www.trustedfirmware.org/projects/mbed-tls/
- cobratbq 3y ago
  Thanks for the feedback. See also comment https://news.ycombinator.com/item?id=39834820 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.
cobratbq 3y ago
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.

cobratbq 3y ago

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

crotchfire 3y ago
Why not buy a TKey Unlocked instead? https://tillitis.se/products/tkey-unlocked/ https://tillitis.se/products/tkey-unlocked/ Then you not only have access to the device secret, you can even choose it yourself.
- cobratbq 3y ago
  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.
  - crotchfire 3y ago
    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.