Взломостойкость DRM-систем и её связь с бизнес-схемами распространения программного обеспечения

Взломостойкость DRM-систем и её связь с бизнес-схемами распространения программного обеспечения

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

Дмитрий Гусев, Протекшен Технолоджи Ресеч

Введение

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

Задачи DRM-системы, используемой для распространения ПО

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

Таблица 1. Бизнес-задачи DRM-системы

Задача

Угрозы, которым должна противостоять DRM-система при решении задачи

Примечание

Организация платежей

Кража платёжных данных

-

Защита от нелегального распространения

Устранение кода DRM-системы из приложения, эмуляция объекта привязки, генератор ключей

Под защитой от копирования здесь понимается обеспечение технической невозможности запуска приложения без приобретения лицензии

Ограничение времени использования приложения

Продление времени, сброс счётчика

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

Ограничение функционала приложения

Расширение функционала

-

Предоставление пользователю пробного периода использования приложения

Продление времени, сброс счётчика

Пробный период подразумевает возможность бесплатно использовать приложение в течение ограниченного времени.

Предоставление пользователю демонстрационного режима использования приложения

Расширение функционала

Демонстрационный режим характеризуется ограниченным функционалом при неограниченном времени использования.

Организация продаж дополнительного контента

Использование нелегально приобретённого контента

Пример решения этой задачи – продажа предметов виртуального мира в компьютерных играх.

Защита от анализа и модификации

Анализ и модификация кода DRM-системы с целью изменить логику её работы

Пример реализации описанной угрозы – преодоление защиты от копирования путём внесения таких изменений в код DRM-системы, которые отключали бы соответствующие проверки

Техническое решение задач DRM-системы

Организация платежей

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

Защита от нелегального распространения

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

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

  1. Привязка приложения к пассивному внешнему объекту, обладающему какими-либо уникальными параметрами. Самые распространённые пассивные объекты привязки – это компьютер конечного пользователя и компакт-диск, на котором поставляется приложения. Привязка осуществляется выдачей конечному пользователю активационного ключа, соответствующему уникальным параметрам объекта привязки.
  2. Привязка приложения к активному внешнему объекту, такому как электронный ключ или смарт-карта. Активный объект привязки содержит вычислительный блок, реализующий часть операций, необходимых для функционирования приложения.
  3. Привязка приложения к аккаунту конечного пользователя на удалённом сервере (привязка к серверу).

Более детальное описание наиболее типичных объектов привязки приведено в таблице 2.

Таблица 2. Типичные объекты привязки.

Объект привязки

Описание

Уязвимости

Компьютер

Привязка производится к программно доступным идентификаторам и параметрам моделей элементов оборудования и ПО. Типичные примеры: модель процессора, объём памяти, MAC-адреса.

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

Возможность программной эмуляции большинства параметров оборудования.

Компакт-диск

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

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

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

Возможность создания эмулятора. Данная уязвимость является самой серьёзной для привязки данного типа на платформе PC.

USB-ключ

Отличительная особенность – сравнительно высокая цена одного ключа, не позволяющая использовать данное решение в дешёвом ПО.

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

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

Удалённый сервер

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

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

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

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

Второй аспект защиты от нелегального распространения – создание трудноустранимой связи внедряемого кода DRM-системы с приложением – решается производителями DRM-систем по-разному. Здесь важно заметить следующее:

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

Ограничение времени использования и пробный период

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

В случае же использования пассивного объекта привязки приходится использовать менее надёжные решения:

Таблица 3. Технические решения задач, связанных с ограничением времени работы приложения при использовании пассивных объектов привязки

Задача

Решение

Уязвимости

Сохранение информации о начале пробного периода

Хранение скрытой информации на компьютере конечного пользователя (как правило, на жёстком диске).

Возможность обнаружения и удаления скрытой информации

Сохранение информации о потраченном количестве запусков и потраченном суммарном времени работы приложения

То же.

То же.

Определение текущего времени

Использование системных часов компьютера конечного пользователя

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

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

Ограничение функционала и демонстрационный режим

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

На практике же достижению хорошей взломостойкости могут препятствовать 2 причины:

  1. Недостаточная проработка вопросов взломостойкости при ограничении функционала авторами DRM-системы, которые рассматривают данную задачу как вспомогательную.
  2. Недостаточное обособление функционала разработчиками защищённого приложения.

Продажи дополнительного контента

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

Защита от анализа и модификации

Любой взлом DRM-системы предполагает осуществления злоумышленником анализа работы её программного кода. Модификация не является обязательным элементом взлома, так как иногда при анализе злоумышленнику удаётся найти уязвимость системы, с помощью которой механизмы защиты могут быть преодолены без модификации. Характерный пример взлома такого рода – создание генератора ключей.

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

Основными подходами к защите от анализа являются:

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

Защита от модификации обычно подразумевает вычисление контрольных сумм (в широком смысле) участков кода и проверку их неизменности.

Заключение

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

  1. Несоблюдение рекомендаций производителя DRM-системы по достижению высокого уровня взломостойкости, в том числе по интеграции защищённого приложения с активным объектом привязки или с удалённым сервером.
  2. Использование пробного периода в случае использования DRM-систем с привязкой к оборудованию или компакт-диску.
  3. Использование демонстрационного режима при недостаточном программном обособлении платного функционала.

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


[1] Если ПО устроено так, что часть его функционала выполняется на удалённых серверах, задача по защите от копирования обычно не возникают, но вместо них появляются другие специфические задачи, такие как, защита от нарушения игрового баланса в многопользовательских играх с помощью программ-читеров. Рассмотрение DRM-систем для данного типа ПО выходит за рамки данной статьи. 

Ваша приватность умирает красиво, но мы можем спасти её.

Присоединяйтесь к нам!