Плюсы / минусы использования сборки в качестве файла лицензии?

Question

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

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

Средство генерации лицензии может скомпилировать сборку с соответствующими свойствами и ресурсами и подписать ее.

Обновление
Из того, что я вижу, использование сериализованного XML или сборки было бы очень похоже. С моей точки зрения, сборки позволят мне добавить другие ресурсы и оставят некоторую гибкость на будущее. Как только ресурсы усложняются, сериализация xml становится проблемой.

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

Answer 1

Файл подписанной xml-лицензии имеет несколько преимуществ, но они могут не подходить для вашей ситуации:

1. Вы можете просмотреть его содержимое с помощью простого инструмента, такого как блокнот или веб-браузер. Если вам приходится управлять большим количеством лицензий и проходит много времени, вы можете легче проверить объем лицензии, просто просмотрев файл. Даже клиент может прочитать вам самые важные пункты его лицензии по телефону.
2. Если одной установке приложения может быть назначено много лицензий (для пользователя, для функции и т. Д.), Проще управлять списком XML-файлов, чем динамически загружать сборки.
3. Проще создать инструмент для создания клиентской лицензии -> приложение отправит неподписанный XML-файл для подписи.
4. Это проще для управления версиями. Если новая версия вашего программного обеспечения имеет новые параметры лицензирования и старая лицензия должна работать с обновленной версией, в зависимости от вашей реализации отдельной лицензионной сборки, вы можете сломать старое программное обеспечение.

Если у вас нет какой-либо из этих конкретных потребностей, воспользуйтесь опцией «сборка как лицензия», поскольку ее проще реализовать.

Обновление

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

Достаточно хорошо подписать лицензию в dll или внешнем XML-файле.

Answer 2

Вы можете использовать сборку вместо файла лицензии, но вы не должны. Всегда было возможно удалить цифровую подпись из сборки; теперь это тривиально с помощью инструмента Reflexil.

См. Статью Сбой защиты от несанкционированного доступа CAS: последствия для лицензирования программного обеспечения для получения более подробной информации.

Answer 3

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

Answer 4

Я бы не стал использовать сборку в качестве файла лицензии - как другие отмечали, что сломать ее относительно просто.
Я хотел бы использовать файл (XML или любой другой), а затем заблокировать его на машине пользователя. Это может быть достигнуто несколькими способами:
1) Использовать System.Cryptography.ProtectedData - это просто обертка Windows DPAPI и использование хранилища ключей Windows (либо для пользователя, либо для локального компьютера). Это простой (ish) подход, но вам придется использовать Encoding.UTF8.GetString (или любую другую кодировку) для преобразования обратно из байтового массива. Это просто, но не промышленная сила, так как кто-то еще может выкопать хранилище ключей и т. Д.
2) Используйте уникальный идентификатор машины, такой как SID, с симметричным алгоритмом, таким как Rijndael или Blowfish, и предоставьте хэш SHA-256 незашифрованного файла лицензии в качестве IV. Это немного сложнее в реализации, так как вам нужно будет использовать WMI для поиска SID, а затем использовать System.Security.Cryptography.RijndaelManaged и т. Д. Для шифрования / дешифрования.

Answer 5

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

Answer 6

Я бы предпочел версию сборки, потому что:

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

Но помните.Это просто защита программного обеспечения.Следующим шагом будет использование криптографического ключа ( hasp , marx …)