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


361

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


8
+1 интересный вопрос, может ответчик может опубликовать ссылки на некоторые хорошие ресурсы по этой теме для дальнейшего чтения? пожалуйста :)
Джейкоб

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

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

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

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

Ответы:


268

Для CD-ключей старой школы это был просто вопрос создания алгоритма, для которого ключи CD (которые могут быть любой строкой) легко генерировать и легко проверять, но соотношение между действительными ключами CD и invalid-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, используемый, например, при покупке игровых карт, выглядит примерно так:

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

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

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


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

18
Хех, я никогда не знал о 1234-56789-1234ключе Starcraft, но я помню, что потребовалось всего около пяти минут, чтобы «грубо заставить» верификатора нажать на клавиатуру и повторить попытку.
Fmark

18
Я также помню, как в прошлом некоторые продукты Microsoft позволяли вам использовать 111-1111111 в качестве действительного cdkey (Visual Studio 6.0)
hannson

25
Никогда не знал про 1234-56789-1234. Вместо этого мы использовали тринадцать троек! 3333333333333
ErikTJ

33
Проблема с онлайн-активацией состоит в том, что мы все облажались, если / когда издатель обанкротился. Пожалуйста, не делай этого. Это происходит, и может / случится даже с Microsoft когда-нибудь.
Брэд

56

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

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

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

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

введите описание изображения здесь

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

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

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

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

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


6
Нет, Эрик это не будет. X - целое число, а Y - пол функции.
Джошуа

Это мало чем отличается от того, как работала старая спутниковая навигация до GPS! youtube.com/watch?v=BBOsQBuCJfs
Брэд

34

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

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

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

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

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

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


21

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

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

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

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

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


9
Я действительно желаю , кто был придумать «номер , используемый , как только» вещь не выбрала Nonce в качестве имени, учитывая гм негативные коннотации , которые делают меня хихикать каждый раз , когда кто - то предлагает шифрование один.
Эд Джеймс

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

@BCS: Извините, мне следовало более четко использовать криптографию с открытым ключом.
Эндрю Айлетт

Используйте схему подписи, а не схему шифрования для версии с открытым ключом. (Подпись RSA выглядит немного как «шифрование с открытым ключом», но это не совсем то же самое. Существуют другие схемы подписи, которые не имеют связанной схемы шифрования, например DSA.)
Paŭlo Ebermann

Проблема с шифрованием с открытым ключом заключается в том, что ключи (и, следовательно, серийные номера) должны быть длинными. В наши дни 512-битную пару ключей RSA нетрудно взломать. Сравните с ключами WinXP (5 групп по 5 алфавитно-цифровых символов), энтропия которых составляет всего 128 бит, но набирать их все же
сложно

17

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

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

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

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

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


легко решается с помощью хорошего обслуживания клиентов - Box Shot + Подтверждение покупки = Блокировка нелегального пользователя, Предоставить доступ второму пользователю.
alexanderpas

1
Вот несколько дополнительных мыслей о ключах CD codinghorror.com/blog/2007/12/software-registration-keys.html
Ричард Чамберс,

10

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

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

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

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

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

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

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

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

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


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

3
Вместо использования RSA вы можете использовать эллиптические кривые. Они используют более короткие ключи, а их длина блока меньше. Читая вики, кажется, что 256-битный ECC так же безопасен, как AES 128.
xanatos

Обратите внимание, что цифровые подписи и «шифрование личным ключом» - это не одно и то же. В RSA они выглядят одинаково (хотя и не из-за различных схем заполнения), другие схемы подписи даже не имеют соответствующей схемы шифрования.
Пауло Эберманн

@xanatos, 256 битов все еще слишком длинны для ввода вручную. Рассмотрим 25-символьные ключи, используемые WinXP - они имеют только 128 бит энтропии.
finnw

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

9

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

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

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

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

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


1

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

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

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


1

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

«Пирату» нужно иметь доступ только к одному легитимному компакт-диску и его коду доступа, после чего он может сделать n копий и распространить их.

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

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

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


0

Вы можете очень легко использовать и реализовывать API защищенного лицензирования с ( https://www.nuget.org/packages/SystemSoulLicense/ ) в своих программных проектах, используя его (вам нужно скачать приложение для настольного компьютера для создания защищенной лицензии с https: / /www.systemsoulsoftwares.com/ ) 1. Создает уникальный UID для клиентского программного обеспечения на основе системного оборудования (ЦП, материнская плата, жесткий диск) (UID действует как закрытый ключ для этой уникальной системы). 2. Позволяет очень легко отправлять зашифрованную строку лицензии в клиентскую систему. Он проверяет строку лицензии. и работает только в этой конкретной системе 3. Этот метод позволяет разработчикам программного обеспечения или компании хранить больше информации о программном обеспечении / разработчике / услугах дистрибьютора / функциях / клиенте 4. Он обеспечивает контроль за блокировкой и разблокировкой функций программного обеспечения клиента, экономя время разработчиков создание большего количества версий для того же программного обеспечения с изменяющимися функциями 5. Он также заботится о пробной версии в течение любого количества дней 6. Он обеспечивает соблюдение срока действия лицензии путем проверки даты и времени онлайн во время регистрации 7. Он разблокирует всю информацию об оборудовании для разработчиков 8.Он имеет все предварительные и настраиваемые функции, к которым разработчик может обращаться при каждом процессе лицензирования для создания более сложного безопасного кода.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.