Доставка обновлений политик для защищенного содержимого
Изобретение относится к секретной связи, а именно к управлению цифровыми правами для защиты контента. Техническим результатом является расширение функциональных возможностей способа доставки обновлений политик для защищенного контента. Технический результат достигается тем, что различные варианты реализации способа разрешают обновлениям политик быть доставленными и обновленными для заданной части защищенного контента. В одном варианте осуществления протокол передачи гипертекста (HTTP) используется для передачи обновлений политик. В другом варианте осуществления протокол поточной передачи в реальном времени (RTSP) используется для передачи обновлений политик. 3 н. и 7 з.п. ф-лы, 9 ил., 4 табл.
Уровень техники
Управление Цифровыми Правами (Digital Rights Management, DRM) обращается к техническим приемам, которые используются для защиты содержимого, таким как регулирование или ограничение использования цифрового медиасодержимого на электронных устройствах. Одной из характеристик DRM является то, что оно может привязывать медиасодержимое к заданной машине или устройству. Таким образом, лицензия, которая относится к конкретной части содержимого и которая определяет права и ограничения, связанные с этой частью содержимого, обычно будет привязана к заданной машине или устройству. В результате, пользователь обычно будет лишен возможности взять часть содержимого и переместить его на другую машину с целью воспроизведения содержимого.
Другой характеристикой некоторых видов DRM-защищенного содержимого является то, что некоторые типы содержимого, такие как ASF файлы, допускают применение только одного набора прав и ограничений, то есть «политик», ко всему файлу. Например, когда видеофайл отображается, может либо требоваться Macrovision, задействованный на аналоговом видеовыходе для всего файла, либо он может не требоваться вовсе. Для подобных специальных типов файлов пользователь не может изменить политики, привязанные к содержимому в середине файла или по ходу операций.
Раскрытие изобретения
Различные варианты воплощений разрешают обновлениям политик, таким как DRM обновления политик, быть доставленными и обновленными для заданной части защищенного содержимого. По крайней мере, в некоторых вариантах воплощений различные протоколы могут быть расширены до разрешения обновления политик к существованию и передаче протоколом. В одних вариантах воплощений протокол передачи гипертекста (Hypertext Transport Protocol, HTTP) используется для передачи обновлений политик. В других вариантах воплощений протокол потоковой передачи в реальном времени (Real Time Streaming Protocol, RTSP) используется для передачи обновлений политик.
Краткое описание чертежей
Фиг.1 иллюстрирует примерную процедуру регистрации протокола, при помощи которой варианты воплощения, представленные в данном изобретении, могут быть использованы в данном варианте воплощения.
Фиг.2 иллюстрирует примерную процедуру определения близости протокола, при помощи которого варианты воплощения, представленные в данном изобретении, могут быть использованы в данном варианте воплощения.
Фиг.3 иллюстрирует примерную процедуру создания сессии протокола, при помощи которого варианты воплощения, представленные в данном изобретении, могут быть использованы в данном варианте воплощения.
Фиг.4 иллюстрирует примерную процедуру передачи данных протокола, при помощи которого варианты воплощения, представленные в данном изобретении, могут быть использованы в данном варианте воплощения.
Фиг.5 иллюстрирует аспекты протокола поточной передачи, при помощи которого варианты воплощения, представленные в данном изобретении, могут быть использованы в соответствии с данным вариантом воплощения.
Фиг.6 иллюстрирует аспекты, связанные с Лицензиями Корня и Лицензиями листа, в соответствии с данным вариантом воплощения.
Фиг.7 является блок-схемой, которая описывает этапы способа в соответствии с данным вариантом воплощения.
Фиг.8 иллюстрирует процесс передачи информации между лицензиями корня и листа в соответствии с данным вариантом воплощения.
Фиг.9 иллюстрирует процесс передачи информации между лицензиями корня и листа в соответствии с данным вариантом воплощения.
Осуществление изобретения
Различные варианты осуществлений разрешают обновлениям политик, таким как DRM обновления политик, быть доставленными и обновленными для заданной части защищенного содержимого. По крайней мере, в некоторых вариантах воплощений различные протоколы могут быть расширены до разрешения обновления политик к существованию и передаче протоколом. В одних вариантах осуществлений протокол передачи гипертекста (Hypertext Transport Protocol, http) используется для передачи обновления политик. В других вариантах воплощений протокол поточной передачи в реальном времени (Real Time Streaming Protocol, RTSP) используется для передачи обновления политик.
В нижеследующих обсуждениях раздел, озаглавленный «Безопасность Содержимого и Протокол Передачи Лицензий», представлен и описывает одну конкретную систему, в которой могут быть применены технические приемы, представленные в данном изобретении. Следующей раздел “RTSP” представлен, чтобы дать читателю, незнакомому с RTSP, хотя бы некоторый контекст для понимания технических приемов, представленных в данном изобретении, в пространстве RTSP.
Следующий за этим разделом раздел, озаглавленный «Скрепление Лицензий Для Доставки Обновленных Политик», приведен и описывает понятие скрепления лицензий и как скрепленные лицензии могут быть использованы в контексте данного изобретения. Следующий за этим разделом раздел, озаглавленный «Доставка Обновленных Политик с Использованием HTTP», описывает, как скрепленные лицензии могут быть использованы в контексте HTTP для доставки обновлений политик. После этого раздела раздел, озаглавленный «Использование RTSP Для Передачи Лицензий Корня и Листа», описывает, как скрепленные лицензии могут быть использованы в контексте RTSP для доставки обновлений политик.
Безопасность Содержимого и Протокол Передачи Лицензий
Ниже предоставлено описание примерного протокола, который обеспечивает безопасность и передает лицензии для содержимого, передаваемого по цифровой ссылке. Данный протокол создается лишь как один примерный протокол, при помощи которого различные технические приемы, представленные в данном изобретении, могут быть применены. Необходимо принять во внимание и понять, что другие протоколы могут быть использованы без отступления от духа и объема приложенной формулы данного изобретения.
Следующие шифровальные условные обозначения использованы в этом описании:
| K{data} | Данные зашифрованы секретным ключом K |
| K[data] | Данные подписаны секретным ключом K |
| {data}device | Данные зашифрованы открытым ключом |
| устройства; | |
| [data]device | Данные подписаны частным ключом |
| устройства. |
В этом конкретном протоколе существуют пять основных процедур: Регистрация, Повторное подтверждение, Определение Близости, Установление Сессии и Передача данных.
В процедуре Регистрации передатчик (т.е. устройство, обладающее содержимым для передачи другому устройству) может однозначно и безопасно распознать предполагаемый приемник (т.е. устройство, которому содержимое передается). В этом конкретном протоколе передатчик содержит базу данных зарегистрированных приемников и гарантирует, что не более чем малое заранее установленное количество приемников будет использовано одновременно. Во время процесса регистрации передатчик также применяет процедуру Определения близости, чтобы убедиться, что приемник расположен в сети «близко» к передатчику, для того чтобы предотвратить широкое распространение защищенного содержимого.
Процедура Повторного подтверждения используется для того, чтобы убедиться, что приемник продолжает находиться «близко» к передатчику. Содержимое не доставляется приемникам, пока они не зарегистрированы или повторно не подтвердились в рамках заранее установленного в прошлом периода времени.
Процедура Установления Сессии используется всякий раз, когда приемник запрашивает содержимое от передатчика. Передатчик обязывает, чтобы устройство было зарегистрировано и недавно подтверждено, прежде чем Установление Сессии может быть завершено.
Когда сессия установлена, Передача данных запрашиваемого содержимого может быть осуществлена безопасным образом. Приемник может повторно использовать сессию для получения конкретных частей содержимого (поиск), но должен устанавливать новую сессию для получения другого содержимого.
Рассмотрим теперь процедуру Регистрации в связи с Фиг.1 и таблицей ниже, которая описывает различные сообщения, которые передаются между передатчиком и приемником во время регистрации.
Регистрации совместно с Фиг.1 и непосредственно нижерасположенной таблицей, которая описывает различные сообщения, которые передаются между передатчиком и приемником во время регистрации.
| Сообщение | Значение | Описание |
| Сообщение запроса регистрации | Ver | 8-битная версия протокола |
| Cert | цифровой сертификат XML на приемнике | |
| DId | 128-битный Серийный Номер | |
| Сообщение отклика регистрации | Ver | 8-битная версия протокола |
| {Seed} Device |
128-битное начальное число используется для получения Ключа Шифрования Содержимого и Ключа Целостности Содержимого | |
| SN | 128-битный Серийный Номер | |
| Address | Адрес сокета исходящих и входящих пакетов близости передатчика | |
| SId | 128-битный случайный идентификатор сессии | |
| Алгоритм Определения Близости | Алгоритм Определения Близости выполняется внеполосно |
В этом примере приемник отправляет сообщение запроса регистрации, которое содержит, среди прочей информации, цифровой сертификат приемника. Отзываясь на получение сообщения запроса регистрации, передатчик подтверждает сертификат приемника, генерирует начальное число и случайный идентификатор сессии, возвращая вышеупомянутое в форме, обозначенной выше, приемнику в сообщении отклика регистрации. Приемник затем подтверждает подпись передатчика, получает идентификатор сессии и выполняет другие действия, обозначенные на чертеже. Приемник и передатчик могут затем подвергнуться процессу определения близости, который описан ниже.
Что касается Повторного подтверждения, то те же самые процедуры, как и описанные выше, выполняются с тем отличием, что во время Повторного подтверждения приемник уже зарегистрирован в базе данных.
Что касается Определения близости, рассмотрим нижеследующее в связи с Фиг.2.
Во время процедуры Определения близости приемник отправляет передатчику сообщение, содержащее идентификатор сессии, определенный в Инициализирущем Сообщении Определения Близости. Передатчик затем отправляет приемнику сообщение, содержащее Nonce (128-битное случайное значение), и измеряет время, которое требуется приемнику, чтобы ответить с Nonce, зашифрованным Ключом Шифрования Содержимого. В заключение, передатчик отправляет сообщение приемнику, указывая, было ли определение близости успешным или нет.
Приемник может повторять процесс до тех пор, пока не получит подтверждения, что определение близости было успешным. Когда данный конкретный проток используется в сетях на основе IP, обмен сообщениями определения близости происходит по UDP. Приемник запоминает адрес передатчика из сообщения Отклика Регистрации. Нет необходимости отдельно сообщать адрес приемника, так как он может быть определен через изучение входящего заголовка IP UDP пакета, который несет Инициализирущее Сообщение Определения Близости.
Нижеследующая таблица описывает сообщения, которыми обмениваются в процессе Определения Близости.
| Сообщение | Значение | Описание |
| Сообщение Начала Близости | SId | Передатчиком передано то же значение 128-битного Идентификатора Сессии. |
| Сообщение Запроса Близости | Seq | 8-битный возрастающий порядковый номер. |
| SId | Тот же 128-битный Идентификатор Сессии. | |
| Nonce | 128-ми битное Случайной Значение. | |
| Сообщение Отклика Близости | Seq | Тот же порядковый номер, определенный передатчиком. |
| SId | Тот же 128-битный Идентификатор Сессии. | |
| KC {Nonce} | 128-битный Nonce зашифрован с использованием Ключа Шифрования Содержимого. | |
| Сообщение Результата Близости | SId | Тот же 128-битный Идентификатор Сессии. |
| Result | Код состояния, указывающий на успех или неудачу процедуры регистрации. |
Что касается Установления Сессии, рассмотрим нижеследующее в связи с Фиг.3 и таблицей ниже, которая описывает сообщения, которыми обмениваются во время Установления Сессии.
| Сообщение | Значение | Описание | |
| Сообщение Запроса Лицензии | Ver | 8-битная версия протокола. | |
| Cert | Цифровой сертификат XML на приемнике. | ||
| SN | 128-битный Серийный Номер. | ||
| Action | Запрошено применение содержимого. Например, «Проигрывание», «Копирование», «Прожигание». | ||
| RId | 128-битный случайный Идентификатор Прав. | ||
| VCRL | Версия CRL применика. | ||
| Сообщение Отклика Лицензии | Ver | 8-битная версия протокола. | |
| CRL | CRL передатчика. Отправляется только в случае, когда он обладает более высоким номером версии, чем CRL приемника, и компонент приемника так же обладает возможностями передачи. | ||
| License | KC (зашифрованный открытым ключом приемника). | 128-битный Случайный Ключ Шифрования Содержимого. | |
| KI (зашифрованный открытым ключом приемника). | 128-битный Случайный Ключ Целостности Содержимого. | ||
| VCRL | Версия VCRL передатчика. | ||
| RId | Тот же 128-битный случайный Идентификатор Прав, отправленный приемником. | ||
| SN | 128-битный Серийный Номер |
В этом примере Сообщение Запроса Лицензии отправляется от приемника к передатчику и содержит информацию, описанную выше. В отклике передатчик может отправить Сообщение Отклика Лицензии, которое содержит информацию, описанную выше.
В этом конкретном примере Лицензия представлена в XMR формате и содержит Ключ Шифрования Содержимого, Ключ Целостности Содержимого, Версию CRL Передатчика, 128-битный Идентификатор Прав и 128-битный Серийный Номер. Лицензия так же содержит OMAC, рассчитанный с использованием Ключа Целостности Содержимого, использующего OMAC.
Что касается процедуры Передачи данных, рассмотрим нижеследующее в связи с Фиг.4. Когда Установление Сессии завершено, выполняется передача данных специальным способом протокола проверки. И отклик, и запрос Передачи Данных должны быть специально определены для протокола проверки и типа содержимого. Это концептуально представлено на Фиг.4.
Теперь, обеспечив краткий обзор типичного протокола, с которым варианты воплощения, представленные в данном изобретении, могут быть применены, рассмотрим теперь некоторую основную информацию о RTSP.
RTSP
Протокол потоковой передачи в реальном времени (RTSP) представляет собой протокол на уровне приложений для управления доставкой данных со свойствами реального времени (т.е. потоковых), как будет определено специалистом в данной области техники. RTSP предоставляет расширяемую структуру для обеспечения управляемой доставки по запросу данных в реальном времени, таких как аудио и видео. Источники данных могут включать в себя и оперативные источники данных, и сохраненные кадры. Данный протокол предназначен, чтобы управлять многократными сессиями доставки данных, предоставлять средство для выбора каналов доставки, таких как UDP, группового UDP и TCP, и предоставить средство для выбора механизмов доставки, основанных на RTP.
RTSP устанавливает и управляет либо одним, либо несколькими синхронизированными во времени потоков непрерывных медиаданных, таких как аудио или видео. Обычно он не доставляет непрерывные потоки сам, хотя чередование непрерывного медиапотока с потоком управления возможно. Другими словами, RTSP действует как «удаленное управление сетью» для серверов мультимедиа.
Набор потоков, которые будут управляться, определяется описанием представления. У RTSP нет представления о подключении RTSP; вместо этого сервер поддерживает сессию, маркированную идентификатором. Сессия RTSP никоим образом не связана с подключением транспортного уровня, таким как подключение TCP. Во время RTSP сессии RTSP клиент может открыть и закрыть множество надежных транспортных соединений с сервером, чтобы получить в результате RTSP запрос. Иначе, он может использовать транспортный протокол без установления соединения, такой как UDP, как будет определено специалистом в данной области техники.
Потоки, контролируемые RTSP, могут использовать RTP, но деятельность RTSP не зависит от механизма транспортировки, используемого, чтобы передавать непрерывные медиаданные.
Рассмотрим теперь типичный RTSP обмен запросами/откликами в связи с Фиг.5, между клиентом/приемником 500 и сервером/передатчиком 502.
Предварительно, запросы/отклики RTSP обладают заголовками, которые, ради краткости, не описаны. В RTSP клиент/приемник 500 обычно генерирует то, что известно как запрос DESCRIBE, направленный на извлечение описания из представления или медиаобъекта, определенного в запросе URL от сервера 502. Сервер 502 откликается описанием запрошенного ресурса, который представлен в ПРОТОКОЛЕ ОПИСАНИЯ СЕССИИ (Session Description Protocol, SDP). Отклик DESCRIBE (SDP) содержит всю информацию инициализации медиаданных для ресурса(ов), которые он описывает.
Затем клиент 500 отправляет запрос SETUP на URL, который определяет механизм транспортировки, который будет использован для потоковых медиаданных. В примере на Фиг.5 запрос SETUP отправляется и для аудио, и для видео. Клиент 500 также указывает в запросе SETUP параметры транспортировки, которые он будет использовать. Заголовок транспортировки в запросе SETUP определяет параметры транспортировки, приемлемые для клиента для передачи данных. Ответ от сервера 502 содержит параметры транспортировки, выбранные сервером. Сервер также генерирует идентификаторы сессии в ответ на запросы SETUP.
С этой точки зрения, клиент может сгенерировать запрос PLAY, который говорит серверу начинать передавать данные при помощи механизма, определенного в SETUP. Отзываясь на получение запроса PLAY, сервер может начать передавать поток содержимого, который в этом примере является звуковым/видео содержимым. В этом примере передаваемое потоком содержимое инкапсулировано с использованием пакетов RTP и отправляется по UDP, как будет определено специалистом в данной области техники.
Протокол RTSP обладает другими способами, представляющими интерес, которые включают в себя PAUSE, TEARDOWN, GET_PARAMETER, SET_PARAMETER, REDIRECT и RECORD. Для дополнительных данных об RTSP читатель может обратиться к RTSP RFC, Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, available at http://www.ietf.org/rfc/rfc2326.txt, April 1998.
Скрепление Лицензий Для Доставки Обновленных Политик
В иллюстрированном и описанном варианте воплощения понятие о скреплении лицензий использовано в процессе обновления политики. В этом конкретном варианте воплощения используется понятие лицензии корня и лицензии листа. Здесь лицензия корня используется, чтобы установить и безопасно доставить ключ содержимого клиенту/приемнику так, чтобы клиент/приемник мог дешифровать доставленные впоследствии обновления политик, используя ключ содержимого. Как только начальный ключ содержимого безопасно доставлен клиенту/приемнику, последующие ключи содержимого могут быть зашифрованы сервером/передатчиком, используя первоначально доставленный ключ содержимого, и отправлены клиенту/приемнику. Используя первоначально доставленный ключ содержимого, клиент может дешифровать связанные обновления политик.
Чтобы предоставить только один пример того, как эта конкретная схема может быть реализована, рассмотрим следующее в связи с Фиг.6. В этом конкретном примере система на Фиг.6 сконфигурирована таким образом, чтобы использовать 1024-битные ключи RSA для операции шифрования открытым ключом и 128-битные AES ключи для симметричных операций шифрования. Конечно, как это предоставлено всего лишь как один пример и не предназначено, чтобы ограничить применение приложенной формулы данного изобретения.
В этом примере клиент/приемник 600 обладает парой 650 открытого/частного ключей, и сервер/передатчик 602 обладает открытым ключом клиента/приемника. В этом примере каждый из открытых и частных ключей клиента/приемника - это 1024-битный ключ RSA. Используя открытый ключ клиента/приемника, сервер/передатчик строит лицензию корня, которая содержит начальный ключ содержимого, которое зашифровано открытым ключом клиента/приемника. Начальный ключ содержимого - это 128-битный AES ключ содержимого. Эта лицензия корня затем отправляется клиенту/приемнику. На Фиг.6 это показано как первое сообщение, которое имеет место между клиентом/приемником и сервером-передатчиком, где зашифрованный ключ содержимого представлен как {ключ содержимого1}CLIENT. Необходимо принять во внимание, однако, что до иллюстрированного сообщения может иметь место другое сообщение.
Получив зашифрованный ключ содержимого от сервера/передатчика, клиент/приемник может теперь дешифровать ключ содержимого, используя свой частный ключ, и может надежно сохранить дешифрованный ключ содержимого для дальнейшего использования. В нижеследующем описании на этот первый ключ содержимого ссылаются как на инициализирующий ключ содержимого.
С этой точки зрения, рассмотрим то, что произошло. Сервер/передатчик надежно сообщил ключ клиенту/приемнику, что может теперь служить основанием для последующих шифровальных операций. Более определенно, представим теперь, что обновление политики должно быть сделано по отношению к определенной части DRM-защищенного содержимого в ходе потоковой передачи. В этом случае сервер/передатчик может подготовить лицензию листа, которая содержит обновленную политику. Эта лицензия листа содержит обновления политики и зашифрованную версию ключа2 содержимого. В этом примере, ключ2 содержимого - это 128-битный AES ключ содержимого, который был зашифрован с использованием инициализирующего ключа содержимого. Таким образом, вычислительная сложность и расходы, испытанные и понесенные клиентом/приемником, связанные с дешифровкой новых и дополнительных ключей содержимого, уменьшены, что связано с операциями с 1024-битным RSA ключом, потому что теперь клиент/приемник должен только дешифровать, используя 128-битный AES ключ содержимого (то есть инициализирующий ключ содержимого).
Для примера варианта реализации, в котором XMR используется, чтобы представить лицензию и обновление лицензии, рассмотрим нижеследующее.
Одна из целей использования скрепления лицензий состоит в том, чтобы сократить число асимметричных операций с ключами, выполняемых в ходе обновления лицензии. В этом примере варианта реализации не ставится акцент на использование лицензий корня как механизма для передачи прав и ограничений. В результате лицензии корня очень просты и не передают никаких прав или ограничений. Необходимо принять во внимание, однако, что лицензия корня может передавать права и ограничения, по крайней мере, в некоторых вариантах реализаций.
В этом примере лицензии листа связаны с лицензией корня через объект KID канала. Следующие разделы освещают объекты, присутствующие в этих лицензиях, в соответствии с данным вариантом воплощения.
С учетом лицензий корня, нижеследующее описывает набор XMR объектов, которые присутствуют в лицензии корня на Воспроизведение.
Структура Заголовка XMR
XMR Объект-контейнер
|
+--Объект-Контейнер Глобальной Политики
| |
| +--Минимальный Объект Среды
| |
| +--Объект Параметров настройки Прав
|
+--Объект-Контейнер Политики Воспроизведения
| |
| +--Объект Защиты Вывода
|
+--Объект-Контейнер Ключевого Носителя Информации
| |
| +--Объект Ключа Содержимого
|
+-- Объект XMR Подписи
Объект-Контейнер Политики Воспроизведения должен наличествовать, чтобы позволить Воспроизведению случиться. Лицензия Корня для действия Копии, с другой стороны, должна содержать Объект-Контейнер Права на Копирование вместо Контейнера Политики Воспроизведения.
Нижеследующее - это набор XMR объектов, которые присутствуют в Лицензии Корня на Копирование.
Структура Заголовка XMR
XMR Объект-Контейнер
|
+--Объект-Контейнер Глобальной Политики
| |
| +--Минимальный Объект Среды
| |
| +--Объект Параметров настройки Прав
|
+--Объект-Контейнер Политики Воспроизведения
| |
| +--Объект Защиты Вывода
|
+--Объект-Контейнер Права на Копирование
|
+--Объект-Контейнер Ключевого Носителя Информации
| |
| +--Объект Ключа Содержимого
|
+-- Объект XMR Подписи
В этом варианте воплощения Объект-Контейнер Права на Копирование должен присутствовать, чтобы указать, что Копирование разрешено. Обратите внимание, что Объект-Контейнер Политики Воспроизведения все еще присутствует, так как разрешение на Воспроизведение необходимо предоставлять всегда.
С учетом лицензий листа в этом конкретном варианте воплощения, рассмотрим нижеследующее. Лицензии листа могут содержать любой тип прав или ограничений, который может быть отражен через XMR. Главное различие между лицензией листа из скрепления и нескрепленной лицензией лежит в использовании симметричного ключа для шифрования ключа содержимого и его присоединения к другой лицензии через канал KID объекта.
Нижеследующее - это пример лицензии Листа для воспроизведения.
Структура Заголовка XMR
XMR Объект-Контейнер
|
+--Объект-Контейнер Глобальной Политики
| |
| +--Минимальный Объект Среды
|
+--Объект-Контейнер Политики Воспроизведения
| |
| +--Объект Защиты Вывода
| |
| +--Объект Списка Выводов с Пониженным Качеством
| |
| +--Объект Защиты Прямого Аналогового Видеовывода
|
+--Объект-Контейнер Ключевого Носителя Информации
| |
| +--Объект Ключа Содержимого
| |
| +-- Объект KID канала
|
+-- Объект XMR Подписи
У объекта Ключа Содержимого Тип Ключа Шифра Шифрования должен быть установленным в 0x0002 (Скрепленная Лицензия) и Тип Симметричного Шифра установленным в 0x0001 (AES CTR). У объекта KID Канала поле KID Канала должно быть установлено в KID лицензии Корня.
Нижеследующее - это пример лицензии Листа на копирование в данном конкретном варианте воплощения.
Структура Заголовка XMR
XMR Объект-Контейнер
|
+--Объект-Контейнер Глобальной Политики
| |
| +--Минимальный Объект Среды
|
+--Объект-Контейнер Политики Воспроизведения
| |
| +--Объект Защиты Вывода
| |
+--Объект-Контейнер Права на Копирование
| |
| +--Объект Ограничения по Числу Копий
| +--Объект Ограничения Уровня Защиты Копирования
|
+--Объект-Контейнер Ключевого Носителя Информации
| |
| +--Объект Ключа Содержимого
| |
| +-- Объект KID канала
|
+-- Объект XMR Подписи
В данном варианте воплощения Объект-Контейнер Права на Копирование должен присутствовать для того, чтобы указать, что Копирование разрешено. Объект Ограничения по Числу Копий присутствует, если есть ограничения по числу разрешенных копий. Объект Ограничения Уровня Защиты Копирования присутствует, если есть ограничения на системы, используемые как место назначения для копирования. Обратите внимание, что Объект-Контейнер Политики Воспроизведения все еще присутствует, так как разрешение на Воспроизведение необходимо предоставлять всегда.
Фиг.7 - это блок-схема, которая описывает этапы в способе в соответствии с данным вариантом воплощения. Этот способ может быть выполнен на подключении с любыми подходящими аппаратными средствами, программным обеспечением, встроенным программным обеспечением или комбинацией этого. В данном варианте воплощения способ может быть осуществлен на подключении с системами, подобными тем, которые иллюстрированы и описаны выше. Дополнительно, в нижеследующем обсуждении, некоторые из действий, которые выполняются, изображены как будто выполняемые сервером/передатчиком, а другие действия изображены как будто выполняемые клиентом/приемником. Примеры сервера/передатчиков и клиента/приемников приведены выше.
Этап 700 зашифровывает инициализирующий ключ содержимого, используя открытый ключ клиента/приемника. Любой подходящий ключ содержимого может быть использован только содним примером, приведенным выше. Этап 702 отправляет лицензию корня, содержащую зашифрованный инициализирующий ключ содержимого клиенту/приемнику. Любой подходящий способ может быть использован, чтобы осуществить этот этап. В нижеследующем рассуждении приведены два характерных примера, которые покрывают два различных протокола. Необходимо принять во внимание и понять, что оно вводит примеры и не призвано ограничить применение приложенной формулы данного изобретения лишь до описанных характерных примеров.
Этап 704 получает лицензию корня, отправленную сервером/передатчиком, а этап 706 дешифрует зашифрованный инициализирующий ключ содержимого. В этом примере этот этап выполняется при использовании частного ключа клиента/приемника, чтобы дешифровать зашифрованный инициализирующий ключ содержимого.
Этап 708 подготавливает лицензию листа и зашифровывает новый ключ содержимого инициализирующим ключом содержимого. этап 710 отправляет лицензию листа клиенту/приемнику. Вспомним, что лицензия листа может и обычно содержит политики и обновления политик для DRM-защищенного содержимого. Необходимо принять во внимание и понять, что этапы 708 и 710 могут быть выполнены многократно над определенной частью DRM-защищенного содержимого. Таким образом, по мере изменения политик для заданной части DRM-защищенного содержимого, соответствующая лицензия листа может быть подготовлена и отправлена клиенту/приемнику.
Этап 712 получает лицензию листа, а этап 714 дешифрует новый ключ содержимого, используя инициализирующий ключ содержимого, который был предварительно получен. Затем этап 716 использует дешифрованный новый ключ содержимого, чтобы дешифровать содержимое и обновить политики, которые содержатся в лицензии листа.
Необходимо принять во внимание и понять, что этапы 712, 714 и 716 могут быть выполнены над каждой новой лицензией листа, которая получается клиентом/приемником.
Доставка Обновленных Политик с Использованием HTTP
Обсудив понятие лицензий корня и листа и как каждая из них может быть использована в контекстах, описанных выше, рассмотрим теперь, как лицензия корня и листа может быть доставлена, используя HTTP.
Когда HTTP используется для передачи DRM-защищенного содержимого, клиент отправляет два запроса серверу/передатчику. Во-первых, клиент отправляет POST запрос, чтобы получить лицензию корня. Во-вторых, клиент отправляет GET запрос для получения DRM-защищенного содержимого. В этом примере клиент отправляет запросы, потому что в HTTP сервер обычно не может инициализировать коммуникацию с клиентом.
Конкретно, рассмотрим Фиг.8 в связи с нижеследующим рассуждением. Когда клиент желает получить лицензию корня, он отправляет серверу POST запрос. POST запрос содержит сообщение запроса лицензии, как рассмотрено выше. Отзываясь на получение этой коммуникации, сервер отвечает сообщением отклика лицензии, которое содержит лицензию корня, которая, по крайней мере, в данном варианте воплощения представлена в XMR. Получив лицензию корня и обработав ее соответственно, клиент отправляет GET запрос серверу, запрашивая DRM-защищенное содержимое. Отзываясь на GET запрос, сервер отвечает сегментами затребованного содержимого, чередуя их с одним или более сообщениями отклика лицензии. Каждое сообщение отклика лицензии содержит лицензию листа, которая относится к конкретной части DRM-защищенного содержимого. Любой подходящий механизм или техника чередования могут быть использованы для формулирования ответа сервера.
В качестве только одного примера варианта реализации в данном конкретном контексте рассмотрим нижеследующее.
В одном примере четырехбайтовый заголовок структуры используется, чтобы инкапсулировать данные и управляющие блоки. Заголовок структуры содержит однобайтовый ASCII знак доллара (0x24) со следующим за ним однобайтовым идентификатором типа блока, со следующей за ним двухбайтовой длиной инкапсулированных данных, представленных в порядке взаимосвязанных байтов.
| Секция | Поля |
| Заголовок | 8-битный ASCII знак доллара (0×24) |
| 8-битный идентификатор типа блока | |
| Длина данных | 16-битная длина инкапсулированных данных |
Управляющий блок использует ASCII символ 'c' (0x63) в качестве своего идентификатора типа. Этот блок содержит сообщение, обычно Сообщение Отклика Лицензии.
Блок Данных использует ASCII 'd' символ (0x63) в качестве своего идентификатора типа. Этот блок содержит описатель Сегмента Данных с непосредственно следующими за ним медиаданными.
Описатель Сегмента данных может быть связан с содержимым, которое зашифровано или открыто. Флажок шифрования в описателе передает эту информацию. Описатель Сегмента данных связан с частью передаваемого файла, к которому, в случае шифрования, применяются единая политика и ключ шифрования содержимого. Другими словами, ключ шифрования содержимого и политики не могут быть изменены в пределах сегмента.
В соответствии с данным вариантом воплощения типичный отклик HTTP с кодированием ссылки состоит из следующих блоков:
1. Управляющий блок [$c], несущий Сообщение Отклика Лицензии со Скрепленной Лицензией.
2. Один или более Блок Данных [$d].
В случае, если ключ или политика меняются в ходе передачи файла, тогда добавляются следующие этапы:
3. Новый Управляющий блок [$c], несущий Сообщение Отклика Лицензии с новой Скрепленной Лицензией.
4. Один или более Блок Данных [$d].
Заметим, что этапы 3 и 4 могут осуществляться многократное количество раз в случае многократной смены ключа или политики.
Использование RTSP Для Передачи Лицензий Корня и Листа
Обсудив понятие лицензий корня и листа и как каждая из них может быть доставлена с использованием HTTP, рассмотрим теперь, как лицензии корня и листа могут быть доставлены с использованием RTSP.
Одно из различий между RTSP и HTTP состоит в том, что RTSP гораздо сложнее, чем HTTP. А именно, RTSP обладает условиями для запросов, инициируемых сервером, что позволяет серверу отправлять команды клиенту в любое время. В соответствии с данным вариантом воплощения рассмотрим следующее в связи с Фиг.9.
Когда клиент/приемник желает воспроизвести DRM-защищенное содержимое, клиент отправляет DESCRIBE запрос, содержащий сообщение запроса лицензии. Отзываясь на получение этого сообщения, сервер отвечает ПРОТОКОЛОМ ОПИСАНИЯ СЕССИИ (SDP), который содержит сообщение отклика лицензии. Сообщение отклика лицензии содержит лицензию корня, которая в данном конкретном варианте воплощения представлена в XMR.
Теперь, когда клиент желает получить DRM-защищенное содержимое, клиент отправляет PLAY запрос серверу, чтобы запустить поток. В любое подходящее время сервер может послать клиенту ANNOUNCE запрос, несущий сообщение отклика лицензии, которое содержит лицензию листа.
В качестве примера варианта реализации рассмотрим нижеследующее. Рассмотрим сначала выдержку из DESCRIBE запроса ниже, которая содержит Сообщение Запроса Лицензии в соответствии с данным вариантом воплощения.
DESCRIBE rtsp://eduardo01/file.wmv RTSP/1.0
Accept: application/sdp
CSeq: 1
Supported: com.microsoft.wmdrm-nd, com.microsoft.wm.eosmsg, method.announce
Require: com.microsoft.wmdrm-nd
Content-Type: application/vnd.ms-wmdrm-license-request
Content-Length: 1078
License_Request_Message
В этом примере “Require: com.microsoft.wmdrm-nd” используется, чтобы указать, что приемник ожидает, что сервер окажется передатчиком определенного типа. В этом примере “Content-Type: application/vnd.ms-wmdrm-license-request” используется, чтобы указать, что основная часть DESCRIBE содержит Сообщение Запроса Лицензии.
Если нет ошибки, то передатчик должен ответить описанием SDP, которое содержит Сообщение Отклика Лицензии, описанное в разделе сразу ниже.
Получив DESCRIBE запрос, который содержит в основной части Сообщение Запроса Лицензии, сервер может возвратить Сообщение Отклика Лицензии. В этом примере сервер возвращает описание SDP, которое не только содержит различные параметры, описанные ранее, но также и Сообщение Отклика Лицензии. Как обозначено ранее, в данном варианте воплощения Сообщение Отклика Лицензии будет передавать XMR лицензию, которая диктует, какие политики применяются к содержимому.
В качестве только одного примера варианта реализации рассмотрим выдержку из SDP ниже, которая содержит Сообщение Отклика Лицензии в соответствии с данным вариантом воплощения.
RTSP/1.0 200 OK
Last-Modified: Thu, 19 Dec 2002 15:36:18 GMT
Content-Length: 1891
Content-Type: application/sdp
CSeq: 1
Supported: com.microsoft.wmdrm-nd, com.microsoft.wm.eosmsg, method.announce
SDP_Description
Возвращенная лицензия соответствует Лицензии Корня, которая будет использована на время сессии. Конкретные Лицензии Листа будут возвращены позднее посредством ANNOUNCE запросов, описанных ниже.
В соответствии с данным вариантом воплощения возвращенный передатчиком SDP содержит Сообщение Отклика Лицензии, закодированное в URL-данных согласно спецификации RFC-2397 (http://www.ietf.org/rfc/rfc2397.txt). В этом примере данные, содержавшиеся в URL-данных, должны быть закодированы Base64, и MIME тип должен быть установлен в “application/vnd.ms-wmdrm-license-response”.
В качестве примера синтаксиса рассмотрим следующее:
data:application/vnd.ms-wmdrm-license-response;base64, AggAAAAAAAABOFhNUgAAAAAB+TTbzXCRw1s+/jA4fQQY0wADAAEAAAEgAAMAAgAAADwAAQADAAAAEgBkAAAAAAAAAAAAAQAMAAAAGKRuHVtxsJ1Lk7WPrQPe5X0AAQANAAAACgABAAMABAAAABoAAQAFAAAAEgBkAGQAZABkAGQAAwAJAAAApgABAAoAAACeajiAiUBMGrAGUAOIqMGBggABAAEAgC7V1QF54EzuYbTYKPbgBEK6nDXGtbV+bJKF+Cn2yd/FUaC4vTIOxkF/eQLx+FqvLCUMtxvRSw01dns9Ejt021se2T+IROiZA0t5pRuNl3gq7JK9JKs+ZX8hKsEJFW0V7cyp9wdaCMh2esJ97r9agH1Sxf0mAqcQ0j1Q5dtXlWx/AAEACwAAABwAAQAQZZaX5nGEUAV8w6p6BQr++Q==
В этом примере URL-данные должны быть вставлены на уровне сессии SDP с использованием атрибута “a=key-mgmt” согласно спецификации расширения управлением ключом SDP, которая продолжает находиться в разработке в настоящее время. Синтаксис следующий:
a=key-mgmt:wmdrm-nd URL
Параметр URL - это URL-данные, описанные выше.
Рассмотрим теперь использование ANNOUNCE запросов для доставки обновленных политик в середине потока. Конкретно, выдержка из ANNOUNCE запроса ниже иллюстрирует, как лицензия листа может быть доставлена в соответствии с данным вариантом воплощения.
ANNOUNCE rtsp://eduardo01/file.wmv RTSP/1.0
CSeq: 27
Session: 8322364901836665746
Supported: com.microsoft.wmdrm-nd, com.microsoft.wm.eosmsg, method.announce
Require: method.announce
Event-Type: 4000 wmdrm-nd-message
Content-Type: application/vnd.ms-wmdrm-license-response
Content-Length: 924
License_Response_Message
В этом примере заголовок “Content-Type: application/vnd.ms-wmdrm-license-response” должен быть использован, чтобы указать, что основная часть запроса содержит сообщение Отклика Лицензии. В этом примере заголовок “Event-Type: 4000 wmdrm-nd-message” должен быть использован, чтобы указать, что это событие, которое передает сообщение WMDRM-ND. Приемник должен обработать сообщение Отклика Лицензии, чтобы убедиться, что Идентификатор Прав соответствует тому, который был в Запросе Лицензии. Если нет ошибки, приемник должен возвратить передатчику ответ 200 OK, подобный тому, который приведен ниже.
RTSP/1.0 200 OK
CSeq: 27
Session: 8322364901836665746
Supported: com.microsoft.wmdrm-nd, com.microsoft.wm.eosmsg, method.announce
Обратите внимание, что Лицензии, начиная с возвращенной в DESCRIBE запросе, соответствуют лицензии корня. Передатчик должен доставить лицензию листа, которая позволит приемнику дешифровать содержимое до того, как будет инициирована доставка данных. Это означает, что сразу после того, как приемник отправляет первый PLAY запрос, передатчик отвечает за то, чтобы отправить Лицензию Листа в ANNOUNCE запросе перед тем, как отправлять поток данных.
Нет никакого строгого соотношения между моментом, в который передатчик доставляет ANNOUNCE сообщение, и потребностью в новой Лицензии для дешифровки содержимого. Это означает, что передатчик может доставить ANNOUNCE прежде или даже после того, как он начинает доставлять пакеты, которые содержат взаимосвязанное защищенное содержимое. Один из способов, который может использоваться, чтобы передавать защищенное содержимое, - это при помощи пакетов RTP, как будет определено специалистом в данной области техники.
Заключение
Различные варианты воплощения, описанные выше, разрешают обновлениям политик, таким как DRM обновления политик, быть доставленными и обновленными для заданной части защищенного содержимого. По крайней мере в некоторых вариантах воплощений, различные протоколы могут быть расширены до разрешения обновления политик к существованию и передаче протоколом.
Хотя изобретение было описано на языке, определенном для структурных функций и/или методологических этапов, необходимо понять, что изобретение, определенное в приложенной формуле изобретения, не обязательно ограничено конкретными функциями или описанными этапами. Скорее конкретные функции и этапы раскрыты как предпочтительные формы реализации формулы изобретения.
1. Реализованный на компьютере способ доставки обновлений политик для защищенного контента, содержащий этапы, на которых:
формируют корневую лицензию, которая содержит зашифрованный первоначальный ключ контента, который асимметрично зашифрован с использованием открытого ключа приемника, причем корневая лицензия относится к защищенному контенту в файле с аудио- и/или видеоконтентом, который должен передаваться в потоке приемнику, при этом открытый ключ имеет больший размер в битах, чем первоначальный ключ контента корневой лицензии;
в ответ на прием запроса лицензии от приемника отправляют корневую лицензию приемнику;
подготавливают с помощью передатчика одну или более концевых лицензий, которые связаны с корневой лицензией посредством объекта идентификатора ключа (KID) канала восходящей линии связи, причем одна или более концевых лицензий, относящихся к обновленным политикам, связаны с передаваемым в потоке защищенным контентом в файле контента, в котором одна или более концевых лицензий содержат каждая в отдельности отличающийся ключ контента, который симметрично зашифрован с использованием первоначального ключа контента; и
в ответ на прием запроса контента от приемника или во время передачи защищенного контента в потоке из файла контента отправляют одну или более концевых лицензий приемнику, причем этап отправки одной или более концевых лицензий содержит этап, на котором чередуют части защищенного контента с данными, которые включают в себя одну или более концевых лицензий, чтобы позволить приемнику использовать защищенный контент в файле контента посредством, прежде всего, асимметричного дешифрования первоначального ключа контента и последующего симметричного дешифрования каждого ключа контента одной или более концевых лицензий, при этом передатчик осуществляет этап отправки одной или более концевых лицензий и отправляет каждую одну из одной или более концевых лицензий до этапа отправки соответствующей части защищенного контента в файле контента, и при этом приемник не содержит сведений о количестве концевых лицензий, подлежащих отправке посредством передатчика.
2. Способ по п.1, в котором первоначальный ключ контента содержит 128-битовый AES ключ.
3. Способ по п.1, в котором упомянутый отличающийся ключ контента содержит 128-битовый AES ключ.
4. Способ по п.1, в котором этапы отправки корневой лицензии и одной или более концевых лицензий осуществляется посредством HTTP.
5. Способ по п.1, в котором этапы отправки корневой лицензии и одной или более концевых лицензий осуществляются посредством потокового протокола реального времени (RTSP).
6. Реализуемый на компьютере способ доставки обновлений политик для защищенного контента, основывающийся на инициированной клиентом связи с сервером посредством HTTP протокола, причем способ содержит этапы, на которых:
принимают HTTP POST запрос, который содержит сообщение запроса лицензии от приемника, который запрашивает корневую лицензию для защищенного контента в файле аудио- и/или видеоконтента, который должен передаваться в потоке приемнику, причем корневая лицензия содержит зашифрованный первоначальный ключ контента, который асимметрично зашифрован с использованием открытого ключа приемника, причем корневая лицензия относится к защищенному контенту в файле контента, который должен передаваться в потоке приемнику, при этом открытый ключ имеет больший размер в битах, чем первоначальный ключ контента корневой лицензии;
в ответ на прием отправляют корневую лицензию приемнику в ответном сообщении о лицензии;
принимают HTTP GET запрос от приемника, который запрашивает защищенный контент в файле контента; и
в ответ на прием HTTP GET запроса отправляют сегменты запрошенного защищенного контента в файле контента, чередующегося с данными, которые включают в себя одну или более концевых лицензий, связанных с корневой лицензией посредством объекта KID канала восходящей линии связи, причем одна или более концевых лицензий содержат каждая в отдельности отличающийся ключ контента, который симметрично зашифрован с использованием первоначального ключа контента, чтобы позволить приемнику использовать защищенный контент в файле контента посредством, прежде всего, асимметричного дешифрования первоначального ключа контента и последующего симметричного дешифрования каждого ключа контента одной или более концевых лицензий, при этом сервер осуществляет этап отправки и отправляет одну или более концевых лицензий в соответствующем ответном сообщении о лицензии до этапа отправки соответствующего одного из сегментов защищенного контента в файле контента, и причем приемник не содержит сведений о количестве концевых лицензий, подлежащих отправке посредством сервера.
7. Реализуемый на компьютере способ доставки обновлений политик для защищенного контента, зависящий от инициированной сервером связи с клиентом посредством RTSP протокола, причем способ содержит этапы, на которых:
принимают RTSP DESCRIBE запрос от приемника, который запрашивает корневую лицензию для защищенного контента в файле с аудио- и/или видеоконтентом, который должен передаваться в потоке приемнику, причем корневая лицензия содержит зашифрованный первоначальный ключ контента, который асимметрично зашифрован с использованием открытого ключа приемника, причем корневая лицензия относится к защищенному контенту в файле контента, который должен передаваться в потоке приемнику, при этом открытый ключ имеет больший размер в битах, чем первоначальный ключ контента корневой лицензии;
отправляют корневую лицензию приемнику;
в ответ на прием запроса воспроизведения контента от приемника для воспроизведения защищенного контента в файле контента инициируют передачу контента в потоке приемнику; и
отправляют одну или более концевых лицензий, связанных с корневой лицензией посредством объекта KID канала восходящей линии связи, причем этап отправки одной или более концевых лицензий осуществляется во время передачи контента в потоке и чередуется с частями защищенного контента в файле контента, и при этом одна или более концевых лицензий содержат каждая в отдельности отличающийся ключ контента, который симметрично зашифрован с использованием первоначального ключа контента, чтобы позволить приемнику использовать защищенный контент посредством, прежде всего, асимметричного дешифрования первоначального ключа контента и последующего симметричного дешифрования каждого ключа контента одной или более концевых лицензий, при этом сервер осуществляет этап отправки и отправляет каждую из одной или более концевых лицензий соответственно в одном или более RTSP ANNOUNCE запросах до отправки соответствующей части защищенного контента в файле контента, и причем каждый из одного или более RTSP ANNOUNCE запросов содержит ответное сообщение о лицензии, и при этом приемник не содержит сведений о количестве концевых лицензий, подлежащих отправке посредством передатчика.
8. Способ по п.7, в котором DESCRIBE запрос содержит сообщение запроса лицензии.
9. Способ по п.7, в котором этап отправки корневой лицензии содержит этап, на котором отправляют RTSP ПРОТОКОЛ ОПИСАНИЯ СЕССИИ (SDP), который содержит ответное сообщение о лицензии, которое содержит корневую лицензию.
10. Способ по п.7, в котором:
DESCRIBE запрос содержит сообщение запроса лицензии; и этап отправки корневой лицензии содержит этап, на котором отправляют RTSP ПРОТОКОЛ ОПИСАНИЯ СЕССИИ (SDP), который содержит ответное сообщение о лицензии, которое содержит корневую лицензию.
