сертификат ЦС что это и с чем его едят? – MIUI общее – Xiaomi Community – Xiaomi

Вступление

Ни одна статья про защищенность мобильных систем не обходится без сравнения iOS и Android. Я не стану исключением и время от времени, при описании различных элементов безопасности Android, буду давать отсылки на аналогичные методы iOS. В качестве вступления я хотел бы сфокусироваться на подходах к формированию модели безопасности этих систем на первоначальном этапе развития, а в заключении попытаться сравнить, как обстоят дела сегодня.

iOS — закрытая операционная система без доступа к исходному коду и описанию того, что происходит внутри: один производитель «железа» и софта, невозможность «отката» и жесткие рамки поддерживаемых версий, сложная система проверки перед публикацией, надстройки над классической системой безопасности Unix.

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

Абсолютно разные подходы и модели, но с развитием систем некоторые механизмы безопасности начинают пересекаться и перетекают из iOS в Android и наоборот.

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

Сертификат цс что это и с чем его едят? – miui общее – xiaomi community – xiaomi

«одноразовые» разрешения

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

«строгий» режим доверенной загрузки

Развивая концепцию доверенной загрузки, которую существенно улучшили в Android 6, начиная с 7-й версии, скомпрометированные устройства больше не запускаются. Также добавлена поддержка исправления ошибок, которые могли возникнуть при загрузке устройства (это всё-таки больше направлено на повышение стабильности работы системы, чем на защиту от злоумышленников, но теперь тоже входит в реализацию цепочки доверенной загрузки в исполнении Google).

Android 10 (q, 2021)

Эта система продолжает дело 9-й версии, постепенно «закручивая гайки» по идентификации устройства и доступа к различной информации пользователя. Складывается ощущение, что Google решила вплотную приблизиться к iOS и постепенно сократить допустимый объем собираемой сторонними приложениями информации до минимума, оставляя, между тем, такую возможность своим приложениям.

Что интересно, начиная с этой версии Google перестаёт давать названия версиям операционной системы, связанных со сладостями. Очень жаль, что это осталось в прошлом.

Android 11 (r, 2020)

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

Android 12 (s, 2021)

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

Кстати, есть потрясающий разбор всех нововведений Android 12 (откуда я и взял информацию, так как это наиболее подробный и качественный обзор) от автора канала Android Guards, советую его посмотреть, если кто хочет подробностей. Все новшества я описывать не стану, остановлюсь на тех, которые мне показались наиболее интересными.

Android 4.4 (kitkat, 2021 год)

Начнем с Android 4.4, которая еще поддерживается некоторыми разработчиками приложений и, вероятно, может считаться отправной точкой усиления контроля над данными пользователя и повышения уровня безопасности в целом. Проанализируем первые шаги Google на пути совершенствования безопасности Android.

Android 5 (lollipop, 2021 год)

Как мне кажется, выпуск пятой версии Android можно назвать «прорывом» в безопасности этой операционной системы. Хотя бы потому, что именно в этой версии был заложен правильный фундамент последующего развития безопасности системы (пусть не самый удачный, но все же).

Android 6 (marshmallow, 2021)

После выпуска 5-й версии компания Google продолжила добавлять новые механизмы безопасности, но также начала переосмысливать предыдущие подходы и допущенные ошибки. Это, наверное, первая версия Android, которая начинает заботиться о безопасности данных пользователей и доступе к этой информации для сторонних приложений. В последующих обновлениях мы увидим развитие этих механизмов.

Android 7 (nougat, 2021)

После двух «рывков», которые принесли достаточно много нововведений, и пересмотра некоторых существующих механизмов разработчики Android решили немного «отдохнуть» от безопасности и переключить свое внимание на другие аспекты платформы. Но несколько вещей они всё-таки доработали.

Android 8 (oreo, 2021)

После небольшого перерыва в виде Android 7, Google решила сделать Android 8 одним из самых важных обновлений системы после пятой версии. Новая модульная система позволяет обновлять компоненты ОС независимо, появилась система ограничений фоновой работы приложений и многое-многое другое.

Android 9 (pie, 2021)

По сравнению с предыдущим выпуском Android 9 несет изменения, в большей степени направленные именно на конфиденциальность пользователя.

Private dns

Частный DNS (реализация DNS over TLS) шифрует весь DNS-трафик, предотвращая прослушивание или изменение его третьей стороной. Эта функция добавляет недостающий уровень безопасности и конфиденциальности всем DNS-запросам, которые отправляет устройство.

По умолчанию Android автоматически использует DNS over TLS, если функциональность поддерживается DNS-сервером. Но, конечно, это так же вынесено в настройки и может быть отключено. 

Treble

Наверное, одним из самых значимых изменений стала переработка внутренних компонентов Android, которая началась уже давно, после отделения WebView и других системных вещей в отдельные компоненты, которые можно обновлять независимо, но такого масштабного изменения не было никогда.

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

Другими словами, Google больше не зависит от производителей устройств в части обновлений безопасности для внутренних компонентов Android. Теперь Google сама решает, как и когда будет обновлен ваш телефон и какие обновления безопасности необходимо установить.

Webview в отдельном процессе

В Android 8 наконец-то изолировали WebView, теперь он выполняется в отдельном процессе, и это очень здорово. Это означает, что при наличии уязвимостей в этом компоненте больше не удастся получить доступ к процессу приложения, так как изоляция реализована с достаточно жесткими условиями, рендеринг страницы запускается в ограниченной «песочнице» без доступа к ресурсам системы и интернету, то есть просто отображает контент страницы, который ей передали.

Биометрия и аппаратное хранилище

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

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

Блокировка запроса на разрешение

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

Возможность автоматических резервных копий

Исторически сложилось, что в Android решение для создания резервных копий приложений было откровенно слабым. Было непонятно, что и как попадает в бекап, какие данные можно восстановить, а какие — нет. Теперь в Android 6 можно настроить автоматическое создание резервных копии как приложений, так и данных.

Наконец-то, любые восстановленные приложения, будут такими же, как и раньше, и с ними можно продолжить работу с момента создания последней резервной копии. Но есть и минус — резервные копии в облаке по-прежнему не защищены пользовательским паролем, а значит, теоретически, их содержимое может быть доступно «большому брату» и это изменится только в Android 9.

Гостевой режим

Продолжая тему «передачи» устройства кому-либо, в Android 5 стал доступен гостевой режим. Передавая кому-то телефон, стало возможным быстро перевести его в режим гостя, в котором он выглядит, как после сброса до «заводских настроек». Честно говоря, для меня это было откровением — никогда в жизни не пользовался этой функциональностью и даже не знал, что она когда-то была.

Дашборд приватности

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

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

Доверенная загрузка

В действительности попытки повторить цепочку доверенной загрузки в iOS предпринимались еще в версии 4.4, но они были не очень успешны. Этот функционал не был полностью проработан и носил необязательный характер. Начиная с версии Android 6, функционал Verified Boot, который обеспечивает защиту от различных модификаций системного раздела и важных файлов системы при загрузке, начинает активно развиваться и становится все более сложным и подготовленным к полноценному использованию.

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

Доступ к аппаратным идентификаторам

Google и раньше «отбирала» некоторые права у приложений, ограничивая доступ к данным пользователя, например ограничение на чтение системного журнала, но, начиная с Android 6, это стало принимать более серьезный масштаб и с каждой новой версией «гайки будут закручиваться».

В частности, в этой версии Android MAC адреса Wi-Fi и Bluetooth адаптеров нельзя получить без специального и явного разрешения пользователя. А сделано это, чтобы усложнить идентификацию устройства сторонними приложениями без ведома пользователя и сопоставление этих данных с данным Wi-Fi-точек, что часто используется для отслеживания устройства пользователя и его перемещения.

Доступ к геолокации в фоновом режиме

Теперь, когда приложение запрашивает разрешение на доступ к местоположению, Android 11 сначала выдает такое разрешение только для запущенного приложения, а если геолокация необходима и в фоновом режиме, формируется отдельный запрос. Этот второй запрос требует от пользователей дополнительных действий вместо того, чтобы просто нажимать «Oк…, Oк…, разрешить…».

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

Доступ к идентификаторам устройства

В Android 6 впервые начали «отбирать» у приложений доступ к аппаратным идентификаторам устройства, в Android 8 этот процесс продолжили. Теперь приложениям запрещено получение информации об Android ID — уникальном идентификаторе, который генерируется при первой загрузке устройства (теперь для каждого приложения он будет уникальным).

Запрет доступа к скрытым api

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

В Android 9 доступ к приватным API запрещен. Более того, новая версия Android выводит уведомление в том случае, если приложение использует объявленные устаревшими (deprecated) API. Это должно заставить разработчиков перейти на использование новых API.

Запрет на использование world-accessible флагов

До Android 9 можно было дать доступ к файлу внутри своей «песочницы», установив ему флаг WORLD_READABLE или WORLD_WRITABLE (фактически, это аналогично выполнению команды chmod c определенными параметрами). Это было достаточно плохой практикой с непредсказуемыми последствиями.

Начиная с девятой версии Android, использование такого подхода запрещено (дополнительно контролируется правилами SELinux), а для предоставления доступа к данным своего приложения необходимо использовать только механизмы IPC (межпроцессного взаимодействия), в виде Content Providers, которые более безопасны, подконтрольны разработчикам и регулируются внутренними механизмами безопасности.

Запрет на использование сенсоров в фоновом режиме

Об одном из самых заметных security-новшеств Android 9 стало известно еще до выхода бета-версии. Это, конечно же, запрет на использование камеры, микрофона и любых сенсоров приложениями, которые находятся в состоянии Idle, то есть свернуты и работают в фоне.

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

Для этого Google в очередной раз предлагает использовать так называемый foreground service. Это специальный тип фоновой службы, которая при использовании сенсоров показывает значок и уведомление в панели уведомлений, а потому заметна пользователю (в теории).

Запрет на получение информации на экране

Чтобы защитить содержимое экрана, доступ к нему в Android 10 существенно ограничен, для чего изменены соответствующие разрешения (READ_FRAME_BUFFER, CAPTURE_VIDEO_OUTPUT и CAPTURE_SECURE_VIDEO_OUTPUT).

Начиная с Android 10, эти разрешения доступны только системным приложениям. Система следит за использованием разрешений при помощи signature-access. То есть, использовать разрешение может только приложение, которое подписано тем же сертификатом, что и «владелец» разрешения (то приложение, которое его регистрирует в системе).

Приложения, которым требуется доступ к содержимому экрана устройства, должны использовать специальный MediaProjection API, который всегда предупреждает пользователя о намерении приложения получить доступ к экрану и запрашивает его явное согласие.

Запрет на получения данных об устройстве

Еще несколько идентификаторов (Serial Number, IMEI, DeviceId, MEID, SIM Serial Number, Subscruber ID) перешли в разряд запрещенных к получению обычными приложениями. С одной стороны, это существенно усложняет жизнь различным приложениям, которые следят за пользователем и идентифицируют устройство.

Тем не менее, встроенные приложения от производителя и компании Google по-прежнему имеют доступ к этой информации.

Запуск activity в фоне

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

Зашифрованные резервные копии

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

Для восстановления данных из зашифрованных резервных копий, требуется ввод PIN-кода устройства, графического ключа или пароля. 

Изменение логики работы с permissions

Прежде чем говорить об изменении логики работы, стоит объяснить, а что же представляют из себя эти Permissions (разрешения).

Операционная система Android устроена таким образом, что для выполнения некоторых операций или доступа к ресурсам, приложение должно иметь определенное разрешение. Эти разрешения разделяются на несколько уровней: Normal и Dangerous. Их отличие в том, что Dangerous-разрешения позволяют получать личную информацию пользователя или совершать потенциально опасные действия (например доступ к контактам или SMS-сообщениям).

До Android 6 все было достаточно просто: пользователь во время установки приложения видел все разрешения, которые запрашивает приложение.

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

Начиная с Android 6, подход изменился: теперь при установке приложения нет экрана со списком всех разрешений. Приложение автоматически получает все необходимые Normal-разрешения, a Dangerous — необходимо запрашивать в процессе работы. Т. е. теперь разработчику недостаточно просто указать, что приложению нужен, например, доступ к контактам. Чтобы получить его необходимо явно вызвать диалог подтверждения.

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

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

Информация об установленном обновлении безопасности

До Android 6.0 оставалось только догадываться, получал ли телефон обновления безопасности и в каком состоянии он сейчас находится. Но в этой версии в раздел «О телефоне» была добавлена информация о том, какое обновление безопасности установлено на данный момент.

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

В итоге оказалось, что многие производители хитрят во время выпуска обновлений и, хотя они утверждают, что их устройства получили все актуальные патчи, на самом деле это не так. Некоторые исправления, по неизвестным причинам, «выпадают» из списков и вообще не доходят до пользователей.

Как установить доверенный сертификат ca на android-устройстве?

<network-security-config>    
    <debug-overrides> 
        <trust-anchors> 
            <!-- Trust user added CAs while debuggable only -->
            <certificates src="user" /> 
        </trust-anchors>    
    </debug-overrides>  
</network-security-config>

<?xml version="1.0" encoding="utf-8"?> 
<manifest>
    <application android:networkSecurityConfig="@xml/network_security_config">
    </application> 
</manifest>

Камера и микрофон

Теперь, по аналогии с iOS, при использовании камеры и микрофона в правом верхнем углу будет отображаться отдельный индикатор, который уведомит пользователя, что какое-то приложение задействует указанные устройства. Это не просто индикатор, а полноценная область, откуда можно сразу же «отнять» разрешения.

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

Новые возможности при потере устройства

Несколько очень полезных и нужных функций при потере устройства появилось в пятой версии Android.

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

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

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

Ограничения на буфер обмена

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

Теперь, начиная с 10-й версии, доступ к буферу обмена разрешен, только если приложение активно и находится в foreground (на переднем плане). 

Отдельное разрешение для bluetooth

Как мы помним, начиная с 6-й версии Android, началось жесткое ограничение доступа приложений к различным идентификаторам, в том числе к MAC-адресам Wi-Fi и Bluetooth, впоследствии досталось и разрешениям на сканирование сети и доступ к устройствам поблизости.

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

Теперь же, в Android 12, ввели отдельное специальное разрешение именно для Bluetooth и всего, что с ним связано. Возможно, на это повлияла популярная сегодня тема умного дома и большое количество датчиков, использующих BLE. Но главное, если появилось отдельное разрешение на эту технологию, может Google и дальше продолжит более логично их разделять, что было бы отлично, так как сейчас, лично для меня, некоторые разрешения совершенно не отражают всех возможностей, которые за ними стоят.

Первые шаги в биометрии и smart lock

По статистике, раньше далеко не все пользователи устанавливали код блокировки на свой телефон, аргументируя это тем, что неудобно каждый раз его вводить, чтобы воспользоваться устройством, например сделать фото и т. д.

Как раз чтобы сделать разблокировку более удобной, Google анонсировала функцию Smart Lock, которая позволяла разблокировать устройство с установленным паролем при помощи различных Bluetooth или NFC аксессуаров. Дополнительно можно было включить опции по разблокировке в определенных местах на основе данных GPS, а также запретить блокировать устройство, пока оно находится у вас в руках (на основе данных с акселерометра).

Переход на пофайловое шифрование (fbe)

Как мы помним, в Android 5 впервые было по умолчанию включено шифрование диска (а на самом деле, внутренней памяти устройства), но оно имело несколько существенных недостатков. Теперь же, начиная с Android 7, появилась опция пофайлового шифрования данных (вместо используемого ранее Full-Disk Encryption).

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

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

Переход обновления некоторых компонентов на google play services

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

Но с выходом 5-й версии был запущен процесс поставки обновлений для части компонентов операционной системы (а именно для WebView) через механизм обновления Google Play. Фактически это означало, что телефон будет своевременно получать все актуальные обновления так же, как обновляются приложения (конечно, не всегда это работает на благо). Удобно, просто и для закрытия критических уязвимостей не нужно ждать, когда производитель соизволит выпустить свой патч.

Получение обновлений безопасности из google play store

Продолжая развивать механизм Treble, существенно улучшенный в Android 8, система теперь получает все критические обновления напрямую из Google Play. Это очень сильно упрощает процесс и повышает общий уровень безопасности устройств, так как теперь обновления системы могут устанавливаться автоматически.

Но что же делать пользователям, у которых нет магазина приложений Google и их сервисов, пока не очень понятно. Вероятно, надеяться на производителя своего смартфона. 

Пользователи android 7.1.1 и более старых версий не смогут открывать защищённые let’s encrypt сайты с января

В 2021 году завешается срок соглашения Let’s Encrypt с IdenTrust. Таким образом, браузеры и ОС без корневого сертификата Let’s Encrypt больше не будут работать с сайтами и службами, которые используют этот сертификат. Центр сертификации Let’s Encrypt предупредил, что проблема коснется устройств с версиями Android до 7.1.1 Nougat. С 11 января 2021 года режим перекрестной подписи отменяется по умолчанию, а с 1 сентября от него откажутся полностью.

Это затронет значительную часть Android-пользователей. По последним данным статистики, на долю Android 7.1 и более старых версий приходилось почти 34% устройств.

Про сертификаты:  Сертификация одежды

Однако существует вариант частичного разрешения ситуации. Пользователи могут установить Firefox, который использует собственное хранилище сертификатов. Это решит проблему браузеров, но не клиентов или функций. Единственный способ полностью обойти ограничения —в обновлении своей версии Android. Но он доступен не всем пользователям старых смартфонов, если их производители прекратили поддержку.

В настоящее время Samsung и другие производители Android-устройств обязуются обновлять ОС в течение трех лет.

Let’s Encrypt ещё в апреле 2021 года планировал перейти на собственную цепочку ISRG Root, но этого не произошло из-за опасений по поводу недостаточного распространения корня ISRG на устройствах Android. Дату перенесли на 8 июля 2020 года.

Сейчас Let’s Encrypt использует перекрёстно подписанный промежуточный сертификат с цепочкой до корня IdenTrust DST Root CA X3. Этот корневой сертификат был выдан ещё в сентябре 2000 года и истекает 30 сентября 2021 года. До этого времени Let’s Encrypt планирует перейти на собственный самоподписанный корень ISRG Root X1, который выпущен 4 июня 2021 года. Он был доступен клиентам через обновление с 6 августа 2021 года.

См. также:

Приблизительная геолокация

В прошлых версиях уже добавляли такое понятие, как приблизительная геолокация, но в Android 12 это «выставлено напоказ». При запросе приложения на геолокацию пользователь может сразу выбрать в красивом диалоге, выдавать ему точное местоположение или приблизительное (хотя до сих пор непонятно, насколько она действительно «приблизительное»).

Работа с сертификатами

В этой версии впервые начали уделять внимание проблеме атаки «Человек посередине». Чтобы обезопасить пользователя, было предпринято несколько важных мер, которые в дальнейшем будут развиты и усилены (в Android 6 и выше):

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

• Усложнение перехвата сетевого трафика, отправляемого и получаемого сервисами Google. Теперь система следит за тем, чтобы только сертификаты из белого списка могли подключаться к этим сервисам. 

Работа с сетевыми соединениями

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

Вторым очень важным изменением является возможность настройки безопасности сетевого взаимодействия, которое позволяет более четко определять параметры соединений. Теперь конфигурация сетевого взаимодействия — это XML-файл, в котором настраиваются параметры безопасности. Ключевые возможности, которые предоставляет такой подход:

Рандомизация mac-адреса по умолчанию

Очевидно, что добавленный в Android 9 механизм рандомизации MAC-адреса при подключении хорошо себя зарекомендовал, так что в новой 10-й версии больше не нужно руками включать эту опцию — теперь она включена по умолчанию. 

Рандомизация mac-адреса при подключении

В прошлой версии Android MAC-адреса менялись только при сканировании точек, доступных для подключения. Логическим продолжением стало использование случайного адреса при подключении к сети.

То есть, при подключении к различным точкам доступа им будут соответствовать разные MAC-адреса, что затруднит идентификацию устройства. Чтобы помнить, какой точке доступа какие MAC-адреса соответствуют, в Android есть специальная табличка сопоставление адреса и Wi-Fi сети. Но по традиции, эту опцию добавили только в режим разработчика, где её нужно самому найти и включить.

Рандомизация mac-адреса при поиске новых сетей

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

И наконец, в Android 8 добавили функцию рандомизации Mac-адреса при поиске сетей (если я не ошибаюсь, в iOS это было реализовано в 8-й версии в 2021 году). Это первый шаг на пути обеспечения приватности пользователя — он не позволяет отследить реальный MAC-адрес и сопоставить его конкретным устройством.

Режим usb по умолчанию

Теперь не стоит волноваться, подключая телефон к зарядке на автобусной остановке или к другому непроверенному USB-порту, так как подключение устройств через USB теперь по умолчанию настроено на режим «только зарядка». Чтобы получить доступ к устройству и его содержимому, пользователь должен явно предоставить на это разрешение.

Снижение системных требований

Google всегда осознавала проблему очень сильной фрагментации Android. Большое количество производителей, кастомные сборки, каждый модифицирует что-то под себя и, как правило, производители не спешат обновлять версии операционной системы из-за сложности адаптации новых версий под вносимые изменения.

Наглядной иллюстрацией описанной ситуации является диаграмма использования версий Android.

Проблема становится особенно хорошо заметна в сравнении с iOS.

На диаграмме использования версий iOS ярко выражены «зубцы», по которым можно однозначно определить время выхода новой версии операционной системы. Немаловажно, что наиболее ранняя версия iOS, которая всё ещё используется, это 13.3 (2021 год). В то время, как на диаграмме Android до сих пор можно видеть версию 5.1 (2021 год).

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

Уведомление о попытке доступа к буферу обмена

В 10-й версии Android уже поработали над буфером обмена и запретили его использование в фоновом режиме. В новой версии Android механизм работы с данными из буфера обмена также усовершенствован. Теперь, когда приложение пытается получить данные из буфера обмена, пользователю будет выведено уведомление (toast сообщение), информирующее, что приложение «залезло» в скопированные данные. Этот механизм практически аналогичен функционалу, который появился в iOS 14 (2020 год).

И это очень правильное изменение, которое добавит больше ясности и прозрачности в работе приложений.

Усиление режима selinux

Android 5 продолжил дело своего предшественника (Android 4) и еще больше интегрировал SELinux в защитные механизмы системы. Теперь Enforcing mode (принудительный режим) обязателен не только для отдельных частей системы, но и для всего остального, включая пользовательские приложения.

Чтение логов

Несмотря на то, что мы начали с Android 4.4, не могу не упомянуть об интересном изменении, которое касается чтения системного журнала обычными приложениями. Начиная с Android 4.1, пользовательские приложения больше не имеют доступа к системному журналу, и не могут использовать разрешение «permission.

READ_LOGS». Теперь это разрешение присутствует только у системных приложений и демона adb. По идее, это должно защитить пользовательские данные, если они вдруг попадают в системный лог. Хотя, кто знает, как системные приложения используют это разрешение (тем более, количество системных приложений от производителя к производителю может существенно отличаться).

Шифрование данных на устройстве

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

Но, начиная с пятой версии, Android использует шифрование диска по умолчанию с помощью классического способа Full-Disk Encryption.

Но не обошлось и без минусов:

Явный экспорт компонентов приложения

Наконец-то, спустя столько времени, страданий и проблем, Google услышала молитвы безопасников и объявила атрибут exported обязательным к заполнению для всех компонентов приложения. Тут стоит немного прояснить: в Android-приложении присутствуют так называемые экспортируемые компоненты, которые могут быть вызваны другими приложениями.

Чтобы сделать компонент экспортируемым, достаточно указать ему атрибут exported=true, но многие забывают, что это не единственный способ. К примеру, при указании любых intent-фильтров, компонент автоматически становится экспортируемым. И это не редко приводило к проблемам безопасности, когда внутренние элементы приложения оказывались доступны для других приложений.

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

Заключение

Конечно, в данной статье не удалось охватить все аспекты безопасности, которые добавлялись в каждой версии, но основные вещи я постарался осветить.

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

После достижения определенного уровня зрелости этих механизмов основные силы были направлены на обеспечение приватности пользователя и защиту его данных. И что интересно, Google нередко вводила различные механизмы, которые сначала оставались выключенными по умолчанию, чтобы определить, насколько они хорошо работают, собрать статистику и в следующем релизе выпустить их доработанными, готовыми к массовому использованию и включенными по умолчанию.

В плане механизмов безопасности система Android все больше и больше начинает походить на iOS. Конечно, до полного тоталитаризма еще далековато, но предпосылки и сходство определенно есть. Как мы видим, некоторые из механизмов приватности впервые появлялись в iOS и постепенно переходили в Android (рандомизация Mac-адресов, запрет на доступ к идентификаторам устройства, одноразовые разрешения и т. д.). Это разумно: брать интересные и работающие решения и применять их для обеспечения безопасности и приватности пользователей.

На мой взгляд, Google проделала очень большую работу по обеспечению безопасности своей платформы и продолжает развивать эту сторону своей операционной системы.

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

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

До встречи!

Отзыв разрешений у неиспользуемых приложений

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

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