Безопасный алгоритм создания лицензионных ключей?
Я хотел бы распространить приложение, но есть лицензионный ключ, который они могут ввести, чтобы разблокировать. Что такое хороший алгоритм для создания ключа сжатый, который содержит информацию о том, какие версии они приобрели, а также дополнительные вещи, такие как срок действия лицензии, и т. д.
Я понимаю, что эта защита может быть взломана, но она держит честных людей честными. Я могу или не могу реализовать онлайн-активацию, но я в основном обеспокоен хорошим способом их создания ключи.
мы все видели эту ситуацию, что алгоритм работает лучше всего? Должен ли я запросить текстовое имя пользователя и использовать его для создания уникального ключа продукта на основе их собственной информации?
есть ли система, которая может быть использована, чтобы сделать почти невозможным создание действительного ключа?
возможно, открытая / частная ситуация шифрования пары ключей, когда только производитель имеет закрытый ключ, и данные могут быть проверены открытым ключом, но публичный ключ не может быть захвачен для создания действительных ключей.
поскольку это ключ продукта, было бы здорово, если бы он был довольно коротким, 64 символа или, возможно, 128 Макс, но чем короче, тем лучше, 32 или меньше было бы здорово.
2 ответов
вы не сказали, на какой платформе вы находитесь, но вот один в Microsoft .Net:
http://jclement.ca/devel/dotnet/reallysimplelicensing.html
эта страница документирует очень простой схема лицензирования, которую можно использовать с ваш .Net-приложения. Он предназначен чтобы быть достаточно безопасным, простым в реализации и легко расширяется. Пример версии позволяет предоставлять файлы лицензий с именем клиента, встроенным в них но вы можете легко расширьте его, чтобы добавить другая идентифицирующая информация, машина привязки, сроки годности и т. д.
эта схема использует Microsoft Библиотека RSA и подпись XML. В основном вы помещаете все, что хотите, в XML Документ и подпишите этот документ. Затем вы можете предоставить этот файл клиент и приложение могут читать информация о лицензии из этого файл. Поскольку файл является цифровым подписанный файл лицензии не может быть подделка, если вы не отпустите закрытый ключ (который вы действительно не стоит).
нет доступа в Интернет и выстрелил ключи
Что касается размера серийного ключа, существует компромисс между короткими / удобочитаемыми ключами (менее безопасно) и имеющие длинные ключи или, возможно, файлы лицензий (более безопасное).
Если вы хотите короткие и читаемые человеком ключи, которые позволяют хранить такие вещи, как срок годности и функции, вы можете использовать SKGL вместе с программным обеспечением 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, статьи о лицензировании системы и Криптолены.