Защита данных и зашифрованная файловая система

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

иобеспечения того, чтобы система работала должным образом). Для защиты данных в дежурном режиме Android и iOS использу-

ют шифрование на уровне файлов (file-based encryption, FBE) и полное шифрование диска (full disk encryption, FDE), а для защиты передава-

емых данных платформы могут шифровать эти данные. Но оба эти элемента должны быть реализованы разработчиком с использовани- ем соответствующих параметров в предоставленных API. Версии An- droid до 7.0 не поддерживают FBE, а версии до 4.4 не поддерживают даже FDE. На платформе iOS вы можете добиться шифрования фай- лов,даже когда устройство меняетсостояние (например,если устрой- ство инициировано или разблокировано или если пользователь хотя бы один раз прошел аутентификацию).

Тестовая среда приложения,безопасный IPC и службы

Android и iOS также изолируют компоненты платформы. Обе плат- формы используют разрешения в стиле Unix,обеспечиваемые ядром, для достижения раздельного контроля доступа и формирования изо- лированной программной среды приложения. На Android каждое приложение запускается как обособленный пользователь со своим собственным UID. Также существует «песочница» для системных процессов и служб, включая телефон, Wi-Fi и стек Bluetooth. Android также имеет обязательный контроль доступа, который определяет разрешенные действия для каждого процесса или набора процессов с использованием Security Enhanced Linux (SE-Linux). В свою очередь все приложения iOS запускаются отимени одного итого же пользова- теля, но каждое приложение изолировано в песочнице, аналогичной Android, и получает доступ только к своей части файловой системы. Крометого,ядро iOS запрещаетприложениям выполнять определен- ные системные вызовы. Обе платформы используют подход в стиле разрешений для конкретных приложений, чтобы обеспечить безо- пасное взаимодействие между процессами идоступ к общимданным (разрешения Android, права iOS). Эти разрешения объявляются на этаперазработкиприложенияипредоставляютсявовремяустановки или выполнения.Обе платформытакже реализуютаналогичную изо- ляцию на уровне ядра за счет сокращения доступа к драйверам или изолирования кода драйверов.

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

вофициальный магазин приложений платформы, но есть различия

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

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

Аутентификация пользователя

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

Управление изолированными аппаратными компонентами и ключами

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