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

" ); wnd.document.close(); wnd.focus(); }

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Второй аспект защиты от нелегального распространения – создание трудноустранимой связи внедряемого кода 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-систем для данного типа ПО выходит за рамки данной статьи. 

18 октября, 2012

Местные провайдеры на один день заблокировали доступ ко всем ресурсам, содержащим слово ubuntu.

15 октября, 2012

Помимо темы жестких дисков, Торвальдс указал на правовые излишества в сфере патентов.

22 октября, 2012

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

19 октября, 2012

Госдума должна рассмотреть ряд законопроектов, устанавливающих лимит на хранение в Сети пользовательских...

16 октября, 2012

В результате мошеннической деятельности пострадавшему был нанесен ущерб в размере 7,7 млн руб.

18 октября, 2012

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

19 октября, 2012

Великобритания набирает 18-летних любителей видеоигр для защиты компьютерных систем страны.

18 октября, 2012

По мнению правообладателей, социальная сеть распространяет определенный контент, не имея на это их согласия.

19 октября, 2012

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

19 октября, 2012

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

22 октября, 2012

---

19 октября, 2012

---

17 октября, 2012

---

15 октября, 2012

---

12 октября, 2012

• Комментарии