[craftkiller]

Well an interesting new approach to security tokens just launched: the tillitis tkey[1]. It has open source hardware and software. Unlike other security tokens that are based around storing your key where it can't be read, the tillitis tkey doesn't have any persistent storage and instead calculates your private key by hashing the program you've loaded onto the key, a user-supplied secret, and a per-device random secret. I'm excited to see what people will do with it. I don't think a u2f application exists for it yet, just an ed25519 ssh agent so far, but it just launched this week.

[1] https://www.tillitis.se/tkey/

Otherwise, in a more traditional yubikey-replacement design, I've had my eye on the onlykey but their github has very little activity which makes me worried its a dead project.

[tadfisher]

I like the idea, but I'm worried about the FPGA being programmed to exfiltrate the secrets and re-flashed to the original program. With the Yubikey, it's mostly guaranteed that the device key remains on the device. Are there safeguards against this?

[JoachimS]

Due to the way the configuration state machine in the Lattice iCE40 UP device operates, we can't block a warm boot-attack, even though the FPGA bitstream is stored and locked into the on-die Non-volatile configuration memory. However we can, and try to, make it really hard to successfully perform an evil maid attack.

First: all registers and logic (LUTs) will always be cleared during the reset phase of the FPGA configuration. So any secrets stored there will be secure. We store the Unique Device Secret (UDS - the primary asset) in registers. Registers that can also only be read once between power cycling. The block RAMs (EBRs) however can be cleared or retain data based on the configuration <-- these are the ones to worry about.

Right now we have to touch the FW-RAM (implemented using EBRs) with the UDS for a few tens of cycles. After it being used, it is wiped from memory. So a successful exfiltration must trigger the warm boot-reconfiguration during that window of time. In order to make this harder (i.e. more time consuming) we do a few things:

1. We randomize when the UDS is moved to the FW-RAM and thus when the window to hit is. And we should not leak any indication when that is.

2. We use ASLR to randomize where and in which order the UDS is stored in the FW-RAM.

3. We use randomized data scrambling of the contents in the FW-RAM. And yes we do fill the memory with randomized, ASLRed data first.

The randomization control values are all stored in registers, and will be lost as part of the reset phase of the attack. So an exfiltration must:

1. Hit the window of time.

2. Extract the contents of the FW-RAM.

3. Be able to distinguish the random data words that make up the UDS from the other contents of the FW-RAM.

4. Descramble the UDS words and place them in the right order.

It is not an impossible attack, but it should take a long time. And it should not scale easily from one device to all other. One could automate it of course, but the work should be the same (multiple exfiltrations) for each device.

But we still think that the attack IS possible, and it is therefore out of scope of attacks that we mitigate for this version of the TKey. The next version will hopefully be able to keep the UDS in registers only. When we have that working, the threat model will be updated to reflect that.

[voltagex_]

>Currently we ship to EU/EEA countries, Norway, Switzerland, UK, USA and Canada