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

лицензионные ключи являются стандартом defacto в качестве антипиратской меры. Честно говоря, мне это кажется (in)безопасность через неизвестность, хотя я действительно понятия не имею, как лицензионные ключи генерируются. Что такое хороший (безопасный) пример генерации лицензионного ключа? Какой криптографический примитив (если таковой имеется) они используют? Это дайджест сообщений? Если да, то какие данные они будут хэшировать? Какие методы используют разработчики, чтобы затруднить крекерам создание собственного ключа генераторы? Как сделаны ключевые генераторы?

333
cryptography license-key security

9 ответов

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

НЕПРАВИЛЬНЫЙ СПОСОБ СДЕЛАТЬ ЭТО:

Starcraft и пол-жизни оба использовали одну и ту же контрольную сумму, где 13-я цифра проверила первые 12. Таким образом, вы может ввести что угодно для первых 12 цифр и угадать 13-й (есть только 10 возможностей), что приводит к печально известному 1234-56789-1234

алгоритм проверки является общедоступным и выглядит примерно так:

x = 3;
for(int i = 0; i < 12; i++)
{
    x += (2 * x) ^ digit[i];
}
lastDigit = x % 10;

ПРАВИЛЬНЫЙ СПОСОБ СДЕЛАТЬ ЭТО

Windows XP берет довольно много информации, шифрует ее и помещает кодировку буквы/номера на наклейку. Это позволило MS проверить ваш ключ и получить тип продукта (Дом, профессионал, etc.) в то же время. Кроме того, он требует онлайн-активации.
Полный алгоритм довольно сложен, но хорошо описан в этой (совершенно законно!) статья, опубликованная в Германии.

конечно, независимо от того, что вы делаете, если вы не предлагаете онлайн-сервис (например,World of Warcraft), любой тип защиты от копирования - это просто стойло: к сожалению, если это какая-то игра стоит того, кто-то сломает (или в наименее обходить) алгоритм CD-key и все другие средства защиты авторских прав.

реальные ПРАВИЛЬНЫЙ СПОСОБ СДЕЛАТЬ ЭТО:

для онлайн-сервисов жизнь немного проще, так как даже с двоичным файлом вам нужно аутентифицироваться на своих серверах, чтобы использовать его (например. имейте учетную запись WoW). Алгоритм CD-key для World of Warcraft, используемый, например, при покупке игровых карт, вероятно, выглядит примерно так:

  1. генерировать очень большое криптографически безопасное случайное число.
  2. храните его в нашей базе данных и распечатайте его на карте.

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

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

256

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

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

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

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

enter image description here

в качестве примера мы построим этот график, выберем четыре очки и закодировать в строку, как "0,-500;100,-300;200,-100;100,600"

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

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

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

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

49

проверьте эту статью на Частичная Проверка Ключа который покрывает следующие требования:

  • лицензионные ключи должны быть достаточно просты для ввода.

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

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

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

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

30

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

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

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

  • генерировать ключи путем шифрования (с закрытым ключом) известного значения + nonce. Это можно проверить путем расшифровки с помощью соответствующего открытого ключа и проверки известного значения. Программа сейчас имеет достаточно информации для проверки ключа, не будучи в состоянии генерировать ключи.

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

21

CD-ключи не являются большой безопасностью для любых не связанных с сетью вещей, поэтому технически они не должны быть безопасно сгенерированы. Если вы находитесь на .net, вы можете почти пойти с Guid.Метод newguid().

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

Это, как говорится, вы можете хотите использовать algorhithm на достижение двух целей:

  • есть какая-то контрольная сумма. Это позволяет вашему установщику отображать сообщение "ключ не кажется действительным", исключительно для обнаружения опечаток (добавление такой проверки в установщик фактически означает, что написание генератора ключей тривиально, поскольку у хакера есть весь код, который ему нужен. Не имея проверки и полагаясь исключительно на проверку на стороне сервера, отключает эту проверку, рискуя раздражать ваших юридических клиентов, которые не понимают, почему сервер не принимает их CD-ключ, поскольку они не знают о опечатке)
  • работа с ограниченным набором символов. Попытка ввести ключ CD и угадать " это 8 или B? 1 или я? Q или O или 0?"- с помощью подмножества не двусмысленно символов/цифр вам устранить эту путаницу.

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

17

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

по существу имеют какой-то nonce и фиксированную подпись.

например: 0001-123456789

где 0001 - ваш nonce, а 123456789-ваша фиксированная подпись.

затем зашифруйте это, используя свой закрытый ключ, чтобы получить ключ CD, который является чем-то вроде: ABCDEF9876543210

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

это тогда мешает кому-то угадать, что ключ CD для nonce 0002, потому что у них нет закрытого ключа.

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

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

10

ключевая система должна иметь несколько свойств:

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

одним из решений, которое должно дать вам это, было бы использовать схема подписания открытого ключа. Начните с "системного хэша" (скажем, возьмите Mac на любой NICs, отсортируйте и CPU-ID info, плюс некоторые другие вещи, объедините все это вместе и возьмите MD5 результата (вы действительно не хотите обрабатывать личная информация если вам не нужно)) добавьте серийный номер компакт-диска и откажитесь от загрузки, если какой-либо раздел реестра (или какой-либо файл данных) не имеет действительной подписи для blob. Пользователь активирует программу, отправив вам blob, и вы отправите обратно подпись.

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

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

9

есть также поведение DRM, которые включают в себя несколько шагов к процессу. Одним из наиболее известных примеров является один из методов Adobe для проверки установки их Creative Suite. Используется традиционный метод ключа CD, обсуждаемый здесь, затем вызывается линия поддержки Adobe. Ключ CD передается представителю Adobe, и они возвращают номер активации, который будет использоваться пользователем.

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

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

1

все CD только алгоритмы защиты от копирования inconvience честных пользователей, не обеспечивая никакой защиты от пиратства вообще.

"пират" должен иметь доступ только к одному законному cd и его код доступа, он может сделать n копий и распространять их.

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

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

в целом, его намного легче установить доверительные отношения с вашими клиентами!

1