Інтеграція Samsung Knox для корпоративного Android-додатку
Ми впроваджуємо Samsung Knox у корпоративні Android-додатки під ключ. Це не EMM-платформа, а набір апаратно-прискорених API, доступних тільки на пристроях Samsung. Knox дає можливості, яких немає в стандартному Android Enterprise: ізольований Keystore (Knox Vault), Dual Persona (особистий + робочий профіль без Work Profile), TIMA KeyStore, управління SIM-картками та NetworkPolicy на рівні нижче ОС. Ми реалізували понад 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, але спрощене ліцензування |
| Підтримка | Застаріває | Активна, всі нові функції |
| Приклад | 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, які не будуть підтримуватися на нових пристроях.
Ми враховуємо ці нюанси в кожному проекті. Надішліть опис вашого сценарію — отримайте консультацію.
