Защита цифрового мультимедиа с различными типами содержимого

Защита цифрового мультимедиа с различными типами содержимого

Иллюстрации

Показать все

Реферат

Уровень техники

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

Текущие DRM-методики имеют ограничения. Зачастую они совместимы только с двумя типами протоколов для передачи цифрового мультимедиа - HTTP и RTSP. Но другие протоколы сегодня или в будущем могут более оптимально подходить для передачи цифрового мультимедиа. Кроме того, содержимое, защищенное посредством DRM, может быть ограничено конкретным типом содержимого. Один конкретный тип содержимого - ASF-файлы - предоставляет возможность только одному набору прав и ограничений, т.е. политик, применяться ко всему ASF-файлу. Например, когда видео подготавливается посредством рендеринга, может потребоваться либо активировать Macrovision на аналоговом видеовыходе для всего файла, либо он может не потребоваться вообще.

Сущность изобретения

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

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

Краткое описание чертежей

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

Фиг. 2 иллюстрирует примерную процедуру обнаружения близости для протокола, с которым изобретаемые варианты осуществления могут быть использованы в одном варианте осуществления.

Фиг. 3 иллюстрирует примерную процедуру установления сеанса для протокола, с которым изобретаемые варианты осуществления могут быть использованы в одном варианте осуществления.

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

Фиг. 5 иллюстрирует аспекты протокола потоковой передачи, с которым изобретаемые варианты осуществления могут быть использованы в соответствии с одним вариантом осуществления.

Фиг. 6 иллюстрирует аспекты, ассоциативно связанные с корневыми лицензиями и листовыми лицензиями в соответствии с одним вариантом осуществления.

Фиг. 7 иллюстрирует аспекты, ассоциативно связанные с корневыми лицензиями и листовыми лицензиями в соответствии с одним вариантом осуществления.

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

Фиг. 9 иллюстрирует один мультимедийный файл по фиг. 8 с примерными сегментами данных, ассоциативно связанными с ключевыми идентификаторами (KID).

Фиг. 10 иллюстрирует для сегмента данных, показанного на фиг. 9, пакет в соответствии с одним вариантом осуществления.

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

Фиг. 12 иллюстрирует примерное шифрование в соответствии с одним вариантом осуществления.

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

Подробное описание изобретения

Обзор

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

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

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

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

Протокол защиты содержимого и передачи лицензий

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

K{data} - данные зашифрованы с помощью секретного ключа K.

K[data] - данные подписаны с помощью секретного ключа K.

{data}_Device - данные зашифрованы с помощью открытого ключа устройства.

[data]_Device - данные подписаны с помощью открытого ключа устройства.

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

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

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

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

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

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

Сообщение	Значение	Описание
Сообщение запроса на регистрацию	Ver	8-битовая версия протокола.
Cert	Цифровой XML-сертификат приемного устройства.
DId	128-битовый серийный номер.
Сообщение ответа по регистрации	Ver	8-битовая версия протокола.
{Seed} Device	128-битовое начальное число, используемое для того, чтобы извлечь ключ шифрования содержимого и ключ целостности содержимого.
SN	128-битовый серийный номер.
Address	Адрес сокета входящих и исходящих пакетов близости передающего устройства.
SId	128-битовый случайный идентификатор сеанса.
Алгоритм обнаружения близости	Алгоритм обнаружения близости приводится в исполнение внешним образом.

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

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

В отношении обнаружения близости рассмотрим следующее в связи с фиг. 2.

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

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

Таблица ниже описывает сообщения, которые передаются при обнаружении близости:

Сообщение	Значение	Описание
Сообщение начала по близости	SId	Такое же 128-битовое значение идентификатора сеанса, что и отправленное посредством передающего устройства.
Сообщение запроса по близости	Seq	8-битовый инкрементный порядковый номер.
SId	Такой же 128-битовый идентификатор сеанса.
Nonce	128-битовое случайное значение.
Сообщение ответа по близости	Seq	Такой же порядковый номер, что и определен посредством передающего устройства.
SId	Такой же 128-битовый идентификатор сеанса.
KC{Nonce}	128-битовый одноразовый номер, зашифрованный с помощью ключа шифрования содержимого.
Сообщение результата по близости	SId	Такой же 128-битовый идентификатор сеанса.
Result	Код состояния, указывающий успешность или сбой процедуры регистрации.

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

Сообщение	Значение	Описание
Сообщение запроса на лицензию	Ver	8-битовая версия протокола.
Cert	Цифровой XML-сертификат приемного устройства.
SN	128-битовый серийный номер.
Action	Запрошенное применение содержимого. Примеры: Play (Воспроизвести), Copy (Копировать) или Burn (Записать).
RId	128-битовый случайный идентификатор прав.
VCRL	Версия CRL приемного устройства.
Сообщение ответа по лицензии	Ver	8-битовая версия протокола.
CRL	CRL передающего устройства. Передается только в том случае, если он имеет более высокий номер версии, чем CRL приемного устройства, и компонент приемного устройства также имеет возможности передачи.
License	KC (зашифрован с помощью открытого ключа приемного устройства).	128-битовый случайный ключ шифрования содержимого.
KI (зашифрован с помощью открытого ключа приемного устройства).	128-битовый случайный ключ целостности содержимого.
VCRL	Версия CRL передающего устройства.
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 на URI-адрес, который указывает механизм транспортировки, который должен быть использован для пакетного мультимедиа. В примере по фиг. 5 запрос SETUP отправляется для аудио и видео. Клиент 500 также указывает в запросе SETUP параметры транспортировки, которые должны быть использованы. Заголовок транспортировки в запросе SETUP указывает параметры транспортировки, допустимые для клиента при передаче данных. RESPONSE от сервера 502 содержит параметры транспортировки, выбранные сервером. Сервер также формирует идентификаторы сеанса в ответ на запросы SETUP.

В этой точке клиент может выдать запрос PLAY, который сообщает серверу начать отправку данных посредством механизма, указанного в SETUP. В ответ на прием запроса PLAY сервер может начать потоковую передачу содержимого, которым является, например, аудио/видеосодержимое. В этом примере потоковое содержимое инкапсулируется с помощью RTP-пакетов и отправляется по UDP, как должны принимать во внимание специалисты в данной области техники.

RTSP-протокол имеет другие представляющие интерес методы, которые включают в себя PAUSE, TEARDOWN, GET_PARAMETER, SET_PARAMETER, REDIRECT и RECORD. Для получения дополнительных сведений по RTSP читатель должен обратиться к документу RTSP RFC, Schulzrinne, H., Rao, A. и R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, доступному по адресу http://www.ietf.org/rfc/rfc2326.txt, апрель 1998 года.

Корневые и листовые лицензии

В проиллюстрированном и описанном варианте осуществления используются понятия корневая лицензия и листовые лицензии. Здесь корневая лицензия используется для того, чтобы устанавливать и защищенно доставлять ключ содержимого (корневой ключ содержимого) клиенту/приемному устройству с тем, чтобы клиент/приемное устройство могло расшифровать впоследствии доставляемую листовую лицензию(и). После того как корневой ключ содержимого защищенно доставлен клиенту/приемному устройству, ключи содержимого для различных листовых лицензий (листовые ключи содержимого) могут быть зашифрованы сервером/передающим устройством с помощью корневого ключа содержимого, отправленного клиенту/приемному устройству. С помощью корневого ключа содержимого клиент может расшифровать листовые ключи содержимого и ассоциативно связанные политики в листовых лицензиях. Каждая из листовых лицензий также имеет уникальный идентификатор, допускающий ассоциативное связывание листовой лицензии с частью мультимедийного файла. Здесь уникальный идентификатор упоминается как ключевой идентификатор, или KID, и предназначен для каждой листовой лицензии, пронумерованной от 1 до n (leaf_-1, leaf_-2,... leaf_-n), KID_leaf-n.

Чтобы предоставить один из примеров того, как может быть реализована эта конкретная схема, рассмотрим следующее в связи с фиг. 6. В этом конкретном примере система по фиг. 6 сконфигурирована так, чтобы использовать 1024-битовые RSA-ключи для криптографической операции с открытым ключом и 128-битовые AES-ключи для симметричных криптографических операций. Разумеется, это приведено только в качестве одного примера и не предназначено для того, чтобы ограничивать применение заявляемого предмета изобретения.

В этом примере клиент/приемное устройство 600 имеет пару 650 открытый/закрытый ключ, а сервер/передающее устройство 602 имеет открытый ключ клиента/приемного устройства. В этом примере каждый из открытого и закрытого ключа клиента/приемного устройства является 1024-битовым RSA-ключом. Используя открытый ключ клиента/приемного устройства, сервер/передающее устройство составляет корневую лицензию, которая содержит корневой ключ содержимого, который зашифрован с помощью открытого ключа клиента/приемного устройства. Корневой ключ содержимого является 128-битовым AES-ключом содержимого. Эта корневая лицензия затем отправляется клиенту/приемному устройству. На фиг. 6 это показано как первый обмен данными, который осуществляется между клиентом/приемным устройством и сервером/передающим устройством, где зашифрованный ключ корневого содержимого представляется как {content key_root}_CLIENT. Тем не менее, следует принимать во внимание, что другой обмен данными до проиллюстрированного обмена данными может осуществляться.

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

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

HTTP

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

Когда HTTP используется для переноса DRM-защищенного содержимого, клиент выдает два запроса серверу/передающему устройству. Во-первых, клиент выдает запрос POST, чтобы извлечь корневую лицензию. Во-вторых, клиент выдает запрос GET для извлечения DRM-защищенного содержимого. Клиент выдает запросы в этом примере, поскольку в HTTP сервер типично не может инициировать обмен данными с клиентом.

В частности, рассмотрим фиг. 7 в связи с последующим описанием. Когда клиент хочет принять корневую лицензию, он выдает запрос POST серверу. Запрос POST содержит сообщение запроса на лицензию, как описано выше. В ответ на прием этого обмена данными сервер отвечает сообщением ответа по лицензии, которое содержит корневую лицензию, которая, по меньшей мере, в одном варианте осуществления выражается в XMR. После приема корневой лицензии и ее обработки надлежащим образом клиент выдает запрос GET серверу, запрашивая DRM-защищенное содержимое. В ответ на запрос GET сервер отвечает сегментами запрошенного содержимого, чередующимися с одним или более сообщений ответа по лицензии. Каждое сообщение ответа по лицензии содержит листовую лицензию, которая относится к конкретной части DRM-защищенного содержимого. Любой подходящий механизм или методика чередования может быть использована для формулирования ответа сервера.

В качестве одного из примеров реализации в одном конкретном контексте рассмотрим следующее.

В одном из примеров четырехбайтовый заголовок кадрирования используется для того, чтобы инкапсулировать данные и управляющие блоки. Заголовок кадрирования содержит однобайтовый ASCII-знак доллара (0×24), после которого следует однобайтовый идентификатор типа блока, за которым следует двухбайтовая длина инкапсулированных данных, представленных в порядке сетевых байтов.

Секции	Поля
Заголовок	8-битовый ASCII-знак доллара (0Ч24)
8-битовый тип блока
Длина данных	16-битовая длина инкапсулированных данных

Блок управления использует ASCII-символ "c" (0×63) в качестве идентификатора типа. Этот блок содержит сообщение, типично сообщение ответа по лицензии.

Блок данных использует ASCII-символ "d" (0×63) в качестве идентификатора типа. Этот блок содержит дескриптор сегмента данных, сразу за которым следуют мультимедийные данные.

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

В соответствии с одним вариантом осуществления, типичный HTTP-ответ с шифрованием линии связи состоит из следующих блоков:

1. Блок управления [$c], переносящий сообщение ответа по лицензии с цепной лицензией.

2. Один или более блоков данных [$d].

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

3. Новый блок управления [$c], переносящий сообщение ответа по лицензии с новой цепной лицензией.

4. Один или более блоков данных [$d].

Отметим, что этапы 3 и 4 могут осуществляться несколько раз в случае нескольких изменений ключа или политики.

Один зашифрованный мультимедийный файл с несколькими листовыми лицензиями

Средства дают возможность одному зашифрованному мультимедийному файлу иметь части, ассоциативно связанные с различными политиками. Один зашифрованный мультимедийный файл может иметь произвольный тип содержимого (к примеру, ASF, MPEG, WAV или другие файлы) и передаваться с помощью различных протоколов управления.

В проиллюстрированном и описанном ниже варианте осуществления по фиг. 8 один зашифрованный мультимедийный файл 800 имеет семь частей 802, 804, 806, 808, 810, 812 и 814. Допустим, что этот мультимедийный файл является мультимедийной программой по истории музыкального видео. Первая часть - это введение в музыкальное видео, вторая - это музыкальное видео, третье - это реклама, четвертая - это еще одно музыкальное видео, пятая - это еще одно музыкальное видео, шестая - это еще одна реклама, а седьмая - это заключение к программе.

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

Чтобы управлять использованием каждой из этих частей, каждая ассоциативно связывается с политикой. Здесь политика - это листовая лицензия, имеющая KID и ключ содержимого. Допустим, что одна корневая лицензия и пять листовых лицензий принято для этой мультимедийной программы. Листовые лицензии показаны на фиг. 8 как 816, 818, 820, 822 и 824. Каждая из листовых лицензий имеет уникальный KID (KID₁, KID₂, KID₃, KID₄ и KID₅) и уникальный листовой ключ содержимого (leaf content key₁, leaf content key₂, leaf content key₃, leaf content key₄ и leaf content key₅). Каждая листовая лицензия также содержит политику (policy₁, policy₂, policy₃, policy₄ и policy₅), разрешающую или исключающую конкретные права для использования мультимедиа в каждой из ассоциативно связанных частей. Эти листовые лицензии выражаются в XMR (расширяемые мультимедийные права), хотя также могут быть использованы другие языки.

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

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

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

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

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

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

Дескрипторы

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

Фиг. 9 иллюстрирует мультимедийный файл 800 с четвертой частью 808 развернутой, чтобы показать один способ, которым эта часть может быть ассоциативно связана с политикой. Здесь мультимедийный файл принимается с частями, в общем, по порядку. В этом примере принимается корневая лицензия, после которой первая листовая лицензия, после которой первая часть мультимедийного файла, после которой вторая листовая лицензия, после которой вторая часть и т.д. Здесь листовые лицензии не все принимаются до приема начала мультимедийного файла, как описано выше. Благодаря этому первая и третья листовые лицензии могут быть отправлены повторно перед частью, ассоциативно связанной с ними (таким образом, первая листовая лицензия может быть отправлена перед первой частью и снова перед седьмой частью).

Когда новая политика должна последовать за частью мультимедийного файла, новая листовая лицензия (здесь четвертая листовая лицензия 822) отправляется перед частью мультимедиа, ассоциативно связанной с четвертой листовой лицензией.

Здесь листовая лицензия отправляется как часть блока 902 управления, за которым следуют сегменты 904-914 данных четвертой части 808. Тем не менее, в RTSP лицензии доставляются в дескрипторах SDP или сообщениях ANNOUNCE. Этот конкретный вариант осуществления ориентирован на использование HTTP, хотя использование и обмен корневыми лицензиями и данными также может использовать RTSP, как, например, изложено в описании, относящемся к фиг. 7 выше. Блок управления содержит листовую лицензию 822 по фиг. 8 и 9. Листовая лицензия имеет leaf content key₄, policy₄ и KID₄. После приема четвертая листовая лицензия может быть расшифрована с помощью корневого ключа содержимого. KID может отправляться открытым или зашифрованным, но допускающим расшифровку.

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

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