<< Предыдущая

стр. 17
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

мер, программы ASProtect (ASPack Software) и EXECryptor (Soft-Complete
Development).
Определим несколько критериев, по которым можно сравнивать свойства
разных методов генерации и проверки кодов:
• возможность связать код с именем пользователя или характеристиками
компьютера;
• невозможность вычислить какой-нибудь правильный код, имея в распо-
ряжении только алгоритм проверки;
П невозможность вычислить код для определенного пользователя, зная ал-
горитм проверки и правильный код другого пользователя;
• невозможность расшифровки программы (получения ключа шифрова-
ния) при наличии заблокированного (занесенного в черный список) ре-
гистрационного кода;
• длина ключевой строки (удобство пользователя).

10.2. Методы проверки
регистрационных кодов
Все методы проверки правильности кодов можно, условно, разделить на три
категории:
• алгоритмические, основанные на принципе "черного ящика";
• алгоритмические, основанные на математически сложной задаче;
1
• табличные. 1
Глава 10. Регистрационные коды для программ 111


10.2.1. "Черный ящик"
Любые алгоритмические методы позволяют связать код с именем пользова-
теля или информацией о его компьютере, тем самым усложнив получение
нескольких копий программы, выглядящих как легальные.
При использовании "черного ящика" разработчик старается запутать алго-
ритм проверки, чтобы его было труднее понять и обратить. Такой подход,
наверное, используется чаще всех остальных вместе взятых. Причем его
применяют не только неопытные разработчики. Так, например, именно
в надежде на то, что противник не сможет разобраться, что к чему, изна-
чально строилась система лицензирования FLEXlm, разрабатываемая ком-
панией 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. Сложная математическая задача
Алгоритмические методы проверки регистрационного кода, основанные на
сложной математической задаче, не нуждаются в сокрытии деталей реализа-
ции. Их особенность в том, что для генерации кода и проверки его пра-
вильности используются два разных алгоритма и получение алгоритма
генерации из алгоритма проверки является математической задачей, не
112 Часть III. Как не надо защищать программы

имеющей на настоящее время эффективного решения. Чаще всего для этих
целей используются криптографические алгоритмы с открытым ключом.
Однако у асимметричной криптографии есть одна особенность: размер бло-
ка, над которым производятся операции, довольно большой. Так, для
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. Регистрационные коды для программ 113

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

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




Хэш + ключ
шифрования

/




/ Зашифрован- /
/ ный элемент /
/ таблицы /


Р и с . 1 0 . 1 . Формирование записей в тяйпвио i-пючей
114 Часть III, Как не надо защищать программы




•, Per. код неверен)

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


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

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


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



ивязка
осителям информации
тьно на поверхности лежит идея привязки программы к носителю ин-
щии, на котором программа доставляется пользователю. Действитель-
> прихода Интернета в жизнь рядового пользователя программы рас-
эанялись преимущественно на дискетах, затем — на компакт-дисках,
ого чтобы ограничить возможности пользователя по тиражированию
.но приобретенной программы, хорошо бы добиться того, чтобы про-
а запускалась и работала только тогда, когда пользователь вставит
:овод оригинальный диск.
л близкая по сути идея подразумевает распространение информации
^записываемых носителях и наличие на каждом оригинальном носи-
юкоторого счетчика установок. При инсталляции программы счетчик
шается до нуля, и выполнение дополнительных инсталляций стано-
невозможным. При деинсталляции счетчик снова увеличивается, что
тяет снова установить программу на другую машину.
;х случаях требуется некоторый способ создания и контроля уникаль-
носителя.



. Ключевые дискеты
змена DOS существовало несколько способов создания некопируемых
вых дискет.
из способов — использование дорожек с нестандартным размером
)а. По историческим причинам почти все перезаписываемые носители
шации на компьютерах, которые назывались IBM-совместимыми,
размер сектора, равный 512 байтам. В базовую подсистему ввода-
а (Basic Input-Output System, BIOS) были встроены возможности рабо-
:екторами других размеров, но для DOS в пределах одного диска все
за должны были иметь один и тот же размер.
118 Часть III. Как не надо защищать программы

Защита заключалась в том, что одна из дорожек, не содержащая полезных
данных, форматировалась с нестандартным размером сектора, например 128
или 256 байт, и на нее записывалась ключевая информация. Для DOS, уве-
ренной в неизменности размера сектора не протяжении всего диска, эта до-
рожка выглядела поврежденной, но программа через BIOS могла читать и
записывать на нее необходимые данные. Очевидно, что такой подход позво-
лял довольно легко повторять манипуляции на уровне BIOS и тиражировать
ключевые дискеты.
Кстати, если защита использовала счетчик инсталляций, очень часто ее
можно было обмануть с помощью простого трюка. Достаточно было пере-
хватить сервисное прерывание, отвечающее за обращение к дискам, и на все
запросы записи и форматирования дорожек дискеты возвращать статус "ус-
пешно", не выполняя никаких действий. Затем дискета защищалась от запи-
си, и запускался процесс установки. И редко какая защита после получения
информации об успешной записи уменьшенного значения счетчика прове-
ряла, действительно ли новое значение меньше предыдущего.
Схему, позволяющую восстанавливать значение счетчика при деинсталля-
ции, можно обойти и другим способом. Сразу после установки программы
необходимо сделать полную копию содержимого жесткого диска, деинстал-
лировать программу и восстановить образ диска с копии. При этом на жест-
ком диске должна оказаться работоспособная версия устаноааенной про-
граммы, а счетчик инсталляций при этом останется в исходном состоянии.
Другой способ создания некопируемых дискет заключался в нанесении фи-
зических повреждений на магнитный слой. Крупные производители исполь-
зовали для этого лазеры. А разработчики-одиночки не менее успешно дос-
тигали того же результата при помощи любого острого предмета, например
булавки.
Защита пыталась читать или писать заранее известную область диска, и если
запрос проходил без ошибки, то дискета не признавалась подлинной.
При наличии некоторой практики можно довольно точно воссоздавать по-

<< Предыдущая

стр. 17
(из 39 стр.)

ОГЛАВЛЕНИЕ

Следующая >>