2

I have almost 0 knowledge of IoT, their protocols and usual device constraints. I had a discussion today with someone that has a fair amount of IoT experience and we were discussing some security related issues and the establishment of a shared key came up. I assumed that Diffie-Hellman would be used but this person seemed to not be familiar with the method and based on their knowledge for low power devices, the keys are actually preloaded inside.

  1. Is this a real scenario?
  2. Is it possible for DH exchange to be too intensive for a low powered device?
  3. What role does Ephemeral Diffie–Hellman Over COSE (EDHOC) play in this case? Is it a good alternative or still problematic?
Improve this question
3
  • This isn't particularly answerable because it assumes knowledge about who knows how many different device manufacturers, platforms, and use cases and doesn't generalize well.
    – Steve
    Jan 7, 2020 at 22:21
  • @Steve is right in general, you have to be more specific, especially hardware-wise. For example. a raspberry PI (considered an IoT) could potentially handle DH ( I dont know how "fast"). But, for an arduino nano, I would say No. The same applies to even smaller, weaker IoT devices like for example, zolertia. They would not have enough processing capabilities, plus they would consume power like crazy. As a research topic though, it sounds very interesting, very advanced, and in general, very "un-researched" yet.
    – George Violettas
    Jan 8, 2020 at 6:39
  • Elliptic curve Diffie-Hellman is typically more efficient than standard Diffie-Hellman, although the difference is not massive.
    – Natanael
    Jan 9, 2020 at 1:18

2 Answers 2

Reset to default
2

It depends on 2 factors: what resources are available on the IoT device (processor speed, memory, power), and how long you can wait for the data to arrive. If one of those factors are not an issue (say, you can wait 1h to receive 1024 bytes), it can be done on any device.

Generally, current technology is more than enough to run basic cryptography, the bandwidth and latency being the main issues. The low-power microcontroller Maxim MAX32621 (12mW on active mode, 2.6 µW on standby) can do AES-128, AES-192, AES-256, DSA/RSA to 2048 and TRNG native. Someone even implemented AES-CMAC on an Attiny85 (8k flash, 512B RAM, 8/16MHz, up to 20MHz). EDHOC intends to solve the latency by, among other things, reducing the amount of round-trips needed to establish the connection.

If you don't care about implementing the full TLS stack, but only on encrypting data, you can implement your own protocol. Save the server public key on the device, generate a symmetric key, encrypt it with the server public key, encrypt the data with the secret key, concatenate both the encrypted data and encrypted secret key, and send to the server all at once. No round-trip, no TLS session establishing. If you use UDP, you can send all the data in one single packet, without even needing to establish a connection.

Improve this answer
1
  • Excellent information although it does directly mention DH (even though it is not really needed in the suggested implementation).
    – PentaKon
    Jan 9, 2020 at 15:14
0

Although it depends on the device it is possible for Diffie-Hellman to be too intensive for low power devices especially when battery conservation is of paramount importance.

Improve this answer
2
  • 1
    It's possible for any protocol to be too power intensive for any device, so I'm not sure how helpful this is as an answer.
    – schroeder ♦
    Jan 8, 2020 at 13:07
  • Of course but I thought in the general case DH would be ok which it seems it isn't. Regardless, this is why I did not accept it as an answer hoping someone else would pitch in.
    – PentaKon
    Jan 9, 2020 at 15:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .