Программирование средства внедрения и анализа водяных знаков в исходные тексты программ

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

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

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

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

Защита  от модификации кода программы

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

а) обнаружить, что программа была модифицирована,

б) если это возможно, исправить обнаруженные изменения, в противном случае обеспечить аварийное завершение программы, 

      В идеальном случае обнаружение изменения в коде и соответствующее этому обнаружению аварийное завершение программы должны быть широко распределены во времени и коде программы, чтобы запутать потенциального атакующего. Очевидно, что код if (tampered()) i = 1 / 0 не обеспечивает достаточной защиты в связи с возможностью тривиального обнаружения и устранения.

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

1. исследовать исполняемый код программы и проверить, совпадает ли он с оригинальным. Для этого можно использовать некоторую одностороннюю хэш-функцию (напр., SHA1). Проверять можно не весь код, а только части, для которых неизменность является критичной. Один из вариантов таких проверок приводился в разделе, посвященном шифрованию программного кода;
2. исследовать правильность промежуточных результатов, получаемых в программе. Этот подход известен как проверка программы (program verification). Кроме рассматриваемых целей, этот метод также может использоваться для верификации/ тестирования программы на этапе разработки и является самым применяемым для решения задачи обнаружения изменений в программе.

      Для проверки приложения на неизменность предлагается использовать множество объектов – троек <тестер, интервал, корректор>. Тестером называется подпрограмма, вычисляющая хэш-функцию от некоторого интервала (участка кода) программы и сравнивающая его с оригиналом. В процессе выполнения тестеры запускаются и проверяют правильность интервала, за который они отвечают, путем сравнения оригинального значения хэш-функции и действительного. В случае, если значения не совпадают, программа через некоторое время аварийно завершается. Корректоры необходимы для безопасного хранения оригинальных значений хэш-функции. Корректоры могут быть как константами (т.е. просто массивом байт), так и подпрограммами, конструирующими оригинальное значение. Очевидно, второй подход обеспечивает большую защиту.

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

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

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

      Один  из таких методов называется забывчивым хэшированием (oblivious hashing). В качестве объекта проверки предлагается использовать не бинарный код, а след выполнения программы (функции, участка программы и т.п.). Программа (функция, участок) представляется в виде последовательности абстрактных машинных инструкций I={i₁, i₂, …, i_N}, которые обращаются для чтения и записи к участкам памяти M={m₁, m₂, …, m_K}, начального состояния памяти M₀, счетчика инструкций C и его начального значения C₀. Следом некоторого участка программы называется пятерка (I, M, C₀, M₀, P), где P – некоторый входной параметр, который влияет на выполнение участка программы. В процессе выполнения участка программы вычисляется хэш-функция от его следа. Поскольку след отражает семантику участка программы, полученное значение хэш-функции по сути является цифровой подписью, выполненной над поведением этого участка. Изменение как кода, так и данных, с которыми оперирует участок, приведет к несовпадению полученного при проверке значения хэш-функции с оригинальным значением, что позволит определить наличие изменений в программе.

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

Лицензионные  метки

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

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

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

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

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

      Следует отметить, что лицензионной меткой не обязательно должен являться числовой регистрационный ключ. Так, в этом качестве можно использовать часть функциональности продукта. Например, меткой может быть динамически подключаемая библиотека (DLL), содержащая в себе, кроме лицензионных данных, некоторую функциональность, необходимую для корректной работы продукта. Такой подход обладает двумя положительными качествами – во-первых, его применение сделает невозможным создание генератора ключей, так как атакующий не обладает исходным кодом для сборки библиотек, во-вторых, атакующий не может применить атаку на обнаружение проверочного кода ввиду ее бессмысленности. [3]

Создание  защищенной среды  выполнения

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

     Можно выделить основные задачи, которые будут возложены на защищенную среду выполнения:

• проверка целостности программного кода;
• запрещение доступа к адресному пространству программы;
• контроль за выполнением программы, отслеживание необычных и ошибочных ситуаций;
• обеспечение шифрования программного кода;
• проверка наличия у пользователя права на выполнение конкретной копии программы. [3]

Альтернативные  подходы к защите программного обеспечения

     Кроме описанных выше методов защиты клиентского ПО, можно отметить несколько альтернативных подходов к его безопасности. Метод, который можно назвать эволюционированием продукта (software aging). Этот метод основывается на периодических обновлениях ПО. Несмотря на кажущуюся бессмысленность, он оказался достаточно хорошей защитой от нелицензионного использования ПО. Суть его заключается в том, что производитель ПО через некоторые, сравнительно небольшие  интервалы времени (один-два месяца), обновляет продукт, немного изменив метод защиты. Пользователям, обладающим легальной версией, необходимо просто ее обновить. Пользователи же, использующие нелегальную версию, должны ждать, пока взломщик вскроет обновленную версию. Таким образом, нелегальные пользователи становятся зависимыми от взломщика, у которого появляется несравнимо больше обязанностей – теперь ему нужно взламывать новую версию продукта каждый месяц. Задача усложняется, если от версии к версии производитель серьезно изменяет защиту продукта. Важность взлома очередной версии для нелегального пользователя тем больше, чем больше очередная версия продукта несовместима с предыдущей. [3]

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