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

Безопасность iOS
iOS 9.0 или более новой версии
Сентябрь 2015 г.
Содержание
Стр. 4
Введение
Стр. 5
Безопасность системы
Безопасная последовательность загрузки
Авторизация системного ПО
Secure Enclave
Touch ID
Стр. 10
Шифрование и защита данных
Аппаратные функции безопасности
Защита данных в файлах
Пароли
Классы защиты данных
Защита данных связки ключей
Доступ к паролям, сохраненным в Safari
Хранилища ключей
Сертификаты и программы обеспечения безопасности
Стр. 19
Безопасность программ
Подпись кода программ
Безопасность в процессе выполнения
Расширения
Группы программ
Защита данных в программах
Аксессуары
HomeKit
HealthKit
Apple Watch
Стр. 30
Безопасность сети
TLS
VPN
Wi-Fi
Bluetooth
Единый вход
Безопасность AirDrop
Стр. 34
Apple Pay
Компоненты Apple Pay
Как в Apple Pay используется защищенный элемент
Как в Apple Pay используется контроллер NFC
Подготовка кредитных и дебетовых карт к использованию
Авторизация платежей
Динамический код безопасности, назначаемый каждой транзакции
Бесконтактные платежи с использованием Apple Pay
Оплата покупок в программах с помощью Apple Pay
Скидочные карты
Приостановка действия, удаление и стирание карт
Обзор безопасности iOS | Сентябрь 2015 г.
2
Стр. 42
Интернет-службы
Apple ID
iMessage
FaceTime
iCloud
Связка ключей iCloud
Siri
Непрерывность
Предложения Spotlight
Стр. 56
Средства управления устройствами
Защита паролем
Модель создания пары iOS
Принудительное применение конфигурации
Управление мобильными устройствами (MDM)
Программа регистрации устройств
Apple Configurator
Ограничения устройства
Ограничения только для сопровождаемых устройств
Удаленное стирание
Функция «Найти iPhone» и блокировка активации
Стр. 63
Настройки конфиденциальности
Службы геолокации
Доступ к персональным данным
Политика конфиденциальности
Стр. 65
Заключение
Всегда на страже безопасности
Стр. 66
Глоссарий
Стр. 68
История правок документа
Обзор безопасности iOS | Сентябрь 2015 г.
3
Введение
Класс защиты данных
«Песочница» программы
ПО
Раздел пользователя
(зашифрован)
Раздел ОС
Файловая система
Ядро
Secure
Enclave
Безопасный
элемент
Оборудование
и прошивка
Криптографический модуль
Ключ устройства
Групповой ключ
Корневой сертификат Apple
На данной схеме архитектуры безопасности
iOS представлен визуальный обзор
различных технологий, которые
рассматриваются в данном документе.
Функции обеспечения безопасности встроены в ядро платформы iOS. Задавшись
целью создать наилучшую мобильную платформу, мы воспользовались накопленным
за десятилетия опытом для построения совершенно новой архитектуры.
Мы подумали о том, какие опасности подстерегают пользователей в среде
персональных компьютеров, и при разработке iOS приняли новый подход
к безопасности. Мы разработали и встроили инновационные функции, которые
повышают безопасность мобильных устройств и по умолчанию защищают
всю систему. В результате iOS демонстрирует значительный прогресс в плане
безопасности мобильных устройств.
Каждое устройство iOS сочетает в себе программное обеспечение, оборудование
и службы, идеальная совместимость которых позволяет гарантировать максимальную
безопасность и прозрачность работы пользователей. iOS защищает не только
само устройство и хранящиеся на нем данные, но и всю цифровую среду, включая
локальные действия пользователей, использование сетей и основных интернет-служб.
iOS и устройства iOS оснащены передовыми функциями безопасности, но при этом их
очень легко использовать. Многие из этих функций включены по умолчанию, поэтому
ИТ-отделам не нужно выполнять обширную настройку. Кроме того, основные функции
безопасности, например шифрование устройств, не имеют никаких параметров,
так что пользователи не могут случайно их отключить. Другие функции, например
Touch ID, облегчают процесс использования устройства, позволяя проще и удобнее
обеспечивать его защиту.
В данном документе представлены сведения о реализации технологий и функций
обеспечения безопасности в платформе iOS. Кроме того, этот документ поможет
объединить технологии и функции безопасности платформы iOS с внутренней
политикой и процедурами организации для удовлетворения своих особых
потребностей в области безопасности.
Этот документ состоит из следующих тематических разделов:
• Безопасность системы. Интегрированные и безопасные программы
и оборудование, которые являются платформой для iPhone, iPad и iPod touch.
• Шифрование и защита данных. Архитектурные и проектные решения, которые
защищают данные пользователя в случае потери или кражи устройства, а также
в случае, если их пытается использовать или изменить несанкционированное лицо.
• Безопасность программ. Системы, которые обеспечивают возможность безопасной
работы программ без нарушения целостности платформы.
• Безопасность сети. Стандартные отраслевые сетевые протоколы, которые
обеспечивают надежную аутентификацию и шифрование данных во время передачи.
• Apple Pay. Разработанная компанией Apple технология безопасных платежей.
• Интернет-службы. Сетевая инфраструктура Apple для отправки сообщений,
синхронизации и резервного копирования.
• Средства управления устройствами. Средства, которые предотвращают
несанкционированное использование устройства и позволяют выполнить
удаленное стирание в случае потери или кражи устройства.
• Настройки конфиденциальности. Функции iOS, которые можно использовать для
контроля доступа к службам геолокации и данным пользователей.
Обзор безопасности iOS | Сентябрь 2015 г.
4
Безопасность системы
Переход в режим обновления
прошивки устройства (DFU)
При восстановлении устройства после
перехода в режим DFU выполняется
возврат в известное исправное
состояние, в котором гарантированно
присутствует только неизмененный
код, который подписан компанией
Apple. Переход в режим DFU можно
выполнить вручную. Сначала подключите
устройство к компьютеру с помощью
USB-кабеля, затем одновременно
нажмите и удерживайте кнопки «Домой»
и «Сон/Пробуждение». По прошествии
8 секунд отпустите кнопку
«Сон/Пробуждение», продолжая
удерживать кнопку «Домой».
Примечание. В режиме DFU на экране
устройства ничего не отображается.
Если появляется логотип Apple,
значит кнопка «Сон/Пробуждение»
удерживалась слишком долго.
Концепция безопасности системы обеспечивает безопасность программного
обеспечения и оборудования всех основных компонентов каждого устройства iOS.
Сюда входит процесс загрузки, обновление программного обеспечения
и Secure Enclave. Эта архитектура является центром безопасности iOS и не оказывает
какого-либо влияния на удобство использования устройства.
Тесная интеграция оборудования и программного обеспечения на устройствах iOS
гарантирует надежность каждого компонента и целостность всей системы. Каждый
шаг — от начальной загрузки iOS и обновления программного обеспечения
до использования программ сторонних разработчиков — анализируется
и проверяется для того, чтобы гарантировать оптимальную совместную работу
оборудования и программного обеспечения и надлежащее использование ресурсов.
Безопасная последовательность загрузки
На каждом этапе загрузки есть компоненты, которые подписаны Apple
с использованием криптографических методов для гарантии целостности
и выполняются только после проверки цепочки доверия. Эти компоненты включают
загрузчики системы, ядро, расширения ядра и прошивку радиомодуля.
Сразу после включения устройства iOS процессор программ исполняет код
загрузочного ПЗУ, которое доступно только для чтения. Этот неизменяемый код,
называемый аппаратным корнем доверия, закладывается в процессе изготовления
микросхемы и считается безоговорочно достоверным. Код загрузочного ПЗУ
содержит открытый ключ корневого сертификата Apple. Используя этот ключ, перед
выполнением загрузки устройство убеждается, что низкоуровневый загрузчик
подписан Apple. Этот этап является первым звеном цепочки доверия, в которой
каждое звено убеждается в том, что следующее звено подписано Apple. Когда
низкоуровневый загрузчик завершает свои процедуры, он проверяет и запускает
загрузчик системы, iBoot, который, в свою очередь, проверяет и запускает ядро iOS.
Эта безопасная последовательность загрузки гарантирует, что низкие уровни
программного обеспечения не подделаны, и позволяет запускать iOS только
на проверенных устройствах Apple.
На устройствах с поддержкой сотовой связи подсистема радиомодуля также
задействует свой собственный аналогичный процесс безопасной загрузки,
в котором используется подписанное программное обеспечение и проверка ключей
процессором радиомодуля.
На устройствах с процессором A7 или более новой версией процессора из серии
А сопроцессор Secure Enclave также задействует процесс безопасной загрузки,
который гарантирует, что его специализированное программное обеспечение
проверено и подписано Apple.
Если одному из этапов этого процесса загрузки не удается загрузить или проверить
следующий этап, процесс загрузки останавливается и на устройстве отображается
сообщение о необходимости подключения к iTunes. Это состояние называется
режимом восстановления. Если загрузочному ПЗУ не удается загрузить или
проверить низкоуровневый загрузчик, оно переходит в режим DFU (обновление
прошивки устройства). В обоих случаях необходимо подключить устройство к iTunes
через USB и восстановить заводские настройки. Дополнительные сведения о том,
как вручную перевести устройство в режим восстановления, можно найти в статье
https://support.apple.com/ru-ru/HT1808. Обзор безопасности iOS | Сентябрь 2015 г.
5
Авторизация системного ПО
Apple регулярно выпускает обновления программного обеспечения в ответ
на возникающие проблемы безопасности и разрабатывает новые функции;
обновления предоставляются для всех поддерживаемых устройств одновременно.
Пользователь получает уведомление о наличии обновления iOS на устройстве
и в iTunes. Обновления передаются через беспроводную сеть, что ускоряет
установку и устранение обнаруженных проблем безопасности.
Вышеописанный процесс загрузки не позволяет устанавливать на устройства
посторонний код — только код, подписанный Apple. Чтобы предотвратить
возможность возврата к предыдущим версиям системы, в которых отсутствуют
новейшие обновления системы безопасности, в iOS используется так называемая
авторизация системного программного обеспечения. Если бы возврат был
возможен, злоумышленник мог бы установить на устройство более раннюю версию
iOS и задействовать уязвимость, которая в текущей версии уже устранена.
На устройствах с процессором A7 или более новым процессором серии A есть
сопроцессор Secure Enclave, который также использует авторизацию системного
ПО для проверки целостности своего программного обеспечения и для защиты
от возврата к предыдущим версиям. См. раздел «Secure Enclave» ниже.
Обновить iOS на устройстве можно через iTunes или через беспроводную сеть.
При использовании iTunes загружается и устанавливается полная копия iOS.
При беспроводном обновлении загружаются только те компоненты, которые
необходимы для обновления системы — тем самым оптимизируется расход
трафика. Кроме того, обновления можно кэшировать на сервере в локальной
сети, где установлена система OS X Server и запущена служба кэширования.
Тогда устройствам iOS не придется обращаться к серверам Apple для загрузки
обновлений.
При обновлении iOS программа iTunes (или само устройство, если выполняется
беспроводное обновление) подключается к серверу авторизации установки
Apple и отправляет ему список криптографических показателей для каждой части
установочного пакета, которую предстоит установить (например, низкоуровневый
загрузчик, iBoot, ядро, образ ОС), случайное значение (nonce) для функции
антиповтора и уникальный идентификатор устройства (ECID).
Сервер авторизации сверяет полученные значения с теми, для которых разрешена
установка. Если соответствие найдено, сервер добавляет ECID к показателям
и подписывает результат. В процессе обновления сервер передает на устройство
полный комплект подписанных данных. Добавление ECID необходимо, чтобы сделать
авторизацию запрашивающего устройства уникальной. Выполняя авторизацию
и выдавая подпись на основе известных значений показателей, сервер гарантирует,
что обновление будет происходить именно так, как предусмотрено Apple.
Проверка цепочки доверия в момент загрузки позволяет убедиться, что
подпись исходит от Apple, а значения показателей объекта, загруженного с диска,
в сочетании с ECID устройства, совпадают с теми, на которые распространяется
подпись.
Все эти этапы гарантируют, что авторизация выполнена для данного конкретного
устройства, а более старую версию iOS нельзя будет скопировать с одного
устройства на другое. Значение nonce не позволяет злоумышленнику сохранить
ответ сервера и использовать его для взлома устройства или какого-либо
изменения системного ПО.
Обзор безопасности iOS | Сентябрь 2015 г.
6
Secure Enclave
Secure Enclave — это сопроцессор, встроенный в процессор A7 и более новые
версии процессоров серии А. В нем используется собственная безопасная загрузка
и персонализированные обновления ПО, отдельные от процессора программ.
Он обеспечивает выполнение всех криптографических операций для управления
ключами защиты данных и обеспечивает целостность системы защиты даже в тех
случаях, когда нарушена работа ядра.
Secure Enclave использует шифрованную память и включает в себя аппаратный
генератор случайных чисел. Его микроядро построено на базе семейства L4
и содержит ряд модификаций, внесенных Apple. Обмен данными между
Secure Enclave и процессором программ ограничен почтовым ящиком,
который управляется прерываниями, и общими буферами данных в памяти.
При изготовлении каждый сопроцессор Secure Enclave получает свой собственный
уникальный идентификатор (UID), который недоступен другим компонентам
системы и неизвестен компании Apple. Во время запуска устройства создается
динамический ключ, который связан с UID. С помощью этого ключа выполняется
шифрование области памяти устройства, которая предназначена для
Secure Enclave.
Кроме того, все данные, сохраняемые сопроцессором Secure Enclave в файловой
системе, шифруются с помощью ключа, который связан с UID и счетчиком
антиповтора.
Secure Enclave отвечает за обработку данных, получаемых датчиком Touch ID.
Он сверяет отпечаток с зарегистрированными отпечатками и разрешает доступ
или покупку от имени пользователя. Датчик Touch ID обменивается данными
с процессором по шине последовательного периферийного интерфейса.
Процессор не может прочитать эти данные, а просто перенаправляет
их сопроцессору Secure Enclave. Для шифрования и аутентификации этих данных
используется ключ сеанса, который согласовывается с помощью общего ключа
устройства, выделенного для датчика Touch ID и Secure Enclave. При обмене
ключом сеанса используется алгоритм защиты ключа AES: обе стороны
предоставляют случайный ключ, который задает ключ сеанса и использует
транспортное шифрование AES-CCM.
Touch ID
Touch ID — это система считывания отпечатков пальцев, которая делает процесс
безопасного доступа к устройству быстрее и удобнее. Эта технология считывает
отпечатки пальцев под любым углом. При каждом использовании датчик выявляет
дополнительные перекрывающиеся узловые точки, расширяя базу данных
об отпечатках пальцев пользователя.
Touch ID повышает рациональность использования более длинного и сложного
пароля, поскольку его не нужно будет вводить слишком часто. Touch ID также
преодолевает неудобства, вызываемые блокировкой устройства с помощью
пароля, не заменяя ее, а предоставляя разумную степень доступа к устройству
с минимальными потерями времени.
Обзор безопасности iOS | Сентябрь 2015 г.
7
Touch ID и пароли
Для использования Touch ID необходимо настроить устройство таким образом,
чтобы для его разблокировки требовался пароль. Если Touch ID сканирует
и распознает зарегистрированный отпечаток пальца, устройство разблокируется,
не запрашивая пароля. В любой момент вместо использования Touch ID можно
ввести пароль. Также пароль требуется в следующих ситуациях:
• устройство только что включено или перезапущено;
• устройство не разблокировалось более 48 часов;
• устройство получило команду удаленной блокировки;
• выполнено пять неудачных попыток сравнения отпечатка пальца;
• выполняется настройка или регистрация новых отпечатков пальцев в Touch ID.
Если включена технология Touch ID, устройство блокируется сразу после
нажатия кнопки «Сон/Пробуждение». Если используется только пароль, многие
пользователи задают отсрочку блокировки устройства, чтобы не вводить пароль
при каждом использовании. При использовании Touch ID блокировка устройства
выполняется при каждом переходе в режим сна, и при каждом пробуждении
необходимо приложить палец к сканеру или ввести пароль.
Touch ID можно обучить распознаванию до пяти различных пальцев. Если
зарегистрирован только один палец, вероятность случайного совпадения
с отпечатком другого пользователя составляет 1 к 50 000. Однако Touch ID
допускает только пять неудавшихся попыток сравнения отпечатка пальца, а затем
для получения доступа пользователю потребуется ввести пароль.
Другие варианты использования Touch ID
Touch ID также можно настроить для авторизации покупок в iTunes Store, App Store
и iBooks Store, чтобы пользователю не приходилось вводить пароль Apple ID.
Когда пользователь решает совершить покупку, устройство и магазин
обмениваются токенами аутентификации. Токен и криптографическое значение
nonce сохраняются в Secure Enclave. Значение nonce подписывается с помощью
ключа Secure Enclave, общего для всех устройств и iTunes Store.
Кроме того, Touch ID можно применять при использовании технологии безопасных
платежей Apple Pay, разработанной Apple. Подробнее об этом рассказано
в разделе данного документа, посвященном Apple Pay.
Кроме того, программы сторонних разработчиков могут использовать системные
API для аутентификации пользователя с помощью Touch ID или пароля. Программа
просто получает уведомление об успешном или безуспешном прохождении
аутентификации; она не имеет доступа к Touch ID или данным, которые связаны
с зарегистрированными отпечатками пальцев.
Touch ID также можно использовать для защиты элементов связки ключей —
в этом случае Secure Enclave будет разблокировать элементы связки ключей только
в случае совпадения отпечатка пальца или пароля устройства. В распоряжении
разработчиков программ также есть API, позволяющие убедиться, что пользователь
установил пароль и, следовательно, может выполнять аутентификацию или
разблокировать элементы связки ключей с помощью Touch ID.
В программах для iOS 9 разработчики могут запрещать применение пароля
программы или устройства для выполнения операций, использующих API Touch ID.
Это позволяет использовать Touch ID не только для получения данных
о зарегистрированных пальцах, но и в качестве второго фактора аутентификации
в программах с повышенными требованиями к безопасности.
Обзор безопасности iOS | Сентябрь 2015 г.
8
Безопасность Touch ID
Датчик отпечатков пальцев активируется только, когда окружающее кнопку
«Домой» емкостное сенсорное кольцо из нержавеющей стали распознает
прикосновение пальца; затем усовершенствованная матрица сканирует палец
и отправляет изображение в Secure Enclave.
Это растровое изображение временно сохраняется в зашифрованном участке
памяти Secure Enclave, векторизируется для анализа, а затем удаляется. Анализ
использует угловое представление дактилоскопического узора, которое намеренно
создается с потерями, чтобы нельзя было восстановить фактический отпечаток
пальца пользователя. Полученная схема узловых точек сохраняется без какой-либо
идентифицирующей информации в зашифрованном формате, который может быть
прочитан только Secure Enclave. Эта схема никогда не передается
в Apple и не включается в резервные копии iCloud или iTunes.
Каким образом Touch ID разблокирует устройство iOS
Если датчик Touch ID отключен, то при блокировке устройства ключи для
класса защиты данных «Полная», хранящиеся в Secure Enclave, удаляются. Файлы
и элементы связки ключей этого класса недоступны, пока пользователь
не разблокирует устройство, введя пароль.
Если датчик Touch ID включен, то при блокировке устройства ключи не удаляются;
они защищаются с помощью ключа, выделенного для подсистемы Touch ID
в Secure Enclave. Если пользователь пытается разблокировать устройство
и подсистема Touch ID распознает его отпечаток, она предоставляет ключ для
доступа к ключам защиты данных, и устройство разблокируется. Эта процедура
обеспечивает дополнительную защиту, поскольку для разблокировки устройства
требуется взаимодействие подсистем защиты данных и Touch ID.
Ключи, которые необходимы подсистеме Touch ID для разблокировки устройства,
пропадают при перезагрузке устройства и удаляются Secure Enclave по прошествии
48 часов или пяти неудавшихся попыток распознавания Touch ID.
Обзор безопасности iOS | Сентябрь 2015 г.
9
Шифрование и защита данных
Безопасная последовательность загрузки, подпись кода и функции обеспечения
безопасности в процессе выполнения помогают следить за тем, чтобы
на устройстве запускались только надежные программы и фрагменты кода.
В iOS также реализованы дополнительные функции шифрования и защиты
данных для обеспечения безопасности данных пользователей даже в случае
компрометации других частей системы безопасности (например, на устройстве
с несанкционированными модификациями). Это имеет большое значение для
пользователей и ИТ-администраторов, поскольку такой подход обеспечивает
постоянную защиту личной и корпоративной информации, а также предоставляет
средства для мгновенного и полного удаленного стирания в случае потери или
кражи устройства.
Аппаратные функции безопасности
В мобильных устройствах решающее значение имеют скорость
и энергоэффективность. Криптографические операции требуют значительных
ресурсов и могут снижать время работы от аккумулятора или производительность
устройства, если при разработке и реализации не уделить этим аспектам должного
внимания.
В каждом устройстве с iOS имеется специализированный криптографический
модуль AES 256, который встроен непосредственно в канал DMA между флэшпамятью и основной системной памятью для повышения эффективности
шифрования файлов.
Стирание всего контента и настроек
Команда «Стереть контент и настройки»
в Настройках вызывает уничтожение всех
ключей в стираемом накопителе,
в результате чего все пользовательские
данные на устройстве становятся
криптографически недоступными.
Следовательно, этот вариант является
идеальным способом надежного удаления
всей персональной информации
с устройства перед его передачей
другому пользователю или в службу
поддержки. Внимание! Не выбирайте
«Стереть контент и настройки», пока
не создана резервная копия устройства,
поскольку восстановить стертые данные
будет невозможно.
Уникальный идентификатор устройства (UID) и идентификатор группы устройств
(GID) — это 256-битные ключи AES, вшитые (UID) или скомпилированные
(GID) в процессор программ и Secure Enclave на этапе производства. Ни одна
программа или микропрограмма не может прочитать их напрямую; им доступны
только результаты операций шифрования и дешифрования, выполненных
специализированными модулями AES на кристалле с использованием UID или
GID в качестве ключа. Кроме того, UID и GID подсистемы Secure Enclave могут
быть использованы только специализированным AES-модулем Secure Enclave.
Идентификаторы UID являются уникальными для каждого устройства
и не регистрируются компанией Apple или ее поставщиками. Идентификаторы
GID являются общими для всех процессоров одного класса устройств (например,
всех устройств с процессором Apple A8) и используются для некритических
по отношению к безопасности задач, таких как доставка системного программного
обеспечения во время установки и восстановления. Интеграция этих ключей
в микросхему предотвращает их подделку или обход и гарантирует, что они будут
доступны только модулю AES. Кроме того, идентификаторы UID и GID недоступны
через JTAG и другие интерфейсы отладки.
UID обеспечивает возможность криптографической привязки данных к конкретному
устройству. Например, UID входит в иерархию ключей, используемых для защиты
файловой системы, поэтому при физическом перемещении микросхем памяти
из одного устройства в другое файлы будут недоступны. UID не связан ни с каким
другим идентификатором устройства.
Обзор безопасности iOS | Сентябрь 2015 г.
10
За исключением UID и GID, все остальные криптографические ключи создаются
системным генератором случайных чисел с использованием алгоритма на основе
CTR_DRBG. Источником энтропии системы являются колебания времени при
загрузке, а также колебания времени обработки прерываний после загрузки
устройства. Для генерирования ключей внутри Secure Enclave используется
аппаратный генератор истинно случайных чисел: в его основе лежат нескольких
кольцевых генераторов, сигнал которых обрабатывается генератором CTR_DRBG.
Надежное стирание сохраненных ключей так же важно, как их генерирование.
Особую сложность представляет стирание на флэш-памяти, поскольку из-за
алгоритма нивелирования износа может потребоваться стереть несколько
копий данных. Для решения этой проблемы в устройствах с iOS предусмотрена
специальная функция, предназначенная для надежного стирания данных.
Она называется «Стираемый накопитель». Эта функция обращается к базовой
технологии накопителя (например, NAND), чтобы получить прямой доступ
и очистить небольшое количество блоков на очень низком уровне.
Защита данных в файлах
Помимо функций аппаратного шифрования, встроенных в устройства iOS, Apple
использует специальную технологию для более надежной защиты данных,
хранящихся во флэш-памяти на устройстве. Технология защиты данных позволяет
устройству реагировать на обычные события, такие как поступление телефонного
вызова, а также обеспечивает более высокий уровень шифрования данных
пользователей. Основные системные программы, такие как Сообщения, Почта,
Календарь, Контакты, Фото и Медданные, используют технологию защиты данных
по умолчанию, а программы сторонних разработчиков, установленные в iOS 7 или
более поздней версии, получают ее автоматически.
Защита данных осуществляется путем построения и контроля иерархии ключей
и основана на технологиях аппаратного шифрования, встроенных в каждое
устройство iOS. Защита данных организована на уровне файлов: каждому
файлу назначается один из классов защиты, а доступность определяется
разблокированием ключей класса.
Обзор архитектуры
При создании файла в разделе данных функция защиты данных создает новый
256-битный ключ («ключ файла») и передает его аппаратному модулю AES, который
использует этот ключ для шифрования файла при записи во флэш-память в режиме
AES CBC. (На устройствах с процессором A8 используется AES-XTS.) В начало файла
добавляется вектор инициализации (IV), после чего файл шифруется
с использованием хэша SHA-1 ключа файла.
Ключ файла защищается с помощью одного из нескольких ключей классов
в зависимости от условий, при которых файл должен быть доступен. Как и в других
случаях защиты ключей, эта процедура выполняется с помощью шифрования NIST
AES по алгоритму RFC 3394. Защищенный ключ файла хранится в метаданных файла.
При открытии файла выполняется дешифрование его метаданных с помощью
ключа файловой системы, которое приводит к раскрытию защищенного ключа
файла и обозначения класса его защиты. Ключ файла дешифруется с помощью
ключа класса, а затем передается аппаратному модулю AES, который выполняет
дешифрование файла при чтении из флэш-памяти. Вся обработка защищенного
ключа файла выполняется в Secure Enclave; ключ файла никогда не раскрывается
непосредственно процессору программ. При загрузке Secure Enclave согласовывает
динамический ключ с модулем AES. Ключи файла расшифровываются
в Secure Enclave, а затем снова защищаются с помощью динамического ключа
и отправляются обратно процессору программ.
Обзор безопасности iOS | Сентябрь 2015 г.
11
Метаданные всех файлов файловой системы шифруются с помощью случайного
ключа, который создается при первой установке iOS или при стирании данных
на устройстве пользователем. Ключ файловой системы хранится на стираемом
накопителе. Поскольку этот ключ хранится на устройстве, он не используется
для обеспечения конфиденциальности данных; он предназначен для быстрого
стирания по запросу (запрос может быть инициирован пользователем с помощью
пункта «Стереть контент и настройки» или администратором с помощью команды
удаленного стирания через сервер управления мобильными устройствами (MDM),
Exchange ActiveSync или iCloud). Такой способ стирания ключа делает все файлы
криптографически недоступными.
Ключ файловой
системы
Аппаратный
ключ
Ключ класса
Пароль
Метаданные файла
Ключ файла
Содержимое
файла
Содержимое файла шифруется с помощью ключа файла, который защищается
с помощью ключа класса и сохраняется в метаданных файла, которые, в свою
очередь, шифруются с помощью ключа файловой системы. Ключ класса защищен
аппаратным UID. Кроме того, ключи некоторых классов защищены паролем
пользователя. Такая иерархия обеспечивает и гибкость, и эффективность.
Например, для изменения класса файла достаточно еще раз защитить его
с помощью ключа файла, а изменение пароля приводит просто к повторной защите
ключа класса.
Рекомендации по паролям
Если введен длинный пароль,
содержащий только цифры, вместо
полной клавиатуры на экране
блокировки отображается цифровая
клавиатура. При аналогичном уровне
безопасности вводить более длинный
цифровой пароль может быть проще,
чем короткий буквенно-цифровой.
Пароли
Установив на устройстве пароль, пользователь автоматически включает защиту
данных. iOS поддерживает пароли из четырех цифр и буквенно-цифровые пароли
произвольной длины. Помимо разблокирования устройства, пароль является
источником энтропии для некоторых ключей шифрования. Это означает, что
злоумышленник, завладевший устройством, не сможет получить доступ к данным
определенных классов защиты, не зная пароля.
Пароль привязывается к UID устройства, поэтому попытки перебора должны
выполняться непосредственно на атакуемом устройстве. Для замедления каждой
попытки используется большое число повторений. Число повторений настроено
таким образом, что одна попытка занимает примерно 80 миллисекунд.
Это означает, что для перебора всех сочетаний шестизначного буквенноцифрового пароля, состоящего из строчных букв и цифр, потребуется больше
5,5 лет.
Чем надежнее пароль пользователя, тем надежнее ключ шифрования. А благодаря
Touch ID пользователь может установить гораздо более надежный пароль, чем это
было бы разумно при отсутствии данной технологии. Это повышает эффективное
количество энтропии, используемое для защиты ключей шифрования системы
защиты данных, без ущерба для удобства пользователей, которым приходится
по несколько раз в день разблокировать устройство iOS.
Обзор безопасности iOS | Сентябрь 2015 г.
12
Задержки между попытками ввода
пароля
Число попыток Принудительная задержка
1–4
нет
5
1 минута
6
5 минут
7–8
15 минут
9
1 час
Чтобы дополнительно усложнить атаки методом перебора, увеличиваются
временные задержки после ввода неправильного пароля на экране блокировки.
Если параметр «Настройки» > «Touch ID и пароль» > «Стереть данные» включен,
все данные на устройстве будут автоматически стерты после 10 неудачных попыток
ввода пароля подряд. Эта функция также доступна при настройке политики
администрирования через сервер управления мобильными устройствами (MDM)
и Exchange ActiveSync. Кроме того, можно установить более низкий порог
ее срабатывания.
На устройствах с процессором A7 или более новым процессором серии
A Secure Enclave применяет принудительные задержки. Если в течение заданного
времени задержки устройство перезапускается, задержка применяется еще раз,
а таймер запускается заново.
Классы защиты данных
Когда программа создает новый файл на устройстве с 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. Сразу после закрытия файла ключ файла
удаляется из памяти. Для повторного открытия снова создается общий ключ
на основе личного ключа класса «Защищено, если не открыто» и динамического
общего ключа; его хэш используется для снятия защиты с ключа файла, который
затем используется для дешифрования файла.
Защищено до первой аутентификации пользователя
(NSFileProtectionCompleteUntilFirstUserAuthenticati
on). Действие этого класса аналогично классу «Полная защита», однако
расшифрованный ключ класса не удаляется из памяти при блокировке устройства.
Защита этого класса похожа на шифрование дисков настольных систем и защищает
данные от атак, которые используют перезагрузку устройства. Этот класс
по умолчанию используется для всех программ сторонних разработчиков,
которым не назначен класс защиты данных.
Обзор безопасности iOS | Сентябрь 2015 г.
13
Без защиты
(NSFileProtectionNone). Ключ этого класса защищен только с помощью
UID и хранится в стираемом накопителе. Поскольку все ключи, необходимые
для дешифрования файлов в этом классе, хранятся на устройстве, единственным
преимуществом такого шифрования является возможность быстрого удаленного
стирания. Даже если файлу не назначен класс защиты данных, он все равно
хранится в зашифрованном виде (как и все данные на устройстве iOS).
Защита данных связки ключей
Многим программам для работы необходимы пароли и другие короткие,
но конфиденциальные фрагменты данных, например ключи и токены входа.
Связка ключей iOS предоставляет безопасный способ хранения этих элементов.
Связка ключей реализована в виде базы данных SQLite, которая хранится
в файловой системе. Существует только одна база данных; демон securityd
определяет, к каким элементам связки ключей может обращаться каждый процесс
или программа. API доступа к связке ключей выдают вызовы демону, который
запрашивает заданные для программы права «keychain-access-groups» (группы
доступа к связке ключей), «application-identifier» (идентификатор программы)
и «application-group» (группа программы). Группы доступа не ограничивают доступ
одним процессом, а позволяют нескольким программам совместно использовать
элементы связки ключей.
Компоненты элемента связки ключей
Помимо группы доступа, каждый элемент
связки ключей содержит административные
метаданные (такие как метки времени
создания и последнего изменения).
Он также содержит хэши SHA-1 для
атрибутов (таких как учетная запись
и имя сервера), используемых при поиске
элемента, чтобы можно было выполнять
поиск без дешифрования каждого элемента.
Наконец, он содержит данные
по шифрованию, включая:
• номер версии;
• данные списка контроля доступа (ACL);
• значение, которое указывает класс
защиты элемента;
• ключ элемента, защищенный с помощью
ключа класса защиты;
• словарь атрибутов, описывающих элемент
(который передан в SecItemAdd); словарь
закодирован как двоичный файл plist
и зашифрован с помощью ключа элемента.
Шифрование выполняется по алгоритму
AES 128 в режиме GCM (Галуа/счетчик);
в состав атрибутов входит группа доступа,
защищенная тегом GMAC, который
вычисляется при шифровании.
Элементы связки ключей могут использоваться совместно только программами
одного и того же разработчика. Для этого программы сторонних разработчиков
обязаны использовать группы доступа с префиксом, который был выделен
им через программу iOS Developer Program путем распределения по группам
программ. Для принудительного использования префиксов и уникальных групп
программ используется подпись кода, профили обеспечения и программа
iOS Developer Program.
Для защиты данных связки ключей используется структура классов, аналогичная
структуре, используемой для защиты данных в файлах. Работа этих классов
эквивалентна работе классов защиты данных в файлах, но эти классы используют
отдельные ключи и входят в состав API с другими именами.
Доступность
Защита данных в файлах
Защита данных связки ключей
В разблокированном состоянии
NSFileProtectionComplete
kSecAttrAccessibleWhenUnlocked
В заблокированном состоянии
NSFileProtectionCompleteUnlessOpen
Недоступно
После первой
разблокировки
NSFileProtectionCompleteUntilFirstUserAuthentication
kSecAttrAccessibleAfterFirstUnlock
Всегда
NSFileProtectionNone
kSecAttrAccessibleAlways
При включении
пароля
Недоступно
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
Если программа пользуется службами фонового обновления, она может
использовать класс kSecAttrAccessibleAfterFirstUnlock для элементов
связки ключей, которые необходимы во время фонового обновления.
Обзор безопасности iOS | Сентябрь 2015 г.
14
Класс kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly работает
так же, как и kSecAttrAccessibleWhenUnlocked, однако его можно использовать,
только если на устройстве задан пароль. Элементы этого класса существуют только
в системном хранилище ключей; они не синхронизируются со связкой ключей
iCloud и не включаются ни в резервные копии, ни в хранилища ключей службы
ответственного хранения. В случае удаления или сброса пароля ключи класса
становятся недействительными, что не позволяет использовать эти элементы.
Другие классы связки ключей имеют эквивалент «Только для этого устройства».
При перемещении с устройства во время резервного копирования этот эквивалент
защищается с помощью UID, что не позволяет восстановить его на другом
устройстве.
Apple достигла отличного баланса между безопасностью и удобством, выбирая
классы связки ключей в зависимости от типа защищаемой информации и от того,
когда эта информация необходима операционной системе iOS. Например, VPNсертификат должен быть доступен постоянно, поэтому устройство поддерживает
постоянное подключение, но он классифицируется как «без возможности переноса»,
поэтому не может быть перемещен на другое устройство.
К элементам связки ключей, созданным iOS, применяются следующие классы защиты.
Элемент
Доступность
Пароли Wi-Fi
После первой разблокировки
Учетные записи Почты
После первой разблокировки
Учетные записи Exchange
После первой разблокировки
Пароли VPN
После первой разблокировки
LDAP, CalDAV, CardDAV
После первой разблокировки
Токены учетных записей социальных сетей
После первой разблокировки
Ключи шифрования уведомлений Handoff
После первой разблокировки
Токен iCloud
После первой разблокировки
Пароль «Домашней коллекции»
В разблокированном состоянии
Токен «Найти iPhone»
Всегда
Автоответчик
Всегда
Резервное копирование iTunes
В разблокированном состоянии,
без возможности переноса
Пароли Safari
В разблокированном состоянии
Закладки Safari
В разблокированном состоянии
Сертификаты VPN
Всегда, без возможности переноса
Ключи Bluetooth®
Всегда, без возможности переноса
Токен службы Apple Push Notification
Всегда, без возможности переноса
Сертификаты и личный ключ iCloud
Всегда, без возможности переноса
Ключи iMessage
Всегда, без возможности переноса
Сертификаты и личные ключи, установленные профилем
конфигурации
Всегда, без возможности переноса
PIN-код SIM-карты
Всегда, без возможности переноса
Контроль доступа к связке ключей
Для установки политик доступа и требований аутентификации связки ключей могут
использовать списки контроля доступа (ACL). Элементы могут задавать условия,
требующие участия пользователя, запрещая доступ до тех пор, пока пользователь
не пройдет аутентификацию с помощью Touch ID или не введет пароль устройства.
Списки контроля доступа оцениваются внутри Secure Enclave и передаются ядру
только при соблюдении заданных ограничений.
Обзор безопасности iOS | Сентябрь 2015 г.
15
Доступ к паролям, сохраненным в Safari
Программы iOS могут получать доступ к элементам связки ключей, сохраненным
программой Safari для автозаполнения паролей, используя следующие два API:
• SecRequestSharedWebCredential;
• SecAddSharedWebCredential.
Доступ будет предоставлен только в том случае, если разработчик программы,
администратор веб-сайта и пользователь дали на это согласие. Разработчики
программ выражают свое намерение использовать пароли, сохраненные в Safari,
включая в свою программу соответствующие права. Список прав представляет собой
список полных доменных имен соответствующих веб-сайтов. Веб-сайты должны
разместить на своем сервере файл со списком уникальных идентификаторов
разрешенных программ. При установке программы с правом com.apple.developer.
associated-domains операционная система iOS отправляет каждому из перечисленных
в списке веб-сайтов TLS-запрос на путь /apple-app-site-association для получения
файла. Если в файле указан идентификатор устанавливаемой программы, то iOS
помечает, что между веб-сайтом и программой существуют доверительные
отношения. Только при наличии доверительных отношений вызовы этих двух API
приводят к выдаче запроса пользователю, который должен согласиться на передачу
паролей программе, а также обновление или удаление паролей.
Хранилища ключей
Ключи для классов защиты данных в файлах и связке ключей организованы
в хранилища ключей. iOS использует следующие четыре хранилища ключей: система,
резервное копирование, передача и резервное копирование iCloud.
Системное хранилище ключей — это место хранения защищенных ключей,
используемых при нормальном функционировании устройства. Например, при вводе
пароля выполняется загрузка ключа NSFileProtectionComplete из системного
хранилища ключей и дешифрование ключа. Хранилище ключей представляет собой
двоичный файл plist с классом «Без защиты», содержимое которого шифруется
с помощью ключа, хранящегося в стираемом накопителе. Для повышения
безопасности хранилищ ключей этот ключ стирается и генерируется снова каждый
раз, когда пользователь меняет пароль. Расширение ядра AppleKeyStore управляет
системным хранилищем ключей и может получать запросы относительно состояния
блокировки устройства. Оно отвечает, что устройство разблокировано только
в том случае, если все ключи классов в системном хранилище ключей являются
доступными и были успешно дешифрованы.
Хранилище ключей резервного копирования создается в тот момент, когда
iTunes создает и сохраняет зашифрованную резервную копию на компьютере,
который настроен для хранения резервных копий устройства. Новое хранилище
ключей создается с новым набором ключей, и данные резервной копии повторно
шифруются с использованием этих новых ключей. Как объяснялось выше, элементы
связки ключей «без возможности переноса» остаются защищены ключом
на основе UID; это позволяет восстанавливать их на исходном устройстве,
но делает недоступными на другом устройстве.
Для защиты хранилища ключей используется заданный в iTunes пароль, к которому
применено 10 000 итераций PBKDF2. Несмотря на большое количество итераций
привязка к определенному устройству отсутствует, поэтому, в принципе,
на хранилище ключей резервного копирования может быть совершена атака
методом перебора с участием большого числа компьютеров. Для ослабления
этой угрозы необходимо использовать достаточно надежный пароль.
Обзор безопасности iOS | Сентябрь 2015 г.
16
Если пользователь решает не шифровать резервные копии iTunes, файлы
резервных копий не шифруются независимо от класса защиты данных, однако
связка ключей остается защищена ключом на основе UID. Поэтому элементы
связки ключей переносятся на новое устройство, только если установлен пароль
резервного копирования.
Хранилище ключей передачи используется для синхронизации iTunes и MDM.
Благодаря этому хранилищу ключей iTunes может выполнять резервное
копирование и синхронизацию, не требуя ввода пароля пользователем, а сервер
MDM может удаленно стирать пароль пользователя. Оно хранится на компьютере,
который используется для синхронизации с iTunes, или на сервере MDM, который
управляет устройством.
Хранилище ключей передачи упрощает работу пользователей при синхронизации
устройства, которое может требовать доступа ко всем классам данных. Когда
защищенное паролем устройство впервые подключается к iTunes, пользователю
необходимо ввести пароль. Затем устройство создает хранилище ключей
передачи, содержащее ключи того же класса, что и используемые на устройстве,
но защищенные с помощью нового сгенерированного пароля. Хранилище ключей
передачи и защищающий его ключ делятся между устройством и хостом или
сервером, а данные сохраняются на устройстве с классом «Защищено до первой
аутентификации пользователя». Поэтому для первого резервного копирования
в iTunes после перезагрузки пользователю необходимо ввести пароль устройства.
В случае беспроводного обновления программного обеспечения пользователь
получает запрос на ввод пароля при запуске обновления. Это нужно для
безопасного создания одноразового токена разблокировки, который позволяет
разблокировать системное хранилище ключей после обновления. Этот токен
невозможно сгенерировать без ввода пароля пользователем, а все ранее
созданные токены становятся недействительными, если пароль пользователя
меняется.
Одноразовые токены разблокировки бывают двух типов и могут использоваться
для установки обновлений программного обеспечения либо с участием
пользователя, либо без его участия. Они шифруются с помощью ключа, полученного
из текущего значения монотонного счетчика, работающего в Secure Enclave,
UUID хранилища ключей и UID Secure Enclave.
При увеличении значения счетчика одноразовых токенов разблокировки в SEP
все существующие токены становятся недействительными. Увеличение
счетчика происходит при использовании токена, после первой разблокировки
перезапущенного устройства, при отмене установки обновления программного
обеспечения (как пользователем, так и системой), а также при истечении таймера
действия токена.
Срок действия одноразового токена разблокировки для установки обновлений
программного обеспечения при участии пользователя истекает через 20 минут.
Такой токен экспортируется из Secure Enclave и записывается на стираемый
накопитель. Таймер действия токена увеличивает значение счетчика, если
устройство не перезагружалось в течение 20 минут.
При установке программного обеспечения без участия пользователя, которая
начинается, если пользователь выберет вариант «Позже» в окне уведомления
об обновлении, процессор программ может поддерживать одноразовый токен
разблокировки в Secure Enclave в действительном состоянии до 8 часов.
По прошествии этого времени таймер действия токена увеличит значение
счетчика.
Обзор безопасности iOS | Сентябрь 2015 г.
17
Хранилище ключей резервного копирования iCloud похоже на хранилище
ключей резервного копирования. Все ключи классов в этом хранилище являются
асимметричными (используют Curve25519, как класс «Защищено, если не открыто»),
поэтому резервное копирование iCloud может выполняться в фоновом режиме.
Для всех классов защиты данных, кроме «Без защиты», зашифрованные данные
считываются с устройства и передаются в iCloud. Соответствующие ключи классов
защищаются с помощью ключей iCloud. Ключи классов связки ключей защищаются
с помощью ключа, полученного из UID, аналогично незашифрованным резервным
копиям iTunes. Хранилище асимметричных ключей также используется для
резервного копирования, необходимого для восстановлении связки ключей iCloud.
Сертификаты и программы обеспечения безопасности
Криптографическая проверка (FIPS 140-2)
Криптографические модули, используемые в каждой версии iOS начиная с iOS 6,
проверяются на соответствие Федеральному стандарту обработки информации
США (FIPS) 140-2, уровень 1. Криптографические модули в iOS 9 идентичны
используемым в iOS 8, но, как и в случае с любой другой версией iOS, Apple
отправляет их на повторную проверку. Эта инициатива подтверждает надежность
криптографических операций в программах Apple и сторонних программах,
которые надлежащим образом используют криптографические службы iOS.
Сертификация по общим критериям (ISO 15408)
Компания Apple уже начала действия по сертификации iOS в рамках программы
сертификации по общим критериям (CCC). В данное время рассматриваются
заявки на получение первых двух сертификатов — по профилю фундаментальной
защиты мобильных устройств версии 2.0 (MDFPP2) и профилю защиты клиентов
VPN IPSecPP1.4 (VPNIPSecPP1.4). Apple принимала активное участие в работе
Международного технического сообщества (ITC) по созданию отсутствующих
на данный момент профилей защиты, которые позволяли бы оценить ключевые
технологии обеспечения безопасности мобильных устройств. Apple продолжает
деятельность, направленную на получение и обновление сертификатов по новым
и изменившимся существующим профилям защиты.
Коммерческие решения для засекреченных сред (CSfC)
Компания Apple также подала заявки на включение платформы iOS и различных
служб в список программных компонентов коммерческих решений для
засекреченных сред (CSfC). Говоря конкретнее, речь идет о включении iOS
в раздел «Мобильная платформа», а клиента IKEv2 — в раздел «Клиент IPSec VPN»
(только функции IKEv2 «VPN всегда включена»). Когда платформы и службы Apple
пройдут сертификацию по общим критериям, будут поданы заявки на их включение
в список программных компонентов CSfC.
Руководства по настройке обеспечения безопасности
Компания Apple в сотрудничестве с правительственными учреждениями по всему
миру разработала руководства с инструкциями и рекомендациями по повышению
безопасности используемой среды. Этот процесс также известен под названием
«device hardening» (повышение защищенности устройства). В этих руководствах
приводится конкретная проверенная информация о том, как настроить
и использовать функции iOS для повышения безопасности.
Подробнее о сертификации и проверке средств обеспечения безопасности в iOS,
а также о руководствах по настройке можно узнать в статье
https://support.apple.com/ru-ru/HT202739.
Обзор безопасности iOS | Октябрь
Сентябрь2014 г.
2015 г.
18
Безопасность программ
Программы являются одним из самых важных элементов современной архитектуры
безопасности мобильных устройств. Программы не только значительно повышают
продуктивность работы пользователей, но и, если не принять должных мер, могут
негативно сказываться на безопасности системы, ее стабильности
и пользовательских данных.
По этой причине в iOS реализована многоуровневая система защиты для
гарантии того, что программы подписаны и проверены, а также запускаются в так
называемой «песочнице» для защиты пользовательских данных. Эти элементы
создают стабильную, безопасную платформу для работы программ, позволяя
тысячам разработчиков предлагать сотни тысяч программ для iOS без ущерба для
целостности системы. А пользователи могут использовать эти программы на своих
устройствах iOS, не опасаясь вирусов, вредоносных программ, или других атак.
Подпись кода программ
После запуска ядро iOS определяет, какие процессы пользователей и программы
могут быть запущены в системе. Чтобы гарантировать, что все программы
получены из известного и утвержденного источника и не подделаны, iOS требует
обязательного подписания всего исполняемого кода с помощью выпущенного
компанией Apple сертификата. Установленные на устройстве программы, такие
как Почта и Safari, подписаны Apple. Программы сторонних разработчиков также
должны быть проверены и подписаны с помощью выпущенного компанией Apple
сертификата. Обязательная подпись кода расширяет концепцию цепочки доверия
с операционной системы на программы и не позволяет программам сторонних
разработчиков загружать неподписанные фрагменты кода или использовать
самомодифицирующийся код.
Для разработки и установки программ на устройствах iOS разработчики должны
зарегистрироваться в Apple и присоединиться к программе iOS Developer Program.
Перед выдачей сертификата компания Apple проверяет личность каждого
разработчика, будь то частное лицо или компания, в реальном мире. Используя
эти сертификаты, разработчики могут подписывать программы и отправлять
их в App Store для распространения. В результате все программы в App Store
отправляются идентифицированными людьми и организациями, что выступает
в качестве сдерживающего фактора для создания вредоносных программ.
Кроме того, все программы проверяются Apple, чтобы гарантировать, что они
соответствуют своему описанию и не содержат явных ошибок или других проблем.
Эта проверка дает пользователям дополнительную уверенность в качестве
программ, которые они покупают.
Обзор безопасности iOS | Сентябрь 2015 г.
19
Разработчики программ для iOS могут встраивать в свои программы различные
структуры, используемые самой программой или встроенными в нее
расширениями. Чтобы защитить систему и другие программы от загрузки
стороннего кода в их адресное пространство, в момент загрузки система
выполняет проверку подписи кода для всех динамических библиотек, на которые
ссылается процесс. Эта проверка выполняется с помощью идентификатора
команды, который извлекается из выпущенного компанией Apple сертификата.
Идентификатор команды представляет собой десятизначную буквенно-цифровую
строку, например 1A2B3C4D5F. Программа может ссылаться на любую библиотеку
платформы, поставляемую вместе с системой, и любую библиотеку с таким
же идентификатором команды в подписи кода, как у основного исполняемого
модуля. Поскольку исполняемые модули, поставляемые с системой, не имеют
идентификатора команды, они могут ссылаться только на библиотеки, которые
также поставлялись с системой.
У компаний есть возможность разрабатывать корпоративные программы для
внутреннего использования и распространять их среди своих сотрудников.
Предприятия и организации могут подать заявку на участие в программе
Apple Developer Enterprise Program (ADEP), указав свой номер D-U-N-S.
Apple проверяет личность заявителей, их соответствие условиям программы
и утверждает заявки. Став членом ADEP, организация может зарегистрироваться
для получения профиля обеспечения, который разрешает запускать собственные
программы компании на указанных в нем устройствах. Для запуска корпоративных
программ у пользователей должен быть установлен профиль обеспечения.
Благодаря этому только санкционированные организацией лица могут загружать
программы на свои устройства iOS. Программы, установленные через MDM,
считаются доверенными, поскольку отношения между организацией и устройством
уже установлены. Другими словами, пользователям необходимо авторизовать
профиль обеспечения программы в Настройках. Организации могут запретить
пользователям авторизовать программы неизвестных разработчиков.
При первом запуске любой корпоративной программы устройство должно
получить подтверждение от Apple, что программу разрешено запускать.
В отличие от других мобильных платформ, iOS не разрешает пользователям
устанавливать потенциально вредоносные неподписанные программы с веб-сайтов
или запускать ненадежный код. В процессе выполнения проводятся проверки
подписей кода всех исполняемых страниц памяти, чтобы убедиться, что программа
не была изменена с момента установки или последнего использования.
Безопасность в процессе выполнения
Убедившись, что программа получена из надежного источника, iOS применяет
специальные средства безопасности для защиты других программ и остальной
системы от взлома данной программой.
Все программы сторонних разработчиков помещаются в «песочницу», что
ограничивает для них доступ к файлам, хранящимся в других программах,
и не позволяет вносить изменения в работу устройства. «Песочница»
не дает программам собирать и изменять информацию, сохраняемую другими
программами. Каждая программа использует для своих файлов уникальную
домашнюю папку, которая назначается случайным образом при установке
программы. Если программе стороннего разработчика необходимо получить
доступ к чужой информации, она может сделать это только при помощи
специальных служб iOS.
Обзор безопасности iOS | Сентябрь 2015 г.
20
Системные файлы и ресурсы отделены от пользовательских программ.
Большинство компонентов iOS, а также все программы сторонних разработчиков
работают с правами непривилегированного «мобильного» пользователя.
Весь раздел операционной системы подключен только для чтения. Системное
программное обеспечение не содержит ненужных инструментов, таких как службы
удаленного входа, а API не позволяют программам расширять свои полномочия для
изменения других программ или самой iOS.
Для контроля доступа сторонних программ к информации пользователя
и таким функциям, как iCloud и расширения, используется декларирование прав.
Права — это пары значений ключей, которые зарегистрированы в программе
и обеспечивают аутентификацию без привязки ко времени выполнения, аналогично
идентификатору пользователя в UNIX. Поскольку права защищены цифровой
подписью, их невозможно изменить. Системные программы и демоны широко
используют права для выполнения конкретных привилегированных операций —
в противном случае для их выполнения требовалось бы использовать корневые
процессы. Это значительно снижает вероятность передачи прав взломанной
системной программой или демоном.
Кроме того, программы могут выполнять фоновую обработку только через
системные API. Это защищает систему от снижения производительности или
значительного сокращения времени работы аккумулятора во время работы
программ.
Технология случайного расположения в адресном пространстве (ASLR) защищает
от атак, связанных с использованием повреждения памяти. Встроенные программы
задействуют ASLR для того, чтобы при запуске все регионы памяти располагались
в случайном порядке. Случайное расположение в памяти исполняемого кода,
системных библиотек и связанных с ними программных конструкций снижает
вероятность многих сложных атак. Например, атака типа «возврат в библиотеку»
пытается обманным образом вынудить устройство выполнить вредоносный код,
манипулируя адресами стека и системных библиотек. Случайное размещение этих
элементов значительно повышает сложность проведения атаки, особенно при атаке
на несколько устройств. Xcode, среда разработки iOS, автоматически включает
поддержку ASLR в программы сторонних разработчиков при
их компиляции.
Функция eXecute Never (XN) в iOS помечает страницы памяти как неисполняемые,
обеспечивая дальнейшую защиту. Страницы памяти, помеченные как доступные
для записи и исполняемые, могут использоваться только жестко контролируемыми
программами: ядро проверяет наличие права динамического подписания кода,
которое предоставляется только Apple. Даже при его наличии можно выполнить
только один вызов mmap для запроса исполняемой и доступной для записи
страницы, которой присваивается случайный адрес. Safari использует эту функцию
в своем компиляторе JavaScript JIT.
Обзор безопасности iOS | Сентябрь 2015 г.
21
Расширения
Программы в iOS могут предоставлять свои функции другим программам
посредством расширений. Расширения — это специализированные подписанные
исполняемые двоичные файлы, входящие в пакет программы. Система
автоматически обнаруживает расширения во время установки и делает
их доступными для других программ, использующих подходящую систему.
Область системы, предназначенная для поддержки расширений, называется
точкой расширения. Каждая точка расширения предоставляет API и обеспечивает
применение политик в своей области. Система определяет доступные расширения
на основе правил соответствия, заданных для конкретной точки расширения.
Система автоматически запускает процессы расширений по мере необходимости
и управляет их закрытием. Чтобы ограничить доступность расширений конкретной
системной программе, можно использовать права. Например, виджет вида
«Сегодня» отображается только в Центре уведомлений, а расширение экспорта
доступно только на панели общего доступа. Точками расширения являются
виджеты «Сегодня», экспорт, персональные действия, редактирование фотографий,
поставщик документов и настраиваемая клавиатура.
Расширения работают в собственном адресном пространстве. Для обмена
данными между расширением и программой, которая его запустила, используется
межпроцессная связь при посредничестве системной структуры. У них нет доступа
к файлам или адресному пространству друг друга. Расширения изолированы друг
от друга, от содержащей их программы и от программ, которые их используют.
Они исполняются в «песочнице», как любые другие программы сторонних
разработчиков, а их контейнер отделен от контейнера содержащей их программы.
Однако им доступны те же настройки конфиденциальности, как у программыконтейнера. Следовательно, если пользователь предоставил программе доступ
к Контактам, этот доступ также получат расширения, встроенные в программу,
но не получат расширения, запускаемые программой.
Настраиваемые клавиатуры являются особым типом расширений, поскольку они
включаются пользователем сразу для всей системы. Если включить расширение,
оно будет использоваться для всех текстовых полей, кроме поля пароля и любого
поля секретного текста. Из соображений конфиденциальности по умолчанию
настраиваемые клавиатуры запускаются в «песочнице» с сильно ограниченными
возможностями; эта «песочница» блокирует доступ к сети, к службам, которые
выполняют сетевые операции от имени процесса, а также к интерфейсам
API, которые могли бы позволить расширению извлекать вводимые данные.
Разработчики настраиваемых клавиатур могут запросить для своего расширения
открытый доступ, чтобы после получения согласия от пользователя система могла
запускать расширение в «песочнице», используемой по умолчанию.
На устройствах, которые зарегистрированы в системе управления мобильными
устройствами, расширения для работы с документами и клавиатурами подчиняются
правилам управления средой просмотра. Например, сервер MDM может
запретить пользователю экспортировать документ из управляемой программы
в неуправляемого поставщика документов или использовать неуправляемую
клавиатуру в управляемой программе. Кроме того, разработчики программ могут
запретить использование сторонних расширений клавиатур в своей программе.
Обзор безопасности iOS | Сентябрь 2015 г.
22
Группы программ
Если программы и расширения, принадлежащие одной учетной записи
разработчика, настроены как часть группы программ, они могут использовать
контент совместно друг с другом. Для этого разработчик должен создать
подходящие группы на портале разработчиков Apple и включить в них
необходимые наборы программ и расширений. Программы, настроенные
как часть группы программ, получают доступ к следующим элементам:
• общий контейнер на диске, используемый в качестве хранилища, который
остается на устройстве, пока на нем установлена хотя бы одна программа
из группы;
• общие настройки;
• общие элементы связки ключей.
Портал разработчиков Apple гарантирует, что каждая группа программ имеет
уникальный идентификатор в пределах всей цифровой среды программ.
Защита данных в программах
Комплект разработчика ПО для iOS (SDK) предлагает полный набор API, которые
упрощают внедрение технологии защиты данных для сторонних и корпоративных
разработчиков, а также помогают им обеспечить высочайший уровень защиты
в своих программах. Защита данных охватывает API для работы с файлами и базами
данных, включая NSFileManager, CoreData, NSData и SQLite.
Программа «Почта» (включая вложения), управляемые книги, закладки Safari,
изображения запуска программ и данные о местоположении также хранятся
в зашифрованном виде, а ключ защищается с помощью установленного
на устройстве пароля пользователя. Календарь (без вложений), Контакты,
Напоминания, Заметки, Сообщения и Фото имеют класс защиты «Защищено
до первой аутентификации пользователя».
Установленные пользователем программы, для которых не задан определенный
класс защиты данных, по умолчанию получают класс «Защищено до первой
аутентификации пользователя».
Аксессуары
Программа лицензирования «Made for iPhone, iPod touch, and iPad» (MFi)
предоставляет проверенным производителям аксессуаров доступ к протоколу
iPod Accessories Protocol (iAP) и необходимым вспомогательным аппаратным
компонентам.
Когда аксессуар MFi связывается с устройством iOS через разъем Lightning
или через Bluetooth, устройство просит его подтвердить, что он авторизован
компанией Apple. Аксессуар должен передать устройству предоставленный Apple
сертификат, который проверяется устройством. Затем устройство направляет
запрос, на который устройство должно отправить подписанный ответ.
Вся процедура выполняется заказной интегральной микросхемой, которую
компания Apple предоставляет утвержденным производителям аксессуаров,
и незаметна для самого аксессуара.
Обзор безопасности iOS | Сентябрь 2015 г.
23
Аксессуары могут запрашивать доступ к различным способам передачи
и функциям, например, доступ к цифровым аудиопотокам через кабель Lightning
или доступ к информации о местоположении по Bluetooth. Интегральная
микросхема аутентификации гарантирует, что полный доступ к устройству
получают только утвержденные устройства. Если аксессуар не обеспечивает
аутентификацию, его доступ ограничен аналоговым аудио и небольшим набором
элементов управления воспроизведением через последовательный аудиопорт
UART.
AirPlay также задействует интегральную микросхему аутентификации для
подтверждения того, что приемники утверждены Apple. Аудиопоток AirPlay
и видеопоток CarPlay используют протокол MFi-SAP (протокол сопоставления
безопасности), который обеспечивает шифрование данных, передаваемых
между аксессуаром и устройством, по алгоритму AES-128 в режиме CTR.
Для обмена динамическими ключами используется алгоритм обмена ключами
ECDH (Curve25519). Интегральная микросхема аутентификации подписывает ключи
с помощью 1024-битного ключа RSA в рамках протокола Station-to-Station (STS).
HomeKit
HomeKit предоставляет инфраструктуру «умного дома», которая использует
функции безопасности iCloud и iOS для защиты и синхронизации личных данных
без передачи этой информации в компанию Apple.
Идентификация в HomeKit
Идентификация и защита в HomeKit реализованы на базе пар открытых и личных
ключей. Устройство iOS генерирует пару ключей Ed25519 для каждого пользователя
HomeKit, и эта пара ключей становится идентификатором пользователя в HomeKit.
Он используется для аутентификации обмена данными между устройствами iOS,
а также между устройствами iOS и аксессуарами.
Ключи хранятся в Связке ключей и добавляются только в зашифрованные
резервные копии Связки ключей. Для синхронизации ключей между устройствами
используется Связка ключей iCloud.
Связь с аксессуарами HomeKit
Аксессуары HomeKit генерируют собственные пары ключей Ed25519 для связи
с устройствами iOS. При восстановлении заводских настроек аксессуара
генерируется новая пара ключей.
Для установления связи между устройством iOS и аксессуаром HomeKit
выполняется обмен ключами по 3072-битному протоколу Secure Remote Password:
производитель аксессуара предоставляет 8-значный цифровой код, который
пользователь вводит на устройстве iOS; затем этот код шифруется по алгоритму
ChaCha20-Poly1305 AEAD с использованием производных ключей HKDF-SHA-512.
Во время настройки также выполняется проверка сертификата MFi устройства.
Если в процессе эксплуатации устройству iOS и аксессуару HomeKit необходимо
обменяться данными, каждый из них проверяет подлинность второй стороны,
используя ключи, которыми они обменялись ранее (см. выше). Каждый сеанс связи
устанавливается с использованием протокола Station-to-Station и шифруется
с использованием производных ключей HKDF-SHA-512, полученных из сеансовых
ключей Curve25519. Этот метод применяется как для IP-аксессуаров, так и для
аксессуаров стандарта Bluetooth Low Energy.
Обзор безопасности iOS | Сентябрь 2015 г.
24
Локальное хранилище
Данные о домах, аксессуарах, сценах и пользователях HomeKit хранятся
на принадлежащем пользователю устройстве iOS. Эти данные шифруются
с помощью ключей, полученных из ключей идентификации пользователя
в HomeKit, а также случайного значения nonce. Кроме того, данные HomeKit
имеют класс защиты данных «Защищено до первой аутентификации пользователя».
Данные HomeKit включаются только в зашифрованные резервные копии, поэтому,
например, незашифрованные резервные копии iTunes не содержат данных
HomeKit.
Синхронизация данных между устройствами и пользователями
Для синхронизации данных HomeKit между принадлежащими пользователю
устройствами iOS можно использовать iCloud и Связку ключей iCloud. В процессе
синхронизации данные HomeKit шифруются с использованием ключей, полученных
из идентификатора пользователя в HomeKit и случайного значения nonce.
При синхронизации эти данные обрабатываются как непрозрачный объект. Самый
последний объект сохраняется в iCloud исключительно для целей синхронизации.
Поскольку он зашифрован с помощью ключей, доступ к которым возможен только
на принадлежащих пользователю устройствах iOS, его содержимое недоступно при
передаче и хранении в iCloud.
Данные HomeKit синхронизируются между различными пользователями одного
«умного дома». Используемые при этом методы аутентификации и шифрования
аналогичны методам, используемым для синхронизации между устройством iOS
и аксессуаром HomeKit. Аутентификация выполняется на основе открытых ключей
Ed25519, которыми обмениваются устройства при добавлении нового пользователя
«умного дома». После добавления нового пользователя для аутентификации
и шифрования всех дальнейших сеансов связи используется протокол
Station-to-Station и сеансовые ключи.
Новых пользователей может добавлять только тот пользователь, который
изначально создал дом в HomeKit. Его устройство настраивает аксессуары
с использованием открытого ключа нового пользователя для того, чтобы
аксессуары могли проверять подлинность и принимать команды от нового
пользователя. Процедура настройки Apple TV для использования с HomeKit
задействует те же методы аутентификации и шифрования, что и при добавлении
новых пользователей, однако выполняется автоматически, если создатель дома
вошел в систему iCloud на Apple TV, а Apple TV находится на территории дома.
Если у пользователя только одно устройство и он не предоставил доступ к своему
дому дополнительным пользователям, синхронизация данных HomeKit с iCloud
не выполняется.
Домашние данные и программы
Доступ программ к домашним данным регулируется настройками
конфиденциальности пользователя. Когда программе необходимы домашние
данные, пользователь получает запрос на предоставление доступа (аналогично
доступу к Контактам, Фото и другим источникам данных iOS). Если пользователь
дает разрешение, программа получает доступ к названиям комнат, названиям
аксессуаров и распределению аксессуаров по комнатам, а также другой
информации, которая подробно описана в документации разработчика HomeKit.
Siri
С помощью Siri можно отправлять запросы аксессуарам, управлять ими и включать
сцены. Siri получает минимальный объем анонимной информации о конфигурации
дома (см. раздел «Siri» данного документа), включая имена комнат, аксессуаров
и сцен, необходимые для распознавания команд.
Обзор безопасности iOS | Сентябрь 2015 г.
25
Удаленный доступ к iCloud для аксессуаров HomeKit
Аксессуары HomeKit могут подключаться прямо к iCloud, чтобы устройства iOS
могли управлять ими при отсутствии связи через Bluetooth или Wi-Fi.
Удаленный доступ к iCloud тщательно продуман, поэтому управление аксессуарами
и отправку уведомлений можно выполнять, не передавая в Apple сведения о самих
аксессуарах, командах и уведомлениях. HomeKit не передает данные о доме через
удаленный доступ к iCloud.
Когда пользователь отправляет команду через удаленный доступ к iCloud,
выполняется взаимная аутентификация аксессуара и устройства iOS, а данные
шифруются с помощью той же процедуры, которая используется при локальном
подключении. Все передаваемые данные зашифрованы и не видны компании
Apple. В основе обращения через iCloud лежат идентификаторы iCloud,
зарегистрированные в ходе настройки.
Подготовка аксессуаров, поддерживающих удаленный доступ к iCloud, выполняется
в рамках процесса настройки аксессуара. Процесс подготовки начинается
со входа пользователя в iCloud. Затем устройство iOS отправляет аксессуару
запрос, который следует подписать с помощью сопроцессора аутентификации
Apple, встроенного во все аксессуары, поддерживающие HomeKit. Кроме того,
аксессуар генерирует ключи эллиптической кривой prime256v1, и открытый ключ
отправляется на устройство iOS вместе с подписанным запросом и сертификатом
X.509 сопроцессора аутентификации. Они используются для того, чтобы запросить
для аксессуара сертификат с сервера подготовки iCloud. Аксессуар сохраняет
сертификат, в котором не содержится никаких данных о самом аксессуаре,
кроме того, что этому аксессуару разрешен удаленный доступ к iCloud HomeKit.
Устройство iOS, выполняющее подготовку, также отправляет аксессуару пакет,
содержащий URL-адреса и другую информацию, необходимую для подключения
к серверу удаленного доступа iCloud. Эта информация не содержит каких-либо
указаний на конкретного пользователя или аксессуар.
Каждый аксессуар регистрирует список разрешенных пользователей на сервере
удаленного доступа к iCloud. Человек, добавивший данный аксессуар к домашней
системе, предоставил этим пользователям возможность управлять аксессуаром.
Сервер iCloud назначает пользователям идентификатор; кроме того, их можно
сопоставить с учетными записями iCloud — с целью доставки уведомлений
и ответов от аксессуаров. Аксессуарам также назначаются идентификаторы iCloud,
но эти идентификаторы являются непрозрачными и не раскрывают никакой
информации о самих аксессуарах.
Когда аксессуар подключается к серверу удаленного доступа iCloud HomeKit,
то предъявляет свой сертификат и пароль. Пароль выдается другим сервером
iCloud и не содержит указаний на конкретный аксессуар. Когда аксессуар
запрашивает пароль, то указывает в запросе своего производителя,
модель и версию прошивки. Этот запрос не содержит информации,
позволяющей идентифицировать пользователя или дом. В целях обеспечения
конфиденциальности при подключении к серверу паролей аутентификация
не выполняется.
Аксессуары подключаются к серверу удаленного доступа iCloud по протоколу
HTTP/2 с шифрованием TLS 1.2 по стандартам AES-128-GCM и SHA-256. Аксессуар
поддерживает подключение к серверу удаленного доступа iCloud открытым, чтобы
получать входящие сообщения и отправлять ответы и исходящие уведомления
на устройства iOS.
Обзор безопасности iOS | Сентябрь 2015 г.
26
HealthKit
Инфраструктура HealthKit предоставляет общую базу данных, которую
программы — с разрешения пользователя — могут использовать для хранения
и просмотра информации о спорте и здоровье. HealthKit также напрямую
взаимодействует с устройствами для спорта и здоровья, такими как совместимые
пульсомеры Bluetooth LE, а также сопроцессор движения, встроенный во многие
устройства iOS.
Медданные
HealthKit сохраняет данные о здоровье пользователя, такие как рост, вес,
пройденное расстояние, давление и т. д., в специальной базе данных. Эта база
данных хранится в системе защиты данных с классом «Полная защита», т. е. она
становится доступна только после того, как пользователь введет пароль или
разблокирует устройство с помощью Touch ID.
Еще одна база данных используется для хранения вспомогательных данных,
таких как таблицы доступа для программ, имена устройств, подключенных
к HealthKit, а также расписания, используемые для запуска программ при
появлении новых данных. Эта база данных имеет класс защиты «Защищено
до первой аутентификации пользователя».
Для хранения медицинских записей, полученных, пока устройство заблокировано
(например, во время тренировки пользователя), используются временные файлы
журналов. Эти файлы имеют класс защиты «Защищено, если не открыто».
При разблокировании устройства они импортируются в основные базы
медданных, после чего удаляются.
Медданные не передаются через iCloud и не синхронизируются между
устройствами. Базы медданных добавляются в зашифрованные резервные копии
iCloud или iTunes. Медданные не добавляются в незашифрованные резервные
копии iTunes.
Целостность данных
Вместе с блоками данных в базе данных хранятся метаданные, которые позволяют
отследить источник каждой записи. Эти метаданные включают идентификатор
программы, которая сохранила запись. Кроме того, метаданные могут включать
копию записи с цифровой подписью. Это позволяет обеспечить целостность
записей, сгенерированных доверенным устройством. Формат хранения цифровой
подписи использует синтаксис криптографических сообщений (CMS), заданный
в IETF RFC 5652. Доступ программ сторонних разработчиков
Доступ к API HealthKit контролируется с помощью прав. Кроме того, программы
должны соблюдать ограничения по использованию данных. Например, программам
запрещено использовать медданные для рекламных целей. Программы также
должны содержать ссылку на политику конфиденциальности, в которой подробно
описывается использование медданных.
Доступ программ к медданным регулируется настройками конфиденциальности
пользователя. Когда программе необходим доступ к медданным, пользователь
получает запрос на предоставление доступа (аналогично доступу к Контактам,
Фото и другим источникам данных iOS). Однако в случае медданных программы
получают доступ отдельно для чтения и записи, а также отдельно для каждого типа
медданных. Пользователи могут просматривать и отзывать предоставленные ими
разрешения на доступ к медданным, используя вкладку «Источники» в программе
«Здоровье».
Обзор безопасности iOS | Сентябрь 2015 г.
27
Если программам разрешено записывать данные, они также автоматически
получают разрешение на чтение данных, которые они записали. Если программам
разрешено считывать данные, они могут считывать данные, записанные всеми
источниками. Однако программы не могут определить уровень доступа,
предоставленного другим программам. Кроме того, программы не могут достоверно
сообщить, разрешено ли им чтение медданных. Если у программы нет доступа для
чтения, все запросы возвращают пустые ответы — точно такие же ответы вернула
бы пустая база данных. Это не позволяет программам угадывать состояние здоровья
пользователя, анализируя то, какие типы данных отслеживает пользователь.
Медкарта
Пользователи программы «Здоровье» могут заполнить медкарту, указав
информацию, которая может оказаться важной при оказании неотложной
медицинской помощи. Эта информация вводится и обновляется вручную.
Она не синхронизируется с информацией в базах медданных.
Для доступа к медкарте необходимо коснуться «SOS» на экране блокировки.
Информация хранится на устройстве с классом «Без защиты», поэтому для
получения доступа не нужно вводить пароль устройства. При использовании
медкарты пользователи сами решают, какой конфиденциальной информацией они
готовы рискнуть ради своей безопасности.
Apple Watch
Apple Watch использует встроенные функции и технологии безопасности iOS для
защиты данных на устройстве, а также для защиты связи с подключенным iPhone
и Интернетом. Сюда входят такие технологии, как система защиты данных
и контроль доступа к связке ключей. Для создания ключей шифрования пароль
пользователя привязывается к UID устройства.
Для обмена открытыми ключами, а затем общим ключом канала BTLE при
создании пары между Apple Watch и iPhone используется отдельное соединение.
На экране Apple Watch отображается анимированный рисунок, который необходимо
считать с помощью камеры iPhone. Этот рисунок содержит зашифрованный ключ,
используемый для создания пары между устройствами по отдельному каналу
BTLE 4.1. При необходимости в качестве резервного способа создания пары
используется стандартный ввод ключа доступа BTLE.
После установления сеанса BTLE устройства Apple Watch и iPhone обмениваются
ключами, используя адаптированную процедуру IDS (см. раздел «iMessage» данного
документа). После обмена ключами ключ сеанса Bluetooth удаляется, и весь обмен
информацией между Apple Watch и iPhone шифруется с помощью IDS. При этом
второй уровень шифрования обеспечивают зашифрованные каналы BTLE и Wi-Fi.
Чтобы ограничить период уязвимости в случае взлома трафика, каждые 15 минут
происходит смена ключей.
Для поддержки программ, которым требуется потоковая передача данных,
шифрование выполняется с помощью методов, описанных в разделе «FaceTime»
данного документа, и службы IDS, предоставляемой подключенным iPhone.
В Apple Watch реализовано хранилище с аппаратным шифрованием, а также защита
файлов и элементов связки ключей на основе классов, как описано
в разделе «Защита данных» этого документа. Для элементов связки ключей также
используются хранилища ключей с контролируемым доступом. Для защиты ключей,
используемых для связи между часами и iPhone, также применяется защита
на основе классов.
Обзор безопасности iOS | Сентябрь 2015 г.
28
Если Apple Watch находятся вне зоны действия Bluetooth, можно использовать
Wi-Fi. Устройство Apple Watch не может подключиться к сетям Wi-Fi, если
на подключенном iPhone отсутствуют учетные данные для такого доступа. iPhone
автоматически предоставляет список известных сетей устройству Apple Watch.
Apple Watch можно заблокировать вручную, нажав и удерживая боковую кнопку.
Также вскоре после того, как часы сняты с запястья, эвристическая система анализа
движения распознает это, и устройство автоматически блокируется. Apple Pay
не может использоваться в режиме блокировки. Если автоматическая блокировка
с помощью функции распознавания запястья отключена, Apple Pay отключен.
Распознавание запястья можно отключить с помощью программы Apple Watch
на iPhone. Эту настройку также можно контролировать через систему управления
мобильными устройствами.
Если часы надеты на запястье, подключенный iPhone может их разблокировать.
Для этого устанавливается соединение, подлинность которого подтверждается
ключами, заданными при создании пары. iPhone отправляет на часы ключ, который
они используют для разблокировки своих ключей защиты данных. Пароль часов
неизвестен iPhone и не передается за пределы устройства. Эту функцию можно
отключить с помощью программы Apple Watch на iPhone.
Одновременно Apple Watch можно объединить в пару только с одним iPhone.
При создании пары с новым iPhone с Apple Watch автоматически стираются все
данные.
При включении функции «Найти iPhone» на iPhone, с которым создана пара,
на Apple Watch включается блокировка активации. Блокировка активации
усложняет использование или продажу Apple Watch в случае их потери или
кражи. После включения блокировки активации для разрыва пары, стирания
или повторной активации Apple Watch необходимо ввести Apple ID и пароль
пользователя.
Обзор безопасности iOS | Сентябрь 2015 г.
29
Безопасность сети
Помимо встроенных средств, используемых Apple для защиты данных
на устройствах iOS, организации могут принять целый ряд мер сетевой
безопасности для защиты информации при передаче между устройством
iOS и другими устройствами и сайтами.
Пользователям с мобильными устройствами необходимо иметь доступ
к корпоративным сетям, в какой бы стране они ни оказались, поэтому необходимо
следить, чтобы к корпоративной сети подключались только авторизованные
пользователи и чтобы их данные были защищены во время передачи.
Для аутентификации, авторизации и шифрования связи операционная система
iOS использует стандартные сетевые протоколы — и предоставляет разработчикам
доступ к ним. Для обеспечения необходимой защиты в iOS встроены проверенные
технологии и новейшие стандарты подключения к сетям Wi-Fi или сотовым сетям
передачи данных.
На других платформах для защиты открытых коммуникационных портов
от вторжений необходимо использовать программный брандмауэр. Поскольку iOS
уменьшает уязвимую область, ограничивая количество портов для прослушивания
и устраняя ненужные сетевые утилиты, такие как telnet, оболочки и веб-сервер,
использовать дополнительный брандмауэр на устройствах iOS не нужно.
TLS
iOS поддерживает Transport Layer Security (TLS версий 1.0, 1.1 и 1.2) и DTLS. Safari,
Календарь, Почта и другие интернет-программы автоматически используют эти
механизмы для установления зашифрованного канала связи между устройством
и сетевыми службами. Высокоуровневые API (такие как CFNetwork) упрощают
внедрение TLS в программах сторонних разработчиков, а низкоуровневые API
(SecureTransport) предоставляют детальный контроль. По умолчанию CFNetwork
не разрешает использовать SSL версии 3, и программам, использующим WebKit
(например, Safari), запрещается устанавливать подключения с использованием SSL
версии 3.
App Transport Security
Протокол App Transport Security предоставляет используемые по умолчанию
требования к подключению, чтобы программы работали с защищенными
подключениями при использовании API NSURLConnection, CFURL и NSURLSession.
Серверы должны поддерживать как минимум TLS 1.2 и прямую секретность,
а сертификаты должны быть действительны и подписаны с использованием
шифрования SHA-256 (или более сложного) с ключом уровнем не ниже, чем
2048-битный ключ RSA или 256-битный ключ эллиптической кривой.
Сетевые подключения, не отвечающие этим требованиям, будут прерваны, если
только в программе не предусмотрен обход протокола App Transport Security.
Использование недействительных сертификатов всегда приводит к постоянному
отказу и отсутствию подключения. Протокол App Transport Security автоматически
применяется для программ, скомпилированных для iOS 9.
Обзор безопасности iOS | Сентябрь 2015 г.
30
VPN
Безопасные сетевые службы, такие как виртуальные частные сети, обычно
требуют минимальной настройки и конфигурирования для работы с устройствами
iOS. Устройства iOS могут работать с VPN-серверами, которые поддерживают
следующие протоколы и способы аутентификации:
• IKEv2/IPSec с аутентификацией по общему ключу, сертификатам RSA,
сертификатам ECDSA, EAP-MSCHAPv2 или EAP-TLS.
• Pulse Secure, Cisco, Aruba Networks, SonicWALL, Check Point, Palo Alto Networks,
Open VPN, AirWatch, MobileIron, NetMotion Wireless и F5 Networks SSL-VPN через
подходящую клиентскую программу из App Store.
• Cisco IPSec с аутентификацией пользователя по паролю, RSA SecurID или
CRYPTOCard, а также автоматической аутентификацией с помощью общего ключа
и сертификатов.
• L2TP/IPSec с аутентификацией пользователя по паролю MS-CHAPV2, RSA SecurID
или CRYPTOCard, а также автоматической аутентификацией с помощью общего
ключа.
• PPTP с аутентификацией пользователя по паролю MS-CHAPV2, RSA SecurID или
CRYPTOCard. Этот вариант поддерживается, но не рекомендуется
к использованию.
iOS поддерживает функцию «VPN по запросу» для сетей, в которых аутентификация
выполняется на основе сертификатов. Для указания доменов, требующих VPNподключения, в ИТ-политиках используется профиль конфигурации.
iOS также поддерживает раздельное подключение программ к VPN, которое
повышает детализацию установления VPN-соединений. Система управления
мобильными устройствами (MDM) позволяет настроить подключение для каждой
управляемой программы и/или конкретного домена в Safari. Это помогает
гарантировать, что защищенные данные не выйдут за пределы корпоративной
сети, а личные данные пользователя в нее не попадут.
В iOS есть функция «VPN всегда включена», которая может быть настроена
для устройств, управляемых через MDM и контролируемых с помощью
Apple Configurator или Программы регистрации устройств. Эта функция избавляет
пользователей от необходимости включать VPN для обеспечения защиты при
подключении к сетям сотовой связи или Wi-Fi. Функция «VPN всегда включена»
предоставляет организации полный контроль над трафиком устройства благодаря
туннелированию всего IP-трафика обратно в организацию. По умолчанию
в качестве протокола туннелирования используется IKEv2, который обеспечивает
передачу трафика с шифрованием данных. Организация может контролировать
и фильтровать входящий и исходящий трафик своих устройств, защитить данные
в сети и ограничить доступ устройств к Интернету.
Wi-Fi
iOS поддерживает стандартные протоколы Wi-Fi, включая WPA2 Enterprise, для
обеспечения авторизованного доступа к корпоративным сетям Wi-Fi. Стандарт
WPA2 Enterprise использует 128-битное шифрование AES, гарантируя максимальный
уровень защиты данных пользователей при отправке или получении по сети Wi-Fi.
Благодаря поддержке 802.1X устройства iOS можно интегрировать в широкий
набор сред, где используется аутентификация RADIUS. Поддерживаемые iPhone
и iPad беспроводные методы аутентификации 802.1X включают EAP-TLS, EAP-TTLS,
EAP-FAST, EAP-SIM, PEAPv0, PEAPv1 и LEAP.
Обзор безопасности iOS | Сентябрь 2015 г.
31
Если устройство не связано с сетью Wi-Fi и его процессор находится в режиме
сна, iOS выполняет проверки предпочитаемой сети для выгрузки данных (PNO),
используя случайный MAC-адрес. Процессор устройства переходит в режим сна
вскоре после выключения экрана. Проверки PNO позволяют определить, может
ли пользователь подключиться к предпочитаемой сети Wi-Fi для выполнения таких
действий, как беспроводная синхронизация с iTunes.
Кроме того, если устройство не связано с сетью Wi-Fi и его процессор находится
в режиме сна, iOS также выполняет расширенные проверки предпочитаемой сети
для выгрузки данных (ePNO), используя случайный MAC-адрес.
Поскольку MAC-адрес устройства изменяется, если устройство не подключено
к сети Wi-Fi, пассивные наблюдатели за трафиком Wi-Fi не могут использовать его
для постоянного слежения за устройством, даже если устройство подключено
к сотовой сети. Мы сообщили производителям оборудования Wi-Fi, что для фоновых проверок
используется случайный MAC-адрес и что ни Apple, ни производители не могут
предсказать эти случайные MAC-адреса.
Использование случайных MAC-адресов для Wi-Fi не поддерживается на iPhone 4s.
Bluetooth
Поддержка Bluetooth в iOS реализована таким образом, чтобы обеспечить
предоставление полезных функций без излишнего доступа к конфиденциальным
данным. При установлении соединения устройства iOS поддерживают режим
шифрования 3, режим безопасности 4 и уровень обслуживания 1. iOS поддерживает
следующие профили Bluetooth:
• профиль громкой связи (HFP 1.5);
• профиль доступа к телефонной книге (PBAP);
• профиль расширенного распределения звука (A2DP);
• профиль дистанционного управления аудио/видео (AVRCP);
• профиль личной сети (PAN);
• профиль устройства взаимодействия с пользователем (HID).
Поддержка этих профилей зависит от устройства. Дополнительные сведения
можно найти в статье https://support.apple.com/ru-ru/ht3647.
Единый вход
iOS поддерживает аутентификацию в корпоративных сетях посредством единого
входа в систему (SSO). Технология SSO работает с сетями на основе протокола
Kerberos, обеспечивая аутентификацию пользователей в службах, к которым
у них есть доступ. SSO можно использовать для целого ряда различных сетевых
операций, начиная с безопасных сеансов Safari и заканчивая программами
сторонних разработчиков.
Для взаимодействия со шлюзами аутентификации на основе Kerberos и системами
встроенной аутентификации Windows, которые поддерживают билеты Kerberos,
технология SSO в iOS использует токены SPNEGO и протокол HTTP Negotiate.
Также поддерживается аутентификация на основе сертификатов. Поддержка SSO
основана на проекте с открытым кодом Heimdal.
Поддерживаются следующие типы шифрования:
• AES128-CTS-HMAC-SHA1-96.
• AES256-CTS-HMAC-SHA1-96.
• DES3-CBC-SHA1.
• ARCFOUR-HMAC-MD5.
Обзор безопасности iOS | Сентябрь 2015 г.
32
Safari поддерживает SSO. Кроме того, на использование этой технологии можно
настроить программы сторонних разработчиков, которые используют стандартные
сетевые API в iOS. Для конфигурирования SSO в iOS используется компонент
профиля конфигурации, позволяющий серверам MDM передавать необходимые
настройки на устройства. Сюда входит настройка главного имени пользователя
(которым является учетная запись пользователя Active Directory) и настройки сфер
Kerberos, а также настройка программ и веб-адресов Safari, которым разрешено
использовать SSO.
Безопасность AirDrop
Устройства iOS, поддерживающие AirDrop, отправляют файлы и информацию
на находящиеся поблизости устройства, включая компьютеры Mac с поддержкой
AirDrop и операционной системой OS X Yosemite или новее, при помощи
технологии Bluetooth Low Energy (BLE) и разработанной компанией Apple
технологии прямого соединения Wi-Fi. Для прямого обмена информацией между
устройствами используется радиосвязь Wi-Fi — подключение к Интернету или
точке доступа Wi-Fi не требуется.
Когда пользователь включает AirDrop, на устройстве сохраняется 2048-битный
идентификатор RSA. Кроме того, создается хэш идентификатора AirDrop на основе
адреса электронной почты и номеров телефона, связанных с Apple ID пользователя.
Когда пользователь использует AirDrop для экспорта элемента, устройство
испускает сигнал AirDrop по каналу Bluetooth Low Energy. Если поблизости
есть другие устройства, которые не находятся в режиме сна и на которых
включена функция AirDrop, они распознают сигнал и отвечают на него, используя
сокращенную версию хэша идентификатора своего владельца.
По умолчанию функция AirDrop настроена на предоставление доступа «Только для
контактов». Пользователи также могут настроить AirDrop на доступ «Для всех» или
полностью отключить эту функцию. В режиме «Только для контактов» полученные
хэши идентификаторов сравниваются с хэшами пользователей в программе
«Контакты» на устройстве инициатора. При обнаружении совпадения передающее
устройство создает одноранговую сеть Wi-Fi и оповещает об установлении
соединения AirDrop, используя Bonjour. Используя это соединение, принимающие
устройства отправляют инициатору полные хэши своих идентификаторов. Если
в программе «Контакты» найдено совпадение для полного хэша, в списке общего
доступа AirDrop отображается имя получателя и его фотография (при ее наличии
в программе «Контакты»).
При использовании AirDrop отправитель должен выбрать пользователя, которому
он хочет передать файлы. Передающее устройство инициирует зашифрованное
TLS-соединение с принимающим устройством, для чего устройства обмениваются
сертификатами удостоверения iCloud. Удостоверение в сертификатах проверяется
по программе «Контакты» каждого пользователя. Затем получатель должен принять
запрос на входящую передачу от указанного пользователя или устройства. Если
выбрано несколько получателей, этот процесс повторяется на каждом целевом
устройстве.
В режиме «Для всех» используется аналогичная процедура, однако если
в программе «Контакты» не найдено совпадения, в списке общего доступа AirDrop
на принимающих устройствах отображается силуэт человека и имя устройства,
заданное в поле «Настройки» > «Основные» > «Об устройстве» > «Имя».
Организации могут запретить использование AirDrop на устройствах или
в программах, управляемых с помощью системы управления мобильными
устройствами.
Обзор безопасности iOS | Сентябрь 2015 г.
33
Apple Pay
Технология Apple Pay позволяет пользователям поддерживаемых устройств iOS
и Apple Watch легко, безопасно и конфиденциально оплачивать покупки.
Для пользователей это удобно, а защита, встроенная как в аппаратное, так
и в программное обеспечение, гарантирует безопасность. Кроме того, в Apple Pay предусмотрена защита личных данных пользователей.
Apple Pay не собирает никакой информации о транзакциях, которую можно было
бы связать с конкретным пользователем. Платежные операции выполняются
исключительно между пользователем, продавцом и эмитентом платежной карты.
Компоненты Apple Pay
Защищенный элемент. Защищенный элемент представляет собой стандартную
сертифицированную микросхему, работающую на платформе Java Card
и совместимую с требованиями финансовой отрасли к электронным платежам.
Контроллер NFC. Контроллер NFC обрабатывает протоколы ближней
бесконтактной связи и маршрутизирует данные, передаваемые между процессором
программ и защищенным элементом, а также между защищенным элементом
и терминалом, установленным в точке продажи.
Wallet. Программа Wallet позволяет добавлять кредитные, дебетовые, скидочные
и магазинные карточки, управлять ими и совершать платежи через Apple Pay.
В Wallet пользователи могут просматривать свои карточки и дополнительную
информацию об их эмитентах, действующих политиках конфиденциальности,
недавних транзакциях и многом другом. Кроме того, пользователи могут
добавлять карточки в Apple Pay через Настройки и Ассистент настройки.
Secure Enclave. Secure Enclave на iPhone и iPad управляет процессом
аутентификации и позволяет продолжить выполнение процесса оплаты.
Там хранятся данные об отпечатках пальцев для Touch ID.
В случае с Apple Watch устройство должно быть разблокировано, а пользователь
должен дважды нажать боковую кнопку. Информация об обнаружении двойного
нажатия передается напрямую в защищенный элемент, не проходя через
процессор программ.
Серверы Apple Pay. Серверы Apple Pay управляют состоянием кредитных
и дебетовых карт в Wallet и учетными номерами устройств, хранящимися
в защищенном элементе. Эти серверы взаимодействуют как с устройством,
так и с серверами платежной сети. Кроме того, серверы Apple Pay отвечают
за повторное шифрование платежных учетных данных при оплате в программах.
Обзор безопасности iOS | Сентябрь 2015 г.
34
Как в Apple Pay используется защищенный элемент
В защищенном элементе хранится специально разработанный апплет
для управления Apple Pay. Также в нем хранятся платежные апплеты,
сертифицированные платежными сетями. Данные кредитной или дебетовой карты
отправляются из платежной сети или от эмитента карты этим апплетам — при
этом данные зашифрованы с помощью ключей, известных только платежной сети
и домену безопасности платежных апплетов. Эти данные хранятся в платежных
апплетах и защищаются функциями обеспечения безопасности защищенного
элемента. Во время транзакции терминал взаимодействует непосредственно
с защищенным элементом по специальной аппаратной шине с помощью
контроллера NFC.
Как в Apple Pay используется контроллер NFC
Контроллер NFC выступает в качестве пункта доступа к защищенному элементу
и гарантирует, что все бесконтактные транзакции выполняются с использованием
терминала, установленного в точке продажи и находящегося в непосредственной
близости от устройства. Только запросы на оплату, поступающего от терминала
на месте эксплуатации, отмечаются контроллером NFC как бесконтактные
транзакции.
После того как владелец карты авторизует транзакцию с помощью Touch ID
или пароля либо путем двойного нажатия боковой кнопки на заблокированных
Apple Watch, бесконтактные ответы, подготовленные платежными апплетами
в защищенном элементе, будут эксклюзивно переданы контроллером в область
действия NFC. Следовательно, данные авторизации оплаты для бесконтактных
транзакций остаются в локальной области действия NFC и не раскрываются
процессору программ. При оплате покупок внутри программ данные авторизации
оплаты наоборот передаются в процессор программ и только после шифрования
защищенным элементом — на сервер Apple Pay.
Подготовка кредитных и дебетовых карт к использованию
Когда пользователь добавляет кредитную или дебетовую карту (в том числе
магазинные карты) в Apple Pay, компания Apple безопасно отправляет эмитенту
карты информацию об этой карте вместе с другими сведениями об учетной записи
пользователя и устройстве. Используя эту информацию, эмитент карты решает,
разрешить ли добавление карты в Apple Pay.
В рамках процесса подготовки карты Apple Pay использует три вызова
со стороны сервера для отправки и получения данных от эмитента карты или
из сети: Required Fields, Check Card и Link and Provision («Обязательные поля»,
«Проверка карты» и «Привязка и подготовка»). Эмитент карты или сеть используют
эти вызовы для проверки, утверждения и добавления карт в Apple Pay. Эти клиентсерверные сеансы связи шифруются с использованием SSL.
Полные номера карт не хранятся ни на устройстве, ни на серверах Apple. Вместо
этого создается учетный номер устройства, который шифруется и сохраняется
в защищенном элементе. Учетный номер устройства шифруется таким образом,
что у Apple нет к нему доступа. Каждый учетный номер устройства уникален
и отличается от обычных номеров кредитных и дебетовых карт — эмитент карты
может запретить его использование при физическом проведении картой
с магнитной полосой, по телефону или на веб-сайтах. Учетный номер устройства
в защищенном элементе изолирован от iOS и WatchOS, не хранится на серверах
Apple Pay, и его резервная копия не создается в iCloud.
Обзор безопасности iOS | Сентябрь 2015 г.
35
Подготовка карт, используемых с Apple Watch, для Apple Pay выполняется
с помощью программы Apple Watch на iPhone. Чтобы подготовить карту для
Apple Watch, необходимо, чтобы часы находились в зоне действия Bluetooth.
Картам, зарегистрированным специально для использования с Apple Watch,
назначаются собственные учетные номера устройства, которые хранятся
в защищенном элементе на Apple Watch.
Подготовить кредитную или дебетовую карту для использования в Apple Pay
можно двумя способами:
• Добавление кредитной или дебетовой карты в Apple Pay вручную
• Добавление в Apple Pay кредитных или дебетовых карт, зарегистрированных
в учетной записи iTunes Store
Добавление кредитной или дебетовой карты в Apple Pay вручную
Чтобы вручную добавить карту, в том числе магазинную, в процессе подготовки
необходимо указать имя владельца, номер кредитной карты, срок окончания
ее действия и код CVV. Пользователи могут сфотографировать на камеру iSight
или ввести эти данные в Настройках, программе Wallet или программе Apple Watch.
После съемки данных карты с помощью камеры Apple пытается заполнить поля
имени владельца, номера карты и срока окончания ее действия. Фотоснимок
не сохраняется на устройстве или в медиатеке. После заполнения всех полей
процесс проверки карты проверяет их значения (кроме кода CVV). Затем они
шифруются и отправляются на сервер Apple Pay.
Если процесс проверки карты возвращает соответствующий идентификатор, Apple
загружает и отображает положения и условия эмитента карты. Если пользователь
принимает положения и условия, Apple отправляет идентификатор принятых
условий и код CVV процессу привязки и подготовки. Кроме того, в рамках
процесса привязки и подготовки Apple передает эмитенту карты или сети такую
информацию с устройства, как сведения об активности пользователя в учетной
записи iTunes и App Store (например, много ли транзакций выполнялось в iTunes),
данные об устройстве (например, номер телефона, название и модель устройства
и любых сопутствующих устройств iOS, необходимых для настройки Apple Pay),
а также примерное местонахождение пользователя во время добавления карты
(если включены службы геолокации). Используя эту информацию, эмитент карты
решает, разрешить ли добавление карты в Apple Pay.
В результате выполнения процесса привязки и подготовки происходят две вещи:
• Устройство начинает загружать файл кредитной или дебетовой карты для Wallet.
• Устройство начинает привязку карты к защищенному элементу.
Файл карты содержит URL-адреса для загрузки изображения карты, таких
метаданных, как контактная информация, связанной программы эмитента карты
и поддерживаемых функций. Кроме того, он содержит различные данные
о состоянии карты: была ли выполнена персонализация защищенного элемента,
не приостановлено ли действие карты ее эмитентом, требуется ли дополнительная
проверка, прежде чем карту можно будет использовать для оплаты с помощью
Apple Pay, и так далее.
Обзор безопасности iOS | Сентябрь 2015 г.
36
Добавление в Apple Pay кредитных или дебетовых карт из учетной
записи iTunes Store
Для добавления кредитных или дебетовых карт, зарегистрированных в iTunes,
может потребоваться повторно ввести пароль Apple ID пользователя. После
получения номера карты из iTunes запускается процесс проверки карты. Если
карту можно использовать в Apple Pay, устройство загрузит и покажет на экране
положения и условия, а затем отправит их идентификатор и код безопасности
карты процессу привязки и подготовки. Для карт, зарегистрированных в учетной
записи iTunes, может потребоваться дополнительная проверка.
Добавление кредитных или дебетовых карт из программы эмитента
карты
Если программа зарегистрирована для использования Apple Pay, этой программе
и серверу продавца назначаются ключи. Эти ключи используются для шифрования
данных карты, отправляемых продавцу, что позволяет избежать чтения этих данных
устройством iOS. Процесс подготовки похож на используемый при добавлении
карт вручную (см. выше), за исключением того, что вместо кода CVV, используются
одноразовые пароли.
Дополнительная проверка
Эмитент карты может решить, что для кредитной или дебетовой карты требуется
дополнительная проверка. В зависимости от того, что предлагает эмитент карты,
пользователь может выбирать между различными вариантами дополнительной
проверки, например текстовым сообщением, электронным письмом, звонком
из службы поддержки или завершением проверки в утвержденной сторонней
программе. Для отправки текстового сообщения или электронного письма
пользователь должен выбрать контактные данные, зарегистрированные у эмитента
карты. На выбранный адрес или номер телефона будет отправлен код, который
пользователь должен будет ввести в программе Wallet, Настройках или программе
Apple Watch. Если пользователь выбирает проверку через службу поддержки или
программу, выполняются действия, предусмотренные эмитентом.
Авторизация платежей
Защищенный элемент разрешает выполнение оплаты только после получения
авторизации от Secure Enclave, подтверждающей, что пользователь прошел
аутентификацию с помощью Touch ID или пароля устройства. По умолчанию
используется технология Touch ID (при наличии), но вместо нее в любой момент
можно использовать ввод пароля. Ввести пароль автоматически предлагается
после трех безуспешных попыток сопоставления отпечатка пальца, а после пяти
безуспешных попыток ввод пароля становится обязательным. Кроме того, пароль
требуется, если технология Touch ID не настроена или ее использование
не включено для Apple Pay.
Secure Enclave и защищенный элемент взаимодействуют через последовательный
интерфейс; защищенный элемент связан с контроллером NFC, который, в свою
очередь, соединен с процессором программ. Хотя они и не связаны напрямую,
Secure Enclave и защищенный элемент могут безопасно взаимодействовать,
используя общий ключ пары, который подготавливается при производстве
устройства. Шифрование и аутентификация передаваемых данных выполняются
на основе AES, и обе стороны используют криптографические значения nonce для
защиты от атак с повторением пакетов. Ключ пары генерируется в Secure Enclave
из его ключа UID и уникального идентификатора защищенного элемента. Затем
ключ пары безопасно передается из Secure Enclave в аппаратный модуль системы
безопасности (HSM) на заводе, где есть необходимый материал для последующего
внедрения ключа пары в защищенный элемент.
Обзор безопасности iOS | Сентябрь 2015 г.
37
Когда пользователь авторизует транзакцию, Secure Enclave отправляет
подписанные данные о типе аутентификации и сведения о типе транзакции
(бесконтактная или в программе) защищенному элементу в связке со случайным
значением авторизации (AR). Значение AR генерируется в Secure Enclave, когда
пользователь впервые подготавливает кредитную карту. Оно сохраняется, пока
включена технология Apple Pay, и защищается шифрованием Secure Enclave
и противооткатным механизмом. Оно безопасно передается защищенному
элементу с помощью ключа пары. При получении нового значения AR защищенный
элемент помечает все ранее добавленные карты как удаленные.
Кредитные и дебетовые карты, добавленные в защищенный элемент, можно
использовать, только если защищенный элемент получает авторизацию с теми
же ключом пары и значением AR, которые использовались при добавлении карты.
Это позволяет iOS сообщать Secure Enclave, какие карты следует отображать как
недоступные, отмечая свою копию значения AR как недействительную в следующих
ситуациях.
Если пароль отключен:
• Пользователь выходит из iCloud.
• Пользователь выбирает стирание всего контента и настроек.
• Устройство восстанавливается с помощью режима восстановления.
На Apple Watch карты помечаются как недействительные в следующих случаях:
• Пароль часов отключен.
• Разорвана пара между часами и iPhone.
• Отключено распознавание запястья.
Используя ключ пары и свою копию текущего значения AR, защищенный элемент
проверяет авторизацию, полученную от Secure Enclave, прежде чем разрешить
платежному апплету бесконтактную оплату. Этот процесс также применяется
при получении зашифрованных платежных данных от платежного апплета для
транзакций в программах.
Динамический код безопасности, назначаемый каждой
транзакции
Все платежные транзакции, инициируемые платежными апплетами, содержат
динамический код безопасности, назначаемый каждой транзакции, а также
учетный номер устройства. Этот одноразовый код вычисляется с помощью
счетчика, значение которого увеличивается для каждой новой транзакции, и ключа,
подготавливаемого платежным апплетом в ходе персонализации и известного
платежной сети и/или эмитенту карты. В зависимости от схемы оплаты при расчете
этих кодов могут также использоваться другие данные, например:
• Случайное число, генерируемое платежным апплетом
• Другое случайное число, генерируемое терминалом при NFC-транзакциях
или
• Другое случайное число, генерируемое сервером при транзакциях в программах
Эти коды безопасности предоставляются платежной сети и эмитенту карты, что
позволяет им проверять каждую транзакцию. Длина таких кодов безопасности
может быть различной и зависит от типа выполняемой транзакции.
Обзор безопасности iOS | Сентябрь 2015 г.
38
Бесконтактные платежи с использованием Apple Pay
Если iPhone включен и обнаруживает зону действия NFC, то предлагает
пользователю подходящую кредитную или дебетовую карту либо карту
по умолчанию (этим можно управлять в Настройках). Кроме того, пользователь
может открыть программу Wallet и выбрать кредитную или дебетовую карту,
а если устройство заблокировано, дважды нажать кнопку «Домой».
Затем, прежде чем платежная информация будет передана, пользователь должен
пройти аутентификацию, используя Touch ID или свой пароль. Если Apple Watch
разблокированы, при двойном нажатии боковой кнопки для оплаты активируется
карта по умолчанию. Без аутентификации пользователя платежная информация
не отправляется.
После аутентификации пользователя для обработки платежа используются учетный
номер устройства и динамический код безопасности, назначаемый каждой
транзакции. Ни Apple, ни устройство пользователя не отправляют продавцу
полный фактический номер кредитной или дебетовой карты. Apple может
получать анонимные данные о транзакции, такие как примерное место и время
ее выполнения. Это помогает улучшить работу Apple Pay и других продуктов
и служб Apple.
Оплата покупок в программах с помощью Apple Pay
Apple Pay также можно использовать для оплаты покупок в программах iOS.
Когда пользователи выполняют оплату в программах, используя Apple Pay, Apple
получает зашифрованную информацию о транзакции и, прежде чем отправить
ее продавцу, заново шифрует ее с использованием ключа, назначаемого каждому
продавцу. Apple Pay сохраняет анонимную информацию о транзакции, например
примерную сумму покупки. Эта информация не может привести обратно
к пользователю и не содержит данных о том, что именно было куплено.
Когда программа запускает платежную транзакцию Apple Pay, серверы Apple Pay
получают зашифрованную транзакцию с устройства раньше, чем ее получит
продавец. Затем серверы Apple Pay повторно шифруют ее с использованием
ключа, назначаемого каждому продавцу, после чего ретранслируют транзакцию
продавцу.
Когда программа запрашивает оплату, она вызывает API, чтобы определить,
поддерживает ли устройство Apple Pay и есть ли у пользователя кредитные
или дебетовые карты, которыми можно оплатить покупку в платежной сети,
поддерживаемой продавцом. Программа запрашивает всю информацию,
необходимую для обработки и выполнения транзакции, например расчетный
адрес, адрес доставки и контактные данные. Затем программа подает iOS запрос
на предоставление листа Apple Pay, и система запрашивает информацию для
программы, а также другие необходимые сведения, например то, какую карту
следует использовать.
В это время программа получает данные о городе, регионе/штате и индексе,
позволяющие вычислить итоговую стоимость доставки. Полный набор
запрошенной информации не предоставляется программе до тех пор, пока
пользователь не авторизует платеж с помощью Touch ID или пароля устройства.
После авторизации платежа информация, представленная в листе Apple Pay,
передается продавцу.
Когда пользователь авторизует оплату, выполняется вызов на серверы Apple Pay
для получения криптографических значений nonce — аналогично значению,
возвращаемому терминалом NFC при выполнении транзакции в магазине.
Обзор безопасности iOS | Сентябрь 2015 г.
39
Значение nonce вместе с другими данными транзакции передается защищенному
элементу для генерации учетных данных для оплаты, которые будут зашифрованы
с помощью ключа Apple. Защищенный элемент передает зашифрованные учетные
данные для оплаты серверам Apple Pay, которые расшифровывают их, сравнивают
значение nonce из учетных данных со значением nonce, переданным защищенным
элементом, и повторно шифруют учетные данные для оплаты с помощью ключа
продавца, связанного с идентификатором продавца. Затем они возвращаются
на устройство, которое возвращает их программе, используя API. Программа
передает их в систему продавца для обработки. Продавец может расшифровать
учетные данные для оплаты, используя свой закрытый ключ, и обработать их.
Это в сочетании с подписью серверов Apple позволяет продавцу проверить, что
транзакция предназначена именно ему.
Интерфейсам API требуются права, в которых указаны идентификаторы
поддерживаемых продавцов. Программа также может отправить на подпись
защищенному элементу дополнительные данные, например номер заказа или
удостоверение покупателя, чтобы гарантировать, что транзакция не будет связана
с другим пользователем. Эту задачу выполняет разработчик программы.
Разработчик программы может задать данные applicationData в запросе
PKPaymentRequest. Хэш этих данных включается в зашифрованные платежные
данные. Затем продавец должен проверить, что хэш его данных applicationData
совпадает с включенным в платежные данные.
Скидочные карты
Начиная с iOS 9 в Apple Pay поддерживается протокол VAS (Value Added Service —
дополнительная услуга) для передачи данных о скидочных картах на совместимые
терминалы NFC. Протокол VAS можно применять на терминалах продавцов.
Он использует NFC для взаимодействия с поддерживаемыми устройствами
Apple. Протокол VAS работает на коротком расстоянии и используется для
предоставления дополнительных услуг, таких как передача информации
о скидочных картах, в рамках выполнения транзакции Apple Pay.
Терминал NFC запускает процесс приема данных о карте, отправляя
соответствующий запрос. Если у пользователя есть карта с идентификатором
магазина, появляется запрос, и пользователь должен авторизовать
ее использование. Если продавец поддерживает шифрование, информация о карте,
временная метка и одноразовый случайный ключ ECDH P-256 используются вместе
с открытым ключом продавца, чтобы получить ключ шифрования для данных карты,
которые отправляются на терминал. Если продавец не поддерживает шифрование,
появляется запрос, и пользователь должен еще раз поднести устройство
к терминалу, прежде чем информация о скидочной карте будет отправлена.
Обзор безопасности iOS | Сентябрь 2015 г.
40
Приостановка действия, удаление и стирание карт
Пользователи могут приостановить действие Apple Pay на iPhone и iPad, переведя
устройства в режим пропажи с помощью функции «Найти iPhone». Кроме того,
пользователи могут удалять и стирать свои карты из Apple Pay, используя функцию
«Найти iPhone» или настройки iCloud, либо прямо с устройства с помощью
программы Wallet. На Apple Watch карты можно удалять с помощью настроек
iCloud, программы Apple Watch на iPhone либо прямо с часов. Возможность
проведения оплаты с помощью карт на устройстве будет приостановлена или
удалена из Apple Pay эмитентом карты или соответствующей платежной сетью,
даже если устройство не подключено к сети сотовой связи или Wi-Fi. Пользователи
также могут позвонить эмитенту карты с просьбой приостановить действие или
удалить карты из Apple Pay.
Кроме того, когда пользователь стирает все данные с устройства с помощью
функции «Стереть контент и настройки», функции «Найти iPhone» или при
восстановлении устройства с помощью режима восстановления, iOS передает
защищенному элементу команду пометить все карты как удаленные. При этом все
карты мгновенно переводятся в недействительное состояние, а после подключения
к серверам Apple Pay полностью стираются из защищенного элемента. Независимо
от этого процесса Secure помечает значение AR как недействительное, чтобы
авторизация оплаты с использованием ранее зарегистрированных карт больше
не была возможна. При подключении к сети устройство пытается связаться
с серверами Apple Pay, чтобы гарантировать, что все карты стерты из защищенного
элемента.
Обзор безопасности iOS | Сентябрь 2015 г.
41
Интернет-службы
Создание надежных паролей Apple ID
Идентификатор Apple ID используется для
подключения к целому ряду служб, включая
iCloud, FaceTime
и iMessage. Чтобы пароли, создаваемые
пользователями, были надежными, для всех
новых учетных записей пароли должны:
• содержать не менее восьми символов;
• содержать не менее одной буквы;
• содержать не менее одной заглавной
буквы;
• содержать не менее одной цифры;
• содержать не более трех одинаковых
символов подряд;
• отличаться от имени учетной записи.
Apple предлагает широкий набор служб для повышения практичности
и эффективности устройств, включая такие службы, как iMessage, FaceTime, Siri,
Предложения Spotlight, iCloud, Резервное копирование iCloud и Связка ключей
iCloud.
Эти интернет-службы построены на тех же критериях обеспечения безопасности,
которые лежат в основе всей платформы iOS. Сюда входит безопасная обработка
данных, как при хранении на устройстве, так и при передаче по беспроводным
сетям; защита личной информации пользователей; и предотвращение
вредоносного или несанкционированного доступа к информации и службам.
Каждая служба задействует собственную мощную архитектуру обеспечения
безопасности, не нарушая общей простоты использования iOS.
Apple ID
Apple ID — это имя пользователя и пароль, используемые для входа в систему
различных служб Apple, таких как iCloud, iMessage, FaceTime, iTunes Store,
iBooks Store, App Store и многие другие. Пользователи должны хранить свои
идентификаторы Apple ID в безопасности, чтобы защитить свои учетные записи
от несанкционированного доступа. Для этого Apple требует использовать
надежные пароли, которые должны содержать не менее восьми символов,
включать буквы и цифры, содержать не более трех одинаковых символов подряд
и не должны совпадать с часто используемыми паролями. Пользователям
рекомендуется устанавливать еще более надежные пароли, добавляя
дополнительные символы и знаки препинания. Кроме того, если в учетную
запись были внесены важные изменения, например, были изменены платежные
данные или пароль либо идентификатор Apple ID был использован для входа
на новом устройстве, Apple отправляет пользователям электронные письма
и push‑уведомления. Если что-то выглядит незнакомым, пользователям
рекомендуется незамедлительно изменить свой пароль Apple ID.
Apple также предлагает двухэтапную проверку идентификатора Apple ID, которая
обеспечивает второй уровень защиты учетной записи пользователя. Если включена
двухэтапная проверка, то перед внесением изменений в учетную запись Apple ID,
в iCloud, iMessage, FaceTime или Game Center либо перед совершением покупок
в iTunes Store, iBooks Store или App Store с нового устройства пользователь должен
подтвердить свою личность с помощью временного кода, который будет отправлен
на одно из доверенных устройств пользователя. Это не позволит постороннему
лицу получить доступ к учетной записи пользователя, даже если он узнает пароль.
Пользователи также получают 14-символьный ключ восстановления, который
следует хранить в безопасном месте на случай, если они забудут пароль или
лишатся доступа к своим доверенным устройствам.
Подробную информацию о двухэтапной проверке Apple ID см. на странице
https://support.apple.com/ru-ru/ht5570.
Обзор безопасности iOS | Сентябрь 2015 г.
42
iMessage
Apple iMessage — это служба обмена сообщениями для устройств iOS
и компьютеров Mac. С помощью iMessage можно передавать не только текст,
но и различные вложения, включая фотографии, контакты и географические
координаты. Сообщения отображаются на всех зарегистрированных устройствах
пользователя, поэтому начатый диалог можно продолжить на любом удобном
устройстве. iMessage активно использует службу Apple Push Notification Service
(APNs). Apple не сохраняет сообщения или вложения, а их содержимое защищено
с помощью сквозного шифрования, поэтому никто, кроме отправителя
и получателя, не может получить к ним доступ. Apple не может расшифровать
данные.
Когда пользователь включает iMessage на устройстве, оно генерирует две
пары ключей для работы со службой: 1280-битный ключ RSA для шифрования
и 256-битный ключ ECDSA на основе кривой NIST P-256 для подписания. Личные
ключи из обеих пар ключей сохраняются в связке ключей устройства, а открытые
ключи передаются в службу каталогов Apple (IDS), где они связываются с номером
телефона или адресом электронной почты пользователя, а также с APNs-адресом
устройства.
По мере того как пользователь включает iMessage на дополнительных устройствах,
их открытые ключи шифрования и подписания, APNs-адреса и связанные
номера телефонов добавляются в службу каталогов. Пользователь также может
добавить дополнительные адреса электронной почты, которые будут проверены
путем отправки ссылки для подтверждения. Для проверки номеров телефона
используется сеть оператора и SIM-карта. При добавлении нового устройства,
номера телефона или адреса электронной почты на всех зарегистрированных
устройствах пользователя отображается соответствующее сообщение.
Процесс отправки и получения сообщений в iMessage
Чтобы начать новый диалог iMessage, пользователь вводит адрес или имя
собеседника. Если пользователь вводит номер телефона или адрес электронной
почты, устройство связывается с IDS для получения открытых ключей и APNsадресов для всех устройств, связанных с адресатом. Если пользователь вводит имя,
устройство сначала извлекает из программы «Контакты» связанные с этим именем
номера телефонов и адреса электронной почты, а затем получает открытые ключи
и APNs-адреса из IDS.
Исходящие сообщения пользователя шифруются отдельно для каждого
из устройств получателя. Открытые ключи шифрования RSA принимающих
устройств извлекаются из IDS. Для каждого принимающего устройства
отправляющее устройство генерирует случайный 128-битный ключ и шифрует
сообщение с помощью этого ключа по алгоритму AES в режиме CTR. Этот ключ AES
отдельного сообщения шифруется по схеме RSA-OAEP с использованием открытого
ключа принимающего устройства. Сочетание зашифрованного текста сообщения
и зашифрованного ключа сообщения хэшируется с использованием SHA-1,
затем хэш подписывается по алгоритму ECDSA с использованием личного ключа
подписания передающего устройства. Результатом являются сообщения —
по одному для каждого принимающего устройства — которые состоят
из зашифрованного текста сообщения, зашифрованного ключа сообщения
и цифровой подписи отправителя. Затем они передаются в APNs для доставки
адресатам. Шифрование метаданных, таких как метка времени и информация
о маршрутизации APNs, не выполняется. Связь с APNs шифруется с использованием
канала TLS с прямой секретностью.
Обзор безопасности iOS | Сентябрь 2015 г.
43
APNs может ретранслировать сообщения размером до 4 или 16 КБ в зависимости
от версии iOS. Если текст сообщения слишком длинный либо к сообщению
приложена фотография или другой большой объект, вложение шифруется
по алгоритму AES в режиме CTR с использованием случайного 256-битного
ключа и загружается в iCloud. Затем в виде содержимого iMessage получателю
пересылается ключ AES для вложения, его универсальный идентификатор ресурса
(URI) и хэш SHA-1 для зашифрованной формы. За защиту их конфиденциальности
и целостности отвечает стандартный процесс шифрования iMessage, который
описан ниже.
Вложение,
зашифрованное с помощью
случайного ключа
iCloud
APNs
Подписанное и зашифрованное
сообщение для пользователя 2
с URI и ключом вложения
Пользователь 2
Пользователь 1
Открытый ключ и токен APNs
для пользователя 2
Открытый ключ и токен APNs
для пользователя 1
IDS
При отправке групповых сообщений эта процедура повторяется для каждого получателя
и его устройств.
На принимающей стороне каждое устройство получает свою копию сообщения
из APNs и при необходимости извлекает вложение из iCloud. Входящий номер
телефона или адрес электронной почты отправителя сравнивается со списком
контактов получателя, чтобы по возможности отобразить имя отправителя.
Как и все push-уведомления, сообщения удаляются из APNs после доставки.
В отличие от других уведомлений APNs, если устройство отключено, сообщения
iMessage ставятся в очередь для последующей отправки. В настоящее время
сообщения хранятся в течение тридцати дней.
FaceTime
FaceTime — это служба Apple для совершения видео- и аудиозвонков.
Аналогично iMessage, для установления первоначального соединения
с зарегистрированными устройствами пользователя вызовы FaceTime также
используют службу Apple Push Notification. Содержимое вызовов FaceTime
защищено с помощью сквозного шифрования, поэтому никто, кроме отправителя
и получателя, не может получить к ним доступ. Apple не может расшифровать
данные.
Обзор безопасности iOS | Сентябрь 2015 г.
44
Для установления прямого соединения между устройствами функция FaceTime
использует Internet Connectivity Establishment (ICE). Устройства проверяют
свои сертификаты удостоверения и выбирают общий ключ для каждого сеанса,
используя сообщения Session Initiation Protocol (SIP). Криптографические значения
nonce, предоставленные каждым устройством, объединяются с ключами «соли»
для каждого из медиаканалов, которые передаются в потоковом режиме через
Secure Real Time Protocol (SRTP) с использованием шифрования AES-256.
iCloud
iCloud хранит контакты, календари, фотографии, документы и другие данные
пользователя и автоматически поддерживает их актуальность на всех устройствах
пользователя. Кроме того, программы сторонних разработчиков могут
использовать iCloud для хранения и синхронизации документов, а также значений
ключей для программ в соответствии с настройками разработчика. Для настройки
iCloud пользователям необходимо войти в систему со своим Apple ID и выбрать
требуемые службы. Функции iCloud, включая Мой Фотопоток, iCloud Drive
и Резервное копирование, могут быть отключены ИТ-администратором
с помощью профиля конфигурации. Служба не учитывает тип хранящихся данных
и обрабатывает все содержимое файлов одинаково, просто как набор байтов. Каждый файл разбивается на фрагменты и шифруется iCloud с использованием
AES-128 и производного ключа, полученного из содержимого каждого фрагмента
с хэшированием SHA-256. Ключи и метаданные файла сохраняются в учетной
записи iCloud пользователя. Зашифрованные фрагменты файлов сохраняются без
какой-либо идентифицирующей пользователя информации в сторонних службах
хранения, таких как Amazon S3 и Windows Azure.
iCloud Drive
iCloud Drive использует ключи на основе учетных записей для защиты документов,
хранящихся в iCloud. Как и существующие службы iCloud, iCloud Drive разбивает
содержимое файла на фрагменты, шифрует их и сохраняет с помощью сторонних
служб. Однако ключи содержимого файлов защищаются с помощью ключей
записей, хранящихся вместе с метаданными iCloud Drive. Эти ключи записей,
в свою очередь, защищаются пользовательским ключом службы iCloud Drive,
который затем сохраняется вместе с учетной записью iCloud пользователя.
Для получения доступа к метаданным своих документов в iCloud пользователям
необходимо пройти аутентификацию в iCloud, а также иметь ключ службы
iCloud Drive для раскрытия защищенных частей хранилища iCloud Drive.
CloudKit
Благодаря CloudKit разработчики могут хранить в iCloud значения ключей,
структурированные данные и ресурсы. Для контроля доступа к CloudKit
используются права программ. CloudKit поддерживает как открытые, так и личные
базы данных. Открытые базы данных используются всеми копиями программы,
обычно предназначены для общих ресурсов и не шифруются. Личные базы данных
используются для хранения данных пользователей.
Как и в случае iCloud Drive, для защиты информации, хранящейся в личной базе
данных пользователя, CloudKit использует ключи на основе учетных записей,
а сами файлы разбиваются на фрагменты, шифруются и хранятся с помощью
сторонних служб. Аналогично системе защиты данных, CloudKit использует
иерархию ключей. Ключи файлов защищаются с помощью ключей записей CloudKit.
Ключи записей, в свою очередь, защищаются с помощью ключа зоны, который
защищается ключом службы CloudKit пользователя. Ключ службы CloudKit хранится
в учетной записи iCloud пользователя и доступен только после аутентификации
пользователя в iCloud.
Обзор безопасности iOS | Сентябрь 2015 г.
45
Ключ службы
CloudKit
Ключ зоны
CloudKit
Ключ записи
CloudKit
Метаданные
файла
Список
фрагментов
файла
Фрагмент
файла
Конвергентное
шифрование
Резервное копирование iCloud
iCloud также выполняет ежедневное резервное копирование информации,
включая настройки устройства, данные программ, фотографии и видео из альбома
«Фотопленка», а также диалоги из программы «Сообщения», по сети Wi-Fi. Для
обеспечения безопасности содержимого iCloud принимаются следующие меры:
шифрование при передаче через Интернет, хранение в зашифрованном формате
и использование токенов безопасности для аутентификации. Для резервного
копирования iCloud необходимо, чтобы экран устройства был заблокирован,
устройство было подключено к источнику питания и к Интернету через Wi-Fi.
Благодаря тому что в iOS используется шифрование, система обеспечивает
безопасность данных при автоматическом инкрементном резервном копировании
и восстановлении.
iCloud создает резервные копии следующих элементов:
• информация о приобретенной музыке, фильмах, телешоу, программах и книгах,
но не сами приобретенные материалы;
• фотографии и видеоролики из альбома «Фотопленка»;
• контакты, события календаря, напоминания и заметки;
• настройки устройства;
• данные программ;
• PDF и книги, добавленные в iBooks, но не купленные;
• история вызовов;
• экран «Домой» и организация программ;
• сообщения iMessage, SMS и MMS;
• рингтоны;
• данные HomeKit;
• данные HealthKit;
• сообщения визуального автоответчика.
Если файлы создаются с классами защиты данных, которые недоступны при
заблокированном устройстве, их ключи файлов шифруются с использованием
ключей классов из хранилища ключей резервного копирования iCloud. Файлы
включаются в резервные копии iCloud в исходном, незашифрованном состоянии.
Файлы, имеющие класс защиты «Без защиты», шифруются во время передачи.
Хранилище ключей резервного копирования iCloud содержит асимметричные
ключи (Curve25519) для каждого класса защиты данных, используемые для
шифрования ключей файлов. Подробнее о содержимом хранилища ключей
резервного копирования и хранилища ключей резервного копирования iCloud
см. «Защита данных связки ключей» в разделе «Шифрование и защита данных».
Обзор безопасности iOS | Сентябрь 2015 г.
46
Комплект резервной копии, состоящий из копии файлов пользователя и хранилища
ключей резервного копирования iCloud, сохраняется в учетной записи iCloud
пользователя. Хранилище ключей резервного копирования iCloud защищается
с помощью случайного ключа, который также сохраняется в комплекте резервной
копии. (Пароль iCloud пользователя не используется для шифрования, поэтому
изменение пароля iCloud не приводит к аннулированию существующих резервных
копий.)
При хранении в iCloud резервная копия базы данных связки ключей пользователя
защищена ключом, который связан с UID. Благодаря этому восстановить связку
ключей можно только на том устройстве, с которого она получена, и никто другой,
включая Apple, не может прочитать элементы связки ключей пользователя.
При восстановлении выполняется извлечение резервных копий файлов,
хранилища ключей резервного копирования iCloud и ключа от хранилища
ключей из учетной записи iCloud пользователя. Сначала с помощью этого ключа
дешифруется хранилище ключей резервного копирования iCloud, а затем
с помощью ключей файлов из хранилища ключей дешифруются файлы,
хранившиеся в комплекте резервной копии. Эти файлы сохраняются в файловой
системе как новые файлы, поэтому они повторно шифруются с учетом своего
класса защиты данных.
Интеграция Safari со Связкой ключей
iCloud
Safari может автоматически
генерировать криптографически стойкие
случайные строки для использования
в качестве паролей веб-сайтов, которые
будут храниться в Связке ключей
и синхронизироваться с другими
устройствами. Элементы связки ключей
передаются между устройствами
и серверами Apple, однако они
зашифрованы таким образом, чтобы
компания Apple и другие устройства
не могли прочитать их содержимое.
Связка ключей iCloud
Связка ключей iCloud обеспечивает безопасную синхронизацию паролей
пользователей между устройствами iOS и компьютерами Mac без передачи этой
информации в компанию Apple. Помимо высокого уровня конфиденциальности
и безопасности, при разработке дизайна и архитектуры Связки ключей iCloud
учитывались такие аспекты, как простота использования и возможность
восстановления связки ключей. Связка ключей iCloud состоит из двух служб:
синхронизации связки ключей и восстановления связки ключей.
Связка ключей iCloud и восстановление связки ключей реализованы таким
образом, что пароли пользователя остаются защищены даже в следующих
ситуациях:
• Учетная запись iCloud пользователя взломана.
• Служба iCloud взломана сторонним злоумышленником или сотрудником.
• Доступ третьей стороной к учетным записям пользователей.
Синхронизация связки ключей
Когда пользователь впервые включает Связку ключей iCloud, устройство
устанавливает круг доверия и создает для себя идентификатор синхронизации.
Идентификатор синхронизации состоит из личного ключа и открытого ключа.
Открытый ключ идентификатора синхронизации помещается в круг, а сам круг
подписывается дважды: в первый раз с помощью личного ключа идентификатора
синхронизации, а во второй раз с помощью асимметричного эллиптического ключа
(на основе P256), полученного из пароля учетной записи iCloud пользователя.
Вместе с кругом сохраняются параметры (случайное значение «соли» и число
повторений), использованные для создания ключа из пароля учетной записи iCloud
пользователя.
Подписанный круг синхронизации размещается в хранилище значений ключей
iCloud пользователя. Его нельзя прочитать, не зная пароля iCloud пользователя,
и нельзя изменить, не имея личного ключа идентификатора синхронизации одного
из членов круга.
Обзор безопасности iOS | Сентябрь 2015 г.
47
Когда пользователь включает Связку ключей iCloud на другом устройстве, новое
устройство видит в iCloud, что пользователь установил круг синхронизации,
в который оно не входит. Устройство создает для себя пару ключей
идентификатора синхронизации, а затем создает билет заявки для запроса
членства в круге. Билет содержит открытый ключ идентификатора синхронизации
устройства. Пользователь получает запрос на прохождение аутентификации
с использованием своего пароля iCloud. Из iCloud извлекаются параметры
генерирования эллиптического ключа, используемые для создания ключа, а затем
этот ключ используется для подписания билета заявки. Наконец, билет заявки
передается в iCloud.
Когда первое устройство обнаруживает поступление билета заявки, оно
отображает сообщение для пользователя с информацией о том, что новое
устройство просит разрешение присоединиться к кругу. Пользователь вводит
свой пароль iCloud, после чего билет заявки проверяется на использование
соответствующего личного ключа. Это подтверждает, что пользователь, который
отправил запрос на присоединение к кругу, ввел свой пароль iCloud при
генерировании запроса.
После того как пользователь разрешает добавить новое устройство в круг,
первое устройство добавляет в круг синхронизации открытый ключ нового члена
и подписывает его еще раз с помощью своего идентификатора синхронизации
и ключа, полученного из пароля iCloud пользователя. Новый круг синхронизации
передается в iCloud, где его аналогичным образом подписывает новый член круга.
Теперь в круг входят два члена, и у каждого из них есть открытый ключ другого
члена. Члены круга начинают обмениваться отдельными элементами связки
ключей через хранилище значений ключей iCloud. Если оба члена круга содержат
одинаковый элемент с разными датами изменения, оба получают элемент
с более новой датой изменения, т. е. синхронизируются. Если даты изменения
совпадают, элемент пропускается. Каждый синхронизированный элемент
шифруется специально для устройства, на которое он пересылается. Он не может
быть расшифрован другими устройствами или компанией Apple. Кроме того,
зашифрованный элемент сохраняется в iCloud только на короткое время;
он заменяется новым элементом при каждой синхронизации.
Когда к кругу присоединяются новые устройства, процедура повторяется.
Например, при присоединении третьего устройства подтверждение отображается
на других двух устройствах пользователя. Пользователь может утвердить
нового члена с любого из этих устройств. При добавлении нового члена круга
выполняется его синхронизация с другими членами круга, чтобы на всех
устройствах хранились одинаковые элементы связки ключей.
Однако синхронизируется не вся связка ключей. Некоторые элементы, например
идентификаторы VPN, относятся к конкретному устройству и не должны
его покидать. Синхронизируются только элементы с атрибутом
kSecAttrSynchronizable. Компания Apple установила этот атрибут для
пользовательских данных Safari (включая имена пользователей, пароли и номера
кредитных карт), а также для паролей Wi-Fi и ключей шифрования HomeKit.
Кроме того, по умолчанию в синхронизации не участвуют элементы связки
ключей, добавленные программами сторонних разработчиков. При добавлении
элементов в связку ключей разработчики должны установить атрибут
kSecAttrSynchronizable.
Обзор безопасности iOS | Сентябрь 2015 г.
48
Восстановление связки ключей
Функция восстановления связки ключей позволяет передать свою связку ключей
на хранение в компанию Apple, не давая ей возможности считывать пароли или
другие данные в связке ключей. Даже если у пользователя есть только одно
устройство, функция восстановления связки ключей обеспечивает защиту
от потери данных. Это особенно важно, если Safari генерирует для учетных записей
веб-сайтов случайные, надежные пароли, поскольку единственный экземпляр этих
паролей хранится в связке ключей.
Фундаментальным элементом восстановления связки ключей является служба
дополнительной аутентификации и безопасного ответственного хранения,
разработанная компанией Apple специально для поддержки этой функции.
Связка ключей пользователя зашифрована с использованием надежного пароля,
и служба ответственного хранения выдает копию этой связки ключей только при
соблюдении строгого набора условий.
При включении Связки ключей iCloud пользователь получает запрос на создание
кода безопасности iCloud. Этот код необходим для восстановления переданной
на хранение связки ключей. По умолчанию пользователям достаточно указать
простое значение из четырех цифр. Однако пользователи также могут
указать собственный, более длинный код или позволить устройству создать
криптографически случайный код, который они могут записать и хранить
самостоятельно.
Затем устройство iOS экспортирует копию связки ключей пользователя, шифрует
ее с помощью ключей из хранилища асимметричных ключей и помещает
в хранилище значений ключей iCloud пользователя. Хранилище ключей
защищается с помощью кода безопасности iCloud и открытого ключа кластера
HSM (аппаратный модуль системы безопасности), в котором будет храниться
запись ответственного хранения. Эта запись становится записью ответственного
хранения iCloud пользователя.
Если вместо того, чтобы задавать свой собственный сложный или четырехзначный
код, пользователь решит принять криптографически случайный код, запись
ответственного хранения будет не нужна. Для защиты случайного ключа будет
использован код безопасности iCloud.
Помимо указания кода безопасности, пользователи должны зарегистрировать
номер телефона. Он используется в качестве второго уровня аутентификации
при восстановлении связки ключей. Пользователь получает сообщение SMS,
на которое он должен ответить, чтобы продолжить процесс восстановления.
Безопасность ответственного хранения
iCloud предоставляет инфраструктуру безопасности, которая гарантирует, что
восстановление переданной на хранение связки ключей смогут выполнить только
авторизованные пользователи и устройства. За iCloud расположены кластеры
аппаратных модулей системы безопасности (HSM). Эти кластеры защищают записи
ответственного хранения. Каждый кластер имеет ключ, который используется для
шифрования находящихся под его контролем записей ответственного хранения,
как было описано ранее.
Обзор безопасности iOS | Сентябрь 2015 г.
49
Чтобы восстановить связку ключей, пользователь должен пройти аутентификацию
с использованием своей учетной записи и пароля iCloud, а также ответить
на сообщение SMS, которое будет отправлено на зарегистрированный номер
телефона. Затем пользователь должен ввести свой код безопасности iCloud.
Чтобы убедиться, что пользователь знает свой код безопасности iCloud, кластер
HSM использует протокол Secure Remote Password; сам код не пересылается
в компанию Apple. Каждый член кластера независимо от других убеждается, что
пользователь не превысил максимальное количество попыток извлечения своей
записи (см. ниже). Если большинство членов кластера соглашаются с этим, кластер
снимает защиту с записи ответственного хранения и отправляет ее на устройство
пользователя.
Затем устройство с помощью кода безопасности iCloud дешифрует случайный
ключ, который был использован для шифрования связки ключей пользователя.
С помощью этого ключа выполняется дешифрование и восстановление
на устройстве связки ключей, извлеченной из хранилища значений ключей
iCloud. Допускается только 10 попыток аутентификации и извлечения записи
ответственного хранения. После нескольких неудавшихся попыток запись
блокируется, и, чтобы получить право на дополнительные попытки, пользователь
должен позвонить в службу поддержки Apple. После десятой неудавшейся попытки
кластер HSM уничтожает запись ответственного хранения, и восстановить связку
ключей невозможно. Такой подход защищает от попыток извлечь запись методом
перебора, но жертвует связкой ключей.
Эти политики закодированы в прошивке HSM. Карты административного доступа,
разрешающие вносить изменения в прошивку, уничтожены. Любая попытка
изменения прошивки или доступа к личному ключу приводит к тому, что кластер
HSM удаляет личный ключ. Если это происходит, все владельцы связок ключей,
защищенных этим кластером, получают сообщение о том, что их записи
ответственного хранения были утеряны. При желании пользователи могут
зарегистрироваться повторно.
Siri
Используя естественную речь, пользователи могут поручить Siri отправлять
сообщения, планировать встречи, звонить по телефону и многое другое.
Для ответа на самые разные запросы Siri использует технологии распознавания
речи, преобразования текста в речь и модель клиент-сервер. Набор
поддерживаемых Siri задач продуман таким образом, чтобы использовать
минимально возможное количество личной информации и гарантировать
ее полную защиту.
При включении Siri устройство создает случайные идентификаторы,
предназначенные для использования с функцией распознавания речи
и серверами Siri. Эти идентификаторы используются только в службе Siri
и направлены на повышение качества обслуживания. Если в дальнейшем функция
Siri будет отключена, устройство сгенерирует новый случайный идентификатор,
который будет использован после включения Siri.
Чтобы оптимизировать работу Siri, на сервер передается определенная
пользовательская информация с устройства. Сюда входит информация о медиатеке
(названия песен, исполнителей и плейлистов), названия списков напоминаний,
а также имена и связи, заданные в программе «Контакты». Весь обмен
информацией с сервером осуществляется по HTTPS.
Обзор безопасности iOS | Сентябрь 2015 г.
50
При запуске сеанса Siri на сервер передаются имя и фамилия пользователя
(из программы «Контакты»), а также примерное местонахождение пользователя.
Благодаря этому Siri может обратиться к пользователю по имени или ответить
на вопросы, требующие знания только примерного местонахождения, например,
вопросы о погоде.
Если требуется знать более точные координаты пользователя, например, для
поиска кинотеатров поблизости, сервер запрашивает у устройства более точную
информацию. Это один из примеров того, что информация передается на сервер
только в том случае, если без нее невозможно обработать запрос пользователя.
В любом случае информация сеанса удаляется после 10 минут бездействия.
При обращении к Siri с устройства Apple Watch оно создает собственный
случайный идентификатор, как описано выше. Однако, вместо повторной
пересылки информации о пользователе, вместе с запросом передается ссылка
на эту информацию — идентификатор Siri, который назначен связанному iPhone.
Запись голосового запроса пользователя передается на сервер распознавания
речи Apple. Если задача ограничивается диктовкой, распознанный текст
передается обратно на устройство. В противном случае Siri анализирует текст
и при необходимости объединяет его с информацией из профиля устройства.
Например, если запрос звучит как «отправить сообщение маме», для его обработки
используются связи и имена, загруженные из программы «Контакты». Команда для
выполнения распознанного действия отправляется обратно на устройство.
Многие действия Siri выполняются устройством под управлением сервера.
Например, если пользователь просит Siri прочитать входящее сообщение, сервер
просто сообщает устройству, что ему необходимо прочитать вслух содержимое
непрочитанных сообщений. Содержимое и отправитель сообщения
не пересылаются на сервер.
Записи голосовых запросов пользователей хранятся на сервере в течение шести
месяцев. Система распознавания речи использует эти записи, чтобы лучше
понимать голос пользователя. По прошествии шести месяцев сохраняется другая
копия этих записей — уже без идентификатора. Apple хранит эту копию не более
двух лет и использует ее для улучшения и развития Siri. Кроме того, для целей
развития Siri сохраняется ряд других записей, в которых упоминается музыка,
спортивные команды, игроки, предприятия или достопримечательности.
Функцию Siri можно активировать голосом. Распознавание команды запуска
выполняется непосредственно на устройстве. В этом режиме Siri активируется
только в том случае, если звучание поступившего аудиозапроса достаточно близко
соответствует настроенной команде запуска. При распознавании команды запуска
соответствующая аудиозапись, включая последующую команду для Siri, передается
на сервер распознавания речи Apple для дальнейшей обработки. Эта обработка
выполняется в соответствии с теми же правилами, которые применяются для
остальных записей голосовых запросов пользователей к Siri.
Непрерывность
Функция «Непрерывность» задействует возможности таких технологий, как
iCloud, Bluetooth и Wi-Fi, чтобы пользователи могли начинать действие на одном
устройстве, а завершать его на другом, совершать и принимать телефонные
вызовы, отправлять и получать текстовые сообщения и совместно использовать
подключение к Интернету по сотовой сети.
Обзор безопасности iOS | Сентябрь 2015 г.
51
Handoff
Если компьютер Mac и устройство iOS пользователя находятся близко друг
к другу, то пользователь может автоматически передавать незавершенные задачи
с одного устройства на другое с помощью Handoff. Handoff позволяет пользователю
переключаться между устройствами и мгновенно продолжать свою работу.
Если пользователь входит в iCloud на втором устройстве с поддержкой Handoff,
два устройства создают пару через отдельное соединение Bluetooth Low Energy
4.0 при помощи службы Apple Push Notification (APNs). Отдельные сообщения
шифруются так же, как в iMessage. После объединения в пару каждое из устройств
генерирует симметричный 256-битный ключ AES, который сохраняется в связке
ключей устройства. Этот ключ используется для шифрования и аутентификации
оповещений Bluetooth Low Energy, которые сообщают о текущем действии
устройства другим объединенным в пару устройствам iCloud, используя AES-256
в режиме GCM с защитой от повторной передачи перехваченных сообщений.
Когда устройство в первый раз получает оповещение от нового ключа, оно
устанавливает соединение стандарта Bluetooth Low Energy с вызывающим
устройством и обменивается с ним ключами шифрования оповещений. Для защиты
этого соединения используется шифрование Bluetooth Low Energy 4.0, а также
шифрование отдельных сообщений, которое похоже на шифрование сообщений
iMessage. В некоторых случаях эти сообщения передаются не через Bluetooth Low
Energy, а через службу Apple Push Notification. Для защиты и передачи информации
о выполняемых пользователем действиях используются такие же методы, как
в iMessage.
Переключение между нативными программами и веб-сайтами с помощью
Handoff
Благодаря Handoff нативные программы iOS могут возобновлять отображение
веб-страниц в доменах, которые на законных основаниях контролируются
разработчиком программы. Кроме того, нативные программы могут возобновлять
действия пользователя в веб-браузере.
Чтобы нативные программы не могли запросить возобновление веб-сайтов,
которые не контролируются разработчиком, программа должна
продемонстрировать наличие законного контроля над веб-доменами, которые
она хочет возобновить. Для доказательства контроля над доменом веб-сайта
используется такой же механизм, как для общего доступа к учетным данным
веб-сайтов. Подробнее см. «Доступ к паролям, сохраненным в Safari» в разделе
«Шифрование и защита данных». Прежде чем программе будет разрешено принять
действия пользователя через Handoff, система должна подтвердить, что программа
контролирует доменное имя. Источником передачи веб-страницы может быть любой браузер с интерфейсами
Handoff API. Когда пользователь просматривает веб-страницу, система передает
ее доменное имя с помощью зашифрованных байтов оповещения Handoff.
Расшифровать байты оповещения могут только другие устройства пользователя
(как описано в разделе выше).
Система принимающего устройства распознает, что установленная нативная
программа принимает информацию Handoff от переданного доменного имени,
и отображает значок этой нативной программы в меню Handoff. При запуске
нативная программа получает полный URL-адрес и заголовок веб-страницы.
Никакая другая информация из браузера не передается в нативную программу.
Обзор безопасности iOS | Сентябрь 2015 г.
52
При передаче информации в обратном направлении нативная программа может
указать резервный URL-адрес на тот случай, если на принимающем устройстве
не установлена та же нативная программа. В этом случае вместо программы
в меню Handoff отображается браузер по умолчанию (если этот браузер
поддерживает интерфейсы Handoff API). При вызове Handoff отображается этот
браузер и в него передается резервный URL-адрес, предоставленный исходной
программой. Резервный URL-адрес не обязательно должен принадлежать
доменным именам, которые контролируются разработчиком нативной программы.
Передача больших объемов данных с помощью Handoff
Помимо основной функции Handoff, некоторые программы могут использовать
API, которые поддерживают отправку больших объемов данных через технологию
прямого соединения Wi-Fi, разработанную компанией Apple (во многом похожую
на AirDrop). Например, программа «Почта» использует эти интерфейсы API для
передачи черновиков писем, которые могут включать большие вложения.
Когда программа задействует эту функцию, между двумя устройствами начинается
обмен данными, как при использовании Handoff (см. предыдущие разделы).
Однако после получения первоначальной информации по Bluetooth Low Energy
принимающее устройство устанавливает новое подключение через Wi-Fi.
Это подключение шифруется (с помощью TLS), для чего устройства обмениваются
сертификатами удостоверения iCloud. Удостоверение в сертификатах сверяется
с удостоверением пользователя. Вся дальнейшая информация пересылается
по этому зашифрованному подключению, пока передача не будет завершена.
Ретрансляция сотовых вызовов через iPhone
Если Mac, iPad или iPod подключены к той же сети Wi-Fi, что и iPhone, они могут
совершать и принимать телефонные вызовы через сотовое подключение iPhone.
Для этого необходимо, чтобы на устройствах был выполнен вход в iCloud
и FaceTime с одним и тем же Apple ID.
При поступлении входящего вызова все настроенные устройства получают
уведомление через службу Apple Push Notification (APNs), при этом для каждого
уведомления используется такое же сквозное шифрование, как в iMessage.
На экранах устройств, подключенных к одной сети, появляется уведомление
о входящем вызове. Когда пользователь отвечает на вызов, аудиопоток начинает
транслироваться с iPhone через безопасное прямое соединение между двумя
устройствами.
Исходящие вызовы также ретранслируются на iPhone через службу Apple Push
Notification, а аудиопоток аналогичным образом передается через безопасное
прямое соединение между устройствами.
Для отключения ретрансляции телефонных вызовов пользователям необходимо
отключить «Сотовые вызовы iPhone» в настройках FaceTime.
Переадресация сообщений через iPhone
Функция переадресации сообщений выполняет автоматическую пересылку SMS,
полученных на iPhone, на зарегистрированные устройства iPad, iPod touch или
Mac. На всех устройствах необходимо выполнить вход в iMessage под одним
и тем же Apple ID. При включении переадресации SMS необходимо подтвердить
регистрацию каждого устройства, введя случайный шестизначный цифровой код,
сгенерированный iPhone.
После завершения привязки устройств iPhone начинает шифровать
и переадресовать входящие SMS на каждое из устройств, используя методы,
описанные в разделе «iMessage» данного документа. Ответы пересылаются
обратно на iPhone аналогичным способом, после чего iPhone отправляет ответ
в виде SMS, используя механизм передачи SMS оператора. Включить и выключить
переадресацию сообщений можно в настройках программы «Сообщения».
Обзор безопасности iOS | Сентябрь 2015 г.
53
Instant Hotspot
Устройства iOS, поддерживающие Instant Hotspot, находят другие устройства,
которые вошли в ту же учетную запись iCloud, и устанавливают с ними соединение,
используя Bluetooth Low Energy. Совместимые компьютеры Mac с операционной
системой OS X Yosemite или новее используют эту же технологию для обнаружения
устройств iOS с поддержкой Instant Hotspot и установления соединения с этими
устройствами.
После того как пользователь вводит настройки Wi-Fi на устройстве iOS, устройство
начинает испускать сигнал Bluetooth Low Energy, содержащий идентификатор,
который был согласован всеми устройствами, использующими одну и ту же учетную
запись iCloud. Идентификатор генерируется из идентификатора связи с адресатом
(DSID), который привязан к учетной записи iCloud и периодически меняется. Если
в непосредственной близости от устройства оказываются другие устройства,
использующие эту же учетную запись iCloud и поддерживающие режим модема,
они распознают сигнал и отвечают на него, сигнализируя о своей доступности.
Если пользователь выбирает одно из доступных устройств для режима модема,
на это устройство отправляется запрос о включении функции «Режим модема».
Запрос передается по зашифрованному каналу Bluetooth Low Energy, а сами
запросы шифруются так же, как в iMessage. Устройство отвечает на запрос по тому
же каналу Bluetooth Low Energy, используя тот же способ шифрования отдельных
сообщений, и передает информацию о подключении к модему.
Предложения Spotlight
Поиск в Safari и поиск Spotlight теперь включают в себя предложения из Интернета,
программ, iTunes Store, App Store, расписаний киносеансов, находящихся рядом
мест и других источников.
Чтобы предложения были более актуальными для конкретного пользователя,
в поисковые запросы включается контекст и обратная информация поиска.
Вместе с поисковыми запросами компания Apple получает следующую информацию
о контексте: i) примерное местонахождение устройства; ii) тип устройства
(например, Mac, iPhone, iPad или iPod); iii) клиентская программа (Spotlight или
Safari); iv) язык по умолчанию и региональные настройки устройства; v) три
последние программы, запущенные на устройстве; vi) анонимный идентификатор
сеанса. Весь обмен информацией с сервером шифруется с помощью HTTPS.
Чтобы защитить конфиденциальность пользователя, функция «Предложения
Spotlight» никогда не отправляет точное местонахождение пользователя —
информация предварительно искажается в клиенте. Уровень искажения зависит
от расчетной плотности населения по месту нахождения устройства; например,
в сельской местности используется более сильное искажение, чем в центре города,
где пользователи обычно находятся ближе друг к другу. Кроме того, пользователи
могут отключить отправку любой информации о местонахождении в компанию
Apple, выключив службы геолокации для предположений Spotlight в Настройках.
При отключении служб геолокации компания Apple может определять
приблизительное местонахождение пользователя по IP-адресу клиента.
Обзор безопасности iOS | Сентябрь 2015 г.
54
Благодаря анонимным идентификаторам сеансов Apple может анализировать
зависимости между сериями запросов, отправленных в течение 15-минутного
периода. Например, если часто бывает так, что пользователь сначала ищет «кафе»,
а вскоре после этого — «номер телефона кафе», служба поиска Apple может
научиться сразу выдавать номера телефонов. В отличие от большинства поисковых
машин, служба поиска Apple не использует постоянный личный идентификатор
для привязки запросов к пользователю или устройству на протяжении всей
истории поиска; вместо этого устройства Apple используют временные анонимные
идентификаторы сеансов, которые существуют не более 15 минут, а затем
уничтожаются.
В качестве дополнительного контекста в запрос включается информация о трех
программах, которые были последними запущены на устройстве. Для защиты
конфиденциальности пользователя в этот список включаются только те программы,
которые находятся в белом списке популярных программ Apple и открывались
не позднее трех часов назад.
В компанию Apple также передается обратная информация поиска, включая
следующую информацию: i) время между действиями пользователя, такими
как нажатие клавиш и выбор результатов; ii) выбранный результат функции
«Предложения Spotlight», если он был выбран; iii) тип выбранного локального
результата (например, «закладка» или «контакт»). Как и в случае контекста поиска,
обратная информация не привязывается к конкретному лицу или устройству.
Журналы функции «Предложения Spotlight» с запросами, контекстом и обратной
информацией хранятся в компании Apple не более 18 месяцев. Сокращенные
версии журналов, которые включают только запрос, страну, язык, время
с точностью до часа и тип устройства, хранятся до двух лет. Журналы запросов
не содержат IP-адресов.
В некоторых случаях функция «Предложения Spotlight» может перенаправлять
запросы общих слов и фраз уполномоченному партнеру, а затем отображать
полученные от него результаты поиска. Уполномоченный партнер не хранит
эти запросы и не получает данные об обратной информации поиска. Партнеры
также не получают IP-адресов. Обмен информацией с партнером шифруется
с помощью HTTPS. В качестве контекста поиска компания Apple сообщает партнеру
местонахождение устройства с точностью до города, тип устройства и язык клиента,
которые чаще других встречаются в запросах пользователей.
Функцию «Предложения Spotlight» для Spotlight и Safari можно выключить
в Настройках. Если выключить эту функцию для Spotlight, программа Spotlight
превращается в локальный клиент для поиска данных только на устройстве,
который не передает информацию в Apple. Если выключить эту функцию для Safari,
поисковые запросы пользователя, контекст поиска и обратная информация поиска
не передаются в Apple.
Spotlight также включает механизмы, обеспечивающие возможность поиска
в локальном контенте на устройстве:
• API CoreSpotlight, позволяющий программам Apple и сторонних разработчиков
передавать функции Spotlight контент с возможностью индексации.
• API NSUserActivity, позволяющий программам Apple и сторонних разработчиков
передавать функции Spotlight информацию о страницах программ, которые
посещал пользователь.
Spotlight хранит на устройстве указатель информации, полученной этими двумя
способами, чтобы отображать результаты из этих данных в ответе на поисковый
запрос пользователя или автоматически при запуске поиска Spotlight. Кроме того,
на устройстве имеется API обобщенного поиска, доступный только программам
Apple, который позволяет функции Spotlight передавать поисковые запросы
пользователя программам для обработки и получения от них результатов.
Обзор безопасности iOS | Сентябрь 2015 г.
55
Средства управления устройствами
iOS предлагает гибкие политики и конфигурации безопасности, которые легко
применять и поддерживать. Благодаря этому организации могут защищать
корпоративную информацию и следить за тем, чтобы сотрудники соблюдали
корпоративные требования, даже если они используют свои собственные
устройства, например, в рамках программы использования личных устройств
сотрудников на работе (BYOD).
Организации могут использовать такие средства, как защита паролем, профили
конфигурации, удаленное стирание и решения MDM сторонних разработчиков,
для управления большой группой устройств и защиты корпоративных данных даже
в том случае, если сотрудники обращаются к этим данным со своих персональных
устройств iOS.
Защита паролем
По умолчанию пароль пользователя является цифровым. На устройствах с Touch ID
минимальная длина пароля составляет шесть цифр. На остальных устройствах —
четыре цифры. Пользователи могут задать более длинный буквенно-цифровой
пароль, выбрав вариант «Произвольный буквенно-цифровой код» в разделе
«Настройки» > «Пароль». Более длинные и сложные пароли труднее подобрать
или взломать, поэтому их рекомендуется использовать в корпоративной среде.
Для принудительного применения сложных паролей и других политик
администраторы могут воспользоваться MDM или Exchange ActiveSync,
а также проследить за тем, чтобы пользователи вручную установили профили
конфигурации. Доступны следующие политики паролей:
• разрешение простых паролей;
• требование буквенно-цифровых паролей;
• минимальная длина пароля;
• минимальное количество сложных символов;
• максимальный возраст пароля;
• история паролей;
• время автоблокировки;
• отсрочка блокировки устройства;
• максимальное количество неудачных попыток;
• Разрешение использовать Touch ID
Подробную информацию о каждой политике см. в Справочнике по ключам профиля
конфигурации на странице https://developer.apple.com/library/ios/featuredarticles/
iPhoneConfigurationProfileRef/.
Обзор безопасности iOS | Сентябрь 2015 г.
56
Модель создания пары iOS
Для управления доступом к устройству с главного компьютера в iOS используется
модель создания пары. Создание пары устанавливает доверительные отношения
между устройством и хостом, которые выражаются обменом открытыми ключами.
iOS использует этот знак доверия для разрешения дополнительных действий
с подключенным хостом, например синхронизации данных. В iOS 9 службы,
требующие создания пары, не могут быть запущены до тех пор, пока устройство
не будет разблокировано пользователем.
Для создания пары пользователь должен разблокировать устройство и принять
запрос на создание пары от хоста. После этого хост и устройство обмениваются
открытыми 2048-битными ключами RSA и сохраняют их. Затем хост получает
256-битный ключ для разблокировки хранилища ключей передачи, которое
расположено на устройстве (см. «Хранилища ключей передачи» в разделе
«Хранилища ключей»). Ключи, которыми обменялись хост и устройство,
используются для установления сеанса связи с использованием шифрования SSL.
Пока такой сеанс не установлен, устройство не пересылает защищенные данные
хосту и не запускает службы (синхронизация iTunes, пересылка файлов, разработка
Xcode и. т. д.). Устройство требует, чтобы этот зашифрованный сеанс использовался
для всех подключений хоста по Wi-Fi, поэтому сначала необходимо создать пару
через USB. Создание пары также предоставляет несколько диагностических
возможностей. В IOS 9 если запись создания пары не использовалась дольше
шести месяцев, срок ее действия истечет. Подробнее об этом можно узнать
на странице https://support.apple.com/ru-ru/HT6331.
Некоторые службы, включая com.apple.pcapd, могут работать только через
USB. Кроме того, для использования службы com.apple.file_relay на устройстве
должен быть установлен профиль конфигурации, подписанный Apple.
Пользователь может очистить список доверенных узлов, выбрав «Сбросить
настройки сети» или «Сбросить геонастройки». Подробнее об этом можно узнать
на странице https://support.apple.com/ru-ru/HT5868.
Принудительное применение конфигурации
Профиль конфигурации представляет собой файл XML, позволяющий
администратору передавать информацию о конфигурации на устройства iOS.
Пользователь не может изменить настройки, заданные установленным профилем
конфигурации. Если пользователь удаляет профиль конфигурации, все заданные
этим профилем настройки также удаляются. Таким образом администраторы могут
обеспечить обязательное применение настроек, привязав политики к возможности
доступа. Например, профиль конфигурации, который настраивает электронную
почту, может также задавать политику использования пароля устройства.
Пользователи не смогут получить доступ к электронной почте, если их пароли
не соответствуют требованиям администратора.
Обзор безопасности iOS | Сентябрь 2015 г.
57
Профиль конфигурации iOS содержит ряд настраиваемых параметров, включая
следующие:
• политики паролей;
• ограничения возможностей устройства (например, отключение камеры);
• настройки Wi-Fi;
• настройки VPN;
• настройки почтового сервера;
• настройки Exchange;
• настройки служб каталогов LDAP;
• настройки служб календарей CalDAV;
• веб-клипы;
• учетные данные и ключи;
• расширенные настройки сотовых сетей.
Профили конфигурации можно подписать и зашифровать, чтобы подтвердить
их источник, обеспечить их целостность и защитить их содержимое.
Для шифрования профилей используется синтаксис криптографического
сообщения RFC 3852 с поддержкой 3DES и AES 128.
Профили конфигурации можно заблокировать, чтобы предотвратить их удаление
с устройства, или же можно разрешить удаление только при условии ввода пароля.
Поскольку многие корпоративные пользователи являются владельцами своих
устройств iOS, они могут удалить профили конфигурации, которые привязывают
устройство к серверу MDM, но при этом также будут удалены все управляемые
настройки, данные и программы.
Пользователи могут устанавливать профили конфигурации напрямую
на устройства с помощью Apple Configurator. Профили также можно загружать
через Safari, отправлять по электронной почте или по беспроводной сети,
используя сервер MDM.
Управление мобильными устройствами (MDM)
iOS поддерживает MDM, благодаря чему компании могут выполнять безопасную
настройку и широко использовать iPhone и iPad во всех своих подразделениях.
Работа функций MDM основана на существующих технологиях iOS, таких как
профили конфигурации, регистрация по беспроводной сети и служба Apple Push
Notification (APNs). Например, APNs используется для вывода устройства из режима
сна, чтобы оно могло напрямую связаться с сервером MDM через безопасное
соединение. Конфиденциальная или корпоративная информация через APNs
не передается.
Используя MDM, отделы ИТ могут безопасно внедрять устройства в корпоративную
среду, устанавливать и обновлять настройки по беспроводной сети, следить
за соответствием корпоративным политикам и даже удаленно стирать данные
или блокировать управляемые устройства. Подробнее об управлении мобильными
устройствами можно узнать на странице www.apple.com/iphone/business/it/
management.html.
Обзор безопасности iOS | Сентябрь 2015 г.
58
Программа регистрации устройств
Программа регистрации устройств (DEP) предоставляет быстрый и эффективный
способ развертывания устройств iOS, которые организация купила
непосредственно в компании Apple, у авторизованных реселлеров Apple или
у операторов. Регистрацию устройств в MDM можно выполнить автоматически —
организации не нужно будет прикасаться к устройствам или готовить их перед
передачей пользователям. Также можно упростить процесс настройки для
пользователей, убрав из Ассистента настройки определенные шаги, чтобы
помочь пользователям быстро приступить к работе. Администраторы могут
указать, разрешено ли пользователям удаление профиля MDM с устройства,
и гарантировать применение ограничений с самого начала использования
устройства. Например, администраторы могут заказать устройства в Apple и задать
все настройки управления, после чего устройства будут доставлены пользователям
на дом. После распаковки и активации устройство регистрируется в системе MDM
организации — и все управляемые настройки, программы и книги добавляются
автоматически, так что пользователь может сразу начать работу.
Процесс очень прост. После регистрации в программе администратору необходимо
войти в систему веб-сайта программы, связать программу со своим сервером
MDM и «заявить» устройства iOS, купленные в компании Apple. Затем можно
назначить устройства пользователям через MDM. После назначения пользователя
выполняется автоматическая установка конфигурации, ограничений и параметров
управления, заданных в MDM. Подробнее об этом можно узнать на странице
https://deploy.apple.com.
Примечание. Программа регистрации устройств доступна не во всех странах
и регионах.
Apple Configurator
Apple Configurator для OS X является еще одним средством (помимо MDM) для
удобного развертывания устройств iOS. С помощью Apple Configurator можно
быстро настроить большое количество устройств, установив на них нужные
программы, записав нужные данные и задав необходимые параметры
и ограничения.
Контроль
Во время настройки организация может задать конфигурацию контролируемого
устройства. Контроль указывает, что устройством владеет компания, что
предоставляет дополнительные возможности управления его конфигурацией
и ограничениями. Во время настройки устройства можно контролировать
с помощью программы регистрации устройств или Apple Configurator.
Дополнительную информацию о настройке и управлении устройствами
с помощью MDM или Apple Configurator можно найти в Справочном руководстве
по развертыванию iOS на странице https://help.apple.com/deployment/ios.
Сведения о дополнительных возможностях управления контролируемыми
устройствами приведены в справочнике по профилям конфигурации:
https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/
iPhoneConfigurationProfileRef.pdf.
Обзор безопасности iOS | Сентябрь 2015 г.
59
Ограничения устройства
Администраторы могут ограничить возможности устройства, установив профиль
конфигурации. Вот некоторые из доступных ограничений:
• Разрешение устанавливать программы
• Разрешение доверять корпоративным программам
• Разрешение использовать камеру
• Разрешение использовать FaceTime
• Разрешение делать снимки экрана
• Разрешение голосового набора при заблокированном устройстве
• Разрешение автоматической синхронизации в роуминге
• Разрешение делать покупки из программ
• Разрешение синхронизировать недавнюю почту
• Требование пароля для магазина при любой покупке
• Разрешение использовать Siri при заблокированном устройстве
• Разрешение использовать iTunes Store
• Разрешение документов из управляемых источников в неуправляемых местах
назначения
• Разрешение документов из неуправляемых источников в управляемых местах
назначения
• Разрешение синхронизации Связки ключей iCloud
• Разрешение обновлять базу данных доверия сертификатов по беспроводной сети
• Разрешение показывать уведомления на экране блокировки
• Обязательное использование паролей создания пары для соединений AirPlay
• Разрешение Spotlight показывать пользовательские материалы из Интернета
• Разрешение предложений Spotlight в Spotlight
• Разрешение использовать Handoff
• Обработка AirDrop как неуправляемого места назначения
• Разрешение резервного копирования корпоративных книг
• Разрешение синхронизации заметок и закладок в корпоративных книгах на все
устройства пользователей
• Разрешение использовать Safari
• Разрешение автозаполнения в Safari
• Обязательная выдача предупреждения о фальшивом сайте
• Включение JavaScript
• Ограничение трекинга рекламы в Safari
• Блокирование всплывающих окон
• Принятие файлов cookie
• Разрешение резервного копирования iCloud
• Разрешение синхронизации документов и данных «ключ-значение» iCloud
• Разрешение Общего доступа к фото iCloud
• Разрешение отправлять диагностические данные в Apple
• Разрешение принимать непроверенные сертификаты TLS
• Обязательное шифрование резервных копий
• Разрешение использовать Touch ID
• Разрешение доступа к Пункту управления с экрана блокировки
• Разрешение доступа к виду «Сегодня» с экрана блокировки
• Требование распознавания запястья для Apple Watch
Обзор безопасности iOS | Сентябрь 2015 г.
60
Ограничения только для сопровождаемых устройств
• Разрешение использовать iMessage
• Разрешение удалять программы
• Разрешение вручную устанавливать профили конфигурации
• Глобальные сетевые прокси для HTTP
• Разрешение устанавливать пару с компьютерами для синхронизации материалов
• Ограничение подключений AirPlay с «белым списком» и дополнительные пароли
подключения
• Разрешение использовать AirDrop
• Разрешение изменять функцию «Найти друзей»
• Разрешение автономного режима одной программы для конкретных
управляемых программ
• Разрешение изменять учетные записи
• Разрешение изменять использование сотовых данных
• Разрешение создавать пару с хостом (iTunes)
• Разрешение блокировки активации
• Предотвращение стирания всего контента и настроек
• Предотвращение включения ограничений
• Фильтр стороннего контента
• Режим одной программы
• VPN всегда включена
• Разрешение изменять пароль
• Разрешение создавать пару с Apple Watch
• Разрешение автоматически загружать программы
• Разрешение использовать предиктивный ввод, автоматическое исправление,
проверку орфографии и сочетания клавиш
Подробнее об ограничениях рассказано в документе https://developer.apple.com/
library/ios/featuredarticles/iPhoneConfigurationProfileRef/
iPhoneConfigurationProfileRef.pdf
Удаленное стирание
Администратор или пользователь может выполнить удаленное стирание данных
с устройств iOS. Мгновенное удаленное стирание реализуется путем надежного
удаления ключа шифрования блочного хранения из стираемого накопителя,
в результате чего все данные становятся недоступными. Удаленное стирание
может быть запущено MDM, Exchange или iCloud.
Когда MDM или iCloud отдают команду удаленного стирания, устройство
отправляет подтверждение и выполняет стирание. При запуске удаленного
стирания через Exchange устройство сначала регистрируется на сервере Exchange,
а затем выполняет стирание.
Для стирания данных со своего устройства пользователи могут использовать
программу «Настройки». И, как уже упоминалось, устройства можно настроить
на автоматическое стирание после ряда неудачных попыток ввода пароля.
Обзор безопасности iOS | Сентябрь 2015 г.
61
Функция «Найти iPhone» и блокировка активации
Если устройство потеряно или украдено, важно отключить его и стереть с него
данные. Если на устройстве с iOS 7 или новее включена функция «Найти iPhone»,
для повторной активации устройства потребуется ввести учетные данные Apple ID
владельца. Организациям рекомендуется либо контролировать свои устройства,
либо отключить использование функции «Найти iPhone» с помощью политики,
чтобы эта функция не помешала организации передать устройство другому лицу.
Если пользователь включает функцию «Найти iPhone» в iOS 7.1 или более поздней
версии, совместимое решение MDM может включить блокировку активации
на контролируемых устройствах. Для управления блокировкой активации для
функции «Найти iPhone» администраторы MDM могут контролировать устройства
с помощью Apple Configurator или Программы регистрации устройств. После
этого при включении блокировки активации решение MDM может сохранять
обходной код, а затем использовать этот код для автоматического снятия
блокировки активации, если устройство необходимо очистить и назначить
другому пользователю. Подробную информацию можно найти в документации
используемого решения MDM.
Внимание! По умолчанию блокировка активации на контролируемых устройствах
остается отключена, даже если пользователь включает функцию «Найти iPhone».
Однако сервер MDM может извлечь обходной код и разрешить блокировку
активации на устройстве. Если сервер MDM включает блокировку активации, когда
функция «Найти iPhone» включена, блокировка включается незамедлительно.
Если функция «Найти iPhone» выключена, когда сервер MDM включает блокировку
активации, то блокировка включится, как только пользователь активирует функцию
«Найти iPhone».
Обзор безопасности iOS | Сентябрь 2015 г.
62
Настройки конфиденциальности
Компания Apple отличается серьезным подходом к конфиденциальности
покупателей и предлагает множество встроенных настроек и параметров,
используя которые пользователи iOS могут указать, как и когда программы могут
использовать их информацию, а также определить круг используемой информации.
Службы геолокации
Для определения приблизительной геопозиции пользователя службы геолокации
используют GPS, Bluetooth, а также краудсорсинговую базу данных точек доступа
Wi‑Fi и вышек сотовой связи. Можно полностью отключить службы геолокации,
выключив один переключатель в Настройках, или разрешить отдельным
программам использовать эти службы. Можно разрешить программам запрашивать
информацию о местоположении только во время использования программы
пользователем или в любое время. При желании пользователи могут запретить
такой доступ и в любое время изменить свой выбор в Настройках. В Настройках
также можно выбрать вариант доступа — не разрешать никогда, разрешать
во время использования или разрешать всегда — в зависимости от запрошенного
программой варианта использования геопозиции. Кроме того, если программа,
которой разрешено использовать данные о местоположении в любой момент
времени, пытается использовать это разрешение в фоновом режиме, пользователь
получает напоминание о своем разрешении и может изменить уровень доступа
программы.
Пользователи получают детальный контроль над тем, как системные службы
используют информацию о местонахождении. Например, пользователи могут
исключить информацию о местонахождении из данных, собираемых службами
диагностики и анализа использования Apple, которые предназначены для
усовершенствования iOS, работы Siri, использования геопозиции для предложений
Spotlight, оценки местной дорожной обстановки и использования часто
посещаемых мест для расчетов приблизительного времени в пути.
Доступ к персональным данным
iOS не позволяет программам получать доступ к персональной информации
пользователя без его разрешения. Кроме того, пользователь может открыть
Настройки и посмотреть, какие программы имеют доступ к определенной
информации, а также предоставить или отменить доступ на будущее.
Пользователь может настроить доступ к следующим элементам:
• Контакты
• Микрофон
• Календари
• Камера
• Напоминания
• HomeKit
• Фото
• HealthKit
• Двигательная активность на iPhone 5s или более
поздней версии
• Общий доступ Bluetooth
• Учетные записи социальных сетей,
таких как Twitter и Facebook
Обзор безопасности iOS | Сентябрь 2015 г.
63
Если пользователь входит в iCloud, программы по умолчанию получают доступ
к iCloud Drive. Пользователи могут управлять доступом отдельных программ
в разделе «iCloud» в Настройках. Кроме того, iOS позволяет настроить ограничения,
чтобы не допустить перемещения данных между программами и учетными
записями, которые установлены MDM, и теми, которые установлены пользователем.
Политика конфиденциальности
Политика конфиденциальности Apple размещена в Интернете на странице
https://www.apple.com/ru/legal/privacy.
Обзор безопасности iOS | Сентябрь 2015 г.
64
Заключение
Всегда на страже безопасности
Компания Apple делает все возможное для защиты клиентов, предлагая
передовые технологии обеспечения конфиденциальности и безопасности для
защиты персональной информации, а также комплексные методы для защиты
корпоративных данных в корпоративной среде.
Безопасность заложена в основу iOS. В iOS предприятия найдут все, что
им нужно — от платформы и сети до программ. Вместе эти компоненты
обеспечивают непревзойденную безопасность iOS без ущерба для удобства работы
пользователей.
Apple использует согласованную, интегрированную инфраструктуру безопасности
в рамках iOS и всей цифровой среды программ для iOS. Аппаратное шифрование
хранилища позволяет выполнять удаленное стирание, если устройство потеряно,
а также полностью стирать всю корпоративную и личную информацию при
продаже или передаче устройства другому владельцу. Диагностическая
информация собирается анонимно.
При разработке программ для iOS компания Apple учитывала самые последние
требования к безопасности. Safari предлагает безопасный просмотр веб-страниц
с поддержкой протокола статуса онлайнового сертификата (OCSP), сертификатов
EV и предупреждений о проверке сертификатов. Почта использует сертификаты
для аутентификации и шифрования почты. Благодаря поддержке сертификатов
S/MIME, которые настраиваются на уровне сообщений, пользователи S/MIME
могут настроить автоматическое подписание и шифрование всех сообщений или
же выборочно настраивать защиту отдельных писем. iMessage и FaceTime также
обеспечивают шифрование от клиента до клиента.
Для программ сторонних разработчиков используется сочетание обязательной
подписи кода, «песочницы» и прав. Пользователи получают надежную защиту
от вирусов, вредоносных программ и других уязвимостей, которые ставят
под угрозу безопасность других платформ. Чтобы дополнительно оградить
пользователей от этих рисков, все программы для iOS проходят проверку,
прежде чем появиться в App Store.
Чтобы максимально эффективно использовать обширные функции безопасности,
встроенные в iOS, компаниям рекомендуется проанализировать свои политики
в области ИТ и безопасности и убедиться, что они задействуют все возможности
многоуровневой системы безопасности, предлагаемой этой платформой.
В Apple есть специальная команда по безопасности, которая отвечает
за поддержку всех продуктов Apple. Эта команда проводит аудит безопасности
и тестирование продуктов, находящихся в стадии разработки, а также выпущенных
продуктов. Команда Apple предоставляет необходимые инструменты, проводит
обучение и активно отслеживает сообщения о новых проблемах и угрозах
безопасности. Компания Apple является членом форума FIRST, который объединяет
группы по безопасности и реагированию на инциденты. Информацию о том, как
сообщить о проблемах в Apple и подписаться на уведомления о безопасности,
Вы найдете на странице apple.com/ru/support/security.
Обзор безопасности iOS | Сентябрь 2015 г.
65
Глоссарий
Случайное расположение в адресном
пространстве (ASLR)
Технология, используемая iOS для того, чтобы значительно усложнить использование
программных ошибок для злоумышленников. Поскольку предсказать адреса памяти
и смещения невозможно, вредоносный код не может задать для них конкретные значения.
В iOS 5 и более поздних версиях расположение всех системных программ и библиотек
задается случайным образом. Если программы сторонних разработчиков скомпилированы
как переместимые исполнимые файлы, их адреса также задаются случайным образом.
Служба Apple Push Notification (APNs)
Доступная по всему миру служба Apple, которая обеспечивает доставку push-уведомлений
на устройства iOS.
Boot ROM
Самый первый код, исполняемый процессором устройства при первой загрузке. Этот код
является неотъемлемой частью процессора и не может быть изменен компанией Apple или
злоумышленником.
Защита данных
Механизм защиты файлов и связки ключей для iOS. Это понятие также относится к API,
используемым программами для защиты файлов и элементов связки ключей.
Обновление прошивки устройства (DFU)
Режим, в котором код Boot ROM устройства ожидает восстановления через USB. В режиме
DFU экран остается черным, однако при подключении к компьютеру с запущенной программой iTunes отображается следующее сообщение: «iTunes обнаружила iPad в режиме
восстановления. Необходимо восстановить этот iPad перед использованием с iTunes».
ECID
Уникальный 64-битный идентификатор процессора, установленного в устройстве iOS.
Используется как часть процедуры персонализации и не считается секретным.
Стираемый накопитель
Выделенная область в хранилище NAND, используемая для хранения криптографических
ключей и поддерживающая прямую адресацию и безопасное стирание. Стираемый
накопитель не обеспечивает защиту, если злоумышленник физически завладевает
устройством, однако хранящиеся в нем ключи могут быть использованы как часть
иерархии ключей для обеспечения быстрого стирания и повышения безопасности.
Ключ файловой системы
Ключ, используемый для шифрования метаданных каждого файла, включая его ключ
класса. Ключ файловой системы хранится в стираемом накопителе для обеспечения
быстрого стирания в ущерб конфиденциальности.
Идентификатор группы (GID)
Похож на UID, но совпадает для всех процессоров одного класса.
Аппаратный модуль системы
безопасности (HSM)
Специализированный, устойчивый к взлому компьютер, который защищает цифровые
ключи и управляет ими.
iBoot
Код, загружаемый LLB и, в свою очередь, загружающий XNU как часть безопасной
последовательности загрузки.
Служба идентификации (IDS)
Каталог Apple, в котором хранятся открытые ключи iMessage, адреса APNs, а также номера
телефонов и адреса электронной почты, используемые для поиска ключей и адресов
устройств.
Интегральная микросхема (IC)
Также известна как микрочип.
Joint Test Action Group (JTAG)
Стандартное средство отладки оборудования, используемое программистами
и разработчиками микросхем.
Обзор безопасности iOS | Сентябрь 2015 г.
66
Хранилище ключей
Структура данных, используемая для хранения коллекции ключей класса. Все типы (система,
резервное копирование, передача и резервное копирование iCloud) имеют одинаковый
формат:
• Заголовок, содержащий следующие элементы:
– версия (имеет значение 3 с iOS 5);
– тип (система, резервное копирование, передача или резервное копирование iCloud);
– UUID хранилища ключей;
– HMAC, если хранилище ключей подписано;
– способ защиты ключей класса: привязка к UID или PBKDF2, а также случайное значение
(«соль») и число повторений.
• Список ключей класса:
– UUID ключа;
– класс (класс защиты данных файла или связки ключей);
– тип защиты (ключ на основе только UID; ключ на основе UID и пароля);
– защищенный ключ класса;
– открытый ключ для асимметричных классов.
Связка ключей
Инфраструктура и набор API, используемые iOS и программами сторонних разработчиков
для хранения и извлечения паролей, ключей и других конфиденциальных учетных данных.
Защита ключа
Шифрование одного ключа с помощью другого ключа. iOS использует защиту ключей
с помощью шифрования NIST AES по алгоритму RFC 3394.
Низкоуровневый загрузчик (LLB)
Код, загружаемый Boot ROM и, в свою очередь, загружающий iBoot как часть безопасной
последовательности загрузки.
Ключ файла
256-битный ключ AES, используемый для шифрования файла в файловой системе.
Ключ файла защищается с помощью ключа класса и хранится в метаданных файла.
Профиль обеспечения
Файл plist, который подписан компанией Apple и содержит набор субъектов и прав,
позволяющих устанавливать и тестировать программы на устройстве iOS. Профиль
обеспечения разработки содержит список устройств, выбранных разработчиком для
специализированного распространения, а профиль обеспечения распространения
содержит идентификатор корпоративной программы.
Угловое представление дактилоскопического узора
Математическое представление направления и толщины линий дактилоскопического узора,
полученное из части отпечатка пальца.
Смарт-карта
Интегрированная, встроенная цепь, которая обеспечивает безопасную идентификацию,
аутентификацию и хранение данных.
Система на кристалле (SoC)
Интегральная микросхема (IC), которая объединяет несколько компонентов на одном
кристалле. Secure Enclave — это SoC с центральным процессором Apple A7 или более
поздней версии.
Привязка
Процесс превращения пароля пользователя в криптографический ключ и его усиления
с помощью UID устройства. В результате атака методом перебора должна обязательно
выполняться на конкретном устройстве, что ограничивает скорость перебора
и не позволяет выполнять его параллельно. В качестве алгоритма привязки используется
PBKDF2: в качестве псевдослучайной функции на каждой итерации используется AES,
согласованный с UID устройства.
Универсальный идентификатор ресурса
(URI)
Символьная строка, которая идентифицирует веб-ресурс.
Уникальный идентификатор (UID)
256-битный ключ AES, вшитый в процессор на этапе производства. Этот ключ не может
быть считан прошивкой или программой и используется только аппаратным AES-модулем
процессора. Для получения фактического ключа злоумышленнику необходимо провести
крайне сложную и дорогостоящую физическую атаку на микросхему процессора. UID
не связан ни с каким другим идентификатором на устройстве, включая UDID.
XNU
Ядро, лежащее в центре операционных систем iOS и OS X. Это ядро считается доверенным
и обеспечивает применение специальных средств безопасности, таких как подпись кода,
«песочница», проверка прав и ASLR.
Обзор безопасности iOS | Сентябрь 2015 г.
67
История правок документа
Дата
Сводка
Сентябрь 2015 г.
Обновлено для iOS 9
•Блокировка активации Apple Watch
•Политики паролей
•Поддержка API Touch ID
•Для защиты данных процессор A8 использует AES-XTS
•Хранилища ключей для обновления программного обеспечения
без участия пользователя
•Обновления сертификации
•Модель доверия для корпоративных программ
•Защита данных для закладок Safari
•App Transport Security
•Спецификации VPN
•Удаленный доступ к iCloud для HomeKit
•Скидочные карты в Apple Pay
•Программа эмитента карты в Apple Pay
•Индексирование содержимого устройства для поиска Spotlight
•Модель создания пары iOS
•Apple Configurator
•Ограничения
•Подробнее о содержимом iOS 9, относящемся к обеспечению
безопасности, можно узнать в статье по адресу:
support.apple.com/ru-ru/HT205212
© 2015 Apple Inc. Все права защищены. Apple, логотип Apple, AirDrop, AirPlay, Apple TV, Apple Watch, Bonjour, FaceTime,
iBooks, iMessage, iPad, iPhone, iPod, iPod touch, iTunes, Keychain, Mac, OS X, Safari, Siri, Spotlight и Xcode являются товарными
знаками Apple Inc., зарегистрированными в США и других странах. Apple Pay, CarPlay Lightning и Touch ID являются
товарными знаками Apple Inc. iCloud и iTunes Store являются знаками обслуживания Apple Inc., зарегистрированными
в США и других странах. App Store и iBooks Store являются знаками обслуживания Apple Inc. IOS является товарным
знаком или зарегистрированным товарным знаком Cisco в США и других странах и используется по лицензии. Словесный
товарный знак и логотипы Bluetooth® являются зарегистрированными торговыми знаками Bluetooth SIG, Inc. и используются
компанией Apple по лицензии. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.
Другие названия продуктов и компаний, упомянутые в этом документе, могут являться товарными знаками соответствующих
компаний. Характеристики продуктов могут быть изменены без уведомления. Сентябрь 2015 г.
Обзор безопасности iOS | Сентябрь 2015 г.
68