СПОСОБЫ СОЗДАНИЯ, СИСТЕМЫ И АРХИТЕКТУРЫ ЗАЩИЩЕННЫХ МЕДИАКАНАЛОВ Российский патент 2008 года по МПК G06F21/20 H04L9/32 G06F7/00 

Область техники

Изобретение относится к способам и системам защиты визуализируемых цифровых данных, таких как аудио- и видеоданные и т.п. В частности, изобретение относится к способам и системам защиты цифровых данных.

Известный уровень техники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробное описание

Обзор

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

В качестве примера рассмотрим фиг.1. Показанная здесь система 100 включает в себя некоторое количество различных типов источников или поставщиков защищенной информации, таких как сервер DVD, обозначенный позицией 102, сервер 104 информации (например, сервер, который может выдавать аудиоинформацию, видеоинформацию и т.п.), сервер HDTV, обозначенный позицией 106, и локальный жесткий диск 116, причем перечислены лишь некоторые из возможных источников или поставщиков. Конфигурация поставщиков информации обеспечивает передачу их информации через различные среды, которые могут включать в себя сети, такие как сети 108, 110, 112, 118, шины (такие как шина для передачи данных со скоростью до 33 Мбайт/с (шина PCI) и шина быстродействующего графического порта (шина AGP)) и т.п. Информацию, как правило, подают в устройство некоторого типа, которое может предоставить информацию пользователю. Возможные устройства включают в себя, но не в ограничительном смысле, персональный компьютер 114, карманный персональный компьютер 120, телевизор 122, например, с компьютерной приставкой 124 к телевизору и т.п.

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

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

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

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

Эти и другие преимущества станут очевидными в свете рассмотрения нижеследующего описания.

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

Возможная вычислительная система

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

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

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

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

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

Шина 206 представлена на чертеже для отображения одного или более из любых нескольких типов структур шин, включая шину памяти или контроллер памяти, шину периферийных устройств, шину быстродействующего графического порта, а также шину процессора или локальную шину, использующую любую из множества архитектур шин. В качестве примера, не носящего ограничительный характер, можно отметить, что такие архитектуры включают в себя шину стандартной промышленной архитектуры (ISA), шину микроканальной архитектуры (МСА), локальную шину, соответствующую техническим нормам американской Ассоциации по стандартизации в области видеоэлектроники (VESA), и шину соединения периферийных компонентов (PCI), известную также под названием «шина Mezzanine».

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

На фиг.2 показано, что память 204 системы включает в себя считываемые компьютером носители в энергозависимой форме, например оперативное запоминающее устройство (ОЗУ) 210 и/или энергонезависимое запоминающее устройство, например постоянное запоминающее устройство (ПЗУ) 208. В ПЗУ 208 хранится базовая система ввода-вывода (BIOS), обозначенная позицией 212 и содержащая базовые стандартные подпрограммы, которые способствуют обмену информацией между элементами внутри компьютера 200, например, во время запуска. ОЗУ 210 обычно содержит данные и/или программные модули, к которым возможен немедленный доступ и/или которые в данный момент используются блоком (блоками) 202 обработки.

Компьютер 200 может также включать в себя другие съемные и/или стационарные, энергозависимые и/или энергонезависимые компьютерные носители информации. Лишь в качестве примера, на фиг.2 изображен дисковод 228 для жестких дисков, предназначенный для считывания со стационарного энергонезависимого магнитного носителя и записи на этот носитель (который не показан и обычно называется «жестким диском»), дисковод 230 для магнитных дисков, предназначенный для считывания со стационарного энергонезависимого магнитного диска 232 (например, «флоппи-диска») или записи на него, и дисковод 234 для оптических дисков, предназначенный для считывания со съемного, энергонезависимого оптического диска 236 или записи на него, причем таким диском может быть неперезаписываемый компакт-диск - CD-ROM, неперезаписываемый цифровой многоцелевой компакт-диск - DVD-ROM или другие оптические носители. Каждый из дисковода 228 для жестких дисков, дисковода 230 для магнитных дисков и дисковода 234 для оптических дисков соединен с шиной 206 с помощью одного или более интерфейсов 226.

Дисководы и связанные с ними считываемые компьютером носители обеспечивают энергонезависимое хранение считываемых компьютером команд, структур данных, программных модулей и других данных для компьютера 200. Хотя в возможной среде, описываемой здесь, используется жесткий диск 228, съемный магнитный диск 232 и съемный оптический диск 236, специалисты в данной области техники поймут, что в этой возможной операционной среде можно использовать другие типы считываемых компьютером носителей, которые могут хранить данные, доступные для компьютера, и к которым относятся магнитные кассеты, платы флэш-памяти, цифровые видеодиски, оперативные запоминающие устройства (ОЗУ), постоянные запоминающие устройства (ПЗУ) и т.п.

На жестком диске 228, магнитном диске 232, оптическом диске 236 и в ПЗУ 208 или ОЗУ 210 может храниться некоторое количество программных модулей, включая - в качестве примера, не носящего ограничительный характер, - операционную систему 214, одну или более прикладных программ 216 (например, мультимедийную прикладную программу 224), другие программные модули 218 и данные 220 программ. Пользователь может вводить команды и информацию в компьютер 220 через устройства ввода, такие как клавиатура 238 и указательное устройство 240 (такое как «мышь»). К числу других устройств ввода можно отнести устройство (устройства) 253 ввода аудио- и/или видеоинформации, микрофон, джойстик, игровой пульт, спутниковую антенну, последовательный порт, сканер, и т.п. (не показаны). Эти и другие устройства ввода соединены с блоком (блоками) 202 обработки через посредство интерфейса (интерфейсов) 242, который подключен (которые подключены) к шине 206, но возможно и соединение посредством других структур интерфейсов и шин, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB).

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

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

Как показано на фиг.2, вычислительная система 200 соединена с возможностью связи с удаленными устройствами (например, с удаленным компьютером 250) посредством локальной сети (LAN) 251 и глобальной сети (WAN) 252. Такие сетевые среды обычно имеют место в офисах, компьютерных сетях предприятий, внутрикорпоративных сетях и сети Интернет.

При использовании в сетевой среде LAN компьютер 200 подключают к LAN 251 через подходящий сетевой интерфейс или адаптер 248. При использовании с сетевой средой WAN компьютер 200, как правило, включает в себя модем 254 или иное средство для установления связи через WAN 252. Модем 254, который может быть внутренним или внешним, может быть подключен к системной шине 206 либо через интерфейс 242 ввода пользователем, либо с помощью другого подходящего механизма.

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

Возможные конкретные варианты осуществления

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

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

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

компонент источника информации (например, источник 300 информации) и его соединение с лицензирующим сервером;

клиентский компонент (например, клиент 304) и связанные с ним компоненты, предназначенные для дешифрирования данных и обработки ведомостей информации, которые содержат информацию DRM;

демультипрексор, декодеры и блоки повторного шифрования данных (например, демультиплексор 306, декодер 308 и шифратор 310);

приложение для обработки и смешения потоков данных (например, приложение 312);

один или более модулей визуализации (например, модуль 314 визуализации), которые устанавливают порядок дешифрирования аппаратными средствами и планируют отображение данных; и

аппаратные средства для дешифрирования и визуализации данных (например, аппаратные средства 316 визуализации).

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

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

Источник информации

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

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

Клиент и аутентификаторы

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

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

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

После этого аутентификатор может (аутентификаторы могут) «пройтись» по компонентам, имеющимся в конвейере, для проверки подписей компонентов, которые имеют дело с незашифрованными данными. Например, в изображенной системе некоторый сервер со средствами защиты может аутентифицировать клиента 304, после чего этот клиент может создать аутентификатор 318. Сразу же после создания аутентификатор 318 может подтвердить, что демультиплексор 306, декодер 308 и шифратор - все эти компоненты правомочны.

Кроме того, в этом примере всякий раз, когда данные проходят по шине или между не аутентифицированными компонентами (например, за счет использования зашифрованных линий связи) или в пространство ядра, можно создавать вторичный аутентификатор для проверки остальной части конвейера обработки потока данных. Следовательно, в этом примере модуль 314 визуализации может создать вторичный аутентификатор 320, который затем подтвердит, что этот модуль визуализации правомочен. Тогда аутентификаторы 318 320 могут устанавливать между собой аутентифицированный зашифрованный канал 319.

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

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

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

Демультиплексор, декодеры и блоки повторного шифрования

Демультиплексор 306 в типичном случае получает незашифрованные данные от клиента 304 и разделяет данные на различные потоки, такие как поток аудиоинформации и видеоинформации. В типичном случае, демультиплексор 306 затем пропускает эти потоки в один или более декодеров, таких как декодер 308, для дальнейшей обработки. Декодер аудиоданных (вместе с шифратором, таким как шифратор 310) может проводить повторное шифрование данных и выдавать их в прикладную систему 312 для обработки. Декодером видеоданных можно проводить повторное шифрование данных таким образом, что будет обеспечена защищенная передача по шине PCI/AGP в оперативное запоминающее устройство видеоплаты (VRAM). Декодер видеоданных в типичном случае может пропускать частично сжатые (и зашифрованные) данные в видеоплату и может проводить изменения меток времени, осуществлять перекомпоновку данных и синтаксический анализ заголовков. Например, при воспроизведении DVD декодер может выделить данные уровня вектора и остатки и пропустить их аппаратные средства обработки видеоданных. Декодер также может вносить любые изменения для моделирования обратного воспроизведения или эффектов переменной скорости.

Приложение и смешение

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

Модули визуализации и модули смешения

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

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

Один путь поддержания целостности данных сразу же после их появления на «рабочем столе» заключается в использовании полномочных (т.е. имеющих право работать с защищенной информацией) аппаратных средств графики. Возможная система описана в следующих патентных заявках, включенных в данное описание посредством ссылки: «Системы и способы защиты выхода видеоплаты», авторы Glenn Evans и Paul England, номер ms1-1115us в Реестре поверенного, дата подачи 24 июня 2002 г.; «Способы и системы, обеспечивающие функциональные возможности поэлементной обработки изображений», авторы Glenn Evans и Paul England, номер ms1-1025us в Реестре поверенного, дата подачи 24 июня 2002 г.

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

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

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

Аппаратные средства визуализации

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

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

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

На этапе 354 определяют, необходимо ли преобразование DRM. Если необходимо, то на этапе 356 можно осуществить преобразование DRM в форму, «понятную» системе обработки, которая должна визуализировать информацию. Этот этап можно проводить с помощью отдельного трансляционного модуля, который в некоторых случаях может поставляться продавцами программного обеспечения, представляющими некоторую третью сторону. На этапе 350 получают зашифрованную информацию, подлежащую защите во время процесса визуализации. Эта информация подлежит защите в соответствии с некоторым алгоритмом DRM. Информация может быть получена из любого подходящего источника, примеры которого приведены выше. На этапе 352 получают ведомость, связанную с информацией. Этапы 350 и 352 может проводить клиент подходящей конфигурации, такой как клиент 304 (фиг.3). В ведомости описаны требования к защищенному медиаканалу, предписывающие процесс, посредством которого надлежит визуализировать информацию. Такие требования могут быть оформлены - и в типичном случае оформляются - в виде лицензии. Получение ведомости может происходить одновременно или не одновременно с получением зашифрованной информации.

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

На этапе 366 определяют, нужны ли вторичные аутентификаторы. Вторичный аутентификатор может понадобиться по любой подходящей причине, примеры которых приведены ниже. Если вторичные аутентификаторы не нужны, на этапе 368 их не создают. С другой стороны, если вторичный аутентификатор нужен, то на этапе 370 создают вторичный аутентификатор и устанавливают защищенный канал между аутентификаторами. Затем на этапе 372 используют вторичный аутентификатор для аутентификации одного или более компонентов, находящихся дальше по цепочке. Способ может затем возвратиться назад к этапу 366, чтобы определить, нужны ли дополнительные вторичные аутентификаторы.

Пример реализации (вариант осуществления локального устройства)

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

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

Источник информации предоставляет информацию клиенту 404. Как отмечалось выше, в лицензии, которую получает клиент, указывается, что предоставляемые данные требуют создать аутентификатор защищенного медиаканала, такой как аутентификатор 418. В этом примере, один-единственный клиент 404 дешифрирует данные, которые получены из источника информации. Для проверки цепочки компонентов, принимающих незашифрованные данные, используют аутентификаторы, такие как аутентификаторы 418, 420 и 422. Такую проверку можно провести множеством различных способов, таких как проверка цифровых подписей, связанных с компонентами, и/или использование списков адресов динамически подключаемой библиотеки (DLL). После задания цепочки обработки компонентов, сервер, такой как сервер DRM, аутентифицирует клиента 404. Затем клиент 404 создает первичный аутентификатор 418, с помощью которого потом определяют местонахождение компонентов, которые обрабатывают данные, включающие в себя дешифрированные данные. Определение местонахождения компонентов может проводить аутентификатор 418 путем посылки запросов отдельным компонентам о том, каким другим компонентам те посылают данные. Например, аутентификатор 418 может послать запрос клиенту 404 о том, каким компонентам этот клиент выдает данные. Клиент может ответить аутентификатору, указывая, что он передает данные в демультиплексор 406. Это можно сделать, передавая в аутентификатор указатель, который указывает на демультиплексор 406. Поскольку демультиплексор 406 обрабатывает незашифрованные данные, он должен быть полномочным. Демультиплексор 406 получает данные, которые не зашифрованы клиентом, и демультиплексирует эти данные с получением потока видеоданных и потока аудиоданных. Поток видеоданных обрабатывается декодером 408а видеоданных и связанными с ними компонентами, находящимися дальше по цепочке (т.е. шифратором 410а, видеомодулем 414а визуализации, видеодрайвером и GPU (которые совместно обозначены позицией 416а)), тогда как поток аудиоданных обрабатывается аудиодекодером 408b и связанными с ними компонентами, находящимися дальше по цепочке (т.е. шифратором 410b, модулем 414b воспроизведения аудиоданных, аудиодрайвером и GPU (которые совместно обозначены позицией 416b)).

Отдельные компоненты в цепочке обработки снабжают аутентификаторы адресами других компонентов, которым они посылают незашифрованные данные. Затем аутентификатор «проходит» по списку компонентов и проверяет подписи компонентов, например, путем проверки подписей, имеющихся в соответствующих динамически подключаемых библиотеках компонентов. Это может быть сделано с использованием сервера со средствами защиты. Так, например, аутентификатор 418 будет аутентифицировать демультиплексор 406. Затем аутентификатор 418 проверит оба декодера 408а, 408b. После изучения компонентов (т.е. шифраторов 410а, 410b), которым декодер посылает данные, аутентификатор 418 будет аутентифицировать эти шифраторы. Приложение 412 может быть полномочным или неполномочным. Если этой прикладной системе приходится иметь дело с незашифрованными данными, то аутентификатор 418 может проверить, полномочна ли эта прикладная система. Если прикладная система не полномочна, то ей просто придется иметь дело с зашифрованными данными.

В конечном счете, данные будут пересылаться в модули 414а, 414b визуализации. Модули визуализации могут создать свой собственный аутентификатор 420, который затем проверяется аутентификатором 418. Между аутентификаторами 418, 420 может быть установлен аутентифицированный зашифрованный канал. Сразу же после его проверки аутентификатор 420 сам может аутентифицировать модули визуализации.

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

Также предусмотрен диспетчер 424 ключей, который может быть аутентифицирован аутентификатором 422. Диспетчер 424 ключей может быть ответственным за управление ключами, которые используются различными компонентами в цепочке обработки для обеспечения прохождения зашифрованных данных. Диспетчер ключей также может управлять сеансовыми ключами, которые используются во время процесса шифрования и дешифрирования. Могут также быть использованы и реализованы способы шифрования информации для потребителей, в частности, с помощью диспетчера ключей. Для промежуточных компонентов может быть предусмотрена, например, сменная библиотека шифрования. Во избежание внедрения ключей в различные компоненты, все ключи должны быть ключами на основе сеансов. Для аутентификации и установки сеансовых ключей между декодером и криптопроцессором в аппаратных средствах визуализации можно использовать алгоритм шифрования открытым ключом. Для установки сеансовых ключей аутентифицированные компоненты могут повторно использовать зашифрованный канал. Это гарантирует, что ключ шифрования будет пересылаться только тому объекту, который проверен следующим аутентификатором. Если некоторый компонент не направляет зашифрованные данные и канал данных аутентификатора по одному и тому же месту назначения, то объект, находящийся на более низком уровне в цепочке обработки, не сможет дешифрировать поток данных. Алгоритм, используемый для задания сеансовых ключей, может быть особым для декодера и компонентов визуализации. Канал аутентификации может быть предназначен специально для подпроцесса генерирования сеансовых ключей во избежание имитации установки сеансового ключа.

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

Согласование и синхронизация ключей

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

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

Аутентификаторы

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

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

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

Бит 0 - программное сокрытие сжатых данных (и подписанного видеодрайвера);

Бит 1 - защита сжатых данных с помощью доверительного программного обеспечения;

Бит 2 - защита сжатых данных по шинам с помощью аппаратных средств;

Бит 3 - защита сжатых данных в видео- и/или аудиоустройстве с помощью аппаратных средств;

Бит 4 - аналоговая защита данных, покидающих устройство вывода; и

Бит 5 - цифровая защита данных, покидающих устройство вывода.

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

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

Компоненты

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

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

На фиг.5 изображен возможный вариант конструкторской проработки аутентификации, в котором аутентификаторы обозначены символами «A_n», а интерфейсы, поддерживаемые различными компонентами в цепочке обработки, обозначены либо символами «IA» в случае аутентифицируемого интерфейса, либо символами «IAP» в случае интерфейса-посредника аутентификации. Интерфейс-посредник действует как интерфейс для предоставления услуги эстафетной передачи (переадресации) к другому аутентифицируемому интерфейсу. Названия различных компонентов указаны рядом с соответствующими компонентами. Например, в аудиоцепочке указаны декодер аудиоданных, кодер аудиоданных, приложение, модуль воспроизведения аудиоданных и драйвер / аппаратные средства воспроизведения аудиоданных. Точно также, в видеоцепочке указаны декодер видеоданных, кодер видеоданных, приложения, модуль визуализации видеоданных и драйвер / аппаратные средства визуализации видеоданных. Отметим, что некоторые компоненты поддерживают как интерфейс-посредник, так и аутентифицируемый интерфейс, например, посредством каждого из модулей визуализации.

Интерфейс - это просто логическая часть компонента, содержащая совокупность вызываемых способов, которые могут быть вызваны другими компонентами. Каждый раз, когда аутентификатор «хочет» установить связь с конкретным компонентом, этот аутентификатор ищет подходящий интерфейс на этом компоненте и осуществляет связь с ним, вызывая способы этого интерфейса.

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

В каждом аутентификаторе символ E_n обозначает пару ключей шифрования и дешифрирования «блока-инициатора» соединения, а символ D_n обозначает пару ключей шифрования и дешифрирования «блока-получателя» соединения.

Первый аутентификатор А₁ может поддерживать несколько вторичных аутентификаторов (например, А₂-А₅), поскольку он используется для проверки двух отдельных цепочек вывода (например, видеоцепочки и аудиоцепочки).

Клиент создает начальный идентификатор А₁, и этому идентификатору указывается интерфейс IA первого компонента (например, демультиплексора). В этом примере интерфейс IA возвращает аутентификатору следующую информацию:

список интерфейсов IA компонентов, находящихся дальше по цепочке;

список интерфейсов-посредников IAP компонентов, находящихся дальше по цепочке (которые рассматривают только зашифрованные данные);

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

место хранения индекса следующей связи аутентификатора (один и тот же аутентификатор может повторно использоваться для нескольких потоков); и

количество сеансов по ключам для цепочки аутентификации.

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

Интерфейс IAP обеспечивает два способа связи со следующим аутентификатором:

«Считывание данных (буфер, длина)»;

«Запись данных (буфер, длина)».

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

Аутентификаторы также могут обеспечивать компонентам с интерфейсами AI возможность пропускания информации по каналу аутентификатора. Такое пропускание, применительно к аутентификатору, может включать в себя EncryptAndSend(link ID, [in] data) - посылку данных в следующий компонент.

В интерфейсе IA, который «пропущен» в аутентификатор, могут существовать следующие обратные вызовы:

DecryptAndReceive([0ut] data) - используется для передачи сигналов и пропуска данных в принимающий компонент;

LinkIdentifier([out] link ID) - пропускается в интерфейс IA для посылки.

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

Для упрощения задачи клиента аутентификатор также может обеспечивать следующую простую поддержку шифрования:

CreateSession(HANDLE [out], CLSID drmEncryptorID) - создает шифратор и устанавливает сеансовый ключ;

EncryptData(YANDLE [in], BYTE* pIn, BYTE* pOut);

DecryptData(YANDLE [in], BYTE* pIn, BYTE* pOut).

Тогда аутентификатор должен продолжать поддерживать объект шифрования для компонента.

Конкретный вариант осуществления сети - случай I

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

В этом примере предусмотрено удаленное устройство 624, включающее в себя средства программного и аппаратного обеспечения (в совокупности обозначенные позицией 617), которые можно использовать для визуализации информации на удаленном устройстве. Возможное удаленное устройство может включать в себя карманные персональные компьютеры, персональные цифровые секретари, громкоговорители стандарта универсальной последовательной шины (USB), громкоговорители стандарта IEEE 1394 Института инженеров по электротехнике и электронике (ИИЭЭ) и т.п. На одной стороне сетевого соединения, например, ведущего к главному компьютеру, могут быть предусмотрены такие компоненты, как клиент 604, диспетчер 624 ключей, демультиплексор 606, декодеры 608а, 608b, шифраторы 610а, 610b, приложение 612, блоки 614а, 614b визуализации, а также один или более аутентификаторов, таких как первичный аутентификатор 618 и вторичный аутентификатор 620. Тогда устройство 624 может осуществлять связь с главным компьютером через сетевое соединение, вследствие чего оно сможет визуализировать защищенную информацию для пользователя из доверенного источника.

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

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

Вариант осуществления сети - случай II

На фиг.7 изображена система, которая несколько отличается от системы, изображенной на фиг.6 и описанной в связи с ней. В данном случае, устройство 724 представляет собой чисто аппаратный компонент 717 визуализации. Предусмотрен интерфейс-посредник 715 программного обеспечения, который может способствовать процессу аутентификации, но не обязательно должен быть полномочным. Аутентификацию можно проводить на вышеупомянутом аппаратном компоненте как таковом, например, с помощью поддержки аутентификации согласно инфраструктуре с открытым ключом (PKI) в этом аппаратном компоненте. В рассматриваемом примере сетевой модуль (сетевые модули) визуализации может (могут) преобразовывать протокол аутентификации на левой стороне сети в протокол аутентификации аппаратного компонента в устройстве 724. Тогда в этом случае интерфейс-посредник 715 должен быть проверенным и полномочным. В альтернативном варианте, аппаратный компонент может быть изначально совместимым с протоколом аутентификации на левой стороне сети или этот аппаратный компонент может содержать трансляционный модуль, позволяющий этому компоненту самому проводить операцию преобразования, исключая за счет этого необходимость предоставления полномочий устройству или проверки программного обеспечения в устройстве.

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

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

Другие расширения и преимущества

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

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

Заключение

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

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

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

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

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

проверяют, является ли клиентский компонент полномочным компонентом,

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

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

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

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

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