Approach (high level)
Use per-device asymmetric keys in a hardware-protected root (TEE/SE), a signed one-time QR payload from factory, and a cloud PKI + challenge-response to prevent cloning and bind identity. Recovery uses multi-party escrow and authenticated out-of-band (OOB) approval.
Protocol (stepwise)
- Factory: for each device generate DeviceKeyPair (sk_D in SE, pk_D exported), create FactoryToken = { device_id, pk_D, expiry, nonce } signed by ManufacturerSK. Encode FactoryToken and a one-time ProvisioningSecret S (high-entropy random) into QR; print QR and store hashed S in manufacturer/cloud DB. QR marked single-use.
- Boot (offline): sealed image reads QR, SE imports nothing—SE uses internal key to sign a proof-of-possession of pk_D (or reveals pk_D via attestation). Device connects to cloud, sends FactoryToken, manufacturer signature, attestation statement from SE, and a challenge-response proving possession of S or sk_D. Cloud verifies manufacturer signature, checks one-time S hash, verifies attestation and freshness, then mints DeviceCertificate bound to cloud account and records pk_D.
Preventing QR cloning
- QR contains a one-time S and manufacturer signature over device_id+nonce; cloud marks S used on first successful provisioning.
- DeviceKeyPair protected in SE—an attacker cloning QR without SE cannot complete challenge-response or produce SE attestation.
- Use tamper-evident packaging and printing secure holographic markers to raise bar for physical cloning.
Identity binding
- Cloud issues X.509/ED25519 certificate for pk_D tied to user account after mutual attestation and optional user authentication (email/phone + OTP). Certificates include device_id and attestation claims.
Secure recovery if QR lost
- Multi-option recovery: (1) Account-based recovery: user authenticates to cloud (MFA) and requests issuance; cloud requires manufacturer attestation or proof from other enrolled devices. (2) Escrow: manufacturer stores encrypted recovery token K_enc = Enc( user_pubkey, K ) where K is wrapped with SE-protected key; release requires user OOB MFA plus manufacturer policy checks. (3) Hardware fallback: bring device to authorized service with physical attestation and manufacturer private approval.
Security considerations / properties
- Freshness: nonces + timestamps prevent replay.
- Forward secrecy: short-lived provisioning tokens; DeviceCertificate rotation.
- Compromise containment: revocation CRL/OCSP; mark S as used.
- Privacy: avoid embedding user-identifying info in QR; use linking only after cloud minting.
Rationale: asymmetric keys + SE attestation enforce that possession of QR alone is insufficient; one-time secret prevents replay/cloning; multi-factor recovery balances usability and security.
