Secure Key Storage in Secure Enclave (iOS) for Crypto Wallet
Secure Enclave — separate processor inside Apple SoC, isolated from main CPU and RAM. Private key generated in Secure Enclave physically never leaves chip — even your code has no direct access. Signing operation happens inside SE, outside returns only result.
Limitations to Know Before Starting
Secure Enclave supports only P-256 (secp256r1, aka NIST P-256). This not secp256k1 used by Bitcoin and Ethereum. So SE unsuitable for directly storing ETH/BTC private keys. Typical use for crypto wallet — store in SE encryption key that encrypts secp256k1 private key in Keychain. Or use SE for biometric protection of Keychain entry via SecAccessControlCreateWithFlags.
If app works with blockchains using P-256 (some enterprise chains or NEAR protocol via ed25519 — don't confuse), SE can directly store and sign.
Creating Key in Secure Enclave
let accessControl = SecAccessControlCreateWithFlags(
nil,
kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
[.privateKeyUsage, .biometryCurrentSet],
nil
)!
let attributes: [String: Any] = [
kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom,
kSecAttrKeySizeInBits as String: 256,
kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave,
kSecPrivateKeyAttrs as String: [
kSecAttrIsPermanent as String: true,
kSecAttrApplicationLabel as String: "wallet-signing-key-v1",
kSecAttrAccessControl as String: accessControl
]
]
var error: Unmanaged<CFError>?
guard let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error) else {
throw error!.takeRetainedValue()
}
kSecAttrTokenIDSecureEnclave — tells system to create key in SE. biometryCurrentSet invalidates key if biometry changes (new fingerprint or Face ID change). For wallet, correct behavior — requires explicit re-authentication.
Signing Data via SE Key
let publicKey = SecKeyCopyPublicKey(privateKey)!
let algorithm: SecKeyAlgorithm = .ecdsaSignatureMessageX962SHA256
guard SecKeyIsAlgorithmSupported(privateKey, .sign, algorithm) else {
throw WalletError.algorithmNotSupported
}
var signError: Unmanaged<CFError>?
guard let signature = SecKeyCreateSignature(
privateKey,
algorithm,
dataToSign as CFData,
&signError
) else {
throw signError!.takeRetainedValue()
}
Signing executes async from UI perspective — while SE processes (and if biometry needed — user authenticates), main thread doesn't block. Entire call should be in Task or dispatch queue.
Scheme for ETH/BTC Wallets
Since SE doesn't work with secp256k1 directly, use following scheme:
- Generate ephemeral P-256 key in SE — this is "encryption key"
- Generate secp256k1 private key in memory
- Encrypt secp256k1 key via ECIES with SE public key:
SecKeyCreateEncryptedDatawith algorithmeciesEncryptionStandardX963SHA256AESGCM - Save encrypted blob in Keychain with
kSecAttrAccessibleWhenUnlockedThisDeviceOnly - On transaction signing: decrypt via SE (requires biometry), use secp256k1 key for signing, immediately zero from memory
More complex than single Keychain storage, but key never lives on disk in plaintext.
Process
Requirements audit (P-256 direct or encryption scheme for secp256k1), implementation, real hardware testing — simulator unsupported. Separately test behavior on biometry change, app deletion and reinstall.
Timeline — 3–5 days. Simulator sufficient for most development, but final testing only on device.







