
Designing Solo, a new U2F/FIDO2 Token - ecesena
https://conorpp.com/designing-solo-a-new-u2ffido2-token
======
badrabbit
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!

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

~~~
pvg
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.

~~~
tptacek
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.

~~~
pvg
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?

~~~
danieldk
Krypton does this:

[https://krypt.co](https://krypt.co)
[https://krypt.co/developers](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.

------
xvector
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.

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

~~~
conorpp
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.

~~~
dagenix
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.

~~~
ecesena
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.

~~~
jiveturkey
> 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.

------
bsder
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.

~~~
pg_bot
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.

~~~
bsder
> 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.

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

------
ncmncm
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.

~~~
eropple
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.

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

~~~
organsnyder
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?

~~~
tonfa
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.

------
thinkmassive
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](https://news.ycombinator.com/item?id=17765979)

~~~
conorpp
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.

~~~
colemickens
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?

~~~
ecesena
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.

~~~
colemickens
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?)

~~~
ecesena
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".

------
newhere420
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.

~~~
JustSomeNobody
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.

------
jiveturkey
> 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.

------
ssebastianj
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](https://github.com/Yubico/python-
fido2)

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

------
ac29
What's the advantage here over the Yubikey equivalent?

Open/hackable firmware? Price?

~~~
ecesena
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.

------
prohor
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.

~~~
moduspwnens14
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](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.

~~~
prohor
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.

~~~
xfer
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.

------
zaarn
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...

~~~
ecesena
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.

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

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

~~~
ecesena
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.

------
jiveturkey
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?

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

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

