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

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

Для 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. Сохраните его в нашей базе данных и распечатайте на карточке.
   
   Затем, когда кто-то вводит номер игровой карты, проверьте, находится ли он в базе данных, и, если он есть, свяжите этот номер с текущим пользователем, чтобы он никогда больше не мог быть использован.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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