Безопасный алгоритм создания лицензионных ключей?

Question

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

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

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

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

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

Поскольку это ключ продукта, было бы замечательно, если бы он был достаточно коротким, 64 символа или, возможно, не более 128, но чем короче, тем лучше, 32 или меньше было бы здорово.

Answer 1

Вы не сказали, на какой платформе вы находитесь, но вот в Microsoft .Net:

http://jclement.ca/devel/dotnet/reallysimplelicensing.html

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

Эта схема использует Microsoft Библиотека RSA и подпись XML. В принципе вы кладете все, что вы хотите в XML Документ и подписать этот документ. затем Вы можете предоставить этот файл вашему клиент и приложение могут прочитать информация о лицензии из этого файл. Поскольку файл является цифровым подписанный файл лицензии НЕ МОЖЕТ быть подделаны, если вы не отпустите закрытый ключ (который вы действительно не должен делать).

Answer 2

Нет доступа в Интернет и ключи для выстрела

Что касается размера серийного ключа, то между короткими / удобочитаемыми клавишами существует компромисс ( менее безопасно ) и имеет длинные ключи или, возможно, файлы лицензий ( более безопасно ).

Если вам нужны короткие и удобные для чтения ключи, которые позволяют хранить такие вещи, как дата окончания срока действия и функции, вы можете использовать SKGL вместе с Software Protector, которые имеют открытый исходный код (https://help.cryptolens.io/faq/what-is-skgl).

Однако недостатком является то, что они, скорее всего, будут использовать симметричную криптографию и / или сохранят алгоритм генерации ключа внутри приложения. Это означает, что конечный пользователь может попытаться найти ключ шифрования и / или алгоритм (см. http://www.codeproject.com/Articles/764610/Licensing-systems-in-NET).

Доступ в Интернет (или автономно с файлами активации)

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

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

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

Решения:

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

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

• передайте третьей стороне - недостаток в том, что большинство из них не бесплатны.

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

Существует несколько решений (, убедитесь, что вы ищете те, которые основаны на сети ), Cryptolens является одним из примеров. Если вы разрабатываете приложение .NET, вот пошаговый пример: https://help.cryptolens.io/examples/key-verification.

---

Отказ от ответственности : я являюсь автором SKGL / Software Protector, статьи о системах лицензирования и Cryptolens.