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

https://stackoverflow.com/questions/599837

11-09-2019
|

Вопрос

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

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

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

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

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

Решение

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

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

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

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

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

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

Другие советы

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

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

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

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

Ответ прост, но технически сложен:цифровые подписи с использованием криптографии с открытым ключом.Ваши лицензионные ключи должны быть фактически подписанными "документами", содержащими некоторые полезные данные, подписанные закрытым ключом вашей компании.Подписи должны быть частью лицензионного ключа.Продукт должен проверять лицензионные ключи с помощью соответствующего открытого ключа.Таким образом, даже если кто-то имеет полный доступ к логике вашего продукта, он не сможет сгенерировать лицензионные ключи, потому что у него нет закрытого ключа.Лицензионный ключ будет выглядеть следующим образом:BASE32(CONCAT(ДАННЫЕ, PRIVATE_KEY_ENCRYPTED(ХЭШ(ДАННЫХ)))) Самая большая проблема здесь заключается в том, что классические алгоритмы с открытым ключом имеют большие размеры подписи.RSA512 имеет 1024-битную сигнатуру.Вы же не хотите, чтобы ваши лицензионные ключи состояли из сотен символов.Одним из наиболее эффективных подходов является использование криптографии с эллиптическими кривыми (с тщательной реализацией, позволяющей избежать существующих патентов).Ключи ECC примерно в 6 раз короче ключей RSA при той же прочности.Вы можете дополнительно уменьшить размеры подписи, используя алгоритмы, подобные алгоритму цифровой подписи Шнорра (срок действия патента истек в 2008 году - хорошо :))
Этого можно достичь с помощью активации продукта (хорошим примером является Windows).По сути, для клиента с действительным лицензионным ключом вам необходимо сгенерировать некоторые "данные активации", которые представляют собой подписанное сообщение, включающее идентификатор оборудования компьютера в качестве подписанных данных.Обычно это делается через Интернет, но только ОДИН РАЗ:продукт отправляет лицензионный ключ и идентификатор компьютерного оборудования на сервер активации, а сервер активации отправляет обратно подписанное сообщение (которое также можно сделать коротким и его легко продиктовать по телефону).С этого момента продукт проверяет не лицензионный ключ при запуске, а данные активации, для проверки которых компьютер должен быть тем же самым (в противном случае ДАННЫЕ были бы другими, и цифровая подпись не была бы проверена).Обратите внимание, что проверка данных активации не требует подтверждения через Интернет:достаточно сверить цифровую подпись данных активации с открытым ключом, уже встроенным в продукт.
Что ж, просто уберите из ваших ключей лишние символы, такие как "1", "l", "0", "o".Разделите строку лицензионного ключа на группы символов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соображения

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

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

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

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

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

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

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

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

Реализация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow