First of all, I’ve created a Google Group for those that want to be in the discussion.
I want to take a step back and think about the CryptoCape goals, because I’m too far in the weeds playing with hardware at the moment (although that’s been fun). The BeagleBone Black (BBB) is already a pretty capable device and has some support for acceleration, although my experiments haven’t turned out that well. Since it can run Debian or something similar, there are great software libraries that will do pretty much everything.
So what’s it really missing? In my mind: isolation of the key. Let’s say you are running a web server on the BBB with HTTPS. In some TLS suites, the server will sign the handshake messages with its private key. Well, all this is happening in userspace and is just one buffer overflow away from leaking the key (Note to self: check if ASLR is turned on in the 3.8 BBB Kernel).
This is where the CryptoCape can help, I think it can protect long-term device keys. With some of the modules I’ve looked at so far, they all seem like good candidates for the algorithms they provide.
Ok, so lets draft some physical requirements:
- The CryptoCape form factor bust be a fully compatible BeagleBone Cape.
- Signing keys shall not leave the CryptoCape.
- Encryption keys, for data that doesn’t leave the BBB, shall not leave the CryptoCape.
- The CryptoCape shall have a battery backed RTC (The BBB does have an RTC. I don’t know if it’s easier to have just a battery on the CryptoCape or the whole RTC and battery together).
- The CryptoCape shall provide the capability of a secure boot with a TPM.
- There shall be a physical interlock to unlock the CryptoCape. Right now I’m thinking to use the SD card as a kind of token, but that would mean monopolizing the SD card. Maybe a set of DIP switches that can be programmed as a sort of PIN? Anyway, the idea is without this interlock, no power goes to the CryptoCape.
I have some ideas for the software, but I’ll save that for another post.