Содержание статьи
ФБР попыталось через суд выкрутить руки компании Apple, не желающей создавать код для обхода собственной системы безопасности. Обнаружена критическая уязвимость в ядре Android, позволяющая получить доступ суперпользователя в обход всех защитных механизмов. Эти два события хоть и не связаны между собой, но совпали по времени, явным образом демонстрируя различия в системе безопасности двух популярных мобильных ОС. Отложим на минуту вопрос с критической уязвимостью ядра Android, которая вряд ли будет когда-либо исправлена большинством производителей в уже выпущенных моделях, и рассмотрим механизмы шифрования данных в Android и Apple iOS. Но прежде поговорим, зачем вообще нужно шифрование в мобильных устройствах.
Зачем шифровать телефон?
Честному человеку скрывать нечего — популярнейшей лейтмотив, который звучит после каждой публикации на тему защиты данных. «Мне скрывать нечего», — говорят многие пользователи. Увы, но гораздо чаще под этим подразумевается всего лишь уверенность в том, что уж в данные конкретного Васи Пупкина никто не потрудится залезть, ибо кому они вообще интересны? Практика показывает, что это не так. Далеко ходить не станем: буквально на прошлой неделе увольнением завершилась карьера школьной учительницы, которая на минутку оставила телефон на столе. Ученики мгновенно разблокировали аппарат и извлекли из него фотографии учительницы в виде, который осуждается пуританской моралью американского общества. Инцидент послужил достаточным основанием для увольнения учительницы. Подобные истории происходят чуть ли не ежедневно.
Как взламываются незашифрованные телефоны
Не будем углубляться в детали, просто имей в виду: данные с незашифрованного телефона можно извлечь почти в ста процентах случаев. «Почти» здесь относится скорее к случаям, когда телефон попытались физически повредить или уничтожить непосредственно перед снятием данных. Во многих устройствах Android и Windows Phone есть сервисный режим, позволяющий слить все данные из памяти аппарата через обычный USB-кабель. Это касается большинства устройств на платформе Qualcomm (режим HS-USB, работающий даже тогда, когда загрузчик заблокирован), на китайских смартфонах с процессорами MediaTek (MTK), Spreadtrum и Allwinner (если разблокирован загрузчик), а также всех смартфонов производства LG (там вообще удобный сервисный режим, позволяющий слить данные даже с «окирпиченного» устройства).
Но даже если в телефоне и нет сервисного «черного хода», данные из устройства все равно можно получить, разобрав аппарат и подключившись к тестовому порту JTAG. В самых запущенных случаях из устройства извлекается чип eMMC, который вставляется в простейший и очень дешевый адаптер и работает по тому же протоколу, что и самая обычная SD-карта. Если данные не были зашифрованы, из телефона легко извлекается вообще все вплоть до маркеров аутентификации, предоставляющих доступ к твоим облачным хранилищам.
А если шифрование было включено? В старых версиях Android (до 4.4 включительно) и это можно было обойти (за исключением, правда, аппаратов производства Samsung). А вот в Android 5.0 наконец появился режим стойкого шифрования. Но так ли он полезен, как полагает Google? Попробуем разобраться.
Android 5.0–6.0
Первым устройством под управлением Android 5.0 стал Google Nexus 6, выпущенный в 2014 году компанией Motorola. В то время уже активно продвигались 64-разрядные мобильные процессоры с архитектурой ARMv8, но у компании Qualcomm не было готового решения на этой платформе. В результате в Nexus 6 был использован набор системной логики Snapdragon 805, основанный на 32-разрядных ядрах собственной разработки Qualcomm.
Почему это важно? Дело в том, что в процессоры на архитектуре ARMv8 встроен набор команд для ускорения потокового шифрования данных, а в 32-битных процессорах ARMv7 таких команд нет.
Итак, следи за руками. Инструкций для ускорения крипто в процессоре нет, поэтому Qualcomm встроил в набор системной логики выделенный аппаратный модуль, призванный выполнять те же функции. Но что-то у Google не сложилось. То ли драйверы на момент выпуска не допилили, то ли Qualcomm не предоставил исходные коды (или не разрешил публиковать их в AOSP). Детали публике неизвестны, но известен результат: Nexus 6 шокировал обозревателей чрезвычайно медленной скоростью чтения данных. Насколько медленной? Примерно вот так:
Xakep #207. Дистанционное банковское ограбление
Причина восьмикратного отставания от «младшего брата», смартфона Motorola Moto X 2014, проста: насильно включенное шифрование, реализованное компанией на программном уровне. В реальной жизни пользователи Nexus 6 на оригинальной версии прошивки жаловались на многочисленные лаги и фризы, заметный нагрев устройства и относительно слабую автономность. Установка ядра, отключающего насильственно активированное шифрование, разом решала эти проблемы.
Впрочем, прошивка — дело такое, ее ведь можно и допилить, не так ли? Особенно если ты Google, располагаешь неограниченными финансами и имеешь в штате самых квалифицированных разработчиков. Что ж, посмотрим, что было дальше.
А потом был Android 5.1 (спустя полгода), в котором нужные драйверы для работы с аппаратным ускорителем сначала добавили в предварительной версии прошивки, а потом снова убрали в финальной из-за серьезных проблем со спящим режимом. Потом был Android 6.0, на момент выхода которого пользователи уже успели потерять интерес к этой игре и стали любыми способами отключать шифрование, пользуясь сторонними ядрами. Или не отключать, если скорости чтения в 25–30 Мбайт/с достаточно.
Android 7.0
Хорошо, но уж в Android 7 можно было исправить серьезную проблему флагманского устройства, которой уже почти два года? Можно, и ее исправили! В лаборатории «Элкомсофт» сравнили производительность двух идентичных Nexus 6, на одном из которых была установлена версия Android 6.0.1 с ядром ElementalX (и отключенным шифрованием), в то время как второе работало под управлением первой предварительной версии Android 7 с настройками по умолчанию (шифрование включено). Результат налицо:
Несмотря на тестовый статус сборки, что-то в этой версии явно подкрутили. Скорость последовательного чтения данных с зашифрованного раздела подросла с жалких 25 Мбайт/с до чуть менее жалких 39. Почему «жалких»? Даже если сравнивать со скоростью работы аналогичного устройства с выключенным шифрованием в 126 Мбайт/с, получается трехкратное падение производительности. А если сравнить со стареньким, 2013 года iPhone 5S под управлением iOS? Обратимся к AnandTech:
Разница в скорости чтения данных с зашифрованного Nexus 6 и зашифрованного iPhone 5S — пять раз. Вопрос можно закрывать.
С Nexus 6 что-то не так
Устройства линейки Nexus интересны в первую очередь тем, что прошивки для них доступны в виде исходных кодов и могут быть исследованы и модифицированы независимыми разработчиками. Один из них сумел активировать аппаратный ускоритель шифрования в Nexus 6. Результат... обескураживающий. Даже с активированным криптосопроцессором Nexus 6 демонстрирует чрезвычайно низкий результат:
Что ж, давай посмотрим, как обстоят дела с шифрованием в других устройствах компании Google.
В новых устройствах шифрование починили!
С выходом в свет Android 6.0 в Google таки прописали требование активировать шифрование в 64-битных устройствах, выпущенных с Android 6 на борту (требование не распространяется на аппараты, которые до Android 6 обновились). Таких устройств пока выпущено немного, так что делать вывод о том, приняли ли производители к сведению это требование, пока рано.
Очевидно, компанию Google не вдохновили лавры Apple, не устроил выделенный модуль ускорения крипто в топовом чипсете Qualcomm — или просто не сложилось. Срочно понадобилось что-то новое. Не хватало, казалось, только набора команд ускорения крипто, которые появились в ARMv8.
Итак, выходят 64-битные Nexus 5x и 6P, базирующиеся на чипсетах Snapdragon 808 и 810 соответственно. Так же как и Snapdragon 805, эти наборы системной логики оснащены высокопроизводительными выделенными модулями аппаратного ускорения шифрования. И так же, как и в Nexus 6, разработчики из Google не смогли (или не захотели) использовать эти модули. Виноград оказался настолько зеленым и кислым, что начальник отдела разработки официально заявил: «Мы использовали программное ускорение шифрования, а именно — набор команд ARMv8, который обеспечивает более высокую производительность в сравнении с аппаратным ускорителем AES, встроенным в SoC».
Что же такое это «программное ускорение» и почему оно «лучше», чем использование выделенного модуля? В 64-разрядных процессорах (непосредственно в основных ядрах, а не в выделенном модуле, наличие которого остается на усмотрение разработчика SoC) есть несколько инструкций, использование которых позволяет ускорить потоковое шифрование подобно инструкциям, ускоряющим кодирование и декодирование потоков видео H.264 в большинстве современных процессоров.
Согласно официальной позиции Qualcomm, эти инструкции ни в коей мере не могут служить полноценной заменой выделенному модулю. Тем не менее Google (а за ней и большинство производителей) радостно начинает использовать именно эти инструкции и начисто игнорирует встроенные в чипсеты криптосопроцессоры.
Результат: зашифрованные данные на таких аппаратах (даже на устройствах начального уровня вроде Moto E 2015) читаются всего лишь в два раза медленнее незашифрованных. А вот на устройствах, базирующихся на 32-битных процессорах ARMv7, падение производительности гораздо сильнее — в четыре раза.
Почему «программное ускорение» — зло?
Отлично, просто замечательно! В 2016 году на Android зашифрованные данные читаются всего вдвое медленнее незашифрованных и всего в пять раз медленнее снятого с производства iPhone 5S (2013 год), в котором шифрование активировано из коробки! Инженерам Google нужно ставить памятник. ТАК медленно реализовать потоковое шифрование нужно сильно постараться.
Но скорость не главное. Основная проблема «программного» ускорения в том, что каждый раз, когда системе нужно что-то прочитать или записать, она вынуждена вместо микроскопического сопроцессора активировать огромные энергоемкие ядра, насильно выводя их из спящего режима. На времени жизни аккумулятора это сказывается однозначно негативно.
Отвлечемся на минуту от 64-разрядных устройств и вернемся к Nexus 6. Представь себе Snapdragon 805. Это — четыре больших ядра («больших» по числу транзисторов, по площади — и прожорливых соответственно). А выделенный ускоритель AES — это даже не малое ядро (хотя в некоторых решениях для крипто используется как раз одно из малых ядер ARM на низкой тактовой частоте, у нас не тот случай). Теперь каждый раз, когда системе нужно дописать строчку в лог-файл, активируется не отдельный маленький энергоэффективный чип, а все огромное и «горячее» ядро. Пусть и на миллисекунды, но пробуждается. А пишет или читает что-то Android постоянно (только в Android 6 появился режим Doze, который снижает интенсивность работы устройства в спящем режиме), и ядро активирует — тоже. Отсюда высокая скорость, с которой аккумулятор разряжается в простое (и еще более высокая — при работе).
И знаешь, что самое грустное? Это референсный дизайн Google. И если уж в Google не смогли или не захотели реализовать крипто на выделенном сопроцессоре, то никто, ни один OEM (за исключением, возможно, Samsung) этим заниматься тем более не будет. Ведь это не попугаи в AnTuTu, это что-то невидимое и обычному пользователю совсем непонятное и, как показала статистика, ненужное.
Подведем итог. Мало того, что за полтора года с выхода Nexus 6 так и не удалось задействовать криптосопроцессор. Мало того, что наступили на те же грабли в свежем последнем поколении Nexus’ов. У нас отобрали надежду на то, что шифрование будет реализовано на уровне хотя бы трехлетней давности iPhone 5S. В Google не могут или не хотят сделать быстрое потоковое крипто, несмотря на наличие всего необходимого — от выделенного сопроцессора до исходных кодов драйверов. Увы. На сегодня скорость шифрования в Android не достигла даже того уровня, который был взят Apple три года назад.
А что у других производителей?
Платформа Android выделяется сильнейшей фрагментацией. Разительно отличаются как аппаратные платформы (вплоть до используемых наборов команд — ARMv7, ARMv8, Intel x86 и x64), так и прошивки, под управлением которых работают устройства разных производителей. Учитывая все разнообразие устройств, проверить работу аппаратного шифрования даже небольшой части не представляется возможным. Тем не менее мы решили протестировать еще по крайней мере один аппарат — редакционный OnePlus One (версия с 16 Гбайт) под управлением прошивки CyanogenMod.
Скорость последовательного чтения данных после шифрования раздела ожидаемо упала втрое. Неожиданностью стало другое: скорость случайного доступа не изменилась, а запись данных небольшими блоками стала даже быстрее. Объяснения этому наблюдению у нас нет; есть комментарий. В отличие от Nexus 6, на OnePlus One не наблюдается сильного падения производительности в сценарии, эмулирующем использование смартфона в реальных условиях. Этот показатель намного более важен, чем скорость последовательного чтения, так как отражает способ использования смартфона (что-то читается и пишется маленькими порциями в разные участки памяти).
А что у Apple?
А у Apple все хорошо. Даже ФБР не смогло заставить компанию взломать собственную систему. Впрочем, совместными усилиями спецслужб и специализированных компаний после долгой шумихи и неудавшегося судебного процесса одно старенькое устройство, не оборудованное даже Secure Enclave, все-таки вскрыли.
Начиная с iPhone 5S, iPad mini 2 и iPad Air, шифрование данных — неотъемлемая часть подсистемы безопасности Secure Enclave. Сам процесс шифрования переложен с больших и горячих ядер основного процессора на энергоэффективный выделенный модуль. Результат? В iPhone 5S скорость последовательного чтения данных — 183 Мбайт/с, а в iPhone 6 — уже 249. И это без какого-либо заметного влияния на скорость работы устройства или время жизни от батарейки.
Заключение
Включать или не включать шифрование на смартфонах Android — дело пока еще добровольное. Старые версии платформы предоставляют пользователям полную свободу: воспользоваться шифрованием и терпеть резко упавшую производительность и повышенный разряд аккумулятора или не защищать данные совсем. Закрытая ОС от Apple подобной свободы не предлагает, в обязательном порядке шифруя данные без каких-либо негативных последствий для производительности дисковой подсистемы и дополнительной нагрузки на аккумулятор.
Впрочем, окно возможностей рисковать персональными данными вот-вот закроется и для любителей свободной ОС, ведь, начиная с шестой версии Android, Google собирается требовать от производителей обязательного включения шифрования из коробки. Учитывая, что с точки зрения Google виноград так и не созрел, использование аппаратного ускорения шифрования владельцам большинства устройств не грозит (впрочем, Samsung может удивить, самостоятельно реализовав то, чего не смогли достигнуть в Google. Вся история шифрования на платформе Android прямо-таки кричит об этом; однако это тема для отдельной статьи). Отдельные производители, такие как OnePlus, могут порадовать хорошей реализацией крипто в реальных сценариях использования, так что, если защита персональных данных для тебя не пустой звук, ты знаешь, куда смотреть. Если же выбирать между горьким и соленым не хочется, почему бы не обратить внимание на устройства яблочной компании?
