Что альтернатива использованию вместо CommonCrypto на iphone?

Question

Подготовка к отправке моего приложения в магазин Apple Itunes и озадачен вопросом во время процесса подачи: «Законы об экспорте требуют, чтобы продукты, содержащие шифрование, были должным образом разрешены для экспорта ... Использует ли ваш продукт шифрование?»

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

Answer 1

Ваше использование «шифрования» не подлежит экспортным правилам США, потому что это не для «информационной безопасности» (я думаю, что вы отвечаете «да, да, да, нет» или так, ICBW, или они могли бы изменить заказ). По сути, если это не помешает NSA шпионить за вами, они с удовольствием позволят вам использовать его.

Однако шифрование традиционно обеспечивает конфиденциальность, а не целостность сообщения. Если вы хотите, чтобы пользователь не изменял файл настроек (например, редактируя резервную копию iPhone), просто сохраните его с помощью MAC. То есть

1. Сгенерируйте ключ MAC (вытащите некоторые байты из/dev/random).
2. Вычислить MAC файла при сохранении его (см Objective-C sample code for HMAC-SHA1, обратите внимание, что принятый ответ на самом деле HMAC-SHA-256)
3. Append МАС до конца файла (или установить его в качестве атрибута файла , или вставьте его в другой файл).
4. При чтении вычислите MAC-адрес файла и убедитесь, что он сохранен. Если он добавлен к файлу, вам нужно будет удалить последние несколько байтов (например, [NSData dataWithContentsOfFile:path], затем -subdataWithRange: два раза, чтобы получить «сообщение» и «MAC», затем проверьте MAC и проанализируйте «сообщение», если проверка завершена.

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

Если вы создаете файл на компьютере, которым вы управляете (например, это файл, загруженный с сервера), тогда подпишите его. Технически валидация подписи RSA эквивалентна шифрованию, но я не думаю, что это считается как шифрование для экспорта целей (если это так, то для целей «аутентификации» и все еще не учитывается). Подтверждение подписи DSA не является шифрованием (я думаю, математика позади этого прошла через мою голову), и также должно быть хорошо.