11

I am attempting to build from scratch something similar to Apple's Secure Enclave.

What I've done is use an AES library for the Arduino to create a security appliance. A random crypto key and the code are stored on the chip and locked (not readable). Service is provided through the USB serial port only. There are a few commands, like set_salt, set_IV, encrypt, and decrypt. Everything worked, except it is very slow - but hey, what can you expect from an Arduino?

To make it useful, I am planning to use it to encrypt an separate AES key stored on the computer/phone, and this key is used to encrypt the application data. My question is. Is this going to have a security risk since the application data is not directly encrypted by the Arduino? I do understand that the key used to encrypt the app data might be exposed through memory dumps, but the application programmers can minimize this risk. I also understand that the communication between the Arduino and the application needs to be encrypted as well. But beside these two, are there other holes where the risk of exposing the key is possible?

Improve this question
9
  • 1
    I can't find a better term to call it so I put it in quotes. No problem for any comment. I do understand that this is has no way to prevent any attack to the OS. The goal I try to achieve is just to secure the application data so it can be safely back up to the cloud.
    – user2600798
    Apr 18, 2016 at 15:04
  • 1
    Not to be snarky but "the application programmers can minimize this risk" is not particularly security-minded. What good is it to have the "really secret key" never leave the arduino's storage, if you are letting the key to your storage out of the box every time? Is there any distinction at all in using your device, vs just storing your key in plaintext? Encryption keys saved on removable devices are quite common.
    – Jeff Meden
    Apr 18, 2016 at 16:43
  • Also, when done with the initial testing and design, there are fuses in the chip which can be set through the ICSP port that allow you to disable reading the flash of the chip. I wouldn't recommend this for your arduino, but if you do decide to prototype it with your own board and atmel microcontroller, it may prevent an attacker from reading the key.
    – Tyzoid
    Apr 18, 2016 at 18:49
  • have you read stefan.arentz.ca/signing-aws-requests-with-your-arduino.html
    – Neil McGuigan
    Apr 18, 2016 at 18:56
  • 1
    @JeffMeden: Where does it say the Arduino allows the key it uses for encryption to be read out? I was under the impression that the intention was for the host to hold encrypted copies of many encryption keys (possibly more than would fit in the Arduino at once), and use the Arduino to decrypt them on when they were needed.
    – supercat
    Apr 18, 2016 at 19:59

2 Answers 2

Reset to default
19

First, Apple's Secure Enclave is a module which ensures that the boot loader only runs code signed by Apple. That's not what you're doing, you are trying to build a Hardware Security Module (HSM).

As you figured out, the proper way to do this is to have the HSM do all the crypto operations internally so that no keys ever leave the device - as you point out, if you hand the encryption/decryption key to the device, then it's now out of your control. So ideally you want a processor that's fast enough to do the crypto processing onboard.

That said, storing an encrypted AES key on the device next to the data, and relying on the HSM to decrypt it for you is exactly how the Android Full Disk Encryption works (I think). I would recommend reading the Android Dev page on Full Disk Encryption to give you ideas.

I'll expand this answer to give some broader context.

This question is deep enough that we should ask what your "threat model" is (ie "What kind of attacks are you trying to protect against?"). As pointed out in comments by @JeffMeden and @supercat, what level of security you need really depends on what you're trying to protect, and how you want it protected.

You mention that you want to protect the AES key from a memory dump. An AES key is valuable, but not because the key itself is valuable, rather because the information it's protecting is valuable. You said:

I do understand that the key used to encrypt the app data might be exposed through memory dumps,

This is a good thing to be thinking about, but if the data itself might be exposed through memory dumps, then it's hardly relevant. But as you say,

but the application programmers can minimize this risk.

Whether your HSM is decrypting an AES key, or decrypting the data directly, once you hand that back to some user program, you no longer have any control over its protection.

Bottom line: if your threat model includes processing the decrypted data on a PC, while also protecting said data against someone powerful enough to do a memory dump, then there's nothing your USB peripheral can do; you also need to write the software that's running on the PC.

If you start going down that line, you will end up inventing a Trusted Execution Environment in which all the processing of the plaintext data actually happens inside a secure processor, and only the result is handed back to the "untrusted" PC.

Improve this answer
4
  • Ah. HSM is the proper term, thanks. I am familiar with FDE. I want to be move the encrypted data to different devices without ever decrypting them.
    – user2600798
    Apr 18, 2016 at 15:25
  • Yeah, moving the data around encrypted should be fine with the scheme you've come up with. Essentially, the data is locked until you connect your andruino device.
    – Mike Ounsworth
    Apr 18, 2016 at 15:33
  • Having a hidden virus dumping the memory during crypto operation is the least likely scenario in our threat model. A more likely situation would be an employee gets his device stolen or temporally taken away in a foreign country.
    – user2600798
    Apr 19, 2016 at 1:22
  • @user2600798 Ah, if you're interested in border crossing-type scenarios, then you might want to read this highly upvoted question.
    – Mike Ounsworth
    Apr 19, 2016 at 1:31
1

Another big problem here is that such a device is not temper-proof. Anyone with physical access to the device can bypass your code and read any secret directly.

A determined hacker can also try to reprogram the device (if you leave the capability open) and achive the same as above.

I wonder what's the value in reinventing the wheel instead of using existing TPM, Smartcard or HVM solutions?

Improve this answer
2
  • Microcontrollers like the Arduino allow the programmer to lock the code (and the stored key) so it is not readable. The only way to get the information on the chip is first to break the packaging and read the bits with a microscope. Also reprogram the device is going to erase everything on the chip including the key. Lastly, no trying to reinventing the wheel here. It is just a personal HSM the user can carry around.
    – user2600798
    Apr 22, 2016 at 13:23
  • I will give a +1, for the general idea that an Arduino is not a purpose-built device designed to provide some level of tamper-protection against a capable adversary able to gain physical access to it. And thus, it's likely to contain some security weaknesses if it's compared to a module or chip that is purpose-designed to do so. However, as long as he or she doesn't just expect it to meet all the same requirements as a real secure cryptographic module it might possibly be acceptable for what he wants to do. (Hard for me to make out exactly what that is.)
    – mostlyinformed
    Apr 22, 2016 at 16:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .