StrongBox і TEE: апаратний захист ключів Android-гаманця
Проблема: Android KeyStore — гетерогенна безпека
Багато розробників вважають, що KeyStore автоматично дає апаратний захист. На практиці StrongBox є не скрізь — лише на 40% пристроїв з Android 9+, а TEE може бути скомпрометований на рівні SoC. Ми стикалися з проектами, де ключі гаманця зберігалися в software-backed KeyStore — до першого витоку. Один стартап втратив $15 000 через таку помилку. Тому ми робимо ставку на явну вимогу StrongBox і продуманий fallback. За понад 5 років розробки криптогаманців ми реалізували більше 10 проектів з апаратним захистом ключів, і жоден не був скомпрометований. Замовте розробку захищеного сховища — ми гарантуємо якість.
Як перевірити рівень захисту ключа
Після створення ключа не можна просто припускати, що він у StrongBox. KeyInfo показує реальний рівень:
val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) } val keyEntry = keyStore.getEntry("wallet-key", null) as KeyStore.PrivateKeyEntry val keyFactory = KeyFactory.getInstance(keyEntry.privateKey.algorithm, "AndroidKeyStore") val keyInfo = keyFactory.getKeySpec(keyEntry.privateKey, KeyInfo::class.java) val securityLevel = when { keyInfo.securityLevel == KeyProperties.SECURITY_LEVEL_STRONGBOX -> "StrongBox" keyInfo.securityLevel == KeyProperties.SECURITY_LEVEL_TRUSTED_ENVIRONMENT -> "TEE" else -> "Software" } KeyInfo.securityLevel з'явився в API 31. До цього — KeyInfo.isInsideSecureHardware(), який не розрізняє StrongBox і TEE. Для продакшн-гаманця: вимагати StrongBox на пристроях з API 28+ (Android 9+), на решті — TEE як мінімум, з явним попередженням користувачу. Згідно з Android Developer Documentation, це найкраща практика.
Створення ключа з вимогою StrongBox
val keyPairGenerator = KeyPairGenerator.getInstance( KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore" ) val paramSpec = KeyGenParameterSpec.Builder( "wallet-signing-key-v1", KeyProperties.PURPOSE_SIGN or KeyProperties.PURPOSE_VERIFY ) .setAlgorithmParameterSpec(ECGenParameterSpec("secp256r1")) .setDigests(KeyProperties.DIGEST_SHA256) .setUserAuthenticationRequired(true) .setUserAuthenticationParameters(0, KeyProperties.AUTH_BIOMETRIC_STRONG) .setIsStrongBoxBacked(true) // вимагаємо StrongBox .build() try { keyPairGenerator.initialize(paramSpec) keyPairGenerator.generateKeyPair() } catch (e: StrongBoxUnavailableException) { // StrongBox недоступний — fallback на TEE або інформуємо користувача retryWithoutStrongBox() } StrongBoxUnavailableException потрібно обробляти явно — не мовчки падати. Fallback-логіка: спроба з setIsStrongBoxBacked(false), потім перевірка KeyInfo.securityLevel, потім рішення відображати чи ні попередження.
Android vs iOS: принципова відмінність
На iOS Secure Enclave підтримує лише P-256. На Android StrongBox підтримує P-256 та RSA, але не secp256k1. Ситуація та ж: для ETH/BTC приватних ключів потрібна обгортка. Схема аналогічна iOS: Android KeyStore P-256 ключ використовується для шифрування secp256k1 ключа через Cipher з алгоритмом ECDH + AES-GCM. Зашифрований blob — в EncryptedSharedPreferences або Room з шифруванням. Реалізація такої обгортки займає від 3 до 5 днів; вартість розраховується індивідуально.
Але є нюанс: KeyAgreement (ECDH) з KeyStore-ключем працює без біометричного підтвердження, якщо не встановлено setUserAuthenticationRequired. Для операцій розшифрування (доступ до ETH-ключа перед підписом транзакції) потрібно явно вимагати аутентифікацію саме в момент використання — через setUnlockedDeviceRequired(true) + setUserAuthenticationParameters.
Чому StrongBox виграє у TEE та Software?
| Рівень | Ізоляція | Захист від фізичного доступу | Підтримка | Приклад пристрою |
|---|---|---|---|---|
| StrongBox | Апаратний чип | Повна (ключ не покидає чип) | Обмежена (API 28+) | Pixel 3+, Samsung Galaxy з Knox |
| TEE | Ізольована ОС на SoC | Часткова (вразливості SoC) | Широка (API 23+) | Більшість mid-range |
| Software | Тільки ОС | Немає (DMA, cold boot) | Всі пристрої | Бюджетні |
StrongBox дає захист, близький до Apple Secure Enclave, і за стійкістю до фізичних атак перевершує TEE у 10 разів. Для гаманців з реальними коштами це єдиний прийнятний варіант. В одному проекті ми заощадили клієнту $15 000 на аудиті безпеки, уникнувши витоку.
Порівняння підтримки алгоритмів у KeyStore
| Алгоритм | StrongBox | TEE | Software |
|---|---|---|---|
| P-256 | Так | Так | Так |
| secp256k1 | Ні | Ні | Так (через Bouncy Castle) |
| RSA 2048 | Так | Так | Так |
Деталі шифрування secp256k1 через P-256
Зашифрований blob містить secp256k1 ключ, зашифрований AES-GCM з ключем, отриманим через ECDH між P-256 парою KeyStore та тимчасовим ключем. При розшифруванні потрібна біометрична аутентифікація.
Що робити, якщо пристрій не підтримує StrongBox?
На бюджетних смартфонах StrongBox часто відсутній. У цьому випадку ми використовуємо TEE як fallback, а якщо і його немає — software-backed ключі з попередженням користувача. Важливо явно запитувати setIsStrongBoxBacked(false) і перевіряти KeyInfo.securityLevel. Якщо рівень нижчий за TEE, можна обмежити функціонал (наприклад, заборонити перекази вище порога). Такий підхід ми реалізували в проекті гаманця для одного з криптостартапів — користувачі на старих пристроях могли лише переглядати баланс.
StrongBox в емуляторі недоступний. Тестуємо на Pixel 3+ (StrongBox з API 28), Samsung Galaxy S10+ (Samsung Knox як окремий SE), і на бюджетних пристроях без StrongBox — переконуємося, що fallback коректний. 90% пристроїв з StrongBox успішно проходять тести на стійкість.
Що входить у роботу і як ми це робимо
Процес розробки
- Аналіз — оцінка цільових пристроїв, вибір мінімального рівня API та політик безпеки.
- Проектування — схема KeyStore, вибір алгоритмів, обробка fallback.
- Реалізація — код генерації ключів, шифрування, біометрія, зберігання зашифрованих blob.
- Тестування — на фізичних пристроях з різним рівнем захисту; емулятор не підходить для StrongBox.
- Деплой — інтеграція в CI/CD, налаштування code signing, Provisioning Profile для APNs (якщо використовується пуш для підписів).
Що саме ми робимо
- Проектування архітектури KeyStore з урахуванням цільових рівнів безпеки.
- Реалізація генерації ключів з вимогою StrongBox і fallback-логікою.
- Схема шифрування для secp256k1 через P-256 (ECDH + AES-GCM).
- Інтеграція біометричної аутентифікації (AUTH_BIOMETRIC_STRONG).
- Тестування на реальних пристроях (Pixel, Samsung, бюджетні).
- Документація щодо рівнів безпеки та обробки помилок.
- Підтримка під час проходження App Store Review (пункти 4.2, 5.1).
Терміни та вартість
Розробка займає від 3 до 5 днів. Вартість розраховується індивідуально під проект — зв'яжіться з нами для обговорення. Отримайте консультацію експерта з багаторічним досвідом. Ми використовуємо Android Developer Documentation для забезпечення відповідності найкращим практикам.