Self-signing devices — device-resident keypair semantics

1. Why each device signs for itself

A model where signatures are produced by a vendor service has three operational costs: a network dependency on the signing path, a trust-path concentration the operator may not be willing to accept, and a custodial liability for the signing key. EEI declines all three by issuing each device its own keypair.

Per-device signing has three immediate consequences:

• No single key is load-bearing for the fleet. Compromise of one device’s key compromises one device. There is no master-key recovery path to design against.
• No vendor service in the verification path. The operator (and the regulator) need only the device’s public key and the signed payload to verify. YinkoShield is not contacted at verification time, ever.
• Records are portable. A signed record carries its own authenticity. It can be replayed against the operator, archived by the operator, retrieved by the regulator, presented to the scheme — without re-issuance, without re-signing, without re-authoring.

2. Where the keypair lives

The keypair is generated inside the platform-provided key store — hardware-backed where the platform supports it, software-backed where no hardware signer is exposed:

• On Android: Android Keystore [5], with setIsStrongBoxBacked(true) on devices that report PackageManager.FEATURE_STRONGBOX_KEYSTORE (a discrete tamper-resistant element such as Pixel’s Titan M); TEE-backed Keystore on devices without StrongBox; software-backed Keystore on devices that expose no hardware-backed signer at all. The actual security level is reflected in the attestation chain the operator records at bootstrap.
• On iOS: App Attest is used where supported to attest an app-instance key according to Apple’s App Attest model; Secure Enclave-backed storage applies within the boundaries Apple exposes for that API [6].
• On POS terminals: the terminal’s certified secure-cryptoprocessor (PCI PTS-listed), addressed through the vendor SDK.
• On SST kiosks: a TPM 2.0 device or an equivalent HSM, depending on the kiosk vendor’s hardware specification.

Where hardware-backed signing is available, the key is generated and used inside the platform secure element or TEE. Where the platform exposes only a software-backed Keystore, the key remains non-exportable at the platform API level, and that weaker posture is surfaced in the attestation chain for operator policy. In no case does key material exist in application memory: the signing operation is performed by the key store on a payload presented through a defined interface; the application receives the signature, not the key.

The non-exportability property is enforced by the platform, not by EEI. EEI declares the policy at key-generation time (KeyGenParameterSpec on Android, kSecAccessControlPrivateKeyUsage on iOS) and verifies the resulting key handle.

3. Algorithm: ES256

The signing algorithm is ES256 — ECDSA on the NIST P-256 curve [4] with SHA-256, registered for JWS by RFC 7518 [2] §3.1 as Recommended+. (RFC 7518 §3.1’s MUST-implement asymmetric algorithm is RS256; we selected ES256 for compactness and for hardware support across Android Keystore, Apple Secure Enclave, and PCI PTS-listed terminal cryptoprocessors.) The four reference verifiers each consume the JWS-compact wire bytes and verify against the device’s registered public key using their language’s standard ECDSA primitive; verification is deterministic across runtimes regardless of how the signer’s nonce was produced.

The signer’s nonce-generation policy depends on the platform’s secure-element implementation and is observable through key attestation rather than mandated by EEI. Where the platform exposes RFC 6979 [3] deterministic ECDSA (commonly available in software-backed signers, and permitted by FIPS 186-5 [4] for certified hardware), EEI’s reference signer uses it; where the platform’s hardware-backed signer uses a CSPRNG-sourced nonce (the common case for Android Keystore and Apple Secure Enclave, which historically follow the FIPS 186-4 random-k construction), the signature remains valid and verifiable, with the platform’s CSPRNG quality covered by its own attestation chain.

P-256 / ES256 was chosen for a combination of regulatory acceptance, hardware support across Android Keystore, Apple Secure Enclave, and PCI-listed terminal cryptoprocessors, and the existence of widely-deployed verifier libraries. Migration to a post-quantum scheme follows the JOSE registry’s evolution and is out of scope for this article.

4. Bootstrap: the public key, once

At first run, after the keypair is generated, the public key is registered with the operator. The registration is one-way: the device sends the public key bytes plus a platform-attestation certificate chain (Android Key Attestation on Android; on iOS, the App Attest assertion attesting an app-instance key using Apple’s App Attest service with Secure Enclave-backed storage) to the operator’s enrolment endpoint. The operator records the public key against a stable device identifier; nothing is sent back from the operator to the device beyond an enrolment receipt. The full bootstrap protocol is covered under /architecture/zero-trust-bootstrap.

Once the public key is registered, no further key material crosses the device boundary. The only material that crosses subsequently is signed evidence — payload plus signature.

5. Key rotation

Keys rotate on three triggers: explicit operator-initiated rotation, factory-reset of the device (which destroys the prior key per the Keystore lifecycle), and operator decision to force rotation when the platform attestation reports a Verified Boot state the operator no longer trusts (e.g. verifiedBootState moves out of Verified to Unverified or Failed, or deviceLocked flips to false). The verified-boot transition does not by itself invalidate Keystore key handles — the keys typically remain — but the new attestation reflects the untrusted boot state, and operator policy at that point forces rotation. Rotation issues a new keypair, registers the new public key with a fresh attestation chain, and records the rotation event in the ledger itself — so the chain spans the rotation, signed by the prior key on one side and the new key on the other, with the boundary explicit.

Self-signing is the property that makes Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — sovereign at verification time: each device’s signature is checked against the operator’s public-key registry only, with no vendor service in the trust path.

6. Cross-references

• Sibling articles: local-key-custody, append-only-ledger-structure
• Architecture: /architecture/zero-trust-bootstrap, /architecture/evidence-token
• Theme 2: hardware-attestation

7. External references

[1] IETF. RFC 7515 — JSON Web Signature. datatracker.ietf.org/doc/html/rfc7515. Cited 2026-03-20.

[2] IETF. RFC 7518 — JSON Web Algorithms. datatracker.ietf.org/doc/html/rfc7518. Cited 2026-03-20.

[3] IETF. RFC 6979 — Deterministic Usage of DSA and ECDSA. datatracker.ietf.org/doc/html/rfc6979. Cited 2026-03-20.

[4] NIST. FIPS 186-5 — Digital Signature Standard. csrc.nist.gov/publications/detail/fips/186/5/final. Cited 2026-03-20.

[5] Google / AOSP. Android Keystore — Hardware-backed key system; FEATURE_STRONGBOX_KEYSTORE. source.android.com/docs/security/features/keystore. Cited 2026-03-20.

[6] Apple. Apple Platform Security — Secure Enclave. support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web. Cited 2026-03-20.