Доступ разрешен. Изучаем баги LG, Samsung и Motorola, позволяющие снять данные с зашифрованного смартфона

Сегодня мы разберемся, о каких именно механизмах безопасности идет речь, и попробуем натянуть «сферический Android в вакууме» на глобус реального мира, представленный устройствами таких производителей, как Samsung, LG и Motorola (Lenovo).

Помимо технических, мы рассмотрим и политические аспекты защиты твоей информации в реальных устройствах. Если Apple не постеснялась судиться с государством за право не разрабатывать версию системы, которая могла бы использоваться спецслужбами для доступа к твоим данным, то как с этим обстоят дела у ближайшего конкурента — компании Samsung? (Спойлер: с точностью до наоборот.)

Но начнем мы все же с технологий.

Android и доступ к данным

Как я уже описывал в одной из статей, у безопасности мобильных устройств множество аспектов. Здесь и безопасность хранения данных, и устойчивость к взлому с помощью физических атак, и защита от кражи, и разнообразные песочницы для приложений, ограничивающие их возможность незаметно следить за тобой, собирать и передавать информацию, и многое другое. Сегодня мы остановимся только на одном аспекте, а именно — устойчивости устройств к физическим атакам, с помощью которых злоумышленник, спецслужбы или органы охраны правопорядка могут попытаться извлечь из него твои данные.

С каждым поколением устройств и с каждой новой версией мобильных ОС смартфоны становятся все более безопасными. И это не иллюзия: и Apple, и Google прикладывают все усилия, чтобы свести к минимуму возможности неавторизованного доступа к информации. Разумеется, все их действия совершаются в рамках ограничений, заданных как самой платформой, так и конкретными устройствами на ее основе.

Давай рассмотрим некоторые из этих механизмов и то, как они способствуют защите от несанкционированного доступа.

Блокировка загрузчика

Прежде чем вдаваться в детали реализации шифрования, немного поговорим о встроенных в Android механизмах, которые призваны защитить твои данные от неразрушающих способов извлечения. Для нас представляют интерес три вещи: блокировка загрузчика (а точнее, все механизмы, способные предотвратить запуск неподписанного кода), шифрование раздела данных и пароль, который может быть установлен на смартфон.

В Android загрузчик (bootloader) — это первый код, который загружается со встроенного в телефон накопителя. Именно загрузчик содержит механизмы, с помощью которых устройство может проверить цифровую подпись и целостность загрузочного раздела, и именно загрузчик несет ответственность за загрузку телефона в систему или один из вспомогательных режимов fastboot или recovery.

Во время загрузки операционной системы загрузчик выполняет инструкции, которые передают управление ядру, записанному в раздел boot. Поскольку загрузчик — это первое, что запускается на смартфоне, именно он принимает решение о том, какой именно код будет выполняться, а какой — нет. Соответственно, защита (блокировка) загрузчика — важный элемент обеспечения безопасности цепочки загрузки.

Итак, загрузчик запускается прежде всех остальных компонентов операционной системы. Он проверяет целостность ядра, а также — если загрузчик заблокирован — аутентичность его цифровой подписи. (Разблокированный загрузчик все равно проверяет целостность и цифровую подпись ядра; просто подписать ядро можно будет не только производителю, но и сторонним разработчикам.) Если следующий компонент загрузки не проходит проверку целостности или безопасности, загрузка прервется, а пользователю будет выведено соответствующее уведомление (особенно жестко этот момент контролируется в версиях Android начиная с 7.0).

Если загрузчик заблокирован, пользователь не сможет вносить изменения в системные и загрузочные разделы, а также не сможет загрузить устройство командой fastboot boot xxx.img с помощью неподписанного образа (например, в стороннее recovery — TWRP и подобные).

Если же загрузчик разблокирован, то тебе будет доступно большинство команд из арсенала fastboot. В частности, ты сможешь загрузить устройство с использованием стороннего образа, модифицировать ядро системы или системный раздел. Именно поэтому разблокирование загрузчика — первое, что проделывают со своими устройствами разработчики и хакеры.

Казалось бы, разблокировка загрузчика — очевидный шаг для полицейского, который хочет покопаться в твоем телефоне. Но так может показаться только на первый взгляд. Во-первых, далеко не все производители позволяют разблокировать загрузчик, а те, которые позволяют, разрешают разблокировку не для каждой модели и не для каждой операторской версии. Некоторые производители предоставляют возможность официально разблокировать загрузчик только после запроса специального кода с их сайта, а некоторые (например, на устройствах линеек Nexus и Pixel, Nextbit Robin) — одной командой в fastboot.

Тем не менее использовать эту процедуру для извлечения информации не удастся: при разблокировании загрузчика уничтожаются криптографические ключи, с помощью которых зашифрован раздел пользовательских данных, и происходит сброс до заводских настроек. Не хочешь сбрасывать? Зашифрованный раздел данных ты сможешь скопировать, но расшифровать его не удастся никакими средствами.

Защита от сброса к заводским настройкам

Допустим, тебе каким-то образом удалось обойти блокировку загрузчика (что само по себе маловероятно) или в твои руки попал телефон с уже разблокированным загрузчиком. Теперь-то можно запустить TWRP и скопировать раздел данных? Скорее да, чем нет, но не всегда и не на всех устройствах. В Android предусмотрен дополнительный механизм защиты — как раз для таких случаев.

Независимо от того, заблокирован или разблокирован загрузчик устройства, в большинстве моделей Samsung и Motorola есть еще одно неочевидное препятствие на пути доступа к информации.

С выходом Android 5.1 разработчики Google добавили механизм, направленный на предотвращение доступа к данным и сброса устройства к заводским настройкам в случае его кражи. Основное предназначение защиты от сброса к заводским настройкам (Factory Reset Protection, FRP) не в том, чтобы защитить устройство от сброса как такового, а в том, чтобы сделать его бесполезным для злоумышленников, предотвратив возможность его активации и использования после сброса.

При активированной защите FRP злоумышленник может удалить данные и сбросить устройство, но (по крайней мере в теории — на самом деле способов обойти эту защиту существует порядочно) воспользоваться им не сможет: система начальной настройки потребует ввести учетные данные того Google Account, который использовался перед сбросом устройства.

FRP активируется автоматически во время настройки устройства при выполнении двух условий: 1) используется безопасный экран блокировки: устройство защищено PIN-кодом, паролем, паттерном или другим способом; 2) пользователь добавляет хотя бы одну учетную запись Google Account. Соответственно, при выключении безопасного экрана блокировки или при удалении учетной записи Google из настроек устройства защита FRP так же автоматически отключается.

Итак, защита от сброса к заводским настройкам — отлично задуманная (но плохо реализованная) система. Но при чем тут она? Дело в том, что ряд производителей (в частности, Samsung и Motorola) пошли чуть дальше, реализовав дополнительный защитный механизм именно через систему FRP.

Что произойдет, если злоумышленник загрузит устройство в стороннее recovery и попросту обнулит раздел frp? Или же установит прошивку без приложений Google, обойдя таким образом защиту от кражи? С разблокированным загрузчиком это вполне возможно.

Именно для защиты от подобных сценариев используется дополнительная проверка. При активированной защите от сброса к заводским настройкам FRP устройство всегда будет вести себя так, будто его загрузчик заблокирован, — даже если была произведена процедура разблокировки. Загрузить неподписанный код (стороннее recovery или прошивку) не получится.

Таким образом, даже если загрузчик смартфона разблокирован (напомним, большинство пользователей этого не делает), его все равно не удастся загрузить в стороннее recovery, если:

• в устройстве до сброса была настроена учетная запись Google Account;
• был настроен безопасный экран блокировки (пароль, паттерн и подобное).

Совместно с защитой, предоставляемой блокировкой загрузчика, FRP способен вполне эффективно воспрепятствовать загрузке стороннего кода и извлечению данных.

Извлекаем данные из устройств с заблокированным загрузчиком

Итак, способ с официальной разблокировкой загрузчика нам не подходит: при разблокировании как криптографические ключи, так и сами данные уничтожаются. Даже в том маловероятном случае, если бы удалось разблокировать устройство без потери данных, механизм защиты от сброса к заводским настройкам может помешать запуску неподписанного загрузочного образа.

В теории — в том самом «сферическом Android в вакууме» — все хорошо: система безопасна, враг не пройдет. А вот на практике… На практике бывает разное.

Возьмем, например, смартфоны LG. Производитель предусмотрел в них чрезвычайно удобный сервисный режим, изначально предназначенный для обновления прошивки. Однако, в отличие от сервисного режима DFU в iPhone, реализация протокола LAF допускает двустороннюю коммуникацию. Соответственно, ты можешь легко и изящно воткнуть практически любой телефон производства LG независимо от чипсета, версии Android и тому подобной мишуры, запустить приложение и нажать кнопку. Спустя десять-пятнадцать минут у тебя на компьютере будет полная копия всех разделов устройства.

Сам процесс предельно прост. Для начала потребуется перевести смартфон LG в режим LAF, для чего нужно выключить телефон, зажать кнопку «Громкость+» и подключить устройство к компьютеру. Телефон при этом будет выглядеть как-то так:

Дальше запускаем любую программу с поддержкой данного режима (например, Oxygen Forensic Suite), выбираем из списка доступных методов «Смартфоны LG» и жмем кнопку. Спустя несколько окошек с инструкциями, которые мы пропустим, на экране компьютера появится что-то в таком роде:

Теперь достаточно просто подождать, и у тебя образуется полная копия данных пользователя. Обрати внимание: нам даже не пришлось загружать систему! Извлечение через сервисный режим не оставляет следов и вообще — «чистая работа».

А что насчет других устройств, тех, что не LG? Для многих из них есть подобные сервисные режимы. Для смартфонов с чипсетами MediaTek это небезызвестный SP Flash Tool, для телефонов на Qualcomm — режим 9008, который также открывает низкоуровневый доступ к данным (впрочем, его использование требует дополнительных телодвижений и некоторых файлов, не всегда доступных широкой публике).

У тебя не возникло мысли, что все это как-то… чересчур просто? Ты совершенно прав: все эти методы прекрасно работали (и продолжают работать!) на устройствах, выпущенных с Android до версии 5.1.1 включительно, даже если эти устройства потом обновились до 6-й или 7-й версии системы. А вот для свежих устройств, которые были выпущены с Android 6.0 на борту, этот подход уже не сработает. Точнее, сработает лишь частично: данные мы скопируем, но столкнемся с тем, что они окажутся зашифрованы.

Шифрование

Шифрование сложным, неизвлекаемым ключом — основной и главный метод защиты данных. В конце концов, телефон, даже нерабочий, всегда можно разобрать, чип памяти — извлечь и считать с помощью недорогого адаптера. В таких сценариях только и исключительно шифрование способно защитить информацию.

Шифрование было доступно пользователям Android на самых ранних этапах становления системы, но во что-то более-менее безопасное этот механизм превратился лишь совсем недавно. Вплоть до версии 6.0 шифрование раздела данных оставлялось на откуп пользователю; чтобы его включить, тебе пришлось бы зайти в настройки и вручную активировать соответствующую опцию. Как думаешь, какой процент пользователей это делал? Добавлю, что даже на таких смартфонах, как Nexus 6, который должен был показать, что защита данных — это совсем не страшно, шифрование серьезнейшим образом тормозило работу устройства. В результате шифрование включали лишь отдельные параноики и жертвы корпоративных политик безопасности.

Ситуация стала изменяться с выходом шестой версии Android и массовым распространением устройств на 64-битных чипсетах ARM, в наборе команд которых (ARMv8) присутствуют расширения для аппаратного ускорения криптографических операций. Теперь производители, выпускающие устройства с Android 6.0 (и более новых версий) на борту, должны активировать шифрование по умолчанию — иначе смартфон не пройдет сертификацию и не сможет получить доступ к Play Store и другим сервисам Google.

Да, здесь есть своя ложка дегтя: старые устройства, которые обновляются до Android 6, а также весь несертифицированный Китай продолжают обходиться без шифрования. Однако в целом о твоей безопасности позаботились: покупая новое устройство в магазине, ты получаешь шифрование, работающее, что называется, из коробки.

Ну что — iOS грустно курит в сторонке? Ну… почти. Дело в том, что начиная с версии 7.0 Android поддерживает два механизма шифрования накопителя: FDE (Full-disk encryption, полнодисковое шифрование) и FBE (File-based encryption, пофайловое шифрование). Второй метод более совершенный, но многие производители по-прежнему продолжают использовать схему FDE либо по привычке, либо просто из-за отсутствия возможности использовать FBE. А это приводит к ряду проблем.

Полнодисковое шифрование

Если помнишь, в iOS используется продвинутая многослойная система шифрования. На блочном уровне (а есть еще и отдельное дополнительное шифрование для некоторых категорий данных!) система использует уникальные криптографические ключи, чтобы защитить каждый блок данных по отдельности. При удалении файла и освобождении блоков данных на диске соответствующие им ключи удаляются, что делает совершенно невозможным восстановление информации из таких блоков.

Полнодисковое шифрование в Android устроено намного проще. Криптографический ключ один на весь раздел; на уровне системы никакой дополнительной защиты для отдельных типов данных (см. понятие «связка ключей» в iOS) не предусмотрено.

Но и это еще не все! Так, если пользователь iOS установил на свой iPhone пароль или PIN-код (а его приходится установить, чтобы активировать датчик отпечатков пальцев Touch ID), то криптографический ключ будет генерироваться на лету в процессе загрузки устройства на основе как данных из Secure Enclave, так и собственно пароля, введенного пользователем.

При полнодисковом шифровании действует совсем другая схема. Если пользователь не включит режим «Запрашивать пароль при загрузке устройства», то раздел данных будет зашифрован ключом, который создается на основе фиксированного пароля default_password и криптографических данных, которые хранятся в защищенной среде Trusted Execution Environment (TEE).

Еще раз, помедленнее. Ты можешь вводить сколь угодно длинный пароль, но ключ для шифрования всех твоих данных будет основан на фразе default_password и данных из TEE.

Использование фразы default_password вместо PIN-кода или пароля пользователя позволяет Android полностью загрузить систему и запустить приложения еще до того, как ты разблокируешь смартфон. Сейчас не будем о том, зачем это сделано именно так; теории, что телефоны на Android склонны к самопроизвольным перезагрузкам, а iPhone — нет, мы отметем как несостоятельные. Просто констатируем, что, с одной стороны, такая схема удобна; с другой — значительно менее безопасна, если сравнивать с подходом Apple или обязательным использованием пароля для загрузки устройства. В конце концов, никто не мешает тебе пожертвовать толикой удобства и включить тот самый режим «Запрашивать пароль при загрузке устройства». Тем не менее даже такой защиты «паролем по умолчанию» уже достаточно для того, чтобы низкоуровневое извлечение данных (например, с прямым доступом к микросхеме памяти) не сработало: раздел данных останется зашифрованным, а необходимые для генерации ключа шифрования данные невозможно будет извлечь из модуля TEE.

Если же ты включишь режим безопасной загрузки (Secure start-up) и опцию «Запрашивать пароль при загрузке устройства», то ключ шифрования будет генерироваться каждый раз при загрузке устройства на основе как данных из TEE, так и того пароля, который введет пользователь. Телефон не сможет продолжить загрузку, а данные не будут расшифрованы до тех пор, пока пользователь не укажет правильный пароль.

В целом такая схема работает против прямолинейных атак стандартными методами. Но…

Что-то пошло не так

После того как Google ввела практику обязательного неотключаемого шифрования раздела данных, многие пользователи стали думать (если они вообще об этом задумывались), что их смартфоны с Android по безопасности совсем как iPhone. Неотключаемое аппаратное шифрование, корректно используемые датчики отпечатков пальцев, заблокированные загрузчики, защита от кражи и сброса к заводским настройкам — галочки можно поставить напротив каждого пункта. Казалось бы, что может пойти не так?

«Не так» начинается в тот момент, когда мы спускаемся с небес на землю и вместо абстрактного «чистого Android» начинаем рассматривать реально существующие устройства. Специально для тех, кто считает, что «надо брать Nexus/Pixel и прочие гуглофоны», ремарка: описанный ниже метод был разработан на основе уязвимости, обнаруженной именно в смартфоне от Google — Nexus 6 и исправленной лишь в июле 2017 года.

Что-то пошло не так, часть первая: Motorola

Загрузчики, FRP, шифрование… Оказалось, что все эти вещи можно обойти буквально в пару кликов, если использовать метод, разработанный Oxygen и встроенный в софт для полицейских «Мобильный криминалист». Как обнаружилось, в подавляющем большинстве устройств, выпущенных под маркой Motorola как во времена бытности ее независимой компанией, так и под крылом сперва Google, а потом и Lenovo, присутствует критическая уязвимость на уровне загрузчика. Уязвимости подвержены практически все устройства Motorola, выпущенные в период с 2013 по 2017 год. Метод действует независимо от версии Android, блокировки загрузчика и статуса FRP. Уязвимость была исправлена лишь в тех устройствах, которые работают под управлением последних версий Android с июльским патчем безопасности (к слову, его получили лишь самые свежие модели Motorola и некоторые флагманы).

Работает это так. Для каждого конкретного устройства с помощью приложения (то есть в автоматическом режиме) создается уникальный загрузчик, который загружается в оперативную память устройства и получает управление. Телефон при этом выглядит так:

На компьютере будет сначала так:

А потом так:

Дальнейшее — вопрос техники: загруженный в память устройства код выполняет все команды, с помощью которых из телефона извлекаются как собственно данные пользователя, так и, с некоторыми оговорками, ключи шифрования. Защищенные данные расшифровываются на лету. Метод опробован на большом количестве разнообразных моделей (испытано лично); он работает даже для устройств с заблокированным загрузчиком и активированной защитой FRP.

О каких оговорках идет речь? Дело в том, что ключи шифрования возможно извлечь не всегда. Так, для устройств, оборудованных аппаратным модулем TEE, ключ шифрования можно извлечь, только если пользователь не установил безопасный экран блокировки (пароль или паттерн) или пароль разблокировки известен. А если нет? Можно попробовать подобрать; принципиальных ограничений здесь нет, но перебор возможен только на самом смартфоне, а после ряда неудачных попыток TEE начнет увеличивать задержку между попытками на аппаратном уровне, так что перебор будет очень и очень медленным.

Следовательно, не все так страшно? Возможно, особенно если на твою «Моторолу» прилетел июльский патч безопасности или у тебя современное устройство с TEE и установлен длинный и сложный пароль. Но подожди, у нас же остался лидер смартфоностроения — Samsung! Давай посмотрим, как обстоят дела с его прошлогодним флагманом — Samsung Galaxy S7.

Что-то пошло не так, часть вторая: Samsung Galaxy S7

В случае с Motorola нам может помешать наличие пароля устройства. Да, его можно перебирать, но это долго, медленно и скучно. Но погоди, зачем пароль, если шифрование (по крайней мере в режиме «по умолчанию») от него никак не зависит? Здесь в дело вступает такая штука, как TEE, который согласен исполнять (в нашем случае — с целью расшифровки раздела данных) исключительно доверенные микропрограммы, подписанные производителем. В случае со смартфонами Motorola софт от «Оксиджен» эксплуатирует уязвимость на уровне загрузчика, позволяя обойти стандартные механизмы защиты от выполнения произвольного кода во время загрузки смартфона, то есть на уровне системы. А вот на модуль TEE эта уязвимость никак не распространяется, и сопроцессор не выдаст криптографический ключ, если код не подписан непосредственно производителем.

А что, если сам производитель создаст и подпишет своей криптографической подписью код, который полезет в TEE и вытащит оттуда ключи? «Фантастика», — скажешь ты. «Паранойя», — хмыкнешь ты. «Очередная теория заговора?» — спросишь ты. И будешь не прав. Встречайте: уважаемая компания Samsung, номер один по продажам устройств на Android, не просто написала (и подписала) такой код, но и позволила ему утечь в интернет. Почему-то про это не трубили во всех газетах (а ведь каждый джейлбрейк каждой мелкой подверсии iOS широко освещается соответствующими СМИ), но факт остается фактом: инженерный загрузчик был создан Samsung, подписан Samsung, украден у Samsung и выложен в Сеть на всеобщее обозрение.

Что это означает на практике? Всего лишь то, что теперь можно загрузить смартфон в инженерный загрузчик и сбросить пароль блокировки устройства. Вот просто так — взять и сбросить. И все? Нет, не все: инженерный загрузчик позволяет получить права суперпользователя, установив root в систему. Дальнейшие шаги тривиальны: смартфон загружается в систему, раздел данных успешно расшифровывается, и при помощи root-доступа снимается полный расшифрованный образ файловой системы.

Посмотрим на процесс внимательнее.

Что тебе понадобится? Джентльменский набор:

1. Модифицированная версия инструмента Samsung Odin Downloader Tool: Odin3 v3.12 (PrinceComsy).zip.
2. Инженерный загрузчик G891A_7.0_ENG_ROOT.tar.
3. Скрипт для установки root: Nougat_S7aRoot_2.82_V2.zip.

Процесс пошел:

1. Загружаем устройство в recovery: зажми кнопки Vol+ и Home, после чего зажми Power. Удерживай все три кнопки, пока экран не мигнет и на нем не появится лого. В этот момент отпусти кнопки.
2. Запускаем Odin modified v.3.12 by PrinceComsy.
3. Прошиваем инженерный загрузчик из архива G891A_7.0_ENG_ROOT.tar (не распаковывая), выбрав только опцию AP и указав в ней путь к архиву.
4. На этом этапе пароль устройства будет сброшен и ты сможешь загрузить систему и активировать режим разработчика в настройках (это необходимо, чтобы заработал ADB, если он не работает).
5. Распакуй Nougat_S7aRoot_2.82_V2.zip и запусти root.bat.

На данном этапе ты успешно сбросил пароль устройства и получил root-доступ и доступ к ADB. У тебя есть полный доступ к файловой системе (обрати внимание, уже расшифрованной файловой системе!). Скопировать данные на компьютер теперь можно с помощью любой подходящей программы — от «Мобильного криминалиста» до простого ADB.

Пароли? Шифрование? Нет, не слышали. Безопасность? Samsung любит поговорить о безопасности, но по факту их решения, мягко говоря, неоднозначны. Так, операционная система Tizen не выдерживает критического взгляда. Процитирую слова Амихая Нейдермана: «Возможно, это худший код из тех, что мне довелось видеть. Все ошибки, которые можно было допустить, были допущены. Очевидно, что код писал или проверял кто-то, кто ничего не понимает в безопасности. Это все равно, что попросить школьника написать для вас программное обеспечение».

Почему это работает и чем отличается от уязвимости Motorola?

Важный момент здесь в том, что инженерный загрузчик создан силами самой компании Samsung и подписан электронной подписью, которой доверяет устройство. С точки зрения телефона процесс доверенной загрузки не нарушается, ведь загружается только и исключительно код, подписанный производителем. А вот для Motorola это не так: хоть разработчики и обошли защиту загрузчика, удалось это проделать лишь с использованием найденной уязвимости, которую Motorola успешно закрыла в патче безопасности за июль 2017-го. А вот инженерный загрузчик Samsung никто не собирается ни патчить, ни закрывать, ни отзывать скомпрометированную электронную подпись (вообще-то именно это должна была в первую очередь сделать компания, которая действительно — а не на словах — беспокоится о безопасности).

Вопрос политики: Apple против Samsung или все против ФБР?

Казалось бы, при чем тут Apple? Давай отмотаем время на полтора года назад и вспомним, как действовала компания в момент, когда ФБР и вставший на сторону агентства американский суд потребовали от Apple создать инструмент (аналог инженерного загрузчика), позволивший бы спецслужбам подобрать пароль на принадлежавшем террористу из Сан-Бернардино iPhone 5c.

Весной 2016 года Apple не подчинилась требованиям Федерального бюро расследований и не стала создавать код с возможностью подбора пароля для разблокировки смартфона. Проблема защиты информации переросла в глобальную; на сторону Apple встали такие монстры индустрии, как Google, Facebook и Microsoft. В конечном итоге в ФБР справились без помощи Apple, заплатив около миллиона долларов израильской компании Cellebrite за взлом единственного устройства.

Интересно здесь не только то, как рьяно компания Apple ринулась отстаивать права своих пользователей на защиту информации в устройствах с iOS, но и то, к каким последствиям это привело. А последствия заметные: в Apple предпринимают шаги, всячески ограничивающие возможности произвола со стороны полиции и спецслужб в отношении пользователей. Так, вскоре после известных событий компания добавила ряд условий, при совпадении которых автоматически отключался датчик отпечатков пальцев, а смартфон требовал разблокировку паролем. Весьма радикально компания поступила с выпуском iOS 11, в которой ограничили возможность использовать излюбленный полицейскими метод извлечь данные из телефонов — с помощью создания резервной копии. Что интересно, в Apple ни словом не обмолвились о таких нововведениях в iOS 11.

А вот компания Samsung любит поговорить о безопасности. «Samsung гордится своими комплексными решениями, которые обеспечивают полную защиту пользовательских данных и приложений», — пишут они в пресс-релизе, рекламирующем систему безопасности KNOX. Впрочем, никакая гордость не помешала компании разработать инженерный загрузчик, позволяющий прошивать и как угодно модифицировать устройство в обход всех предохранителей KNOX, а фактическое (а не громогласно-рекламное) отношение к безопасности — позволить этому инженерному загрузчику утечь в свободное плаванье и не озаботиться отзывом электронной подписи скомпрометированного загрузчика.

Заключение

Четыре производителя — и четыре разных подхода к безопасности. Режим прямого доступа к хранилищу у LG, не позволяющий тем не менее обойти шифрование; взлом загрузчика целой линейки устройств Motorola, позволяющий обходить шифрование, но закрытый компанией с июльским патчем безопасности; инженерный загрузчик Samsung, словно специально разработанный для того, чтобы кто угодно мог получить полный доступ к зашифрованным данным; и Apple, все ужесточающая фактическую безопасность устройств без особого шума. Насколько важна безопасность данных лично тебе? Думаю, от ответа на этот вопрос может зависеть выбор твоего следующего смартфона.

Источник — xakep.ru