YinkoShield
Brief

Architecture / architecture · 05

Zero Trust Bootstrap Protocol

At first initialisation, the device generates a keypair inside its trusted execution environment. The private key never leaves. The public key is registered to the operator backend over an operator-controlled onboarding channel — a path that does not include us.

[ zero trust bootstrap protocol · first init ] device ·01 generate keypair at first initialisation, in-TEE private stays in TEE public leaves once ·02 register public key over operator-controlled onboarding channel YinkoShield is not in this path public key only operator backend stores registered public key indexed by device id verifies any future evidence independently — sovereign private key never leaves · public key registered once · no key-escrow
Private key stays in the device's secure element. The operator registers the public key once and verifies all future evidence with it.

What “zero trust” means here

There is no shared secret installed at the factory. There is no key that we hold on behalf of the operator. There is no escrow. At first initialisation, the device generates its own keypair inside its trusted execution environment — TEE on Android, Secure Enclave on iOS, HSM on the terminal. The private key is generated there and lives there. The public key, and only the public key, leaves the device.

outcomes

What this lets you do today that you couldn't before

  • Onboard devices without pre-shared secrets

    No keys to provision at the factory, no shared static credentials to rotate. The keypair appears at first init, on the device, in the trust boundary.

  • Hold key sovereignty across the device lifecycle

    YinkoShield never sees a private key. Operators do not depend on a vendor's escrow practices for their own audit posture.

  • Detect re-bootstrap as a signal, not as a silent restart

    A wiped or restored device generates a new keypair. The operator sees the change explicitly and applies policy — typically requiring re-attestation of the user identity.

  • Avoid escrow-related compliance overhead

    No part of the substrate stores private keys, transmits them, or has access to recover them. Your compliance scope shrinks accordingly.

  • Onboard at PKI-conformant pace

    Existing PKI infrastructure for registering and rotating public keys works unchanged. The bootstrap fits inside the operator's standard identity-binding flow, not alongside it.

How registration works

The public key is registered to the operator’s backend over the operator’s onboarding channel — typically the same channel they use for any device-identity-binding step in their existing process. We are not in this path. We do not see the public key. We do not store the device-to-operator mapping.

From that moment, the operator owns the verification material. Every future event signed by the device can be verified by the operator with the registered public key, and only by parties to whom the operator chooses to grant the public key.

properties

What you get when the bootstrap runs

  • ·01 In-TEE generation

    Keypair created inside the device's secure element — TEE on Android, Secure Enclave on iOS, HSM on terminals. Nothing in user-space sees the private key.

  • ·02 One-way registration

    The public key leaves the device exactly once, over the operator's onboarding channel. The private key never leaves.

  • ·03 No escrow, anywhere in the stack

    No backup, no recovery key, no master key. A device that has lost its private material re-bootstraps from scratch.

  • ·04 Operator-owned device-to-key mapping

    The operator stores it. We do not. We do not have it. Audit scope reflects that.

  • ·05 PKI-conformant operation

    Public-key registration, rotation, and revocation follow standard PKI patterns. No bespoke key-management protocol.

  • ·06 Re-bootstrap detection

    A device presenting a new public key with the same device identifier surfaces as a state change the operator can act on.

Why this matters

Sovereign verification — the property where any party with the public key can verify evidence independently, with no YinkoShield endpoint in the path — is established by this bootstrap, not by the verifier. If the bootstrap put us in the key path, the verifier could not be sovereign no matter how it was implemented. The two are coupled: ZTBP is the property at registration, sovereign verification is the property at use.

What’s out of scope for the bootstrap

  • Device authenticity. The TRP measures what it can about the device’s runtime state at bootstrap, but a device that presents a counterfeit hardware identity is a separate problem the operator handles in their onboarding flow.
  • Re-bootstrap after device wipe or transfer. A device that has been wiped generates a new keypair. The operator can detect this and apply policy — typically requiring re-attestation of the user identity — but the bootstrap itself is identity-of-device, not identity-of-user.

Where to read more

The bootstrap protocol, TEE guarantees, and onboarding interface specification live in YEI-001 §6.6, shared with regulators and qualifying partners under NDA.

Request the YEI-001 specification →