10.2. Методы проверки регистрационных кодов

Все методы проверки правильности кодов можно, условно, разделить на три категории:

10.2.1. "Черный ящик"

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

При использовании "черного ящика" разработчик старается запутать алгоритм проверки, чтобы его было труднее понять и обратить. Такой подход, наверное, используется чаще всех остальных вместе взятых. Причем его применяют не только неопытные разработчики. Так, например, именно в надежде на то, что противник не сможет разобраться, что к чему, изначально строилась система лицензирования FLEXlra, разрабатываемая компанией Globetrotter, а теперь принадлежащая Macrovision. Но противник, зачастую, оказывается одареннее, упорнее и лучше подготовлен в своей профессиональной области, чем разработчик защиты. Возможно, именно поэтому на очень многие продукты, защищенные FLEXlm, в Интернете нетрудно найти поддельные лицензии. А начиная с версии 7.2, FLEXlm поддерживает лицензии на основе эллиптических кривых, поделка которых сводится к решению сложной математической задачи.

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

Правда, попытки запутать алгоритм проверки в последнее время получают научную поддержку. Так на семинаре по проблемам управления цифровыми правами DRM Workshop 2002 была представлена работа "A White-Box DES Implementation" ("Прозрачная реализация DES"), в которой предлагалась реализация DES, где ключ шифрования не фигурирует в явном виде, но является частью кода, обрабатывающего данные. То есть при смене ключа изменится код функции шифрования. Подобный подход, возможно, является перспективным, но в рамках того же DRM Workshop 2002 была представлена другая работа, в которой анализировалась White-Box DES-реализация и предлагался метод эффективной атаки, приводящей к извлечению ключа шифрования.

10.2.2. Сложная математическая задача

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

Однако у асимметричной криптографии есть одна особенность: размер блока, над которым производятся операции, довольно большой. Так, для RSA-1024 размер блока (а значит, и минимальный размер регистрационного кода) составляет 128 байт. А чтобы двоичные данные можно было ввести с клавиатуры, их кодируют, например, алгоритмом MIME64, который увеличивает размер блока на треть. То есть длина кодовой строки составит как минимум 172 символа. Очевидно, что ввести без ошибок бессмысленную последовательность такой длины, состоящую из букв, цифр и знаков препинания, почти невозможно. Это делает данную схему неприемлемой для регистрации, например, по телефону или факсу.

Делаются попытки создать стойкую систему регистрации, использующую короткие коды и основанную на сложной математической задаче. Так, компания SoftComplete Development в своем продукте HardKey System версии 2.0 (апрель 2002) использовала алгоритм, для взлома которого надо было многократно вычислить дискретный логарифм, что является сложной задачей. Существует изящный способ вычисления дискретного логарифма, который требует времени и памяти пропорционально квадратному корню из модуля. С его помощью на однопроцессорной машине с тактовой частотой 2 ГГц версия HardKey, использующая 35-битовый модуль, могла быть взломана примерно за 10 минут, а 47-битовый модуль — за сутки. Но для взлома версии, использующей 62-битовой модуль, потребовалось бы 16 Гбайт оперативной памяти, что рядовой взломщик себе вряд ли сможет позволить. Тем не менее, к ReGet Deluxe версии 3.118 RC, использовавшей именно 62-битовый модуль, группой SSG был создан генератор кодов. Правда, по непроверенной информации, вычисление дискретного логарифма не проводилось — секретный ключ якобы был похищен с сервера авторизации. Но современные оценки сложности вычисления дискретного логарифма совпадают с оценками сложности для разложения числа на простые множители, выполняемого при взломе RSA И, как известно, еще в 1999 году был факторизован 512-битовый ключ RSA, а значит, теоретически на современной технике можно вычислить и дискретный логарифм по 512-битовому модулю.

HardKey System начиная с версии 3.0 опирается на другую сложную математическую проблему — Hidden Field Equations (HFE, замаскированная система уравнений над полем), которая, на настоящий момент, очень слабо изучена, но вроде бы позволяет обеспечить достаточно высокий уровень стойкости при малом размере блока. Однако стоит заметить, что HFE является патентованной технологией во многих странах.

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

10.2.3. Табличные методы

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

Рис. 10.1. Формирование записей в таблице ключей

Рис. 10.2. Проверка регистрационного кода

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

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