16.4. Защита электронных книг

Устоявшихся и хорошо себя зарекомендовавших DRM-решений, пожалуй, нет ни для одного вида цифровых произведений. Существуют эффективные методы и для обхода шифрования, применяемого для защиты содержимого DVD-дисков, и для создания незащищенных копий музыкальных композиций, распространяемых в формате WMA (Windows Media Audio) с защитой DRM версии 2.

Но рассматривать основные аспекты DRM можно на любом примере, в том числе и на примере электронных книг.

16.4.1. Adobe PDF Merchant (Adobe.WebBuy)

Как уже говорилось, в Acrobat Reader 4.0.5 появилась поддержка модуля защиты, предназначенного для работы с электронными книгами, продаваемыми через Интернет. PDF Merchant был первым модулем защиты для PDF, позволяющим работать с ключами шифрования, длина которых превышает 40 бит.

При попытке открытия защищенного документа модуль защиты выполнял следующие действия. На сервер, отвечающий за управление правами, отсылалась информация о покупке документа, к которому запрашивался доступ, и один или несколько идентификаторов вычислительной среды, таких как ID компьютера или процессора, серийный номер диска или имя пользователя. Сервер проверял, разрешен ли доступ к документу (была ли действительно на него куплена лицензия), и если все было правильно, генерировал и присылал RMF-файл. Скорее всего, RMF является аббревиатурой от Rights Management Format, во всяком случае, RMF-файл представлял собой XML-документ, в котором хранилась такая DRM-информация, как замаскированный ключ шифрования PDF-документа, перечень разрешенных операций (например печать) и сертификат для проверки подлинности лицензии.

В проверке подлинности лицензии были задействованы два 1024-битовых открытых ключа RSA. Один из этих ключей, вероятно, принадлежат издателю и использовался для проверки цифровой подписи лицензии. А второй ключ, скорее всего, принадлежащий Adobe, применялся для заверения подлинности открытого ключа издателя.

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

Несколько условий могли быть скомбинированы с помощью логических операций AND И OR ЕСЛИ все необходимые проверки выполнялись успешно, то замаскированное значение ключа шифрования документа одной из записей превращалось в ключ шифрования, который и использовался для расшифровки содержимого документа.

В целом, шифрование применялось таким образом, что создать RMF-файл без участия Adobe было практически невозможно. Но зато наличие RMF, соответствующего определенному документу, позволяло вычислить ключ шифрования без физического доступа к компьютеру, для которого был лицензирован этот документ, — проверка условий выполнялась логически (возвращалось состояние истина/ложь), но характеристики компьютера явно не участвовали в вычислении ключа шифрования. К тому же, если несколько проверок объединялись оператором AND, КЛЮЧ шифрования можно было извлечь из записи, соответствующей любой из проверок, не обязательно было выполнять их все.

Можно считать, что стойкость DRM, реализуемая в PDF Merchant, основывалась, в основном, на некоторой сложности выполняемых для получения ключа действий. Однако для построения надежного решения DRM этого явно недостаточно.

16.4.2. Adobe DRM (EBXJHANDLER)

Еще одно решение в области DRM для электронных книг, продвигаемое в настоящее время компанией Adobe, как уже упоминалось ранее, было изначально разработано для программы GlassBook Reader.

GlassBook Reader реализовывал управление правами доступа в соответствии со спецификацией протокола обмена электронными книгами (Electronic Book Exchange, ЕВХ), разрабатываемым организацией ЕВХ Workgroup.

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

Таким образом, для получения ключа шифрования документа необходим секретный ключ пользователя. Несмотря на то, что секретный ключ считается принадлежащим пользователю, сам пользователь не имеет к нему доступа — только Reader знает, как этот ключ может быть извлечен.

В GlassBook Reader существовало два пути доступа к секретному ключу пользователя. Один из путей требовал вычисления значения хэш-функции от некоторых параметров компьютера, таких как ID процессора и серийный номер диска. Разумеется, при смене оборудования результат хэш-функции изменялся и доступ к ключу становился невозможен.

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

Надежность модели DRM, реализуемой GlassBook Reader, основывалась не только на сложности получения доступа к секретному ключу пользователя. Скорее всего, разработчики полагались в некоторой степени на протектор РАСЕ InterLok, который использовался для предотвращения исследования кода Glass-Book Reader. Однако InterLok плохо спраапялся с возложенной на него задачей, что делало GlassBook Reader уязвимым для целого спектра атак на DRM.

После перехода GlassBook Reader в собственность Adobe и превращения его в Adobe eBook Reader никаких значительных технических улучшений в плане снижения уязвимости системы DRM так и не было сделано.

Однако с появлением Acrobat 6 работа с электронными книгами была перенесена в Adobe Acrobat и Adobe Reader, a Adobe eBook Reader, похоже, перестал развиваться.

16.4.3. Общая проблема с DRM для PDF

С обеспечением DRM в отношении документов в формате PDF существует еще одна сложность.

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

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

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

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

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

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

Разумеется, Adobe предприняла некоторые усилия для того, чтобы предотвратить возможность загрузки посторонних модулей расширения в тот момент, когда идет работа с книгами, защищенными DRM. Но, как было показано в разд. 2.3, самые последние версии программ семейства Acrobat продолжают загружать модули расширения, имеющие поддельную цифровую подпись, но только в "несертифицированном" режиме, в котором работа с защищенными электронными книгами невозможна.

Но после того как модуль расширения был загружен и получил управление, он может "убедить" Acrobat в том, что все загруженные модули расширения имеют правильные сертификаты, а значит, можно и открывать электронные книги.

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

16.4.4. Microsoft LIT

Еще одна независимая попытка построения рынка электронных документов была предпринята корпорацией Microsoft. Были разработаны новый формат электронных книг LIT (Literature) и бесплатная программа Microsoft Reader для просмотра представленных в нем документов.

Формат внутреннего представления данных в LIT основан на спецификации ОЕВ (Open eBook Publication Structure), разрабатываемой организацией Open еВоок Forum, к настоящему моменту объединившейся с ЕВХ Workgroup.

При разработке LIT было предложено реализовать 5 уровней защиты документа с возрастанием защищенности при переходе к следующему уровню. Однако уровень 1 (без защиты вообще) и уровень 4 (ограничено защищенный от копирования) были отброшены как бесперспективные. В результате, Microsoft Reader поддерживает документы трех степеней защиты:

Для использования книг, имеющих пятый уровень защиты (Owner-Exclusive), необходимо активировать Microsoft Reader,  привязав его к учетной записи в системе MS Passport. К одному паспорту можно привязать суммарно до 8-ми разных персональных компьютеров и устройств Pocket PC. Тогда книги, купленные с одного из этих устройств, можно будет читать с любого другого компьютера, привязанного к тому же паспорту.

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

Однако как минимум одному британскому программисту Дэну А Джексону (Dan A. Jackson) удалось разобраться с устройством средств защиты, применяемых в Microsoft Reader, и разработать программу Convert LIT, позволяющую переводить Owner-Exclusive книги в Sealed, а также извлекать все содержимое книг и сохранять его в виде набора файлов ОЕВ. Convert LIT распространяется под лицензией GPL (GNU General Public License) бесплатно и с исходными текстами.

Microsoft не стала устраивать истерии по поводу появления программы для снятия защиты с электронных книг, в результате чего инцидент прошел практически незамеченным средствами массовой информации. С тех пор было выпущено несколько обновлений Microsoft Reader, препятствующих снятию защиты, но автор Convert LIT в ответ оперативно создает новые версии своей программы.

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

Дело в том, что Microsoft при разработке LIT использовала несколько существующих технологий. Так для вычисления хэш-функции применяется модификация алгоритма SHA1, в которой 9 трансформаций из 80 были изменены. Шифрование выполняется при помощи модифицированной версии алгоритма DES. Но, самое главное, внутреннее устройство файлов LIT очень похоже на внутреннее устройство файлов СНМ (Compiled HTML Help file), применяемых для хранения справочной информации.

Но про СНМ-файлы достоверно известно, что они являются одной из реализаций структурированного хранилища, т. е. поддерживают интерфейс IS-torage. Следовательно, можно сделать вывод, что и LIT-файлы поддерживают этот интерфейс. Если противнику удастся перехватить управление в тот момент, когда все защитные механизмы отработают и Microsoft Reader будет иметь указатель на объект, соответствующий корню хранилища, снятие защиты станет тривиальным. Достаточно будет вызвать методы интерфейсов IStorage и IStream, описанные в MSDN (Microsoft Developers Network), чтобы перебрать все вложенные хранилища и потоки и сохранить их на диске в виде директорий и файлов.

16.4.5. Тенденции рынка электронных книг

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

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

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

В любом случае, 9 сентября 2003 года онлайновый книжный магазин, принадлежащий Barnes&Noble, одной из крупнейших мировых книготорговых компаний, объявил о прекращении продаж электронных книг в форматах Microsoft Reader и Adobe Reader.