3 ms·

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

• Nextgrid 6mo ago
  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.
  • jamiesonbecker 6mo ago
    Rotating keys is easy with the right software. (I work @ Userify) Agree with the auditing point Token-based keys, to tptacek's point, is that they can be a giant pain once you start scripting across fleets.
• lxgr 6mo ago
  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?
• knorker 6mo ago
  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.
  • spwa4 6mo ago
    I guess you could implement that on android.
    • lxgr 6mo ago
      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-protected-confirmation.html 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).
      • tadfisher 6mo ago
        Protected Confirmation was deprecated a while back, unfortunately: https://android.googlesource.com/platform//system/security/+/07fec0ff0cf35beb223bedb06e0e41d49596bfb6%5E%21/ https://android.googlesource.com/platform//system/security/+... 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."
        • lxgr 6mo ago
          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.
• Borealid 6mo ago
  TPMs support setting a PIN without which a key cannot be used. The PIN can be an arbitrary string (password).
  • tegmentum 6mo ago
    I wish they wouldn't do that with the naming. It's confusing as hell to call it a PIN (Personal Identification Number) if it's actually a password.
    • ButlerianJihad 6mo ago
      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] https://en.wikipedia.org/wiki/Windows_10#System_security https://en.wikipedia.org/wiki/Windows_10#System_security 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?
      • XorNot 6mo ago
        Secret Code Word. Communicates it is meant to be secret, and can be a short memorable thing.
  • palata 6mo ago
    Though if your computer is compromised, then the malware can read the password, right?