Как запутать строковые константы?

Question

У нас есть приложение, которое содержит конфиденциальную информацию, и я изо всех сил стараюсь ее защитить.Чувствительная информация включает в себя:

1. Основной алгоритм
2. Ключи для алгоритма шифрования / дешифрования

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

Кто-нибудь может подсказать, как я могу защитить эти строки?

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

Answer 1

Есть способы сделать то, что вы хотите, но это не дешево и не легко.

Стоит ли это?

При рассмотрении вопроса о том, следует ли защищать программное обеспечение, сначала необходимо ответить на ряд вопросов:

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

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

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

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

Уныние

запутывание

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

Обнаружение

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

Защита

SaaS - Программное обеспечение как услуга

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

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

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

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

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

Защитные ключи для программного обеспечения

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

Более новые ключи переноса кода (такие как SenseLock ^{& dagger;} ), похоже, могут делать то, что вы хотите. С этими устройствами вы извлекаете код из приложения и переносите его на защищенный процессор ключа. Как и в случае SaaS, ваше приложение будет связывать данные, передавать их ключу (возможно, USB-устройству, подключенному к вашему компьютеру) и считывать результаты.

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

^{& кинжал; Это был первый пример, который я смог найти с помощью поиска в Google.}

Надежная платформа

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

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

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

Заключение

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

Answer 2

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

Я стараюсь изо всех сил, чтобы обеспечить его

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

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

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

Answer 3

Я недавно прочитал очень простое решение для ОП.

Простое объявление ваших констант как строки только для чтения, а не как строки констант. Так просто. Очевидно, переменные const записываются в область стека в двоичном файле, но записываются в виде простого текста, тогда как строки readonly добавляются в конструктор и записываются как байтовый массив вместо текста.

т.е. Если вы ищете его, вы не найдете его.

Это был вопрос, верно?

Answer 4

@ Том Гуллен дал правильный ответ.

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

Что касается алгоритма: не компилируйте ваш алгоритм во время компиляции, но во время выполнения. Чтобы сделать это, вам нужно указать интерфейс, который содержит методы для алгоритма. Интерфейс используется для его запуска. Затем добавьте исходный код алгоритма в виде зашифрованной строки (встроенный ресурс). Расшифруйте его во время выполнения и используйте CodeDom для компиляции в класс .NET.

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

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

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

Answer 5

Использование собственного алгоритма ( безопасность через затмение? ) в сочетании с хранением ключа внутри приложения просто небезопасно.

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

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

[Изменить]

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

Идея состоит в том, чтобы хешировать ваши серийные номера во время сборки в их хешированные представления, которые нельзя отменить (SHA-256 считается довольно безопасным алгоритмом по сравнению, скажем, с MD5). Во время выполнения вам нужно только применить ту же хеш-функцию к пользовательскому вводу и сравнить только хеш-значения . Таким образом, ни один из действительных серийных номеров недоступен для атакующего.

Answer 6

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

Answer 7

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