Stallman saw this coming decades ago. And I firmly believe he will be proven right in due time.
Don't run Intel and AMD CPUs then!
a) the source code of the secure enclave is 100% open source b) I can compile my own version of it c) I can run my own version of it d) I face no reprecussions (i.e. services not working, DRM not working, ...) if I choose to do so.
This is all fine and dandy for key storage purposes; you actually want all of these to guarantee that your keys are safe. But modern enclaves are primarily used for DRM, and this just doesn't work if I can just patch a way into my enclave to get the key if I really want to.
So, I'd much rather have a system with no enclave which I can attach a HSM to than a secure "trust me bro" enclave.
DRM was the original sin of computing, and nobody can convince me otherwise.
A plain USB stick is not a secure place for a keystore as a compromised kernel could trivially copy it and send it somewhere else for cracking.
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.
It does. It can request that the key do attestation, which involves providing a certificate that proves who the manufacturer is.
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.
It must not be a hardware manufacturer.
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.
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.
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.
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.
The crucial problem is that the IT industry is more concerned about using it to enforce DRM instead of educating users so they can use it to retain ownership of their services.
The TPM itself does very little. It is simply used by the UEFI to verify that the digital signature of the OS image is valid, similarly to how a browser validates a server certificate using its own truststore.
A possible attack vector to compromise that functionality would be to tamper with UEFI. Since it is firmware, the operating system simply doesn't have the capability to so. Even when doing firmware updates, the OS must ask the UEFI nicely to apply a new firmware image, which is similarly verified using a digital signature.
All the above assume that there are no backdoors that allow an upper layer to compromise a lower layer.
Private key material is required for remote attestation, which makes it possible to prove certain things to an external party, for example the exact identity of the TPM. This feature is much more questionable.
That's a useful property, but you have to weigh it against a kernel that can be audited and patched.
The utility of patching your own kernel has to be carefully weighted against the security impact of doing so. If an attacker can take over the user account that compiles the kernel, they can make you install a compromised kernel. For example, by running a file system monitor that exchanges the kernel image with a compromised one as soon as it has been built.