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

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

Ответ 1

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

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

Starcraft и Half-life использовали одну и ту же контрольную сумму, где 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 одновременно проверить ваш ключ и получить тип продукта (домашний, профессиональный и т.д.) Одновременно. Кроме того, для этого требуется онлайн-активация. Полный алгоритм довольно сложный, но хорошо очерченный в этот (полностью законный!) Документ, опубликованный в Германии.

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

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

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

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

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

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

Ответ 2

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

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

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

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

enter image description here

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

Ключи для компакт-дисков не очень важны для любых не-сетевых файлов, поэтому технически они не должны быть надежно созданы. Если вы находитесь в .net, вы можете почти пойти с Guid.NewGuid().

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

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

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

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

Ответ 6

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

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

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

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

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

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

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

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

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

В целом гораздо проще установить доверительные отношения с вашими клиентами!

Ответ 9

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

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

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