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

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

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

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

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

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

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

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

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

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

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

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

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

хорошая резьба на вопрос: http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вычислить код и отправить их обратно в ключ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Грозный способ обработки проверки лицензии в вашем приложении.

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

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

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

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

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

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

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

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

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

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

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

соображения

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

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

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

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

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

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

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

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

реализация

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

вы можете использовать бесплатное стороннее решение для обработки этого для вас, например 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