Содержание статьи
Одним из самых интересных на 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 это исправила, позволив тонко регулировать, какие именно соединения шифровать, а какие пусть идут открытым текстом. Еще одно нововведение: установленные пользователем сертификаты теперь не получают уровень доверенных.
Шифрование данных
Дальше становится совсем весело: Адриан начинает рассказ об очень странной технологии, понять суть которой без бэкграунда затруднительно. А суть такова. Начиная с Android M Google стала требовать, чтобы все новые устройства на базе этой ОС принудительно включали шифрование данных. В общем-то, все логично, и к этому все шло еще с пятой версии системы. Но есть в этом требовании проблема: если после случайной перезагрузки девайс останется заблокирован (и следовательно, зашифрован), как приложения, которые, допустим, должны выводить уведомления и выполнять какие-то фоновые действия, получат доступ к своим данным?
Инженеры Google придумали гениальное решение — режим Direct Boot. Суть такова: каждое приложение теперь может иметь два различных каталога с данными, один доступен до разблокировки устройства, другой — только после. При этом разработчик должен сам определять, какой из них использовать и когда. То есть если какие-то данные нужны приложению всегда, даже если смартфон не разблокирован, — будь добр использовать хранилище, доступное до разблокировки, а остальные данные уже держи в другом.
Принудительный контроль загрузки
А это уже о тех вещах, о которых так любят заливать ребята из BlackBerry. Речь идет о механизме доверенной загрузки (Verified Boot), поддерживаемом Android начиная с версии 4.4 (а не только в вашей прошивке, BlackBerry!). Суть в следующем: на каждом этапе загрузки «первичный загрузчик → вторичный → aboot → ядро Linux → система Android» операционная система умеет проверять целостность всех этих компонентов (загрузчики по цифровым подписям, ядро по контрольной сумме, система по контрольной сумме всей ФС). Однако если раньше об изменении какого-либо из компонентов система лишь предупреждала, то теперь она просто откажется загружаться.
Более того, теперь в Android есть механизм, позволяющий откатить состояние системы. То есть ты можешь получить root, перезагрузиться и при следующей загрузке получишь нерутованную систему. Как это работает, не совсем понятно, но в целом звучит круто.
Проверка устройств и ОС
Дальше Адриан перешел к корпоративщине, а если точнее — к технологии, которая ей понравится. В Google Play Services теперь есть API под названием SafetyNet, который выполняет одну простую задачу: проверяет, оригинальное ли устройство (сверка серийников), не была ли его прошивка изменена или получен root и в каком состоянии годности она вообще находится.
Используя данный API, разработчики смогут писать приложения, которые в принципе не заработают на модифицированных прошивках или, например, в том случае, если версия прошивки или ее patch level не соответствуют определенным требованиям. Ранее разработчикам приходилось все это делать самим или с помощью специальных библиотек, теперь у них есть готовый и простой в использовании инструмент.
Другие улучшения
Под конец Адриан рассказал про общее укрепление безопасности:
- MediaServer, тот самый сервис, где нашли огромное количество багов класса StageFright, теперь разделен на множество независимых сервисов, и из них каждый имеет только те полномочия, которые ему нужны. Идея здесь в том, что баги были найдены в коде медиакодеков, которые теперь не имеют доступа к интернету, так что они не могут быть проэксплуатированы удаленно. Подробнее об этом можно почитать в блоге Google.
- В дополнение к системе изоляции процессов SELinux теперь используется механизм seccomp ядра Linux, предназначенный для запирания приложения в песочницу. В основном применяется к системным низкоуровневым демонам.
- Ужесточен контроль доступа к системной информации, предоставляемой с помощью файловых систем /proc и /sys.
- Добавлена защита от ransomware. Теперь у пользователя есть возможность разблокировать смартфон, заблокированный сторонним приложением. Также приложения больше не могут перекрывать системные диалоги.
Выводы
Команда Android действительно вкладывает много усилий в безопасность системы. Если проследить историю развития платформы, то становится заметно, насколько сильно Android нашпигован самыми разными защитными механизмами и подсистемами. Кажется, задействовано уже все, однако баги есть везде, и Google не может обеспечить должную скорость их закрытия, в отличие от Apple, багов в которой найдено не меньше (подробности в дайджесте).
