Security has always been a difficult balance between usability and safety. Passkeys are a way to “bridge” these seemingly opposed concepts. They allow enhanced security between a server and a client, while also removing the need for the end-user to manage login details. The connection is more secure than that provided by the classic “User ID/Login” model, yet there is no need for the user to worry about the details.
NOTE: If you already know what a Passkey is, you can skip this summary.
What Is A Passkey?
A passkey is actually an agreement between a server and a client, where the client sends the server a public key (part of the classic “Public Key Encryption” model), which the server stores, and uses to validate communication from the client. The client maintains the private key, which it uses to sign a login data record.
FIDO Alliance
PassKeys are the invention of the FIDO Alliance; an industry organization, dedicated to safe, efficient authentication.
The Valet Key Metaphor
Think of public-key encryption, the way that you would about the “Valet Key” that you get, when you buy a car. This is a special key that can’t open the trunk or the glove compartment, but will allow a parking attendant to drive the car.
The private key is the “full” key, and the public key is the “valet” key.
Read-Only
With public-key encryption, the holder of the public key can only decrypt; not encrypt. That’s something that can only be done by the holder of the private key.
This means that the server can only verify the client, while the client needs to trust the server; which is fine, as that’s the classic model, anyway. The idea is that the server holds valuable data, and is publicly accessible, so it’s important for it to be able to validate requests for that data.
How This Works in A Client/Server System
When the client first registers an account, they generate an “on-the-spot” pair of keys, keep the private key stored locally (and associated with the server), and send the public key to the server. The server then stores the public key (associated with the client), and will use that in the future, to validate the data sent from the client. Only the client will be able to send something to the server that can be decrypted with the server’s “valet key.” If it comes from the client, and can’t be decrypted, using the server-stored public key, then it is not a valid data exchange, and the server should refuse to honor the request.
So, to summarize:
- Upon creation of the passkey, the client generates a new linked key pair, keeps the private key, and sends the public key to the server.
- The server stores the public key, associating it with the new client account.
- On subsequent logins, the client sends the server a record that has been signed with its private key.
- The server then uses the stored public key to decrypt what the client sent it. If the data decrypts properly, then the server knows that this is a legitimate login from the correct client associated with the stored key. No other credentials are necessary.
There’s actually a bit more that happens, in the exchange (which we’ll cover, shortly), but that’s the most basic description of what goes on.
Look Ma, No Hands!
It should be noted that the “signed data,” sent from the client, can be “opaque” to the user of the client. They don’t need to access a login ID or password. They just need to validate the encryption, which, in the case of Apple devices, is usually biometric (Touch ID or Face ID). In the worst case, the user’s main device login may be the only password they need to remember.
Share the Joy
One advantage of having a private key that can be used to validate the same account on a server, is that the key can be shared amongst devices or client accounts, and they will all have the same access. In Apple’s case, a shared Passwords setup automatically makes stored PassKeys available on all signed-in devices.
Conclusion
- Passkeys use Public Key Encryption.
- Passkeys are the brainchild of the FIDO Alliance.
- A passkey requires support from BOTH the client AND the server, but the server doesn’t need any special privileges.
- At the time the passkey is created, the client generates an “on the fly” PKE pair (Public Key and Private Key).
- When the passkey is created, the client sends the Public Key to the server, and keeps the Private Key local; associating it with the server.
- The server stores the public key, and associates it with the client data on the server.
- When the client subsequently wants to log in, they authorize the Private Key locally (usually biometrics, or something like a YubiKey).
- The client then sends a data package to the server, that they encrypted (signed) with their Private Key.
- The server decrypts that data package with the public key that they have, and, if successful, allows the client access.
- The client then accesses the data/service from the server.
- PassKey client implementations can be shared amongst multiple contexts; each, as valid as the next.
Although we didn’t say so, the “server” doesn’t need to be something on the other end of a network connection. It can be a local service on the machine, or a connected peripheral device (but the device will be responsible for correctly handling the FIDO transaction). Also, the “data” can be an operation done by the server, on behalf of the client, that requires authorization.
Now that we have the basics down, let’s take a closer look at passkeys in operation.