Когда мы говорим о защите приложения iOS, мы часто забываем защищать самую критическую конфиденциальную информацию, такую как секрет, ключ, токен, encryptionKey. Эта информация хранится в двоичном формате iOS. Таким образом, ни один из ваших протоколов безопасности на стороне сервера не поможет вам.
Есть много предположений о том, что мы не должны хранить такую информацию в приложении, а хранить на сервере и получать ее через SSL-защищенный веб-сервис. Но это невозможно для всех приложений. Напр. если мое приложение не нуждается в веб-сервисе вообще.
В iOS-приложении у нас есть следующая опция для хранения информации.
Просьба отправить какое-нибудь большое решение этой проблемы.
Если вы не хотите использовать собственный бэкэнд, используйте Apple. Вы можете настроить On Demand Resources и сохранить файл данных с вашим ключом, токеном, любым секретом на сервере Apple. После первой загрузки вы можете записать эти данные в Keychain, который достаточно безопасен. Я предполагаю, что сеть между iOS и сервером Apple также достаточно безопасна.
1) Требуется подключение к Интернету
1.1) Push-уведомления Отличным способом обеспечения безопасного обмена данными может быть использование (беззвучный) push-сервисов от Apple, которые используют apns и отправляют данные через https - подробнее Подробнее 3.1
1.2) Более или менее аналогичный подход также используется при распространении новых пользовательских сертификатов на уже развернутые приложения, если переустановка приложения не имеет возможности, и приложение в любом случае требует рабочего интернет-соединения.
Даунсайд: требуется рабочее сетевое подключение и в основном информация поступает в приложение, когда он уже выполняется = > кажется, не подходит для вашего дела. (см. шаг 4)
2) Статические данные (поскольку обмен не будет осуществляться без сетевого подключения/партнера связи)
Шифрование данных с закрытым ключом, предоставляемым в самом пакете. Является ли это теперь строкой или хешем, который может быть изменен с помощью функций, которые вы получили в своем приложении. С iOS9 довольно сложно декомпилировать приложения iOS, и в основном вы будете в основном просматривать предоставленные заголовочные файлы. Поэтому, если у вас есть такая функция, строка, хэш-значение или что-то еще, убедитесь, что вы получили его в своем .m файле!
Но опять же: если информация не является устройством или пользователем, а просто секрет вашей собственной микро-среды, действующий на всех устройствах, вам необходимо предоставить зашифрованные данные и метод дешифрования в том же комплекте, если есть нет процесса обновления/обмена информацией или чего-то еще, вы можете подумать.
Хорошо для шифрования: iOS System.Security https://developer.apple.com/reference/security или просто openssl
Различие между вашим описанным подходом к цепочке ключей: У вас есть значение, которое будет зашифровано и сохранено безопасно. (2) описывает подход к получению зашифрованного и сохраненного (в комплекте) полузащищенного значения, которое будет дешифровано
3) Обмен информацией
Вы описываете критические данные, которые были хэшированы другим экземпляром. Большой! - Убедитесь, что убедитесь, что экземпляр, о котором вы говорите, действительно является экземпляром, который вы ожидаете (предотвращение сетевого подключения с помощью ssl-сертификата и т.д., Но даже здесь у вас может быть злоумышленник (мужчины в середине)). И вы, вероятно, имеете сертификат, предоставляемый в вашем комплекте приложений, чтобы убедиться в подлинности сервера связи - здесь вы снова отправляете данные, которые должны обеспечивать безопасный процесс между определенными экземплярами вашей микро-среды. Тем не менее, эти данные предоставляются в вашем приложении.
3.1 Расширенная защита информации - Silent Push Используйте серверы Apple для обмена вашими секретами для этой цели. Если вам просто нужно обмениваться небольшими кусками данных. Я бы рекомендовал использовать молчащие push-уведомления пользователю, которые даже работают без явного разрешения пользователя. Огромное преимущество: в случае изменения ваших секретов или ключей вы можете как можно скорее сообщить об этом изменениям. Скорее всего, они потребуют изменения, когда они получат новые данные, которые в большинстве случаев должны быть надежно работать. Исключение: обмен данными в локальных сетях или через Bluetooth, в этом случае я бы рекомендовал предоставить уведомление пользователю о необходимости обновления локального ключа дешифрования. Или обменять ключ в этом формате. Еще раз: я пропущу некоторую подробную информацию о вашей архитектуре окружения. Недостаток: вы не знаете, пользовался ли пользователь просто вашим приложением в первый раз, пока пользователь "не говорит" вам об этом. https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
3.1 Расширенная защита информации - в App Purchase Используйте frree In-App Purchase для пользователя, чтобы получить данные на свой телефон. Хороший пункт здесь: вы можете легко предоставить большие куски данных, так как это должен быть активный запрос пользователя, пользователь действительно ожидает определенное время обработки, а также должен знать о том, что требуется рабочее интернет-соединение. Даунсайд: пользователь должен будет выбрать это специально. До тех пор приложение не будет работать. https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction.html#//apple_ref/doc/uid/TP40008267
Таким образом, он немного отличается от подхода (2) в своей основной идее.
Вкратце: можете ли вы предоставить дополнительную информацию, какие данные необходимо шифровать/хотите хранить надежно и будет ли у вас сетевой обмен или нет?
Вам понадобится дополнительная информация: -)
Я хотел бы еще раз подчеркнуть, что приложение на iOS не так просто расшифровать, даже декомпиляция не получит все, что вы ожидаете от него. Например, инструменты дешифрования, такие как dumpdecrypt, работали правильно только до iOS 8.4
Я согласен с @Lobsterman и считаю, что лучший способ - использовать их комбинацию.
Cocoapods-keys может быть лучшим вариантом.
Из Cocoapods-keys doc
Имена ключей хранятся в ~/.cocoapods/keys/и значениях ключа в OS X Брелок. Когда вы запускаете pod install или pod update, класс Objective-Cсоздается с помощью скремблированных версий ключей, что затрудняет просто выгрузите содержимое расшифрованного двоичного файла и извлеките ключи. Во время выполнения ключи дешифруются для использования в вашем приложении.
Сгенерированные классы Objective-C хранятся в папках Pods/CocoaPodsKeys, поэтому, если вы проверяете папку "Подписки", просто добавьте Pods/CocoaPodsKeys в ваш файл .gitignore. Поддержка CocoaPods-Keys интеграции в проектах Swift или Objective-C.
Посмотрите эту ссылку для установки, использования и дополнительной информации: https://github.com/orta/cocoapods-keys
Если данные чрезвычайно чувствительны, то они никогда не должны храниться в автономном режиме на устройстве, потому что все устройства являются взломанными. Если вы все еще хотите хранить на устройстве, тогда связка ключей является одним из вариантов безопасного хранения данных. Однако это шифрование основано на пин-код устройства. Пользователь не вынужден устанавливать контакт, поэтому в некоторых ситуациях данные даже не могут быть зашифрованы. Кроме того, пин-код пользователя может быть легко взломан.
Лучшим решением является использование чего-то вроде SQLCipher, который является полностью зашифрованной базой данных SQLite. Ключ шифрования может быть применен приложением и отделен от PIN-кода пользователя.