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

В настоящее время я занимаюсь разработкой продукта (разработанного на C#), который будет доступен для бесплатной загрузки и установки, но в очень ограниченной версии. Чтобы получить доступ ко всем функциям, пользователь должен заплатить лицензионный сбор и получить ключ. Затем этот ключ будет введен в приложение, чтобы «разблокировать» полную версию.

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

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

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

О чем еще мне следует подумать в этом сценарии?

Ответов (15)

Решение

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

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

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

Но, повторяю: пиратство это не предотвратит.


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

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

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

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

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

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

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

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

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

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

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

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

Так как же решить эти проблемы?

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

  2. Это достигается активацией продукта (хороший пример - Windows). По сути, для клиента с действующим лицензионным ключом вам необходимо сгенерировать некоторые «данные активации», которые представляют собой подписанное сообщение, включающее идентификатор оборудования компьютера в качестве подписанных данных. Обычно это делается через Интернет, но только ОДИН РАЗ: продукт отправляет лицензионный ключ и идентификатор оборудования компьютера на сервер активации, а сервер активации отправляет обратно подписанное сообщение (которое также можно сделать коротким и простым, чтобы его можно было продиктовать через Телефон). С этого момента продукт проверяет не лицензионный ключ при запуске, а данные активации, для проверки которых компьютер должен быть одинаковым (в противном случае ДАННЫЕ будут другими, а цифровая подпись не будет проверяться).

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

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

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

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

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

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

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

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

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

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

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

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

Соображения

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

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

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

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

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

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

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

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

Реализация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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