7 ms·
Hey, can you share some crypto advice for limited embedded systems (let's say minimum being 32bit cortex-M0). Say for firmware updates, user data uploading, etc
by suf 9y ago
Hey, can you share some crypto advice for limited embedded systems (let's say minimum being 32bit cortex-M0). Say for firmware updates, user data uploading, etc.
- asd2r23dasd 9y agoAdvice for that kind of problem typically requires a lot more context, e.g.: * You need to do symmetric crypto between two MCUs, where only one has an RNG; * You need to do symmetric crypto with no RNG; * You can't rely on your MCU safely storing state / unreliable transports. Cryptography and libraries/standards are gradually building towards a world in which higher-and-higher level abstractions let inexperienced web/high-level application developers build safe systems. The same isn't really true for the lower-end of the embedded space, and consequently you can't really produce an equivalent set of (reasonable) guidelines like the ones linked.
- loup-vaillant 9y agoUse Monocypher, TweetNaCl, or Libsodium. Monocypher is portable (C99/C++), pretty fast, and has low memory footprint (generated binary between 30kB and 60kB). Problem: it isn't trusted yet. (I'd like to run a bug bounty, but I'm not sure how I should go about it.) TweetNaCl is portable (C89), has low memory footprint, and is made by trustworthy professional cryptographers. Problem: it is slow. Libsodium is blazing fast on modern processors, has portable implementations, and is trusted. Problem: it is pretty big, and I hate the auto tools. Edit: of course, those recommendations only hold if you have a trustworthy RNG.
- MrBuddyCasino 9y agoGot an opinion on BearSSL?
- tptacek 9y agoI can't be sure, but I think he thinks you should use his thing.
- loup-vaillant 9y agoI'm not yet to the point where I can recommend my thing without even mentioning the other two competitors. I did get bloody thorough, though, and I do think it is good enough for me to bet my job. (Meaning, I'd be willing to lose my job if my employer uses Monocypher on my watch, and data gets leaked because of that choice.) (As for the original question, I don't know BearSSL enough to have an opinion. It does seem however to get even further than Monocypher on the constant time thing. Monocypher needs the platform to provide constant time 64-bit multiplication. Most do, but not all.)
- dsacco 8y ago> (Meaning, I'd be willing to lose my job if my employer uses Monocypher on my watch, and data gets leaked because of that choice.) Would you be willing to be personally liable for that data leak? (Put aside the philosophical question of whether or not it's reasonably for developers to be personally liable for their software failures - I'm interested in how far your confidence in your cryptography goes).
- vardump 9y agoWhat could be used with a small/medium sized microcontroller, something like 64 kB total flash budget and 4-20 kB RAM? IOW, Cortex M0 territory. Small IoT is about this size, so I think many will be interested in some answers... any answers. Say, for securely transmitting sensor data to an x86 server (or similar) without hardcoding symmetric keys on the devices.
- asd2r23dasd 9y agoWhen you're that small it really requires more context. What are you trying to do? I've deployed TLS in 50 KiB flash and 6 Kb RAM. But I could rely on hardware support for some public key operations and could pick a single ciphersuite, and controlled the server end as well. The boring answer is that you'll need to identify the set of primitives you need and then find a library that matches. I can't think of any single primitive that would break that budget, so it'll depend on how many you need!
- loup-vaillant 9y agoTake Monocypher or TweetNaCL, and rip off any primitive you don't need. This may be enough. Even when you take the whole thing, Monocypher only needs 30kb of x86-64 machine code when compiled with -Os. If you only keep authenticated encryption and x25519, which are enough for many uses, I think you should be able to halve that down to 15kb or less. If speed doesn't matter, TweetNaCl is even smaller. If those aren't enough still, you may want to dive in, learn a ton about crypto (starting with https://www.crypto101.io/ https://www.crypto101.io/), and investigate the sponge construction, whose versatility may allow you to shrink the code even more. Perhaps. I'm in over my head at this point.
- posterboy 9y agoavr has aes extensions, surely arm cortex-m has similar. are those any good, are they used by the libs you mention?
- loup-vaillant 9y agoIf they have hardware AES support, forget everything I said. Monocypher and TweetNacl are portable C, they don't use extensions of any kind.
- lvh 9y agoDisclaimer: I'm not 'tptacek but I'm one of the Latacora principals and co-edited this document. Embedded crypto gets weird fast. General recommendations are a little tricky, but: is that device talking to the internet directly or some kind of IoT hub or whatever?
- suf 9y agoLet's say talking directly to the internet.
- lvh 9y agoIf it's on the raspi side of powerful, just use OpenSSL, or maybe Go's TLS stack, again, assuming you can get away with it. On smaller systems, things get weird. If you can't afford go/openssl, there aren't a lot of things I'm very confident in. BearSSL near the top of the list. That's still double-digits kilobytes of RAM though, so maybe I just ate all your budget. You might be in one of the cases where a NOISE protocol instance is in fact the right answer; depends a little on what else the box is doing and how frequently. Sorry, I get that it's not a satisfying answer :-) It's complicated!
- suf 9y agoThanks, yeah embedded systems are always an exception that makes for strange design.
- lvh 9y agoYeah. Unfortunately this cuts both ways: I've also heard "you don't understand, we are on an embedded platform" when they mean "we're on a raspi".
- Cyph0n 9y agoWhat's wrong with PolarSSL/Mbed TLS? It is designed for low-end ARM processors and is directly backed by ARM.