Basic Technology
Passkeys have their basis in a good idea. It is a good idea at the heart of much of modern encryption – asymmetric encryption or, as it is often called, PKI (Public Key Infrastructure). In this type of encryption there is a pair of keys. One key is public and everyone can know it. The other key is private and known only to the receiver/owner of the key. Only the owner of the private key can decrypt a message encrypted with the public key. Only the owner of the private key can sign a message that can be verified with the public key as signed by them.
This what is at the heart of passkeys. It is also at the heart of how cryptocurrency wallets work and of technology in use for over thirty years such as PGP. This same technology is what secures HTTPS and many other protocols the modern world depends upon.
The this is used generally used for authentication of whom you are interacting with is that the person or organization that wants to authenticate the other party has the public key. They encrypt a short message with it and send it to the claiming to be the party the key is for. That entity decrypts it performs some operation and sends it back signed. Thus they have shown they have the private key and are the entity owning the key pair.
Passkeys work similarly except that your passkey includes not only public key information but a user identity. This is what allows a single key, the passkey, with no other information such as a user name.
It is here that we encounter the first worry from a privacy point of view – how that identity is formed. It could be as simple and anonymous as some site specific random user id somehow salted or otherwise blended in. But for some providers it requires biometrics such as a face scan or the identity inherent in some user device. The close this gets to user unique external (across all sites) identity the worse it is for privacy.
It doesn’t have to be that way. It could be as simple as the site you are registering add producing a unique id for the registrant relative to that side with the key pair generating device in user control blends into the public key which it hands back to the site. That would preserve anonymity and not introduce broader tracking of registrant across multiple sites.
Some of the literature on passkeys simply assumes that they do or should identify the precise person or entity and not merely be authentication as a register user of some site. In this guise and to the extend some passkey providers do this they become indistinguishable from a Digital ID. This has quite obvious privacy problems. All ability to operate without showing ones papers is gone if this type of passkey becomes the required norm.
I am of the opinion that such smearing of dependable safer authentication with strong Digital ID is no accident. Many of those pushing passkeys seem to have agendas far beyond safer site authentication of site authorized users. Indeed some implementers are pushing to require exact identity via biometrics as part of creation of passkeys making the passkey itself a Digital ID effectively or to use a passkey on a site with the obvious potential to leak personal identity. They attempt to sell it as making it impossible for a thieve or hacker to impersonate you. While it is true that it would you immediately lose all anonymity and all your usage and actions is tied together online. This is a level of in debt online surveillance we should fight hard against.
Now the FIDO white papers say that the biometrics are not part of the passkey itself and are only scanned on the user device side. However IF that device itself has that information and can send it anywhere, say to a Big Tech mothership, then we have a problem. We also have a problem user core identity is known on one site that uses a passkey known to be authenticated by device with id X that and device id X is used for authentication subsequently on sites that did not have this information. Data gathering suites that exist most everywhere can easily link all the sites and the person’s activities on them.
Something very good about passkeys is having a unique one per site you use passkeys on. If the passkey tattles as to you true name this advantage disappears This is very important for two reasons. The first is that using the same passkey and thus public key on multiple sites is effectively a common identifier among those sites by which your activity on them can be tracked. Using the same passkey would be like using the same password on multiple sites. If it is cracked or stolen on one site then all the sites it is used on are in jeopardy. This is even more true with passkeys as there is no additional factor for an attacker to know such as email address or username.
So we could look at a passkey implementations as needing to:
- generate multiple key pairs,
- when given a challenge string and perhaps id of challenger (site?) answer with signature using secret key appropriate to that site.
Thus far the base tech seems an excellent thing. You could do this kind of signing challenge/response with a crypto wallet that is handy or with something based on PGP. A app on your non-mobile computer could do it. So could a dedicated hardware device or the conjunction of the two. However what is commingled with passkeys and is being pushed alongside them is not a good thing at all.
Implementation Issues
Other aspects that are not so good are two aspects of the current passkey system – making it depend on your phone and the involvement of Big Tech.
Phone Issues
The Big Tech passkey proposal requires use of a smartphone to hold the secret keys. To log into a site by passkey your smartphone needs to be nearby as you need to scan a QR code and your phone will connect by Bluetooth to your computer to complete the challenge signing for verification.
The reason this is a problem for privacy is that your smartphone for most people is tied both directly to their true government id and to either and Apple ID or a Google ID or both. So this means in principle that your government identity is tied to or easy to find potentially for every website your login to with a passkey. Which roughly having to show your papers to access those sites. So at the very least there must provably be no logging or transmission of phone and or Big Tech ids in the interchange to log into a site with a passkey. Otherwise you are tracked and all the way back to your “true name” more deeply than you are today.
Remember that a vast horde of data is harvested from each of us. It is exists in database as a graph of information about identifiable entities on the internet. Some of it we can limit but other parts not so much. So our only defense is to have few of the identities these nodes use so easily connectable to our true identity. If they are easy to connect then ALL that information points straight to you and I. If passkey exposes a very strong identifier like our personal phone then connecting all the sub-graphs of information becomes trivial.
Basing the platform on a phones has the advantage of being something a lot of people already have and absent theft of phone are likely to be in possession of. To be safe of the above concern though neither the site being logged in or registered on or the any logs and analytics sent off the phone can be allowed to tied phone id, Big Tech account ids and so on with the passkey transactions. This is a Big Ask and not easy to ensure – especially not across proprietary apps.
Today web apps in a desktop browser can use cross device tracking to tie proximity of known user phone to identifying who is logged into a web site. Location tracking of phones has advanced enough in precision to make this possible. So having one’s known personal phone close enough for Bluetooth between the desktop and the phone itself gives high probability of true name identity match.
On a iPhone or a stock Android (non de-googled) phone Apple or Google respectively have fully ability to see and potentially log anything they wish that happens on the phone. This is the first aspect of why the Big Tech involvement is problematic.
Big Tech Involvement
The second Big Tech aspect that is a problem is the current answer to where the key pairs are backed up which is that they are backed up to Apple or Google (or perhaps Microsoft) cloud. There have been plenty of articles on breaches and privacy and security problems with these clouds. Unless this data is provably E2EE (end to end encrypted) and Zero Access this Big Deck involvement is not acceptable. The Zero Access part means not even the provider themselves can see the secret keys. Post Snowden Prism revelations nothing less would be acceptable.
It is surprising and suspicious that a Big Tech cloud backup is even put forward as the solution to changing phones or having you device rendered inoperable or stolen respecting passkeys. Why not use a password manager who very core business and reputation is protecting credentials that is not tied to some Big Tech account? There are also very good password managers that are open source and can be run on your own hardware with no Cloud potential danger whatsoever. In this case you do you own secure backups.
Which brings us to a third reason having your backups for passkeys only on a Big Tech cloud is a problem. If your Big Tech account is hacked or in these increasingly censorious times your account gets canceled what then? If you are on an iPhone the iPhone does not work at all without an Apple Id. If shut out of that or someone else has taken it over you then you have no backups or ability to use your device and thus your passkeys in the first case and someone else has full access to all your passkey used sites in the second. All they have to do is set up a new iPhone using your Apple ID. There is a similar store for a stock Android phone.
Additionally there is thus far no proposal for how to export and import passkey data across Big Tech ecosystems. That is if an Apple user decides to migrate to Android (or vice versa) how are there passkeys transportable between these Big Tech empires?
On the FIDO passkey pages passkeys are rather explicitly tied to Big Tech platforms Apple, Google and Microsoft. There is an implicit assumption that passkey users will be using one of these. Many of us that care about privacy have left these systems to the degree we can. It is a major problem when a knew security standard associates itself this deeply to current major companies. That assumption makes it difficult to have full transparency to the internals of the technology technically and as implemented by proprietary platforms.
Possibly Better Implementation
Password Managers securely store credentials today and since they all provide some means of backup regardless of what device they are used on. Some can be self-hosted and a few even have no data in the cloud or on provider services. In the latter case the user is responsible for their own encrypted and secured backups.
This removes the Big Tech issues entirely. There is the issue for a server or cloud backed Password Manager of E2EE and Zero Access privacy and security. All Password Managers today have guarantees in this area. Even if a hacker gets their data they can not read it. Neither can the provider. And if there is no server out your control to start even this possible problem area is gone.
Another decent passkey solution would be a dedicated device for that purpose. Today many hardware crypto wallets can handle multiple key pairs and keep the secret keys secure under one master secret key. Some of them are also air gapped. Something very much like this could be made to work. It has a master secret key that can be used on another freshly acquired instance of the hardware wallet to retrieve all the keys in the advent of theft, loss or broken device.
Conclusion
Passkeys are a very good idea. But care must be taken in implementation to ensure:
- the implementation does not provide a vector for tracking of the one using them
- the implementation does not bind one to a Big Tech entity
- the implementation does not require Big Tech involvement
- secure backup of secret keys is available
- portability of keys across different implementations is supported