Безпечне зберігання ключів у Secure Enclave для криптогаманця на iOS

Безпечне зберігання ключів у 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, але ключ ніколи не зберігається на диску відкрито.

Порівняння методів зберігання

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.
• Тестування на фізичних пристроях (усіх цільових моделях).
• Документація з експлуатації та міграції ключів.
• Навчання команди підтримці та доробкам.

Процес роботи

Скільки часу займає інтеграція SE?

Терміни — від 3 до 14 днів залежно від складності схеми. Симулятор достатній для більшої частини розробки, але фінальне тестування обов'язково на пристрої.

Зв'яжіться з нами для консультації та оцінки вашого проекту — ми безкоштовно проаналізуємо поточну схему та запропонуємо оптимальне рішення. Отримайте надійний захист для свого криптогаманця вже сьогодні!

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.