Улучшенная система цифрового управления правами (drm)

Улучшенная система цифрового управления правами (drm)

Иллюстрации

Показать все

Реферат

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

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

Авторизованные домены

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

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

Для авторизованных доменов необходимо решить такие проблемы, как идентификация авторизованного домена, регистрация входа устройства, регистрация выхода устройства, регистрация прав при входе, регистрация прав при выходе, регистрация контента при входе, регистрация контента при выходе, а также управление доменом. Для более полного ознакомления с использованием авторизованного домена и т.д. см. S.A.F.A. van den Heuvel, W.Jonker, F.L.A.J. Kamperman, P.J. Lenoir, "Secure Content Management in Authorised Domains", Philips Research, The Netherlands, IBC 2002 conference publication, pages 467-474, held at 12-16 September 2002 или Paul Koster, Frank Kamperman, Peter Lenoir and Koen Vrielink, "Identity based DRM: Personal Entertainment Domain", Conference on Communications and Multimedia Security (CMS) 2005, LNCS 3677, pp.42-54, Salzburg, Austria, September 19-21, 2005.

Некоторые формы разрешенных доменов

Существуют различные предложения, в некоторой степени реализующие концепцию авторизованных доменов. В так называемых основывающихся на устройствах доменах AD, домен формируется определенным набором аппаратурных устройств или приложений программного обеспечения (здесь далее упоминаемых вместе как клиенты) и контента. Менеджер или контроллер домена, которым может быть один или более клиентов, смарт-карта или другое устройство, управляет тем, какие клиенты могут присоединяться к домену. Только определенному набору клиентов в домене (членам) разрешается использовать контент данного домена, например, открывать, копировать, запускать или экспортировать его. Примеры таких AD, основывающихся на устройствах, приводятся в международной патентной заявке WO 03/098931 (номер в досье поверенного PHNL020455), международной патентной заявке WO 2005/088896 (номер в досье поверенного PHNL040288) и международной патентной заявке WO 04/027588 (номер в досье поверенного PHNL030283), поданных одним и тем же заявителем, каждая из которых включается сюда путем ссылки.

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

Другим типом AD является так называемый основывающийся на индивидуумах AD, где домен основывается на индивидуумах вместо устройств. Пример такой системы описан в международной патентной заявке WO 04/038568 (номер в досье поверенного PHNL021063) тем же самым заявителем, которая включена сюда ссылкой, в которой контент привязывается к индивидуумам, которые затем группируются в домен.

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

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

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

Примеры гибридных систем AD можно найти в международной патентной заявке WO 2005/010879 (номер в досье поверенного PHNL030926) и в международной патентной заявке WO 2005/093544 (номер в досье поверенного PHNL040315), которые обе включены сюда посредством ссылки.

Вообще говоря, AD содержит группу Клиентов. Клиент обычно является функциональным субъектом, который может приобретать и анализировать Лицензии (License) и привязки (Link) с целью получения доступа к экземпляру Контента (Сontent), основываясь на правах, выраженных в этих Лицензиях и привязках. Обычно Клиент воплощается как одно или более приложений программного обеспечения и/или аппаратурных компонент. Например, Клиент может обеспечиваться как приложение на устройстве типа мобильного телефона или портативного музыкального плеера. Клиент обычно содержит процессор, чтобы выполнять необходимые операции, и оснащен запоминающим устройством, чтобы сохранять Контент и/или команды, которые должны исполняться процессором. Клиенты, содержащиеся в AD, упоминаются как Клиенты-Члены или просто как Члены (Members) для краткости.

Контент делается доступным Клиентам-Членам одним или более Владельцами лицензии (LO). Владелец лицензии (License Owner), вообще говоря, является лицом, являющимся представителем Пользователя в окружении Домена (Domain). Пользователь является индивидуумом, который взаимодействует с системой. Пользователю могут предоставляться права на экземпляр Контента. Такое предоставление лицензии может быть представлено в системе путем предоставления Лицензии, которая привязывает (конкретный экземпляр) Контент к Владельцу лицензии. Владелец лицензии может быть реализован путем предоставления информации в структуре данных, записи в базе данных или программном объекте. Отношения с Пользователем в системе не определяются в явной форме, но могут, например, осуществляться Пользователем, имеющим Устройство, содержащее эту информацию.

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

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

право осуществлять доступ к части Контента "находится в собственности" у Владельца лицензии, и

этот Владелец лицензии ассоциирован с Доменом, и

Клиент является членом этого Домена.

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

Клиент -> Домен ->Владелец лицензии -> Контент

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

На фиг.1 схематично показана такая цепочка разрешений от Клиента до Контента, в которой каждое отношение может иметь множественность больше 1 в каждом направлении, как указано символом "*". Отношение между объектами Клиент, Домен, Владелец лицензии и Контент в конфигурации Домена могут быть выражены и квалифицированы в форме свидетельства, иногда также упоминаемого как (цифровой) сертификат. Могут использоваться следующие свидетельства:

• Право, которое конкретный Владелец лицензии имеет касаемо части Контента, выражается в Лицензии со ссылкой на Владельца лицензии, а также на часть оговариваемого Контента. Лицензия обычно реализуется как объект с цифровой подписью, содержащий соответствующую информацию в машиночитаемом формате. Такая Лицензия также содержит в себе конкретные разрешения и ограничивающие правила, выраженные в исполняемом коде Control (Контроль), хранящемся в так называемом объекте Control в Лицензии, которые должны быть оценены на момент желаемого доступа к Контенту. (Обратите внимание, что разрешения и ограничения могут быть также представлены на формальном языке представления прав, подобном, например, XrML). Разрешение, в положительной модели предоставления, как мы используем ее здесь, является индивидуальным правом, например "Play" (воспроизвести) или "Copy" (копировать), которое может ограничиваться одним или более ограничениями, например "only 10 times" (только 10 раз) или "not before 20:00 pm" (не раньше 20:00 часов" или "only on a Saturday" (только по субботам). Ограничение, используемое в комбинации с разрешением, обеспечивает условие, которое ограничивает использование разрешения. Каждое разрешение может иметь различные ограничения. Заметим, что каждая Лицензия имеет свой собственный набор разрешений и ограничений для этих разрешений (в объекте Control). Первоначальный поставщик услуг контента определяет в Лицензии разрешения, возможно дополненные множеством ограничений. Пользователь системы, потребитель, может пожелать добавить дополнительные ограничения к Лицензии для использования в "своем" Домене. Первоначальный поставщик услуг контента не устанавливает, например, ограничения, соответствующие водительскому контролю, но Владелец лицензии, который выпускает приобретенный им Контент в Домен, может захотеть это сделать. Как пример, Владелец лицензии определяет количество позиций Контента, которые не должны быть доступны раньше 22:00 часов, или позиции Контента, которые не должны быть доступны без некоторой надлежащей аутентификации пользователя, эксплуатирующего Клиент. Это ведет к различным областям контроля: одна - для поставщика услуг и одна - для Владельца лицензии (пользователя) с несколько различными характеристиками. Маловероятно, что параметры настройки поставщика услуг изменятся; Лицензия будет аннулироваться полностью, когда необходимо, приводя в результате к требованию аннулирования Лицензий. Владелец лицензии (пользователь), с другой стороны, может захотеть изменить свои ранее определенные ограничения, приводя в результате к требованию возможности передачи изменений Лицензии в систему.

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

• Отношение членства между Клиентом и Доменом выражается в направленной Привязке, называемой LinkC, от Клиента к Домену. Такая Привязка может содержать ограничительные правила, выраженные в исполняемом коде Control, хранящемся в так называемом объекте Control в Привязке, квалифицирующем действительность Привязки, которая должна оцениваться на момент, когда Привязка должна использоваться. Такая Привязка предпочтительно создается, используя объект с цифровой подписью, в котором Домен и Владелец лицензии идентифицированы.

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

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

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

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

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

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

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

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

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

Для запрещения возможности доступа в таком Домене конкретная часть Контента может быть организована с ограничением в Лицензии или посредством сообщения о действительности Лицензии Клиенту. Для запрещения возможности доступа в таком Домене любой Контент конкретного Владельца лицензии может быть организован с ограничением в Привязке Домен → Владелец лицензии (LinkLO) или путем сообщения о действительности Привязки Клиенту. Чтобы запретить отдельному Клиенту доступ к любому Контенту Домена, может быть выполнена подобная операция для Привязки Устройство → Домен (LinkC).

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

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

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

Недостатки, связанные с периодами действительности свидетельств.

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

2. Не все свидетельства на Клиенте будут блокироваться по истечении времени на Клиента одновременно, создавая у пользователя нежелательные впечатления, особенно когда Лицензии блокируются по истечении времени в различные моменты;

3. Для сохранения согласованности системы, в некоторые операции должны вводиться времена ожидания, чтобы убедиться, не истек ли период действительности выпущенного свидетельства;

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

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

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

Это достигается способом, содержащим этапы, на которых:

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

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

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

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

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

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

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

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

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

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

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

На фиг.2 схематично показан пример системы 100, содержащей устройства 101-105 и индивидуумов 130, 131, образующих авторизованный домен (AD). Система 100, которая представляет типичную цифровую домашнюю сеть, содержит множество устройств, например радиоприемник, тюнер/декодер, проигрыватель компакт-дисков, пару громкоговорителей, телевизор, видеомагнитофон, цифровое записывающее устройство, мобильный телефон, кассетный магнитофон, персональный компьютер, персональный цифровой секретарь, мобильный дисплейный блок и так далее. Эти устройства соединены между собой через сеть 110, чтобы позволить одному устройству, например телевизору, управлять другим, например видеомагнитофоном. Одно устройство, такое как, например, тюнер/декодер или телевизионная приставка (STB), обычно является центральным устройством, обеспечивающим централизованное управление всеми остальными.

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

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

Телевизионная приставка 101 или любое другое устройство в системе 100 может содержать носитель S1 данных, такой как жесткий диск надлежаще большой емкости, позволяющий запись и последующее проигрывание принятого контента. Носитель S1 данных может быть персональным цифровым записывающим устройством (PDR) некоторого вида, например, записывающим устройством DVD+RW, к которому телевизионная приставка 101 подсоединена. Контент может также вводиться в систему 100 сохраненным на носителе 120 типа компакт-диска (CD) или цифрового универсального диска (DVD).

Портативный дисплей 103 и мобильный телефон 104 подсоединяются беспроводным способом к сети 110, используя точку 111 беспроводного доступа, например, используя Bluetooth или IEEE 802.11b/g. Другие устройства подсоединяются, используя традиционное проводное подключение. Чтобы позволить устройствам 101-105 взаимодействовать, предлагаются несколько стандартов взаимодействия, которые позволяют различным устройствам обмениваться сообщениями и информацией и управлять друг другом. Одним из известных стандартов является Universal Plug and Play (http://www.upnp.org).

В одном примерном сценарии, по меньшей мере, один из пользователей 130, 131 привязан к Разрешенному Домену в дополнение к одному или более устройствам 101-105. В необязательном порядке некоторое количество позиций контента (не показаны) также могут быть привязаны к авторизованному Домену. Эта привязка пользователей и/или контента может делаться способом, раскрытым в международной патентной заявке WO 04/038568 (номер в досье поверенного PHNL021063), способом, раскрытым в международной патентной заявке WO 2005/010879 (номер в досье поверенного PHNL030926), или способом, описанным в международной патентной заявке с серийным номером IB2005/050910 (номер в досье поверенного PHNL040315).

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

• приемное устройство было аутентифицировано как совместимое устройство, и

• пользователь контента имеет право переносить (перемещать и/или копировать) этот контент на другое устройство.

Если перенос контента разрешен, он обычно будет выполняться зашифрованным способом, чтобы гарантировать то, что контент не может быть незаконно перехвачен в удобном формате через транспортный канал, такой как шина между дисководом CD-ROM и персональным компьютером (Хостом).

Аутентификация члена AD

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

Чтобы гарантировать правильность открытого ключа и проверить, является ли пара ключей законной парой сертифицированного устройства, открытый ключ сопровождается сертификатом, который в цифровой форме подписан Органом Сертификации (CA), организацией, которая управляет распространением пар открытых/личных ключей для всех устройств. Любой знает открытый ключ CA и может использовать его для проверки подписи СА на сертификате. В простой реализации открытый ключ СА жестко программируется в реализации устройства.

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

Поток управления определяет, нужно ли предоставлять доступ к части контента Клиенту-Члену. Результатом потока управления является решение, можно ли осуществлять доступ к Контенту или нет. Конечно, такой доступ должен осуществляться согласно соответствующей Лицензии на Контент, которая принадлежит владельцу лицензии. Информация для этого решения состоит из наличия отношений между субъектами системы.

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

Клиент, например любое из устройств 102-105, и контроллер домена, например телевизионная приставка 101, вместе поддерживают первую переменную состояния, которая отражает отношение членства клиента в Домене. Точно также контроллер домена и контроллер владельца лицензии, ассоциированный с владельцем лицензии, вместе поддерживают вторую переменную состояния, которая отражает отношение ассоциациативной связи между владельцем лицензии и доменом. Контроллером Владельца лицензии является, например, смарт-карта, принадлежащая пользователю, представляемому Владельцем лицензии.

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

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

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

Заметим, что различные субъекты, такие как Клиент, контроллер Домена и контроллер владельца лицензии, могут быть реализованы как модули аппаратного и/или программного обеспечения в едином устройстве. Телевизионная приставка 101, например, была описана выше как контроллер Домена, но, конечно, она может также работать как Клиент, когда ей требуется осуществить доступ к определенному контенту.

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