I have a product that is going to be deployed in large numbers, and I want to maximize the trouble that someone is going to go through to reverse engineer it (a high level of security). It is an internet-connected product based on an STM32 microcontroller that connects to a server to retrieve its firmware update blobs and stores it on an external flash memory.
Here are a few facts about the situation:
- ~1 Megabyte firmware build size
- There is no encryption hardware accelerator on the chip
- Since the DFU process is blocking (the system stops working), we need the decryption process to be as quick as possible
Since there is a wide variety of encryption schemes implemented in the STM32 crypto library, is there a preferred encryption scheme out of all of these that I should use to encrypt/decrypt the data being stored on the external flash?
Best Answer
I don't know if there is really any metric that makes any algorithm 'preferred' over any other in regards to flash, but I would suggest doing what hardware encrypted flash drives are doing, and just use either AES-128/256 CBC or CTR.
CTR just uses a counter as a nonce, making it a bit faster and removing the need to store every single key for every 16 byte block in the chain in memory (which would amount to requiring the same amount of RAM as there is firmware). CTR actually turns a block cipher into a stream cipher, making it relatively painless to write each block to flash as it was decrypted, minimizing the time spent in RAM (and thus time spent being vulnerable to cold boot attacks). It is well suited to embedded flash encryption, and indeed, CTR mode is often the more heavily optimized encryption scheme in embedded libraries.
In general, decrypting AES-256 is 40% slower than AES-128. So there is little advantage to using AES-128 over 256, in my opinion.
As for actual decryption time, I think you may be hugely overestimating how difficult this really is.
For one, AES accelerators really only yield around an 8 times speed up on the STM32 at least, so doing it in software is not even hugely slower.
For AES-256, most libraries I could find took around 1600-2000 cycles per block decrypted. I don't know what your clock speed is, but assuming worst case, for 1MB, that would be 131,072,000 clock cycles. Depending on your exact STM32, that could be anywhere from 2 seconds to 500 ms. But, just to be clear, in general, even AES-256 in software is still measured in MB/s on the STM32 platform. Probably not much more than 1-1.5MB/s, but it's MB/s nonetheless.
And, you can get assembly-only libraries capable of doing AES-128 (which, in my opinion is also good enough, if you really want every last bit of speed) in less than 700 cycles per block. See https://cryptojedi.org/papers/aesarm-20160718.pdf
But, regardless, it is hardly a massive time sink to decrypt 1MB of AES blocks. AES is probably as close to a 'preferred' encryption algorithm as you'll get, mostly because one of the main criteria that was used to choosing which algorithm would be used for AES (by the US Military) was performance. So other encryption schemes are unlikely to be any faster than AES, unless they offer significantly less security as a trade-off.