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