3

What password hashing algorithms and other cryptographic hashes (e.g. scrypt, bcrypt, PBKDF2, MD5, SHA-256) are suitable for resource-constrained IoT devices for the consumer-oriented smart home environment?

I am looking at a range from ultra-low power CPU devices (most embedded devices) to the devices that have processing power equivalent to a basic Raspberry Pi. This includes the ARM Cortex M3/A8/A9 processors, and low cost chinese SoCs (such as HiSilicon that uses ARM 926).

  • You might want to clarify what you mean by resource-constrained -- there are a lot of resources that can be constrained. RAM? CPU? Network? All three? Something else? Alternatively, you could give an example device -- my go-to for "look how weak embedded systems are" is the Arduino Nano, with a 16Mhz CPU and 2k RAM, but you might be operating under a different type of constraints, which would be useful to represent. – Nic Hartley Jul 3 at 14:11
  • 1
    It is neither clear what the exact purpose of these operations should be on the IoT device nor how much resource-constraint the device is. This makes it impossible to propose alternatives which are lean on resources in order to be used on the device but which are still sufficiently secure for the purpose. – Steffen Ullrich Jul 3 at 14:22
  • RAM and CPU - hardware constraints mainly due to keeping costs reasonable. I don't see network throughput constraints being there. I know 'IoT' covers a wide array of devices, but assume Smart Home devices (webcam, smart bulbs, thermostat). – Sneekes Jul 3 at 14:26
  • @Sneekes As the other contributors have pointed out, you should quantify the restraints. Then you will probably get some fantastic answers. – Patriot Jul 3 at 15:17
  • I'd say typical processing power would be on the lines of the Arm Cortex-M33 and M23 (arm.com/products/silicon-ip-cpu), not sure re the RAM requirements (This question is to a study on the overall security properties of IoT devices in Smart Homes. Hence, I haven't gone into much detail). – Sneekes Jul 3 at 15:27
4

No password hashing algorithm is suitable for resource-constrained devices. That's because password hashing must be inherently slow. It needs to be slow on the attacker's computer, and yet not unacceptably slow on yours. But if your computer is slow, such as a microcontroller, what takes a few minutes on your computer only takes a fraction of a second on the attacker's computer.

Do not store passwords on an IoT device. A typical IoT device doesn't have a keyboard input anyway, so why would it store a password? If you need to authenticate, use an authentication token which is not meant to be memorized by humans, and thus verifying it can be a simple hash or signature verification, and not a password hash. If you need the user to authenticate with a password, this should happen on a control server which is a full-blown PC (in the cloud or on premises), and the PC generates the authentication token for the IoT device.

When it comes to choosing cryptographic algorithms for constrained devices, don't overthink it. The benefits of fine-tuning nonstandard algorithms tend to be marginal in practice. Use standard algorithms such as:

  • SHA-256 or SHA-3 for hashing. (That's hashing data for integrity — not hashing passwords, which as I said before you cannot do.) SHA-3 has the best performance when implemented in hardware but the hardware isn't out there yet.
  • RSA or ECDSA (with P256r1) or EdDSA (with Curve2519) for signature verification. RSA verification is faster than ECDSA/EdDSA verification, but signature generation is a lot slower and RSA requires more RAM and has larger signatures.
  • AES-CCM or AES-GCM or ChaCha20-Poly1305 for encryption. ChaCha_Poly is faster in software, but Cortex-M systems with hardware acceleration for AES are getting more common.
3

Whenever this question is asked, the answer is "as slow as possible". You won't get a different answer just because you use a slow computer. Your algorithm just needs to be as slow as is acceptable for your purpose.

If you do PBKDF2 with only 2 rounds because the cheapest Arduino takes 2 seconds to run that, then that's simply the best you can do. But that does mean that an attacker, who might be able to do those 2 rounds in 2 microseconds, can do an attack 1 000 000 times (2s divided by 2µs) faster than you can prevent it. Your configuration would protect the user's password only marginally.

Some devices may be incapable of running certain algorithms, so then those algorithms are automatically ruled out. Having to give up memory-hardness (e.g. Argon2, Scrypt) slightly reduces security but is not catastrophic. Other than what you cannot use, the recommendation is the same: Argon2, Scrypt, Bcrypt, or PBKDF2 (in order from best to worst). The parameters are, as mentioned, "as slow as possible". You should benchmark different parameters and pick the slowest that is acceptable for you.

After picking an algorithms and parameters, you should consider how secure the setup now is by comparing it to what an attacker can do. Is it then NSA? Then assume they have ASICs. Are you worried about regular commercial espionage? Assume an expensive set of CPUs and GPUs. It depends whom you want to protect against. If it turns out that you cannot adequately protect the user's password, you may want to warn users to use ephemeral and unique passwords. The CPUs and platforms you mention (such as a Raspberry Pi) are already pretty beefy, though, so this would probably not be necessary in your specific situation.

For any details about the different algorithms or choosing a set of parameters, see these questions:

3

Your security needs are not going to be lowered because a device happens to be in the IoT. (Ever hear of the "Fine Dining Attack"?) In other words, you need to apply your security profile across the entire aggregated attack surface. And the other thing we need to keep in mind is that IoT devices tend to be leaky and have few, if any, updates.

As Mr. Schneier has said, cryptographic hashes are the workhorses of cryptography. We have to use them correctly without cutting corners on salts, etc. Hashing is probably too resource intensive for most IoT devices, especially when done right.

One thing that makes sense for use in the IoT is obviously elliptic curve cryptography because the key sizes are much smaller. Curve 25519 is recommended over the NIST curves, for sure.

In fact, if we really get into the nitty-gritty for tiny devices, it may start to make sense to use a one-time pad, especially when there is a bit of storage available. If we go with a proper OTP for confidentiality, then Poly1305 makes sense for authentication. Or shared secrets might start being used in authentication. es.

I see the IoT as a big threat. Instead of lowering security to meet device capabilities, we need to assure security every step of the way and that may very well mean shared secrets and storage of strongly generated (made elsewhere) keys. Otherwise the IoT will be the attacker's dream come true.

  • This misses the point. There are many times where it's literally impossible to do things the normal way, because your device has, say, 2k of RAM, total, for it to use to do everything it needs to do. The question was explicitly asking for algorithms which can run in environments as constrained as that. – Nic Hartley Jul 3 at 14:09
  • @Nic Hartley That's fair. But my overall point is still valid. – Patriot Jul 3 at 14:42
  • 1
    To be clear, I agree with your answer's overall point now ("security for IoT is still important, be conscientious about what you pick, here are some strong, low-resource options"). It was only your initial version I disliked. – Nic Hartley Jul 3 at 16:49
  • 2
    @NicHartley "what would work in those sorts of ultra-constrained environments" What (I think) this answer is saying is that in at least some use cases, the answer must be "nothing will work" in such constrained environments. Either you use a less-constrained option (albeit at higher cost) where necessary security can be implemented, or you don't implement the solution at all (until technology advances make sufficient power cost effective). Implementing without the necessary security will see you webcam/heating system/whatever hijacked. – TripeHound Jul 4 at 9:46
  • 2
    @TripeHound I guess I phrased it poorly. My original concern was that, previously, I read the answer as saying "you must use the normal industry standards at all times" -- i.e. only consider security, and nothing else. Now, I read the answer as saying, "Remember that security is incredibly important, and here are some options which are both secure and require less RAM." The latter actually answers the question. Your comment (or any equivalent of "it's not possible") would also be an answer IMO -- but this answer wasn't originally saying it's impossible. – Nic Hartley Jul 4 at 15:26

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.