KeyStore Storage

Why We're Using React Native Keychain for Secure Private Key Storage

The Problem

In any mobile application that handles cryptographic identities, whether for blockchain wallets, end-to-end encrypted messaging, or secure authentication flows, securely storing private keys on the user’s device is a non-negotiable requirement.

Storing a private key insecurely (e.g., in AsyncStorage, the file system, or an unencrypted database) exposes the user to catastrophic security risks. If someone gains access to that key, they gain complete control over the user's identity or assets.

The question is not whether private keys should be stored, but how they can be stored safely without compromising usability or sovereignty.

Why React Native Keychain

We use React Native Keychain in client-side reference applications because it provides access to OS-native secure storage mechanisms rather than JavaScript-level storage.

OS-Level, Hardware-Backed Security

Instead of relying on application-level storage, React Native Keychain interfaces directly with platform-native secure storage:

• iOS: Private keys are stored in the iOS Keychain and may be protected by the Secure Enclave when key-generation policies require hardware-backed isolation.

• Android: Keys are stored using the Android Keystore and may be backed by a Trusted Execution Environment (TEE) or StrongBox, depending on device capabilities.

This ensures cryptographic material benefits from OS-level isolation, access control, and hardware-assisted protections where available.

Important clarification: Not all Keychain-stored keys are always Secure Enclave–resident. Hardware backing depends on key attributes and device support. Cryptic explicitly configures keys to require the strongest available protection.

Perfect Fit for Private Keys

Private keys are long-lived, high-value secrets that cannot be rotated if leaked. React Native Keychain applies appropriate safeguards:

• Encrypted at rest: The OS encrypts key material before persistence

• Application-scoped access: Other apps cannot read or extract stored keys

• Optional biometric enforcement: Access can require Face ID or fingerprint authentication

This allows private key material to remain on-device and non-custodial, without transmission to servers.

What We’re Avoiding

We explicitly chose not to use:

AsyncStorage	Unencrypted, accessible via root; insecure for secrets
File system / SQLite	Requires manual encryption and complex secure bootstrapping
Server-side key storage	Compromises user privacy and decentralization; introduces trust

---

Security-Usability Tradeoff

Keeping keys only in volatile memory would maximize security but severely degrade usability. React Native Keychain enables a practical balance:

• Security: OS-level encryption, hardware-backed isolation where available, biometric gating

• Usability: Keys are securely persisted and accessed without repeated prompts

• Sovereignty: Users retain exclusive control over device-bound keys

Real-World Applications

We use secure on-device storage in reference applications for:

• Wallet-based identity: Long-lived identity keys used for signing and authentication

• Encrypted messaging: Asymmetric keys used to establish forward-secure sessions

• Post-quantum workflows: Temporary or device-bound ML-KEM key material for session establishment

• Decentralized authentication: Cryptographic signatures replace usernames and passwords

Note: Device-stored keys are used only in client-side reference applications. Cryptic’s enterprise and protocol integrations rely on TEE-isolated server-side key management as described in the Cryptic KMaaS architecture.

Summary: Why We Trust It

React Native Keychain provides a mature, OS-native mechanism for storing sensitive key material in client environments. Used correctly, it ensures:

• Private keys remain device-bound

• Access is enforced by OS security and optional biometrics

• User experience remains seamless without compromising cryptographic hygiene