Безпечне зберігання ключів у Secure Enclave для криптогаманця на iOS
Типова проблема криптогаманця на iOS: приватний ключ зберігається в Keychain, але при компрометації пристрою або джейлбрейку він може бути вкрадений. Secure Enclave (SE) — апаратний ізольований процесор всередині Apple SoC, який гарантує, що ключ ніколи не покидає чип. Ми пропонуємо інтеграцію SE для максимального захисту. Наш досвід — багаторічний у iOS-розробці та криптографії. Реалізуємо все під ключ: від проектування до тестування на реальних пристроях.
Офіційна документація Apple: Secure Enclave — апаратний модуль безпеки, ізольований від основного процесора.
Як Secure Enclave захищає приватні ключі?
SE генерує та зберігає ключі всередині свого чипа. Операція підпису виконується всередині SE, назовні повертається тільки результат. Навіть ваш код не має прямого доступу до приватного ключа. У поєднанні з kSecAttrAccessControl та флагом .biometryCurrentSet ключ автоматично інвалідується при зміні біометрії користувача. Це означає, що при додаванні нового відбитка або зміні Face ID старий ключ стає недоступним — потрібне створення нового. Для криптогаманця така поведінка обов'язкова.
Обмеження, які потрібно знати до початку
Secure Enclave підтримує тільки P-256 (secp256r1, він же NIST P-256). Це не secp256k1, яку використовують Bitcoin та Ethereum. Тому SE не підходить для зберігання ETH/BTC приватних ключів напряму. Типове використання для криптогаманця — зберігати в SE ключ шифрування, яким зашифровано secp256k1 приватний ключ у Keychain. Або використовувати SE для біометричного захисту Keychain-запису через SecAccessControlCreateWithFlags.
Якщо ваш додаток працює з блокчейнами, які використовують P-256 (наприклад, деякі enterprise-ланцюжки або NEAR protocol через ed25519), SE можна використовувати для прямого зберігання та підпису.
Чому SE не підходить для Bitcoin та Ethereum?
Bitcoin та Ethereum використовують алгоритм secp256k1, який SE не підтримує. Рішення — схема з шифруванням: генеруємо ефемерний P-256 ключ у SE, генеруємо secp256k1 ключ у пам'яті, шифруємо його публічним ключем SE через ECIES та зберігаємо зашифрований blob у Keychain. При підписі розшифровуємо через SE (з біометрією), використовуємо secp256k1 ключ для підпису і одразу обнуляємо пам'ять. Це безпечніше простого Keychain, але ключ ніколи не зберігається на диску відкрито.
Порівняння методів зберігання
| Метод | Безпека | Продуктивність | Застосовність |
|---|---|---|---|
| Keychain (без SE) | Середня (залежить від пароля пристрою) | Висока | Будь-які ключі |
| Secure Enclave (P-256) | Максимальна (апаратна ізоляція) | Середня (потрібна біометрія) | Тільки P-256 |
| SE + шифрування (для secp256k1) | Дуже висока (ключ зашифровано) | Нижча (два криптокроки) | Будь-які, але складніше |
Secure Enclave в рази безпечніше програмного зберігання: ключ фізично ізольований, що виключає крадіжку через аналіз пам'яті або дамп диска. Навіть при компрометації пристрою зловмисник не зможе витягти приватний ключ без біометричної аутентифікації.
Реалізація підпису та зберігання
Створення ключа в 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 — це і є вказівка системі створити ключ у SE. biometryCurrentSet інвалідує ключ при зміні біометрії (додавання нового відбитка або зміна Face ID). Для гаманця це правильна поведінка — потрібна явна переаутентифікація.
Підпис даних через SE-ключ
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() } Підпис виконується асинхронно з точки зору UI — поки SE обробляє запит (і якщо потрібна біометрія — поки користувач аутентифікується), main thread не блокується. Весь виклик потрібно винести в Task або dispatch queue.
Що входить у роботу
- Аудит поточної схеми зберігання ключів та загроз.
- Проектування схеми з Secure Enclave (пряме або з шифруванням).
- Реалізація на Swift 5.9+ з використанням Swift Concurrency.
- Інтеграція з біометрією (Face ID / Touch ID) через
LocalAuthentication. - Тестування на фізичних пристроях (усіх цільових моделях).
- Документація з експлуатації та міграції ключів.
- Навчання команди підтримці та доробкам.
Процес роботи
| Етап | Тривалість | Результат |
|---|---|---|
| Аудит вимог | 1 день | Визначення необхідності P-256 або схеми шифрування |
| Проектування | 1-2 дні | Архітектура, прототип на реальному пристрої |
| Реалізація | 3-7 днів | Код на Swift з async/await, інтеграція біометрії |
| Тестування | 2-3 дні | Сценарії зміни біометрії, перевстановлення, бекапу |
| Документація та передача | 1 день | Документація, навчання команди |
Скільки часу займає інтеграція SE?
Терміни — від 3 до 14 днів залежно від складності схеми. Симулятор достатній для більшої частини розробки, але фінальне тестування обов'язково на пристрої.
Зв'яжіться з нами для консультації та оцінки вашого проекту — ми безкоштовно проаналізуємо поточну схему та запропонуємо оптимальне рішення. Отримайте надійний захист для свого криптогаманця вже сьогодні!