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