Your passkeys.
Your phone.
Your call.

What passkey sovereignty means

Passkeys are a big step up from passwords. But in practice they tend to live inside somebody’s account: your phone maker’s, your browser’s, your password manager’s. You may use them, on their terms, on their devices. PassKeyChain starts from the other end: a passkey is yours, just like a passphrase you know by heart.

What it does

Everything you need to hold your own passkeys and use them where you want.

🔒 For passkeys you own. PassKeyChain holds and uses the passkeys of your own accounts, and signs only on the phone, never on a server.

How signing in with a QR code works

When a website asks your computer for a passkey that lives on your phone, the computer shows a QR code. You scan it, and a few seconds later you are signed in on the computer, without the private key ever leaving your phone. This is what happens in between.

1. Scan the QR, derive keys

   Computer → phone · QR code

   The QR holds a one-time public key of the browser and a random secret. The phone reads it with its camera, and from that secret both sides compute the same set of keys. The secret itself never travels over the internet.

2. Set up the tunnel

   Phone → tunnel server · internet

   Phone and computer are often not on the same network, so they meet at a relay on the internet: the tunnel server. The phone connects first and reserves a “meeting room”.

3. Tell the browser where to go

   Phone → computer · Bluetooth

   The phone sends a short Bluetooth broadcast, encrypted with the keys from the QR, saying which tunnel server and which meeting room to use. Only the computer that showed the QR can read it, and only when it is close by.

4. The browser starts the handshake

   Computer → tunnel → phone · internet

   The computer connects to the same meeting room and sends the first message of a cryptographic handshake, built from the keys of step 1.

5. The phone answers the handshake

   Phone → tunnel → computer · internet

   The phone answers. Both sides now share fresh session keys, and everything after this is encrypted end to end.

6. The browser asks for a signature

   Computer → phone · through the tunnel

   It sends the name of the website and a random challenge from that website. The phone looks up which of your passkeys belong to that website.

7. You approve

   On the phone · your fingerprint, face or PIN

   The phone shows which website and which account want to sign in, and asks you to unlock. Nothing is signed until you do. Cancel, and the browser simply gets a “no”. With more than one passkey for the site, you pick which one.

8. The phone sends the signature

   Phone → computer → website

   The phone signs the challenge with the passkey’s private key. The browser hands the signature to the website, which checks it with the public key it saved when you created the passkey. You are signed in.

This is the FIDO “hybrid” transport, the open protocol that Android phones and iPhones use for this. Because it is open, an independent app can speak it too: PassKeyChain does all eight steps itself, in about 1000 lines of Kotlin, and has signed in to a Microsoft account this way. Passkey sovereignty in practice: your key, your phone, the same front door as everyone else.

Your own Vaultwarden or Bitwarden server

Bring passkeys in from your vault, add new ones to it, or keep both in step.

PassKeyChain signs in to a Bitwarden-compatible server the way Bitwarden’s own apps do, with your server address, email and master password (and a code, if your account asks for one). It decrypts only the passkeys; your passwords and notes stay encrypted. Import fetches them; export first shows which passkeys the vault lacks and adds only those, as new items. Live sync keeps both in step, with a status light in the app: passkeys new in the vault come to the phone, passkeys created on the phone go to the vault, and nothing is deleted on either side.

💡 Tip: a separate account for passkeys. Live sync keeps your vault key on the phone (encrypted by Android’s keystore), and that key opens everything in the account. Use a separate Bitwarden account that holds only your passkeys, so it opens nothing else. A Bitwarden organisation doesn’t separate them: an account’s key opens all of its organisations too. But an organisation is how you share them: put both accounts in one, choose one of its collections for new passkeys in the app, and your main account sees them too, while passkeys it puts there come to the phone.

Run your own tunnel server

The phone decides which tunnel server is used, not the website and not the browser. So you can choose one you run yourself.

In step 2 the phone opens the tunnel, and in step 3 its Bluetooth broadcast tells the browser where that tunnel is. The browser simply follows, and the website never learns which server was used. Android phones use Google’s server; PassKeyChain does too, unless you choose another.

Browsers can reach more servers than Google’s: for numbers 256 to 65535 they compute a hostname themselves, such as cable.wufkweyy3uaxb.com. PassKeyChain’s source code includes a small tunnel server in plain Python and a script that lists those names. Find one that is still free, register it, and run the server.

Then, in the app, open the menu and choose Tunnel server. Pick your own server as first choice (type its number to check that the name is yours), and a second choice, such as Google, for when yours can’t be reached. The Activity log notes every sign-in that went through a server other than Google’s.

Sign-ins are encrypted end to end on any tunnel server. Running your own means Google no longer sees when and from where you sign in, and your sign-ins no longer depend on its server. Not yet tried with Chrome on a real server; whether Safari and Firefox accept these computed names is not known yet.

Your own server first, Google as fallback.