Local key custody — device, operator, and vendor boundaries

1. The three custody regions

The custody story has three regions. They are concentric — the device is inside the operator’s trust perimeter, which sits inside the regulator’s audit perimeter — but they are not nested in terms of access. Each region holds material the other regions do not see.

• Device. Holds the private key — platform key-store resident, non-exportable at platform API level, hardware-backed where available — the Local Evidence Ledger, and the in-flight payload before it is signed and submitted.
• Operator. Holds the public-key registry, the verifier deployment, the policy engine, and the evidence corpus submitted by devices across the operator’s fleet.
• Regulator. May review operator-held evidence under the applicable legal, supervisory, scheme, or contractual basis. Privacy and security frameworks such as POPIA [1], NDPA 2023 [2], and GDPR Article 32 [3] inform the operator’s processing and security posture; they do not by themselves define every evidence-access path. Holds nothing custodially of its own.

YinkoShield is outside this set. The supplier of the runtime is not a holder of any of the three sets of material — by design, not by promise.

2. What the device retains

Material that lives only on the device, never crosses the device boundary, and is destroyed on factory reset (subject to the platform key-flag dependencies noted below):

• The ES256 private key. Generated inside the platform key store at first run, with hardware backing where the platform exposes it: Android Keystore with setIsStrongBoxBacked(true) on devices reporting PackageManager.FEATURE_STRONGBOX_KEYSTORE, TEE-backed Keystore on devices without StrongBox, software- backed Keystore on devices that expose no hardware-backed signer (with that posture surfaced in the attestation chain the operator records at bootstrap). On iOS, the local signing key is Secure Enclave-backed: generated via SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave and a SecAccessControl produced by SecAccessControlCreateWithFlags(allocator, protection, .privateKeyUsage, &error) (Swift: SecAccessControlCreateFlags.privateKeyUsage) passed via kSecAttrAccessControl. This is the local signing key for EEI’s ES256 evidence operations; App Attest is used separately at bootstrap to attest the app-instance key’s origin — that path is described in self-signing-devices. The key is non-exportable from the platform key store. The application process never holds the key bytes; the operator never holds them; the regulator never holds them. Destruction on factory reset is enforced by the platform; for keys generated with setUserAuthenticationRequired(true), destruction also occurs on credential change.
• The Local Evidence Ledger. Append-only on-device record of every observed event. Records are pruned from the device after delivery beyond a retention window; pruning is itself signed.
• In-flight signal payloads. Observations from the TRP that have been recorded in the ledger but not yet signed and submitted.

3. What the operator holds

Material that crosses the device boundary and is held by the operator under whatever record-keeping policy applies:

• The device’s public key. Registered once, at bootstrap, with a platform attestation chain reporting the key’s origin and security level: StrongBox / TEE-backed where available, software-backed where no hardware-backed signer is exposed. The public key by itself produces no claim about the device’s behaviour; it is the predicate against which signed payloads are checked.
• The submitted Evidence Tokens. JWS-compact serialised records carrying the signal stream, indexed by the operator’s transaction context (tctx). The operator decides retention, retention is visible to the regulator under jurisdictional audit rules.
• Verifier deployment artefacts. The four reference verifiers (Python, JavaScript, Go, Java) deployed inside the operator’s perimeter. The operator runs verification; YinkoShield does not.
• Operator-decided verdicts. Policy outputs derived from the signal stream — covered separately in signal-vs-verdict-separation.

4. What YinkoShield does not hold in standard operation

Stated as a flat enumeration so the boundary is unambiguous:

• The device’s private key — never.
• The device’s public key — not held in standard operation.
• Any submitted Evidence Token — not held in standard operation.
• Any device telemetry, license beacon, or analytics — none of these exist in the architecture.
• Any cryptographic material associated with the operator’s verifier deployment — never.

YinkoShield publishes the spec YEI-001, supplies the runtime as an SDK / runtime module, and provides support. The runtime ships compiled; it does not phone home. It does not request keys, payloads, or telemetry from the operator. The operator runs verification; the regulator may audit. YinkoShield is outside all three rings.

These properties hold in standard operation. Where an operator initiates a support engagement and voluntarily shares diagnostic artefacts — crash logs, reproduction test tokens, configuration excerpts — that access is customer-initiated, separately tracked, and outside the runtime data path described here.

This property is operator-testable: during certification the operator can confirm by network observation that the runtime makes no outbound connection outside the operator’s own verification endpoint (no vendor analytics endpoint, no licence beacon, no crash-report SDK). “By design, not by promise” means the operator can verify it themselves; it does not ask the operator to take YinkoShield’s word for it.

5. The legal shape this produces

For an operator-side compliance lead, the practical consequence is that the data-processing posture toward YinkoShield is shaped by what the runtime actually does — which, on the evidence above, is nothing that triggers controller / processor obligations under POPIA [1], NDPA 2023 [2], or GDPR Article 28. A standard DPA may still be appropriate to formalise the no-processing posture (and a careful DPO will request one regardless), but it has no operative content on key, evidence, or telemetry custody — there is none.

For the operator’s audit surface — whether that means internal audit, a payment-scheme assessor, a banking regulator, or a dispute investigator — the custody boundary is verifiable rather than asserted. A verifier can be deployed inside the auditor’s own perimeter (the four reference implementations are language-portable and operate purely on signed input) and signed records can be replayed offline against it. No vendor service is invoked. The applicable review basis — scheme rule, banking supervisory mandate, or contractual audit right — determines who can require access to what; the architecture makes all of it technically verifiable without vendor involvement. This is what makes Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — sovereign-by-construction for the operator and audit-by-construction across all reviewer contexts.

6. Cross-references

• Sibling articles: self-signing-devices, signal-vs-verdict-separation
• Architecture: /architecture/sovereign-verification, /architecture/zero-trust-bootstrap
• Glossary: /glossary
• Theme 9 (forthcoming): key-custody-on-device, what-the-backend-receives-and-cannot-receive

7. External references

[1] Republic of South Africa. Protection of Personal Information Act, No. 4 of 2013 (POPIA) (Government Gazette). gov.za/sites/default/files/gcis_document/201409/3706726-11act4of2013popi.pdf. Cited 2026-03-25.

[2] Federal Republic of Nigeria. Nigeria Data Protection Act (NDPA) 2023 (signed June 2023, supersedes the Nigeria Data Protection Regulation (NDPR) 2019). ndpc.gov.ng. Cited 2026-03-25.

[3] EU. GDPR Article 32 — Security of processing. gdpr-info.eu/art-32-gdpr. Cited 2026-03-25.

[4] Google. Android Keystore — Hardware-backed key system. source.android.com/docs/security/features/keystore. Cited 2026-03-25.