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

Ответ 1

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

Предполагая, что вы не хотите делать специальную сборку для каждого пользователя, тогда:

• Создайте секретный ключ для продукта
• Введите имя пользователя
• Соединить имя пользователя и секретный ключ и хэш с (например) SHA1
• Распакуйте хэш SHA1 как буквенно-цифровую строку. Это индивидуальный пользовательский ключ продукта
• В рамках программы выполните один и тот же хеш и сравните с ключом продукта. Если оно равно, ОК.

Но, повторяю: это не помешает пиратству

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

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

Ответ 2

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

В идеале вы хотели бы, чтобы ваши лицензионные ключи имели следующие свойства:

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

• Лицензионный ключ должен использоваться только на одном компьютере (или, по крайней мере, вы должны иметь возможность контролировать это очень сильно)

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

Итак, как вы решаете эти проблемы?

• Ответ прост, но технически сложный: цифровые подписи с использованием криптографии с открытым ключом. На ваших лицензионных ключах должны быть фактически подписаны "документы", содержащие некоторые полезные данные, подписанные с вашим личным ключом вашей компании. Подписи должны быть частью лицензионного ключа. Продукт должен проверить ключи лицензии с соответствующим открытым ключом. Таким образом, даже если у кого-то есть полный доступ к вашей логике продукта, они не могут генерировать лицензионные ключи, потому что у них нет закрытого ключа. Лицензионный ключ будет выглядеть так: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA)))) Самая большая проблема здесь заключается в том, что классические алгоритмы открытого ключа имеют большие размеры подписи. RSA512 имеет 1024-битную подпись. Вы не хотите, чтобы ваши лицензионные ключи имели сотни символов. Одним из самых сильных подходов является использование криптографии с эллиптической кривой (с тщательной реализацией, чтобы избежать существующих патентов). Клавиши ECC в 6 раз короче ключей RSA, для той же силы. Вы можете дополнительно уменьшить размеры подписи с помощью алгоритмов, таких как алгоритм цифровой подписи Schnorr (срок действия патента в 2008 году - хороший:))

• Это достигается путем активации продукта (примером является Windows). В принципе, для клиента с действующим лицензионным ключом вам необходимо сгенерировать некоторые "данные активации", которые являются подписанным сообщением, встраивающим идентификатор аппаратного обеспечения компьютера в качестве подписанных данных. Обычно это делается через Интернет, но только ОТВЕТ: продукт отправляет лицензионный ключ и идентификатор аппаратного обеспечения компьютера на сервер активации, а сервер активации отправляет обратно подписанное сообщение (которое также можно сделать коротким и легким, чтобы диктовать Телефон). С этого момента продукт не проверяет лицензионный ключ при запуске, но данные активации, которые требуют, чтобы компьютер был одним и тем же для проверки (иначе DATA будет отличаться и цифровая подпись не будет проверяться). Обратите внимание, что проверка данных активации не требует проверки через Интернет: достаточно проверить цифровую подпись данных активации с открытым ключом, уже встроенным в продукт.

• Ну, просто исключите лишние символы, такие как "1", "l", "0", "o" из ваших ключей. Разделите строку ключа лицензии на группы символов.

Ответ 3

Простой ответ. Независимо от того, какую схему вы используете, он может быть взломан.

Не наказывайте честных клиентов системой, предназначенной для предотвращения хакеров, поскольку хакеры будут взламывать ее независимо.

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

Хорошая тема в этом вопросе: http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34

Ответ 4

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

После того, как вы найдете несколько ключей или патчей, плавающих в astalavista.box.sk, вы узнаете, что вам удалось сделать что-то достаточно популярное, чтобы кто-то побеспокоился трещина. Радуйтесь!

Ответ 5

Кроме того, что уже было сказано....

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

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

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

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

Ответ 6

Механизм С#/.NET, который мы используем для генерации лицензионного ключа, теперь поддерживается как открытый источник:

https://github.com/appsoftware/.NET-Licence-Key-Generator.

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

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

Ответ 7

Я использовал Crypkey в прошлом. Это один из многих доступных.

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

Ответ 8

Я не знаю, насколько тщательно вы хотите получить

но я считаю, что .net может получить доступ к серийному номеру жесткого диска.

у вас может быть программа, которая отправит вам это и что-то eles (например, имя пользователя и адрес mac nic)

вы вычисляете код, основанный на этом, и отправляйте их по электронной почте.

они будут держать их от переключения машин после того, как они имеют ключ.

Ответ 9

Я являюсь одним из разработчиков платформы лицензирования программного обеспечения Cryptolens и работаю над системами лицензирования с 14 лет. В этот ответ я включил несколько советов, основанных на опыте, накопленном за эти годы.

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

Преимущества сервера лицензионных ключей

Преимущества использования сервера лицензионных ключей:

1. Вы всегда можете обновить или заблокировать лицензионный ключ с немедленным вступлением в силу.
2. каждый лицензионный ключ может быть привязан к определенному количеству компьютеров (это помогает пользователям не публиковать лицензионный ключ в сети для других пользователей).

Соображения

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

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

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

Примечание вы всегда должны проверять сертификат ответа лицензионного ключа, даже если вы подключены к Интернету), чтобы убедиться, что он не был изменен после того, как он покинул сервер (это все равно необходимо сделать, даже если ваш API для сервера ключей лицензий использует https)

Защита секретных алгоритмов

Большинство приложений .NET можно довольно легко реверсировать (есть и дизассемблер, предоставляемый Microsoft для получения кода IL, и некоторые коммерческие продукты могут даже получать исходный код, например, в С#). Конечно, вы всегда можете запутать код, но он никогда не будет на 100% безопасным.

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

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

РеализацияЕсли вы не хотите реализовывать все самостоятельно, я бы рекомендовал взглянуть на этот учебник (часть Cryptolens).

Ответ 10

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

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

Ответ 11

Я реализовал одноразовую активацию в Интернете на своем программном обеспечении (С#.net), для которого требуется лицензионный ключ, который ссылается на лицензию, хранящуюся в базе данных сервера. Программное обеспечение попадает на сервер с ключом и получает информацию о лицензии, которая затем зашифровывается локально с использованием ключа RSA, сгенерированного из некоторых переменных (комбинация CPUID и других вещей, которые не будут часто меняться) на клиентском компьютере, а затем сохраняет их в реестра.

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

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

Ответ 12

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

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

Ответ 13

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

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

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

Я бы установил 2 типа лицензий (политика в Keygen), где одна из них является базовой политикой для ограниченной бесплатной версии, а другая - политикой для платной версии.

Я не уверен, что вы используете для платежей, но позвольте предположить, что вы используете что-то вроде Stripe (довольно стандартное в наше время), которое предлагает веб-камеры. У Keygen также есть веб-узлы (независимо от того, используете вы это или нет, все это по-прежнему применимо). Вы можете интегрировать Keygen, чтобы поговорить с поставщиком платежей с помощью веб-кнопок с обеих сторон (подумайте: customer.created → создать базовую лицензию для клиента, license.created → зарядить клиента для новой лицензии).

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

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

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

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

Теперь о проверке лицензии: когда ваш клиент регистрируется в вашем приложении с помощью своего электронного письма/пароля, вы можете запросить свою учетную запись для своих лицензий, чтобы определить, могут ли они использовать функцию-X или функцию -Y. И поскольку ваше приложение теперь самообслуживается, вы можете позволить своим клиентам приобретать дополнительные функции прямо из вашего приложения!

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

В любом случае, это получилось долго, но, надеюсь, это помогает кому-то!

Ответ 14

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

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

Ответ 15

Вы можете использовать бесплатное решение третьей стороны, чтобы справиться с этим для вас, например, Quantum-Key.Net. Оно бесплатное и обрабатывает платежи через PayPal через страницу веб-продаж, которую он создает для вас, выдачу ключей по электронной почте и блокирует использование ключей на конкретном компьютере для предотвратить пиратство.

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

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

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

https://quantum-key.net

Как использовать ConfuserEx?

https://github.com/0xd4d/de4dot

https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download