Безопасное хранение ключей в 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 дней в зависимости от сложности схемы. Симулятор достаточен для большей части разработки, но финальное тестирование обязательно на устройстве.
Свяжитесь с нами для консультации и оценки вашего проекта — мы бесплатно проанализируем текущую схему и предложим оптимальное решение. Получите надежную защиту для своего криптокошелька уже сегодня!