iOS_8_3_Security_WP_RS
.pdfСтирание всего контента и настроек
Команда «Стереть контент и настройки»
вНастройках вызывает уничтожение всех ключей в стираемом накопителе,
врезультате чего все пользовательские данные на устройстве становятся криптографически недоступными. Следовательно, этот вариант является идеальным способом надежного удаления всей персональной информации с устройства перед его передачей другому
пользователю или в службу поддержки. Внимание! Не выбирайте «Стереть контент и настройки», пока не создана резервная копия устройства, поскольку стертые данные восстановить невозможно.
Все другие криптографические ключи, кроме UID и GID, создаются системным генератором случайных чисел с использованием алгоритма на основе CTR_DRBG. Источником энтропии системы являются колебания времени при загрузке, а также колебания времени обработки прерываний после загрузки устройства. Для генерирования ключей внутри Secure Enclave используется аппаратный
генератор истинно случайных чисел: в его основе лежат нескольких кольцевых генераторов, сигнал которых обрабатывается генератором CTR_DRBG.
Надежное стирание сохраненных ключей так же важно, как их генерирование. Особую сложность представляет стирание на флэш-памяти, поскольку из-за алгоритма нивелирования износа может потребоваться стереть несколько копий данных. Для решения этой проблемы в устройствах iOS предусмотрена специальная функция, предназначенная для надежного стирания данных. Функция называется «Стираемый накопитель». Функция обращается к базовой технологии накопителя (например, NAND) для получения прямого доступа и очистки небольшого количества блоков на очень низком уровне.
Защита данных в файлах
Помимо функций аппаратного шифрования, встроенных в устройства iOS, Apple использует специальную технологию защиты данных для более надежной защиты данных, хранящихся во флэш-памяти на устройстве. Технология защиты данных позволяет устройству реагировать на обычные события, такие как поступление телефонного вызова, а также обеспечивает более высокий уровень шифрования данных пользователей. Основные системные программы, такие как Сообщения, Mail, Календарь, Контакты, Фото и Медданные, используют технологию защиты данных по умолчанию, а программы сторонних разработчиков, установленные в iOS 7 или более поздней версии, получают ее автоматически.
Защита данных осуществляется путем построения и контроля иерархии ключей и основана на технологиях аппаратного шифрования, встроенных в каждое устройство iOS. Защита данных организована на уровне файлов: каждому файлу
назначается один из классов защиты, а доступность определяется разблокированием ключей класса.
Обзор архитектуры
При создании файла в разделе данных функция защиты данных создает новый 256-битный ключ («ключ файла») и передает его аппаратному модулю AES, который использует этот ключ для шифрования файла при записи во флэш-память в режиме AES CBC. В начало файла добавляется вектор инициализации (IV), после чего файл шифруется с использованием хэша SHA-1 ключа файла.
Ключ файла защищается с помощью одного из нескольких ключей классов в зависимости от условий, при которых файл должен быть доступен. Как и в других случаях защиты ключей, эта процедура выполняется с помощью шифрования
NIST AES по алгоритму RFC3394. Защищенный ключ файла хранится в метаданных файла.
При открытии файла выполняется дешифрование его метаданных с помощью ключа файловой системы, которое приводит к раскрытию защищенного ключа файла и обозначению класса его защиты. Ключ файла дешифруется с помощью ключа класса, а затем передается аппаратному модулю AES, который выполняет дешифрование файла при чтении из флэш-памяти.
Обзор безопасности iOS | Июнь 2015 г. |
11 |
Рекомендации по паролям
Если введен длинный пароль, содержащий только цифры, вместо полной клавиатуры на экране блокировки отображается цифровая клавиатура. При аналогичном уровне безопасности вводить более длинный цифровой пароль может быть проще, чем короткий буквенно-цифровой.
Метаданные всех файлов файловой системы шифруются с помощью случайного ключа, который создается при первой установке iOS или при стирании данных на устройстве пользователем. Ключ файловой системы хранится в стираемом накопителе. Поскольку этот ключ хранится на устройстве, он не используется для обеспечения конфиденциальности данных; он предназначен для быстрого стирания по запросу (запрос может быть инициирован пользователем с помощью пункта «Стереть контент и настройки» или администратором с помощью команды удаленного стирания через сервер управления мобильными устройствами (MDM), Exchange ActiveSync или iCloud). Такой способ стирания ключа делает все файлы криптографически недоступными.
Ключ файловой Аппаратный системы
ключ
Ключ класса |
Метаданные файла |
Содержимое |
|
|
|||
Ключ файла |
файла |
||
|
Пароль
Содержимое файла шифруется с помощью ключа файла, который защищается
спомощью ключа класса и сохраняется в метаданных файла, которые, в свою очередь, шифруются с помощью ключа файловой системы. Ключ класса защищен аппаратным UID. Кроме того, ключи некоторых классов защищены паролем пользователя. Такая иерархия обеспечивает и гибкость, и эффективность. Например, для изменения класса файла достаточно еще раз защитить его
спомощью ключа файла, а изменение пароля приводит просто к повторной защите ключа класса.
Пароли
Установив на устройстве пароль, пользователь автоматически включает защиту данных. iOS поддерживает пароли из четырех цифр и буквенно-цифровые пароли произвольной длины. Помимо разблокирования устройства, пароль является источником энтропии для некоторых ключей шифрования. Это означает, что злоумышленник, завладевший устройством, не сможет получить доступ к данным определенных классов защиты, не зная пароля.
Пароль привязывается к UID устройства, поэтому попытки перебора должны выполняться непосредственно на атакуемом устройстве. Для замедления каждой попытки используется большое число повторений. Число повторений настроено таким образом, что одна попытка занимает примерно 80 миллисекунд.
Это означает, что для перебора всех сочетаний шестизначного буквенно-цифрового пароля, состоящего из строчных букв и цифр, потребуется больше 5,5 лет.
Чем надежнее пароль пользователя, тем надежнее ключ шифрования. А благодаря Touch ID пользователь может установить гораздо более надежный пароль, чем это было бы разумно без него. Это повышает эффективное количество энтропии, используемое для защиты ключей шифрования системы защиты данных, без ущерба для удобства пользователей, которым приходится по несколько раз в день разблокировать устройство iOS.
Обзор безопасности iOS | Июнь 2015 г. |
12 |
Для дальнейшего усложнения атаки методом перебора интерфейс iOS увеличивает временные задержки после ввода неправильного пароля на экране блокировки. При желании пользователи могут включить автоматическое стирание данных с устройства после 10 попыток ввода неверного пароля подряд. Эта функция также
доступна при настройке политики администрирования через сервер управления мобильными устройствами (MDM) и Exchange ActiveSync. Можно также установить более низкий порог срабатывания.
На устройствах с процессором A7 или более новым процессором А-серии
за выполнение операций с ключами отвечает сопроцессор Secure Enclave, который также применяет принудительную 5-секундную задержку между повторными неудавшимися запросами разблокировки. Это обеспечивает защиту от атак методом перебора, дополняя средства защиты, применяемые iOS.
Классы защиты данных
Когда программа создает новый файл на устройстве с iOS, она назначает ему класс. Каждый класс использует различные политики для определения условий доступа к данным. Основные классы и политики описаны в следующих разделах.
Полная защита
(NSFileProtectionComplete). Ключ класса защищается с помощью ключа, полученного из пароля пользователя и UID устройства. Вскоре после того, как пользователь блокирует устройство (через 10 секунд, если параметр «Запрос пароля» имеет значение «Сразу»), расшифрованный ключ класса удаляется, в результате чего все данные этого класса остаются недоступны, пока пользователь снова не введет пароль или не разблокирует устройство с помощью Touch ID.
Защищено, если не открыто
(NSFileProtectionCompleteUnlessOpen). Пока устройство заблокировано,
может возникнуть потребность в записи файлов. В качестве примера можно привести загрузку почтового вложения в фоновом режиме. Такое действие становится возможным благодаря использованию асимметричной эллиптической криптографии (ECDH по Curve25519). Для защиты обычного ключа файла используется ключ, полученный в результате однопроходного согласования ключей Диффи-Хеллмана, как описано в документе NIST SP 800-56A.
Динамический общий ключ для согласования хранится вместе с защищенным ключом файла. В качестве KDF используется функция формирования ключа сцеплением (утвержденная альтернатива 1) согласно пункту 5.8.1 документа
NIST SP 800-56A. AlgorithmID опускается. PartyUInfo и PartyVInfo — это динамический и статический общие ключи, соответственно. В качестве функции хэширования используется SHA-256. Сразу после закрытия файла ключ файла удаляется
из памяти. Для повторного открытия снова создается общий ключ на основе личного ключа класса «Защищено, если не открыто» и динамического общего ключа; его хэш используется для снятия защиты с ключа файла, который затем используется для дешифрования файла.
Защищено до первой аутентификации пользователя
(NSFileProtectionCompleteUntilFirstUserAuthentication).
Действие этого класса аналогично классу «Полная защита», однако расшифрованный ключ класса не удаляется из памяти при блокировке устройства. Защита этого класса похожа на шифрование дисков настольных систем и защищает данные от атак, которые используют перезагрузку устройства. Этот класс по умолчанию используется для всех программ сторонних разработчиков, которым не назначен класс защиты данных.
Обзор безопасности iOS | Июнь 2015 г. |
13 |
Компоненты элемента связки ключей
Помимо группы доступа, каждый элемент связки ключей содержит административные метаданные (такие как метки времени создания и последнего изменения).
Он также содержит хэши SHA-1 для атрибутов (таких как учетная запись и имя сервера), используемых при
поиске элемента, чтобы можно было выполнять поиск без дешифрования каждого элемента. Наконец, он содержит данные по шифрованию, включая:
•номер версии;
•данные списка контроля доступа (ACL);
•значение, которое указывает класс защиты элемента;
•ключ элемента, защищенный
спомощью ключа класса защиты;
•словарь атрибутов, описывающих элемент (который передан
в SecItemAdd); словарь закодирован как двоичный файл plist и зашифрован
спомощью ключа элемента.
Шифрование выполняется по алгоритму AES 128 в режиме GCM (Галуа/счетчик); в состав атрибутов входит группа доступа, защищенная тегом GMAC, который вычисляется при шифровании.
Без защиты
(NSFileProtectionNone). Ключ этого класса защищен только с помощью UID и хранится в стираемом накопителе. Поскольку все ключи, необходимые для дешифрования файлов в этом классе, хранятся на устройстве, единственным преимуществом такого шифрования является возможность быстрого удаленного стирания. Даже если файлу не назначен класс защиты данных, он все равно хранится в зашифрованном виде (как и все данные на устройстве iOS).
Защита данных связки ключей
Многим программам для работы необходимы пароли и другие короткие, но конфиденциальные фрагменты данных, например ключи и токены входа.
Связка ключей iOS предоставляет безопасный способ хранения этих элементов.
Связка ключей реализована в виде базы данных SQLite, которая хранится в файловой системе. Существует только одна база данных; демон securityd определяет, к каким элементам связки ключей может обращаться каждый процесс или программа.
API доступа к связке ключей выдают вызовы демону, который запрашивает права группы доступа к связке ключей, заданные для программы, и идентификатор программы. Группы доступа не ограничивают доступ одним процессом, а позволяют нескольким программам совместно использовать элементы связки ключей.
Элементы связки ключей могут использоваться совместно только программами одного и того же разработчика. Для этого программы сторонних разработчиков обязаны использовать группы доступа с префиксом, который был им выделен через программу iOS Developer Program, а в iOS 8 для этого используются группы программ. Для принудительного использования префиксов и уникальных групп программ используется подпись кода, профили обеспечения и программа
iOS Developer Program.
Для защиты данных связки ключей используется структура классов, аналогичная структуре, используемой для защиты данных в файлах. Работа этих классов эквивалентна работе классов защиты данных в файлах, но эти классы используют отдельные ключи и входят в состав API с другими именами.
Доступность |
Защита данных в файлах |
Защита данных связки ключей |
В разблокированном |
NSFileProtectionComplete |
kSecAttrAccessibleWhenUnlocked |
состоянии |
|
|
|
|
|
В заблокированном |
NSFileProtectionCompleteUnlessOpen |
Недоступно |
состоянии |
|
|
|
|
|
После первой |
NSFileProtectionCompleteUntilFirstUser- |
kSecAttrAccessibleAfterFirstUnlock |
разблокировки |
Authentication |
|
|
|
|
Всегда |
NSFileProtectionNone |
kSecAttrAccessibleAlways |
|
|
|
При включении |
Недоступно |
kSecAttrAccessible- |
пароля |
|
WhenPasscodeSetThisDeviceOnly |
Если программа пользуется службами фонового обновления, она может использовать класс kSecAttrAccessibleAfterFirstUnlock для элементов связки ключей, которые необходимы во время фонового обновления.
Обзор безопасности iOS | Июнь 2015 г. |
14 |
Класс kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly доступен только, если на устройстве установлен пароль. Элементы этого класса существуют только в системном хранилище ключей; они не синхронизируются со связкой ключей iCloud, не включаются в резервные копии и не включаются в хранилища ключей службы ответственного хранения. В случае удаления или сброса пароля ключи класса становятся недействительными, что не позволяет использовать эти элементы.
Другие классы связки ключей имеют эквивалент «Только для этого устройства». При перемещении с устройства во время резервного копирования этот эквивалент защищается с помощью UID, что не позволяет восстановить его на другом устройстве.
Apple достигла отличного баланса между безопасностью и удобством, выбирая классы связки ключей в зависимости от типа защищаемой информации и от того, когда эта информация необходима операционной системе iOS. Например, VPN-сертификат должен быть доступен постоянно, поэтому устройство поддерживает постоянное подключение, но он классифицируется как «без возможности переноса», поэтому не может быть перемещен на другое устройство.
К элементам связки ключей, созданным iOS, применяются следующие классы защиты.
Элемент |
Доступность |
|
|
Пароли Wi-Fi |
После первой разблокировки |
|
|
Учетные записи Mail |
После первой разблокировки |
|
|
Учетные записи Exchange |
После первой разблокировки |
Пароли VPN |
После первой разблокировки |
|
|
LDAP, CalDAV, CardDAV |
После первой разблокировки |
|
|
Токены учетных записей социальных сетей |
После первой разблокировки |
|
|
Ключи шифрования уведомлений Handoff |
После первой разблокировки |
|
|
Токен iCloud |
После первой разблокировки |
|
|
Пароль «Домашней коллекции» |
В разблокированном состоянии |
|
|
Токен «Найти iPhone» |
Всегда |
|
|
Автоответчик |
Всегда |
Резервное копирование iTunes |
В разблокированном состоянии, |
|
без возможности переноса |
|
|
Пароли Safari |
В разблокированном состоянии |
|
|
Сертификаты VPN |
Всегда, без возможности |
|
переноса |
Ключи Bluetooth® |
Всегда, без возможности |
|
переноса |
|
|
Токен службы Apple Push Notification |
Всегда, без возможности |
|
переноса |
|
|
Сертификаты и личный ключ iCloud |
Всегда, без возможности |
|
переноса |
Ключи iMessage |
Всегда, без возможности |
|
переноса |
|
|
Сертификаты и личные ключи, установленные |
Всегда, без возможности |
профилем конфигурации |
переноса |
|
|
PIN-код SIM-карты |
Всегда, без возможности |
|
переноса |
|
|
Обзор безопасности iOS | Июнь 2015 г. |
15 |
Контроль доступа к связке ключей
Для установки политик доступа и требований аутентификации связки ключей могут использовать списки контроля доступа (ACL). Элементы могут задавать условия, требующие участия пользователя, запрещая доступ до тех пор, пока пользователь не пройдет аутентификацию с помощью Touch ID или не введет пароль устройства. Списки контроля доступа оцениваются внутри Secure Enclave и передаются ядру только при соблюдении заданных ограничений.
Доступ к паролям, сохраненным в Safari
Программы iOS могут получать доступ к элементам связки ключей, сохраненным программой Safari для автозаполнения паролей, используя следующие два API:
•SecRequestSharedWebCredential;
•SecAddSharedWebCredential.
Доступ будет предоставлен только в том случае, если разработчик программы, администратор веб-сайта и пользователь дали на это согласие. Разработчики программ выражают свое намерение использовать пароли, сохраненные в Safari, включая в свою программу соответствующие права. Список прав представляет собой список полных доменных имен соответствующих веб-сайтов. Веб-сайты должны разместить файл, подписанный с использованием CMS, со списком уникальных идентификаторов разрешенных программ. При установке программы с правом com.apple.developer.associated-domains операционная система iOS 8
отправляет каждому из перечисленных в списке веб-сайтов TLS-запрос на путь /apple-app-site-association для получения файла. Если подпись выдана объектом, который является действительным для домена и который операционная система iOS считает доверенным, а в файле содержится идентификатор устанавливаемой программы, то iOS помечает веб-сайт и программу как находящиеся
в доверительных отношениях. Только при наличии доверительных отношений вызовы этих двух API приводят к выдаче запроса пользователю, который должен согласиться на передачу паролей программе, а также обновление или удаление паролей.
Хранилища ключей
Ключи для классов защиты данных в файлах и связке ключей организованы в хранилища ключей. iOS использует следующие четыре хранилища ключей:
системное, резервного копирования, передачи и резервного копирования iCloud.
Системное хранилище ключей — это место хранения защищенных ключей, используемых при нормальном функционировании устройства. Например, при вводе пароля выполняется загрузка ключа NSFileProtectionComplete из системного хранилища ключей и дешифрование ключа. Хранилище ключей представляет собой двоичный файл plist с классом «Без защиты», содержимое которого шифруется с помощью ключа, хранящегося в стираемом накопителе.
Для повышения безопасности хранилищ ключей этот ключ стирается и генерируется снова каждый раз, когда пользователь меняет пароль. Расширение ядра AppleKeyStore управляет системным хранилищем ключей и может получать запросы относительно состояния блокировки устройства. Оно отвечает, что устройство разблокировано только в том случае, если все ключи классов в системном хранилище ключей являются доступными и были успешно дешифрованы.
Обзор безопасности iOS | Июнь 2015 г. |
16 |
Хранилище ключей резервного копирования создается в тот момент, когда iTunes создает и сохраняет зашифрованную резервную копию на компьютере, который настроен для хранения резервных копий устройства. Новое хранилище ключей создается с новым набором ключей, и данные резервной копии повторно шифруются с использованием этих новых ключей. Как объяснялось выше, элементы связки ключей «без возможности переноса» остаются защищены ключом
на основе UID; это позволяет восстанавливать их на исходном устройстве, но делает недоступными на другом устройстве.
Для защиты хранилища ключей используется заданный в iTunes пароль, к которому применено 10 000 итераций PBKDF2. Несмотря на большое количество итераций привязка к определенному устройству отсутствует, поэтому, в принципе, на хранилище ключей резервного копирования может быть совершена атака
методом перебора с участием большого числа компьютеров. Для ослабления этой угрозы необходимо использовать достаточно надежный пароль.
Если пользователь решает не шифровать резервные копии iTunes, файлы резервных копий не шифруются независимо от класса защиты данных, однако связка ключей остается защищена ключом на основе UID. Поэтому элементы связки ключей переносятся на новое устройство, только если установлен пароль резервного копирования.
Хранилище ключей передачи используется для синхронизации iTunes и MDM. Благодаря этому хранилищу ключей iTunes может выполнять резервное копирование и синхронизацию, не требуя ввода пароля пользователем, а сервер MDM может удаленно стирать пароль пользователя. Оно хранится на компьютере, который используется для синхронизации с iTunes, или сервере MDM, который управляет устройством.
Хранилище ключей передачи упрощает работу пользователей при синхронизации устройства, которое может требовать доступа ко всем классам данных. Когда защищенное паролем устройство впервые подключается к iTunes, пользователю необходимо ввести пароль. Затем устройство создает хранилище ключей передачи, содержащее ключи того же класса, как используемые на устройстве, но защищенные с помощью нового сгенерированного пароля. Хранилище ключей
передачи и защищающий его ключ делятся между устройством и хостом или сервером, а данные сохраняются на устройстве с классом «Защищено до первой аутентификации пользователя». Поэтому для первого резервного копирования
в iTunes после перезагрузки пользователю необходимо ввести пароль устройства.
При обновлении программного обеспечения используется особый экземпляр хранилища ключей передачи, называемый временным хранилищем ключей. Благодаря ему процесс обновления получает доступ к файлам и элементам связки ключей с любыми уровнями защиты данных. Доступ после перезагрузки устройства в процессе обновления программного обеспечения необходим для запуска модулей переноса данных, которые выполняют такие задачи, как обновление схем баз данных, генерирование предварительного просмотра элементов или даже изменение уровней защиты данных.
В случае беспроводного обновления программного обеспечения пользователь получает запрос на ввод пароля при запуске обновления. Это необходимо для безопасной установки флажка в системном хранилище ключей, который вызывает создание временного хранилища ключей в памяти заблокированного устройства. Когда пользователь готов выполнить обновление, которое может быть произведено только при разблокированном устройстве, временное хранилище ключей записывается на диск и защищается ключом, хранящимся в стираемом накопителе. При выполнении обновления через iTunes с соединенного в пару хоста, содержащего действительное хранилище ключей передачи, пользователь до начала обновления получает запрос на разблокирование устройства, чтобы временное хранилище ключей также могло быть записано на диск, пока устройство разблокировано.
Обзор безопасности iOS | Июнь 2015 г. |
17 |
При запуске модулей переноса данных они вызывают загрузку временного хранилища ключей, предоставляя доступ к ключам классов защиты данных.
В этот момент временное хранилище ключей удаляется с диска, а защищающий его ключ удаляется из стираемого накопителя, чтобы его можно было использовать повторно. По завершении работы модуля переноса данных происходит удаление ключей, которые обычно существуют только при разблокированном устройстве, что переводит устройство в состояние «после первой разблокировки».
Если до выполнения обновления не удалось создать временное хранилище ключей, после перезагрузки устройства на экране будет показана надпись «сдвиньте для обновления» и выведен запрос на ввод пароля для завершения процесса обновления.
Хранилище ключей резервного копирования iCloud похоже на хранилище ключей резервного копирования. Все ключи классов в этом хранилище являются асимметричными (используют Curve25519, как класс «Защищено, если не открыто»), поэтому резервное копирование iCloud может выполняться в фоновом режиме. Для всех классов защиты данных, кроме «Без защиты», зашифрованные данные считываются с устройства и передаются в iCloud. Соответствующие ключи классов защищаются с помощью ключей iCloud. Ключи классов связки ключей защищаются с помощью ключа, полученного из UID, аналогично незашифрованным резервным копиям iTunes. Хранилище асимметричных ключей также используется для резервного копирования, необходимого для восстановлении связки ключей iCloud.
FIPS 140-2
Криптографические модули в iOS 8 проходят проверку на соответствие Федеральному стандарту обработки информации США (FIPS) 140-2, уровень 1. Это подтверждает надежность криптографических операций в программах Apple и сторонних программах, которые надлежащим образом используют криптографические службы iOS. Информацию о проверках предыдущих версий и текущем состоянии iOS 8 см. на странице https://support.apple.com/ru-ru/HT5808.
Обзор безопасности iOS | Июнь 2015 г. |
18 |
Безопасность программ
Программы являются одним из самых важных элементов современной архитектуры безопасности мобильных устройств. Программы не только значительно повышают продуктивность работы пользователей, но и, если не принять должных мер, могут негативно сказываться на безопасности системы, ее стабильности и пользовательских данных.
По этой причине в iOS реализована многоуровневая система защиты для гарантии того, что программы подписаны и проверены, а также запускаются в так называемой «песочнице» для защиты пользовательских данных. Эти элементы создают стабильную, безопасную платформу для работы программ, позволяя
тысячам разработчиков предлагать сотни тысяч программ для iOS без ущерба для целостности системы. А пользователи могут использовать эти программы на своих устройствах iOS, не опасаясь вирусов, вредоносных программ, или других атак.
Подпись кода программ
После запуска ядро iOS определяет, какие процессы пользователей и программы могут быть запущены в системе. Чтобы гарантировать, что все программы получены из известного и утвержденного источника и не подделаны, iOS требует обязательного подписания всего исполняемого кода с помощью выпущенного компанией Apple сертификата. Установленные на устройстве программы, такие как Mail и Safari, подписаны Apple. Программы сторонних разработчиков также должны быть проверены и подписаны с помощью выпущенного компанией Apple сертификата. Обязательная подпись кода расширяет концепцию цепочки доверия с операционной системы на программы и не позволяет программам сторонних разработчиков загружать неподписанные фрагменты кода или использовать самомодифицирующийся код.
Для разработки и установки программ на устройствах iOS разработчики должны зарегистрироваться в Apple и присоединиться к программе iOS Developer Program. Перед выдачей сертификата компания Apple проверяет личность каждого разработчика, будь то частное лицо или компания, в реальном мире. Используя эти сертификаты, разработчики могут подписывать программы и отправлять
их в App Store для распространения. В результате все программы в App Store отправляются идентифицированными людьми и организациями, что выступает в качестве сдерживающего фактора для создания вредоносных программ. Кроме
того, все программы проверяются Apple для гарантии того, что они соответствуют своему описанию и не содержат явных ошибок или других проблем. Эта проверка дает пользователям дополнительную уверенность в качестве программ, которые они покупают.
Обзор безопасности iOS | Июнь 2015 г. |
19 |
Разработчики программ для iOS 8 могут встраивать в свои программы различные структуры, используемые самой программой или встроенными в нее расширениями. Чтобы защитить систему и другие программы от загрузки стороннего кода в их адресное пространство, в момент загрузки система выполняет проверку
подписи кода для всех динамических библиотек, на которые ссылается процесс. Эта проверка выполняется с помощью идентификатора команды, который извлекается из выпущенного компанией Apple сертификата. Идентификатор команды представляет собой десятизначную буквенно-цифровую строку, например 1A2B3C4D5F. Программа может ссылаться на любую библиотеку платформы, поставляемую вместе с системой, и любую библиотеку с таким же идентификатором команды в подписи кода, как у основного исполняемого модуля. Поскольку исполняемые модули, поставляемые с системой, не имеют идентификатора команды, они могут ссылаться только на библиотеки, которые также поставлялись с системой.
У компаний есть возможность разрабатывать корпоративные программы для внутреннего использования и распространять их среди своих сотрудников. Предприятия и организации могут подать заявку на участие в программе iOS Developer Enterprise Program (iDEP), указав свой номер D-U-N-S. Apple
проверяет личность заявителей, их соответствие условиям программы
и утверждает заявки. Став членом iDEP, организация может зарегистрироваться для получения профиля обеспечения, который разрешает запускать собственные программы компании на указанных в нем устройствах. Для запуска корпоративных программ у пользователей должен быть установлен профиль обеспечения. Благодаря этому только санкционированные организацией лица могут загружать программы на свои устройства iOS. Корпоративные программы также проверяют подпись в процессе выполнения. Если срок действия сертификата истек или сертификат отозван, программа не запускается.
В отличие от других мобильных платформ, iOS не разрешает пользователям устанавливать потенциально вредоносные неподписанные программы с веб-сайтов или запускать ненадежный код. В процессе выполнения проводятся проверки подписей кода всех исполняемых страниц памяти, чтобы убедиться, что программа не была изменена с момента установки или последнего использования.
Безопасность в процессе выполнения
Убедившись, что программа получена из надежного источника, iOS применяет специальные средства безопасности для защиты других программ и остальной системы от взлома данной программой.
Все программы сторонних разработчиков помещаются в «песочницу», что ограничивает для них доступ к файлам, хранящимся в других программах, и не позволяет вносить изменения в работу устройства. «Песочница» не дает
программам собирать и изменять информацию, сохраняемую другими программами. Каждая программа использует для своих файлов уникальную домашнюю папку, которая назначается случайным образом при установке программы. Если программе стороннего разработчика необходимо получить доступ к чужой информации, она может сделать это только при помощи специальных служб iOS.
Системные файлы и ресурсы отделены от пользовательских программ. Большинство компонентов iOS, а также все программы сторонних разработчиков работают с правами непривилегированного «мобильного» пользователя.
Весь раздел операционной системы подключен только для чтения. Системное программное обеспечение не содержит ненужных инструментов, таких как службы удаленного входа, а API не позволяют программам расширять свои полномочия для изменения других программ или самой iOS.
Обзор безопасности iOS | Июнь 2015 г. |
20 |