Technology Overview
BKEY Under The Hood
A high-level overview for developers, product teams, and business stakeholders
BKEY uses a live biometric and a device-held secret to create ephemeral cryptographic keys when the right person is present — a biometric key, or BKEY for short. BKEY offers a user experience similar to Apple's FaceID and supports familiar public-key use cases. The technology is developed based on two decades of experience in the field of biometrics and identity systems and is protected by 22 patents.
Part I
1. BKEY at a Glance
BKEY applies biometrics in a secure key-regeneration flow that enables cryptographic proof of identity and modern public-key use cases. In this flow no password or PIN is required, and under the hood cryptographic proofs are created that can be verified with a registered public key.
BKEY is designed to be privacy-friendly. No biometric signal or derivative is stored. The service registers a public key during enrollment. The private key is never stored but is recreated on the device when it is needed.
BKEY in One Minute
What the user sees
A face scan on an enrolled device, followed by a quick approval.
What happens on the device
The device checks for a live user, tests for deep fakes, and combines a cleared live biometric result with a device secret (generated during enrollment and protected in a secure enclave or similar), and recreates the signing key for that service.
What the service verifies
A fresh signature that matches the public key registered at enrollment.
2. The Core Idea
Traditional biometrics usually act as a gatekeeper. They unlock access to something else — a phone, an account, a vault, or a stored secret.
BKEY goes a step further. It uses a live biometric together with a device-held secret to recreate the key that proves identity.
The hard problem BKEY solves is turning varying samples of the same biometric into the same repeatable mathematical representation. That is what makes it possible to recreate the same key again later.
In simple terms, BKEY binds a particular biometric to a particular device-held random value. Different random values will create different keys. BKEY can therefore support many distinct keys and use cases with the same biometrics. In case a key has been compromised, such key can also be revoked.
3. How the Flow Works
Enrollment
Enrollment begins with a live scan. The device first checks that it is seeing a real person and not a replay, mask, or deepfake. BKEY builds on the native biometric protections of the device and supplements with its own proprietary testing schemes.
BKEY then combines the biometric result with a large random value protected inside the device (typically a secure enclave). That combined result is used to create a key pair for that service and that use case.
The public key is registered with the service. The private key is ephemeral and regenerated on the fly when needed. It is never stored and never uploaded to a server.
Verification and Signing
When the user returns, the service sends a fresh challenge. BKEY repeats the same basic process: live scan, device-held secret, key recreation.
If the right biometric and the right device are present, the same private key is recreated and used to sign the challenge. The service checks the signature with the public key it already knows.
This gives the service proof that the request came from the enrolled device and the live user, within the limits of the device's biometric and integrity protections.
4. What Makes BKEY Different
No stored biometrics or private keys
Reduces the attack surface as no biometrics or private keys need to be protected.
Different keys for each service
Helps prevent cross-service correlation and keeps login keys separate from transaction-signing keys.
Biometrics are never used alone
The device-held secret provides the strength needed for modern cryptographic use cases.
Same biometric, new key
Revocation and re-issuance can happen with the same biometrics.
BKEY gives developers a familiar model: register a public key once, then verify signatures against fresh challenges. The user experience stays simple, while the service-side model stays close to modern public-key authentication and transaction-approval flows.
For product teams, that means strong proof tied to a live user and the right device without asking end users to manage another secret in the core flow.
5. BKEY Integrity
BKEY does not assume biometrics alone are enough for cryptographic strength. The design relies on the device-held secret for that strength, and higher-risk services can add a PIN, a second biometric, approval from another device, or another possession factor.
For higher-risk deployments, services should be ready to step up or decline requests from rooted, jailbroken, or otherwise untrusted devices.
The integrity of BKEY is based on the integrity of the surrounding platform. Solid biometric anti-spoofing, strict rate limits, device integrity checks are all important components of a practical implementation.