Hacker News Reader

Comment by dboreham | Hacker News Reader

Time for an open source u2f token.

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.

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

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.

https://w3c.github.io/webauthn/#attestation-statement

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 am aware how attestation works and what problem it addresses. But I strongly believe the power imbalance it creates outweighs the benefits.

Especially with bullshit like CF using it as a captcha substitute. https://blog.cloudflare.com/introducing-cryptographic-attest...

This fucking article.

CF, WHICH IS THE FUCKING SOURCE OF THIS PROBLEM, complains about the problem

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.

The FIDO alliance offers up a JWT with attestation data: https://fidoalliance.org/metadata/

But I agree, I don't think there's any enforcement mechanism beyond whatever the RP decide.

> The idea of authenticator hardware is inherently hostile to DIY and open source

Isn't this the same with all hardware?

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.

> The idea of authenticator hardware is inherently hostile to DIY and open source

The authenticator hardware that I use every day is a device I built myself.

Like SoloKeys? The Solo 2 has a firmware written in Rust: https://solokeys.com

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.

Solo 2 fixed the bent connectors issue. Solo 2 USB-C has supply issues, you'll probably have to wait a couple of months to get one.

solokeys2 is physically better than solokeys1, but firmware is buggier

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.

https://github.com/google/OpenSK works, it runs on something like this $15 board. Could do with a case though.

https://www.nordicsemi.com/About-us/BuyOnline?search_token=n...

Nitrokey, Solokey, OnlyKey.

Reply on news.ycombinator.com