Мне удалось провести дополнительные исследования, и я решил поделиться своими выводами, основанными на документе Apple Безопасность iOS для iOS. 11а>.
Все нижеизложенное основано на знаниях, полученных из документа, и моей личной интерпретации. Поэтому, прежде чем применять это к вашему решению, внимательно прочитайте документ.
Файлы всегда зашифрованы на флэш-памяти (локальное хранилище)
Во-первых, насколько я понял из прочтения документа, файлы на локальном хранилище никогда не расшифровываются (даже без какой-либо дополнительной защиты).
Если файлу не присвоен класс защиты данных, он все равно хранится в зашифрованном виде (как и все данные на устройстве iOS).
Однако, включив Data Protection, мы получаем еще один уровень защиты, который генерирует ключ шифрования для защищенного файла. Но все же независимо от того, какой класс защиты мы выберем, файл все время будет оставаться зашифрованным в локальном хранилище.
Как это работает, что мы получаем расшифрованные данные в приложении?
Каждое устройство iOS имеет специальный механизм шифрования AES-256, встроенный в путь прямого доступа к памяти между флэш-памятью и основной системной памятью, что делает шифрование файлов очень эффективным.
Когда файл открывается, его метаданные расшифровываются с помощью ключа файловой системы, раскрывая обернутый ключ для каждого файла и обозначение того, какой класс его защищает. Файловый (или экстентный) ключ распаковывается с помощью ключа класса, а затем передается аппаратному механизму AES, который расшифровывает файл по мере его чтения из флэш-памяти. Вся обработка ключей обернутых файлов происходит в Secure Enclave; ключ файла никогда не передается процессору приложения напрямую.
Таким образом, вся расшифровка происходит «на лету», а файлы по-прежнему защищены во флэш-памяти.
а>
NSFileProtectionCompleteUntilFirstUserAuthentication
Я не буду вдаваться в подробности по каждому классу защиты, однако хотел бы пояснить этот. Как я упоминал выше, файлы защищены все время, так что же произойдет, если мы используем класс NSFileProtectionCompleteUntilFirstUserAuthentication? Ответ здесь:
Этот класс ведет себя так же, как Полная защита, за исключением того, что расшифрованный ключ класса не удаляется из памяти при блокировке устройства.
Только наше приложение может получить доступ к файлу, но работу здесь выполняет Crypto Engine, который имеет доступ к нашему ключу файла в памяти, даже если устройство заблокировано и расшифровывает данные из флэш-памяти в системную память.
а>
Аппаратная безопасность
Стоит отметить, что аппаратное обеспечение также защищено, и даже если вы перенесете флешку на другое устройство, получить ее данные будет невозможно.
UID позволяет криптографически привязывать данные к конкретному устройству. Например, иерархия ключей, защищающая файловую систему, включает UID, поэтому, если микросхемы памяти физически перемещаются с одного устройства на другое, файлы становятся недоступными. UID не связан ни с каким другим идентификатором на устройстве.
Проблемы с джейлбрейком
Сохраняются ли данные в безопасности после побега из тюрьмы?
К счастью, механизм защиты данных использует пароль для расшифровки данных, поэтому данные останутся зашифрованными даже после взлома вашего устройства, если хакер не взломает ваш пароль.
Фоновый режим
Для приложений, использующих фоновый режим, должно быть достаточно NSFileProtectionCompleteUntilFirstUserAuthentication. Apple упоминает это в разделе, связанном с доступом к цепочке ключей (что очень похоже):
Приложения, использующие службы фонового обновления, могут использовать kSecAttrAccessibleAfterFirstUnlock для элементов связки ключей, к которым необходимо получить доступ во время фоновых обновлений.
person
Wojciech Kulik
schedule
09.06.2018
NSFileProtectionCompleteUnlessOpen
Тогда вам не нужно беспокоиться о связке ключей - person Paulw11   schedule 08.06.2018NSFileProtectionCompleteUntilFirstUserAuthentication
может быть достаточно для ваших нужд; особенно с новой защитой USB в iOS 12. - person Paulw11   schedule 08.06.2018