Passkey Management

This operation requires root-level privileges.

The passkeys are stored in /var/lib/passkeyd/database with permissions set to 700. Only the root user has read and write access to the folder, while normal users are not permitted to read it. The folder has the following structure:

└── /var/lib/passkeyd/database/
    └── <Hex(Sha256(PublicKeyCredentialRpEntity.id))>/
        ├── metadata
        └── <Hex(CredentialSource.id)>

Each folder inside the database is named after the hex-encoded hash of the replying party's ID. It contains one required special file, metadata. The content of metadata is CBOR-encoded PublicKeyCredentialRpEntity and other files stores a passkey. However, the private key is encrypted and technically cannot be decrypted. Instead, the masked private key is directly sent to the TPM (Trusted Platform Module) along with the arbitrary data. Only the same TPM that generated the private key can decrypt i t. However, the TPM will never release the decrypted key to anyone, not even to a passkeyd.

Instead of revealing the private key, the TPM signs the provided arbitrary data and returns the signature. After this operation, the decrypted private key is completely erased by the TPM within the TPM chip. This signing process occurs within the TPM hardware and is not handled by software. After signing, the signature is returned to passkeyd, which then processes it into the expected format. The formatted signature is forwarded to the entity that initiated the request (e.g., Chromium), which then sends it to the requested website. The website uses the signature to validate that you are the owner of the account. Each time you sign in, arbitrary data is sent, and a different signature is generated. The private key is required for generating the signature, while the public key is used for validating it.

PublicKeyCredentialRpEntity

pub struct PublicKeyCredentialRpEntity {
    pub id: String<256>,
    pub name: Option<String<64>>,
    pub icon: Option<Icon>,
}