Безопасность Android



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

Общие угрозы безопасности

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

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

Исследование компании Trend Micro заключило, что злоупотребление премиум-сервисом является наиболее распространённым типом вредоносного Android ПО, когда текстовые сообщения без согласия пользователя отправляются из заражённых телефонов на телефоны пользователей с премиум-подпиской.

Другое вредоносное ПО отображает навязчивую рекламу на устройстве или отправляет информацию неавторизованной третьей стороне.

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

Google также утверждает, что опасное ПО встречается достаточно редко — исследование, проведённое F-Secure, продемонстрировало, что только 0,5 % зарегистрированного вредоносного ПО получено из Google Play.

В августе 2015 компания Google заявила, что устройства Nexus будут получать ежемесячное обновление с исправлениями обнаруженных уязвимостей в системе. Ежемесячные обновления систем безопасности Android и своевременное реагирование производителей устройств значительно уменьшили влияние уязвимостей «нулевого дня» в Android-системах.

Например, CVE-2016-5195 («Dirty cow») был публично раскрыт 19 октября 2016 года. Уже в ноябре 2016 некоторые производители, например BlackBerry, внедрили исправления в производство.

В 2016 году Android объединил усилия с мобильными компаниями, такими как Qualcomm, Broadcom и MediaTek, чтобы увеличить скорость, с которой потребители получают ежемесячные обновления системы своих устройств.

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

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

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

В 2016 году исследователи исправили 655 уязвимостей путём разработки 133 критических обновлений, 365 высокой, 154 средней и 3 низкой критичности. Это более чем в 2 раза больше, чем в 2015 году.

Весь 2016 год Google продолжал выпускать срочные обновления безопасности для Android 4.4 и выше. В декабре 2016 года 735 миллионов устройств имели свежую версию обновлений.

Google также сотрудничает с разработчиками приложений, чтобы повысить уровень безопасности их продуктов. Программа улучшения безопасности приложений (ASI) определяет приложения в Google Play, которые имеют недостатки в коде или в подключаемых внешних библиотеках. Это делается путём сканирования приложений, загружаемых в Google Play, на наличие известных уязвимостей. Если таковые обнаружены, ASI связывается с разработчиками по почте и предлагает путь устранения неполадок. В 2016 году ASI включила 18 новых уязвимостей в список проверки к уже имеющимся с 2015 года 8 угрозам.

В 2016 году Google запустил 6 кампаний, которые ставят своей целью предупреждать разработчиков о наличии в из продуктах уязвимостей и потенциальном риске для потребителей. Если приложение было опубликовано в Google Play до запуска этих кампаний и в течение 90 дней разработчик не предпринял попыток исправить дыры в безопасности, то его приложение остаётся в Google Play, но если он захочет обновить приложение, то оно должно иметь исправления всех найденных уязвимостей.

Исправления дыр в безопасности, найденные в операционной системе, часто не доходят до пользователей более старых и дешёвых устройств.

Однако, так как Android — ОС с открытым кодом, то это позволяет разработчикам ПО для обеспечения безопасности адаптировать существующие устройства для особо секретного использования. Например, Samsung сотрудничает с General Dynamics благодаря приобретению Open Kernel Labs для восстановления Jelly Bean поверх своего упрочнённого микровизора для проекта Samsung Knox.

Android-смартфоны могут сообщать местоположение точек доступа Wi-Fi, встречающихся при перемещении пользователей телефонов, для создания баз данных, содержащих физические местоположения сотен миллионов таких точек доступа. Эти базы данных формируют электронные карты для поиска смартфонов, позволяя им запускать такие приложения, как Foursquare, Google Latitude, Facebook Places и предоставлять рекламу на основе местоположения.

Стороннее программное обеспечение для мониторинга, такое как TaintDroid, финансируемое научными исследованиями, может в некоторых случаях обнаруживать, когда личная информация отправляется с приложений на удалённые серверы.

Новшества в системе безопасности Android 8.0

Установка приложений из неизвестных источников

В Android 8.0 из меню исчезла настройка «Разрешить неизвестные источники». Таким образом Android 8.0 защищает пользователей от потенциально опасного ПО, которое маскируется под важное системное обновление из стороннего источника. В Android Oreo разрешение «Установить неизвестные приложения» привязано к приложению, которое запрашивает установку, как и другие разрешения во время выполнения, и гарантирует, что пользователь предоставит разрешение на использование источника установки, прежде чем оно сможет предложить пользователю установить приложение.

Использование Peer Group Analysis для поиска вредоносных программ

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

Treble

Слабое место Android — код, привязанный к процессору и чипсету, «размазан» по всей ОС, что усложняет подготовку патчей. В 2016 году более 50 % Android-устройств не получали обновления безопасности.

Project Treble — это слой HAL, сильнее отделяющий операционную систему от драйверов. Это позволит Google присылать обновления ОС даже на неподдерживаемые устройства, и усложнит поиск цепочки уязвимостей, которая бы добралась до драйверов и обеспечила бы исполнение кода с драйверными правами.

Защита от даунгрейда

Механизм Verified Boot проверяет целостность компонентов ОС на всех этапах загрузки смартфона и может запретить загрузку, если загрузчик, ядро или ОС были модифицированы. Но в этом механизме есть проблема — возможность сделать даунгрейд. В Android 8 теперь есть официальная реализация этой защиты. Но она отключается при разблокировке загрузчика штатными средствами.

Блокировка ядра и фильтр seccomp

По словам представителей Google, к уровню ядра в 2014 году относилось всего 4 % багов, о которых сообщили пользователи, а сейчас они составляют 39 %. В этой связи в Android Oreo были внедрены фильтр secure computing mode.

Оповещения

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

Безопасность ядра и системы

На уровне операционной системы платформа Android обеспечивает безопасность ядра Linux, а также средство безопасного межпроцессного взаимодействия (IPC). Эти функции безопасности на уровне ОС гарантируют, что даже собственный код ограничен изолированной программной средой приложения. Независимо от того, является ли этот код результатом включенного поведения приложения или использованием уязвимости приложения, система разработана таким образом, чтобы предотвращать вред, наносимый мошенническим приложением другим приложениям, системе Android или самому устройству.

Безопасность ядра Linux

Основой платформы Android является ядро ​​Linux. Ядро Linux широко используется в течение многих лет и используется в миллионах сред, чувствительных к безопасности. Благодаря своей истории постоянных исследований, атак и исправлений тысяч разработчиков Linux стал стабильным и безопасным ядром, которому доверяют многие корпорации и специалисты по безопасности.

Ядро ​​Linux предоставляет Android несколько ключевых функций безопасности, в том числе:

  • Модель разрешений на основе пользователей
  • Изоляция процесса
  • Расширяемый механизм для безопасного IPC
  • Возможность удалять ненужные и потенциально небезопасные части ядра

Как многопользовательская операционная система, основной целью безопасности ядра Linux является изоляция пользовательских ресурсов друг от друга. Философия безопасности Linux заключается в защите пользовательских ресурсов друг от друга.

Таким образом, Linux:

  • Запрещает пользователю A читать файлы пользователя B
  • Гарантирует, что пользователь A не использует память пользователя B
  • Гарантирует, что пользователь A не использует ресурсы ЦП пользователя B
  • Гарантирует, что пользователь A не использует устройства пользователя B (например, телефония, GPS и Bluetooth)

Песочница приложений (Application Sandbox)

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

Android использует UID для настройки «песочницы» на уровне ядра. Ядро обеспечивает безопасность между приложениями и системой на уровне процессов с помощью стандартных средств Linux, таких как идентификаторы пользователей и групп, которые назначаются приложениям. По умолчанию приложения не могут взаимодействовать друг с другом и имеют ограниченный доступ к ОС. Если приложение A пытается сделать что-то вредоносное, например, прочитать данные приложения B или набрать номер телефона без разрешения, это будет запрещено, поскольку у него нет соответствующих пользовательских привилегий по умолчанию. Песочница проста, проверяема и основана на многолетнем пользовательском разделении процессов и прав доступа в стиле UNIX.

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

Системный раздел и безопасный режим

Системный раздел содержит ядро ​​Android, а также библиотеки операционной системы, среду выполнения приложений, инфраструктуру приложений и приложения. Этот раздел доступен только для чтения. Когда пользователь загружает устройство в безопасном режиме, сторонние приложения могут запускаться вручную владельцем устройства, но не запускаются по умолчанию.

Разрешения файловой системы

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

Linux с улучшенной безопасностью (SELinux)

Как часть модели безопасности Android, Android использует Security-Enhanced Linux (SELinux) для обеспечения обязательного контроля доступа (MAC) ко всем процессам, даже процессам, работающим с привилегиями root/superuser. С помощью SELinux Android может лучше защищать и ограничивать системные службы, контролировать доступ к данным приложений и системным журналам, уменьшать влияние вредоносного программного обеспечения и защищать пользователей от потенциальных ошибок в коде на мобильных устройствах.

SELinux работает по принципу отказа по умолчанию: все, что явно не разрешено, запрещается.

Верифицированная загрузка (Verified Boot)

Verified Boot стремится к тому, чтобы весь исполняемый код был получен из надежного источника (обычно это производители устройств), а не от злоумышленника. Он устанавливает полную цепочку доверия, начиная с аппаратной защитой корня доверия к загрузчику, в загрузочном разделе и другие проверенных разделы, включая system, vendor и необязательно oem перегородки. Во время загрузки устройства каждый этап проверяет целостность и подлинность следующего этапа перед передачей выполнения.

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

В дополнение к проверке ОС, Verified Boot также позволяет устройствам Android сообщать пользователю о своем состоянии целостности.

Криптография

Android предоставляет набор криптографических API для использования приложениями. К ним относятся реализации стандартных и обычно используемых криптографических примитивов, таких как AES, RSA, DSA и SHA. Кроме того, API предоставляются для протоколов более высокого уровня, таких как SSL и HTTPS.

Root-доступ

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

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

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

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

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

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

Функции безопасности пользователя

Шифрование файловой системы

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

У Android есть два метода шифрования устройства: шифрование на основе файлов и полное шифрование диска.

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

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

Android 7.0 и более поздние версии поддерживают шифрование на основе файлов. Файловое шифрование позволяет шифровать разные файлы разными ключами, которые можно разблокировать независимо.

Защита паролем

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

Администратор устройства может потребовать использование пароля и/или правил сложности пароля.

Администрирование устройства

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

Trusty TEE

Trusty - это безопасная операционная система, которая предоставляет Trusted Execution Environment (TEE) для Android. Trusty OS работает так же как и Android OS, но Trusty изолирован от остальной системы как аппаратным, так и программным обеспечением. Trusty и Android работают параллельно друг другу. У Trusty есть доступ ко всей мощности основного процессора устройства и памяти, но он полностью изолирован. Изоляция Trusty защищает его от вредоносных приложений, установленных пользователем, и потенциальных уязвимостей, которые могут быть обнаружены в Android.

Trusty совместим с процессорами ARM и Intel. В системах ARM Trusty использует ARM Trustzone™ для виртуализации основного процессора и создания безопасной среды надежного выполнения. Аналогичная поддержка также доступна на платформах Intel x86 с использованием технологии виртуализации Intel.

Хранилище ключей (Keystore) с аппаратной поддержкой

Наличие надежной среды выполнения в системе на кристалле (SoC) дает возможность устройствам Android предоставлять аппаратные, надежные службы безопасности для ОС Android, для платформ и даже для сторонних приложений. Хранилище ключей обеспечивает операции цифровой подписи и проверки, а также генерацию и импорт пар ключей асимметричной подписи. Это уже реализовано на многих устройствах, но есть много целей безопасности, которые не могут быть легко достигнуты только с помощью API подписи.

Безопасность Android приложений

Модель разрешений Android: доступ к защищенным API

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

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

Эти защищенные API включают в себя:

  • Функции камеры
  • Данные о местоположении (GPS)
  • Функции Bluetooth
  • Функции телефонии
  • Функции SMS / MMS
  • Интернет

Эти ресурсы доступны только через операционную систему. Чтобы использовать защищенные API-интерфейсы на устройстве, приложение должно определить возможности, необходимые для его манифеста. Все версии Android 6.0 и выше используют модель разрешений во время исполнения приложения (Runtime Permission Model). Если пользователь запрашивает функцию из приложения, для которого требуется защищенный API, система отображает диалоговое окно, предлагающее пользователю отклонить или разрешить действие.

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

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

Проверки разрешений защищенного API применяются на самом низком уровне для предотвращения обхода.

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

Межпроцессное взаимодействие

Процессы могут взаимодействовать с использованием любого из традиционных механизмов типа UNIX. Примеры включают файловую систему, локальные сокеты или сигналы. Тем не менее, разрешения (permissions) Linux по-прежнему применяются.

Android также предоставляет новые механизмы IPC:

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

Services могут предоставлять интерфейсы, напрямую доступные через Binder.

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

ContentProvider - это хранилище данных, которое обеспечивает доступ к данным на устройстве; Классическим примером является ContentProvider, который используется для доступа к списку контактов пользователя. Приложение может получить доступ к данным, которые другие приложения предоставили через ContentProvider, и приложение также может определить свои собственные данные.

API, содержащий операции, вызывающие издержки (Cost-Sensitive APIs)

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

Эти API включают в себя:

  • Телефония
  • SMS / MMS
  • Интернет
  • Биллинг в приложении (Например, внутриигровые покупки)
  • NFC

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

Доступ к SIM-карте

Низкоуровневый доступ к SIM-карте недоступен сторонним приложениям. ОС обрабатывает все коммуникации с SIM-картой, включая доступ к личной информации (контактам) в памяти SIM-карты. Приложения также не могут получить доступ к AT-командам, поскольку они управляются исключительно на уровне радиоинтерфейса (RIL). RIL не предоставляет API высокого уровня для этих команд.

Личные данные

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

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

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

Устройства ввода, связанные с конфиденциальными данными

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

Метаданные

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

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

Центры сертификации (Certificate authorities)

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

Чтобы добавить его в качестве нового общедоступного ЦС в набор акций Android, ЦС должен завершить процесс включения в Mozilla ЦС, а затем подать запрос на добавление в стандартный Android ЦС, связанный с Android Open Source Project.

Все еще существуют ЦС, которые являются специфичными для устройства и не должны включаться в базовый набор ЦС AOSP, как частные ЦС операторов, которые могут понадобиться для безопасного доступа к компонентам инфраструктуры оператора, таким как шлюзы SMS / MMS. Производителям устройств рекомендуется включать частные ЦС только в те компоненты / приложения, которым необходимо доверять этим ЦС.

Цифровая подпись приложения (Application Signing)

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

В Google Play подписывание приложений дает доверие Google к разработчику и доверие разработчика к их приложению. Разработчики знают, что их приложение предоставляется без изменений на устройство Android; и разработчики могут нести ответственность за поведение своих приложений.

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

Когда приложение (файл APK) установлено на устройстве Android, диспетчер пакетов проверяет, что APK был правильно подписан с помощью сертификата, включенного в этот APK. Если сертификат (или, точнее, открытый ключ в сертификате) соответствует ключу, используемому для подписи любого другого APK на устройстве, новый APK имеет возможность указать в манифесте, что он будет использовать UID с другим аналогичным образом. подписанные АПК.

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

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

Управление цифровыми правами

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

Платформа Android DRM реализована в двух архитектурных слоях:

API инфраструктуры DRM, который предоставляется приложениям через платформу приложений Android и запускается через виртуальную машину Dalvik для стандартных приложений.

Менеджер DRM с собственным кодом, который реализует структуру DRM и предоставляет интерфейс для подключаемых модулей (агентов) DRM для управления правами и дешифрования для различных схем DRM.

Аутентификация

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

Хранилище криптографических ключей и поставщик услуг (Content provider): Хранит криптографические ключи и предоставляет стандартные криптографические процедуры поверх этих ключей. Android поддерживает аппаратное хранилище ключей и Keymaster для криптографических служб, включая аппаратную криптографию для хранения ключей, которая может включать в себя Trusted Execution Environment (TEE) или Secure Element (SE).

Аутентификаторы пользователей (User authenticators): Подтверждение присутствия пользователя и / или успешной аутентификации. Android поддерживает Gatekeeper для аутентификации по PIN / шаблону / паролю и по отпечатку пальца для аутентификации. Эти компоненты связывают свое состояние аутентификации со службой хранилища ключей через аутентифицированный канал. (Система хранилища ключей Android на уровне инфраструктуры также поддерживается службой хранилища ключей.)

Компоненты Gatekeeper, Fingerprint и Biometric работают с Keystore и другими компонентами для поддержки использования токенов аутентификации с аппаратной поддержкой (AuthTokens).

Регистрация

При первой загрузке устройства после сброса к заводским настройкам все аутентификаторы готовы получать регистрационные данные от пользователя. Пользователь должен сначала зарегистрировать PIN-код / ​​шаблон / пароль в Gatekeeper. Эта первоначальная регистрация создает случайно сгенерированный 64-битный безопасный идентификатор пользователя (SID), который служит идентификатором для пользователя и маркером привязки для криптографического материала пользователя. Этот SID пользователя криптографически связан с паролем пользователя; успешные аутентификации в Gatekeeper приводят к AuthTokens, которые содержат SID пользователя для этого пароля.

Аутентификация

После того, как пользователь установил учетные данные и получил SID пользователя, он может начать аутентификацию, которая начинается, когда пользователь предоставляет PIN-код, шаблон, пароль или отпечаток пальца. Все компоненты TEE имеют секретный ключ, который они используют для аутентификации сообщений друг друга.