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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

У подписанного файла лицензии xml есть несколько преимуществ, но они не могут быть применены к вашей ситуации:

  • Вы можете проверить его содержимое с помощью простого инструмента, такого как блокнот или веб-браузер. Если вам нужно управлять большим количеством лицензий и много времени, вы можете легко проверить область лицензии, просто просмотрев файл. Даже клиент может прочитать вам самые важные моменты своей лицензии по телефону.
  • Если для одной установки приложения может быть назначено множество лицензий (на пользователя, за функцию и т.д.), проще управлять списком xml файлов, чем динамически загружать сборки.
  • Легче создать инструмент для создания клиентской лицензии → приложение отправит файл подписи без знака для подписания.
  • Это проще для управления версиями. Если новая версия вашего программного обеспечения имеет новые параметры лицензирования, а старая лицензия должна работать с обновленной версией, в зависимости от вашей реализации объединенной сборки лицензирования вы можете разбить старое программное обеспечение.

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

Обновление

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

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

Ответ 2

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

См. статью CAS Tamper-Proofing Broken: последствия для лицензирования программного обеспечения для более подробной информации.

Ответ 3

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

Ответ 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 и т.д. Для шифрования/дешифрования.

Ответ 5

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

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

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

Ответ 6

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