Зашифрованные и защищенные док-контейнеры

Question

Все мы знаем ситуации, когда вы не можете использовать открытый исходный код и свободно распространять программное обеспечение - и я попал в одну из таких ситуаций.

У меня есть приложение, которое состоит из нескольких двоичных файлов (скомпилированных из исходников C) и кода Python, который превращает все это в систему. Это приложение использовалось в качестве облачного решения, поэтому пользователи имели доступ к функциям приложения через сеть, но не имели возможности прикоснуться к реальному серверу, на котором хранятся двоичные файлы и код.

Теперь мы хотим доставить "локальную" версию нашей системы. Приложение будет работать на ПК, которые физически будут принадлежать нашим пользователям. Мы знаем, что все может быть сломано, но по крайней мере хотим максимально защитить приложение от возможного копирования и реверс-инжиниринга.

Я знаю, что docker - замечательный инструмент развертывания, поэтому мне интересно: возможно ли создавать зашифрованные док-контейнеры, где никто не может видеть никаких данных, хранящихся в файловой системе контейнера? Есть ли известное решение этой проблемы?

Также, может быть, есть хорошо известные решения, не основанные на докере?

Answer 1

То, о чем вы спрашиваете, называется обфускацией. Это не имеет никакого отношения к Docker и является очень специфичной для языка проблемой; для данных вы всегда можете делать все, что хотите, но вы можете надеяться отговорить злоумышленника, но он никогда не будет в безопасности. Даже современные схемы шифрования не могут помочь, так как программа (которую вы предоставляете) должна содержать ключ.

C, как правило, достаточно сложно перепроектировать, для Python вы можете попробовать pyobfuscate и аналогичные.

Для данных я нашел этот вопрос (ключевые слова: шифрование файлов игры).

Answer 2

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

Используя запутывание на стандартном Linux-боксе, вы можете усложнить чтение файловой системы и оперативной памяти, но вы не можете сделать это невозможным или контейнер не может работать.

Если вы можете управлять оборудованием, работающим под управлением операционной системы, вам может понадобиться модуль Trusted Platform Module, который запускает проверку системы сразу после загрузки системы. Затем вы можете теоретически сделать что-то, прежде чем пользователь root сможет получить доступ к системе, чтобы скрыть ключи и надежно зашифровать файловые системы. Даже тогда, имея физический доступ к машине, решительный злоумышленник всегда может получить расшифрованные данные.

Answer 3

Если вы хотите полностью безопасное решение, вы ищете "святой Грааль" конфиденциальности: гомоморфное шифрование. Короче говоря, вы хотите зашифровать свое приложение и данные, отправить их на ПК, и этот ПК должен запускать их без того, чтобы их владелец, ОС или кто-либо еще мог просматривать данные. Это без активного снижения производительности является активным исследовательским проектом. Был по крайней мере один проект, который управлял этим, но у него все еще есть ограничения:

1. Это только для окон
2. Процессор имеет доступ к ключу (т.е. вы должны доверять Intel)
3. Он оптимизирован для облачных сценариев. Если вы хотите установить его на несколько компьютеров, вам необходимо предоставить ключ безопасным способом (т.е. просто зайти туда и набрать его самостоятельно) на одном из компьютеров, на котором вы собираетесь установить приложение, и этот компьютер должен быть в состоянии безопасно распространять ключ на другие компьютеры.

Предложение Энди об использовании TPM имеет те же последствия, что и пункты 2 и 3.

Answer 4

Похоже, Docker - не тот инструмент, потому что он никогда не предназначался для использования в качестве полноценной песочницы (по крайней мере, исходя из того, что я читал). Почему вы не используете более полнофункциональный подход VirtualBox? По крайней мере, тогда вы сможете заблокировать виртуальную машину за входами в систему (столько, сколько может быть заблокирована физическая установка на чужом компьютере) и запустить ее изолированно, зашифрованные файловые системы и целые девять ярдов.

Вы можете либо стать легкими и открытыми, либо толстыми и закрытыми. Я не знаю, что есть "легкий и закрытый" вариант.

Answer 5

У меня точно такая же проблема. В настоящее время то, что я смог открыть, это ниже.

А. Асило ( https://asylo.dev/)

1. Asylo требует, чтобы программы / алгоритмы были написаны на C++.
2. Библиотека Asylo интегрирована в Docker, и представляется целесообразным создать собственный образ докера на основе Asylo.
3. Asylo зависит от многих не очень популярных технологий, таких как "прото буферы", "bazel" и т. Д. Мне кажется, что кривая обучения НЕ будет крутой, т. Е. Человеку, создающему образы / программы докера, потребуется много времени, чтобы понять как это сделать.
4. Asylo бесплатно
5. Asylo - новинка со всеми преимуществами и недостатками.
6. Asylo производится компанией Google, но она НЕ является официально поддерживаемым продуктом Google в соответствии с заявлением об отказе от ответственности на его странице.
7. Asylo обещает, что данные в доверенной среде могут быть сохранены даже от пользователя с привилегиями root. Однако документации не хватает, и в настоящее время неясно, как это можно реализовать.

Б. Сконе ( https://sconedocs.github.io/)

1. Он привязан к технологии INTEL SGX, но есть и режим симуляции (для разработки).
2. Это не бесплатно. Он имеет лишь небольшой набор функций, которые не оплачиваются.
3. Кажется, поддерживает множество функций безопасности.
4. Прост в использовании.
5. Кажется, у них больше документации и инструкций по созданию собственного образа докера с помощью их технологии.

Answer 6

Что касается части Python, вы можете рассмотреть возможность использования Pyinstaller с соответствующими параметрами, он может упаковать все ваше приложение python в один исполняемый файл, который не требует запуска установки Python конечными пользователями. Он эффективно запускает интерпретатор python для упакованного кода, но имеет параметр шифрования, который позволяет зашифровать байт-код.

Да, ключ будет где-то около исполняемого файла, и очень сообразительный заказчик может иметь средства для его извлечения, таким образом распутывая не очень читаемый код. Вам решать, содержит ли ваш код какой-то большой секрет, который нужно скрыть любой ценой. Я бы, вероятно, не стал бы этого делать, если бы хотел брать большие деньги за устранение ошибок в развернутом продукте. Я мог бы использовать его, если у клиента есть хорошие стандарты соответствия, и он не является потенциальным конкурентом, и не ожидается, что он будет платить за дополнительные лицензии.

Хотя я сделал это один раз, я, честно говоря, не стал бы делать это снова.

Что касается кода C, если вы можете скомпилировать его в исполняемые файлы, и / или общие библиотеки могут быть включены в исполняемый файл, созданный Pyinstaller.

Answer 7

У меня такая же проблема. Я подумал о том, чтобы создать основной компонент приложения, являющийся общей библиотекой (.so), и сделать так, чтобы этот фрагмент загружался на виртуальный диск при запуске контейнера.

Конечно, не весь ваш код защищен, но вы пытаетесь сделать его бесполезным без этого одного основного компонента, который скомпилирован на C++ или C.

Это просто идея без каких-либо фактических деталей реализации.