NIST Helps You With Cryptography

Getting cryptography right isn’t easy, and it’s a lot worse on constrained devices like microcontrollers. RAM is usually the bottleneck — you will smash your stack computing a SHA-2 hash on an AVR — but other resources like computing power and flash code storage space are also at a premium. Trimming down a standard algorithm to work within these constraints opens up the Pandora’s box of implementation-specific flaws.

NIST stepped up to the plate, starting a lightweight cryptography project in 2013 which has now come out with a first report, and here it is as a PDF. The project is ongoing, so don’t expect a how-to guide. Indeed, most of the report is a description of the problems with crypto on small devices. Given the state of IoT security, just defining the problem is a huge contribution.

Still, there are some concrete recommendations. Here are some spoilers. For encryption, they recommend a trimmed-down version of AES-128, which is a well-tested block cipher on the big machines. For message authentication, they’re happy with Galois/Counter Mode and AES-128.

I was most interested in hashing, and came away disappointed; the conclusion is that the SHA-2 and SHA-3 families simply require too much state (and RAM) and they make no recommendation, leaving you to pick among less-known functions: check out PHOTON or SPONGENT, and they’re still being actively researched.

If you think small-device security is easy, read through the 22-question checklist that starts on page twelve. And if you’re looking for a good starting point to read up on the state of the art, the bibliography is extensive.

Your tax dollars at work. Thanks, NIST!

And thanks [acs] for the tip!

33 thoughts on “NIST Helps You With Cryptography

  1. Is AES and other such more complex security really needed for IoT? I mean can’t you just go simple and use things like dictionary encryption or some such? It’s not like you are protecting from some major player wanting to steal ‘state’ secrets but merely that you don’t want hacking kids to mess with your stuff to make a botnet or fuck up your setup.
    AES and such more robust professional systems seems really overkill and impractical IMHO.

    1. You can mitigate, to an extent, having a (relative) weaker encryption if you make other aspects harder. For example, each device having a different key (that way if one key is ‘solved’ it doesn’t mean the entire network is compromised). Or, in the case of an embedded micro, selecting a device/architecture that makes it harder to extract the code (and so the keys).

      No security scheme will be perfect but one just needs to make it “harder than it’s worth” (depending upon who and what you are trying to prevent) – I thought the questionnaire was very thorough and, even if you don’t follow the advice of the report, is a good start for performing ‘due-diligence’ if you’re going DIY.

      1. Reminds me how big professional companies apparently secure their hardware.using AES and then having the MAC be the keyword… or in other words yes you want more varied keys.

      1. You mean when “First Cognition” happens and some AGI running on a quantum computer wakes up and takes over the entire internet and everything connected to it? Yeah, but how many years from now?

    2. Some IoT platforms (for example NodeMCU) have AES libraries, so implementation is faster as well as far more secure than rolling your own thing. Risk:reward tends to heavily favor encryption for even modest systems.

    1. Unfortunately any security developed in the US, can have a FISA gagging order attached – so yea (Foreign Intelligence Surveillance Act). The default broken by design random number generator was acceptance as a NIST FIPS standard (Federal Information Processing Standards). So it was endorsed for US government use (But not actually used by the US government). It was corporations with a need for high security having an open front door for the NSA.

    2. The same. AES-128 turns into 64-bit hardness when facing a quantum computer, so it is probably not future-proof. AES-256 on the other hand should be, provided your SoC has a built-in hardware RNG. If it doesn’t, then an attacker can exhaust your entropy pool and recover your keys.

    3. for some reason, I think the reverse; that the NSA graciously provides advice/technology to NIST that leads to holes in civilian crypto. I don’t think NIST is at fault directly.
      [Truth] mentions the random number thing a few years back. Those were found to be almost certainly deliberately broken, and possibly with collusion with RSA, since it’s a rather goofy random number generator to begin with, but the RSA library makes that the default unless explicitly selected otherwise.. Hence, an careless programmer would be prone to use the crappy one, making systems more likely to be exposed.
      Really, I like elliptic curve cryptography, but the patents are rather goofy, and cover curve generation techniques, rather than the encryption algorithm itself. The NSA has also graciously created and licensed for the benefit of the people some curves that you can use in encryption, royalty free. These are the standard NIST curves. Thanks NSA, how sweet of you! It always gave me the heebyjeebies, but even more so after BSAFE revelation. Pity, really…. Makes me ‘wanna cry’. Oh, yes, another NSA-related debacle, but that’s a separate thread…..

      1. Check out BearSSL being written by a fellow Québec security architect. He seems to have progresses even further than Nist on this question. He started his project 2 years ago after being finalist for PHC. He implements AES and only ecdhe without DHE. It is a bit too long to describe here. He presented it at the northsec 2017 last weekend.

    1. yes but OMG openssl itself is a monster code base, and it’s not designed to be linker friendly, so you generally pull in everything even if you don’t use it. Personally, I blame it mainly on the EVP functions (the capability of dynamically instantiating algorithms by ids forces code to be references and fails the linker’s ability to prove that code is unreachable, and thus can be discarded). OpenSSL is my go-to on big systems, but not on embedded.
      My embedded systems tend to be purpose-built, so I usually wind up simply integrating modules with the primitives I need. I have successfully used libTomCrypt in embedded systems, but I am wary of suggesting that for aany critical systems because it’s not actively maintained. The implementation is good (and public domain), but things like side-channel vulnerabilities require constant scrutiny to discover, and someone to write code to correct.
      In my opinion, the biggest challenge to security in embedded systems is really patch management and distribution.

  2. Wolfssl/Wolfcrypt runs on VERY small systems.

    I’ve gotten TLS connections running on the CC3200/CC3220 as well as the ESP8266

    It’s well-written, and affordable when you hit it big and want to go into production.

    AND it supports OCSP with stapling so you don’t need two sockets just to get a TLS connection setup.

    I haven’t even tried their new teensy-tiny implementation, so that should work on even smaller systems.

    (I don’t have anything to do with Wolf other than being a satisfied customer.)

  3. NaCl (or libsodium) seems like a good choice for easy to use (hard to misuse) crypto. The implementation is efficient, plain C, which makes it seem like a good candidate for embedded devices. The hashing algorithm of choice is blake2b/s, which is faster than most SHAs (and even md5 iirc) while being more secure than SHA1 (obviously), SHA2 and SHA3.
    Does anyone have experience with libsodium on small devices?

    1. Second that.
      There even seems to be a (maybe abandoned) port for Microcontrollers.
      (I’m very interested but don’t know enough)
      I wouldn’t trust such an institution and as a conclusion don’t like Hardware Crypto.

    1. happily, these are becoming much more common as a feature under a different part number (e.g. STM32F405 vs ‘415). unhappily, most products don’t integrated the one with the crypto accellerator, choosing to save the tiny cost difference between the two products. Even in dev boards, where I could care less if it costs a buck more (e.g. currently on mouser I can get a STM32F405RGT6 for $10.58 or a STM32F415RGT6 for $11.16 in UNIT quantities, heavens knows in scale. So, $0.58 for hardware crypto on chip).
      Crypto everywhere. Crypto forever.

  4. Use an AVR Xmega. It has AES and DES Crypto engine built in. Its just a pity that they did not base Arduino on a chip like this. 32Mhz, DMA Events etc… whats not to like for an 8 bit MPU?

  5. Look into Shamir’s secret sharing algorithm… It can be used for “encryption” and “hashing”, and can be made to use very little resources.
    While it is not true encryption or hashing, it is very secure if done carefully.

Leave a Reply


You are commenting using your account. Log Out / Change )

Twitter picture


Facebook photo


Google+ photo


Connecting to %s