ML модели, как и многие другие формы интеллектуальный собственности, подвержены риску быть украденными и использованными без ведома автора. В случае с CoreML большинство моделей зашиты внутри приложения. Достаточно взять Jailbreak девайс, прочитать содержимое бандла и вытащить модель. Подобрать инпут модели уже дело техники и некоторого количества времени. В свое время на практике подобный подход я использовал для сравнения качества нашей ML модели с моделями конкурентов. В этой статье я хотел бы поделиться возможными способами шифрования CoreML моделей.
В 2020 году Apple представила удобный способ деплоя и шифрования CoreML моделей с помощью Apple Cloud. Это довольно мощный инструмент, который дает нам следующие возможности:
Independent development. Возможность обновлять модели на девайсах юзеров без апдейта приложения
Model collections. Возможность объединять модели в коллекции и гарантировать их консистентное обновление. Удобно для случая, когда для одной фичи используется несколько моделей.
Targeted deployments. Возможность поставлять разные ML модели в зависимости от правил: девайса, версии iOS и т.д.
Model encryption. Возможность поставлять модель в зашифрованном виде
Apple Encryption
Остановимся подробней на последнем пункте. Рассмотрим шаги для шифрования ML модели, которую мы будем поставлять вместе с бандлом приложения.
Сначала нам нужно сгенерировать ключ для нашей модели и сохранить его на диске. Для в Project Navigator выбираем нашу модель. Открываем вкладку Utilities и нажимаем Create Encryption Key. В появившемся окне нужно выбрать именно ту команду, под которой мы будем релизить приложение. Нажимаем Continue. Ключ будет сгенерирован и сохранен на диске.
Далее нам нужно указать для Xcode, что мы хотим во время сборки нашего приложения при компиляции модели зашифровать ее с нашим ключом. Для этого выбираем таргет нашего приложения, идем Build Phases -> Compile Sources и добавляем для нашей модели в Compiler Flags:
--encrypt $KeyPathOnDisk
.
Готово. Модель зашифрована. Теперь осталось обратиться к ней в коде таким образом, чтобы мы смогли ее дешифровать. Для этого вместо
init
метода для создания MLModel нужно использовать асинхронный методload
, который появился в iOS 14. Ключ, который мы использовали для шифрования, в момент создания сохраняется в Apple Cloud. В момент первого обращения кload
он скачивается и сохраняется локально на девайсе. Поэтому очень важно, чтобы в момент первого обращения был доступ к сети. При вызовеload
модель дешифруется и загружается в память. На диске же по-прежнему остается зашифрованная ML модель.
MLModel.load(contentsOf: modelURL) { result in
switch result {
case .success(let loadedModel):
print("Successfully loaded model \(loadedModel).")
// Use the loaded model for predictions.
// ...
case .failure(let error):
print("Error loading model: (error).")
}
}
В случае, если мы планируем для доставки модели использовать Apple Cloud, нам нужно выполнить те же шаги, за исключением шага 2. Нам не нужно шифровать модель во время ее компиляции, но нужно во время создания архива. Для этого в диалоговом окне создания архива нам нужно выбрать Encrypt Model и указать путь до нашего ключа
Custom Encryption
Для большинства случаев решение от Apple отлично работает, но бывают исключения, когда приходится задуматься над кастомным решением. Основная причина для этого - кастомный деплой ML моделей, когда нам нужно поставлять ML модели с наших серверов. Несколько возможных причин для этого:
Необходимость более тонкой настройки таргетирования моделей
В компании существует централизованный процесс хранения и апдейта ресурсов приложения, а также требование ему следовать.
A/B тестирование моделей.
Внутренние политики безопасности компании, не позволяющие хранить контент, представляющий интеллектуальную ценность, на серверах Apple.
Поддержка iOS 13 и ниже.
Технически можно пойти по пути, когда мы шифруем модель, чтобы ее забандлить, но по факту не бандлить ее, а доставать зашифрованную, скомпилированную модель и загружать ее на наши сервера. Однако при таком решении, помимо отсутствия возможности автоматизировать процесс деплоя ML модели, значительно повышается риск ошибки, в силу того, что ключ мы будем хранить в Apple Cloud, а саму модель - на наших серверах.
Давайте рассмотрим возможное решение, если перед нами встала задача кастомного шифрования.
Так как модель представляет собой папку, поэтому первым шагом, нам нужно ее заархивировать и получить 1 файл. Для этого можно использовать zip, tar или любой другой архиватор.
Далее нам нужно зашифровать наш файл. Для этого можно использовать популярный
sha256
либо любой другой алгоритм.Зашифрованную модель бандлим в приложение или заливаем на бэкенд.
-
Далее нам нужно придумать способ доставки ключа на клиент. Тут возможны варианты:
-
Обфусцировать ключ и захардкодить его на клиенте. Обращаться к ключу при этом стоит как можно ближе к моменту расшифровки модели и сразу после этого его релизить, чтобы минимизировать время нахождения целого ключа в памяти. Для обфускации можно воспользоваться
https://github.com/pjebs/Obfuscator-iOS или https://github.com/UrbanApps/UAObfuscatedString
-
Можно залить ключ на бэкенд и получать его с помощью запроса в нужный момент.
[UPD 25.11.22] @house2008сделал хорошее замечание, что для этого метода есть риск того, что на Jailbreak девайсе можно отключить ssl pining и прочитать ключ из ответа бэкенда.
Чтобы максимально усложнить жизнь взломщику можно использовать комбинированный подход и разбить ключ на две части. Одну захардкодить, а другую получать с бэкенда. Опять же важно минимизировать время полного ключа в памяти приложения.
-
Теперь дешифрование. Во время работы приложения в момент первого обращения к модели за сессию приложения берем зашифрованную модель на диске (предварительно скачиваем если нужно), получаем ключ, дешифруем модель, релизим из памяти ключ, разархивируем модель и сохраняем во временную папку, например:
NSTemporaryDirectory()/YourFolder/
Инициализируем модель и загружаем ее в память c помощью
init
методаMLModel
Удаляем временную папку.
Конечно это не 100% защита и небольшую часть времени во время работы приложения у нас оказывается на диске незашифрованная модель. Но все же это гораздо лучше, чем не шифровать модель вообще, и усложняет жизнь желающим воспользоваться вашей моделью.
Итого
Мы рассмотрели два подхода к шифрованию CoreML моделей. Какой способ выбрать и стоит ли вообще тратить время на шифрование как водится каждый решает для себя исходя из задач. Всем добра.
Ссылки
Скриншоты взяты из презентации Apple
Комментарии (6)
house2008
25.11.2022 09:38+1Спасибо, очень интересно) А если сделать jailbreak и отключить ssl pining, ваш ключ для расшифровки будет виден в трафике ?
albrom Автор
25.11.2022 13:59+1хорошее замечание, думаю таким способом можно прочитать ключ из трафика. В качестве альтернативы можно захардкодить обфусцированный ключ на клиенте. Либо пойти дальше и сделать составной ключ, часть захардкодить, часть получать с бэкенда. Очень важно при этом минимизировать время нахождения полного ключа в памяти. Для обфускации подойдут библиотеки вроде:
S-trace
27.11.2022 14:40дешифруем модель, релизим из памяти ключ, разархивируем модель и сохраняем во временную папку, например:
NSTemporaryDirectory()/YourFolder/
Вот тут всё ваше шифрование модели разом потеряло смысл, так как на джейлбрейктнутом девайсе достаточно поднять что-то типа inotify на временную папку с коллбэком который будет тут же открывать и оставлять открытыми все появляющиеся во временной директории файлы (чтобы последующее их удаление не помешало прочесть файлы через уже открытые дескрипторы).
Ну или просто запустить ваше приложение под чем-то типа strace и оттрассировать все вызовы
open()
иwrite()
а затем отфильтровать их по пути, получив только вызовы связанные с временной директорией, а затем повторить их и получить полностью дубликат вашей временной директории с расшифрованной моделью.Инициализируем модель и загружаем ее в память c помощью
init
методаMLModel
Ещё одно место которое можно немножко попячить (к примеру вставив в
init
что-то типаsleep(10000)
или заменить вызовinit
наexit()
и спокойненько вычитать за время сна (или после завершения приложения) всю временную директорию с расшифрованной моделью.Удаляем временную папку.
Или просто заменить все вызовы удаления файлов на
nop
- первый же запуск приложения и временная директория с расшифрованной моделью останется.То есть, предложенные методы защищают только от статического анализа, и полностью бессильны против динамического анализа (как активного, с модификацией кода приложения или OS, так и пассивного, просто наблюдая за работой приложения без его модификации).
S-trace
27.11.2022 17:23Далее нам нужно зашифровать наш файл. Для этого можно использовать популярный
sha256
либо любой другой алгоритм.Шифровать алгоритмом хэширования файл конечно можно, но будет очень-очень-очень трудно его расшифровать потом.
Может всё-таки лучше для шифрования выбрать что-то вроде AES256?
fralik
"В момент первого обращения к
load
он скачивается и сохраняется локально на девайсе." - а злоумышленик может утащить этот ключ, чтобы потом самому дешифровать модель?albrom Автор
хороший вопрос. Кажется, что это возможно. Я не нашел информации, где именно сохраняется ключ, но подозреваю что в кейчейне, который можно сдампить.