Почти каждый разработчик или издатель коммерческого программного обеспечения (ПО) хотя бы раз задумывался об использовании в своём продукте какой-нибудь DRM-системы. При этом окончательное решение о том, стоит ли использовать DRM, принималось, в том числе, на основе анализа таких свойств системы, как её взломостойкость и поддержка требуемой бизнес-схемы распространения ПО.
Дмитрий Гусев, Протекшен Технолоджи Ресеч
Почти каждый разработчик или издатель коммерческого программного обеспечения (ПО) хотя бы раз задумывался об использовании в своём продукте какой-нибудь DRM-системы. При этом окончательное решение о том, стоит ли использовать DRM, принималось, в том числе, на основе анализа таких свойств системы, как её взломостойкость и поддержка требуемой бизнес-схемы распространения ПО. Анализ показывает, что перечисленные свойства являются сильно связанными. Рассмотрению этой связи и посвящена данная статья.
Прежде чем говорить о взломостойкости, рассмотрим бизнес-задачи DRM-системы, предназначенной для продажи автономно работающего ПО [1]. Основные из этих задач перечислены в таблице 1. Приведённый список не является исчерпывающим, но другие задачи либо являются специфичными для конкретной системы (например, борьба с недобросовестностью партнёров по распространению ПО), либо неинтересны с точки зрения взломостойкости (например, сбор статистики по продажам), поэтому в таблицу не включены.
Таблица 1. Бизнес-задачи DRM-системы
Задача |
Угрозы, которым должна противостоять DRM-система при решении задачи |
Примечание |
Организация платежей |
Кража платёжных данных |
- |
Защита от нелегального распространения |
Устранение кода DRM-системы из приложения, эмуляция объекта привязки, генератор ключей |
Под защитой от копирования здесь понимается обеспечение технической невозможности запуска приложения без приобретения лицензии |
Ограничение времени использования приложения |
Продление времени, сброс счётчика |
Лицензия может ограничивать календарный период использования приложения, число запусков, суммарное время работы приложения. |
Ограничение функционала приложения |
Расширение функционала |
- |
Предоставление пользователю пробного периода использования приложения |
Продление времени, сброс счётчика |
Пробный период подразумевает возможность бесплатно использовать приложение в течение ограниченного времени. |
Предоставление пользователю демонстрационного режима использования приложения |
Расширение функционала |
Демонстрационный режим характеризуется ограниченным функционалом при неограниченном времени использования. |
Организация продаж дополнительного контента |
Использование нелегально приобретённого контента |
Пример решения этой задачи – продажа предметов виртуального мира в компьютерных играх. |
Защита от анализа и модификации |
Анализ и модификация кода DRM-системы с целью изменить логику её работы |
Пример реализации описанной угрозы – преодоление защиты от копирования путём внесения таких изменений в код DRM-системы, которые отключали бы соответствующие проверки |
Сами действия по переводу денег в процессе покупки реализуется вне DRM-системы теми же методами, которые используются для обычной покупки через интернет. DRM-система, тем не менее, часто предоставляет возможности по интеграции с платёжными системами и отслеживания факта покупки. Поэтому при использовании DRM-системы необходимо убедиться, что интеграция произведена правильно и в её результате не образовалось «слабых мест».
Типовым подходом к решению задачи является внедрение в приложение некоторого кода DRM-системы, который бы обеспечивал неработоспособность приложения без наличия некоторого трудно копируемого внешнего по отношению к приложению объекта (объект привязки). Внедряемый код DRM-системы должен быть хорошо связан с приложением, чтобы его сложно было бы удалить или заблокировать.
Можно выделить следующие способы организации привязки:
Более детальное описание наиболее типичных объектов привязки приведено в таблице 2.
Таблица 2. Типичные объекты привязки.
Объект привязки |
Описание |
Уязвимости |
Компьютер |
Привязка производится к программно доступным идентификаторам и параметрам моделей элементов оборудования и ПО. Типичные примеры: модель процессора, объём памяти, MAC-адреса. |
Возможность создания генератора ключа, если для его создания не используется криптография с открытым ключом. Несмотря на очевидность данной угрозы, многие производители систем DRM отказываются от применения криптографии с открытым ключом из-за большой длины ключа и упрощения атаки методом модификации кода DRM (типовые алгоритмы трудно защитить от анализа и модификации). |
Возможность программной эмуляции большинства параметров оборудования. | ||
Компакт-диск |
Привязка производится к физической геометрии расположения секторов, к логической геометрии расположения секторов, наличию искусственно созданных нечитаемых областей. |
Возможность создания генератора ключа, если не используется криптография с открытым ключом (аналогично ситуации с привязкой к оборудованию). |
Возможность копирования диска путём повторения уникальных параметров. Особенно это относится к нечитаемым областям и логической геометрии расположения секторов. | ||
Возможность создания эмулятора. Данная уязвимость является самой серьёзной для привязки данного типа на платформе PC. | ||
USB-ключ |
Отличительная особенность – сравнительно высокая цена одного ключа, не позволяющая использовать данное решение в дешёвом ПО. |
Возможность создания эмулятора путём взлома и восстановления программы микроконтроллера, используемого в ключе. Также сюда относится возможность изменения данных о лицензии в памяти микроконтроллера. Случаи использования данной уязвимости очень редки. Некоторые производители ключей предлагают штатные средства их эмуляции для целей отладки. Анализ таких средств также может помочь злоумышленнику. |
Возможность создания эмулятора путём анализа протокола обмена данными между защищённым приложением и ключом. Теоретически в ключе можно реализовать сколь угодно сложный код, что сделало бы данную уязвимость несущественной, однако на практике очень часто встречается плохая проработка данного вопроса (как разработчиками систем DRM, так и программистами, осуществляющими интеграцию системы DRM с приложением), что делает данную уязвимость наиболее важной. | ||
Удалённый сервер |
Аналогично активным объектам привязки, за исключением того, что в качестве объекта привязки выступает удалённый сервер. Отличительная особенность – необходимость подключения к интернету при каждом запуске или в течение всей работы защищённого приложения. |
Возможность создания эмулятора путём анализа протокола (аналогично ситуации с активными объектами привязки). |
В целом следует отметить, что в настоящее время все перечисленные объекты привязки (с оговорками даже и компакт-диск) позволяют получить удовлетворительную взломостойкость, однако наиболее надёжными является всё же удалённый сервер.
Второй аспект защиты от нелегального распространения – создание трудноустранимой связи внедряемого кода DRM-системы с приложением – решается производителями DRM-систем по-разному. Здесь важно заметить следующее:
В случае использования привязки к серверу данная задача решается тривиально. Аналогично дело обстоит и с активными объектами привязки (тут, правда, появляется уязвимость, связанная с возможностью модификации лицензии в памяти объекта привязки и нарушения работы внутренних часов объекта привязки, однако и в этом случае достижение высокого уровня взломостойкости не является проблемой).
В случае же использования пассивного объекта привязки приходится использовать менее надёжные решения:
Таблица 3. Технические решения задач, связанных с ограничением времени работы приложения при использовании пассивных объектов привязки
Задача |
Решение |
Уязвимости |
Сохранение информации о начале пробного периода |
Хранение скрытой информации на компьютере конечного пользователя (как правило, на жёстком диске). |
Возможность обнаружения и удаления скрытой информации |
Сохранение информации о потраченном количестве запусков и потраченном суммарном времени работы приложения |
То же. |
То же. |
Определение текущего времени |
Использование системных часов компьютера конечного пользователя |
Перевод часов назад. Частично проблему перевода часов удаётся решить сохранением скрытой информации о времени последнего запуска, но эту информацию можно удалить. |
Использование удалённых серверов для сохранения информации об использовании лицензии или о текущем времени не используется, т.к. при этом исчезает главное преимущество пассивных объектов привязки перед привязкой к серверу: возможность работы без подключения к интернету.
Если функционал защищаемого приложения, который нужно предоставлять опционально (только в полной версии или за отдельную плату), обширен и хорошо локализован в виде отдельных функций, то теоретически его можно защитить столь же хорошо, как и основное приложение. Действительно, обширный и отделимый от приложения функционал можно рассматривать как отдельное независимое приложение. При этом задача ограничения функционала сводится просто к защите ещё одного приложения.
На практике же достижению хорошей взломостойкости могут препятствовать 2 причины:
Хотя задача ограничения использования контента внешне похожа на рассмотренную выше задачу ограничения функционала, качество решения этой задаче в плане взломостойкости обычно получается хуже. Действительно, решение об использовании того или иного файла данных обычно принимается в одной точке программы, тогда как в случае ограничения функционала проверку объекта привязки можно осуществить во многих точках. Это облегчает злоумышленнику взлом путём модификации кода DRM-системы.
Любой взлом DRM-системы предполагает осуществления злоумышленником анализа работы её программного кода. Модификация не является обязательным элементом взлома, так как иногда при анализе злоумышленнику удаётся найти уязвимость системы, с помощью которой механизмы защиты могут быть преодолены без модификации. Характерный пример взлома такого рода – создание генератора ключей.
Решение задач защиты от анализа и модификации обычно является основным ноу-хау DRM-систем, хотя до сих пор не существует идеальных решений: со временем для всех методов защиты появляются средства преодоления. Тем не менее, своевременное обновление решений может обеспечить системам DRM хороший уровень взломостойкости.
Основными подходами к защите от анализа являются:
Защита от модификации обычно подразумевает вычисление контрольных сумм (в широком смысле) участков кода и проверку их неизменности.
Взломостойкость любой системы DRM не является фиксированным параметром, а зависит от многих факторов. Вот наиболее типичные причины ухудшения взломостойкости:
Для того чтобы защита была надежной и совместимой необходимо начать задумываться о ее установке заранее, 2-3 месяца до релиза программы. Производители DRM систем накопили значительный опыт, поэтому хорошим советом для правообладателей, желающих надежно защитить свою интеллектуальную собственность, станет совет всегда консультироваться с производителем и не пренебрегать его указаниями.