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.
The idea with HSM-backed keys is that even in case of compromise, you can clean up without having to rotate the keys. It also makes auditing easier as you can ensure that if your machine was powered down or offline then you are guaranteed the keys weren't used during that timeframe.
Without presence test (e.g. yubikeys touch) it's certainly not perfect. But it does close some real world attacks. Like the key can only be used while your laptop is on. (assuming laptop, here).
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.
Android actually supports secure transaction confirmation on Pixel devices using a secure second OS that can temporarily take control of the screen and volume button as secure input and output! https://android-developers.googleblog.com/2018/10/android-pr...
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."
Oh damn, I missed that, thank you. I could see how it was a very expensive thing to maintain for an effectively Pixel-only feature.
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.
Yes. But that'd just be a TPM on a computer, in hand held 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.
Ah, I guess by "that" you meant the touch part, not the uncopiable part.
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.
That's still an improvement. In sophisticated attacks, attackers might well store stolen credentials and use them at a later, more opportune time.
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?
Well... it would also be confusing to call them "passwords" because they are not that.
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?
If your computer is compromised while you enter the PIN in such a way that the malware can read your input, yes.
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.