AES encryption on embedded device: Can this be secure?

Question

I plan to create an encryption program for an embedded device with the following characteristics:

• CPU is Intel 80186 compatible @ ~20 MHz
• 128 KB RAM, of which I have ~20 KB at my disposal for purposes of encryption
• application binary size limited to 128 KB, but I'd like to keep the encryption part < 16 KB
• persistent storage in Flash memory

---

These are the requirements:

• encrypt small text files and bitmaps < 32 KB
• I can always decrypt the entire file to RAM, i.e. I don't need random access
• the encrypted files are not "locked in" by the hardware, i.e. they can be transferred to a PC at any time, so I want to protect against someone who steals the device and tries to decrypt the data
• I am not worried about software exploits, keyloggers and so on (assume I never borrow the device to anyone and keep it under my pillow at night, and also assume the NSA doesn't break into my house to chloroform me and install a targeted exploit)

---

I'm far from being a crypto expert, but I spent some time reading Wikipedia on AES, block cipher modes and key derivation algorithms, and I also read "If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong". All this has made me doubt whether I can succeed given to the limitations of the hardware and my superficial knowledge of the subject, but I'll try.

The following steps line out what I plan to do:

• I plan to follow the basic procedure lined out in this response, that is: encryption with AES in CBC mode, key derivation with PBKDF2, random salt, random IV.
• Because I'd prefer AES-256 instead of AES-128, I would use PBKDF2 with SHA-512 so I can derive a key of double length.
• There is no reliable random number source on the embedded device, so my plan is to have the user generate the random key (k1) on a PC and transfer it (probably by manually typing it in). This should not be a problem because it only happens once, i.e. I use the same key (k1) to encrypt any number of files.
• The play/essay "If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong" points out the dangers of an attacker who has control over the encryption process, i.e. who can supply arbitrary plaintext and have it encrypted, because this enables all kinds of side-channel attacks such as "error oracle". Am I right to assume this is not an issue for me because the attacker only gets to see my encrypted files?
• My understanding is that I should generate a random IV and salt for every individual encryption so as to avoid identical outcome for identical plaintext. But do IV and salt have to be cryptographically strong random numbers? The best I can do would be a Mersenne Twister (or preferably something more efficient) seeded with hash(concat(time, battery voltage)); but is this neccessary at all? I store both IV and salt in plaintext anyway, so I only need to make sure they are different each time, not worry about their predictability.
• I plan to use either this implementation or one of the implementations linked here, of course after verifying them with the NIST test vectors. Is there anything else I must check for when choosing an implementation?

I'd be grateful for comments telling me which parts are wrong, unsecure or should be improved. Also, if there is a trusted AES-256 implementation for Intel 80186 I'd love to know about it. And finally, if you think it is hopeless, don't hesitate to tell me.

Answer 1

You don't specify a use case for this, so it's difficult to understand the limitations, and if this is "secure".

You didn't mention using an HMAC, but I'm assuming you're aware of the need for one under certain applications.

You want to use AES-256 over AES-128, but don't specify why. AES-256 requires 14 rounds, vs only 10 for AES-128, so AES-128 is considerably faster, which may be significant in the very limited environment you're dealing with (16 bit words for instance). AES-128 is already extremely secure, and there's little if any additional security offered by a larger keyspace, especially if you're using user typed passwords which almost never have a full 128 bits of entropy.

IV doesn't need to be unpredictable (the IV must be known to any attacker anyway). The only important thing about an IV is that it's not re-used. Personally I'd use a random seed that's hashed every time a new file is encrypted, and the results saved back the random hash. The next IV will always be predictable, but given enough initial entropy will never be re-used, even globally across all devices.

Answer 2

The security of this scheme depends on exactly what the attacker is able to read. Remember the embedded device is performing decryption, so it clearly has all the parts needed to do so (encrypted data, key, and algorithm)

• If the attacker has any sort of debug connection to the system (e.g. JTAG) -- Game Over (immediately and effortlessly). Attacker can just read the decrypted content from RAM.

• If he can read only your data files, and your AES key is one of them -- Game Over.

• If he can read only your data files, and your AES key is embedded in code in a separate memory -- Ok (maybe).

• If he can read both data files and code memory and the AES key is stored in the code -- Game Over. Attacker doesn't even need to reverse-engineer the key, he can just execute the code and let it dump decrypted content into memory. Finding virtual environments capable of executing x86 code is trivial.

• If he can read both data files and code memory, but the code pulls the AES key from an on-die secure memory designed explicitly for tamper-proof key protection -- Should be ok. Unless the attacker can cause the microcontroller to execute modified code and copy the decrypted data from microcontroller memory.

• If he can read data files, and the AES key is stored in a secure memory, but that memory is not on-die -- Not good. Attacker can steal the key as it is transmitted between secure storage and the processor core. More difficult than the software-only attacks, but still insecure.

Basically, protection of code and off-chip data requires a chip designed with fuses to burn out the debug interface, code stored on chip with all external access denied by those same fuses, encrypted data, and an on-board tamperproof key storage. It's very unlikely that an 80186-era chip would have these features (especially the latter), although based on the memory sizes and clockspeed, this is a modern 80186 clone which might.