Комментарии 17
А после того, как Вы прочитали модель, вы вызываете что-нибудь типа torch.load() ?
А зачем использовать Sentinel, если есть OpenSSL и можно шифровать/дешифровать свободно и все ограниченно только личной фантазией?
Аппаратная защита + защита от взлома бинарника
Ну в данной задаче аппаратная защита, вряд ли даёт преимущества, зашифрованным 256 битным ключом или даже 512 битным, уже не взломать. Вы имеете в виду защита от взлома бирнарника, после применении утилиты Envelope ?
Да. Для того, чтобы расшифровать нужно иметь ключь, его нужно где-то хранить, если его хранить в необфусцированном бинарнике, то его можно там найти. Еще можно сделать мемори дамп и найти его там. Средства типа Envelope позволяют решить эти проблемы.
Слава, здравствуйте. Давно не общались, думаю вы соскучились по мне)))
Интересный материал вы опубликовали....
Все же специалист должен быть нишевым. Если получается хорошо писать код - то это позиция разработчика. Если нужно приземлять решения в On-prem, то как это делает Сбер - нанимают devSecOps инженера.
Здесь вы пишите про защиту .so библиотеки шифрованием с помощью HASP ключа, но отвечаете в тексте комментариев о том, что в коде есть функция torch.load. Это на самом деле серьезная утечка для службы безопасности МТС. Дело в том, что тут сразу вскрываются несколько вещей:
- во-первых очевидно, что решение этой задачи могло и должно было быть построено вокруг использования с ключом дополнительно защищенных так называемых .etrt или encrypted ONNX моделей. Ведь обозначив факт использования torch - вы потенциально раскрываете ряд фактов, один из них - что развернутый граф нейронной сети перестает быть зашифрованным, находясь в памяти видеокарты. А там он - это набор констант определенного типа по фиксированным адресам. Получается есть далеко ненулевая вероятность запустится с Hasp ключом, отправить граф в память vRAM GPU и подключив безопасников - веса графа сдампить себе на память.
- во-вторых видно, что Python используется тут как метод короткого инженерного пути и сразу ухудшает потенциальную привлекательность продукта, потому что обозначает cython и как следствие микс 2х языков реализации внутри - Python и биндингов, вероятно с++. Конечно для компании уровня 100% актива МТС это не серьезно и наносит урон её репутации. Ведь конечный продукт будет обладать более низкой надежностью, и вероятно скоростью.
- в-третьих тут есть неплохой комментарий от frazer о том, что диффи-хелман и openssl - вполне себе живые вещи, если готовить правильно. К тому же энкриптер на питоне пишется в 10-20 строк кода. Сам сертификат вполне себе генерируется для on-prem системы.
- в четвертых. Компании в области ИИ значительную часть расходов на НМА (нематериальные активы) несут через списание затрат на наиболее дорогие задачи - такие как ML (серверные ресурсы) и зарплаты ML инженеров. И именно модель нужно защищать, а не код. Код в этой индустрии почти ничего не стоит, особенно когда команда не может написать серверный код на чистом С++.
- даже не сдампив чекпоинт нейронного графа, но определив его архитектуру (полный конфигуратор слоев) можно нанести глубочайший урон публичной компании, ведь сам граф может выдать так называемые open source решения, львиная часть которых заставит опубликовать весь код в исходниках по запросу.
-в-шестых с позиции лицензирования софт в паре с ключом образует не очередную лицензионную копию продукта, а новый продукт на балансе, ведь получается, что .so файл, зашифрованный аппаратным ключом, образует уникальную копию продукта. Сигнатура библиотек уникальная для каждого выпущенного ключа и такой софт уже не является очередной копией продукта, лицензию на который компания ставит по закону на баланс. В этой ситуации юридическая защита On-prem поставок сильно затруднена, ведь поставляется по сути каждый раз уникальное по сигнатурам решение. И такую поставку, если и защищать - то получается каждый раз формировать для этого новый продукт с уникальным названием, не говоря уже про трудности гос. регистрации.
- с позиции защиты самой опасной утечкой является граф классификатора. Пока еще не существует обратного доказательства, на каких данных он обучен, но это еще произойдет в индустрии и тогда вскроется много фактов, из-за которых вероятно будут недовольны к примеру авторы открытых данных и большая аудитория в целом.
- ну и напоследок - HASP ключ отлично прокидывается на удаленную систему через USB IP. В своей практике я моделировал такое и проверял эффективности защиты этим ключом сервисов ASR, поставленных в on prem. Результат был так себе. Клон системы делали одной командой и запускали на удаленной машине как VM, куда с текущей прокидывали hasp ключ, который ничего не подозревал. Так и может работать система заказчика, исполняя код на удаленной системе с прокинутым ключом хоть из Москвы на сервер Пентагона.
После запуска - будет расшифровка данных и они и ранее обфусцированные строки программы будут в памяти в открытом виде или применяются еще механизмы защиты ?
Да. Будут в открытом виде в памяти процесса, но дастать их будет затруднительно, т.к. благодяря Envelope отладчик не работает и дамп снять нельзя.
хм, интересно, а есть ли тех. информация как Envelope это удается ?
хотелось бы попробовать это сделать самому )
На линуксе есть /dev/mem с помощью которого с правами рута можно прочитать всю оперативку. И соответственно можно либо полный дамп снять и в нем уже искать, либо найти адреса конкретного процесса и сделать его дамп
Подскажите, как бы Вы посоветовали шифровать ml-модельки которые так же поставлялись бы с зашифрованным ПО?
Мы шифровали средствами Sentinel SDK. Или что вы имеете ввиду?
Странно, а почему вы опытного девопса на пару часов не позвали сделать нормальный setuptools файл?
Как установить лицензионную защиту кода на Python и обезопасить данные с помощью HASP?