Как я могу защитить “включенные функции” файл лицензии для моей программы?

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

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

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

Я размышлял об использовании специально созданных сборок для лицензирования приложений. Подход к ключевому файлу изначально ошибочен. Фактически, это набор флагов, говорящих: «Функция X включена, а функция Y - нет». Даже если мы зашифруем его, приложение будет иметь все встроенные функции, а также метод расшифровки файла. Любому решительному хакеру вряд ли будет ужасно сложно взломать эту защиту (хотя этого может быть достаточно, чтобы честные люди оставались честными, а это действительно то, чего мы хотим).

Давайте предположим, что такой подход с использованием зашифрованной функции «Да / Нет» флагов недостаточно. Было бы лучше вообще не поставлять ограниченную функциональность. Используя динамическую загрузку сборки, мы можем легко перенести только одну или две основные функции из каждого ограниченного элемента в другую сборку и при необходимости задействовать их. Эти дополнительные сборки «включения» становятся ключевыми файлами. Для максимальной безопасности вы можете подписать их своим закрытым ключом и не загружать их, если они не подписаны должным образом.

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

Преимущество этого подхода по сравнению с простыми ключевыми файлами Yay / Nay состоит в том, что само приложение не включает функциональность ограниченных режимов. Его невозможно взломать, не имея хотя бы четкого представления о том, что делают эти дополнительные сборки - если хакер удалит их загрузку (как они удаляют ключевой файл), код просто не может работать.

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

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

Однако, помимо этого, чтобы ответить на ваш вопрос, этот код должен работать на вас:

http : //www.dotnetspark.com/kb/810-encryptdecrypt-text-files-using-rijndael.aspx

Я считаю, что схему защиты в стиле Perforce проще всего реализовать и использовать, и в то же время она достаточно защищена от взлома. В этом методе используется простой текстовый файл с проверочной подписью, прикрепленной в последней строке. Например:

----(file begin)
key1: value1
key2: value2
expires: 2010-09-25
...
keyN: valueN
checksum: (base64-encoded blob)
---- (file end)

Вы должны выбрать ассиметрический (открытый / закрытый ключ) алгоритм шифрования + алгоритм хеширования по вашему выбору. Сгенерируйте эталонную пару открытого / закрытого ключей. Включите открытый ключ в свою программу. Затем напишите небольшую служебную программу, которая возьмет неподписанный файл настроек и подпишет его - вычислите цифровую подпись для содержимого файла (прочтите файл настроек, вычислите хэш, зашифруйте этот хеш с помощью закрытого ключа) и прикрепите его (например, в кодировке base64 ) как «контрольную сумму» в последней строке.

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

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

Используйте любой метод «криптографии» для реализации этот. Просто проверьте пространство имен System.Security.Cryptography

Вышеупомянутое пространство имен предоставляет множество функций шифрования и дешифрования для защиты секретных данных.

У вас есть другой способ реализовать это с помощью реестра. Вы можете хранить данные в реестре Windows. Лучше зашифровать данные перед сохранением в реестр.

ROT-13!

Изменить:

ROT-13 - это простой шифр подстановки, в котором каждая буква заменяется буквой из 13 букв перед ней в алфавите. (ПРИМЕЧАНИЕ: в качестве альтернативы вы можете использовать значение ascii на 13 меньше, чем данный char, чтобы поддерживать больше, чем [A-Z0-9].)

Для получения дополнительной информации см. wikipedia .