Одним из самых интересных на Google I/O было выступление Адриана Людвига, отвечающего за безопасность платформы Android. За сорок минут он успел рассказать и о новшествах Android M в плане безопасности, и о грядущем Android N. Так как о security-фичах шестой версии системы мы уже писали, я остановлюсь лишь на том, что инженеры Гугла успели добавить в седьмую (или 6.1, которой, по слухам, может стать новая версия Android). Поехали.

 

Хардварное хранилище ключей

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

Данная технология используется в iPhone (Secure Enclave) и реализована в Android начиная с версии 4.3. Однако до более-менее пригодного к использованию состояния она была доведена лишь к версии 6.0, когда появились все необходимые функции для генерации ключей, разграничения доступа к ним, поддержка ключей RSA, ECDSA, AES, HMAC и прочее.

Так вот, начиная с Android N Google будет требовать обязательное включение поддержки хардварного хранилища ключей в устройства. То есть то, что Apple сделала четыре года назад, в Android появилось только сейчас. Это совсем не удивительно, учитывая зоопарк устройств на базе Android, среди которых далеко не только смартфоны и планшеты. Удивительно другое — TrustZone, самая распространенная реализация данной технологии, разработанная ARM, дырявая как сапог.

Один из слайдов презентации
Один из слайдов презентации

Точнее, дырявая не сама технология, а ее реализация в чипах Qualcomm, которые чаще всего используются в смартфонах и планшетах. Обход защиты этой технологии уже давным-давно описан в блоге «Bits, Please!», а совсем недавно появилась информация об извлечении мастер-ключа TrustZone, того самого, с помощью которого можно расшифровать все «защищенное» хранилище.

Возможно, новые девайсы на базе Qualcomm и получат исправленную версию чипа, но доверия технология уже не вызывает.

 

Сканер отпечатков пальцев и Smart Lock

Идем дальше. На очереди сканер отпечатков пальцев и Smart Lock. Здесь все довольно скучно. Раньше защиту экрана блокировки применяли 50% пользователей, сканер поднял этот уровень до 90% (очень странные цифры, кстати). Ну и Smart Lock, технология, с помощью которой можно привязать смартфон к смарт-часам и не вводить пароль, пока они поблизости, позволила вводить пароль в два раза реже.

Все защищены!
Все защищены!
 

Шифрованные соединения с сетью

Здесь у Адриана две новости. Первая: теперь разработчики могут более тонко управлять тем, какие компоненты приложения должны использовать зашифрованные соединения, а какие нет. Тут нужна небольшая предыстория. В определенный момент разработчики Android осознали, что самим управлять HTTPS- и прочими TLS-соединениями разработчикам довольно трудно, и ввели в AndroidManifest специальную директиву, с помощью которой программист мог прямо сказать: «Мое приложение использует только зашифрованные соединения» (или наоборот), а далее он мог использовать стандартные сетевые библиотеки, и система все делала сама.

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

Кусок AndroidManifest.xml
Кусок AndroidManifest.xml
 

Шифрование данных

Дальше становится совсем весело: Адриан начинает рассказ об очень странной технологии, понять суть которой без бэкграунда затруднительно. А суть такова. Начиная с Android M Google стала требовать, чтобы все новые устройства на базе этой ОС принудительно включали шифрование данных. В общем-то, все логично, и к этому все шло еще с пятой версии системы. Но есть в этом требовании проблема: если после случайной перезагрузки девайс останется заблокирован (и следовательно, зашифрован), как приложения, которые, допустим, должны выводить уведомления и выполнять какие-то фоновые действия, получат доступ к своим данным?

Инженеры Google придумали гениальное решение — режим Direct Boot. Суть такова: каждое приложение теперь может иметь два различных каталога с данными, один доступен до разблокировки устройства, другой — только после. При этом разработчик должен сам определять, какой из них использовать и когда. То есть если какие-то данные нужны приложению всегда, даже если смартфон не разблокирован, — будь добр использовать хранилище, доступное до разблокировки, а остальные данные уже держи в другом.

Direct Boot
Direct Boot
 

Принудительный контроль загрузки

А это уже о тех вещах, о которых так любят заливать ребята из BlackBerry. Речь идет о механизме доверенной загрузки (Verified Boot), поддерживаемом Android начиная с версии 4.4 (а не только в вашей прошивке, BlackBerry!). Суть в следующем: на каждом этапе загрузки «первичный загрузчик → вторичный → aboot → ядро Linux → система Android» операционная система умеет проверять целостность всех этих компонентов (загрузчики по цифровым подписям, ядро по контрольной сумме, система по контрольной сумме всей ФС). Однако если раньше об изменении какого-либо из компонентов система лишь предупреждала, то теперь она просто откажется загружаться.

Более того, теперь в Android есть механизм, позволяющий откатить состояние системы. То есть ты можешь получить root, перезагрузиться и при следующей загрузке получишь нерутованную систему. Как это работает, не совсем понятно, но в целом звучит круто.

Verified Boot
Verified Boot
 

Проверка устройств и ОС

Дальше Адриан перешел к корпоративщине, а если точнее — к технологии, которая ей понравится. В Google Play Services теперь есть API под названием SafetyNet, который выполняет одну простую задачу: проверяет, оригинальное ли устройство (сверка серийников), не была ли его прошивка изменена или получен root и в каком состоянии годности она вообще находится.

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

Пример сверки patch level
Пример сверки patch level
 

Другие улучшения

Под конец Адриан рассказал про общее укрепление безопасности:

  • MediaServer, тот самый сервис, где нашли огромное количество багов класса StageFright, теперь разделен на множество независимых сервисов, и из них каждый имеет только те полномочия, которые ему нужны. Идея здесь в том, что баги были найдены в коде медиакодеков, которые теперь не имеют доступа к интернету, так что они не могут быть проэксплуатированы удаленно. Подробнее об этом можно почитать в блоге Google.
  • В дополнение к системе изоляции процессов SELinux теперь используется механизм seccomp ядра Linux, предназначенный для запирания приложения в песочницу. В основном применяется к системным низкоуровневым демонам.
  • Ужесточен контроль доступа к системной информации, предоставляемой с помощью файловых систем /proc и /sys.
  • Добавлена защита от ransomware. Теперь у пользователя есть возможность разблокировать смартфон, заблокированный сторонним приложением. Также приложения больше не могут перекрывать системные диалоги.
Разделенный MediaServer
Разделенный MediaServer
 

Выводы

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

Евгений Зобнин

Евгений Зобнин

Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.

1 комментарий

  1. rstp14

    17.07.2016 at 11:31

    Ага. patch level. Очень хорошо.
    1. Купит пользователь какое-нибудь китайское устройство, производитель которого естественно обновлять прошивку не будет и через полгодика приложения работать перестанут.
    2. Купит пользователь бренд и со равно производитель (Будь то Samsung, Sony, LG или даже сам Google) вечно обновлять устройство не будут. Через пару лет уже новое покупать придётся.

    Очень «хорошее» нововведение.

Оставить мнение

Check Also

Все по песочницам! Запускаем приложения в отдельных виртуалках с помощью AppVM

Если ты действительно заботишься о безопасности, то некоторые приложения есть смысл запуск…