Как безопасно хранить данные на iOS, когда требуется доступ в фоновом режиме?

Я работаю над мобильным приложением для iOS, которое должно безопасно хранить данные и иметь возможность загружать данные с устройства Bluetooth в фоновом режиме.

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

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

Подытожу мои опасения:

  1. Можно ли обеспечить хорошую безопасность в фоновом режиме?
  2. Каков наилучший подход?
  3. kSecAttrAccessibleAfterFirstUnlock — означает ли это, что мои данные не в безопасности, когда пользователь разблокирует устройство после перезагрузки?
  4. Что делать, если у пользователя нет пароля? Безопасны данные или нет?

Заранее благодарю за любую помощь в этой теме.


person Wojciech Kulik    schedule 08.06.2018    source источник
comment
Вы должны иметь возможность использовать NSFileProtectionCompleteUnlessOpen Тогда вам не нужно беспокоиться о связке ключей   -  person Paulw11    schedule 08.06.2018
comment
@ Paulw11, к сожалению, это не решает проблему полностью, потому что приложение может быть завершено (поэтому файл будет закрыт), но iOS может запускать приложение в фоновом режиме, когда устройство Bluetooth становится доступным. Так что в этом случае мой файл будет недоступен. Также еще остается вопрос - как меняется безопасность при использовании разных атрибутов? Видно ли изменение только с точки зрения приложения или оно делает файл уязвимым для атак?   -  person Wojciech Kulik    schedule 08.06.2018
comment
Вам нужно будет открыть и записать в новый файл, а затем объединить эти файлы, когда приложение находится на переднем плане.   -  person Paulw11    schedule 08.06.2018
comment
В качестве альтернативы, NSFileProtectionCompleteUntilFirstUserAuthentication может быть достаточно для ваших нужд; особенно с новой защитой USB в iOS 12.   -  person Paulw11    schedule 08.06.2018
comment
Я также думал об объединении файлов, но я не уверен, что это лучший доступный подход. Однако в сочетании с NSFileProtectionCompleteUnlessOpen кажется разумным. Но мне интересно, действительно ли это необходимо, не является ли NSFileProtectionCompleteUntilFirstUserAuthentication безопасным, если да, то для чего этот атрибут?   -  person Wojciech Kulik    schedule 08.06.2018
comment
CompleteUntilFirstUserAuthentication означает, что файлы расшифровываются после первого ввода пользователем кода доступа после включения питания. Вам необходимо определить, представляет ли это для вас риск или нет; iOS 12 улучшает безопасность USB, поэтому кому-то сложнее подключить компьютер и загрузить расшифрованные файлы.   -  person Paulw11    schedule 08.06.2018


Ответы (1)


Мне удалось провести дополнительные исследования, и я решил поделиться своими выводами, основанными на документе 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