10

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.

Community
  • 1
Moritz Beutel
  • 201
  • 2
  • 4
  • I'm not sure about your hardware / CPU / OS (if present). However, could you take a ready implementation of AES256 (e.g., http://www.literatecode.com/aes256) and cross-compile it for your processor? For cross-compilation, see http://stackoverflow.com/questions/227762/looking-for-16-bit-x86-compiler and http://www.embeddedrelated.com/usenet/embedded/show/35751-1.php – Andrey Sapegin Feb 18 '15 at 10:04
  • Thank you, but cross-compilation is not an issue (if my question were about cross-compiling I'd ask on StackOverflow); and my post already linked to the implementation you are referring to. I am asking about the security of my outlined approach, not the technical details of the implementation. – Moritz Beutel Feb 19 '15 at 10:31

2 Answers2

3

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.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • The embedded device is an ancient PDA which I'd like to use for storing sensitive data (think passwords, personal thoughts etc.); I hope this clarifies the use case part. I wanted to use AES-256 because I thought a) it would increase security and b) performance doesn't matter for KB-sized data, but I guess you are right about password entropy. – Moritz Beutel Mar 19 '15 at 20:06
  • Yes, I'm aware of MAC/HMAC (though I believe I didn't fully understand them), but as I wrote I don't see an "oracle"-based attack scenario because data can be encrypted with my key only after my password has been entered, and authentication doesn't seem to be an issue either. Or am I missing something? – Moritz Beutel Mar 19 '15 at 20:25
  • if it's just you interpreting the message from a PDA, then it's not so much a concern as you're likely to notice garbled nonsense at the end. In a practical sense I wouldn't worry about it, but if you want to think more deeply about the problem, consider this. You start using the PDA to put in appt times for a secret meeting. The message to yourself is simply "Meeting with Deep Throat at 10". The attacker (somehow) knows you always end the message with the last one or two bytes as the time. He garbles the last byte, so it now reads "Meeting with Deep Throat at 1". (continued) – Steve Sether Mar 20 '15 at 16:03
  • You go to the parking garage, and Deep Throat isn't there because you're going at the wrong time. Deep Throat gets spooked, and suspects you've been compromised and stops revealing watergate information. So message integrity can still be important even when you might not suspect it. In this case, the attacker got lucky and still created a valid, but modified message that you interpreted. But it doesn't matter, since you were still fooled and could have been saved had you used an HMAC. It's a contrived situation, but it demonstrates how message integrity is important. – Steve Sether Mar 20 '15 at 16:09
  • 1
    Very vivid scenario :) I think the attacker would have to be very lucky to garble my data such that "10" becomes "1"; he has no insight into the exact message length due to AES block size, and removing or altering a block is likely to catch my attention, so it's a risky manipulation. On the other hand, I might occasionally sync the data with a PC which has a much larger attack surface, so it's not entirely unreasonable that my data might be manipulated even without physical access to my device. So maybe I'd better use a HMAC. – Moritz Beutel Mar 21 '15 at 09:29
  • It's paranoid to be sure. But the use of an HMAC allows you greater flexibility to in case you want to extend the functionality to something else. Software tends to creep in its uses, so planning for reasonable extensions of use is a good way to think. – Steve Sether Mar 24 '15 at 03:57
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.

Ben Voigt
  • 760
  • 1
  • 10
  • 17
  • The device is an old obsolete PDA (cf. my comment in Steve's answer) which has no secure storage features whatsoever, so everything that is stored on the device can be read by anyone with physical access to it. The idea was that it shouldn't matter because the AES key is encrypted with my password following the procedure described in http://security.stackexchange.com/questions/38828/how-can-i-securely-convert-a-string-password-to-a-key-used-in-aes/38854#38854 , and because I'd be careful to never store decrypted data anywhere except in volatile RAM. – Moritz Beutel Mar 19 '15 at 20:10
  • Oh, and I assumed the device is never connected or accessible in any other way while I'm working on decrypted data. The only way to connect to it is via RS-232, and the wiring setup probably wouldn't go unnoticed. – Moritz Beutel Mar 19 '15 at 20:13
  • @MoritzBeutel: So, the password is entered by the user into the device each time just before the decryption is performed, and never stored? That's a bit different from "manually copy the key, once, storing it in plaintext on the device" that your question seems to indicate. Then the attacker has the code, the keyfile, and the datafile, and has to attack the password protecting the keyfile rather than the key itself. – Ben Voigt Mar 19 '15 at 20:21
  • Sorry if my phrasing was a bit imprecise. But I didn't mean to store the key k1 (which I'd transfer manually) in plaintext, it would be encrypted with my password (which would be transformed with PBKDF2 as described). So yes, the password will have to be typed in every time the data is accessed, and any attacks against k1 would actually be attacks against my password. – Moritz Beutel Mar 19 '15 at 20:29
  • @MoritzBeutel: So the other threats you face are that the attacker is able to get another application running on the device while you enter your password, that reads either the decrypted key or decrypted data from RAM. – Ben Voigt Mar 19 '15 at 20:42
  • Sure, everyone who has physical access could install a keylogger -- Game Over. But that is not a cryptographic threat, and hence not subject of my question. Also, this is true for almost every non-trivial computing device I am aware of. – Moritz Beutel Mar 19 '15 at 21:10