This is someone related to a major TPM pet peeve of mine: the TPM only really cares about global device state and has no concept that a device may be a multi-user system, have multiple processes with different security levels, have multiple tenants, etc.
For example, it really ought to be possible to seal a secret such that it can only be unsealed if PCRs have certain values (the usual TPM thing) and the requester of the unseal operation is tagged by the OS (software TCB) as having a certain identity. The latter part is entirely missing from the TPM spec. (The identity could be a hash of the process, just a UUID, or just about anything else as long as it was reasonably well associated with the process in question. Obviously there are subtleties here.)
If the TPM worked the way I wanted, an unprivileged process running alongside Chrome would be completely unable to use the TPM to pretend to be Chrome.
Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)?
The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.
>4. Using the hash of that handshake, the attacker interacts with the victim’s TPM and uses the extracted identity key to sign the handshake hash together with the assertion request
Huh? If you have this level of local privileges you can just read session cookies from the browsers store? I guess stealing all the keys is notable, but you can manipulate any password manager with this level of access right?
What's the threat model here, that synced passkeys should be secure in even in situations involving compromised clients? How?
>that synced passkeys should be secure in even in situations involving compromised clients?
I think that is the idea actually. By using secure hardware features it is in theory possible to secure the passkeys even in the case of compromised clients. Like how the iphone uses a security coprocessor to store the decryption keys and face id info out of the reach of iOS.
But this isn't overly concerning since it's still at a minimum as secure as passwords in a local compromise situation.
It's not that simple. The stolen file has no clear text passwords and ideally, these passwords can only be decrypted on the right hardware with user confirmation. Of course, eternal and repeated confirmation requests are an anti pattern all their own, but the cloud attestation service not verifying the hardware sounds like a really glaring omission.
It kinda is. If they use Chrome and it's cloud backed password manager, odds are they use GMail. That plus full access to a trusted device (which you have in this scenario) allows you to change their Google account password. Boom, full persistence.
I can think of at least a dozen easier ways to do nefarious things with this level of access that are at least that simple. As an example, faking user attribution would be trivial.
How could Google patch this? If the client is compromised and the attacker can manipulate the local TPM or it's equivalent there's no defense.
At least for accounts you want to keep very secure, session cookies are probably very time-limited. Stealing a passkey ensures persistent access in the future.
But I largely agree, if they're able to do this on your system you're already hacked and they can do a ton of very bad things.
Boy I’m so tired of people trying to make clever attack names. They don’t help remember things, there are too many.
So all 3 “pass-ta-key” attacks are not attacks on passkeys, they’re attacks on the Google vault.
And if you get access to the vault, then you get everything. OK. And if you get access to a synced traditional password vault, then you get everything.
So… meh. These are bugs, they will be fixed. Good on them for disclosing them. But this does not prove that passkeys are terrible. This does not make them less secure than random passwords.
If it wasn’t for the fact that they just happen to be getting passkeys, seems like this wouldn’t be worth a headline or discussing at all. And if they have this level of access, then they also get all the standard password credentials in the vault too, right?
Also, can I add a backup key without having the private key with me? Ideally I would like to keep a master key in a vault, to recover compromised accounts and such, but requiring me to load the master key to create every account prevents truly secure storage.
The right questions. The ability to set up an alternate key in advance is functionally similar to being able to make a backup.
If I had my 'druthers:
1. You can register multiple keys, such as for different devices. Like 5-10, not two.
2. There are two categories of keys: "Regular" and "Backup/Recovery".
3. Attempting to use a Backup Recovery key prompts to user to confirm that they want to discard all regular keys and promote the backup key(s) to the new regular.
In this way, a compromised backup key can't be used secretively.
To my understanding both Apple Passwords and the Android equivalent allow you to
export passkeys to a different app (password manager), but I haven’t tried it yet.
If anyone has direct experience I appreciate to know how it was.
I had a click around Apple Passwords on macos and I could not find a way to move my passkeys to another app. I could only see a way to share them with other Apple Passwords users.
This is someone related to a major TPM pet peeve of mine: the TPM only really cares about global device state and has no concept that a device may be a multi-user system, have multiple processes with different security levels, have multiple tenants, etc.
For example, it really ought to be possible to seal a secret such that it can only be unsealed if PCRs have certain values (the usual TPM thing) and the requester of the unseal operation is tagged by the OS (software TCB) as having a certain identity. The latter part is entirely missing from the TPM spec. (The identity could be a hash of the process, just a UUID, or just about anything else as long as it was reasonably well associated with the process in question. Obviously there are subtleties here.)
If the TPM worked the way I wanted, an unprivileged process running alongside Chrome would be completely unable to use the TPM to pretend to be Chrome.
Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)?
The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.
These are endpoint malware attacks, not attacks on Passkeys per se. This is already a game-over position for an attacker to be in.
>4. Using the hash of that handshake, the attacker interacts with the victim’s TPM and uses the extracted identity key to sign the handshake hash together with the assertion request
Huh? If you have this level of local privileges you can just read session cookies from the browsers store? I guess stealing all the keys is notable, but you can manipulate any password manager with this level of access right?
What's the threat model here, that synced passkeys should be secure in even in situations involving compromised clients? How?
>that synced passkeys should be secure in even in situations involving compromised clients?
I think that is the idea actually. By using secure hardware features it is in theory possible to secure the passkeys even in the case of compromised clients. Like how the iphone uses a security coprocessor to store the decryption keys and face id info out of the reach of iOS.
But this isn't overly concerning since it's still at a minimum as secure as passwords in a local compromise situation.
It's not that simple. The stolen file has no clear text passwords and ideally, these passwords can only be decrypted on the right hardware with user confirmation. Of course, eternal and repeated confirmation requests are an anti pattern all their own, but the cloud attestation service not verifying the hardware sounds like a really glaring omission.
It kinda is. If they use Chrome and it's cloud backed password manager, odds are they use GMail. That plus full access to a trusted device (which you have in this scenario) allows you to change their Google account password. Boom, full persistence.
I can think of at least a dozen easier ways to do nefarious things with this level of access that are at least that simple. As an example, faking user attribution would be trivial.
How could Google patch this? If the client is compromised and the attacker can manipulate the local TPM or it's equivalent there's no defense.
At least for accounts you want to keep very secure, session cookies are probably very time-limited. Stealing a passkey ensures persistent access in the future.
But I largely agree, if they're able to do this on your system you're already hacked and they can do a ton of very bad things.
Boy I’m so tired of people trying to make clever attack names. They don’t help remember things, there are too many.
So all 3 “pass-ta-key” attacks are not attacks on passkeys, they’re attacks on the Google vault.
And if you get access to the vault, then you get everything. OK. And if you get access to a synced traditional password vault, then you get everything.
So… meh. These are bugs, they will be fixed. Good on them for disclosing them. But this does not prove that passkeys are terrible. This does not make them less secure than random passwords.
If it wasn’t for the fact that they just happen to be getting passkeys, seems like this wouldn’t be worth a headline or discussing at all. And if they have this level of access, then they also get all the standard password credentials in the vault too, right?
Have we standardized a way to backup and export passkeys yet? Do websites commonly allow multiple passkeys to be registered?
Also, can I add a backup key without having the private key with me? Ideally I would like to keep a master key in a vault, to recover compromised accounts and such, but requiring me to load the master key to create every account prevents truly secure storage.
The right questions. The ability to set up an alternate key in advance is functionally similar to being able to make a backup.
If I had my 'druthers:
1. You can register multiple keys, such as for different devices. Like 5-10, not two.
2. There are two categories of keys: "Regular" and "Backup/Recovery".
3. Attempting to use a Backup Recovery key prompts to user to confirm that they want to discard all regular keys and promote the backup key(s) to the new regular.
In this way, a compromised backup key can't be used secretively.
There’s FIDO CXF/CXP: https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-2026030...
To my understanding both Apple Passwords and the Android equivalent allow you to export passkeys to a different app (password manager), but I haven’t tried it yet.
If anyone has direct experience I appreciate to know how it was.
I had a click around Apple Passwords on macos and I could not find a way to move my passkeys to another app. I could only see a way to share them with other Apple Passwords users.
I can confirm it works on iOS 27. I haven’t tried elsewhere though
It is hard to find the content for all of the glitzy ads on this site.
There's ads?
But when you do, there are glaring holes these people uncovered.
"You must enable DRM to play some audio or video on this page" pops up in the strangest places...
"Oh no, someone might pirate my advertisement and show it off to people for free!"