«Сферический Android в вакууме» — система, которая при выполнении ряда условий и грамотном использовании могла бы стать достаточно безопасной. В реальном же мире производители непременно добавят ложку дёгтя, испортив, казалось бы, непробиваемые защитные механизмы операционной системы. Сегодня мы рассмотрим защитные механизмы Android, призванные обеспечивать доверенную загрузку и защищать данные от злоумышленников – а также ошибки и не совсем ошибки производителей, сводящие пользу от этих механизмов на нет.

Дискуссии на тему безопасности или небезопасности той или иной операционной системы, наверное, будут всегда, но, пожалуй, нигде нет такого разнообразия мнений, как в системе Android. Никто не хочет выпускать «дырявую» ОС; не стал исключением и Android. Действительно, «чистый» Android задумывался как достаточно безопасная система. При этом «безопасная» следует понимать в контексте того или иного временного периода. Так, в 2014 году мало кто из производителей задумывался о необходимости сквозного шифрования данных или двухфакторной аутентификации для защиты данных в облаке. Тем не менее, смартфоны с операционной системой BlackBerry 10, в которых шифрование было опциональным, а двухфакторной аутентификации не появилось по сей день, считались эталоном безопасности. Те же самые смартфоны сегодня безопасными назвать можно с большой натяжкой.

Если говорить о количестве найденных в системе уязвимостей, то число обнаруженных уязвимостей в Android вполне сравнимо с числом уязвимостей ближайшего конкурента – Apple iOS. Принципиальная разница в том, что найденные в iOS уязвимости исправляются в течение нескольких недель, если не дней, а патчи поступают одновременно на весь парк устройств. В то же время в мире Android подавляющее большинство устройств работает на версии ОС двух-трёхлетней давности, а патчи безопасности могут поступать или с большой задержкой, или с очень большой (а для многих устройств – и вовсе никогда).

Тем не менее, если абстрагироваться от грустной реальности и предположить, что смартфоны с Android внезапно получили последние обновления – даже в этом невероятном случае система не станет безопасной. Почему так? Попробуем разобраться. Сегодня мы рассмотрим, о каких именно механизмах безопасности идёт речь, и попробуем натянуть «сферический Android в вакууме» на глобус реального мира, представленный устройствами вполне реальных производителей — Samsung, LG, Motorola и OnePlus.

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

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

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

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

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

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

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

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

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

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

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

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

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

К слову, штатной разблокировки загрузчика для устройств Apple не предусмотрено вовсе, а немногочисленные эксплойты зорко стерегут их разработчики: их поиск может длиться годами, а закрыть обнаруженную уязвимость для Apple – дело одной-двух недель.

Казалось бы, разблокировка загрузчика – очевидный шаг для полицейского, который хочет проанализировать данные в телефоне. Но так может показаться только на первый взгляд. Во-первых, далеко не все производители позволяют разблокировать загрузчик, а те, которые позволяют – разрешают разблокировку не для каждой модели и не для каждой операторской версии. Некоторые производители позволяют официально разблокировать загрузчик только после запроса специального кода с их сайта, а некоторые (например, на устройствах линеек Pixel, Essential PH-1, Razer Phone и т.п.) – одной командой в fastboot. Тем не менее, использовать эту процедуру для извлечения информации не удастся: в процессе разблокирования загрузчика уничтожаются криптографические ключи, с помощью которых зашифрован раздел пользовательских данных.

В теории звучит хорошо, но на практике производители продолжают наступать на одни и те же грабли. Так, довольно свежая модель OnePlus 6 была выпущена с уязвимостью загрузчика, позволявшей загружать произвольный код без всякого разблокирования. Подробности – в нашей статье Уязвимость загрузчика OnePlus 6 невозможно исправить?

Обнаруживались уязвимости и в загрузчиках Motorola (кстати, включая устройство Nexus 6, работавшее на том самом «чистом Android») и Samsung, не говоря о многочисленных телефонах из Китая.

Всё же нормальное поведение заблокированного загрузчика – не допускать выполнения произвольного кода. Единственное, что можно сделать с устройством после снятия блокировки загрузчика – это сбросить его к заводским настройкам и настроить телефон заново. Не хочется сбрасывать? Зашифрованный раздел данных можно скопировать, но расшифровать его не удастся никакими средствами.

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

Допустим, специалисту каким-то образом удалось обойти блокировку загрузчика или в его руки попал телефон с уже разблокированным загрузчиком. Теперь можно запустить 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 способен вполне эффективно воспрепятствовать загрузке стороннего кода и извлечению данных.

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

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

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

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

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

Дальше запускаем любую программу с поддержкой данного режима (например, «Мобильный криминалист» компании Oxygen), выбираем из списка доступных методов «Смартфоны LG» и жмём кнопку. Теперь достаточно просто подождать, и на компьютере образуется полная копия данных пользователя. Обратите внимание: нам даже не пришлось загружать систему! Извлечение через сервисный режим не оставляет следов, и вообще – «чистая работа».

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

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

Шифрование

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

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

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

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

iOS побеждена? Почти, но не совсем. Дело в том, что в большинстве устройств на Android до сих пор используется устаревшая схема шифрования Full Disk Encryption, или FDE. (Сейчас мы говорим исключительно о блочном шифровании раздела данных; более современную схему File-Based Encryption – FBE – мы обсудим отдельно).

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

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

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

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

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

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

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

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

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

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

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

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

Загрузчики, FRP, шифрование… Оказалось, что все эти вещи можно обойти буквально в пару кликов, если использовать уязвимость загрузчика. Существуют самые разнообразные методы, самым, пожалуй, продвинутым из которых является метод «расшифровывающего загрузчика» (decrypting EDL), разработанный компанией Cellebrite. При помощи данного метода можно получить полный доступ к содержимому устройств, работающих на ряде распространённых наборов системной логики от Qualcomm. Всё, что требуется – это соответствующее программное обеспечение, телефон с совместимым чипсетом и способ перевода телефона в режим EDL. Последнее может быть как тривиальным («провод с кнопкой»: выключить телефон, подключить к проводу, нажать кнопку, подключить телефон к компьютеру, отпустить кнопку), так и сложным (тест-пойнты на плате телефона, которые нужно замкнуть).

Метод извлечения данных через EDL достаточно универсален и поддерживает множество устройств, но работает он только тогда, когда используется шифрование FDE, а режим Secure Startup не включен.

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

Ирония в том, что уязвимость была обнаружена в Nexus 6 – устройстве, произведённом Motorola во времена, когда компания являлась собственностью Google.

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

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

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

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

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

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

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

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

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

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

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

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

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

«Samsung гордится своими комплексными решениями, которые обеспечивают полную защиту пользовательских данных и приложений», говорят [http://mobile-review.com/news/samsung-knox-poluchila-vysshij-rejting-v-otchete-gartner-bezopasnost-mobilnyx-ustrojstv-sravnenie-platform] они в пресс-релизе, рекламирующем систему безопасности KNOX. Впрочем, никакая гордость не помешала компании разработать инженерный загрузчик, позволяющий прошивать и как угодно модифицировать устройство в обход всех предохранителей KNOX, а фактическое (а не громогласно-рекламное) отношение к безопасности – позволить этому инженерному загрузчику утечь в свободное плаванье и не озаботиться отзывом электронной подписи скомпрометированного загрузчика.

Заключение

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