Teensy as a secure storage for private keys

Status
Not open for further replies.
C

cpalm

New member
Hello,

I want to build an authentication application which requires a Teensy to be in an USB port. Therefore I want to store an RSA private key on it.

Now I have some security considerations:
1. How safe is the Teensy in regards of hardware cloning?
2. What about reading program/data from the Teensy? Is this possible?
3. If it's possible to read program/data e.g. from a stolen Teensy would it be possible somehow to block that by somehow "finalizing" everything?
4. In an ideal world the only attack I don't want to be spcifically take care of is: dissolving the chip in an acid and reengineering the current state of flash and everything else...

5. Is there a version of the Teensy that comes with a case? I don't need the additional pins in my application. Ideally there is a Teensy which is even smaller because the connections are left out.

Thanks for feedback!

Christian
 
Pretty sure anything written in a Teensy is recoverable - you'd want to encrypt it well and require a key to re-assemble it. The Teensy could let you do that coding easily enough. I assume the RSA key comes off USB in plaintext so you trust that - so then you could trust the password going in nearly as much on a safe system.

The atsha204a chip would give you ways to up the uniqueness 'Teensy' as it is uniquely serialized and maybe even help provide safe key storage.

The Teensy is given a Serial# - I'm wondering if that is Sketch readable and if it can be spoofed/changed? Is that is part of the MiniTan programming (which would make it safer)?
 
The Teensys have a unique MAC that can be read out. I have seen posts about setting the write once bits to code protect the chip (lots of OEMs don't want firmware cloned either). Even without that pulling the software out of a Teensy via USB isn't possible unless the software was written in the first place to support it, since the core design is when you hit program the mini54 takes over the IC and does a lobotomy before any 3rd party programing takes place (current version does leave EEPROM though so don't leave your key there).

What this doesn't do is prevent someone pulling the IC off and sticking it in a socket with JTAG (which is an expensive off the shelf item so not impossible) and making free with it.

So setting the write only fuses may be helpful. Freescale Document Number: K20P32M50SF0RM, chapter 8 apparently.

I have seen it discussed multiple times but I don't believe anybody has published code to do it since of course it bricks the Teensy and nobody has been keen enough to verify it.

Re the form factor there is just the one, and suspecting the K20 IC is actually rather more than you need for this. If you want to use the Teensy because it's easy to develop for you can design your own PCB (given most of the pins aren't needed for you) using the mini51's sold by PJRC https://www.pjrc.com/store/ic_mini54_tqfp.html, possibly as a plug once programer. So you have a baby PCB with the USB and power components and some sort of programing header.

That said if you are already going the route of custom PCBS that can't be reprogrammed it might actually be easier to find a CPU designed specifically to resist attack and be done with it.
 
Last edited:
Teensy is small but not the smallest and certainly could be overkill (best kind). That 204 chip is tiny and can run off i2c, or 'single wire' with general libraries on smaller chips and might provide help in securing the data on any device that can also do USB. Combo of CPU and that 204 chip could easily obscure the key and split it across the two devices. The 204 has some hardening that require the approved interface to remove encrypted eeprom data. I've only scanned it so far so it may have features or limitations that help or hinder its use in this case. The 204 [has unique factory serial# and 64 byte one time write area] can store some part of 4Kbit as user data - combined with storage on Teensy - as long as the USB prompt process (and/or other user input) is needed to provide a third key element the other two parts are just a random number generator.
 
Last edited:
Ok a three pad SMD version of a CPU is new for me. Amuses me that we can now use rolling 256 bit keys to secure our ink cartridges.
 
in 'disposable' cartridges ... with the pen mightier than the sword each pico-liter must be accounted for! A 3 pin, 230baud Specialty Function Logic 'processor'? About 75 cents each - under 500 and .57 or less 500+
 
If you're going to store the private key inside your Teensy, to keep it truly secure you'll probably need to write to location 0x40C in flash to permanently lock and "brick" your Teensy. Once locked with mass erase disabled, Teensy can never be unlocked, erase or reprogrammed. Teensyduino and Teensy Loader won't let you do this, no matter what data you put in your HEX file at 0x40C. You can only accomplish this with code (running on the Teensy) that erases and rewrites that flash block. I never publish example code specifically to do this, because, well, it bricks a Teensy. But for good security, you probably would need to do this, so the private key is secure (at least as secure as Freescale's hardware locking) and can't ever be read or altered.
 
Crypto security is a real tricky business.

You want to store a private key on a Teensy, probaly with some program on the Teensy that
in unison with a PC program, decides that it is time (safe) to transfer the private key to the PC.

So the question as regards safety is which is harder, to retreive the private key from Teensy flash, by
scanning flash, recovering program, or to fool the keyhandling application programmed into the Teensy
to nicely hand over the private key.

Without any extra information its hard to tell wich is the weakest in the proposed scheme, but its always
true that no chain is stronger than its weakest link.
 
I have been working on a project to to use the Teensy as a key management / Encryption device. The idea would be that it would be a very flexible and powerful add-on root of trust. Before I started down this road I was using the mentioned ATSHA204 and ATECC508A (as part of the cryptocape https://www.sparkfun.com/products/12773) but after reading the datasheets I really don't think these provide protection if an attacker has physical access to the device (depending on the design). So my project uses the Teensy along with the Maxim DS3640 for key storage and tamper protection. I put together a basic library here https://github.com/cr7pt0/DS3640. My next step is to incorporate AES or ECC functionality but I have not found a good library yet so suggestions would be appreciated. This is really my first Teensy project so comments and collaboration would be welcomed.
 
I don't know what your time scale is, or when the Teensy 3++ will be announced, but Paul has said that the Teensy 3++ will be based on the Freescale Kinetis K66 chips. The high level datasheet for the K66 chips indicates that it has support for an AES/DES accelerator (cau). My minimal reading of the spec sheets says that CAU is optional on the MK2x chips (used in Teensy 3.1/3.2) but it is standard on the K66 processors.

I wonder if that means the K66 is import/export controlled, or perhaps it isn't considered fast enough to warrant some countries prohibiting its sale.
 
What is your threat model? Ruling out modifications to the die is a good element of a threat model, but which kind of attacks are ruled in? What are the stakes?
 
Hey thanks for the replies, that was quick this forum is great!

Pictographer - My threat model is I want the key to be inaccessible to an attacker that gains physical access to the device, or logical access for that matter. Essentially FIPS 140-2 Level 4 equivalent. The attacker would in this scenario have considerable means to attack hardware. The idea is that the entire device would be enclosed in a tamper respondent enclosure (consisting of overlapping wire mesh attached to the DS3640). Attempts to penetrate the enclosure to gain access to the hardware in order to perform typical side channel attacks on hardware will result in a change in the resistance of the wire mesh, tamper of DS3640, and wiping the root key. The root key (or key encryption key) would be used to encrypt other keys so once it is wiped all keys are sanitized. The root key is only stored on the DS3640 and temporarily in Teensy RAM while being used to decrypt other keys.

Obviously this design assumes that an attacker cannot gain access to the hardware without tampering the DS3640 (which with a properly designed enclosure I think would prevent all but the very best from gaining physical access to hardware https://www.maximintegrated.com/en/app-notes/index.mvp/id/4185). If an attacker can access hardware without tampering they could obtain the root key by sniffing the key when it is transmitted across the I2C to the teensy.

One reason for this project is that it is becoming increasingly easier to perform attacks on hardware and I think physical tamper protection is not just for credit card readers and government encryption devices anymore. These types of hardware attacks are now not just possible for threat actors like nation states, they can be done by individuals:
https://hardsploit.io/ - The v2 of this when it comes out will be able to sniff and replay I2C, I imagine that this would defeat a lot of TPMs since an attacker could capture and replay the static values sent to the TPM.
http://newae.com/chipwhisperer

I have not tried either of these but they look promising. Thoughts on the threat model?

MichaelMeissner - AES in hardware would definitely be an awesome feature. I would buy it.
 
You could add an SD card to the T3 and use FATFS. And an app that uses AES128 or 256, or creates an encrypted zip file, etc. Then store that on the SD. Then you need not trust the T3 itself.
 
cr7pt0 said:
I have not tried either of these but they look promising. Thoughts on the threat model?
Click to expand...

Brief thoughts now, maybe more after some reading. First, it's nice to see this level of sophistication. I'm curious whether you're intending to mass produce these or content with a small number of hand-crafted units and whether or not you intend to open source all of it (that isn't already).

In my much lighter-weight thoughts about creating a password safe, I address the threat of physical access to the hardware by requiring a password to unlock the device, by giving no immediate feedback about incorrect password attempts and by storing all the sensitive material encrypted. If your device password and encryption is strong enough, do you really need to worry so much about physical tampering? I'm willing to accept the risk that user fails to maintains custody of the device allowing the attacker a chance to plant a trojan in it. Perhaps I should at least consider making it tamper-evident.

Since my personal efforts in this area are mostly a shared learning exercise and what I'm attempting to make more secure are personal passwords for routine things like banking and since I'm not a high-value target (not rich, not famous, not well-connected, not much access, etc.) I'm trying to strike a balance between something I'll have time to actually build and use against something that addresses every conceivable attack but never gets off the drawing board.

I'm also not worrying too much that my development platforms and my physical environments have already been compromised. Sadly, a determined attacker probably wouldn't have much trouble doing this. I'd like to think that someone with a serious need, i.e. political activist in a repressive country, would be able reuse ideas here, but be cautious enough to be really clear about their threat model and to do the critical part of the work in a more secure environment.
 
If you want to store keys on a teensy, encrypt them. Add a little keyboard to allow a) entering a key to decrypt the keys and b) cause the teensy to transmit the right key.

If you want a USB authentication dongle, I assume that you would lock the teensy and use Diffie-Hellman key exchange.
 
defragster said:
I saw this secure storage 32Kbit EEPROM last night - SPI or I2C interface: Atmel ATAES132A-SHEQ-T .

Does this offer any generally trustable and useful features? I'll post this on the other thread linked in post #12 with some summary details from the data sheet.
Click to expand...
yes. A fast scan of the data sheet says
  • AES Algorithm with 128-bit Keys
  • AES-CCM for Authentication
  • Message Authentication Code (MAC) Capability
  • 16 EEPROM counters (for the nonce) and a random number generator to seed the nonce.

Says it's data storage is 16 banks of 2Kbits each, for data.

8-pad UDFN and 8-lead SOIC Package Options


You can do this in your firmware (as I had to do with an NXP LPC2106 ARM7).
The hardest part is keeping the nonce/counters in sync with a copy thereof held by whatever is accessing.
Free AES128/CCM code on the web, at NIST.
In my case, this was wireless communications. So the nonce supported mutual authentication as well as lost and duplicate wireless packets in the protocol.

Be sure to decide early if you NEED mutual authentication and use of the nonce, etc. Fixed shared keys, or temporal key changes, is so much simpler.
 
@Steve - Now I've done it - posting here and there I split the focus. This thread just wanted secure storage - the other is general authentication/security. On the other thread it would be interesting to see how you can tell when a device has left the authenticated group. And how you keep the others in the loop, or get one back in?
 
Excepting shared-key for access control (may not be secure enough), I'm not familiar with group-wise mutual authentication. Mutual, because of the risk of a counterfeit device.
 
Status
Not open for further replies.
Back
Top