В настоящее время я занимаюсь разработкой продукта (разработанного на C #), который будет доступен для загрузки и установки бесплатно, но в очень ограниченной версии. Чтобы получить доступ ко всем функциям, пользователь должен оплатить лицензионный сбор и получить ключ. Затем этот ключ будет введен в приложение, чтобы «разблокировать» полную версию.
Так как использование лицензионного ключа вроде обычного, мне интересно:
- Как это обычно решается?
- Как я могу сгенерировать ключ и как он может быть проверен приложением?
- Как можно также избежать публикации ключа в Интернете и его использования другими лицами, которые не заплатили лицензию (ключ, который в основном не является "их").
Думаю, мне следует как-то привязать ключ к версии приложения, чтобы можно было взимать плату за новые ключи в версиях функций.
Что-нибудь еще, о чем я должен думать в этом сценарии?
c#
license-key
Riri
источник
источник
Существует много способов создания лицензионных ключей, но очень немногие из них действительно безопасны. И очень жаль, потому что для компаний лицензионные ключи имеют почти такую же ценность, как реальные деньги.
В идеале вы хотели бы, чтобы ваши лицензионные ключи имели следующие свойства:
Только ваша компания должна иметь возможность генерировать лицензионные ключи для ваших продуктов, даже если кто-то полностью обратный инжиниринг ваших продуктов (что произойдет, я говорю из опыта). Запутывание алгоритма или скрытие ключа шифрования в вашем программном обеспечении действительно исключено, если вы серьезно относитесь к контролю лицензирования. Если ваш продукт успешен, кто-то сделает генератор ключей в течение нескольких дней с момента выпуска.
Лицензионный ключ должен использоваться только на одном компьютере (или, по крайней мере, вы должны быть в состоянии контролировать это очень жестко)
Лицензионный ключ должен быть коротким, его легко набирать или диктовать по телефону. Вы не хотите, чтобы каждый клиент звонил в службу технической поддержки, потому что он не понимает, содержит ли ключ «l» или «1». Ваш отдел поддержки поблагодарит вас за это, и у вас будет меньше затрат в этой области.
Итак, как вы решаете эти проблемы?
Ответ прост, но технически сложен: цифровые подписи с использованием криптографии с открытым ключом. Ваши лицензионные ключи должны быть на самом деле подписаны «документы», содержащие некоторые полезные данные, подписанные с закрытым ключом вашей компании. Подписи должны быть частью лицензионного ключа. Продукт должен проверить лицензионные ключи с соответствующим открытым ключом. Таким образом, даже если кто-то имеет полный доступ к логике вашего продукта, он не может генерировать лицензионные ключи, потому что у него нет закрытого ключа. Лицензионный ключ будет выглядеть следующим образом: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA))))) Самая большая проблема здесь заключается в том, что классические алгоритмы открытого ключа имеют большие размеры подписи. RSA512 имеет 1024-битную подпись. Вы не хотите, чтобы ваши лицензионные ключи имели сотни символов. Одним из наиболее эффективных подходов является использование криптографии с эллиптическими кривыми (с осторожными реализациями, чтобы избежать существующих патентов). Ключи ECC примерно в 6 раз короче, чем ключи RSA, при той же прочности. Вы можете дополнительно уменьшить размеры подписи, используя такие алгоритмы, как алгоритм цифровой подписи Schnorr (срок действия патента истек в 2008 году - хорошо :))
Это достигается активацией продукта (хороший пример - Windows). По сути, для клиента с действующим лицензионным ключом вам необходимо сгенерировать некоторые «данные активации», которые представляют собой подписанное сообщение, в которое в качестве подписанных данных входит идентификатор оборудования компьютера. Обычно это делается через Интернет, но только ОДИН РАЗ: продукт отправляет лицензионный ключ и идентификатор аппаратного обеспечения компьютера на сервер активации, а сервер активации отправляет обратно подписанное сообщение (которое также можно сделать коротким и легко диктовать через Телефон). С этого момента продукт проверяет не лицензионный ключ при запуске, а данные активации, для которых компьютер должен быть одинаковым для проверки (в противном случае данные будут отличаться, а цифровая подпись не будет проверяться).
Ну, просто удалите лишние символы, такие как «1», «l», «0», «o» из ваших ключей. Разбейте строку лицензионного ключа на группы символов.
источник
Простой ответ - независимо от того, какую схему вы используете, ее можно взломать.
Не наказывайте честных клиентов с помощью системы, предназначенной для предотвращения хакеров, так как хакеры взломают ее независимо от этого.
Простой хешированный код, связанный с их электронной почтой или подобным, вероятно, достаточно хорош. Аппаратные идентификаторы всегда становятся проблемой, когда людям нужно переустанавливать или обновлять оборудование.
Хорошая тема по этому вопросу: http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34
источник
При генерации ключа не забудьте объединить версию и номер сборки со строкой, по которой вы вычисляете хеш. Таким образом, не будет ни одного ключа, который разблокирует все, что вы когда-либо выпускали.
После того, как вы обнаружите, что некоторые ключи или патчи плавают в astalavista.box.sk, вы узнаете, что вам удалось сделать что-то достаточно популярное, чтобы кто-то потрудился взломать. Радуйтесь!
источник
Помимо того, что уже было заявлено ....
Любое использование приложений .NET по своей природе может быть взломано из-за проблем со средним языком. Простая разборка кода .NET откроет ваш продукт любому. В этот момент они могут легко обойти ваш лицензионный код.
Вы даже не можете использовать аппаратные значения для создания ключа больше. Виртуальные машины теперь позволяют кому-то создавать образ «лицензированной» машины и запускать его на любой платформе, которую они выберут.
Если это дорогое программное обеспечение, есть другие решения. Если это не так, просто сделайте это достаточно сложным для случайного хакера. И принять тот факт, что в конечном итоге будут нелицензионные копии.
Если ваш продукт сложный, проблемы, связанные с поддержкой, создадут вам некоторую защиту.
источник
Движок C # / .NET, который мы используем для генерации лицензионного ключа, теперь поддерживается как открытый исходный код:
https://github.com/appsoftware/.NET-Licence-Key-Generator .
Он основан на системе «Partial Key Verification», которая означает, что в ваш дистрибутив должен быть скомпилирован только поднабор ключей, которые вы используете для генерации ключа. Вы сами создаете ключи, поэтому реализация лицензии уникальна для вашего программного обеспечения.
Как указано выше, если ваш код можно декомпилировать, то относительно легко обойти большинство систем лицензирования.
источник
Я один из разработчиков Cryptolens программной платформы лицензирования и работают на системы лицензирования , начиная с возраста 14. В этом ответе, я включил некоторые советы , основанные на опыте , приобретенном на протяжении многих лет.
Лучший способ решить эту проблему - настроить сервер лицензионных ключей, который будет вызывать каждый экземпляр приложения для проверки лицензионного ключа.
Преимущества сервера лицензионных ключей
Преимущества использования сервера лицензионных ключей:
Соображения
Хотя проверка лицензий в режиме онлайн дает вам больший контроль над каждым экземпляром приложения, подключение к Интернету не всегда присутствует (особенно если вы нацелены на крупные предприятия), поэтому нам необходим другой способ проверки лицензионного ключа.
Решение состоит в том, чтобы всегда подписывать ответ лицензионного ключа от сервера, используя криптосистему с открытым ключом, такую как RSA или ECC (возможно, лучше, если вы планируете работать на встроенных системах). Ваше приложение должно иметь только открытый ключ для проверки ответа лицензионного ключа.
Таким образом, в случае отсутствия подключения к Интернету, вы можете использовать предыдущий ответ лицензионного ключа. Убедитесь, что в ответе хранятся и дата, и идентификатор компьютера, и убедитесь, что он не слишком старый (например, вы разрешаете пользователям оставаться в автономном режиме не более 30 дней и т. Д.) И что ответ лицензионного ключа принадлежит правильному устройству.
Защита секретных алгоритмов
Большинство приложений .NET можно довольно легко реверсировать (есть и дизассемблер, предоставленный Microsoft для получения кода IL, и некоторые коммерческие продукты могут даже получать исходный код, например, в C #). Конечно, вы всегда можете запутать код, но он никогда не будет на 100% безопасным.
В большинстве случаев цель любого решения по лицензированию программного обеспечения состоит в том, чтобы помочь честным людям быть честными (т. Е. Честные пользователи, которые готовы платить, не забывают платить по истечении пробного периода и т. Д.).
Однако у вас все еще может быть какой-то код, который вы никоим образом не хотите разглашать общественности (например, алгоритм для прогнозирования цен на акции и т. Д.). В этом случае единственный способ - создать конечную точку API. которую ваше приложение будет вызывать каждый раз, когда должен выполняться метод. Требуется подключение к Интернету, но это гарантирует, что ваш секретный код никогда не выполняется на клиентском компьютере.
Реализация
Если вы не хотите реализовывать все самостоятельно, я бы порекомендовал взглянуть на этот учебник (часть Cryptolens )
источник
Я использовал Crypkey в прошлом. Это один из многих доступных.
Вы можете защищать программное обеспечение только до определенной степени с любой схемой лицензирования.
источник
Я не знаю, насколько тщательно вы хотите получить
но я считаю, что .net может получить доступ к серийному номеру жесткого диска.
Вы могли бы заставить программу прислать вам это и что-то еще (например, имя пользователя и MAC-адрес ник)
Вы вычисляете код на основе этого и отправляете им по электронной почте ключ обратно.
они не дадут им переключаться между машинами после того, как у них будет ключ.
источник
Единственный способ сделать все, что вы просили, это потребовать доступ в Интернет и проверку с помощью сервера. Прикладная программа должна войти на сервер с ключом, а затем вам необходимо сохранить детали сеанса, такие как IP-адрес. Это предотвратит использование ключа на нескольких разных машинах. Это обычно не очень популярно среди пользователей приложения, и если это не очень дорогое и сложное приложение, оно того не стоит.
Вы можете просто получить лицензионный ключ для приложения, а затем проверить клиентскую сторону на предмет его пригодности, но его легко распространить среди других пользователей, и с помощью декомпилятора можно генерировать новые ключи.
источник
Я реализовал однократную активацию через Интернет в программном обеспечении моей компании (C # .net), для которого требуется лицензионный ключ, который ссылается на лицензию, хранящуюся в базе данных сервера. Программное обеспечение попадает на сервер с ключом и получает лицензионную информацию, которая затем шифруется локально с использованием ключа RSA, сгенерированного из некоторых переменных (комбинация CPUID и других элементов, которые не часто меняются) на клиентском компьютере, а затем сохраняет его в реестр.
Это требует некоторого кодирования на стороне сервера, но оно очень хорошо сработало для нас, и я смог использовать ту же систему, когда мы расширились до программного обеспечения на основе браузера. Он также дает продавцам отличную информацию о том, кто, где и когда используется программное обеспечение. Любая система лицензирования, которая обрабатывается только локально, полностью уязвима для эксплуатации, особенно с учетом .NET . Но, как все говорили, ни одна система не является полностью безопасной.
По моему мнению, если вы не используете веб-лицензирование, нет никакой реальной причины для защиты программного обеспечения вообще. Из-за головной боли, которую может вызвать DRM, несправедливо по отношению к пользователям, которые фактически заплатили за это.
источник
Я твердо верю, что только система лицензирования на основе криптографии с открытым ключом является правильным подходом, потому что вам не нужно включать в ваш исходный код важную информацию, необходимую для генерации лицензии.
В прошлом я много раз использовал Библиотеку лицензирования Treek , потому что она полностью удовлетворяет этим требованиям и предлагает действительно хорошую цену. Он использует одинаковую лицензионную защиту для конечных пользователей и самого себя, и никто не взломал это до сих пор. Вы также можете найти хорошие советы на сайте, чтобы избежать пиратства и взлома.
источник
Как и некоторые другие упомянутые выше, я являюсь огромным противником враждебного отношения к клиентам по умолчанию - то, на что индустрия лицензирования печально известна. Поэтому я остановлюсь на хорошем решении вашей проблемы, которое также предлагает хороший пользовательский UX .
Для начала вы упомянули, что у вас есть «ограниченная» версия программного обеспечения, которую вы используете, чтобы попытаться преобразовать клиентов в «апгрейд» для получения дополнительных функций. Итак, вам нужны лицензии для вашего продукта, например, клиент может приобрести лицензию для Feature-X или Feature-Y .
Я создал Keygen с учетом этого типа лицензирования. Keygen - это лицензионный REST API, который позволяет управлять учетными записями пользователей, лицензиями, а также отслеживать использование / ассоциации компьютеров.
Я хотел бы установить два типа лицензий ( политика в Keygen), где один является базовой политикой для ограниченной бесплатной версии, а другой - политикой для платной версии.
Я не уверен, что вы используете для платежей, но давайте предположим, что вы используете что-то вроде Stripe (довольно стандартного в настоящее время), который предлагает веб-хук . У Keygen также есть webhooks (используете ли вы это или нет, все это по-прежнему применимо). Вы можете интегрировать Keygen, чтобы разговаривать с вашим платежным провайдером, используя веб-крюки с обеих сторон (подумайте:
customer.created-> создать базовую лицензию для клиента,license.created-> взимать плату с клиента за новую лицензию).Таким образом, используя webhooks, мы можем автоматизировать создание лицензий для новых клиентов. Так как насчет проверки лицензии в самом приложении? Это может быть сделано различными способами, но наиболее популярным является требование, чтобы ваш клиент ввел длинный лицензионный ключ в поле ввода, которое затем можно проверить; Я думаю, что это ужасный способ проверки лицензии в вашем приложении.
Почему я так думаю? Ну, во-первых, вы требуете от своего клиента ввести утомительно длинный лицензионный ключ, предназначенный для потребления машины, а во-вторых, вы требуете, чтобы вы и ваш клиент отслеживали указанный утомительно длинный лицензионный ключ .
Ладно, а какая альтернатива? Я думаю, что лучшая альтернатива - сделать то, к чему привыкли все ваши клиенты: позволить им создать учетную запись для вашего продукта, используя адрес электронной почты / пароль . Затем вы можете связать все их лицензии и их машины с этой учетной записью. Так что теперь вместо ввода лицензионного ключа они могут просто войти в систему, используя свои учетные данные.
Какое преимущество это дает вам? Во-первых, это избавляет вас и ваших клиентов от необходимости отслеживать лицензионные ключи, поскольку все они обрабатываются за кулисами внутри их учетной записи пользователя, и самое главное: теперь вы можете предложить своим клиентам лицензию и машину для самообслуживания. активация! т. е. поскольку все их лицензии и машины связаны с их учетной записью пользователя, вы можете предложить им приобрести лицензию, когда они запустят ваше приложение на неизвестной машине.
Теперь перейдем к проверке лицензии : всякий раз, когда ваш клиент входит в ваше приложение со своим адресом электронной почты / паролем, вы можете запросить у его учетной записи пользователя лицензии, которыми они владеют, чтобы определить, могут ли они использовать Feature-X или Feature-Y . А поскольку ваше приложение теперь самообслуживается , вы можете позволить своим клиентам приобретать дополнительные функции прямо из вашего приложения!
Итак, мы внедрили тонну автоматизации в нашу систему лицензирования, мы можем лицензировать отдельные функции (то есть ограниченную или полную версию), мы предложили удивительный UX для наших клиентов, и мы также решили одну из главных причин для запросов поддержки: восстановление лицензионного ключа.
В любом случае, это долго, но, надеюсь, кому-то поможет!
источник
Полное предотвращение компьютерного пиратства невозможно. Вы можете предотвратить случайное пиратство, и именно это делают все решения по лицензированию.
Лицензирование на узле (машине) заблокировано, если вы хотите предотвратить повторное использование лицензионных ключей. Я уже почти год использую Cryptlex для своего программного обеспечения. У него также есть бесплатный план , поэтому, если вы не ожидаете слишком много клиентов, вы можете использовать его бесплатно.
источник
Вы можете использовать бесплатное решение третьей стороны, чтобы справиться с этим для вас, например 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
источник