Безопасность · 8 min read · Oct 24, 2025
Samsung Knox одобрен правительством США для секретного использования, но действительно ли он безопасен?

Table Of Contents
- Samsung Knox подтвержден и одобрен для секретного использования правительством США
- Значит ли это, что Samsung Knox является самым безопасным способом хранения важных и личных изображений /видео /документов
- Как уязвим Samsung Knox
- В заключение Ares указывает на то, что Samsung Knox не так безопасен, как утверждается.
- Рекомендация от Ares
Samsung Knox подтвержден и одобрен для секретного использования правительством США
Samsung Electronics объявила, что ее решения были одобрены правительством США как первые потребительские мобильные устройства, подтвержденные NIAP, для обработки полного спектра секретной информации. После завершения десяти меморандумов о соглашениях (MOA) правительство добавило Galaxy S4, Galaxy S5, Galaxy Note 3, Galaxy Note 4, Galaxy Note 10.1 (2014 Edition), Galaxy Note Edge, Galaxy Alpha, Galaxy Tab S 8.4, Galaxy Tab S 10.5 и Galaxy IPSEC Virtual Private Network (VPN) Client в список компонентов программы Commercial Solutions for Classified (CSfC).
Этот успех является прямым результатом успешного тестирования и сертификации Samsung в рамках программ Common Criteria Mobile Device Fundamental Protection Profile (MDFPP) и VPN Protection Profile (VPNPP) правительства США. Указанные устройства Samsung доступны для использования с секретными правительственными сетями и данными. Все устройства и возможности включают функции безопасности, поддерживаемые Samsung KNOX.
Собственное описание Samsung своего сервиса Knox также указывает на те же факты
“Контейнер KNOX Workspace улучшает пользовательский опыт, обеспечивая безопасность корпоративных данных, создавая безопасную зону на устройстве сотрудника для корпоративных приложений и шифруя корпоративные данные как в состоянии покоя, так и в движении. Контейнер KNOX Workspace предоставляет пользователям изолированную и безопасную среду внутри мобильного устройства, полностью с собственным домашним экраном, лаунчером, приложениями и виджетами для более простого, интуитивного и безопасного использования. Приложения и данные внутри контейнера разделены.”
Список одобренных продуктов DISA можно найти по адресу: https://www.disa.mil/Services/Network-Services/UCCO.
Значит ли это, что Samsung Knox является самым безопасным способом хранения важных и личных изображений /видео /документов
С учетом нарушений и взломов, происходящих почти каждый день, пользователь подвергает себя серьезным рискам, сохраняя личные изображения/документы или видео в облаке. С взломами iCloud было доказано, что даже знаменитости не защищены от взлома. Утечки SnapChat доказали, что изображения детей в возрасте от 13 до 17 лет подвержены таким утечкам. Утечки Dropbox доказали, что сохранение в Dropbox также связано с относительно высоким риском.
Так что же делать пользователям с их изображениями и видео, снятыми в эти приватные моменты? С одобрением правительства США для секретного использования Samsung Knox стал первым мобильным устройством, которому гарантирована безопасность от хакеров, не менее чем от самого Большого Сэма.
С неограниченной памятью (до 64 ГБ) на борту многих продуктов Samsung вы в безопасности с точки зрения пространства, но действительно ли Samsung Knox является Форт-Ноксом для безопасного хранения ваших личных документов/изображений и видео? Хотя правительство США так считает, исследователь безопасности Ares так не думает.
На самом деле Ares продемонстрировал на своем блоге, почему Knox от Samsung уязвим и довольно легко.
Как уязвим Samsung Knox
Ares предоставил полный PoC о уязвимости на своем блоге, который здесь воспроизводится:
Телефон Samsung поставляется с предустановленными двумя приложениями: Knox и Knox EMM. Knox EMM является облачным решением для управления мобильными устройствами для предприятий, которое не входило в этот анализ. Внимание было сосредоточено на приложении Knox, которое предоставляет контейнер Knox и отдельный (безопасный) домашний экран с собственными приложениями. Настройка Knox довольно проста, вам просто нужно установить пароль и PIN-код для приложения Knox. Изучая внутренности системы, Knox устанавливает довольно много компонентов на ваш телефон. Приложения, связанные с Knox в /data/data/:
com.samsung.klmsagent
com.samsung.knoxemm.mdm
com.sec.knox.app.container
com.sec.knox.containeragent
com.sec.knox.eventsmanager
com.sec.knox.seandroid
com.sec.knox.store Кроме того, все приложения, которые установлены на новом домашнем экране Knox, находятся в стандартной папке установки приложений /data/data/ и имеют префикс: com.sec.. Перечисление всех из них здесь было бы слишком много. После типичной установки Knox установлено 139 приложений и сервисов с префиксом com.sec.* Заглядывая немного глубже в систему, Knox распределен по всей системе и хранит данные в нескольких различных местах, например: зашифрованный контейнер будет храниться в /data/.container_ и/data/container/.sdcontainer_1. Разные файлы и базы данных для настроек хранятся в /data/system/secure_storage и /data/system/container. Каждый анализ мобильного приложения начинается с статического анализа файлов, которые приложение хранило после настройки. Хорошей отправной точкой для Android-приложений является папка приложения в /data/data/. Эти папки обычно имеют следующую структуру: com.aPackageName |- cache |- databases |- extracted |- lib |- shared_prefs Особенно папки databases и shared_prefs заслуживают первого внимания. Приложение ContainerAgent Knox (com.sec.knox.containeragent) имело несколько интересных файлов: Activation.xml ContainerActivator.xml ContainerType.xml CreateSettings.xml DB_BRIDGE_INIT_SYNC.xml DB_BRIDGE_ISCHNDUOS.xml DB_BRIDGE_ONCHANGE_CONTACTS.xml DB_BRIDGE_ONCHANGE_EVENT.xml KLMSLicenseStatus.xml Pref.xml PrivacyPolicy.xml bno.xml com.sec.knox.containeragent_preferences.xml pin.xml Да, угадайте, что написано в файле pin.xml? PIN-код, который мы должны были установить во время настройки Knox в открытом виде! Теперь Samsung Knox дает пользователю максимум 20 попыток для имени пользователя и пароля.*
**
Другие файлы не раскрыли ничего интересного. Но вернемся к файлу pin.xml. Какова цель PIN-кода в Knox? Если вы собираетесь запустить Knox, вам нужно ввести свой пароль, чтобы получить доступ к данным и домашнему экрану Knox. Но есть маленькая кнопка под текстовым полем под названием “Забыли пароль?”. Нажав на нее, вам нужно ввести свой PIN-код. Если PIN-код правильный, приложение Knox покажет вам небольшую подсказку пароля (первый и последний символ вашего пароля!! + оригинальная длина вашего пароля!). Теперь становится довольно очевидно, что Samsung Knox собирается хранить ваш пароль где-то на устройстве! Как упоминалось выше, Knox не только хранит настройки в /data/data/, в папке /data/system/container есть файл с названием containerpassword_1.key [sic!] хранящийся. Содержимое — это зашифрованная строка: 72C9EE6D56CB15916A4CAB01814F978FA1E2689D (я изменил строку по очевидным причинам ;)). Таким образом, это выглядит как строка, зашифрованная с помощью AES. Теперь нам нужно декомпилировать приложения, чтобы глубже понять, как именно работает шифрование пароля и откуда берется ключ для шифрования. Samsung использует предоптимизацию dex, чтобы удалить все файлы classes.dex (java-код хранится в файле с именем classes.dex, и этот файл анализируется виртуальной машиной Dalvik) в apk-файлах Knox, тем самым усложняя реверс-инжиниринг. Чтобы получить бинарные файлы, нам нужно посмотреть в /system/app/ и найти .odex файлы (odex — это, по сути, предварительно обработанная версия классов приложения classes.dex, которая готова к выполнению для Dalvik). Файлы odex можно преобразовать обратно в код smali, который затем можно преобразовать обратно в файл dex. Наконец, файл dex можно преобразовать в файл jar, который можно декомпилировать любым декомпилятором Java. Samsung не использовал никакой обфускации кода, но действительно пытался скрыть код хранения пароля среди сотен классов Java, наследования и прокси. Наконец, в приложении Knox Store был реализован прокси IDataService, который все другие приложения постоянно вызывали при работе с чем-то, связанным с паролем. Таким образом, при сохранении пароля приложение делает следующее:
public boolean setData(String paramAnonymousString) {
this.keyGenInput = DataService.this.mPasswordUtil.getInputForKeyGenerate();
String str = SecureKeyLoader.getKeyForPassword(this.keyGenInput, this.bit_size);
return DataService.this.mEncryptDecrypt.encryptAndSave(paramAnonymousString, str);
}
Давайте посмотрим на каждую строку и соответствующие методы:
public long getInputForKeyGenerate()
{
return Long.parseLong(SecureKeyLoader.getPartialString(getAndroidID()), 16);
}
private String getAndroidID()
{
return Settings.Secure.getString(this.mContext.getContentResolver(), “android_id”);
}
Таким образом, входные данные для ключа, очевидно, являются уникальным идентификатором Android, который есть у каждого устройства. 16-байтный идентификатор, преобразованный в значение Long, затем используется в качестве аргумента для функции getKeyForPassword:
public class SecureKeyLoader
{
static
{
System.loadLibrary(“mealy”);
}
public static native String getKeyForPassword(long paramLong, int paramInt);
public static native String getPartialString(String paramString);
} Хорошо, Samsung все больше и больше обфусцирует, чтобы скрыть реальную генерацию ключа. Метод getKeyForPassword помещен в общую библиотеку на C под названием “mealy”. Давайте извлечем библиотеку с устройства и поместим ее в дизассемблер, такой как IDA:
В бинарном файле есть одна жестко закодированная строка с названием “out_char” со следующим значением: eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv . Изучая код, метод getKeyForPassword получает в качестве аргумента длинное значение getPartialString(getAndroidID()), хранящее в переменной строку out_char и передает оба этих значения в подпрограмму ‘mealymachine’. Давайте взглянем на функцию getKeyForPassword и подпрограмму mealymachine в псевдокоде: function Java_com_sec_knox_store_SecurityManager_SecureKeyLoader_getKeyForPassword { r4 = r0; //partialString androidID as long value r0 = r2; //integer = 16 r0 = mealymachine(r0, var_8, next, “eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B_xf+@h*#S&wpfv”, STK29);* *r3 = *r4;* *r2 = *(r3 + 0x29c);* *r0 = (r2)(r4, r0, r2, r3);* *return r0;* *}* *function mealymachine {* *r6 = r0; //partialString androidID as long value* *r5 = r1; //var_8* *r7 = r2; //next* *r8 = r3; //eu>q5b0KPlLwyb@*#j9?!*ehjl(LHukkA(di^S4UXAChr3B_xf+@h#S&wpfv
if (r1 <= 0x64) {
r4 = 0x0;
memset@PLT(0x2144, 0x0, 0x64);
r1 = r4;
do {
if (r4 >= r5) {
break;
}
r0 = r6 & 0x1;
r6 = r6 >> 0x1;
(int8_t )(r4 + 0x2144) = (int8_t )(r0 + r8 + r1); //AndroidID + eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv + var_8 r4 = r4 + 0x1; r1 = (r0 0x4 + r7 + r1); } while (true); r0 = 0x2144;* (int8_t )(r0 + (r5 & !r5)) = 0x0;
return r0;
}
else {
r0 = 0x0;
return r0;
} return r0; } Изучая подпрограмму, она просто добавляет длинное значение из идентификатора Android и жестко закодированную строку. Метод getPartialString вычитает часть из идентификатора Android. Просто для разъяснения: каждое приложение может запросить у системы идентификатор Android, вызвав: Secure.getString(getContext().getContentResolver(),Secure.ANDROID_ID);*
В заключение Ares указывает на то, что Samsung Knox не так безопасен, как утверждается.
Samsung действительно пытался скрыть функциональность генерации ключа, следуя правилу безопасности за счет неясности. В конце концов, он просто использует идентификатор Android вместе с жестко закодированной строкой и смешивает их для шифрования ключа. Я ожидал от продукта, называемого Knox, другого подхода:
Ключ должен быть получен из функции производной ключа на основе пароля 2 (PBKDF2), которая генерирует гораздо более сильный ключ с большей случайностью.
Тот факт, что они сохраняют ключ только для функции подсказки пароля, полностью компрометирует безопасность этого продукта. Для такого продукта пароль никогда не должен храниться на устройстве. В этом нет необходимости, только если вы забыли свой пароль. Но тогда ваши данные должны быть потеряны, иначе они не безопасны, если есть какая-либо возможность восстановления.
Рекомендация от Ares
Вместо Samsung Knox используйте встроенную функцию шифрования Android и зашифруйте все устройство. Android использует функцию PBKDF2 из выбранного вами пароля шифрования и никогда не сохраняет его на устройстве. Очевидно, вы никогда не сможете получить доступ к данным, если забудете свой пароль, но это и есть суть хорошего шифрования.
*Ресурс: Mobile Security Blog
Get new posts in your inbox
No spam. Unsubscribe anytime.