УПРАВЛЕНИЕ ЦИФРОВЫМИ ПРАВАМИ С ИСПОЛЬЗОВАНИЕМ МЕТОДИК ДОВЕРИТЕЛЬНОЙ ОБРАБОТКИ

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

DRM OMA является системой DRM, заданной альянсом OMA, консорциумом производителей мобильных телефонов и устройств и поставщиков мобильных услуг. Схема реализуется на многих мобильных телефонах и предназначена для использования поставщиками мобильного контента, чтобы добавлять DRM в свои продукты и услуги. Выпущено две версии DRM OMA: DRM 1.0 OMA и DRM 2.0 OMA.

DRM 1.0 OMA предназначена для схем для базового управления цифровыми правами для объектов контента. По существу, она не обеспечивает сильной защиты либо для объектов контента, либо для объектов прав. DRM 1.0 OMA устанавливает три способа доставки: Forward Lock (Запрет пересылки, который предотвращает пересылку пользователями контента пользователям или устройствам), Combined Delivery (Комбинированная доставка, объединенные объект прав и медиа-объект) и Separate Delivery (Раздельная доставка, отдельные объект прав и медиа-объект). DRM 1.0 OMA была спроектирована для обработки небольших медиа-объектов, таких как мелодии звонков (рингтоны) или фоновые изображения ("обои") для телефонов.

DRM 2.0 OMA улучшает и расширяет механизм доставки DRM 1.0 OMA. Устройство, совместимое с DRM 2.0 OMA, обладает индивидуальным сертификатом на основе инфраструктуры открытых ключей (PKI) DRM, то есть у каждого устройства есть открытый ключ, соответствующий личному ключу, и сертификат, подтверждающий данный факт. Каждый объект прав (RO) защищается как для конфиденциальности (с помощью шифрования), так и для целостности (с помощью цифровых подписей). Использование PKI, шифрования, и проверки целостности усиливает безопасность системы DRM 2.0 OMA по сравнению с безопасностью системы DRM 1.0 OMA.

DRM 2.0 OMA также определяет множество протоколов, которые вместе называются Протоколом получения объектов прав (ROAP), который содержит различные подпротоколы, относящиеся к взаимной аутентификации и регистрации между устройством и эмитентом прав (RI), запросу RO, ответу на доставку RO или отказу доставить RO, и присоединению и выходу устройства из доменов. Нижеследующие являются некоторыми из основных объектов, определенных в DRM OMA:

Действующий субъект - внешний объект, который выполняет сценарии использования.

Резервирование/удаленное хранение - пересылка RO и объектов контента (CO) в другое место с намерением передачи их обратно на исходное устройство.

Комбинированная доставка - способ DRM 1.0 OMA для доставки защищенного контента и RO. RO и защищенный контент доставляются вместе в одном объекте, сообщении DRM.

Конфиденциальность - свойство, что информация не станет доступной или раскрытой неуполномоченным людям, сущностям или процессам.

Составной объект - CO, содержащий один или более медиа-объектов посредством включения.

Связанное устройство - устройство, которое способно непосредственно соединяться с RI, используя подходящий протокол по подходящему глобальному интерфейсу транспортного/сетевого уровня.

Контент - один или более медиа-объектов.

Эмитент контента (CI) - объект, делающий контент доступным агенту DRM.

Поставщик контента - объект, который является либо CI или RI.

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

Аннулирование устройства - процесс RI, указывающий, что устройство уже не является надежным, чтобы получать RO.

RO устройства - RO, выделенный для конкретного устройства посредством открытого ключа устройства.

Домен - множество устройств, которые имеют возможность совместно использовать RO домена. Устройства в домене совместно используют ключ домена. Домен определяется и управляется с помощью RI.

Идентификатор домена - уникальный строковый идентификатор ключа домена.

Ключ домена - ключ 128-разрядного симметричного шифра.

Агент DRM - объект в устройстве, который управляет разрешениями для медиа-объектов на этом устройстве.

Контент DRM - медиа-объекты, которые используются согласно набору разрешений в RO.

Время DRM - защищенный, не изменяемый пользователем источник времени. Время DRM находится в формате времени UTC (всеобщее скоординированное время).

Целостность - свойство, которое указывает, что данные не изменены или разрушены несанкционированным способом.

Присоединение к домену - процесс, в котором RI включает устройства в домен.

Выход (отсоединение) из домена - процесс, в котором RI исключает неаннулированное устройство из домена.

Медиа-объект - цифровое произведение или составной объект.

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

Разрешение - фактические использования или действия, разрешенные RI над контентом DRM.

Воспроизвести - создать кратковременное, воспринимаемое представление ресурса.

Защищенный контент - медиа-объекты, которые используются согласно набору разрешений в RO.

Восстановление - перемещение защищенного контента и/или RO из внешнего расположения обратно в устройство, из которого они быть резервированы.

Аннулирование - процесс объявления устройства или сертификата RI как недействительного.

Эмитент прав (RI) - объект, который выпускает (эмитирует) RO для совместимых с DRM OMA устройств.

Контекст RI - информация, которая была согласована с данным RI во время 4-проходного Протокола регистрации, например идентификатор (ID) RI, цепочка сертификатов RI, версия, алгоритмы и другая информация. Контекст RI необходим для устройства, чтобы успешно принимать участие во всех протоколах из набора ROAP, за исключением Протокола регистрации.

Объект прав (RO) - совокупность разрешений и других атрибутов, которые привязаны к защищенному контенту.

Протокол получения объектов прав (ROAP) - протокол, который дает возможность устройствам запрашивать и получать RO от RI.

Триггер ROAP - документ на расширяемом языке разметки (XML), включающий в себя URL, который при его приеме устройством запускает ROAP.

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

Права с сохранением состояния - RO, для которых устройство должно явно сохранять информацию о состоянии, так что ограничения и разрешения, выраженные в RO, могут правильно приводиться в исполнение. RO, содержащий любое из следующих ограничений или разрешений, расценивается как Права с сохранением состояния: <interval>, <count>, <timed-count>, <datetime>, <accumulated> или <export>.

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

Несвязанное устройство - устройство, которое способно соединяться с RI через связанное устройство, используя подходящий протокол, по технологии локального установления связи, например OBEX по IrDA (обмен объектами по ИК-связи), Bluetooth или универсальная последовательная шина (USB). Несвязанное устройство может поддерживать время DRM.

Пользователь - пользователь устройства. Пользователь не обязательно владеет устройством.

Фиг.1 является общим представлением о существующий функциональной архитектуре 100 DRM 2.0 OMA. Архитектура 100 состоит из системы 102 DRM, поставщика 104 контента и пользователя 106. Система 102 DRM включает в себя CI 110, RI 112, агентов 114 DRM, сетевое хранилище 116 и съемный носитель 118. CI 110 распространяет защищенный контент 122, а RI 112 распространяет RO 124. Агенты 114 DRM перераспределяют защищенный контент 122.

CI 110 является объектом, который доставляет контент 122 DRM. DRM OMA определяет формата контента 122 DRM, который должен быть доставлен агентам 114 DRM, и способ, которым контент 122 DRM может быть перемещен от CI 110 к агенту 114 DRM, используя разные транспортные механизмы. CI 110 может сам выполнять фактическую упаковку контента 122 DRM или он может получать заранее упакованный контент из некоторого другого источника.

RI 112 является объектом, который назначает разрешения и ограничения контенту 122 DRM и формирует RO 124. RO 124 является XML-документом, выражающим разрешения и ограничения, ассоциированные с контентом 122 DRM. RO 124 управляют тем, как контент 122 DRM может использоваться; контент 122 DRM не может использоваться без ассоциированного RO 124 и может только использоваться, как задано его ассоциированным RO (несколькими RO). Контент DRM мог бы ассоциироваться с более чем одним RO, если, например, RO имеет время прекращения действия (например, 10 дней), после времени прекращения действия нужен был бы новый RO, чтобы получить доступ к контенту. Агент 114 DRM является логическим объектом, который является ответственным за управление соблюдением "места использования" контента 122 DRM. Агент 114 DRM реализует доверяемый компонент устройства, и он несет ответственность за соблюдение разрешений и ограничений для контента 122 DRM на устройстве, управление доступом к контенту DRM на устройстве (к которому можно обращаться только через агент 114 DRM), и так далее.

Контент 122 DRM упаковывается для его защиты от несанкционированного доступа до его доставки. CI 110 доставляет контент 122 DRM, и RI 112 формирует RO 124. В системе 102 CI 110 и RI 112 реализуют логические роли, а не физические сущности. Например, в одном применении владельцы контента могут заранее упаковать контент DRM, который затем распространяется с помощью распространителей контента, действующих в качестве как CI, так и RI.

RO 124 управляет тем, как может использоваться контент 122 DRM. Контент 122 DRM не может использоваться без ассоциированного RO 124 и может использоваться только согласно разрешениям и ограничениям, заданным в RO 124. DRM OMA устанавливает логическое разделение контента DRM от RO. Контент DRM и RO могут запрашивать отдельно или вместе и они могут доставляться отдельно или одновременно. Когда они доставляются одновременно, они, как правило, предоставляются посредством CI 110, со встроенными RO и контентом в формате контента DRM (DCF).

RO 124 криптографически привязан к конкретному агенту 114 DRM с помощью набора ключей, так что к нему может обращаться только этот конкретный агент 114 DRM. К контенту 122 DRM можно обращаться только с действительным RO 124, поэтому контент 122 может свободно распространяться или распространяться посредством супердистрибуции.

DRM 2.0 OMA позволяет привязывать один RO к группе агентов DRM. Такая группа называется доменом. Контент DRM и RO, выделенные домену, могут совместно использоваться автономно всеми агентами DRM, принадлежащими этому домену. Например, пользователь может приобрести контент DRM для использования как на ее телефоне, так и на ее PDA.

Спецификации DRM OMA определяют формат и механизм защиты для контента DRM (или DCF), формат (язык выражения прав (REL)) и механизм защиты для RO и модель безопасности для управления ключами шифрования. Спецификации DRM OMA также определяют, как контент DRM и RO могут передаваться устройствам, используя ряд транспортных механизмов, включающих извлечение (HTTP pull, загрузка OMA), доставку (WAP push, MMS) и потоковую передачу. Однако спецификации DRM OMA не затрагивают никакого взаимодействия между сетевыми сущностями, например между CI 110 и RI 112.

Нижеследующее является неисчерпывающим списком случаев использования, охватываемых спецификациями DRM 2.0 OMA.

1. Базовая модель извлечения

Пользователь выбирает контент для загрузки с помощью просмотра веб-сайта и подтверждает условия приобретения. CI 110 идентифицирует и защищает контент 122, то есть упаковывает его. Контент 122 шифруется с использованием ключа шифрования контента (CEK). Возможности устройства могут распознаваться с использованием объявленной поддержки MIME-типа и т.д. RI 112 формирует RO 124 для контента 122 и целевого агента 114 DRM. RO 124 включает в себя разрешения для транзакции контента и CEK. Наконец, RO 124 криптографически защищается с помощью шифрования (используя ключ шифрования RO, или REK) и цифровых подписей и привязывается только к целевому агенту 114 DRM. Контент 122 DRM и защищенный RO 124 затем доставляются агенту 114 DRM.

2. Доставка контента DRM

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

2A. Доставка контента

CI 110 и/или RI 112 могут обладать некоторыми предварительными знаниями о пользователе и конкретном агенте 114 DRM, так что контент 122 и RO 124 могут быть отформатированы и упакованы для доставки.

2B. Извлечение, начатое доставкой

В этом случае, CI 110 и/или RI 112 может не иметь никаких предварительных знаний о пользователе или его агенте 114 DRM, но могут все еще иметь намерение доставить контент, например, позволить пользователю предварительно ознакомиться с контентом 122, чтобы привлечь его к приобретению контента. Вместо доставки контента DRM 122 непосредственно пользователю может быть отправлена ссылка на контент или ссылка на предварительный просмотр контента. Следование по ссылке приведет пользователя к конкретному расположению и затем процедура продолжается, как в базовой модели извлечения.

3. Потоковая передача контента DRM

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

4. Домены

Домены являются необязательной особенностью и могут не поддерживаться всеми RI. Домены расширяют базовую модель DRM 2.0 OMA, где RO и CEK привязываются к конкретному агенту 114 DRM, и позволяют RI 112 привязывать права и СЕК к группе агентов DRM вместо всего лишь одного агента DRM. Пользователи могут тогда совместно использовать контент 122 DRM автономно среди всех агентов DRM, принадлежащих одинаковому домену. RI 112 может использовать концепцию доменов для предоставления новых услуг, например предоставления пользователям возможности обращаться к контенту 122 DRM из нескольких устройств, которыми они владеют, или обеспечивать поддержку для несвязанных устройств, где пользователи приобретают контент DRM и права с помощью одного устройства (например, ПК) для последующего использования на другом устройстве (например, портативном плеере).

5. Резервирование

Контент 122 DRM может сохраняться на съемном носителе 118, в сетевом хранилище 116 или на любом другом виде запоминающего устройства. Контент 122 DRM хранится в зашифрованном виде и к нему можно обращаться только с помощью конкретного целевого агента 114 DRM, используя ассоциированный RO 124. RO 124 могут храниться для целей резервирования, если RO содержит только разрешения без состояния. Модель безопасности гарантирует, что RO 124 защищен и к нему можно получить доступ только с помощью предназначенного агента 114 DRM, даже если RO 124 хранится вне устройства. Некоторые разрешения требуют сохранения состояния с помощью агента 114 DRM, например, ограниченное количество воспроизведений. Такие RO не могут храниться вне устройства, так как это могло бы привести к потере информации о состоянии.

6. Супердистрибуция

Контент 122 DRM может копироваться и передаваться другим агентам 114 DRM, например, пользователь отправляет контент 122 DRM другу. Друг, чтобы получить доступ к контенту 122, направляется к RI 112 по ссылке в пакете контента DRM, чтобы получить RO 124.

7. Экспорт (в не-OMA системы DRM)

Контент DRM 122 может быть экспортирован в другие системы DRM, для использования на устройствах, которые несовместимы с DRM OMA, но поддерживают некоторые другие механизмы DRM. Архитектура DRM OMA позволяет RI 112, если они пожелают, представлять разрешение для агентов 114 DRM на выполнение преобразований в конкретные системы DRM, возможно как задано другими системами DRM. RI 112 может ограничивать экспорт только в конкретные внешние системы DRM.

8. Поддержка несвязанных устройств

DRM OMA дает возможность связанному устройству действовать в качестве посредника, чтобы помочь несвязанному устройству приобрести и загрузить контент 122 и RO 124. Пользователь, например, может иметь совместимое с DRM OMA портативное устройство (несвязанное устройство), у которого нет возможности сетевого подключения, и совместимое с DRM OMA мобильное устройство (связанное устройство), которое имеет возможность сетевого подключения. После использования связанного устройства для просмотра и приобретения контента 122 DRM и загрузки контента 122 DRM на связанное устройство пользователь может затем пожелать воспроизвести контент 122 DRM на несвязанном устройстве. В этом случае, агент 114 DRM на связанном устройстве запрашивает и загружает RO 124 домена от RI 112.

Агент 114 DRM на связанном устройстве затем вставляет домен RO 124 в DCF. DCF может передаваться несвязанному устройству с использованием подходящего протокола по технологии локального установления связи, например Bluetooth или USB. И связанное устройство, и несвязанное устройство обязаны быть совместимыми с DRM OMA, чтобы поддерживать эти функциональные возможности. Также, несвязанное устройство обязано принадлежать к тому же домену, что и связанное устройство.

Безопасность и доверие

Нижеследующее является общим представлением о мерах по безопасности и доверию DRM 2.0 OMA. Вообще, любое решение DRM должно отвечать двум требованиям безопасности: (1) к защищенному контенту обязательно обращаться только с помощью должным образом аутентифицированных и авторизованных агентов DRM; и (2) разрешения на защищенный контент должны соблюдаться всеми агентами DRM. Принудительное выполнение разрешений и ограничений, ассоциированных с контентом DRM, являются основной заботой мер по безопасности и доверию любой схемы DRM. Несанкционированный доступ к контенту DRM в обход, что обусловлено ассоциированным RO, и создание нелегальных копий и перераспределение контента DRM составляют основные угрозы для любой системы DRM. Система DRM OMA предоставляет средство для безопасного распространения и управления защищенным контентом в окружении OMA и соответствует указанным выше требованиям. DRM OMA усиливает использование и защиту контента и RO в точке использования с помощью агента DRM, который обеспечивает защищенное использование контента при ограничениях RO.

Основные этапы для распространения контента DRM могут быть резюмированы следующим образом:

1. Упаковка контента. Контент пакуется в защищенный контейнер контента (DCF). Контент DRM шифруется с помощью симметричного ключа шифрования контента (CEK). Контент может быть заранее упакован, то есть упаковка контента не должна происходить "на лету". Тот же самый CEK не используется для всех экземпляров части контента, хотя это не является требованием в DRM OMA.

2. Аутентификация агента в DRM. Все агенты DRM обладают уникальной парой личный/открытый ключ и сертификатом. Сертификат включает в себя дополнительную информацию, например производителя устройства, тип устройства, версия программного обеспечения, порядковые номера и т.д. Это позволяет CI и RI надежно аутентифицировать агента DRM.

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

4. Защита RO. Перед доставкой RO восприимчивые части RO (например, CEK) шифруются с помощью ключа шифрования прав (REK), и RO затем криптографически привязывается к целевому агенту DRM. Это гарантирует, что только целевой агент DRM может обращаться к RO, CEK и контенту DRM. К тому же, RI подписывает RO цифровой подписью. RO также управляет доступом к контенту DRM с помощью включения CEK. Язык выражения прав (REL) DRM OMA задает синтаксис (XML) и семантику разрешений и ограничений, управляя использованием контента DRM. RO имеет свой собственный MIME-тип контента.

5. Доставка. RO и DCF теперь могут быть доставлены целевому агенту DRM. Так как оба элемента, по сути, защищены, они могут доставляться с использованием любого транспортного механизма (например, HTTP/WSP, WAP Push, MMS). RO и DCF могут доставляться вместе, например, в MIME-сообщении из нескольких частей, или могут доставляться по отдельности.

Модель доверия DRM OMA для RO основывается на инфраструктуре открытых ключей (PKI), при помощи которой существуют группы принципалов, верификаторов и один или более органов аутентификации, признанных и получивших доверие от обеих групп. Одна сущность может играть роль, как принципала, так и верификатора в зависимости от потребностей контекста и выбранных решений. PKI дает верификатору возможность установить подлинность идентификатора и других атрибутов принципала, когда они взаимодействуют по открытой незащищенной сети. В такой системе, как правило, верификатору не нужно хранить никакой чувствительной информации о принципалах, с которыми он взаимодействует, для целей аутентификации. К тому же, Центр сертификации (CA) не вовлечен непосредственно в транзакции между принципалом и верификатором. RI доверяет агенту DRM, что тот работает правильно, если сертификат агента DRM поддается проверке RI и не был аннулирован. Аналогичным образом, агент DRM доверяет RI, что тот работает правильно, если сертификат RI поддается проверке агентом DRM и не был аннулирован. Исходными сущностями в PKI, которые применяются к DRM OMA, являются CA, устройства и RI. Протоколы аутентификации и передачи ключей в DRM OMA требуют, чтобы RI мог аутентифицировать устройство, и устройство могло аутентифицировать RI. Такая взаимная аутентификация выполняется с помощью ROAP.

К тому же предполагается, что устройства снабжаются (либо во время производства, либо позже) открытым и личным ключами устройства и ассоциированными сертификатами, подписанными соответствующим CA. На основе предпочтений сертификатов, выраженных RI, устройству нужно предоставить подходящий сертификат. Устройства обязаны хранить личные ключи в локальном ЗУ с защитой целостности и конфиденциальности.

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

Отметим, что в системе DRM может существовать множество CA. Протокол ROAP требует, чтобы CA, подписывающий сертификаты RI, работал на отвечающем устройстве по онлайновому протоколу статуса сертификата (OCSP) для использования во время выполнения протокола. От CA также требуется определять надлежащие политики сертификатов для управления использованием выданных сертификатов.

Нижеследующее описывает основные особенности безопасности DRM OMA.

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

2. Аутентификация, которая является процессом, с помощью которого сторона идентифицирует саму себя для другой стороны. В DRM OMA взаимная аутентификация агента DRM и RI достигается в 4-проходном Протоколе регистрации, 2-проходном Протоколе получения RO и 2-проходном Протоколе присоединения к домену. В зависимости от используемого протокола и отправленного сообщения, аутентификация достигается посредством цифровых подписей на основе либо одноразовых номеров, либо отметок времени. 1-проходный Протокол получения RO добивается аутентификации RI посредством цифровой подписи на основе отметки времени. Он не аутентифицирует агента DRM для RI, но вследствие защищенного контента, упакованного с помощью открытого ключа получателя, аутентификация косвенно выполняется посредством привязки ключей. 2-проходный Протокол выхода из домена аутентифицирует агента DRM для RI посредством цифровой подписи на основе отметки времени. Он не аутентифицирует RI для агента DRM. От RI требуется аутентифицировать себя для агента DRM во время доставки RO. Это обеспечивает некоторую степень уверенности о подлинности RI.

3. Защита целостности данных обеспечивает возможность обнаружить несанкционированное изменение данных. В DRM OMA защита целостности данных, когда применима, достигается посредством цифровых подписей на сообщениях ROAP и RO.

4. Подтверждение ключа гарантирует получателю сообщения, содержащего защищенный ключ, что отправитель сообщения знает значение ключа. В контексте DRM это свойство защищает от несанкционированной повторной выдачи RO от одного RI другим. В системе DRM OMA подтверждение ключа достигается посредством управления доступом к среде передачи (MAC) над защищенным ключом и отправки идентификатора стороны путем использования частей защищенного ключа в качестве ключа MAC. Агент DRM должен вызывать доверие у RI как в отношении правильной работы, так и в отношении реализации защиты. В DRM OMA каждый агент DRM снабжается уникальной парой ключей и ассоциированным сертификатом, идентифицирующим агента DRM и удостоверяющим привязку между агентом и этой парой ключей. Это позволяет RI надежно аутентифицировать агента DRM, используя стандартные процедуры PKI.

Информация в сертификат дает RI возможность применять политику на основе его бизнес-правил, стоимости его контента и т.д. Например, RI может доверять некоторым производителям, или он может хранить обновленный список агентов DRM, про которых известно, можно им доверять или не доверять по каким-нибудь критериям, определенным RI.

Формат контента DRM (DCF) является защищенным пакетом контента для зашифрованного контента со своим собственным MIME-типом контента. В дополнение к зашифрованному контенту он содержит дополнительную информацию, например описание контента (тип исходного контента, поставщик, версия и т.д.), унифицированный идентификатор ресурса (URI) RI (место, где может быть получен RO) и так далее. Эта дополнительная информация не шифруется и может быть показана пользователю до извлечения RO. CEK, необходимый для разблокирования контента DRM внутри DCF, содержится в RO. Таким образом, невозможно получить доступ к контенту DRM без RO, и контент DRM может использоваться только как указано в RO. DRM OMA включает в себя механизм, позволяющий агенту DRM проверять целостность DCF, защищающий от изменения контента несанкционированным объектом.

Система DRM OMA предполагает наличие времени DRM в агенте DRM. Поскольку пользователям нельзя изменять время DRM, определяется механизм, с помощью которого время DRM может синхронизироваться со временем, поддерживаемым на отвечающем устройстве OCSP. Некоторые ограничения (например, ограничения абсолютного времени), а также некоторые особенности протокола доставки для RO зависят от агента DRM, имеющего защищенный источник времени. Время DRM в контексте спецификаций DRM OMA означает точное время, а также значение времени, которое не является изменяемым пользователями. Спецификации DRM OMA предоставляют механизмы для синхронизации времени DRM при необходимости, например, если время DRM утрачено после продолжительного перебоя в питании. Некоторые несвязанные устройства с ограниченными возможностями могут не поддерживать часы реального времени и поэтому могут не поддерживать время DRM. Связанные устройства, однако, обязаны поддерживать время DRM.

DRM OMA защищает от атак на защиту от повторного воспроизведения RO. Примером атаки на повторное воспроизведение RO является то, где посредник перехватывает RO с ограниченным количеством воспроизведений во время доставки агенту DRM. Когда на агенте DRM истекают права, перехваченный RO может доставляться снова (повторно воспроизводиться) от посредника. DRM OMA препятствует возникновению этой и аналогичных атак.

Система DRM OMA обеспечивает безопасность уровня приложения посредством использования перечисленных выше механизмов защиты. Поэтому она не зависит от, или предполагает, безопасность транспортного уровня.

ROAP играет основную роль в DRM 2.0 OMA в разрешении защищенного, основанного на аутентификации обмена информацией касательно RO. ROAP является общим наименованием для набора протоколов защиты DRM между RI и агентом DRM в устройстве. Набор протоколов содержит несколько подпротоколов:

1. 4-проходный протокол для регистрации устройства с RI, как показано на фиг.2.

2. 2-проходный протокол получения RO включает в себя запрос и доставку RO, как показано на фиг.3.

3. 1-проходный протокол получения RO относится к доставке RO от RI на устройство (например, обмен сообщениями/доставка), как показано на фиг.4.

4. 2-проходный протокол присоединения к домену для устройства, чтобы присоединиться к домену, как показано на фиг.5.

5. 2-проходный протокол выхода из домена для устройства, чтобы выйти из домена, как показано на фиг.6.

Фиг.2 - блок-схема алгоритма 4-проходного протокола 200 регистрации. Протокол 200 использует устройство 202, RI 204 и отвечающее устройство 206 OCSP. Устройство 202 начинает (возможно, при приеме триггера ROAP) контакт с RI 204 путем отправки сообщения Приветствия устройств (этап 210), которое содержит информацию, например ID устройства (хэш сертификата устройства, который RI 204 может проверить позже с помощью отвечающего устройства 206 OCSP) и другую информацию. Таблица 1 иллюстрирует основные компоненты в сообщении Приветствия устройств. Никакая информация в сообщении Приветствия устройств не обладает защитой целостности, то есть отсутствует подпись для сообщения.

RI 204, в ответ на сообщение Приветствия устройств (этап 210), отправляет сообщение Приветствия RI устройству 202 (этап 212), которое содержит информацию, например учетные данные сертификата RI (в виде ID RI), некоторые относящиеся к сеансу (противоответная цель) одноразовые номера и номера сеансов и другую необязательную информацию, например информацию о цепочке доверия устройству, которое распознает RI 204. Таблица 2 иллюстрирует формат сообщения приветствия RI. Отметим, что никакая информация в сообщении приветствия RI не обладает защитой целостности.

При успешной проверке информации, содержащейся в сообщении приветствия RI, устройство 202 отправляет сообщение с Запросом регистрации (этап 214), которое включает в себя обязательную информацию, например время запроса, ID сеанса и подпись, и необязательную информацию, например цепочка сертификатов, доверенная привязка органа RI, расширения и т.д. Таблица 3 иллюстрирует формат сообщения с Запросом регистрации. Сообщение с Запросом регистрации содержит, в своей заключительной части, цифровую подпись всех сообщений, переданных между устройством 202 и RI 204, вплоть до поля Подписи в сообщении с Запросом регистрации, то есть, все сообщение Приветствия устройств, все сообщение приветствия RI и поля сообщения с Запросом регистрации вплоть до (и исключая) поля Подписи. Эта цифровая подпись выполняется с использованием секретного ключа устройства. Включение цифровой подписи обеспечивает некоторую защиту целостности ассоциированных сообщений ROAP.

Пока устройство 202 не указывает, с помощью информации в Расширениях, что проверка OCSP не нужна или не поддерживается, RI 204 отправляет сообщение с запросом OCSP на отвечающее устройство 206 OCSP (этап 216) для запроса проверки информации, доставленной RI 204 устройством 202. Отвечающее устройство 206 OCSP ищет информацию в сообщении с запросом, чтобы попытаться проверить информацию, и возвращает ответное сообщение OCSP (этап 218), содержащее результаты запроса.

RI 204 отправляет ответное сообщение регистрации устройству 202 (этап 220), которое включать в себя указание, была ли регистрация успешной или неуспешной, и другую информацию. Таблица 4 иллюстрирует формат ответного сообщения регистрации. Ответное сообщение регистрации содержит, в своей заключительной части, хэш SHA-1 сообщения с Запросом регистрации и Ответного сообщения регистрации (вплоть до и исключая поле подписи). Эта цифровая подпись выполняется с использованием личного ключа RI. Включение цифровой подписи обеспечивает некоторую защиту целостности ассоциированных сообщений ROAP. Отметим, что хотя хэш SHA-1 используется для цифровой подписи, мог бы использоваться любой подходящий алгоритм для наложения цифровой подписи.

Фиг.3 - блок-схема алгоритма 2-проходного протокола 300 получения RO. Протокол 300 использует устройство 202 и RI 204 и работает после того, как завершен 4-проходный Протокол 200 регистрации и устройство 202 приняло действительную цепочка сертификатов о RI 204. Протокол 300 используется устройством 202 для запроса RO от RI 204. Устройство 202 отправляет сообщение с запросом RO к RI 204 для запроса RO (этап 310). Таблица 5 показывает формат сообщения с Запросом RO. Сообщение с запросом RO содержит цифровую подпись сообщения (исключая поле Подписи).

RI 204 в ответ на сообщение с запросом отправляет Ответное сообщение RO устройству 202 (этап 312). Ответное сообщение RO включает в себя RO или включает в себя указание, что RO не будет отправлен. Таблица 6 показывает формат Ответного сообщения RO. Ответное сообщение RO, в случае успешного состояния, содержит цифровую подпись, которая является хэшем SHA-1 Сообщения с запросом RO и Ответного сообщения RO, исключая поле Подписи.

Фиг.4 - блок-схема алгоритма 1-проходного протокола 400 получения RO. Протокол 400 использует устройство 202 и RI 204. В протоколе 400 RI 204 в одностороннем порядке отправляет устройству 202, без запроса от устройства 202, Ответное сообщение RO (этап 410), включающее RO. Протокол 400 применяет, например, сценарии использования доставки. Таблица 7 показывает формат Ответного сообщения RO.

Фиг.5 - блок-схема алгоритма 2-проходного протокола 500 Присоединения к домену. Протокол 500 использует устройство 202 и RI 204. Когда устройство 202 хочет присоединиться к домену, устройство 202 отправляет RI 204 сообщение с Запросом присоединения к домену (этап 510). RI 204 оценивает запрос и отправляет Ответное сообщение присоединения к домену устройству 202 (этап 512). Таблица 8 показывает формат сообщения с Запросом присоединения к домену, а Таблица 9 показывает формат Ответного сообщения присоединения к домену.

Фиг.6 - блок-схема алгоритма 2-проходного протокола 600 Выхода из домена. Протокол 600 использует устройство 202 и RI 204. Когда устройство 202 хочет выйти из домена, устройство 202 отправляет RI 204 сообщение с Запросом выхода из домена (этап 610). RI 204 оценивает запрос и отправляет Ответное сообщение выхода из домена устройству 202 (этап 612). Таблица 10 показывает формат сообщения с Запросом выхода из домена, а Таблица 11 показывает формат Ответного сообщения выхода из домена.

Все протоколы, включенные в набор ROAP, за исключением 1-проходного протокола получения RO, могут запускаться с использованием Триггера ROAP. Устройство 202 может также начинать протоколы в одностороннем порядке в результате взаимодействий пользователя. RI 204 формирует и отправляет Триггер ROAP устройству 202, чтобы запустить обмен по протоколу ROAP. В качестве альтернативы RI 204 может поручить формирование Триггера ROAP другим системам путем предоставления этим системам необходимой информации (например, идентификаторы RO и идентификаторы домена). Триггер ROAP (сформированный непосредственно или косвенно с помощью RI 204) также может быть передан устройству 202 другими системами (например, посредством CI).

Когда устройство 202 принимает Триггер ROAP, оно начинает обмен по протоколу ROAP как можно скорее. Соответствующее согласие пользователя должно быть получено до запуска любых протоколов ROAP в результате приема Триггера ROAP. Поскольку ROAP содержит несколько протоколов, Триггер ROAP включает в себя указание текущего протокола (например, Регистрация, Получение RO, Присоединение к домену или Выход из домена), который должен быть запущен устройством 202. Сообщения ROAP и то, как сообщения обрабатываются протоколами, обеспечивают не только RO и их ассоциированная обработка, но также функции безопасности, окружающие RO в DRM 2.0 OMA. Точнее говоря, протоколы ROAP обращаются к следующим особенностям безопасности и доверия:

1. Взаимная аутентификация между RI и устройством;

2. Противостояние атакам на повторное воспроизведение с использованием одноразовых номеров в различных сообщениях;

3. Защита целостности сообщений ROAP или частей сообщений ROAP; и

4. Проверка защищенного времени DRM в сообщениях ROAP или части сообщений ROAP.

Методики доверительных вычислений

В последнее время методики надежных вычислений появились в литературе и в изделиях, в основном под техническим прикрытием Trusted Computing Group (Группы доверительных вычислений, TCG). Технологии TCG предоставляют способы, при помощи которых вычислительные объекты могут устанавливать достоверность для них самих и для других устройств с помощью использования цепочки доверия, так что эта обработка или вычисление на таких устройствах может быть:

1. Оценена на достоверность платформы и различных аппаратных (HW) и программных (SW) компонентов;

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

3. Внешние стороны могут выполнять оценку и решения об обмене информацией и обработке с другими устройствами и на основе доказанных уровней доверия таких целевых устройств.

TCG определяет основной модуль обработки, названный Доверяемым модулем обработки (TPM), который обладает следующими свойствами:

1. Физическая защита модуля и его интерфейсов;

2. Защищенные энергозависимые и энергонезависимые области памяти;

3. Защищенные криптографические функции внутри модуля, которые могут выполнять шифрование и цифровую подпись;

4. Использование Регистров конфигурации платформы (PCR), которые последовательно фиксируют "состояние" платформы и ее SW-компонентов с помощью расширения хэша;

5. Наличие специфичных для устройства и защищенных Ключей подтверждения (EK) на основе PKI, которые служат в качестве основы аутентификации устройства, но не прямыми путями. EK никогда не показывается извне, но его псевдонимы, называемые ключами удостоверения подлинности (AIK), используются для подписывания значений измерения целостности платформы; и

6. Использование "запечатывания" данных, в сочетании со значениями PCR, подписанными с помощью AIK, в "блобах" [больших двоичных объектах] памяти, так что к данным можно обращаться или извлекать, только когда проверена целостность платформы или SW (которая измерена и проверена путем сравнения значений PCR от TPM и от запечатанного блоба в памяти).

Методики доверительных вычислений проверялись, особенно в контексте мобильных телефонов, на возможное применение в обеспечении безопасности приложения DRM на таких мобильных устройствах. Ранее предложенные способы для защиты приложения DRM с помощью использования методик TCG включали в себя некоторые способы, которые используют процедуру запечатывания TPM и блобы в памяти для надежного хранения связанных с DRM данных после обработки по протоколу ROAP с использованием ключей TCG, а TPM и в областях памяти с защитой по ключу.

Однако существующий предшествующий уровень техники не реагирует явно и не реагирует правильным способом на то, как установить и использовать "доверие" на платформе и/или программном обеспечении DRM. Также предшествующий уровень техники не обращается к конкретным методикам для защиты целостности в сообщениях ROAP, для усиления обработки целостности в системах DRM 2.0 OMA. Настоящее изобретение включает в себя новые методики для таких целей.

Текущая спецификация DRM 2.0 OMA обеспечивает сильные способы обеспечения безопасности на основе PKI, затрагивающие CA, RI и устройство. Однако имеются уязвимости, относящиеся к безопасности и целостности платформ, SW, агентов и сообщений как в рамках самой спецификации DRM 2.0 OMA, так и по отношению к неуказанной реализации устройств и RI, которые совместимы с DRM 2.0 OMA.

Спецификация DRM OMA подтвердила различные угрозы и уязвимости, с которыми может столкнуться любое устройство или RI, даже когда они соответствуют спецификации DRM 2.0 OMA. Эти уязвимости включают в себя:

1. Компрометация объекта, где атакующий может попытаться скомпрометировать объект системы DRM, физически или иным образом. Типы атак компрометации объекта включают в себя компрометацию агента DRM на устройстве и SW DRM в RI. Последствия компрометации объекта включают в себя, например, раскрытие секретных ключей, ключей домена, ключей шифрования RO, ключей шифрования контента и защищенного контента, а также утрату защиты целостности кэша повторного воспроизведения агента DRM, и/или утрату защиты прав, сохраненных внутри в агенте DRM. Более того, также могут возникать потери времени DRM. Воздействия на PKI скомпрометированного CA или отвечающего устройства OCSP обсуждаются в ссылках, например IETF RFC3280.

Система DRM OMA полагается на аннулирование сертификата, чтобы минимизировать повреждение, вызванное скомпрометированным объектом. Агенты DRM и RI обязаны всегда проверять, что объект, с которым они взаимодействуют, не был скомпрометирован, путем проверки состояния сертификата объекта. Атака компрометации объекта может происходить как "прямым", так и "обратным" путями. Прямая атака компрометации направлена на объекты DRM (RI, агент DRM, CI, CA или отвечающее устройство OCSP), приводя к несанкционированной работе. Обратная атака компрометации нейтрализует или ослабляет защиту агента DRM, настройки целостности и конфигурации.

2. Удаление сообщения, при помощи чего атакующий может удалить сообщение, отправленное между агентом DRM и RI, как правило, приводящее к атакам отказа в обслуживании (DoS). Атака с удалением сообщения может включать в себя: удаление сообщения во время протокола регистрация или протокола получения RO, удаление одноразового номера для повторного воспроизведения, удаление триггера ROAP и т.д.

3. Изменение сообщения, при помощи чего атакующий может изменить сообщение, отправленное между агентом DRM и RI, как правило, приводящее к DoS-атакам. Атака с изменением сообщения может включать в себя изменение во время протокола регистрации, во время протоколов Присоединения к домену и Выхода из домена и изменение в различных триггерах ROAP.

4. Вставка сообщения, при помощи чего атакующий может вставлять сообщения в канал связи в любой точке между RI и агентом DRM.

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

5. Другие атаки, например обычные DoS-атаки, пассивные атаки, например анализ трафика и раскрытие конфиденциальности.

Устанавливаются следующие проблемы текущих спецификаций и реализаций DRM OMA. Определяется расширенное понятие "целостности", которое применяется к схемам DRM OMA. В традиционном понимании спецификации DRM OMA обращаются только к небольшой области целостности сообщения ROAP. Ниже в расширенном понятии целостности, определенном в настоящем изобретении, отмечается, где и какой вид целостности может рассматриваться.

1. Целостность платформы DRM. Это относится к целостности объектов платформы, то есть физических сущностей, включающих в себя устройство, RI и функции контента. Разные объекты включают в себя операционную систему (OS), загрузочный код (например, BIOS в случае ПК), HW/микропрограммное обеспечение (FW)/SW для доступа к памяти, различные объекты HW/FW/SW, которые обрабатывают связанные с безопасностью функции (например, криптография и управление ключом, а также привилегированное хранение секретных данных, например, политик, сертификатов и т.д.) и возможность сетевого и локального подключения HW/FW/SW. Целостность платформы определяет, действительна ли платформа, подлинна, не изменена за исключением законных процессов, и работает только, как предназначено.

2. Целостность SW DRM. SW DRM относится к программным объектам и компонентам, хранящимся в устройстве, RI или CI, которые выполняют функции, характерные для спецификаций DRM OMA и их процедур. В устройстве агент DRM состоит из SW DRM. В RI и CI SW DRM в собирательном значении относится к множеству SW, которое выполняет специальные DRM-функции, например упаковка RO, форматирование DCF, шифрование контента, доставка контента или RO, проверка, обработка ROAP и т.д. Целостность SW DRM поддерживается, если SW DRM действительно, подлинно, не изменено за исключением законных процессов, и работает только, как предназначено.

3. Целостность сообщений ROAP и информации. Целостность сообщений ROAP и их составляющая информация поддерживается, если такая информация подтверждена, подлинна и не изменена за исключением законных процессов. В спецификациях DRM 2.0 OMA некоторые подмножества сообщений ROAP и их составляющая информация снабжаются защитой целостности путем использования цифровых подписей.

4. Целостность медиа-объекта и контента DRM. Медиа-объекты и контент DRM также обязаны обладать защитой целостности, то есть не должны быть изменены, удалены или обманным образом вставлены, сохраняются ли они на устройстве, RI или CI или находятся в процессе передачи или доставки между любыми двумя сторонами. Определенный интерес представляет беспроводная (OTA) доставка контента, которая применима к передаче контента на мобильное устройство, где контент DRM доставляется с использованием главным образом открытых каналов.

5. Целостность связанной с DRM информации. Связанная с DRM информация, например ID объекта (ID устройства, ID RI и т.д.), ключи шифрования (CEK, REK) и ключи подписи, сами RO, контекстная информация, сертификаты и другая связанная с цепочкой доверия информация должна быть надежно защищена, что означает, что их следует защищать не только для конфиденциальности, но также и для целостности.

Отметим, что ни текущие спецификации DRM 2.0 OMA, ни существующий предшествующий уровень техники, по-видимому, не предложили решений для проблем компрометации объекта или целостности. Этот недостаток решений ставит следующую проблему: даже если все процедуры ROAP правильно реализуются, согласно спецификации DRM 2.0 OMA, например, как устройство может на самом деле узнать, заслуживает ли доверия платформа RI? Другими словами, как устройство может узнать, не будет ли платформа RI злоупотреблять данными, которые отправляет устройство как часть протоколов ROAP, или злоупотреблять самой обработкой DRM? Например, устройство не знает, будет ли RI произвольно и неверно ограничивать права использования устройства, потому что SW платформы RI скомпрометировано и оно ограничивает во всем остальном действительные права использования устройства. Аналогичные вопросы возникают для проблемы целостности программного обеспечения DRM. Точнее говоря, некоторыми проблемами текущих систем DRM 2.0 OMA, с точки зрения расширенного понятия целостности, которое описано выше, являются следующие.

1. Отсутствие способов проверки и сообщения целостности платформы и SW DRM. По отношению к угрозе компрометации объекта, которая установлена выше, не существует способа в предшествующем уровне техники для явной и структурированной проверки целостности платформы и проверки целостности агента SW между устройством и RI, который либо указан спецификациями DRM 2.0 OMA, либо является частью сценариев использования TCG 1.2. Это особенно справедливо для проверки целостности платформы, а не только агента DRM.

2. Платформа (например, ПК или PDA, по отношению к устройству, или сервер, как для RI) могла быть умышленно скомпрометирована, что может привести к препятствованию правильного выполнения SW агента DRM и агента RI, даже когда дана правильная и защищенная в конфиденциальности и защищенная в целостности информация. Например, иным образом хорошо защищенное SW агента DRM может хранить некоторую информацию в простом тексте в совместно используемой памяти перед, во время или после обработки. Скомпрометированная платформа может, в таких случаях, явно обращаться к совместно используемой памяти и удалять информацию, изменять информацию или вставлять новую ложную информацию, которая тогда могла бы быть обработана впоследствии SW агента DRM, которое может воспринять такую информацию как подлинную. Это может привести к DoS-атакам, несанкционированному раскрытию частной информации или несанкционированной доставке, распространению или использованию RO DRM или контента DRM.

3. SW агента DRM и SW RI, которые являются частями SW, которое обрабатывает связанную с DRM информацию, могут стать скомпрометированными по различным причинам. Такое SW, например, могло быть изменено вирусом или другими злоумышленными объектами SW. Одним результатом такой компрометации в платформе или SW DRM была бы последующая компрометация в целостности сообщений и информации, которую рассматривает DRM 2.0 OMA, особенно сообщения по протоколу ROAP. В некоторой степени из-за того, что только некоторые, но не все, сообщения ROAP обладают защитой целостности, ими можно теоретически манипулировать синхронизированными способами между скомпрометированным устройством и мошенническим или скомпрометированным RI. Сообщения могли бы изменяться синхронно как на устройстве, так и на RI, и все еще могут казаться "проверенными на целостность", поскольку сообщения изменялись одинаковым образом.

4. Недостаточная защита целостности у сообщений ROAP. В части целостности сообщений, сообщения ROAP и информация, перемещаемая различными полями сообщения, подвержены уязвимостям, которые не решены спецификацией DRM 2.0 OMA. Например, защита целостности сообщения ROAP, указанная в настоящее время в спецификации DRM 2.0 OMA, оставляет такие просчеты, как:

4A. Не все сообщения ROAP имеют защиту целостности. Невключение цифровых подписей во все сообщения могло бы представлять собой уязвимости в некоторых случаях.

4B. Даже когда сообщения ROAP или некоторые поля информации имеют защиту целостности с помощью цифровых подписей, после того как информация расшифрована, проверена на целостность и затем "использована" в виде обычного текста, злоумышленные объекты могли бы получить доступ к открытой информации и удалить, изменить или повторно распространить ранее проверенную на целостность информацию. Таким образом, требуется усиленная защита целостности.

5. Уязвимости относительно целостности контента DRM и его доставки. Точнее говоря, существуют следующие проблемы:

5A. Механизмы проверки целостности контент неполные. Например, не определена целостность контента, пока контент находится в пересылке или доставке (например, загрузка OTA). Подпись для DCF, например, формируется только для использования в процедурах ROAP. Пока и до того, как происходят процедуры ROAP, отсутствует механизм проверки целостности, который управляет целостностью контента при хранении, например, у CI.

5B. Шифрование контента, даже для использования в протоколе ROAP, является обязательным, но проверка целостности является лишь факультативной.

5C. Особенно для пакетизированного контента для услуг потоковой передачи формат PDCF имеет проблему синхронизации. Пакеты, которые были неправомерно изменены, могли быть загружены и даже могли быть использованы (то есть, воспроизведены на медиаплеере) до того, как может быть проверена целостность всего потока.

Основной проблемой становится: как различные стороны (устройство, RI и CI) могут быть уверены в целостности платформы и целостности SW DRM? Таким образом, необходим способ для усиления и проверки целостности платформы (например, операционная система, BIOS, медиаплеере, программное обеспечение связи, совместно используемая память и т.д.), на которую полагаются либо SW агента DRM, либо SW RI. Настоящее изобретение обращает внимание на недостатки предшествующего уровня техники.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение раскрывает несколько способов, которые усиливают целостность объектов, сообщений и обработки, имеющих отношение к спецификации DRM OMA версии 2.0. Способы используют методики, общеизвестные как Методики доверительных вычислений, которые указаны промышленным форумом Группы по доверительным вычислениям (TCG). В первом варианте осуществления изобретения раскрываются методики для проверки целостности или достоверности платформы и SW DRM, как с изменениями в спецификациях ROAP DRM и DCF, так и без оных. Во втором варианте осуществления раскрываются методики для усиления целостности сообщений ROAP DRM OMA, составляющей их информации и обработки без изменения существующего протокола ROAP. В третьем варианте осуществления раскрываются методики для усиления целостности сообщений ROAP, информации и обработки с некоторыми изменениями в существующем протоколе ROAP.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг.1 - блок-схема существующей функциональной архитектуры DRM 2.0 OMA;

Фиг.2 - блок-схема алгоритма существующего 4-проходного протокола ROAP регистрации в DRM 2.0 OMA;

Фиг.3 - блок-схема алгоритма существующего 2-проходного протокола ROAP получения RO в DRM 2.0 OMA;

Фиг.4 - блок-схема алгоритма существующего 1-проходного протокола ROAP получения RO в DRM 2.0 OMA;

Фиг.5 - блок-схема алгоритма существующего 2-проходного протокола ROAP присоединения к домену в DRM 2.0 OMA;

Фиг.6 - блок-схема алгоритма существующего 1-проходного протокола ROAP выхода из домена в DRM 2.0 OMA;

Фиг.7 - блок-схема многосторонней проверки целостности платформы среди объектов DRM 2.0 OMA;

Фиг.8 - блок-схема алгоритма способа для выполнения контроля целостности платформы между двумя объектами, где два объекта могут быть устройством и RI или устройством и CI;

Фиг.9 - блок-схема алгоритма 4-проходного протокола ROAP регистрации для выполнения взаимной проверки целостности платформы между устройством и RI, используя предварительную проверку доверия;

Фиг.10 - блок-схема алгоритма 4-проходного протокола ROAP регистрации для выполнения взаимной проверки целостности платформы между устройством и RI, используя измененные сообщения Приветствия устройств и Приветствия RI;

Фиг.11 - блок-схема алгоритма способа для выполнения проверки целостности программного обеспечения DRM между двумя объектами, где два объекта могут быть устройством и RI или устройством и CI;

Фиг.12 - блок-схема алгоритма 2-проходного протокола ROAP получения RO для выполнения взаимной проверки целостности программного обеспечения DRM между устройством и RI; и

Фиг.13 - блок-схема алгоритма способа для повышения целостности сообщений ROAP и обработки с использованием методик TCG, включая запечатанную привязку и использование блобов в памяти.

ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

В дальнейшем термин "блок беспроводной передачи/приема" (WTRU) включает в себя, но не ограничивается, пользовательское оборудование, мобильную станцию, стационарный или мобильный абонентский модуль, пейджер или любой другой тип устройства, допускающий работу с проводной или беспроводной среде. В дальнейшем при ссылке на него, термин "базовая станция" включает в себя, но не ограничивается, Узел Б, контроллер узла, точку доступа или любой другой тип устройства установления связи в беспроводной среде.

Настоящее изобретение раскрывает способы, при помощи которых информация относительно состояния доверия или целостности объекта DRM (например, устройства, RI или CI) явно и взаимно запрашивается и обменивается между любыми двумя объектами DRM, как необходимое условие к процедурам DRM OMA.

Общая архитектура 700 этого способа показана на фиг.7. Архитектура включает в себя четыре объекта DRM: устройство 702, RI 704, CI 706 и Частный центр сертификации (PCA) 708. Проверка целостности платформы предполагает, что PCA 708 имеет записи об учетных данных доверительных вычислений (например, TCG) для других объектов DRM (например, устройство 702, RI 704 и CI 706) и предоставляет основание доверия для сертификации учетных данных TCG.

Любая пара объектов (например, устройство 702 и RI 704, устройство 702 и CI 706 или RI 704 и CI 706), которая желает осуществить взаимную проверку целостности платформы между собой, допускает выполнение доверительных вычислений (например, оборудована модулями доверительной обработки (TPM) 710 TCG). Это подразумевает, что допускающий доверительные вычисления объект DRM не только имеет TPM 710 (или эквивалент), но также связанные ресурсы TCG, например, AIK 712, SML 714 и защищенную память, использующую блобы 716. Также имеются операционная система (OS) или платформенное программное обеспечение 718 и программное обеспечение 720 DRM.

Когда вышеупомянутые требования выполняются, любая пара разных объектов DRM может взаимно проверять их целостность платформы или достоверное состояние платформы, используя PCA 708 и возможности доверительных вычислений. В качестве примера процедуры для взаимной проверки целостности между устройством 702 и RI 704 являются следующими.

Устройство 702, RI 704 и CI 706 все допускают выполнение самопроверки OS или других платформенных программных компонентов (этап 730) и самопроверки программного обеспечения DRM (этап 732). Самопроверки могут запрашиваться как часть большего процесса проверки (который более подробно обсуждается ниже) или могут быть автономными процессами. Если одна из самопроверок потерпела неудачу, это могло быть указанием того, что объект скомпрометирован и ему не следует доверять.

Устройство 702 отправляет информацию об учетных данных своей платформы TCG к RI 704 (этап 740). Примеры учетных данных платформы TCG включают в себя, но не ограничиваются, подписанный сертификат платформы TCG или подписанный сертификат TPM. Как часть учетных данных, устройство 702 также может отправлять RI 704 самозаверенный признак Достоверного Состояния или Проверенной целостности платформы в качестве дополнительной информации. Если устройство 702 собирается проверить целостность платформы у RI 704, то информация о полномочиях, отправленная на этапе 740, также будет включать в себя указание устройством 702, что оно желает, чтобы RI 704 начал процедуры для проверки его целостности платформы. Отметим, что устройство 702 сможет принять решение относительно того, проверять ли целостность платформы у RI 704, только если проверка состояния целостности платформы RI является необязательной функцией; в одном варианте осуществления проверка целостности платформы RI является обязательной функцией.

После приема информации о полномочиях от устройства 702, RI 704 ретранслирует информацию о полномочиях к PCA 708 (этап 742), а также просит у PCA 708 проверить учетные данные об устройстве 702, особенно последнюю достоверность устройства. PCA 708 затем отправляет информацию о последней достоверности (например, уровень доверия платформы и т.д.) касательно устройства 702 к RI 704 (этап 744). После приема информации о достоверности платформы устройства от PCA 708, и также при желании дополнительной информации от устройства 702, RI 704 оценивает уровень доверия устройства 702. RI 704 решает, наделить ли достаточным доверием целостность платформы устройства, чтобы продолжить далее с процедурами DRM, например протоколом регистрации или протоколом получения RO.

Устройство 702, либо в качестве обязательной процедуры, либо в качестве необязательной процедуры, может оценить целостность платформы у RI 704 аналогичными и взаимными способами, как на этапах 740-744. Точнее говоря, RI 704 отправляет информацию об учетных данных его платформы TCG на устройство 702 (этап 750). Как часть учетных данных, RI 704 также может отправлять устройству 702 самозаверенный флаг Достоверного Состояния или Проверенной целостности платформы в качестве дополнительной информации.

После приема относящейся к TCG информации от RI 704 устройство 702 ретранслирует информацию к PCA (этап 752), а также просит у PCA 708 проверить учетные данные о RI 704, особенно последнюю достоверность RI. PCA 708 затем отправляет последнюю информацию о достоверности касательно RI 704 на устройство 702 (этап 754). После приема информации о достоверности платформы RI от PCA 708 касательно RI 704, и также при желании дополнительной информации от самого RI, устройство 702 оценивает уровень доверия у RI 704. Устройство 702 решает, наделить ли достаточным доверием целостность платформы RI, чтобы продолжить далее с процедурами DRM, например протоколом регистрации или протоколом получения RO.

Устройство 702, либо в качестве обязательной процедуры, либо в качестве необязательной процедуры, может оценить целостность платформы у CI 706. CI 706 отправляет информацию об учетных данных своей платформы TCG к устройству 702 (этап 760). Как часть учетных данных, CI 706 также может отправить устройству 702 самозаверенный флаг Достоверного Состояния или Проверенной целостности платформы в качестве дополнительной информации.

После приема относящейся к TCG информации от CI 706 устройство 702 ретранслирует информацию к PCA (этап 762), а также просит у PCA 708 проверить учетные данные о CI 706, особенно последнюю достоверность CI. PCA 708 затем отправляет последнюю информацию о достоверности касательно CI 706 на устройство 702 (этап 764). После приема информации о достоверности платформы CI от PCA 708 касательно CI 706, и также при желании дополнительной информации от самого CI, устройство 702 оценивает уровень доверия у CI 706. Устройство 702 решает, наделить ли достаточным доверием целостность платформы CI, чтобы продолжить далее с процедурами DRM.

Целостность платформы у устройства 702 может быть проверена CI 706 следующим образом. Устройство 702 отправляет информацию об учетных данных своей платформы TCG к CI 706 (этап 770). Как часть учетных данных, устройство 702 также может отправить CI 706 самозаверенный флаг Достоверного Состояния или Проверенной целостности платформы в качестве дополнительной информации. Если устройство 702 собирается проверить целостность платформы у CI 706, то информация о полномочиях, отправленная на этапе 770, также будет включать в себя указание устройством 702, что оно желает, чтобы CI 706 начал процедуры для проверки его целостности платформы. Отметим, что устройство 702 сможет принять решение относительно того, проверять ли целостность платформы у CI 706, только если проверка состояния целостности платформы CI является необязательной функцией; в одном варианте осуществления проверка целостности платформы CI является обязательной функцией.

После приема информации о полномочиях от устройства 702 CI 706 ретранслирует информацию о полномочиях к PCA 708 (этап 772), а также просит у PCA 708 проверить учетные данные об устройстве 702, особенно последнюю достоверность устройства. PCA 708 затем отправляет последнюю информацию о достоверности касательно устройства 702 к CI 706 (этап 774). После приема информации о достоверности платформы устройства от PCA 708, и также при желании дополнительной информации от устройства 702, CI 706 оценивает уровень доверия устройства 702. CI 706 решает, наделить ли достаточным доверием целостность платформы устройства, чтобы продолжить далее с процедурами DRM.

Отметим, что в вышеупомянутом примере этапы 740-744 для устройства 702, чтобы проверить его состояние целостности для RI 704, являются обязательной функцией настоящего изобретения. Однако проверка целостности платформы либо RI 704 для устройства 702 (этапы 750-754), проверка целостности платформы у CI 706 для устройства 702 (этапы 760-764) и проверка целостности платформы устройства для CI 706 (этапы 770-774) являются необязательными, однако настоятельно рекомендованными функциями в системе DRM.

Также отметим, что эти процедуры не нужно начинать с помощью активной инициации объектом, который необходимо проверить. Процедуры проверки целостности могли бы начинаться с запроса объектом, желающим проверить целостность другой стороны. В таких случаях каждый этап 740, 750, 760 или 770 предварялся бы другим этапом, при помощи чего объект, желающий выполнить проверку целостности платформы другой стороны, вызывает или просит другую сторону отправить соответствующую относящуюся к доверию информацию.

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

1. Процедуры проверки целостности платформы устройства (то есть этапы 740-744) могли бы выполняться с помощью одного или более из следующего.

1A. Перед тем, как устройство желает начать новый 4-проходный протокол ROAP регистрации.

1B. Один раз для каждого RI, перед первой регистрацией, происходящей с конкретным RI. В этом случае RI получит учетные данные TCG устройства один раз перед первой регистрацией, и затем RI защищает информацию о полномочиях устройства под своим собственным TPM путем привязки информации о полномочиях к ключу TPM. RI тогда позже отвязывает сохраненные учетные данные TCG и проверяет, периодически или по некоторым событиям, действительны ли еще учетные данные TCG устройства, которые он получил, например с помощью консультации с CA OCSP.

1C. Периодически, каждый раз как истекла заданная длительность времени, например, T_{DEV-PLATFORM-LAST-REG}, с тех пор как устройство завершило последний протокол регистрации с тем же RI.

1D. Периодически, каждый раз как истекла заданная длительность времени, например, T_{DEV-PLATFORM-LAST-REPORT}, с того последнего момента, как устройство проверяло состояние целостности его платформы для того же RI.

2. Если и когда реализуются процедуры проверки целостности платформы RI (то есть этапы 750-754), они могли бы выполняться с помощью одного или более из следующего.

2A. Один раз для каждого устройства, перед первой регистрацией, происходящей с конкретным устройством. В этом случае устройство получит учетные данные TCG RI один раз перед первой регистрацией, и затем устройство защищает информацию о полномочиях RI под своим собственным TPM путем привязки информации о полномочиях к ключу TPM. Устройство тогда позже отвязывает сохраненные учетные данные TCG и проверяет, периодически или по некоторым событиям, действительны ли еще учетные данные TCG RI, которые он получил, например с помощью консультации с CA OCSP.

2B. Всегда, когда RI принимает указание от устройства, что устройство желает, чтобы RI проверил свое состояние целостности для устройства, либо как отдельное сообщение, либо как часть сообщения по измененному протоколу ROAP.

2C. Периодически, каждый раз как истекла заданная защитная длительность времени, например, T_{RI-PLATFORM-LAST-REPORT}, с последнего момента, как RI проверило свое состояние целостности для устройства.

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

Предшествующий уровень техники рассмотрел использование "защищенной загрузки" с использованием методик TCG в сочетании с применением надежного DRM. В таких схемах OS платформы и другой связанный с загрузкой код проверяется на целостность всякий раз, когда загружается устройство, неявно выполняя проверку целостности платформы перед тем, как может быть запущено любое приложение DRM. Настоящее изобретение предоставляет более систематичное и явное использование проверки целостности платформы во время загрузки, а также проверки целостности платформы в другое время на основе предопределенных периодов времени, а также при возникновении некоторых событий. Настоящее изобретение также распространяет проверку целостности платформы от устройства также на RI и CI. Непрерывные проверки целостности платформы полезны вследствие того факта, что именно потому, что устройство правильно приняло конкретный действительный CO, это не означает, что RI или CI следует рассматривать как заслуживающие доверия бесконечно в будущем с этого времени. Периодическая и/или событийная постоянная проверка достоверности предоставляет хороший защитный механизм.

Также, что касается необходимости проверки целостности между устройством и CI, даже если контент приходит перед RO, контент может быть скомпрометирован, когда целостность платформы CI или SW DRM CI скомпрометирована. Например, предположим, что пользователь загрузил файл. Даже когда RO еще не получен, пользователь может нечаянно щелкнуть мышью на контенте или может выполнить проверку достоверности контента. Если контент был скомпрометирован (например, имеет прикрепленный к нему вирус), то контент, даже без RO, мог бы причинить ущерб устройству. Также, в предзагрузочных взаимодействиях между устройством и CI (например, во время фазы обнаружения) скомпрометированное устройство может навредить CI, например, путем добавления вируса, прикрепленного к контенту, к сообщению, предназначенному для CI. К тому же, с точки зрения бизнеса, CI не захотел бы отправлять контент скомпрометированному устройству; например, скомпрометированное устройство может повторно распространять контент бесплатно несанкционированным получателям. Взаимный контроль целостности платформы (и SW) между устройством и CI, таким образом, обладает достоинствами в защите всей системы.

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

Контроль целостности платформы

Фиг.8 - блок-схема алгоритма способа 800 для выполнения проверки целостности платформы между двумя объектами. Двумя объектами могут быть устройство и RI, устройство и CI или RI и CI. Способ 800 использует запрашивающий объект (RE) и целевой объект (TE); отметим, что каждый объект из пары (устройство, RI или CI) может быть RE. Способ 800 работает аналогичным образом относительно того, какой объект является RE и какой объект является TE.

Способ 800 начинается с RE, отправляющего запрос к TE, чтобы сообщить свое состояние целостности платформы (этап 802). В ответ на запрос TE отправляет его учетные данные TCG к RE (этап 804). Учетные данные TCG могут включать в себя, например, учетные данные платформы, учетные данные TPM или учетные данные согласования. RE затем отправляет учетные данные TCG TE отвечающему устройству OCSP для проверки учетных данных (этап 806). Отвечающее устройство OCSP анализирует учетные данные TCG TE и сообщает RE состояние проверки (этап 808).

RE отправляет запрос к TE для сообщения своего собственного состояния целостности платформы (этап 810). TE проверяет свое состояние целостности платформы (этап 812), отправляет признак состояния целостности платформы к RE (этап 814), и способ завершается (этап 816).

Способ 800 может применяться либо без изменений в протоколах ROAP (обсуждается ниже в связи с фиг.9) или с изменениями в протоколах ROAP (обсуждается ниже в связи с фиг.10).

Контроль целостности без изменений в протоколах ROAP

Фиг.9 - блок-схема алгоритма способа 900 для обмена относящейся к целостности информации между устройством 902 и RI 904 с использованием методик TCG (то есть используя отвечающее устройство OCSP / PCA 906) отдельно от протокола ROAP. Отметим, что в способе 900 один и тот же объект 906 изображается являющимся как PCA для обработки DRM, а также отвечающим устройством OCSP для обработки TCG. В способе 900 проверка целостности платформы (которая показана пунктирным прямоугольником) выполняется перед 4-проходным протоколом ROAP регистрации. Выполнение проверки целостности платформы перед протоколом регистрации полезно, так как протокол регистрации не часто выполняется, и процесс проверки целостности платформы занимает некоторое время для завершения; если проверка целостности платформы выполнялась с каждым сообщением, общая работа системы могла бы излишне замедлиться. Специалист в данной области мог бы предположить, что после того, как выполнена проверка целостности платформы, только одно сообщение Приветствия устройств было бы принято RI, так как оно указывало бы надежное устройство. Если более одного сообщения Приветствия устройств было принято RI от одного и того же устройства, это могло бы быть указанием DoS-атаки. Проверка целостности платформы также могла бы выполняться в связи с протоколом аутентификация и протоколом получения объекта.

Устройство 902 перед запуском 4-проходного протокола регистрации с RI 904 запускает отдельный набор процедур с RI 904 для выполнения взаимной проверки целостности платформы. Устройство 902 сначала отправляет свои собственные учетные данные TCG (например, учетные данные платформы, учетные данные TPM, учетные данные согласования и т.д.) или другую информацию, включающую или имеющую отношение к учетным данным TCG, к RI 904 (этап 910). При желании, устройство 902 также отправляет запрос к RI 904 для проверки и сообщения устройству 902 своего собственного состояния целостности платформы; этот запрос включается в учетные данные устройства.

RI 904 запрашивает у PCA 906 проверить учетные данные TCG устройства (этап 912). PCA 906 отвечает на запрос RI и отправляет информацию об учетных данных TCG устройства (этап 914).

RI 904 запрашивает у устройства 902 сообщить свой признак состояния целостности платформы (этап 916). Также, если устройство 902 запросило, чтобы RI 904 проверило и сообщило свое состояние целостности платформы на этапе 910, и если RI 904 желает и способно удовлетворить запрос, то RI 904 отправляет устройству 902 свои собственные учетные данные TCG или другую информацию, включающую или имеющую отношение к учетным данным TCG, на этапе 916. Если RI 904 не может или не желает удовлетворить запрос, он отправляет "не обязывающее" сообщение устройству. RI 904 может не отвечать на запрос по некоторому количеству причин, включая ограниченный в ресурсах RI (то есть RI не обладает достаточными доступными ресурсами для ответа на запрос) или неудачи проверки достоверности устройства. Устройство может аварийно завершить протокол в зависимости от уровня доверия, который есть у устройства с RI; если устройство доверяет RI, то оно, вероятно, продолжило бы протокол, даже если RI отказался отвечать на запрос. После приема запроса от RI 904 для проверки состояния платформы устройство 902 проверяет свое собственное состояние целостности платформы (этап 918).

Устройство 902 запрашивает у PCA 906 проверить учетные данные TCG у RI (этап 920). PCA 906 после такого приема запроса от устройства 902 возвращает информацию об учетных данных TCG RI (этап 922). Устройство 902 отправляет свой флаг состояния целостности платформы к RI 904 (этап 924). Если RI 904 принял запрос от устройства 902 для проверки своего состояния целостности, и если RI 904 желает и может удовлетворить запрос, то RI 904 проверяет свою собственную целостность платформы (этап 926). RI затем возвращает свой флаг состояния целостности платформы устройству 902 (этап 928). Необязательные этапы касательно проверки целостности RI могут выполняться в любом порядке; эти этапы не нужно смешивать с проверкой целостности устройства, которая показана на фиг.9. К тому же, RI может начать свою собственную проверку целостности. Также, если RI отказывается полностью ответить на запрос с информацией о своих собственных полномочиях TCG по любым возможным причинам, оно может указывать такой факт устройству соответствующим образом, например, на этапе 922.

Способ 900 дает устройству 902 и RI 904 возможность осуществить взаимную проверку целостности платформы. После такой проверки устройство может затем начать протокол регистрации ROAP. Этапы протокола регистрации (этапы 930-940), показанные на фиг.9, являются теми же, что и этапы 210-220 способа 200, описанного выше. Также отметим, что эти процедуры могут запускаться или повторяться с периодическими интервалами.

Контроль целостности с изменениями в протоколе регистрации ROAP

Фиг.10 в другом типовом варианте осуществления показывает способ 1000, в котором устройство 1002 и RI 1004 обмениваются относящейся к целостности информацией, также используя услуги отвечающего устройства OCSP/PCA 1006. В способе 1000 существующие сообщения Приветствия устройств и Приветствия RI в протоколе регистрации ROAP изменяются для передачи как учетных данных TCG, так и запроса другой стороне на проверку целостности платформы.

Устройство 1002 отправляет измененное сообщение Приветствия устройств к RI 1004 (этап 1010), причем сообщение включает в себя учетные данные TCG устройства и необязательный запрос к RI 1004 для сообщения его целостности платформы. RI 1004 перенаправляет учетные данные устройства к PCA 1006 для контроля (этап 1012). PCA 1006 затем возвращает учетные данные TCG устройства к RI 1004 (этап 1014). RI 1004 отвечает устройству 1002 измененным сообщением приветствия RI (этап 1016), причем сообщение при желании включает в себя учетные данные TCG RI.

Далее устройство 1002 при желании отправляет запрос к PCA 1006 для проверки учетных данных TCG RI (этап 1018). PCA 1006 проверять учетные данные у RI и информирует о результате устройство 1002 (этап 1020). Устройство 1002 проверяет свое собственное состояние целостности (этап 1022) и сообщает RI 1004 состояние целостности (этап 1024).

Если устройство 1002 запросило, чтобы RI 1004 сообщил его состояние целостности, то RI 1004 выполняет проверку целостности платформы (этап 1026) и информирует устройство 1002 о состоянии целостности, например о его признаке достоверного состояния (этап 1028). Этапы 1030-1036 являются теми же, что и этапы 214-220, которые показаны на фиг.2 протокола регистрации ROAP.

Проверка целостности программного обеспечения DRM

Фиг.11 - блок-схема алгоритма способа 1100 для проверки целостности SW DRM (например, SW агента пользователя DRM, находящееся в устройстве, или SW DRM, находящееся в RI или CI) среди любой пары объектов DRM. Запрашивающий объект (RE) отправляет запрос целевому объекту (TE) для выполнения проверки целостности SW DRM (этап 1102). TE проверяет целостность своего SW DRM (этап 1104), отправляет признак состояния целостности SW DRM к RE (этап 1106), и способ завершается (этап 1108). Отметим, что когда TE является устройством, целостность драйверов устройства и SW медиаплеера может проверяться отдельно от целостности SW DRM, если эти два компонента существуют отдельно на устройстве.

Способ 1100 относится только к RE, получающему от TE проверку целостности SW DRM. Для выполнения взаимной проверки целостности SW DRM было бы необходимо выполнить способ 1100 дважды, один раз от RE для TE и затем от TE для RE (с переключающимися ролями RE и TE). Во время взаимной проверки целостности SW DRM запросы могут смешиваться (как показано на фиг.12) или могут разделяться, как показано на фиг.11. Работа способа не меняется, если выполняется взаимная проверка целостности SW DRM.

Спецификация DRM 2.0 OMA предполагает, без предложения того, как такие предположения могут быть законно реализованы, что SW агента пользователя DRM (или SW DRM устройства, в использованной в настоящем изобретении терминологии), а также RI (или SW DRM RI) могут быть неявно проверены. Протокол аутентификации в спецификации DRM 2.0 OMA, соответственно, задает только фактические процедуры аутентификации между объектами, которые уже рассматриваются как заслуживающие доверия. По очевидным причинам, это неявное допущение доверия к SW на практике не может предполагаться автоматически, без реальных этапов для реализации и его проверки. Способы, описанные в этом разделе, имеют отношение к таким конкретным этапам.

Фиг.12 - блок-схема алгоритма способа 1200 для применения проверки SW DRM в связи с протоколом ROAP получения RO. Способ 1200 использует устройство 1202, RI 1204 и отвечающее устройство OCSP/PCA 1206. Сначала PCA 1206 взаимодействует с устройством 1202 и RI 1204 для выполнения проверки целостности платформы и протокола ROAP регистрации (этап 1210). Устройство 1202 и RI 1204 выполняют взаимную проверку целостности платформы, однонаправленную проверку целостности SW DRM или взаимную проверку целостности SW DRM (этап 1212).

RI 1204 отправляет запрос устройству 1202, чтобы проверить и сообщить целостность SW агента пользователя (UA) DRM в устройстве (этап 1214). Устройство 1202 проверяет его последнюю целостность SW UA DRM (этап 1216). Устройство 1202 при желании отправляет запрос к RI 1204, чтобы проверить и сообщить целостность SW DRM у RI (этап 1218). Если запрашивается, то RI 1204 проверяет его последнюю целостность SW DRM (этап 1220). Устройство 1202 отправляет RI 1204 флаг состояния целостности SW DRM устройства (этап 1222). Если ранее запрашивалось, то RI 1204 отправляет устройству 1202 флаг состояния целостности SW DRM в RI (этап 1224) Отметим, что этапы необязательной проверки целостности RI могут выполняться в любом порядке и их не нужно смешивать с проверкой целостности устройства, которая показана на фиг.12.

Отметим, что способ 1200 может обобщен для взаимного контроля целостности SW DRM между устройством и CI, вместо проиллюстрированного взаимодействия устройства/RI. После завершения этапов 1210-1224 устройство 1202 может начать, например, 2-проходный протокол получения RO на этапах 1226 и 1228, которые являются теми же, что и этапы 310 и 312, которые описаны выше в связи с фиг.3. Дополнительно отметим, что хотя способ 1200 показывается в сочетании с протоколом получения RO, он может использоваться в сочетании с любым другим протоколом ROAP, но для минимизации издержек, связанных со способом 1200, он мог бы выполняться только с соответственно выбранным подмножеством протоколов ROAP в любое заданное время. Для практической реализации системы DRM OMA некоторые из условий или механизмов запуска для предложенных процедур проверки целостности платформы и/или SW DRM, описанных выше, могут включать в себя:

1. Процедуры проверки целостности SW DRM устройства могут запускаться с помощью одного или более из следующего.

1A. Перед тем, как устройство желает начать новый 2-проходный протокол ROAP регистрации, 2-проходный протокол присоединения к домену или 2-проходный протокол выхода из домена.

1B. Периодически, каждый раз как истекла заданная длительность времени, например T_{DEV-DRM-LAST-ROAP}, с тех пор как устройство последний раз завершило 2-проходный протокол ROAP регистрации, 2-проходный протокол присоединения к домену или 2-проходный протокол выхода из домена с тем же самым RI.

1C. Периодически, каждый раз как истекла заданная длительность времени, например T_{DEV-DRM-LAST-REPORT}, с того последнего момента, как устройство проверяло и сообщало состояние целостности своего SW DRM тому же RI.

1D. Всякий раз, когда устройство обновляет свое SW DRM.

1E. Всякий раз, когда платформа SW обновляется или изменяется.

2. Процедуры проверки целостности DRM RI могли бы выполняться с помощью одного или более из следующего.

2A. Всегда, когда RI принимает указание от устройства, что устройство желает, чтобы RI проверил состояние целостности своего SW DRM для устройства, либо как отдельное сообщение, либо как часть сообщения по измененному протоколу ROAP.

2B. Периодически, каждый раз как истекла заданная длительность времени, например T_{RI-DRM-LAST-REPORT}, с того последнего момента, как RI проверило и сообщило устройству состояние целостности своего SW DRM.

2C. Всякий раз, когда RI обновил свое SW DRM.

2D. Каждый раз перед тем, как устройство отправляет запрос RO в случаях, где пользователь является получающим контент на повторяющейся основе, например с потоковым контентом.

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

Предложенные способы для проверки платформы DRM и проверки SW DRM могут выполняться независимо друг от друга, но также предполагается, что эти процедуры проверки могут объединяться как часть группы процедур. В таком варианте осуществления этапы проверки платформы DRM рассматриваются как предварительное условие для этапов проверки SW DRM. Например, для проверки целостности между устройством и RI устройство и RI сначала устанавливают доверие на всей платформе друг друга путем выполнения процедур проверки платформы DRM, которые описаны выше. Механизмы запуска включают в себя общие условия запуска проверки платформы. Затем, так как возникают условия для запуска проверки SW DRM, следует процедура проверки SW DRM. Отметим, что оба типа процедур проверки будут выполняться, когда выполняются их соответствующие условия запуска. Однако этапы проверки SW DRM будут управляться до успешного завершения этапов проверки платформы DRM, то есть если проверка платформы DRM терпит неудачу между устройством и RI, то дальнейшая обработка в проверке SW DRM, а также фактическая обработка ROAP DRM и связанная с использованием обработка потерпят неудачу.

Запечатанное подписание и привязка

Существующие механизмы спецификации DRM 2.0 OMA для защиты целостности протокола ROAP ограничены на включение цифровых подписей (или проверки целостности сообщения) в некоторые, но не все сообщения ROAP. С учетом того, что протокол ROAP представляет основную значимость в реализации защищенной обработки DRM, важно защищать и все время проверять целостность информации, которая используется и обменивается в протоколе ROAP.

Поэтому в альтернативном варианте осуществления настоящего изобретения раскрываются способы для усиления целостности протокола ROAP, при помощи которых информация, важная в надежной аутентификации и проверке целостности между устройством DRM и RI, может быть: (1) надежно сохранена с использованием методик TCG, и (2) предварительно проверена перед передачей другой стороне или перед использованием для обработки на стороне, где хранится информация.

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

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

Каждый из устройства и RI могут выделить и использовать набор из двух ключей защиты памяти для криптографической привязки и надежного хранения некоторой информации, имеющей отношение к обработке ROAP для достоверной платформы, на которой находится устройство или RI. Для устройства этими ключами являются K_DEV_BIND_A и K_DEV_BIND_B. Для RI этими ключами являются K_RI_BIND_A и K_RI_BIND_B. Эти ключи являются асимметричными ключами с поддержкой TPM (то есть шифрование выполняется с открытым ключом, а дешифрование выполняется с личным ключом, защищенным внутри TPM).

Каждый из устройства и RI используют либо один PCR, либо множество PCR для обработки DRM. Устройство и RI также выделяют и используют Ключ удостоверения подлинности (AIK) для запечатанной подписи некоторой информации, имеющей отношение к обработке ROAP, для достоверной платформы и ее конкретных значений PCR. Отметим, что ключи AIK TCG используются только для подписания значений PCR. Для устройства его AIK является K_DEV_AIK, а для RI его AIK является K_RI_AIK. Также, запечатанное подписание требует асимметричного ключа защиты памяти для операции шифрования целевых данных. Устройство и RI, таким образом, выделяют и используют ключ защиты памяти для этой цели. Ключом защиты памяти для устройства является K_DEV_STO_SEAL, а ключом защиты памяти для RI является K_RI_STO_SEAL.

Способ тогда использует сочетание запечатанного подписания и привязки с дополнительной степенью защиты конфиденциальности, а также целостности для повышения стойкости хранения различных элементов информации, вовлеченных в обработку ROAP. Например, фиг.13 - блок-схема алгоритма способа 1300, в котором используются операции TPM запечатанного подписания и привязки для защиты конфиденциальности и целостности информации в различных сообщениях, которые содержат 4-проходный протокол ROAP регистрации. В способе 1300 каждый из устройства 1302 и RI 1304 подписывают с запечатыванием выборочное множество связанной с ROAP информации и привязывают информацию, используя два набора ключей защиты памяти, которые каждый либо передает (другой стороне), либо принимает (от другой стороны) во время хода 4-проходного протокола регистрации.

Устройство 1302 сначала подписывает с запечатыванием элемент информации ID устройства (который в случае DRM OMA является хэшем SHA-1 открытого ключа DRM OMA) с помощью ключа шифрования K_DEV_STO_SEAL и специфичного для устройства ключа удостоверения подлинности K_DEV_AIK (этап 1310). Эта информация привязывается (используя асимметричное шифрование) к другой информации, предназначенной для сообщения Приветствия устройств, с помощью ключа защиты памяти K_DEV_BIND_A (этап 1310). Сообщение Приветствия устройств затем отправляется от устройства 1302 к RI 1304 (этап 1312).

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

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

RI 1304 после приема сообщения Приветствия устройств привязывает информацию, содержащуюся в сообщении Приветствия устройств, с помощью его ключа привязки, K_ RI_BIND_A (этап 1314). Этот этап делает возможным безопасное хранение с защитой целостности информации о ключе, которую RI 1304 принял от устройства 1302. В качестве альтернативы RI 1304 также может извлекать ID устройства (или любой другой элемент информации) из сообщения Приветствия устройств и отдельно подписывать с запечатыванием элемент информации, используя ключ удостоверения подлинности K_RI_AIK и ключ шифрования K_RI_STO_SEAL.

RI 1304 подписывает с запечатыванием элементы информации ID RI и URL RI с помощью ключа шифрования K_RI_STO_SEAL и ключа удостоверения подлинности K_RI_AIK (этап 1316). RI 1304 также привязывает другую информацию, содержащуюся в его сообщении приветствия RI, с помощью ключа защиты памяти K_ RI_BIND_A (этап 1316). Затем RI 1304 отправляет сообщение приветствия RI устройству 1302 (этап 1318).

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

Устройство 1302 после приема сообщения приветствия RI привязывает информацию, содержащуюся в сообщении приветствия RI, с помощью второго ключа привязки, то есть K_DEV_BIND_B (этап 1320). Этот этап делает возможным безопасное хранение с защитой целостности информации о ключе, которую устройство приняло от RI 1304. В качестве альтернативы устройство 1302 также может извлекать выбранные элементы информации из принятого сообщения приветствия RI (например, ID RI и/или URL RI) и подписывать с запечатыванием, используя ключ удостоверения подлинности K_DEV_AIK и ключ шифрования K_DEV_STO_SEAL, наряду с простой привязкой оставшейся информации, принятой в сообщении приветствия RI, используя K_DEV_BIND_B.

Устройство 1302 подписывает с запечатыванием цепочку сертификатов, хэш DCF и Время запроса с помощью K_DEV_AIK и K_DEV_STO_SEAL (этап 1322). Устройство 1302 затем привязывает другую информацию, предназначенную для сообщения с Запросом регистрации, с помощью K_DEV_BIND_A (этап 1322). Затем устройство 1302 отправляет сообщение с Запросом регистрации к RI 1304 (этап 1324). Устройство 1302 только отправляет сообщение с Запросом регистрации, если устройство восстанавливает (то есть удаляет подпись с распечатыванием и отвязывает) ранее подписанную с запечатыванием и привязанную информацию, сравнивает восстановленные значения с текущими временными значениями, использованными в памяти SW DRM, и проверяет подлинность и целостность текущих значений. После приема сообщения с Запросом регистрации RI 1304 привязывает информацию из сообщения с Запросом регистрации с помощью ключа привязки K_RI_BIND_B (этап 1326).

RI 1304 подписывает с запечатыванием ключи, цепочку сертификатов и RO с помощью K_RI_AIK и K_RI_STO_SEAL (этап 1328). RI 1304 затем привязывает это вместе с другой информацией, которая должна быть включена в Ответное сообщение регистрации, с помощью ключа привязки K_ RI_BIND_A (этап 1328). Затем RI 1304 отправляет Ответное сообщение регистрации устройству 1302 (этап 1330). RI 1304 только отправляет Ответное сообщение регистрации, если RI восстанавливает (то есть подписывает с распечатыванием и отвязывает) ранее подписанную с запечатыванием и привязанную информацию, сравнивает восстановленные значения с текущими временными значениями, использованными в запоминающем устройстве SW DRM, и проверяет подлинность и целостность текущих значений. После приема Ответного сообщения регистрации устройство 1302 привязывает сформированную RI информацию из Ответного сообщения регистрации с помощью ключа привязки K_DEV_BIND_B (этап 1332).

Отметим, что запечатанное подписание и привязка могут использоваться с любым другим протоколом ROAP. Способ 1300, описанный выше, является типовым и его принципы могут в равной степени применяться к любому другому протоколу ROAP. Данные, полученные во время обменов сообщениями ROAP в DRM OMA, нужно будет распечатать и повторно запечатать для значения PCR в новой конфигурации, если объект, который запечатал или подписал с запечатыванием данные, обновил либо свою OS платформы, либо SW DRM. Когда возникает такое событие, связанные с ROAP данные DRM, которые были запечатаны или подписаны с запечатыванием для конкретного состояния (или, равносильно, для конкретного множества значений PCR), нужно будет сначала распечатать и затем повторно запечатать для текущего состояния обновленной OS платформы. Имеются существующие методики в предшествующем уровне техники, которые направляют усилия на это процедурное требование, и предполагается, что такие процедуры будут происходить, чтобы обеспечить надлежащее распечатывание и повторное запечатывание любых связанных с ROAP данных DRM, которые хранятся с использованием запечатывания или запечатанного подписания, как предложено в этом документе.

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

Модификация сообщения приветствия устройств и его образования

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

Второй модификацией является использование специфичных для устройства учетных данных EK TCG или учетных данных AIK TCG для хэширования и выведения ID устройства DRM. Преимущество этой модификации в том, что учетные данные EK и/или учетные данные AIK сильно защищены с помощью TPM внутри устройства, и поэтому выведение ID устройства DRM из любых этих учетных данных усиливает целостность информации о ID устройства DRM.

Третьей модификацией является добавления нового параметра подписи, где сообщение Приветствия устройств, все за исключением подписи, подписывается с помощью секретного ключа AIK устройства, предназначенного для проверки с помощью RI. Преимуществом этой модификации является защита целостности возможности TPM устройства из первого взаимодействия между устройством и RI. Использование личного ключа AIK устройства, который надежно защищен с помощью TPM, усиливает целостность операции подписания.

Таблицы 12 и 13 показывают два возможных формата для модифицированного сообщения Приветствия устройств. Таблица 12 показывает формат сообщения с разрядом DTCI в качестве первого параметра. Таблица 13 показывает формат сообщения Приветствия устройств, где DTCI является новым элементом в существующем параметре Расширения.

Модификация сообщения Приветствия RI и его образования

Первой модиикацией является добавление нового Индикатора возможности TPM у RI (RTCI), который является индикатором возможности TPM у RI, либо как новый элемент в существующем параметре Расширения в сообщении Приветствия RI, либо в качестве альтернативы и предпочтительно, добавление RTCI в качестве нового первого параметра в заголовок сообщения Приветствия RI. Преимущество этой модификации в том, что она позволяет устройству использовать информацию RTCI для оценки достоверности RI и использовать такую информацию в дальнейшем взаимодействии с RI в оставшейся части процедур протоколов ROAP.

Второй модификацией является использование TPM RI для предоставления псевдослучайного числа для ID сеанса. Преимущество этой модификации в том, что TPM предоставляет сильно защищенный аппаратный генератор псевдослучайных чисел. Использование TPM для формирования псевдослучайного числа, которое используется в качестве ID сеанса, усиливает защиту протокола.

Третьей модификацией является использование учетных данных EK TCG в RI или учетных данных AIK TCG, принадлежащих TPM RI, для выведения ID RI. Преимущество этой модификации в том, что учетные данные EK и/или учетные данные AIK сильно защищены с помощью TPM внутри устройства, и выведение ID устройства DRM из любых этих учетных данных усиливает целостность информации о ID устройства DRM.

Четвертой модификацией является использование TPM RI для предоставления одноразового номера RI. Преимущество этой модификации в том, что TPM предоставляет сильно защищенный аппаратный генератор псевдослучайных чисел. Использование TPM для формирования одноразового номера RI усиливает целостность одноразового номера, который используется в сообщении приветствия RI.

Пятой модификацией изменением является включение учетных данных TCG устройства в доверяемую устройством привязку RI. Учетные данные TCG устройства включают в себя учетные данные EK, учетные данные AIK, учетные данные платформы и учетные данные совместимости, которые RI предварительно получил от достоверного CA TCG. Преимуществом этой модификации является повышение доверия, которым устройство может обладать в сообщении приветствия RI.

Шестой модификацией является добавление подписи сообщения приветствия RI вплоть до и исключая подпись, сделанную с помощью личного ключа AIK у RI, где открытый ключ AIK RI ранее выделен устройству как часть сообщения приветствия RI. Преимуществом этой модификации является защита целостности RTCI из первого взаимодействия между RI и устройством. Использование личного ключа AIK RI, который надежно защищен с помощью TPM RI, усиливает целостность операции подписания.

Таблицы 14 и 15 показывают два возможных формата для модифицированного сообщения Приветствия RI. Таблица 14 показывает формат сообщения приветствия RI с разрядом RTCI в качестве первого параметра. Таблица 15 показывает формат сообщения Приветствия RI, где RTCI является новым элементом в существующем параметре Расширения.

Модификация для сообщения с Запросом регистрации и его

образования

Первой модификацией является использование TPM устройства для предоставления одноразового номера устройства. Преимущество этой модификации в том, что TPM предоставляет защищенное и надежное псевдослучайное число, подходящее для использования для одноразового номера.

Второй модификацией является включение учетных данных TCG устройства в цепочку сертификатов. Включение учетных данных TCG устройства может быть в виде либо замены, либо дополнения к существующим в DRM 2.0 OMA учетным данным устройства. Преимуществом включения учетных данных TCG (например, учетных данных EK, учетных данных AIK, учетных данных платформы или учетных данных совместимости) является добавка к достоверности устройства.

Третьей модификацией является включение списка CA TCG, которым доверяет RI, в доверяемый RI элемент привязки. Включение CA TCG, которым доверяет RI, может быть в виде либо замены, либо дополнения к существующим в DRM 2.0 OMA спискам доверяемых RI элементов привязки. Преимуществом включения списка CA TCG, которым доверяет RI, является добавка к достоверности устройства.

Четвертой модификацией является включение информации о TPM устройства в элемент Подробностей об устройстве в параметре Расширений. Преимуществом включения этой информации является повышение достоверности устройства для RI.

Пятой модификацией является подписание Подписи с помощью AIK устройства, использованного для подписания измененного сообщения Приветствия устройств. Преимуществом этой модификации является добавка к достоверности устройства и сообщения с Запросом регистрации вследствие сильно защищенной природы AIK устройства.

Таблица 16 показывает формат для модифицированного сообщения с Запросом регистрации.

Модификация Ответного сообщение регистрации и его образования

Первой модификацией является использование TPM RI для предоставления псевдослучайного числа для ID сеанса. Преимущество этой модификации в том, что TPM предоставляет сильно защищенный аппаратный генератор псевдослучайных чисел. Использование TPM для формирования псевдослучайного числа, которое используется в качестве ID сеанса, усиливает защиту протокола.

Второй модификацией является использование учетных данных EK TCG в RI или учетных данных AIK TCG, принадлежащих TPM RI, для выведения ID RI. Преимущество этой модификации в том, что учетные данные EK и/или учетные данные AIK сильно защищены с помощью TPM внутри устройства, и выведение ID устройства DRM из любых этих учетных данных усиливает целостность информации о ID устройства DRM.

Третьей модификацией является использование TPM RI для предоставления одноразового номера RI. Преимущество этой модификации в том, что TPM RI предоставляет защищенное и надежное псевдослучайное число, подходящее для использования в качестве одноразового номера.

Четвертой модификацией является включение списка CA TCG, которым доверяет устройство, в доверяемый устройством элемент привязки. Включение CA TCG, которым доверяет устройство, может быть в виде либо замены, либо дополнения к существующим в DRM 2.0 OMA спискам доверяемых устройством элементов привязки. Преимуществом включения списка CA TCG, которым доверяет устройство, является добавка к достоверности RI.

Пятой модификацией является подписание Подписи с помощью AIK RI, использованного для подписания измененного сообщения Приветствия RI. Преимуществом этой модификации является добавка к достоверности RI и Ответного сообщения регистрации вследствие сильно защищенной природы AIK RI.

Таблица 17 показывает формат для модифицированного Ответного сообщения регистрации.

Модификация Сообщения с запросом RO и его образования

Первой модификацией является использование TPM для создания хэша SHA-1 выбранных учетных данных TCG (учетные данные EK, учетные данные AIK, учетные данные платформа или учетные данные совместимости) для использования в качестве ID устройства. Преимущество этой модификации в том, что учетные данные сильно защищены с помощью TPM, и поэтому выведение ID устройства из одних из этих учетных данных усиливает целостность информации о ID устройства.

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

Третьей модификацией является включение учетных данных TCG устройства в цепочку сертификатов. Включение учетных данных TCG может быть в виде либо замены, либо дополнения к существующим в DRM 2.0 OMA учетным данным устройства. Преимуществом включения учетных данных TCG является добавка к достоверности устройства.

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

Пятой модификацией является подписание Сообщения с запросом RO с помощью AIK устройства, использованного для подписания последнего успешно отвеченного сообщения с Запросом регистрации. Преимуществом этой модификации является добавка к достоверности RI и Сообщения с запросом RO вследствие сильно защищенной природы AIK RI.

Таблица 18 показывает формат модифицированного сообщения с Запросом RO.

Модификация Ответного сообщения RO и его образования

Одной модификацией является использование TPM RI для подписи Ответного сообщения RO с помощью того же AIK у TPM RI, использованного в подписании последнего успешного Ответного сообщения регистрации. Преимуществом этой модификации является добавка к достоверности RI и Ответного сообщения RO вследствие сильно защищенной природы AIK RI.

Таблица 19 показывает формат модифицированного Ответного сообщения RO.

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

Варианты осуществления

1. Способ для выполнения проверки целостности платформы между запрашивающим объектом (RE) и целевым объектом (TE), содержащий этапы: отправки запроса от RE к TE, чтобы запросить у TE сообщить его учетные данные группы доверительных вычислений (TCG); отправки учетных данных TCG TE от TE к RE; перенаправления учетных данных TCG TE от RE к ответчику протокола состояния онлайновой сертификации (OCSP) для проверки; сообщения состояния проверки учетных данных TCG TE от ответчика OCSP к RE; отправки запроса от RE к TE, чтобы запросить у TE сообщить состояние целостности его собственной платформы; проверки состояния целостности платформы у TE; и отправки индикатора состояния целостности платформы от TE к RE.

2. Способ согласно варианту осуществления 1, в котором RE является эмитентом прав (RI), а TE является устройством.

3. Способ согласно варианту осуществления 2, в котором способ выполняется перед тем, как устройство инициирует протокол регистрации с RI, входящий в протокол получения объектов прав (ROAP), с помощью устройства, отправляющего триггер к RI для того, чтобы начать способ.

4. Способ согласно вариантам осуществления 2 или 3, в котором способ выполняется периодически на основе истекшего времени с момента, когда устройство последний раз регистрировалось с RI.

5. Способ согласно одному из вариантов осуществления 2-4, в котором способ выполняется периодически на основе истекшего времени с момента, когда устройство последний раз проверяло состояние целостности его платформы для RI.

6. Способ согласно варианту осуществления 1, в котором RE является устройством, а TE является эмитентом прав (RI).

7. Способ согласно варианту осуществления 6, в котором способ выполняется периодически на основе истекшего времени с момента, когда RI последний раз проверял состояние целостности его платформы для устройства.

8. Способ согласно варианту осуществления 1, в котором RE является эмитентом контента (CI), а TE является устройством.

9. Способ согласно варианту осуществления 8, в котором способ выполняется периодически на основе истекшего времени с момента, когда устройство последний раз проверяло состояние целостности его платформы для CI.

10. Способ согласно вариантам осуществления 8 или 9, в которых способ выполняется, когда устройство приобретает контент у CI.

11. Способ согласно варианту осуществления 1, в котором RE является устройством, а TE является эмитентом контента (CI).

12. Способ согласно варианту осуществления 11, в котором способ выполняется периодически на основе истекшего времени с момента, когда CI последний раз проверял состояние целостности его платформы для устройства.

13. Способ согласно вариантам осуществления 11 или 12, в которых способ выполняется, когда устройство приобретает контент у CI.

14. Способ согласно варианту осуществления 1, в котором способ выполняется как часть процесса по протоколу получения объектов прав (ROAP).

15. Способ согласно варианту осуществления 14, в котором способ выполняется перед процессом ROAP.

16. Способ согласно вариантам осуществления 14 или 15, в котором процесс ROAP модифицируется, чтобы содержать в себе способ как часть процесса ROAP.

17. Способ для выполнения проверки целостности программного обеспечения управления цифровыми правами (DRM) между запрашивающим объектом (RE) и целевым объектом (TE), содержащий этапы: отправки запроса от RE к TE, запрашивающего, чтобы TE выполнил проверку целостности программного обеспечения DRM; проверки с помощью TE целостности программного обеспечения DRM; и отправки индикатора состояния целостности программного обеспечения DRM от TE к RE.

18. Способ согласно варианту осуществления 17, в котором RE является эмитентом прав (RI), а TE является устройством.

19. Способ согласно варианту осуществления 18, в котором устройство отправляет триггер к RI, чтобы начать способ раньше устройства, инициирующего процесс по протоколу получения объектов прав (ROAP).

20. Способ согласно варианту осуществления 19, в котором процесс ROAP выбирается из группы, состоящей из: двухпроходной регистрации, двухпроходного присоединения к домену и двухпроходного выхода из домена.

21. Способ согласно вариантам осуществления 19 или 20, в котором способ выполняется периодически после того, как устройство завершило процесс по протоколу получения объектов прав (ROAP) с RI.

22. Способ согласно вариантам осуществления 19-21, в котором процесс ROAP выбирается из группы, состоящей из: двухпроходной регистрации, двухпроходного присоединения к домену и двухпроходного выхода из домена.

23. Способ согласно одному из вариантов осуществления 18-22, в котором способ выполняется периодически после того, как устройство проверило и сообщило RI состояние целостности его программного обеспечения DRM.

24. Способ согласно одному из вариантов осуществления 18-23, в котором способ выполняется после того, как устройство обновило его программное обеспечение DRM.

25. Способ согласно одному из вариантов осуществления 18-24, в котором RI запрашивает у устройства выполнить проверку целостности программного обеспечения DRM на медиаплеере в устройстве.

26. Способ согласно варианту осуществления 17, в котором RE является устройством, а TE является эмитентом прав (RI).

27. Способ согласно варианту осуществления 26, в котором способ выполняется при его инициации устройством.

28. Способ согласно вариантам осуществления 26 или 27, в которых способ является самостоятельным процессом.

29. Способ согласно одному из вариантов осуществления 26-28, в котором способ является частью модифицированного процесса по протоколу получения объектов прав.

30. Способ согласно одному из вариантов осуществления 26-29, в котором способ выполняется периодически после того, как RI проверил и сообщил устройству состояние целостности его программного обеспечения DRM.

31. Способ согласно одному из вариантов осуществления 26-30, в котором способ выполняется после того, как RI обновил его программное обеспечение DRM.

32. Способ согласно одному из вариантов осуществления 26-31, в котором способ выполняется раньше устройства, отправляющего запрос объекта прав к RI.

33. Способ согласно одному из вариантов осуществления 26-32, в котором способ выполняется периодически во время запроса потокового контента от устройства к RI.

34. Способ согласно варианту осуществления 17, в котором RE является эмитентом контента (CI), а TE является устройством.

35. Способ согласно варианту осуществления 34, в котором устройство отправляет триггер к CI, чтобы начать способ раньше устройства, инициирующего процесс по протоколу получения объектов прав (ROAP).

36. Способ согласно вариантам осуществления 34 или 35, в котором способ выполняется периодически после того, как устройство завершило процесс по протоколу получения объектов прав (ROAP) с CI.

37. Способ согласно одному из вариантов осуществления 34-36, в котором способ выполняется периодически после того, как устройство проверило и сообщило CI состояние целостности его программного обеспечения DRM.

38. Способ согласно одному из вариантов осуществления 34-37, в котором способ выполняется после того, как устройство обновило его программное обеспечение DRM.

39. Способ согласно одному из вариантов осуществления 34-38, в котором CI запрашивает у устройства выполнить проверку целостности программного обеспечения DRM на медиаплеере в устройстве.

40. Способ согласно варианту осуществления 17, в котором RE является устройством, а TE является эмитентом контента (CI).

41. Способ согласно варианту осуществления 40, в котором способ выполняется при его инициации устройством.

42. Способ согласно вариантам осуществления 40 или 41, в котором способ является самостоятельным процессом.

43. Способ согласно одному из вариантов осуществления 40-42, в котором способ является частью модифицированного процесса по протоколу получения объектов прав.

44. Способ согласно одному из вариантов осуществления 40-43, в котором способ выполняется периодически после того, как CI проверил и сообщил устройству состояние целостности его программного обеспечения DRM.

45. Способ согласно одному из вариантов осуществления 40-44, в котором способ выполняется после того, как CI обновил его программное обеспечение DRM.

46. Способ согласно одному из вариантов осуществления 40-45, в котором способ выполняется раньше устройства, отправляющего запрос объекта прав к CI.

47. Способ согласно одному из вариантов осуществления 40-46, в котором способ выполняется периодически во время запроса потокового контента от устройства к CI.

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

49. Способ согласно варианту осуществления 48, в котором этап сохранения включает в себя запечатанное подписание информации и привязку информации.

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

51. Способ согласно варианту осуществления 50, в котором этап подписания включает в себя использование состояния целостности платформы, на которой работает объект.

52. Способ согласно вариантам осуществления 50 или 51, в которых этап подписания включает в себя использование состояния целостности программного компонента объекта.

53. Способ согласно одному из вариантов осуществления 49-52, в котором этап привязки включает в себя асимметричное шифрование информации с помощью ключа, чей личный ключ расшифрования хранится в защищенном модуле в объекте.

54. Способ согласно варианту осуществления 53, в котором защищенный модуль является модулем доверительной обработки (TPM).

55. Способ согласно варианту осуществления 54, в котором TPM используется для выведения параметров для использования в сообщениях ROAP.

56. Способ согласно одному из вариантов осуществления 48-55, в котором информация выбирается из группы, состоящей из: идентификации устройства, идентификации эмитента прав, сертификата, цепочки сертификатов, значения времени, относящегося к управлению цифровыми правами, объекта прав, алгоритма и одноразового номера.

57. Способ согласно одному из вариантов осуществления 48-56, в котором способ применяется ко всем сообщениям ROAP.

58. Способ согласно одному из вариантов осуществления 48-56, в котором способ применяется отдельно от сообщения ROAP.

59. Способ согласно одному из вариантов осуществления 48-56, в котором способ интегрируется в формирование и передачу сообщений ROAP.

60. Способ согласно одному из вариантов осуществления 48-56, дополнительно содержащий этап добавления поля к существующим сообщениям ROAP для указания возможности доверительных вычислений у отправляющего объекта.

61. Система, сконфигурированная для выполнения способа согласно одному из вариантов осуществления 1-60.

62. Интегральная схема, сконфигурированная для выполнения способа согласно одному из вариантов осуществления 1-60.