Seems a little pointless, your keys can't be stolen but they can be instantly used by malware to persist across anything you have access to. The keys don't have any value in their own right, the access they provide does.
Token-based keys, to tptacek's point, is that they can be a giant pain once you start scripting across fleets.
And keys cannot be stolen from backups.
Or stolen without your knowledge when you left your laptop unguarded for 5min.
Not every attacker has persistent undetected access. If the key can be copied then there's no opportunity for the original machine's tripwires to be triggered by its use. Every second malware runs is a risk of it being detected. Not so, or not in the same way, with a copied key.
This is really cool and goes beyond the usual steps of securing the key, but handling "what you see is what you sign" and key usage user confirmation at the OS level, which can be compromised much more easily (both input and output).
Quote: "Android Protected Confirmation is deprecated due to the high support/maintenance cost for Android device makers and low adoption rate among app developers. APC requires Android device makers to have a substantial amount of device-specific UI code running in the trusted execution environment. That has proven to be expensive to maintain and non-scalable, as there cannot be a single implementations device makers can share or use as a reference. Additionally, app developers have not adopted this feature, as the Android platform offers other mechanisms for authentication a user's intent. These mechanisms, such as authentication-bound Keystore keys, are less secure than Trusted UI, but are more wide-spread. While we explore alternatives to APC that are viable to the device makers ecosystem, we sunset the APC API."
Still, I think this was one of the most ambitious and user-beneficial implementations of trusted computing I've seen so far, in that it theoretically safely allows a completely rooted/user-owned device to still participate in things like online banking or e-government transaction authorization. I hope it'll return in some form.
A laptop and a phone are both general purpose computers with "TPM chips", so "you could implement that on android" is as true as "you could implement that on a white computer".
There was something about Macs. It took them a while to get a TPM. But I think now they do, so macs can do it too.
There are many ways to implement this. I think some Chromebooks have FIDO gated on a physical button.
If you have an unlocked device with keys usable requiring a mere touch, I'm not sure fingerprint adds much value. A button would be enough.
Actually checking with fingerprint only addresses an extremely narrow attack where someone who wants to attack you steals your device (so already physical access, meaning not DPRK hackers) while it's unlocked, and only getting a window of opportunity until you've called your security department to lock your account. … and yet this attacker would NOT be willing to use force against your person, to make you use your fingerprint.
Sure, if that's a threat model that's worth your time, use fingerprint too.
Keep in mind that already going from software only (and arguably this includes OTP app on your phone) already means effectively going to zero. Google moved to security keys and says “We have had no reported or confirmed account takeovers since implementing security keys at Google” — https://krebsonsecurity.com/2018/07/google-security-keys-neu...
So there are extreme diminishing returns after just security key with touch.
An app solution even gets a callout in that article as being not as good.
Of course a real secure attention sequence would be preferable, such as e.g. requiring a Touch ID press on macOS for keys stored in the Secure Enclave. Not sure if TPM supports something similar when a fingerprint sensor is present?
The PIN can be an arbitrary string (password).
In addition to biometric authentication, Windows Hello supports authentication with a PIN. By default, Windows requires a PIN to consist of four digits, but can be configured to permit more complex PINs. However, a PIN is not a simpler password. While passwords are transmitted to domain controllers, PINs are not. They are tied to one device, and if compromised, only one device is affected. Backed by a Trusted Platform Module (TPM) chip, Windows uses PINs to create strong asymmetric key pairs. As such, the authentication token transmitted to the server is harder to crack. In addition, whereas weak passwords may be broken via rainbow tables, TPM causes the much-simpler Windows PINs to be resilient to brute-force attacks.[139]
So you see, Microsoft needs a way to describe an access code that isn't a password, because it's more secure than that, but yet it isn't exactly a number, so what do you call it? "PIN" is perhaps an unfair recycling of an in-use term, but should they coin a neologism instead? Would that be less confusing?
Communicates it is meant to be secret, and can be a short memorable thing.
If your computer is compromised after you've already entered the PIN, or there is an app running on the computer but it is not sufficiently privileged to sit in between you and the TPM, no.
That's quite good protection generally. The defense against this type of attack is to get a smartcard reader with an on-board PIN entry keypad - those do exist, but it's quite a step.