[loup-vaillant]

> Such devices are called FIDO keys. But they work only if the service you're accessing also supports it.

That’s not quite true. The (web) service I’m accessing doesn’t communicate with my FIDO keys — there’s my browser in the middle. The service has no way to know whether my browser is talking with a hardware token or emulating one, and it is not privy to the details of how my browser communicates with my token.

If my browser supports FIDO on the network end, and my hardware token on the other end, it works. Now I’m guessing right now only relatively mainstream stuff like Yubikeys are supported out of the box, but support for say, the TKey (https://tillitis.se/products/tkey/), is likely only a browser extension away.

[samus]

> The service has no way to know whether my browser is talking with a hardware token or emulating one, and it is not privy to the details of how my browser communicates with my token.

The service doesn't necessarily have to know that for the scheme to work. If the user is fine with the browser keeping the keys, then so be it. Browsers have been featuring password managers for a while now, and people happily use them because they have a convenient user experience.

However, if the user wants to use a hardware token, all the browser has to do is be the middle man between service and token. The actual protocol is MITM-proof. Unless you assume your browser is compromised and will screw with your data and your account as soon as you log in. But that's a problem different from user authentication :)

These features are actually nothing new - browsers have supported client certificates and hardware security modules for ages. The features are not in the spotlight and have a horrible user experience though.

[loup-vaillant]

The server can trust that once the user is registered, they’ll be able to detect any key change. After registration, MitM is as you say not possible. And I agree that if the private key came from the hardware token itself, switching back to a password manager without telling the server is impossible, because we’d have to change our private key.

First though, the user must register their key. My claim here is that without a PKI (the sister thread speaks of what I think of attestations) the server has now way to tell where that new key comes from. Could be a hardware token, could be derived from `/dev/urandom`.

This is where it gets interesting: we could generate the user’s key outside the hardware token and copy it somewhere safe¹. The hardware token would then encrypt that key, and we’d keep that encrypted blob somewhere convenient (we don’t care if the blob leaks). Before the token does its end of the protocol, it must first decrypt the blob and extract the key (for internal use only). If we lose the token, we can switch back to a password manager (or set up a new hardware token) by retrieving the original key from its safe location. Since we didn’t change the key, the server doesn’t have to know.

[1] The definition of "somewhere safe" is is left as an exercise for Bruce Schneier. Me, I’ll just wave my hands.

[samus]

You're completely right about everything you wrote. But this is only a problem if the browser is assumed to be malicious. In this case, remote attestation can prove that we are indeed talking with a TPM.

However, if the browser is assumed to be malicious, then authenticating the TPM is pointless. As soon as the user establishes a session via that browser, the user account would be compromised.

[loup-vaillant]

You're correct, a malicious browser can wreck havoc in the user's account. The advantage of a hardware token is that it can limit the damage: if log in and important operations require the hardware token, we can make sure that a compromised browser cannot exfiltrate the user's long term secrets, and cannot permanently hijack the account. Done well enough, the account would only temporarily be compromised (which I reckon is still bad), and the user can easily reclaim control by turning off their computer and log in with another.

As for why I care about compromised browsers, well… I hear malware is still a thing. I'm relatively safe, but I'm one bad vulnerability or bad decision away from letting a Trojan in. So I quite like the idea of protecting my most important long term secret with something that's immune to that. Maybe I'll even get there.

As for the service, most of the time their own stakes are pretty low. They ought to offer good security options, but I'm not sure it's their place to mandate stuff like 2FA.

[jrockway]

> The service has no way to know whether my browser is talking with a hardware token or emulating one

It does. It can request that the key do attestation, which involves providing a certificate that proves who the manufacturer is.

[loup-vaillant]

Such attestations are evil and I want nothing to do with them.

I mean, I’d be okay that if I’m working for some company, I have to use the company issued hardware token that can deliver a company issued attestation that the company servers can then check. In some sense, the company is the user here, and the fact that employees have no say in this matter is not a big deal.

For individual however, I believe it is important that the user be in control. If they don’t want (or can’t afford) to buy a hardware token emulation should be an option. And if they prefer the hardware token they should be able to buy it from any company.

Picture how anti-competitive it would be that to use AWS you must use a security token issued by Yubico (or a list of approved companies): how does a small non-approved company like Tillitis enters the market? They have to ask every relevant cloud provider to add them to their list? This is both impractical and unfair.

An alternative that wouldn’t be anti-competitive is for AWS to mandate an Amazon provide key to use their services. And that key must not be usable for anything else. Note the e-waste and impracticality if every cloud provider did this however. It’s much better to let users use one hardware token for all services.

The worst thing is, I’m pretty sure companies will try and mandate such attestations, they will say it is to "protect the user", while in fact it will be yet another tool in their lock-in toolbox. As I said, it’s evil and I want nothing to do with it.

[ori_b]

I think the requirement here is that the owner of the user account needs to be able to register their own attestation keys. The owner of the account may be an employer or an end user.

It must not be a hardware manufacturer.

[loup-vaillant]

Yes, that I can support.

[ori_b]

Note, this makes the system more secure, because the manufacturer is no longer a single point of failure, and a compromised key can be rotated by the account owner.

[thinkerswell]

As long as the system is fully auditable and open source, I’d be happy. Having the keys be external is a big plus, assuming that is fully auditable as well. Having no “management engine” is a big plus too.