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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

Нет доступа к Интернету и клавишам съемки

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

Если вам нужны короткие и удобные для чтения ключи, которые позволяют хранить такие вещи, как дата истечения срока действия и функции, вы можете использовать SKGL вместе с программным обеспечением Protector, которые являются открытым исходным кодом (http://skgl.codeplex.com/).

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

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

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

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

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

Решения:

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

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

Существует несколько решений (убедитесь, что вы ищете веб-сайты), SKM Platform - один из примеров. Если вы разрабатываете приложение .NET, здесь представлен пошаговый пример: https://help.skmapp.com/#getting-started.

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