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.
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.
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?
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.
The idea of authenticator hardware is inherently hostile to DIY and open source because you cannot produce or extract a keypair to generate valid attestation statements. Unless you are part of the cartel of course.
WebAuthn doesn’t require the RP to enforce any particular hardware attestation, and many sites (the overwhelmingly majority?) allow anonymous attestation, self-attestation, or simply no attestation at all.
Having hard-to-extract device keys isn’t “DIY hostile”; it’s critical to the attestation security model. If you want to build your own WebAuthn authenticator, then you can either form your attestation root (there’s no “blessed” vendor list that I know of) or simply ignore that part of the spec.
I happen to agree that this is a bad use of attestation (as well as a pointless one, since it’s cheaper and easier for a click farm to do attestation with a bunch of yubikeys than to contact out CAPTCHA solves).
However, I don’t really think it’s an indictment of either WebAuthn or attestation more generally: as pointed out, most public services do not (and probably will never) require attestation. The winds are against it more generally: non-attestation flows are easier to implement, and WebAuthn adoption is increasingly driven by authenticators that don’t necessarily offer useful attestations (e.g. on-device and virtual tokens). Most future users of WebAuthn won’t have physical keys of the sort that Cloudflare’s scheme will require.
Attestation isn't a necessary requirement of an authentication token, and is inherently hostile to user freedom.
If some knobsite wants to insist on me using a "hardware authentication key" (similar to how many currently insist on using email/SMS codes), but I want to set it up so that secret is stored in my browser because that site isn't so important to me, setting my own security policy that directly contradicts their wishes should be my right. Their control shouldn't extend onto my own computers(s), with the demarcation point being the Internet itself.
I purchased a few solo key 2s but have ended up pretty disappointed. Keys ended up being delivered with bent usb connectors which worries me that they will break prematurely.
And the documentation, at least when I received the keys, felt incomplete and hard to find; it did not give me confidence in the product.
I still use them as a backup key, but I decided to just by two yubikeys as my main keys.
Really like the SoloKeys... but once you go at the level of small or large MNC they do business with people like YubiCo etc only. Never with tiny shops. (Sad)
Anybody have a solokey, or have some feedback? I wanted to buy some, but the comments about bent connectors put me off, as well as the supply issues for usb-c
I backed their crowdfunding campaign back in the day. Due to $REASON I didn't test all of them when I got them, but when I got around to it two out of four were broken (the broken ones had USB-C). Their support didn't help at all (why should they? but they could have offered me keys for a better price...)
With that said, I had a Yubikey Neo die for me as well (NFC still worked, USB totally dead) - Yubikey offered me a new key for a discount.
[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.