AES encryption on embedded device: Can this be secure?

Moritz Beutel
  • AES encryption on embedded device: Can this be secure? Moritz Beutel

    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.

  • 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.

aes random embedded-system
Related questions and answers
  • because it means that I am slightly limited when it comes to the use of frameworks that might help with security. What I am currently doing is the following: The client has the password stored... the hashing algorithm and code from here and here. My assumptions: If I assume that the client itself has not been compromised, this should be secure. If someone gains access to the server's database, the users should still be safe because the passwords are hashed. I can transmit the passwords to the server in plaintext (Base64), because the transmission itself is secured via HTTPS. I'm only working

  • can see) advantages to using a "wacky" hash over a normal hash: Sure, your system should be secure if the attacker has the source code, but it's a very likely possibility that your attacker wont have...I'm afraid I'll have tomatoes thrown at me for asking this old question, but here goes. After reading that cooking up your own password hash out of existing hashing functions is dangerous over... if everything about the system is known. Agreed. This is basically the motivation for not storing your passwords as plaintext in the first place. But if my response to the first criticism stands

  • is posing a serious usability issue since we need to authenticate for 90% of the use cases in our application) Can we reduce the iteration count OR do without it since we have added an additional layer...As mentioned in this wonderful link, the way to get a PBKDF2 Hash of a user given password given a password (of course), a salt (generated Cryptographically Secure Random Number Generator... line of thinking. Please validate. Keep the salt argument to the method pbkdf2 (in the code snippet above) secret (obtain it from a highly secure HSM as opposed to storing it in the database alongside

  • username and password). I am using serpent 256 to encrypt the files, and I use a random key (created Crypto.Random in python) that is encrypted using GPG, with a 4k key. Side question: The key is sha256... data from my program to, let's say a browser text field or a terminal. I am concerned about keyloggers. So, clipboard is out, virtual typing is out. I don't know what to google, so search term suggestions are welcome too. I am working on linux (I don't care about other OSes) with python. The code so far:

  • I need your advice on the security of this design. I have a scenario whereby a server application and a smart card application need to share a value e.g. 52, which has been encoded in a long... that I need to be aware of? Any advice will be welcome. Thanks - - - EDIT (24-Apr-2013 14:45pm GMT) - - - It must have been a long day and a late night and after reading all the great responses (i.e. sanity checks) below, I seem to have come back to my senses and jettisoned the poorly thought out, home-made crypto idea. :) As a bit of background, this solution is meant to be used in rural

  • the EK's public key hash sufficient to identify a unique host/device? (Assuming all you want is a "fingerprint" and not to encrypt/decrypt with it.) And in fact, this is sort of suggested by the other answer to the question which suggests generating an AIK and using its public key. (But why do you need the extra step of generating an AIK when you can just use the EK's public key?) Update: @Andre, in a comment below, says that the EK can be reset and regenerated by the device. I didn't know this, thanks! Microsoft says "The endorsement key is an encryption key that is permanently embedded

  • . We are using AES-256 symmetric encryption, but the fundamental problem remains even for a PKI solution, as you still need to secure the private key. Note also that we could use a keystore instead.... So, what is the best practice for storing a secret on the cloud? How should a web app load such a secret? I would be particularly interested in a Java solution, but this is a general problem in any... users (scaling to millions). All user data will be encrypted on a per-user basis with standard encryption. The password-protected encryption keys will be stored on a remote secure keyserver, which

  • )) I've done some of my homework and so far I have: Smart cards (Basic cards, JCOP JAVA cards). Pros - have protected storage, can run code. Cons - firmware limits, every card need separate reader.... Device itself should be able to run program code of some kind and have some common connection interface (ex. usb). You must be able to burn code only once, or there must be assurance that no one can...I'm looking for some embedded device that will be able to store sensitive data like certificates, private keys, etc. It should comply with following requirements: Sensitive data, stored

  • An answer to a recent question has given me an idea for a school project (security CS program). Also, an active attacker (with a fake base station) can potentially force a mobile phone to use... limited research, but I have two main questions: What equipment would I need to buy and how much would it cost (this project is self-funded)? The article said $1,500, including the laptop (which I already have), but did not give any specific information on the antenna. What sort of APIs/libraries/etc., if any, exist for the communications protocols? If none, I can probably try to implement

Data information