v145 · Web APIs · Key Management

Key Management

The lifecycle of browser-bound keys — how they are generated, stored, attested, verified, and what happens when the browser or device changes.

key lifecycle

1.Generation: During SPC credential registration, Chrome generates a device-local asymmetric key pair (EC P-256 or RSA). The private key is stored in the browser's secure key store and never exported.
2.Attestation (optional): The browser can optionally provide an attestation certificate chain proving the key is hardware-backed, similar to WebAuthn attestation.
3.Registration: The server stores the browser-bound public key alongside the credential public key. Both must be verified on each payment.
4.Payment assertion: On each SPC payment, Chrome signs the payment data with the browser-bound private key. The assertion includes both the credential signature and the browser-bound signature.
5.Verification: Server verifies the credential signature (user auth) and the browser-bound signature (device binding) separately. Both must pass.
6.Device change: If the user moves to a new device or reinstalls Chrome, the browser-bound key changes. A new registration flow is required — the relying party must update its stored public key.

server-side verification

// Server verification pseudocode (Node.js style)
async function verifySpcAssertion(assertion, storedCredential) {
  const { response } = assertion;

  // 1. Verify user authentication (standard WebAuthn)
  const credentialOk = await verifyWebAuthnSignature(
    response.authenticatorData,
    response.clientDataJSON,
    response.signature,
    storedCredential.publicKey
  );
  if (!credentialOk) throw new Error('Invalid credential signature');

  // 2. Verify browser-bound key (new in Chrome 145)
  if (response.browserBoundKey) {
    const bbkOk = await verifyBrowserBoundSignature(
      response.browserBoundKey.signature,
      response.browserBoundKey.publicKey,
      storedCredential.browserBoundPublicKey  // stored at registration
    );
    if (!bbkOk) throw new Error('Browser-bound key mismatch — possible fraud');
  }

  return { success: true };
}

security properties

// Browser-bound keys provide:
// ✓ Device binding — key tied to specific Chrome installation
// ✓ Non-exportable — private key cannot leave the browser
// ✓ Phishing resistance — credential + browser must both match
// ✓ Fraud signal — mismatched browser-bound key = strong fraud indicator

// Browser-bound keys do NOT replace:
// ✗ User authentication — still requires biometric/PIN
// ✗ Transport security — still requires HTTPS
// ✗ Server validation — still requires full WebAuthn verification

see also

scenario focus

Select a scenario to focus its rendered example and summary.