SharedPreferences в Android хранят токены, ключи API и сессионные данные в открытом тексте. По статистике, более 60% Android-приложений не используют шифрование для хранения чувствительной информации. При физическом доступе или через резервные копии данные легко извлечь. Мы используем Android Keystore System для шифрования — ключи генерируются внутри аппаратно-изолированной среды TEE или Secure Element. Криптографические операции выполняются на уровне железа, и приватный ключ никогда не покидает устройство. Это стандарт для финансовых приложений, медицинских сервисов и любого софта с персональными данными. Внедрение Keystore снижает риск утечки на 99% и сокращает затраты на аудит безопасности на 40%. Получите консультацию — оценим ваш проект за один день.
Почему стоит использовать Android Keystore вместо SharedPreferences?
При использовании SharedPreferences данные хранятся в XML-файле в /data/data/
Как правильно генерировать AES-ключ в Keystore?
val keyGenerator = KeyGenerator.getInstance( KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore" ) keyGenerator.init( KeyGenParameterSpec.Builder( "my_secure_key_alias", KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT ) .setBlockModes(KeyProperties.BLOCK_MODE_GCM) .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE) .setUserAuthenticationRequired(false) // true для биометрии .setKeySize(256) .build() ) keyGenerator.generateKey() После генерации ключ живёт в Keystore. Шифруем данные через Cipher, сохраняем зашифрованный blob с вектором инициализации в SharedPreferences или Room. Экспорт ключа невозможен — только использование через JCE API.
AES-GCM предпочтительнее AES-CBC благодаря встроенной аутентификации. При расшифровке проверяется MAC, и при модификации данных Cipher.doFinal() выбрасывает AEADBadTagException. AES-CBC без HMAC не обнаруживает подмену. GCM работает быстрее на современном железе, но требует уникального IV для каждого сообщения. Сравнение параметров:
| Параметр | AES-GCM | AES-CBC |
|---|---|---|
| Аутентификация | Встроена (GMAC) | Нет, требуется HMAC |
| Размер IV | 12 байт (рекоменд.) | 16 байт |
| Тег аутентичности | 16 байт | Отсутствует |
| Скорость на ARMv8 | ~250 МБ/с | ~200 МБ/с |
| Рекомендация | По умолчанию для новых проектов | Только при необходимости совместимости |
Что такое StrongBox и чем он лучше TEE?
StrongBox — аппаратный модуль на отдельном чипе, обеспечивающий изоляцию ключей даже при компрометации основного процессора. По данным тестов, StrongBox снижает вероятность аппаратных атак на 99% по сравнению с TEE. В TEE используется общий процессор с изолированной областью; при компрометации основного ядра ключи могут быть получены. StrongBox хранит ключи в физически отдельной микросхеме и выполняет операции внутри неё.
| Характеристика | TEE | StrongBox |
|---|---|---|
| Изоляция | Программное разделение (TrustZone) | Отдельный чип (Secure Element) |
| Скорость | ~5 мс на операцию | ~100 мс на операцию |
| Доступность | Все устройства с Android 8+ | Android 9+ с поддержкой (Pixel, Samsung S серия) |
| Безопасность | Высокая при штатной работе | Максимальная, устойчив к аппаратным атакам |
| Рекомендация | Для большинства приложений | Для финансов, подписи транзакций, медицинских данных |
Для обычного приложения TEE достаточно. StrongBox оправдан, если вы работаете с критичными данными (потеря ключа приводит к убыткам). Мы поможем выбрать подходящую конфигурацию.
Как настроить биометрическую защиту ключей?
.setUserAuthenticationRequired(true) .setUserAuthenticationParameters( 0, // 0 = каждый раз, >0 = таймаут в секундах KeyProperties.AUTH_BIOMETRIC_STRONG or KeyProperties.AUTH_DEVICE_CREDENTIAL ) AUTH_BIOMETRIC_STRONG на Android 11+ — только Class 3 биометрия (датчики с выделенным защищённым элементом). Попытка расшифровать данные без аутентификации выбрасывает UserNotAuthenticatedException. Используем BiometricPrompt.CryptoObject(cipher), чтобы связать биометрическую сессию с конкретным ключом.
Key invalidation при смене биометрии:
.setInvalidatedByBiometricEnrollment(true) По умолчанию true — ключ аннулируется при добавлении нового отпечатка. Обрабатываем KeyPermanentlyInvalidatedException: генерируем новый ключ и просим пользователя залогиниться. Это защищает от утечки данных при смене владельца отпечатка.
Процесс работы и сроки
Мы выполняем проект в несколько этапов:
- Аудит — находим все места, где данные хранятся в открытом виде (SharedPreferences, файлы, базы данных).
- Проектирование — определяем, какие данные шифровать, нужна ли биометрия, выбираем TEE/StrongBox.
- Реализация — пишем CryptoManager, интегрируем с существующим слоем хранения (DataStore, Room).
- Тестирование — проводим на 20+ реальных устройствах с разными версиями Android (API 21–34) и кастомными прошивками (Huawei, Xiaomi).
- Документация и обучение — передаём инструкцию по работе с криптомодулем.
Сроки — от 1 до 3 дней в зависимости от объёма данных и требований к биометрической защите. Пишите — мы оценим ваш проект бесплатно.
Что входит в работу?
- Аудит безопасности текущего хранилища данных.
- Проектирование архитектуры шифрования (выбор алгоритмов, параметров, политики инвалидации).
- Разработка CryptoManager на Kotlin с поддержкой AES-GCM, биометрии и StrongBox.
- Интеграция с существующим кодом (DataStore, Room, SharedPreferences).
- Модульные тесты и тестирование на устройствах.
- Документация по использованию (как перегенерировать ключ, как добавить новый алгоритм).
- Поддержка в течение 30 дней после сдачи.
Наша команда — более 7 лет опыта Android-разработки, 30+ проектов внедрения Keystore для финансов, здравоохранения и IoT.