К аппаратным средствам защиты относятся различные электронные, электронно-механические, электронно-оптические устройства. К настоящему времени разработано значительное число аппаратных средств различного назначения, однако наибольшее распространение получают следующие:
2.1. Аппаратные ключи защиты
Уже много лет на рынке средств защиты программ от несанкционированного тиражирования присутствуют так называемые аппаратные ключи защиты (Dongles). Разумеется, компании, продающие такие устройства, представляют их если не как панацею, то уж как надежное средство противодействия компьютерному пиратству. Но насколько серьезным препятствием могут служить аппаратные ключи?Аппаратные ключи защиты можно пытаться классифицировать по нескольким признакам.
Если рассматривать возможные типы подключения, то бывают, например, ключи на порт принтера (LPT), последовательный порт (СОМ), USB-порт и ключи, подключаемые к специальной плате, вставляемой внутрь компьютера.
Можно при сравнении ключей анализировать удобство и функциональность сопутствующего программного обеспечения. Например, для некоторых семейств аппаратных ключей разработаны автоматические протекторы, позволяющие защитить программу "за один клик", а для некоторых такие протекторы отсутствуют. Определенный интерес представляет список языков программирования, для которых разработчик ключей предоставил библиотеки и примеры. Поддержка языков (доступ к API ключа из определенной среды) нужна для того, чтобы программист смог более эффективно использовать ключ для защиты разрабатываемой программы. Важен также список аппаратных платформ и операционных систем, для которых поддерживается интерфейс с ключом. Некоторых может заинтересовать применимость ключа для сетевого лицензирования программного обеспечения.[4]
Однако все сказанное о ключах относится скорее к маркетингу, чем к защите информации. Для защиты не важно, какого цвета корпус у ключа и на каком языке можно читать документацию. А по-настоящему важно только то, что в ключе является секретным и неповторимым и способно ли это "нечто" обеспечить необходимым уровень защиты.
Поэтому в дальнейшем ключи рассматриваются исключительно как аппаратные устройства, работающие в определенных условиях и имеющие некоторую функциональность. Полезными признаются только те функции, которые невозможно реализовать чисто программными средствами и для которых не существует эффективной атаки.
Будем исходить из предположения, что у противника есть физический доступ к ключу, а основная задача заключается в том, чтобы за разумное время получить копию программы, функционирующую в отсутствие ключа точно так же, как при его наличии.
Рассматривать атаки на систему, в которой не хватает некоторых узлов необходимых для работы, особого смысла нет - если зашифровать программу и не сообщить противнику ключ шифрования, легко получить высокую стойкость и без применения аппаратных ключей. Только это уже нельзя называть защитой от копирования.
Модификация кода и эмуляция
Для того чтобы заставить программу работать так, как она работала бы с ключом, можно или внести исправления в программу, или эмулировать наличие ключа. Модификация программы, как правило, возможна лишь в тех случаях, когда ответы, полученные от ключа, просто проверяются, но не являются математически необходимыми для обеспечения работоспособности программы. Но это значит, что ключ, по большому счету, не требуется для достижения полной функциональности. Такое случается, когда программа не использует всех возможностей ключа или когда возможности ключа очень ограничены.
При эмуляции никакого воздействия на программу не происходит, т.е., например, не нарушается контрольная сумма исполняемых модулей. И полный эмулятор, если его удается построить, просто повторяет все поведение реального ключа.
Не вдаваясь очень глубоко в технические подробности, будем исходить из предположения, что у противника есть следующие возможности:
• Перехватывать все обращения к ключу;
• Протоколировать и анализировать эти обращения;
• Посылать запросы к ключу;
• Получать ответы от ключа;
• Протоколировать и анализировать эти ответы;
• Посылать ответы от имени ключа.
Такие широкие возможности противника можно объяснить тем, что в его распоряжении есть вся та информация, какая есть и у программиста, защищающего программу с помощью аппаратного ключа. То есть противник имеет доступ ко всем открытым интерфейсам, документации, драйверам и может их анализировать на практике с привлечением любых средств. Следовательно, можно предположить, что противник со временем научится полностью контролировать протокол, по которому происходит обмен информацией между прикладной программой и ключом. Контроль может осуществляться на любом уровне, но чаще всего запросы перехватываются при передаче данных между программой и драйвером ключа.
Однако стоит учитывать, что возможность эмуляции еще не означает, что противник способен вычислять правильные ответы на любые запросы, которые посылает ключу программа.
Ключи с памятью.Это, наверное, самый простой тип ключей. Ключи с памятью имеют определенное число ячеек, из которых разрешено считывание. В некоторые из этих ячеек также может производиться запись. Обычно в ячейках, недоступных для записи, хранится уникальный идентификатор ключа.
Когда-то давно существовали ключи, в которых перезаписываемой памяти не было вообще, а программисту для считывания был доступен только идентификатор ключа. Но очевидно, что на ключах с такой функциональностью построить серьезную защиту просто невозможно.
Правда, и ключи с памятью не способны противостоять эмуляции. Достаточно один раз прочитать всю память и сохранить ее в эмуляторе. После этого правильно эмулировать ответы на все запросы к ключу не составит большого труда.
Таким образом, аппаратные ключи с памятью в заданных условиях не способны дать никаких преимуществ по сравнению с чисто программными системами.
Ключи с неизвестным алгоритмом.Многие современные аппаратные ключи содержат секретную функцию преобразования данных, на которой и основывается секретность ключа. Иногда программисту предоставляется возможность выбрать константы, являющиеся параметрами преобразования, но сам алгоритм остается неизвестным.
Проверка наличия ключа должна выполняться следующим образом. При разработке защиты программист делает несколько запросов к алгоритму и запоминает полученные ответы. Эти ответы в какой-то форме кодируются в программе. Во время выполнения программа повторяет те же запросы и сравнивает полученные ответы с сохраненными значениями. Если обнаруживается несовпадение, значит, программа получает ответ не от оригинального ключа.
Эта схема имеет один существенный недостаток. Так как защищенная программа имеет конечный размер, то количество правильных ответов, которые она может хранить, также является конечным. А это значит, что существует возможность построения табличного эмулятора, который будет знать правильные ответы на все запросы, результат которых может проверить программа.[5]
В рекомендациях по защите программ с помощью аппаратных ключей даются советы, как сделать фиктивные запросы со случайными данными так, чтобы затруднить построение эмулятора. Однако если программа при запуске делает 100 запросов, результат которых может быть проверен, и 100 случайных запросов, результат которых не проверяется, то, запустив программу 10 раз, очень легко выделить действительные запросы, повторившиеся 10 раз, и отсечь все фиктивные, встретившиеся по 1-2 раза.
Конечно, не стоит всегда проверять наличие ключа выполнением одной и той же серии запросов с проверкой. Лучше выполнять проверки в разных частях программы и в разное время. Это может значительно усложнить сбор статистики для отсечения фиктивных запросов.
Но не стоит забывать, что противник может проанализировать программу и попытаться в дизассемблере найти все обращения к ключу. Это поможет ему выяснить, ответы на какие из запросов проверяются, и построить компактную таблицу для эмуляции. Так что ключи с неизвестным алгоритмом могут затруднить, но не могут предотвратить построение эмулятора для конкретной версии конкретной программы. Зато при переходе к новой версии, если перечень проверки программой ответов на запросы будет изменен, противнику придется заново выполнять сбор статистики или анализ программы.
Атрибуты алгоритмов.В некоторых ключах алгоритму могут сопутствовать дополнительные атрибуты. Так, например, в ключах Sentinel SuperPro алгоритм может быть защищен паролем и начинает работать только после того, как будет выполнена активация, в ходе которой правильный пароль должен быть передан ключу.
Активация позволяет разработчику предусмотреть возможность изменения функциональности ключа на стороне пользователя. То есть программа может иметь несколько версий (например базовую, расширенную и профессиональную), и в ключе изначально активированы только те алгоритмы, которые необходимы для функционирования базовой версии. Если пользователь решит перейти к более полной версии, разработчик пришлет ему инструкции по активации алгоритмов, соответствующих расширенной или профессиональной версии.
Однако все достоинства алгоритмов, активируемых по паролю, опираются на секретность пароля, а не на свойствах аппаратного ключа. Следовательно, аналогичная защита может быть реализована чисто программными средствами. Другой тип атрибутов алгоритмов, поддерживаемых ключами Sentinel SuperPro, - это счетчики. С активным алгоритмом может быть связан счетчик, изначально имеющий ненулевое значение. Программа при каждом запуске (или выполнении определенной операции, например при экспорте данных) вызывает специальную функцию API-ключа, уменьшающую значение счетчика на единицу. Как только счетчик принимает нулевое значение, алгоритм деактивируется и перестает работать.
Однако данная схема не способна помешать применению эмулятора. Противник может перехватывать и предотвращать все попытки уменьшения значения счетчика. Следовательно, алгоритм никогда не будет деактивирован, и в распоряжении противника будет неограниченное время для сбора данных, необходимых для табличной эмуляции.
Противостоять эмуляции может счетчик, значения которого уменьшается при каждом обращении к алгоритму. Но в этом случае возникает опасность, что из-за сбоев в работе программы или операционной системы иногда значение счетчика будет уменьшаться без совершения программой полезных действий. Причина проблемы в том, что обращение к алгоритму должно производиться до того, как программа совершит полезную работу, а счетчик должен уменьшаться только в том случае, если работа выполнена успешно. Но автоматическое уменьшение счетчика при обращении к алгоритму такую функциональность не обеспечивает - количество оставшихся попыток уменьшается независимо от успеха выполнения операции.