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

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

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


ios app-store-connect
person PrimeSeventyThree    schedule 24.11.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

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

person tc.    schedule 24.11.2010
comment
спасибо за пояснение и идею по защите файлов. это именно то, что я искал. - person PrimeSeventyThree; 24.11.2010