Как я могу защитить программное обеспечение на Pi для коммерческого использования?

Я хотел бы использовать Raspberry Pi в коммерческом продукте, но я бы хотел предотвратить реверс-инжиниринг программного обеспечения на устройстве. Программное обеспечение, о котором идет речь, будет написано на Ruby. Я предполагаю, что конечный пользователь имеет физический доступ к SD-карте и достаточно умен, чтобы получить root-доступ к Pi.

Как я понимаю, варианты могут включать в себя:

• Зашифровать часть (или все) SD-карты
• Запутать код Ruby или скомпилировать его в байт-код (JRuby или Rubinius)

Шифрование было бы лучшим решением, но я не могу придумать способ расшифровки, не спросив у пользователя ключ. Обфускация кода определенно возможна, но менее безопасна для меня.

Можно ли зашифровать часть SD-карты, не запрашивая у пользователя ключ для ее расшифровки? Или есть лучший способ убедиться, что код доступен только на нужном устройстве?

Конечно, можно расшифровать зашифрованный файл / контейнеры / и т. Д. не спрашивая пароль. Достаточно сохранить (зашифрованный) пароль на SD-карте и использовать его для расшифровки ваших данных. Например, простая opensslдемонстрация может быть:

openssl enc -a -e -salt -aes-256-cbc -pass pass:abc123 -in /tmp/plaintext.txt -out /tmp/ciphertext.enc

openssl enc -d -a -aes-256-cbc -pass pass:abc123 -in /tmp/ciphertext.enc

Шифрование будет выполняться при установке программного обеспечения на Pi, а дешифрование будет выполняться во время выполнения, возможно, в ОЗУ. Например, пароль может быть комбинацией некоторого псевдослучайного порядкового номера (известного вам) и конкретного серийного номера Pi, полученного из a cat /proc/cpuinfo. Затем вам нужно найти подходящее скрытое место для хранения этого псевдослучайного числа, которое, по сути, является « паролем » и, следовательно, слабым местом всего механизма шифрования. Например, резервный сектор на SD будет типичным выбором, но вы даже можете встроить его в один из ваших исполняемых файлов.

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

Наконец, если вашему программному обеспечению требуется подключение к Интернету, вы можете даже заставить Pi каждый раз запрашивать пароль. Вам все еще нужно будет скрыть пароль внутри соединения, вы также должны httpsбудете использовать его, и вам придется защищаться от ответных атак, используя текущее время saltдля шифрования.

У вас есть много (дешевых) вариантов, чтобы сделать ваше программное обеспечение безопасным. Но вы должны знать, что если ваше программное обеспечение достигнет какого-то четко определенного порога популярности, оно наверняка будет взломано, даже если вы вложите значительные средства в его защиту.

Практически, если код и ключи на машине SD - карты, они будут иметь возможность декомпилировать его, они будут иметь возможность открыть для себя ключи , и они будут иметь возможность извлечь конфиденциальные данные.

Это как шифрование фильмов, DVD должен включать всю информацию, необходимую для расшифровки фильма, чтобы его можно было показать зрителю, так что все механизмы защиты от копирования фильма в конечном итоге обречены.

Лучшее, что вы можете сделать, это изменить экономику обратного проектирования вашего продукта.

Стоит ли шифрование и / или запутывание?

Теперь мы установили, что нет способа полностью защитить себя, вопросы становятся

1. Насколько вероятно, что это произойдет?
2. Какова ценность для кого-то еще вашего алгоритма и данных?
3. Сколько стоит им покупка лицензии на использование вашего программного обеспечения?
4. Сколько стоит им тиражирование вашего алгоритма и данных?
5. Сколько стоит им обратный инжиниринг вашего алгоритма и данных?
6. Сколько стоит защита вашего алгоритма и данных?

Если это создает значительный экономический императив для защиты вашего алгоритма / данных, то вам следует заняться этим. Например, если стоимость услуги и стоимость для клиентов высоки, но стоимость обратного инжиниринга вашего кода намного ниже, чем стоимость его разработки самостоятельно, тогда люди могут попробовать это.

Итак, это приводит к вашему вопросу

• Как вы защищаете свой алгоритм и данные?

затемнение

Вариант, который вы предлагаете, запутывая код, смешивается с экономикой выше - он пытается значительно увеличить стоимость для них (5 выше) без значительного увеличения стоимости для вас (6). Проблема заключается в том, что, как и в случае с шифрованием DVD, оно обречено на провал, и если разницы между 3, 4 и 5 достаточно, то в конечном итоге это кто-то сделает.

Другим вариантом может быть форма стеганографии , которая позволяет вам определить, кто расшифровал ваш код и начал его распространять. Например, если у вас есть 100 различных значений с плавающей запятой как часть ваших данных, и 1-битная ошибка в LSB каждого из этих значений не вызовет проблем с вашим приложением, закодируйте уникальный (для каждого клиента) идентификатор в эти биты , Проблема в том, что если кто-то имеет доступ к нескольким копиям данных вашего приложения, очевидно, что они различаются, что облегчает идентификацию скрытого сообщения.

защита

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

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

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

Очевидным недостатком является то, что клиенты привязаны к вашему обслуживанию, находятся в зависимости от ваших серверов и их интернет-соединения. С другой стороны, они всегда в курсе исправлений ошибок. К сожалению, многие люди возражают против SaaS именно по этим причинам.

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

Недавно я изобрел очень изящное решение этой неразрешимой проблемы. Это было вдохновлено этим комиксом xkcd:

Так что решение называется супер клей . Если одна карта SD приклеена к ПИ, извлечь карту практически невозможно, не повредив ее.

Вы даже можете использовать внешний SSD-диск, зашифрованный паролем, хранящимся на SD, и чувствовать себя в безопасности!

Компиляция в байт-код будет лучшим репеллентом. Что касается шифрования, программное обеспечение может храниться на томе TrueCrypt, но только если пользователь не получил root-доступ; просто невозможно надежно сохранить пароль, так как память / диск могут быть сброшены в любое время для проверки. Даже помощь защищенных устройств (смарт-карт) мало что даст, если программное обеспечение работает там, где у пользователя есть множество утилит linux. Насколько я знаю, безопасная загрузка не является опцией на R-Pi, которая предотвращает работу пользователя внутри ОС.

Если вы хотите сделать настоящее коммерческое приложение, то Pi, как он есть в форме конечного пользователя, вам не подходит!

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

1. Напишите правильное встроенное программное обеспечение для BCM, которое сгенерировало один код для входа в систему на основе какого-то совершенно секретного алгоритма, который можно использовать только в течение следующих 10 секунд.
2. Скомпилируйте свое собственное ядро ​​с соответствующим программным обеспечением и включите некоторые функции Linux, которые позволяют вам монтировать root из зашифрованного файла на флэш-памяти, который содержит другой зашифрованный раздел с вашим программным обеспечением (двойная защита).
3. Ваша микропрограмма BCM сгенерирует сверхсекретный однократный ключ авторизации на основе некоторых хитрых алгоритмов или открытых ключей и передаст его в ваш собственный linux kernal, который загрузит зашифрованный корневой раздел и во время загрузки выполнит еще некоторые криптографические операции для загрузки вашего зашифрованного программного диска в зашифрованном изображении.

ЧАЕВЫЕ

• Хорошие ключи авторизации не имеют длины 8-16 символов. Важно предоставлять ключи аутентификации длиной 256/512 байт, используя системные системные символы (HEX) и меньше символов (ASCII)
• Не используйте AES, TKIP, так как он легко взломан
• На сегодняшний день шифрование Whirlpool является одним из самых сложных для взлома с использованием ключей 256/512.
• Даже если хакер может извлечь флешку или сбросить содержимое. Ваше программное обеспечение зашифровано дважды.
• Если они перехватывают ключ авторизации, это будет очень трудно получить из прошивки (потому что BCM может предотвратить дамп прошивки)
• У некоторых умных флеш-ромов также есть функция предотвращения полных дампов памяти.
• Если вы проектируете печатную плату, вы внедрите (как Dell и Apple) микросхемы безопасности, которые обеспечивают все ваши данные и ключи шифрования и предотвращают попытки взлома. Некоторые Dell имеют самоуничтожение для использования в военных целях. Если вы дважды введете неверный пароль в BIOS, он сотрет диск с разбросанными бомбами. Вы можете реализовать то же самое, если обнаружите манипуляции с ключом аутентификации.

Конец дня. Raspberry Pi предназначен для образовательных целей для детей, чтобы научиться использовать Linux и писать некоторые программы.

Он не подходит для коммерческого использования. Вам нужно создать собственное устройство и придумать свои собственные системы защиты. Потому что если только вы и никто другой не знает, как вы защищаете вашу конфиденциальную информацию, то вероятность того, что кто-то взломает ее с помощью известного подвига или грубого нападения, составляет 0,001%.

АЛЬТЕРНАТИВЫ

• Напишите свое программное обеспечение, чтобы оно могло быть скомпилировано и развернуто в целевой системе в двоичном формате. Пример EXE для Windows, которая работает на .NET, JAR для Java или (Не уверен в Linux, C ++?)
• Помните, чем лучше безопасность, которую вы хотите - тем больше денег вам придется потратить на это. Нет никаких исключений.

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

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

Вы можете использовать решение на основе контекста: Software Serial Protection для Raspberry Pi

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

Другой вариант - сохранить ключ шифрования в вашем RTC. Большинство микросхем RTC имеют некоторый объем памяти, и их можно предварительно запрограммировать с помощью ключа, который позволяет разблокировать и смонтировать исполняемый файл с SD или с флэш-памяти SPI.

Я считаю, что все процессоры, используемые в линейке Raspberry Pi, поддерживают собственную безопасную загрузку. Я полагаю, что для перепрошивки 4,8,16,32 или 64 КБ внутренней вспышки или ЭСППЗУ требуется 12 вольт, которых сам пи не имеет. С их помощью вы можете настроить зону доверия с вашим кодом, чтобы не было видно всего хорошего. Я также понимаю, что обе формы статического ОЗУ стабильны только для заданного числа перезаписей. Моим первым шагом было бы иметь запасной процессор и попробовать перезагружать эту безопасную загрузочную память в течение нескольких часов или дней. В конечном итоге все биты становятся фиксированными, поэтому никто другой не может изменить ваш код, и в зависимости от фактического продукта вы можете периодически запрашивать двухфакторную идентификацию (например, банки), чтобы продукт выплевывал код и отправлял код повторной активации. адрес электронной почты. Если ты немного изменишь пи, Я считаю, что у ARM также есть CPUID, поэтому вы можете использовать несколько уровней безопасности. Я имею в виду, вы также можете предложить SMS на определенный номер. Много способов.