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

Question

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

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

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

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

Что-нибудь еще, о чем я должен подумать в этом сценарии?

Answer 1

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

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

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

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

---

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

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

Answer 2

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

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

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» из ваших ключей. Разбейте строку лицензионного ключа на группы символов.

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

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

Answer 9

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

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

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

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

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

Вопросы

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

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

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

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

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

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

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

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

Осуществление

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

Answer 10

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

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

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