01 / The Problem & Hard Constraints

The Problem & Hard Constraints

Standard software-based 2FA or financial signing applications store private keys in application sandboxes. On rooted, jailbroken, or malware-infected devices, these memory spaces can be scraped, exposing cryptographic keys.

• Zero Key Extraction: The private key must never exist in the mobile operating system’s active RAM.
• Cryptographic Proof: Transactions must be signed using Elliptic Curve Digital Signature Algorithm (ECDSA/Ed25519) within hardware isolated from the main CPU.
• Anti-Spoofing: The backend server must be able to cryptographically verify that the signature came from genuine hardware, not an emulator or a replay attack.

02 / Architecture & Core Design Decisions

Architecture & Core Design Decisions

• Trusted Execution Environment (TEE): Interfaced directly with iOS Secure Enclave and Android StrongBox/Keystore. Key generation occurs inside the silicon microchip. The OS can request a payload to be signed, but the hardware physically cannot export the private key.
• Hardware Attestation: Implemented Apple App Attest and Android Play Integrity APIs. During registration, the device generates an X.509 certificate chain signed by the manufacturer (Apple/Google) proving the hardware is genuine and unmodified.
• Biometric Cryptographic Binding: Access to the hardware signing key is mathematically bound to biometric authentication (FaceID/Fingerprint). The OS cannot authorize a transaction without a fresh, local biometric token.

03 / Deep Technical Challenges & Solutions

Deep Technical Challenges & Solutions

The Challenge: Replay Attacks on Financial Payloads. An attacker could intercept a valid signed transaction payload (e.g., “Transfer $100”) and resubmit it to the API multiple times.

The Solution: Nonce Pinning & Strict Payload Serialization.

1. The backend issues a cryptographically secure, single-use nonce.
2. Jeria serializes the financial payload, the nonce, and a timestamp into a strict canonical byte array.
3. The raw bytes are hashed (SHA-256) and sent to the Secure Enclave for ECDSA signing.
4. The backend verifies the signature, processes the transaction, and instantly invalidates the nonce. Any intercepted payload becomes mathematically useless.