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?

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
user2600798
  • 175
  • 1
  • 6
  • 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 '16 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 '16 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 '16 at 18:49
  • have you read http://stefan.arentz.ca/signing-aws-requests-with-your-arduino.html – Neil McGuigan Apr 18 '16 at 18:56
  • @JeffMeden: If different pieces of data are processed using different AES keys, a memory dump may expose the keys which are being used to process data at that moment, but the data which are being processed are likely to also be in memory at that time. What's important is that the exposure be limited to compromising data which is actively being worked upon, rather than everything in the entire system. – supercat Apr 18 '16 at 19:19
  • @supercat my overall concern isn't that the key is in memory from time to time, but that there is no demonstrable difference between encrypting the key at rest on the arduino, and leaving the key in plaintext on the arduino (or any other means of demarcated storage) since if you want the key from the arduino, all you have to do is ask (the IV and salt are interesting but if stored with/near the data, are ultimately pointless). What would be more interesting (if the idea is to encrypt files on their way out to the cloud) would be an arduino that was effectively write-only, to hold the new keys – Jeff Meden Apr 18 '16 at 19:29
  • 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 '16 at 19:59
  • Yes. The arduino has very limited storage and power. That's the reason for this scheme as compromise. The idea is to create a portable HSM for mobile device secure certain application data. The key in the arduino is not exposed to the outside world. – user2600798 Apr 19 '16 at 01:06
  • @Tyzoid. The whole point of locking the chip is to have the key hidden. – user2600798 Apr 19 '16 at 01:11

2 Answers2

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.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 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 '16 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 '16 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 '16 at 01:22
  • @user2600798 Ah, if you're interested in border crossing-type scenarios, then you might want to read this [highly upvoted question](http://security.stackexchange.com/q/88947/61443). – Mike Ounsworth Apr 19 '16 at 01: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?

billc.cn
  • 3,852
  • 1
  • 16
  • 24
  • 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 '16 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 '16 at 16:34