Система условного доступа

Система условного доступа

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

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

Так как эти устройства становятся более универсальными и более сложными, простое ручное управление не является достаточным. Более того, так как все более и более устройств становятся доступными, возможность к взаимодействию становится проблематичной. Многие поставщики используют свои собственные протоколы связи, чтобы позволить их устройствам взаимодействовать, но при этом устройства от различных поставщиков не взаимодействуют. Для преодоления этих проблем определены несколько стандартов взаимодействия, которые позволяют различным устройствам обмениваться сообщениями и информацией и управлять друг другом. Одним из общеизвестных стандартов является стандарт Home Audio/Video Interoperability (HAVi) (стандарт на взаимодействие бытовой аудио/видео аппаратуры), версия 1.0 которого опубликована в январе 2000, и который доступен в сети Интернет по адресу http://www.havi.org/. Другими общеизвестными стандартами являются стандарт domestic digital bus (D2B) (стандарт на домашнюю цифровую шину), протокол связи, описанный в IEC 1030, и стандарт Universal Plug and Play (универсальный стандарт на распознавание и настройку устройств без последующего конфигурирования пользователем) (http://www.upnp.org.).

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

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

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

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

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

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

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

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

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

Предпочтительно первый класс из упомянутого набора включает в себя операции ВОСПРОИЗВЕСТИ (RENDER), ПЕРЕМЕСТИТЬ (MOVE) и КОПИРОВАТЬ (COPY). Далее предпочтительно, второй класс из упомянутого набора включает в себя операции СОХРАНИТЬ (STORE), ВОСПРОИЗВЕСТИ (RENDER), РЕДАКТИРОВАТЬ (EDIT), УДАЛИТЬ (DELETE) и ОБРАБОТАТЬ (PROCESS). В другом варианте выполнения операция ОБРАБОТАТЬ предпочтительно санкционируется независимо от любых ограничений на права, связанные с контентом. Операция "обработать" позволяет совместимым устройствам в сети выполнять доступ к защищенному контенту для выполнения операций, которые не изменяют права на этот контент, без изменения этих прав. Примерами таких операций являются транскодирование контента и битовой скорости, обработка, требуемая для поддержания спецэффектов, улучшение изображения.

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

В варианте выполнения первый класс из набора включает в себя операции СОХРАНИТЬ, ВОСПРОИЗВЕСТИ, РЕДАКТИРОВАТЬ, УДАЛИТЬ и ОБРАБОТАТЬ. В другом варианте выполнения операцию ОБРАБОТАТЬ санкционируют независимо от любых ограничений на права, связанные с контентом.

Перечень фигур чертежей

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

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

Фиг.2 - иллюстрация базовой структуры предпочтительной инфраструктуры безопасности для управления правами и их защиты (RMP).

Фиг.3 - описание сообщения, отправленного от одной инфраструктуры безопасности к другой.

Фиг.4 - иллюстрация того, как выполняются вызовы с помощью вызовов RPC на открытом интерфейсе виртуальных машин OPIMA.

Фиг.5 - иллюстрация того, как реализуется распределенный доступ к контенту.

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

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

Архитектура домашней сети

Фиг.1 схематически иллюстрирует предпочтительную схему домашней цифровой сети в соответствии с изобретением, содержащую источник, приемник и два носителя S1 и S2 данных. Сеть делится концептуально на область условного доступа (СА) и область защиты от копирования (CP).

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

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

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

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

Инфраструктура безопасности

Базовую структуру предпочтительной инфраструктуры безопасности для управления правами и их защиты (RPM) иллюстрирует фиг.2. Эта инфраструктура безопасности определена в Призыве к Содействию (CFC) в рамках стандарта TV Anytime (TVA, «ТВ в любое время»), смотри web-сайт TV Anytime на http://www.tv-anytime.org/cfcs/. На фиг.2 описаны следующие элементы.

- Интерфейс Прикладного Программирования (API) приложений: Разрешает приложениям связываться с системой RMP способом, обеспечивающим возможность взаимодействия.

- Приложение: Программы и/или службы, разрешающие пользователю доступ к контенту и Функциональным возможностям PDR в соответствии с условиями RMP.

- Базовая система RMP: Функциональные возможности, согласующиеся с базовой спецификацией RMP TV Anytime (TVA).

- Частные системы RMP: Частные системы защиты контента, непосредственно взаимодействующие с базовой системой RMP TVA через API служб RMP.

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

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

- Функциональный слой системы RMP: Набор функций, реализующих Базовую систему.

- Менеджер системы RMP: Управляет работой базовой системы.

- Инструментальные средства Безопасности, возможно, содержат: средство дескремблирования, средство обнаружения/встраивания водяных знаков, средство проверки подлинности подписи и т.д.

- Стандартизованные усовершенствования для базовой системы RMP TVA: необязательные стандартизованные TVA-расширения для базовой системы RMP TVA.

- Интерфейс базового устройства RMP TVAF (инфраструктуры TVA): Слой безопасной связи между устройствами, совместимыми с TVA.

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

- API приложений

- API служб RMP

- Связь между устройствами.

API приложений

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

В качестве API приложений предлагается API DAVIC CA, разработанный Советом по Цифровой и Визуальной Информации (DAVIC (DIGITAL Audio-Visual Council), 1998, спецификации DAVIC 1.4, http://www.davic.org/). API DAVIC CA охватывает большую часть функциональных возможностей, требуемых для использования защищенного контента из приложения. Тем не менее, по всей видимости, потребуются некоторые расширения для решения некоторых вопросов, относящихся к хранению данных или сетям.

API служб RMP

API служб RMP разрешает системе RMP осуществлять связь с функциями безопасности базовой системы RMP способом, обеспечивающим возможность взаимодействия. API служб RMP должен состоять из поднабора методов стандарта OPIMA (инициатива в рамках открытой платформы для доступа к мультимедиа), как дано в этом разделе. В последующих разделах методы OPIMA для API RMP сгруппированы согласно функциональным возможностям. В отношении OPIMA, см. спецификацию OPIMA версии 1.1, 2000, включенную в настоящее описание посредством ссылки. http://www.cselt.it/opima/.

Доступ к контенту

Эта часть отражает определение интерфейса «Абстрактный доступ к контенту», раздел 3.3.4.7 стандарта OPIMA. Через этот интерфейс приложение может показывать требуемое действие в отношении контента.

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

Следующие методы используются для доступа к контенту:

- installCallbackContentAccess

- AbstractContentAccess

- replyToContentAccess

В необязательном порядке можно использовать следующий дополнительный метод:

- stopContent(ContentId)

Доступ к правилам/ключам

Эта часть отражает определение интерфейса для интерфейса «Абстрактный Доступ к Содержимому», раздел 3.3.4.8 стандарта OPIMA. Через этот интерфейс приложение может показывать, какие данные о правилах/правах оно желает принять.

Следующие методы используются для взаимодействия с пользователем:

- obtainUserRules

-obtainContentRules

- newRules

- updateContentRules

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

- addContentRules

Интеллектуальные карты (смарткарты)

Эта часть отражает определение интерфейса для интерфейса «Интеллектуальные карты», раздел 3.3.4.6 стандарта OPIMA. Система RMP может осуществлять доступ к интеллектуальным картам через эту систему и модули данных протокола прикладного уровня (APDU) стандарта ISO 7816 на передачу/прием.

Следующие методы должны быть использованы для взаимодействия с интеллектуальными картами:

-addCTListener

- removeCTListener

- cardInserted

- cardRemoved

- getSlotId

- isCardPresent

- openSlotChannel

- closeSlotChannel

- getATR

- reset

- sendAPDU

Шифрование/Дешифрирование

Эта часть отражает определение интерфейса для интерфейса «Средства шифрования и дешифрирования», раздел 3.3.4.3 стандарта OPIMA. Система RMP может управлять через этот интерфейс как криптографией контента, так и криптографическими действиями в отношении смешанной информации.

Следующие методы используются для шифрования и дешифрирования:

- queryEncryptionAlgorithms

- encrypt

- initEncryption

- updateEncryptionKeys

- stopEncryption

- decrypt

- initDecryption

- updateDecryptionKeys

- stopDecryption

Подписи

Эта часть отражает определение интерфейса для интерфейса «Средства для Подписей», раздел 3.3.4.4 стандарта OPIMA. Через этот интерфейс система RMP может проверять и генерировать как подписи для контента, так и подписи для смешанной информации.

Следующие методы используются для подписей:

- querySignatureAlgorithms

- verifySignature

- verifyContentSignature

- generateSignature

- generateContentSignature

Водяные знаки

Эта часть отражает определение интерфейса для интерфейса «Средство для Водяных Знаков», раздел 3.3.4.5 стандарта OPIMA. Через этот интерфейс система RMP может обнаруживать и встраивать водяные знаки в контент.

Следующие методы используются для водяных знаков:

- queryWatermarkAlgorithms

- extractWatermark

- stopWatermarkExtraction

- insertWatermark

- stopWatermarkInsertion

Доступ к RMP

Эта часть отражает определение интерфейса для интерфейса «Абстрактный Доступ к Одноранговым элементам OPIMA», раздел 3.3.4.9 стандарта OPIMA. Через этот интерфейс базовые системы могут взаимодействовать друг с другом.

Следующие методы используются для взаимодействия между системами RMP:

- openConnection

- closeConnection

- addConnectionListener

- sendMessage

- newConnection

- receiveMessageFromPeer

Взаимодействие с пользователем

Эта часть отражает определение интерфейса для интерфейса «Взаимодействие с пользователем», раздел 3.3.4.1 стандарта OPIMA. Через этот интерфейс пользователь может обмениваться информацией с системой RMP.

Следующие методы используются для взаимодействия с пользователем:

- sendMessageToUser

- receiveMessageFromUser

Метод receiveMessageFromUser разрешает лишь перенос строк символов между системой RMP и пользователем. Система RMP не контролирует форматирование и представление информации. Для поддержки такого форматирования в методе receiveMessageFromUser, значение(я) MessageText должно(ы) соответствовать сообщениям высокоуровневого интерфейса взаимодействия человека с аппаратурой (MMI), соответствующего Общему Интерфейсу, как стандартизовано в CENELEC EN 50221: 1997, Common Interface for Conditional Access and other Digital Video Decoder Applications; и в CENELEC R 206-001: 1997, Guidelines for the Implementation and Use of the Common Interface for DVB 15 Decoder Applications.

Взаимодействие с приложениями

Эта часть отражает определение интерфейса «Абстрактный Доступ к Приложениям», раздел 3.3.4.10 стандарта OPIMA. Этот интерфейс определяет прозрачный битовый канал между приложением и системой RMP.

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

Следующие методы должны быть использованы для взаимодействия с приложениями:

- installCallbackApplication

- replyMessage

- receiveMessageFromApplication

Нижеследующее расширение является необязательным.

Метод receiveMessageFromApplication должен содержать дополнительный тип сообщения (Message Type) «QUERY ENTITLEMENT». В ответ на этот тип сообщения система RMP возвращает список доступных вариантов доступа для текущего пользователя через стандартный метод «replyMessage».

Управление жизненным циклом

Эта часть отражает определение интерфейса для интерфейса «Управление жизненным циклом», раздел 3.3.4.11 стандарта OPIMA.

Следующие методы используются для управления жизненным циклом:

- initialize

- terminate

- update

- remove

Базовый Интерфейс Устройства RMP TVAF

Интерфейс Устройства должен обеспечивать безопасный уровень связи между устройствами, совместимыми с TVA. Элементы, относящиеся к этому интерфейсу, включают взаимосвязь инфраструктуры безопасности с другими элементами системы, такими как сетевое связующее программное обеспечение (например, UPnP, NAVi и Jini). Более того, аутентификация совместимых устройств и безопасная связь между этими устройствами обеспечивается Базовым Интерфейсом Устройства. Интерфейс устройства определен как расширение OPIMA для домашних сетей.

Базовая Система RMP

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

Базовая Система RMP, как и любая Система RMP, состоит из двух частей: управление ключами и шифрование контента. Использование системы, описанной в следующем разделе, позволяет частной системе RMP, которая использует базовую схему шифрования контента, осуществлять сквозное управление. Хотя Базовая система RMP не предложена, любая предлагаемая система RMP должна быть совместима с API служб RMP, соответствующим OPIMA.

Простая базовая система должна поддерживать по меньшей мере следующие правила, относящиеся к контенту: copy free (свободное копирование), copy_one_generation (копировать одно поколение), copy_no_more (больше не копировать). Поскольку эта Базовая система RMP будет присутствовать в каждом совместимом устройстве, алгоритм шифрования контента должен быть дешев, легко доступен и надежен. Так как Усовершенствованный Стандарт Шифрования (AES) удовлетворяет всем этим требованиям, предпочтительно использовать AES в качестве базовой схемы шифрования контента.

Базовый Интерфейс устройства

В предыдущем разделе была введена система OPIMA. OPIMA обеспечивает инфраструктуру безопасности для приложений и систем Цифрового Управления Правами (DRM) для взаимодействия между собой. В этом разделе система OPIMA усовершенствована для работы в домашней сети. Для введения в использование DRM в домашних сетях см. F.L.A.J. Kamperman, S.A.F.A. van den Heuvel, M.H. Verberkt, Digital Rights Management in Home Networks, Philips Research, The Netheklands, IBC 2001 conference publication vol. I, стр.70-77.

Домашняя сеть может быть определена как набор устройств, которые соединены между собой с помощью некоторого вида сетевой технологии (например, Ethernet, IEEE 1394, BlueTooth, 802.11b, и т.п.). Хотя сетевая технология позволяет сообщаться различным устройствам, этого недостаточно, чтобы разрешить устройствам взаимодействовать. Чтобы быть способными к взаимодействию, устройствам необходимо обнаруживать функции, присутствующие в других устройствах в сети, и обращаться к ним. Такое взаимодействие обеспечивается связующим программным обеспечением домашней сети (HN-MW). Например связующим программным обеспечением домашней сети являются Jini, HAVi, UPnP, AVC.

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

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

Инфраструктуры безопасности и домашние сети

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

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

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

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

Для выполнения этого, инфраструктура безопасности должна иметь возможность посылать и принимать сообщения и реализовать способ, который позволяет посылать ей сообщения, используя методики HN-MW (см. Приложение Д).

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

Данные вызова удаленных процедур являются телом сообщения, подлежащего обработке SAC. Хотя SAC может быть определен для каждого стандарта HN-MW, предлагается использовать один SAC, предпочтительно SSL (протокол защищенных сонетов) (RFC 2246) для всех стандартов HN-MW. Элемент данных SAC опять же является вызовом удаленной процедуры, но на этот раз в отношении функций: функции безопасности. В этом случае он является функциональным вызовом OPIMA. Сообщение HN-MW затем встраивается в сетевое сообщение и передается по домашней сети.

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

Аутентификация и доверие

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

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

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

Использование удаленных инструментальных средств

Как объяснено выше в разделе, относящемся к инфраструктурам безопасности и внутренним сетям, между инфраструктурами TVAF создается VPN. Это может рассматриваться как одна большая TVAF. VPN может быть использована для локального предоставления инструментальных средств удаленной TVAF. В этом случае вызовы выполняются с помощью вызовов RPC открытого интерфейса другой TVAF. Пример такого вызова в контексте виртуальных машин OPIMA (VMO) (которые могут быть использованы как инфраструктуры TVAF) показан на фиг.4. В устройстве 2 вызов функции и возвращаемое ей значение маршрутизируются через OVM, чтобы символизировать, что RPC с SAC извлечен и вызван.

Другой вариант инфраструктур TVAF для предоставления инструментальных средств, реализованных где-либо в сети, состоит в предоставлении инструментальных средств, непосредственно доступных в HN-MW. Вероятно, лучшим примером таких инструментальных средств является средство считывания интеллектуальных карт. Связь с интеллектуальными картами уже защищена системой RMP, и к ней можно осуществить доступ по незащищенному каналу.

Эта конфигурация позволяет инфраструктурам TVAF предоставлять инструментальные средства HN-MW и инструментальные средства, доступные на других TVAF в VPN. С точки зрения эффективности желательно использовать локальные инструментальные средства, когда они доступны. Сетевые инструментальные средства представляются с помощью обычного API OPIMA. Конечно, в реализации TVAF можно выбрать предоставление сетевых инструментальных средств, что подчеркивает, что использование локальных инструментальных средств не является жестким предписанием.

Декодирование контента, преобразование его в поток и HN-MW

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

Так как контент всегда может быть перехвачен на интерфейсе устройства, любой контент, отправляемый из TVAF, должен быть защищен. Как правило, это делается с помощью какого-либо вида шифрования. Система RMP поддерживает управление контентом, контролируя доступ к ключам, которые позволяют дешифровать этот контент. Контент должен лишь покинуть область устройств TVA, защищенных каким-либо видом системы RMP. Более того, управление каждым переносом контента из одной системы RMP в другую осуществляется системой RMP. В этом случае система RMP остается в состоянии контроля того, что случается с контентом.

Распределенный доступ к контенту

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

- Источник - источник контента.

- Приемник - приемник контента.

- Обработка - одна или более функций обработки могут быть представлены в тракте потока. Функция обработки является функцией, в которой некая операция выполняется в отношении контента.

- Приложение - приложение, соединяющее различные функции HN-MW и инициирующее доступ к контенту. Заметим, что это "приложение" является в действительности реализацией API стандарта DVB-MHP (DVB - домашняя платформа мультимедиа) (или любого другого подобного API).

- RMP, система RMP, управляющая контентом.

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

Секции HN-MW и OPIMA

Существует множество форматов контента и систем RMP. Чтобы избежать необходимости моделирования и поддержки каждого возможного варианта, OPIMA использует концепцию секций. Согласно OPIMA секция является классом устройств, поддерживающих OPIMA, которые совместно используют некоторые общие элементы в их интерфейсах RMP и/или архитектурных компонентах. Например, DVB может рассматриваться как секция, которая, в свою очередь, содержит другие секции, определяемые конкретной системой RMP. Секции могут быть иерархическими. То есть секция может содержать подсекции.

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

В пределах HN-MW секции используются для определения сетевых функций, которые должны быть доступны в IHDN, межсоединения в которой должны быть обеспечены с использованием HN-MW. Эти функции безопасности определены в секции и могут быть реализованы как отдельная функция в HN-MW, или же они могут быть встроены в другую функцию (например, тюнер может содержать фильтры правил, дисплей, средство дескремблирования). Используя секции, функции безопасности можно определить таким образом, что контент будет доступен только на интерфейсе устройства, защищенном некоторым видом системы RMP.

Защищенный контент и метаданные

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

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

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

Функц