Designing Solo, a new U2F/FIDO2 Token | Hacker News Reader

Designing Solo, a new U2F/FIDO2 Token

conorpp.com

144 pointsecesena93 comments

A personal hardware security device is useful not just for logins but signing messages and encrypting data.

Imagine signing up to a site or service,all you need to do is allow it to generate a unique public/private key pair on your personal hsm. You would optionally associate a username with the public key,but that's it!

No need to enter name,address,phone,email,etc.., Unless required for the service. You won't even need a password(!!)

Lost the personal hsm? No worries,you wrote down a recovery key on paper and stored it next to your social security card and passport.

Here is my thing, simpler security is better security. I use a yubi everyday and it's nice but I also use TOTP and SMS every day. If I am using a hardware security device,why do I need any other form of authentication?

Why can't that same device be used for TLS client certificate storage for every site I visit,storing SSH private keys,trusted root CA store I can use with any device, message(email,signal,telegram,etc...) Encryption,message non-repudiation(think a twitter post or even this comment being signed by my hsm so I can't say 'the hackers did it'). You can use it for banking,voting,signing important documents online,etc...

You can already see how much work goes into adopting something like a yubikey. Why not make it a general purpose hsm that solves all these security problems.

You know what I like about this the most? Minimal user education required,just plug it in,click yes on the app's prompt and press the button on the hsm. Not only that,you can't phish or some other way social engineer the user to give up the private key. Users can keep it on their keychain or building access badge that would give physical attackers similar level of access(they can unlock your house keys and steal pii or get in the building with your badge and steal your laptop).

A user friendly usbarmory for the lay-person!

Because the parts you need to provide the functionality you want at the level of security Yubico is promising are expensive.

I don't buy that argument. I have purchased Blu phones for under $50,yubikey nano cost me ~50. Plus,it gets even cheaper with mass production.

A cheap smartphone without radio,screen,large battery with a custom os and a usb connection would be an even cheaper phone. The only things a personal hsm would add might be nfc and hardware rng. I'm surprised yubikey hasn't gotten cheaper even with companies like google using it.

> I'm surprised yubikey hasn't gotten cheaper even with companies like google using it.

The cost is probably much cheaper, but there is no reason for them to lower prices when there isn't really major (popular) competition.

I think once Google releases their key for general sale, Yubi will be forced to drop prices to compete.

Google's key is, from what I understand, just a relabeled Feitian. You've been able to buy them for a long time.

Feitan are also way less reliable than Yubico. My Yubico keys have lived in my pocket on my keyring for six months, no problems. My feitan sat on a shelf, and its Bluetooth is now so unreliable I'm getting a second Yubico key for nfc.

That phone does not make the hardware security promises Yubico makes. You can't make a hardware security module with a cheap ARM core and nothing else.

True, but an ARM core and a ATECC608A ?

- FIPS compliant RNG and key generation

- Hardware based key protection

- Secure (encrypted) on chip key (ECC, AES, SHA HMAC) and data storage

- Guaranteed Unique 72-bit Serial Number

- Boot validation

If what you need is the management of 16 different NIST P-curve keys and nothing else, and you don't necessarily care if the whole package is secure against DPA, that part is a cheap way to get that.

But that's not what people on this thread are asking for; they want it to do all the crypto stuff they do normally, with all the keys secured in hardware.

I'm a little out of my depth on this stuff; I've done chipset work but my part of those projects always starts with the C code. Maybe you can accomplish what you want with a cheap crypto IC. I'm really just pushing back on the idea that because you can build a smartphone out of a cheap ARM core, you can also build an HSM out of one.

> If what you need is the management of 16 different NIST P-curve keys and nothing else

You can put AES keys in the slots and have the IC perform operations with them.

> and you don't necessarily care if the whole package is secure against DPA, that part is a cheap way to get that.

Go get the NDA datasheet.

> (HSM out of ARM core alone)

We agree here.

That's AES (right, of course; I assume arbitrary small blob of data, but these are the operations the IC can do itself without you having to drag the key out into the SRAM of your MCU) for GCM, and P-curve ECC. It's not SSH, right, or Signal protocol. It's just designed to drive TLS, and can do U2F.

Does the data sheet talk about hardware side channel mitigation?

Check out the Datasheet of the ATECC508A, it has been available without an NDA since Jan 2018.

http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pd...

Would it not be possible to use hardware that can make similar security promises using the cost saved by not having the LCD and Battery?

USBArmory is around ~$100,I'm essentially talking about a mass produced user friendly version that cuts 40-60% of the cost due to mass production and slightly less extravagant hardware.

Are there technical reasons that device (well, maybe not quite that blue-sky-ish, but the general idea) can't be your phone? You've already paid for it, people seem to think they're quite secure, etc. I don't get the whole desire to make hw tokens more computery so we can better use our computers while also already carrying another computer in our pockets.

This is a can of worms. Experts will tell you that iPhones are quite secure, and there is a lot of hardware security going into making them secure. It doesn't follow that any piece of hardware you build with L4 and a cheap ARM core will protect keys, such that losing sight of your token for a couple minutes won't mean you have to ditch the keys it stored.

Right, I mean a secure phone, so a recent iPhone with the enclave and the exurb and the whatnot. The U2F key I get - it's cheap, it's indestructible, I can buy a bunch and put them on my keychain and hide them under the couch and forget them in drawers filled with old SCSI terminators. But the phone already can do things like, say, authorize access to my google account by gmail app push notifications. Why not my ssh keys or all the other zany things people want to do with fancier USB tokens?

I think (I don't have the numbers and I might be wrong) that the price difference between a Yubico U2F key and the Yubico Y4 key that will also hold your SSH key is in large part down to the BOM cost of the NXP chip they're using as the on-board HSM.

Krypton does this:

https://krypt.co https://krypt.co/developers

It acts as a U2F token, but can also hold a private key for SSH authentication and/or git commit signing. On iOS, it can use the secure enclave.

You would then have to replace all the not-secure phones your users have, iOS market share is ~15%. It could work for company-internal things w/ work phones though. Phones generally get lost, broken and out of battery a lot though.

Why not just house the yubikey guts inside the phone enclosure then?

Separation of duties. You want the hsm to be unchanged in many years with minimal maintainance. While your phone is already being used for too many things which means it will need an upgrade frequently and you will have a harder time securing it.

Think of the hsm as just another key on your keychain. It has no ui other than a button,does not need charging and will remain in your pocket until needed. You don't want someone grabbing it off your hand while texting or making a call,that would mean they can access all your accounts.

The Yubikey Neo has a whopping 2 ICs on the board. The secure element is around $6 and the microcontroller is almost certainly cheaper than that.

http://www.hexview.com/~scl/neo/

https://www.avnet.com/shop/apac/products/nxp/a7005cghn1-t1ag...

I hoped WebAuthn would allow such general-purpose use of security devices. Unfortunately, in the spec: "To save bandwidth and processing requirements on the authenticator, the client hashes the client data and sends only the result to the authenticator. The authenticator signs over the combination of the hash of the serialized client data, and its own authenticator data." [1]

So, in the foreseeable future on the web, the devices are useful just for authentication.

[1] https://w3c.github.io/webauthn/

You understand that in addition to simplifying the protocol, confining it to authentication helps, somewhat, keep Webauthn from becoming essentially a hardware cookie.

I think that’s mitigated by the physical button one has to press every time something is signed.

I’m not sure if the restriction to authentication has substantially simplified the WebAuthn API. The restriction is caused by a speed optimization, not design simplification. If the actual payload was sent to the authenticator, rather than just its hash due to bandwidth limitations, then it seems like the API could be used for signing messages, not just authentication. I do agree that the user interfaces surrounding the APIs will be simpler due to the focus on authentication.

> If I am using a hardware security device,why do I need any other form of authentication?

Hardware breaks.

Hardware is easily stolen.

Hardware-to-hardware interfaces require compatibility. You will probably respond, "but USB". To which I will say, "but BLE. but NFC. but data-over-audio ala square".

No security is perfect. When a hardware flaw is discovered, or comms technology changes, you have to buy new hardware.

If it does break or is stolen, how will you recover your account? This is not trivial.

How vulnerable are these to differential power analysis? From my understanding, many FIDO keys are designed with resistance to these sort of side-channels in mind.

What is the threat model that these keys are typically designed for?

Typically these keys are designed to be secure against remote attacks (i.e. adverse software on PC can't extract any secrets). If the attacker physically steals the key, he can just use it directly, no need for DPA. So protecting from physical access typically isn't in threat model.

The problem isn't someone stealing the physical key - yes, if someone does that, they can use it. But, if its your key, and you no longer have it, you'll notice that and can take action. A bigger problem is if someone briefly takes the physical key, clones the digital key, and then returns it to you. Then, you have no idea that its been compromised.

If your use case is that you want them to be secure from a wealthy nation-state - well, thats probably a tall order. What you are probably most interested in is that the cleaning person in your hotel can't clone your key. The thing with digital security, though, is that it real hard / impossible to really define intermediate security levels - what is possible for a nation state to do, may be only a research paper or code leak away from everyone else being able to do.

So, I'd really hope that any serious security key would be designed to defend against physical attacks.

To echo on Conor's comment, our keys will protect you from online attacks. The one you describe is certainly a threat, but still pretty sophisticate and requires physical contact with the key.

To protect from physical attacks you need stronger devices, for example Yubico now has an entire new line of FIPS certified products. Note that the cost is higher than the FIDO2 usb-a only key.

As Conor mentioned in other places, to obtain stronger hardware we'd need to sign NDAs with vendors, and thus we couldn't make our key open source. Personally, I really hope that this first iteration will be a success, so we'll be able to push the industry for even more open hardware, and eventually we'll be able to address threats like the one you reported.

> to obtain stronger hardware we'd need to sign NDAs with vendors, and thus we couldn't make our key open source.

That's not true. First, you won't even be eligible to sign an NDA with a secure chip vendor. Second, this won't limit you from having your application (running on their chip) subject to the NDA.

Ledger Nano S protects you against physical theft by having a 4 number pin code. If the pin code is entered wrong 3 times, the device resets itself.

That's good for a wallet, because misuse would signify loosing money. As these keys are primarily designed for 2fa, the attacker would also need your password to break into your account.

Things may change when 1fa will be more widely adopted, but for the time being we're going to keep it as simple as the "competition" is, i.e. just a button that you press to log in.

Typically only one component of a device will be security hardened (e.g. a security element such as STSAFE-A100) and it will be designed to protect against side-channel attacks. You won't be able to find any information about the measures and resiliency online though - you'd need to chat with vendors for that kind of info (even then, unlikely).

PCB assemblies are pretty impossible to secure in themselves so you have to confine security functions to a small portion of the system and work hard to make sure nothing leaks from there.

This is neat, but my biggest problem isn't the key.

My biggest problem is how many things I have to configure to even be able to start to use the key.

There is a reason why Duo got bought for >2Gigabucks. 2FA is a PITA to administer.

By using the key, I assume you mean how painful it is to implement it server-side?

I'd really like to use FIDO for entire organization. For windows logins, .NET apps etc. But there is no easy solution.

On the other hand TOTP is simple to add for .NET apps.

Technically, nothing needs to be additionally configured for FIDO U2F to be implemented for an application. You just need to connect the key to your account and it should just prompt you to click the button when you need to sign in. If a company requires a phone number or some other byzantine process for registering a key that is their own design choice.

I get that simple U2F key registration is not what's seen in a lot of time in the real world, but most implementations are needlessly complex IMO.

"You just need to connect the key to your account" is the onerous part, though. Google doesn't require a phone number or whatever, but you have to click through like four pages to get to it.

Google Account -> Sign-in & Security -> 2-Step Verification

Or just click: https://myaccount.google.com/signinoptions/two-step-verifica...

Yes. Then click U2F. Then start messing around with that.

It takes time. And I have a ton of accounts. I like my U2F key but it is still a pain in the ass.

Seems pretty easy to me, in my opinion.

All barriers are insurmountable UX burdens to a significant portion of users, no matter how trivial the barrier.

Do it for 20 apps. On two keys. When every app has a different place they hide the feature, when every app has a different workflow to get it done, and most of them don't tell you they support it in the first place. It really sucks. At minimum, WebAuthN should enable detecting when the key has been slotted and ask if you want to enable U2F, then take you through it...but nobody does, and nobody probably will anytime soon.

At work, Okta at least will handle it for us, but personally? It really sucks.

Yea, that is cumbersome and not at all user-friendly. I was operating under the assumption of a single app + device use-case at solely Google in my original comment.

Sure - and like I said, Okta does a good job of that for us. But to get people to really embrace it, I tend to think it's gotta work for them personally too. Otherwise it's just this "thing" on a keychain, you know? It's not important.

Ideally, there would be an event emitted by the browser that could detect that a U2F key was inserted, but do to the design limitations of the key this is unlikely to happen. The U2F key is essentially a keyboard that has been plugged into your USB port. Some people keep "nano"[0] ones plugged in at all times for convenience. To address the common use cases of real users, you would need the browser to be able to check if an external keyboard is plugged in to a USB port on DOM ready, and when inserted into the computer.

I will let your imagination run wild with what a nefarious person could do if every browser has the ability to detect if you are using a specific type of USB keyboard. I could point you in direction of device fingerprinting to start, but that's the bare minimum of what you expose.

[0]: https://www.yubico.com/product/yubikey-4-series/#yubikey-4-n...

I appreciate the explanation, but I do understand at least at a high level how this works. I understand why it's not being done this way. How it's being done is kind of messed up.

WebAuthN is able to tell you that the web page wants you to put a hardware key in. That should be enough to be able to prompt users who've opted into using such a key elsewhere that they can do so here.

> You just need to connect the key to your account

Which account? Where is the account? Who runs that account?

In a 10-person office, I want to be able to hand 3 keys to each person (1 for use, 1 for loss, and 1 just in case the other two somehow foul up), and then have them use those keys for computer login, email login, AWS login, GCP login, NXP/ST/SiLabs support forum login, etc.

And when one of them goes to another company (it happens), I need to be able to shut those keys down without their cooperation.

Until I can do this, 2FA is going to remain the province of big companies and not be very useful.

So basically you need SSO with an identity provider that supports key-only logins. Perhaps SimpleSamlPHP with privacyIdea would fit the bill.

I don't understand why all these things have to be so huge and clumsy. The Tomu (tomu.im) fits almost entirely inside a USB slot, and has 64k of flash and a 32-bit ARM.

If it does have to be big enough to be on a lanyard or something, I need it to be flexible, like a short cable dongle. A long skinny USB stick is an accident waiting to happen.

The Yubikey Nano is about that size. I find it too small, though, and the NEO is perfect for me. It's the same size as my keys and I've put it through the washing machine with no problems.

I think the point of a key like the nano is to permanently put it on your device, not carry it around.

If you're essentially attaching it permanently, why bother with an external key at all? Isn't the main point of these devices that they remain with your person?

Yes, in part - another part is that it can't be remotely compromised or duplicated. Someone has to have physical control of the key. If you have a secured area your device is in, such as an office or a locked apartment, it's way better than password or SMS 2fa.

It's still stronger crypto vs passwords and tokens. It has certainly different use cases, and you need to protect your laptop in other ways, for example with a strong enough password to unlock the screen. It's certainly not a product for the masses, imo.

it's a non fish-able token, a password can be fished a security key can't. For most people I'd think the biggest risk are non physical attacks.

I showed the prototype yesterday night to my aunt and uncle. They had issues keeping it in their hands, let alone pressing the button.

The tomu/yubikey nano are great products for a certain population, and certain use cases. I have a nano, for example, that I use for vpn and for conveniency. I don't use it, for example, for authentication to my personal accounts, because it's always connected to my laptop, and often time I'm not in physical possession.

> But since U2F/FIDO2 devices need to derive secret keys at runtime to be able to work with an unlimited number of services, the ATECC508A doesn’t work out well. This is because to derive a key at runtime, you typically need to compute an HMAC that’s keyed with a master secret, and store the result as the runtime key. This needs multiple interactions with the ATECC508A and requires the runtime key be stored temporarily on the MCU, which tarnishes the idea of key isolation.

This is incorrect.

The atec family can derive keys using a static master seed and variable nonce. Such keys are derived internally and kept internally, never leaving the chip.

By storing a single derivation master secret, you can use the hashed u2f appid as the nonce. I would additionally have a 2nd hmac secret to apply to the nonce, and use that as the key derivation nonce rather than the appid directly.

If this device is reprogrammable so I can experiment with the 2-device solution proposed a week ago then I’ll order quite a few of these when the Kickstarter goes live.

https://news.ycombinator.com/item?id=17765979

Yup it will be. I've actually been in touch with Dmitry, he came up with a nice backup solution. We were thinking about coming up with some sort of protocol so devices may initially be designated as this sort of backup.

I was wondering if inspiration could be taken from the BIP32/BIP39 in the Bitcoin world. You can use a Trezor as a GPG-Agent, for example, with a key that's derived from the master key (BIP32) in the TREZOR (aka, already backed up via the BIP39 seed phrase). I haven't looked at u2f-on-trezor yet, but I'd assume it is implemented similarly.

It seems like you could use existing tooling to generate the phrase and then use some existing code/processes to derive the key backing the token's u2f private key?

Independently from the protocol you choose, the final result is that two (or more) devices will share the same private key for, e.g., your google account.

The problem that we need to solve securely, is that you as a user must be sure you know all devices with that private key, i.e. no one else can trigger a backup without you knowing that, even with a temporary access to the key.

I (think I) was just discussing a way to make the master key easy to backup.

Isn't what you're discussing (prevent unknown backups) more a function of how the private key is held in the Solo itself (and in my example, how securely your seed phrase is stored)? Or is there an element of U2F that I'm missing here? (Does the token itself have an identity that you want to be unique while still preserving the same key for authentication, or is there some other detail I'm missing?)

Let me try to rephrase. If you have a (too easy) way to backup, i.e. extract, the master key, then an attacker can use the same mechanism to backup your master key without you even knowing that the backup happened.

You can, for example, set up a pin or passphrase, however the fido2 protocol doesn't (necessarily) work like that. You buy a key, and you just start using it. There are multiple options to implement a backup protocol, but no standard one to the best of my knowledge. My original point was just that in designing such a protocol, it's important to consider this "unknown backup attack".

Interesting.

I'm not perfectly fluent in the U2F/WA protocol but shouldn't it be possible to have two devices but one is programmed to only accept registration and not allow normal operation?

That way you could put the fully functional one into a bank deposit and use the other to register that key...

Is there any reason why these devices can't have a USB-C connector on one side, and a USB-A connector on the other? Being able to keep just one single token around and knowing I can always use it without an adaptor is the holy grail of these devices for me.

Cost. That's really the only reason.

This would be a really good stop gap until the industry has transitioned everyone over to usb-c.

Just wondering, is there any reason why the Yubico FIDO2 Python API[0] talks to a USB device by using custom code to handle the USB protocol instead of using a module like PyUSB[1]?

[0] https://github.com/Yubico/python-fido2

[1] https://pyusb.github.io/pyusb/

What's the advantage here over the Yubikey equivalent?

Open/hackable firmware? Price?

Just the existence of the project is important as it validates the openness of the FIDO/U2F standard and ecosystem.

Please let me start by saying that Yubico is NOT the closed/evil. Without Yubico, we wouldn't have security keys, and we probably wouldn't have these standards. They're working since 10+ years on this problem, and they released a great amount of open source.

Some short term advantages of Solo: open firmware that can be verified by the community. Somehow a reference implementation maybe. Prices will be slightly lower, yes, but not a massive advantage imo. I also hope we can build an open documentation system, to make it easier for people to start using fido2 devices.

Long term dreams.

1) Open hardware will allow for experimentation. I'm personally hacking security keys into jewels, and I hope that people will take Solo design, alter it, and embed security keys into other objects and shapes. Keys are getting obsolete.

2) Pushing the industry. Again Yubico is not the "closed one" here. Security coprocessors/chips are. Hopefully, by having more and more open hardware, there'll be a market for even more open chips.

What I miss in the U2F tokens is a small display that would show transaction details which is approved.

Imagine you have a malware on your PC; it can send another transaction than the one you see in the browser, while the URL would still match. Having transaction summary on the token would be the last verification point where can still spot something is wrong.

The screen has to be run by the crypto chip if you want it to be properly 'secure' and most can't do that. At least not the ones who you can buy of the shelf unfortunately.

If you have malware on the PC you can still be MITM'd when you actually, say, access your bank.

Not if the encrypted data is displayed by the crypto chip, via a round trip between the bank and the chip (encrypted). Yes, technically it can be done, but this requires physical access to the device.

Ledger and Trezor have a display, though I don't know whether their U2F UX is any good.

I have a Ledger Nano S that I use for cryptocurrency and it does basically this. It won't sign transactions unless you approve them from the device, and the little screen on the device shows the address(es) to which you're sending.

https://www.ledger.com/products/ledger-nano-s

It's $100, which is probably too much for your average user, but cheap enough that it's got to be feasible for a U2F kind of thing in a few years.

I guess even the addition of the screen, though, kind of necessitates using a cord so you can see that screen, which makes it less clean than my Yubikey Nano (which is far less obtrusive). But I think we're getting closer.

Thanks. Yes, this is something what I think of. Does it show on the screen what operation you confirm with U2F? Or just "U2F authentication"? But cord makes it far less convenient unfortunately.

I'm not sure if it supports U2F. If it does, I haven't used it. It just seems to prove that what you were conceptually describing can exist, and at a not-completely-unreasonable price point.

I use it for gpg, ssh(gpg-agent) and u2f. These are official applications that you can install on the device that does the above. It doesn't show the operation, just the website trying to access.

Ssh and gpg sadly doesn't display what requests it, might be a protocol limitation. Same deal for FIDO

My wishlist for this includes some RSA GPG usage but it'll probably remain on my wishlist. The Yubikey tokens are still rather expensive at 50$ and soldering my own and maybe selling extra copies (thanks MOQ) to friends.

Otherwise, this looks great, I'll definitely sign up for the newsletter later on...

We're considering this and similar features (gpg/ssh keys). One minor issue is the memory requirement, as our current chip only has 128KB of flash available. The bigger issue is certainly our time :), we're really pushing to have Solo keys available before Xmas, and thus we're prioritizing hardware and fido2. We also want to get fido2 certification, which of course means a lot more work that just making it work.

Of course, yeah, getting a product out can be more important. Good luck :)

If it's got USB-C, does it need NFC given most phones have USB-C? Or is the phone USB port incompatible?

Nfc is more convenient than having to plug it in. I like my yubikey for that reason.

NFC is just more convenient. Also, the support for fido over usb vs nfc vs ble depends on the apps/software implementation. To my knowledge Google supports all of them, but many apps may just choose to implement NFC as it's "easier"/more common.

why didn't you use a cap touch sensor? pretty easy to do.

the problem with the mechanical button is that it will torque the usb port. this is more of a problem with your design, where the usb contacts are just contact area on the pcb, as opposed to a fully enclosed usb-a "connector".

admittedly, a small problem, but since cap touch would have been easy, it seems a problem that would have been worth tackling maybe?

Do these use any sort of security element to store the keys? Or just stored in firmware?

Firmware. In the blog post there's a section on this, and why.

Reply on news.ycombinator.com