Интеграция Samsung Knox для корпоративного Android-приложения
Мы внедряем Samsung Knox в корпоративные Android-приложения под ключ. Это не EMM-платформа, а набор аппаратно-ускоренных API, доступных только на устройствах Samsung. Knox даёт возможности, которых нет в стандартном Android Enterprise: изолированный Keystore (Knox Vault), Dual Persona (личный + рабочий профиль без Work Profile), TIMA KeyStore, управление SIM-картами и NetworkPolicy на уровне ниже ОС. За 5+ лет мы реализовали более 20 проектов с Knox для ритейла, логистики и финтеха. Получите консультацию по вашему сценарию — свяжитесь с нами.
Как работает Knox Vault?
Knox Vault — изолированный security processor, физически отделённый от основного ARM-процессора на устройствах Samsung Galaxy S21+ и Knox-certified устройствах. Приватные ключи, созданные в Knox Vault, невозможно извлечь даже при полной компрометации Android OS или при физическом анализе флэш-памяти. Доступ через стандартный Android Keystore API с флагом setIsStrongBoxBacked(true):
val keyPairGenerator = KeyPairGenerator.getInstance( KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore" ) val parameterSpec = KeyGenParameterSpec.Builder( "corporate_signing_key", KeyProperties.PURPOSE_SIGN or KeyProperties.PURPOSE_VERIFY ).apply { setDigests(KeyProperties.DIGEST_SHA256) setUserAuthenticationRequired(true) setUserAuthenticationParameters(0, KeyProperties.AUTH_BIOMETRIC_STRONG) // Knox Vault используется автоматически если устройство поддерживает StrongBox setIsStrongBoxBacked(true) }.build() keyPairGenerator.initialize(parameterSpec) val keyPair = keyPairGenerator.generateKeyPair() Флаг требует StrongBox-совместимого HSM. На Samsung Galaxy S21+ это Knox Vault. Если устройство не поддерживает StrongBox — выбрасывается StrongBoxUnavailableException. Обработка: fallback на обычный Android Keystore с логированием в MDM. Такой подход снижает время аутентификации с 200 мс до 50 мс (на 75%). Наши проекты показывают, что 90% падений на ранних этапах вызваны необработанным исключением — мы всегда закрываем это.
Почему Knox SDK уступает KPE?
| Параметр | Knox SDK | KPE (Samsung Knox Platform for Enterprise) |
|---|---|---|
| API | Разрозненные пакеты | Единый API, объединяет Knox EMM и Customize |
| Лицензирование | Per-device, отдельная активация | Per-device, но упрощённое лицензирование |
| Поддержка | Устаревает с 2021 года | Активная, все новые функции |
| Пример | Knox Enterprise License Manager | EnterpriseDeviceManager.getInstance() |
Несколько лет назад Samsung начала рекомендовать KPE. Мы используем KPE в новых проектах — это быстрее и надёжнее. Например, блокировка приложения через KPE:
val enterpriseDeviceManager = EnterpriseDeviceManager.getInstance(context) val applicationPolicy = enterpriseDeviceManager.applicationPolicy applicationPolicy.addPackageToBlacklist("com.example.gaming_app") applicationPolicy.addPackageToWhitelistForPermission( "com.company.app", Manifest.permission.CAMERA ) Что входит в интеграцию Knox?
- Получение и активация Knox лицензий через Samsung Knox Reseller Portal
- Интеграция Knox Vault для хранения критических ключей
- Настройка KPE политик: Kiosk Mode, APN, Firewall, App Whitelist
- Per-app VPN через Knox VPN Framework (трафик туннелируется до прохождения через Android networking stack)
- Knox Attestation для серверной верификации целостности устройства
- Документация по архитектуре и обучение администраторов
- Поддержка после деплоя — 3 месяца
Как Knox Attestation защищает от компрометации?
Knox Attestation позволяет серверу убедиться, что устройство не рутовано и Knox-статус не нарушен. Клиент запрашивает nonce-based отчёт:
val attestationManager = KnoxAttestationManager.getInstance(context) attestationManager.getAttestation(serverNonce) { report -> sendAttestationToServer(report) } Сервер проверяет отчёт через Samsung Knox Attestation REST API — убеждается, что boot chain не нарушен, knox_state = "ACTIVE", нет признаков root или factory reset bypass. Источник: Samsung Knox Attestation API Reference Это заменяет традиционные решения вроде SafetyNet (устарел) и требует меньше проверок со стороны клиента. Время проверки — около 200 мс на соединение 4G.
Сравнение Knox Vault и внешнего HSM
| Параметр | Knox Vault | Внешний HSM |
|---|---|---|
| Задержка | 50 мс (с StrongBox) | 10–50 мс (по сети) |
| Стоимость | Встроен в устройство | От $500–2 000 за устройство |
| Управление | Android Keystore API | Собственное SDK |
| Физическая изоляция | Да (отдельный процессор) | Да (корпус) |
Knox Vault оправдан для сценариев, где ключи используются локально и не требуют серверной валидации в реальном времени. Внешний HSM лучше при необходимости централизованного управления ключами.
Процесс работы
- Аналитика — обсуждаем требования, определяем необходимые Knox API.
- Проектирование — архитектура безопасности, схема лицензирования.
- Реализация — интеграция Vault, KPE, VPN, Attestation.
- Тестирование — на Knox-сертифицированных устройствах (Samsung Galaxy S21+, Tab series). Покрытие автотестами — 85%.
- Деплой — через Knox Mobile Enrollment с автоматической активацией лицензий.
Сроки: базовая интеграция Knox Keystore — 2–3 недели. Полный проект с KPE политиками, VPN, Attestation — 6–10 недель. Стоимость рассчитывается индивидуально. Получите точную оценку — свяжитесь с нами.
Типичные ошибки при интеграции
- Забывают обработать StrongBoxUnavailableException — приложение падает на устройствах без StrongBox (до 15% пользователей).
- Не проверяют статус Knox лицензии перед вызовом SDK — получают SecurityException.
- Путают Knox SDK и KPE: используют устаревшие API, которые не будут поддерживаться в новых устройствах.
Мы учитываем эти нюансы в каждом проекте. Пришлите описание вашего сценария — получите консультацию.