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

Question

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

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

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

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

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

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

Answer 1

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

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

  

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

     

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

Answer 2

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

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

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

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

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

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

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

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

Решения заключаются в следующем:

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

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

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

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

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

---

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