3

We're contemplating to use the following design to securely identify IoT devices from the cloud, and we would like to know if anybody would see major flaws in it.

  • The design is based on the use of a 4096 bits RSA key.

  • The public key would be included in the IoT device firmware.

  • At startup, the device will generate a random 256 bits ID (using a specific chip with true random capabilities or entropy from the user pushing buttons on the device). This ID will not change until the device is reset, and will be kept in RAM.

  • At first connection, the device will register in a cloud infrastructure sending an encrypted message containing the ID.

  • Then the device will send encrypted messages containing the ID and the payload. Cloud infrastructure will decrypt the message and will be ensured that it comes from the same device that had registered with the given ID in the first time.

  • JTAG capabilities are supposed to be disabled on the device. Potting can be considered.

  • Firmware is supposed to be genuine (user has the ability to flash his device before using it).

In those conditions, do you think there is a way for an attacker with access to the device to steal the ID?

Also another question is which pseudorandom generator could we use (library?) for the RSA encryption?

Thank you very much!

  • 1
    Would like to know what are you developing based on which security can be described. There are few flaws in above design. What to you actually want to develop ? I can understand disabling of JTAG which is good idea, but what is the application you are looking for ? Also which hardware module are you using because generating RSA huge prime numbers should not be limited by hardware you will be using, so do mention the hardware too... – Surendra Patil Sep 26 '16 at 6:10
  • Our goal is to be 100% sure that the device which sends an information is the same that had registered in the first place (ie with the same ID). The hardware has not been chosen yet, but it may be a 32bits AVR UC3 from Atmel. In our design, the device doesn't have to generate RSA keys, as it uses the public key to encrypt informations. Communications are basically one-way, from device to cloud. Thanks! – Vincz777 Sep 26 '16 at 7:02
  • The ID is in RAM so theoretically it can be obtained by an attacker. The only way to prevent that is to use dedicated security hardware - e.g. the same chip as a smartcard. If the ID changes on device restart how will the ID be updated in your system? If your central certs are compromised, you need new public keys on the devices, how is that managed? – Julian Knight Sep 26 '16 at 7:09
  • To your last question: Since you already use RSA, you could conveniently use a CSPRBG based on RSA, see A. Menezes et al. Handbook of Applied Cryptography (freely availble online). A Python code of mine implementing that is in Example 5 of s13.zetaboards.com/Crypto/topic/7234475/1 – Mok-Kong Shen Sep 26 '16 at 9:36
  • @JulianKnight Could you elaborate on how the ID in RAM could be accessed? We don't need our device to be NSA-proof. What we don't want is an attacker steals the ID, puts the device back in place, and the device continues to work as if nothing happened.The ID will change on device restart but this isn't a problem for us, as the device is not supposed to be turned off or reset. Also we plan to manage our private keys with HSM. What do you think? – Vincz777 Sep 26 '16 at 11:12
1

I would recommend the following:

  1. Its best if you deployed a well-tested TLS 1.2 protocol on this device for the purposes of secure authenticated communication rather than invent your own protocol.
  2. Deploy a client certificate on each device and store it as well as the root CA certificates on the device.
  3. Some micro-controllers have an on-chip secure SRAM/EEPROM storage area that can be used ot store keys - e.g. Maxim's MAXQ1010 has a 128 bit storage. Hash the device's certificate and CA root certificates and store this hash value in on-chip secure storage. At startup, the device should generate a hash of the certificate and root CA contents and check whether this is the same as the stored value, if not give an error and refuse to start. Alternatively, store the certificate and root CA within programmable memory for micro-controllers that are one-time programmable.

In summary, by using the current generation of TLS you can rest assured that you've implemented a robust and well-researched protocol. You can then focus your time and effort on developing other functionality of your solution.

  • Thanks for your answer. We'd love to use a standard protocol, however communication speed of the device will be very limited (2kbits/sec, half duplex). TLS handshake would take 20-30 seconds or so, which is far too much for the application we need. This is why we must limit ourselves to small encrypted messages (actually 4096 bits messages is almost too much). – Vincz777 Sep 26 '16 at 12:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.