СПОСОБ И УСТРОЙСТВО ДЛЯ ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИИ ИДЕНТИФИКАЦИИ ДЛЯ ЦИФРОВОЙ ПОДПИСИ И ЦЕЛОСТНОСТИ ЗАШИФРОВАННОГО СОДЕРЖАНИЯ И АУТЕНТИЧНОСТИ В СЕТЯХ, ОРИЕНТИРОВАННЫХ НА СОДЕРЖАНИЕ Российский патент 2015 года по МПК G06F21/64 H04L9/00 H04L29/06 H04W12/08 

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

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

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

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

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

Раскрытие изобретения

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

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

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

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

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

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

На фиг. 1 представлена схема одного варианта осуществления CON.

На фиг. 2 представлена схема варианта осуществления схемы аутентификации контента.

На фиг. 3 представлена схема другого варианта осуществления схемы аутентификации контента.

На фиг. 4 представлена схема варианта осуществления схемы шифрования контента.

На фиг. 5 представлена схема другого варианта осуществления схемы шифрования контента.

На фиг. 6 представлена схема варианта осуществления гибридной схемы аутентификации контента.

На фиг. 7 представлена схема варианта осуществления формата метаданных контента.

На фиг. 8 показана блок-схема последовательности операций варианта осуществления способа аутентификации контента.

На фиг. 9 показана блок-схема последовательности операций варианта осуществления способа шифрования контента.

На фиг. 10 представлена схема варианта осуществления модуля сети.

На фиг. 11 представлена схема варианта осуществления универсальной вычислительной системы.

Осуществление изобретения

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

Пользователь может не иметь доступа к оригинальному серверу для получения объекта контента в CON. При этом может потребоваться гарантирование целостности контента (то есть гарантирование того, что контент не был изменен третьей стороной) и аутентичности (то есть гарантирование, что контент происходит от издателя, которому оно соответствует). Цифровая сигнатура представляет собой общий подход, который обеспечивает целостность и аутентичность контента в CON. Как правило, издатель контента может подписывать объект контента, используя частный ключ издателя. Сигнатура может быть прикреплена к контенту или может отдельно распространяться через CON. Когда абонент получает контент, абонент может проверить целостность контента, используя открытый ключ издателя. Необходимое условие этого механизма состоит в том, что абонент должен получить открытый ключ издателя, который может распространяться через CON, как предполагается для сети с центром на контенте (CCN)/сети с поименованными данными (NDN), как архитектуру сети. Однако степень доверия к открытому ключу издателя также может потребовать проверки, используя другой открытый ключ, который обычно представляет собой открытый сертификат, выдаваемый сертификационной организацией (СА), пользующейся глобальным доверием.

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

На фиг. 1 иллюстрируется вариант осуществления CON 100, в которой контент можно направлять на основе префиксов наименования и поставлять заказчикам на основе запроса. CON 100 может содержать сетевой домен 110, который содержит множество узлов, таких как домен протокола Интернет (IP), домен многопротокольной коммутации на основе меток (MPLS) или домен Ethernet. Домен 110 сети может содержать множество внутренних узлов 112 и множество маршрутизаторов 114 контента, которые могут быть соединены друг с другом через сетевые соединения, например, фиксированные соединения. Маршрутизаторы 114 контента могут быть соединены с множеством узлов 120 заказчика через множество сетей 140 доступа и множеством сайтов 150 заказчиков, как показано на фиг. 1. Обмен данными между маршрутизаторами 114 контента, узлами 120 заказчиков, сетью 140 доступа и сайтами 150 заказчиков обозначен пунктирными линиями со стрелками на фиг. 1. CON 100 также может содержать плоскость 160 администрирования, которая может сообщаться с внутренними узлами 112 и/или маршрутизаторами 114 контента (обозначены сплошными линиями со стрелками на фиг. 1)

Внутренние узлы 112 могут представлять собой любые узлы, устройства или компоненты, которые поддерживают передачу трафика, например фреймов и/или пакетов, через CON 100. Внутренние узлы 112 могут пропускать трафик в или принимать трафик из других узлов в том же сетевом домене 110. Например, внутренние узлы 112 могут представлять собой маршрутизаторы, коммутаторы или мосты, такие как магистральные основные мосты (ВСВ), основные мосты провайдера (РСВ) или маршрутизаторы коммутации на основе меток (LSR). Внутренние узлы 112 также могут представлять собой маршрутизаторы 114 контента, которые перенаправляют контент на основе префиксов наименования контента. Маршрутизаторы 114 контента могут представлять собой любые узлы, устройства или компоненты, которые поддерживают транспортирование трафика между сетевым доменом 110 и внешними компонентами. Маршрутизаторы 114 контента могут представлять собой узлы на кромках, которые перенаправляют трафик контента из внутренних узлов 112 в узлы 120 заказчиков и/или на сайты 150 заказчиков, например, на основе запроса или требования заказчика. Маршрутизаторы 114 контента также могут принимать запросы контента из узлов 120 заказчика. Например, маршрутизаторы контента могут представлять собой маршрутизаторы или мосты, такие как магистральные мосты на границе домена (ВЕВ), мосты провайдера на границе домена (РЕВ) или маршрутизаторы с присвоением меток на границе домена (LER), которые направляют контент на основе префиксов наименования контента. Внутренние узлы 112 и/или маршрутизаторы 114 контента могут содержать или могут быть соединены с множеством серверов контента, которые содержат или кэшируют контент, который может быть предоставлен заказчикам или абонентам, например, по требованию.

Узлы 120 заказчиков могут представлять собой узлы, устройства или компоненты, выполненные с возможностью поставки контента пользователю или заказчику и приема запросов на контент из узлов 120 заказчика. Например, узлы 120 заказчика могут быть фиксированными или мобильными, ориентированными на пользователя устройствами, такими как настольные компьютеры, переносные компьютеры, карманные персональные компьютеры (PDA) или сотовые телефоны. В качестве альтернативы, узлы 120 заказчика могут представлять собой устройства передачи данных в помещении заказчика, такие как модемы или телевизионные приставки. Узлы 120 заказчика также могут содержать оборудование заказчика (не показано), которое может быть выполнено с возможностью приема контента из маршрутизаторов 114 контента через сети 140 доступа и распределения этого контента множеству заказчиков. Например, узлы 120 заказчика могут содержать терминалы оптической сети (ONU) и/или модули приемопередатчиков высокоскоростной цифровой абонентской линии (VDSL) в местах проживания (VTU-РТС). Сети 140 доступа могут представлять собой любые сети, которые обеспечивают доступ к контенту в CON 100, такие как частные виртуальные сети (VPN). Сайты 150 заказчиков могут представлять собой любые сайты или офисную среду, выполненные с возможностью принимать контент от маршрутизаторов 114 контента, и могут передавать контент в соответствующие узлы 120 заказчика через сети 140 доступа. Сайты 150 заказчика также могут принимать запросы контента из узлов 120 заказчика и посылать запросы контента в маршрутизаторы 114 контента.

CON 100 может быть выполнен с возможностью обеспечения целостности данных для множества пользователей, ассоциированных с узлами 120 заказчика и/или сайтами 150 заказчика. Для обеспечения целостности данных контент может быть принят и может быть кэширован с сигнатурой от издателя. Сигнатура может быть затем проверена абонентом для определения целостности контента. Издатель и абонент могут использовать открытый/частный ключ подписи и проверки контента, соответственно. Как правило, пара ″открытый/частный ключ″ может быть предусмотрена инфраструктурой управления открытыми ключами (PKI). Такая схема может требовать распределения открытого ключа абонентам и использования дополнительного механизма проверки абонентами для обеспечения доверия к открытому ключу, например, используя сертификаты от СА. Для исключения использования такого дополнительного механизма может использоваться схема сигнатуры на основе идентичности вместо обеспечения целостности контента в CON 100. В соответствии с этим идентичность, ассоциированная с издателем или контентом, которая известна абоненту, может быть принята и может быть кэширована с контентом. Абонент может затем принимать известную идентичность с контентом и распознать эту идентичность для определения целостности контента без требования дополнительного распределения идентичности или ключа, и/или механизмов доверия. Кроме того, для обеспечения защиты и конфиденциальности данных идентичность может использоваться для дешифрования контента, которое было зашифровано без использования дополнительных механизмов распределения и/или обеспечения доверия для ключа шифрования, как подробно описано ниже.

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

На фиг. 2 иллюстрируется вариант осуществления схемы 200 аутентификации контента для обеспечения целостности и аутентичности контента для пользователей CON. Схема 200 аутентификации контента может быть воплощена в CON 210, которая может быть аналогична CON 100. CON 210 может содержать множество внутренних узлов 212 и маршрутизаторов 214 контента, которые могут быть сконфигурированы аналогично внутренним узлам 112 и маршрутизаторам 114 контента, соответственно. Маршрутизаторы 214 контента могут быть соединены с множеством узлов/сайтов 250 заказчика, аналогичных узлам 120 заказчика/сайтам 150 заказчика, например, через множество сетей доступа (не показаны). Узлы/сайты 250 заказчика могут быть сконфигурированы для публикации/абонирования контента в CON 210. CON 210 также может содержать или может быть соединена с PKG 270, которая может быть сконфигурирована для генерирования множества частных ключей для множества издателей контента.

В схеме 200 аутентификации контента каждый узел/сайт 250 заказчика может использовать общие алгоритмы или функции, например, для подписи контента, публикации контента, абонирования контента и проверки контента, как описано ниже. Алгоритмы или функции могут представлять собой любые криптографические алгоритмы или функции, известные или используемые в существующих CON, например, используя библиотеки алгоритмов, такие как открытый протокол защищенных сокетов (openSSL). Каждый пользователь или узел/сайт 250 заказчика, который может представлять собой издателя, также может иметь открытую идентичность (p_id), которая может использоваться для получения частного ключа для издателя (pr-p) для подписи контента. Открытая идентичность (p_id) также может быть известна и может использоваться абонентом для проверки контента. Например, открытая идентичность может представлять собой общеизвестную идентичность, ассоциированную с издателем, такую как адрес электронной почты издателя, номер телефона, название организации, локально уникальную идентичность (например, имя пользователя или название департамента в организации) или любую другую общеизвестную идентичность издателя, которая известна абоненту CON 210.

Например, первый узел/сайт 250 заказчика может представлять собой издателя, который публикует контент для пользователя в CON 210, через маршрутизатор 214 контента. Издатель может быть аутентифицирован в PKG 270, используя открытую идентичность (p_id), для получения частного ключа (pr-p), который может затем содержаться в секрете издателем. PKG 270 может генерировать открытый во всей системе параметр или МК и частный параметр или MSK, например, используя алгоритм/функцию Setup: Generate (МК, MSK). MK/MSK может быть сгенерирован как часть операции установки PKG 270. Например, когда PKG 270 начинает работу или переходит в режим онлайн, PKG 270 может выполнять установку для генерирования МК и MSK до обработки какого-либо запроса заказчика. МК также может быть опубликован в CON 210, например, используя алгоритм/функцию Publish(MK), без распределения MSK.

Затем издатель может запрашивать из PKG 270 частный ключ для подписи контента издателем из PKG 270, используя p_id, например, используя алгоритм/функцию GetPrk (p_id). PKG 270 может затем использовать MSK и p_id для генерирования pr-p, например, используя алгоритм/функцию GeneratePrK (MSK, p_id). Генерирование МК и MSK, используя Setup: Generate (MK, MSK), и получение pr-p, используя GetPrk (p_id), может быть воплощено только один раз PKG 270 и издателем, соответственно, например, в режиме офлайн, независимо от процесса публикации контента (обозначено сплошными линиями со стрелками на фиг. 2). Издатель затем может подписать объект контента, например, используя алгоритм/функцию Sign (pr-p, m), и может опубликовать контент с сигнатурой (s), используя p_id, например, используя алгоритм/функцию Publish (m, name, p_id, s). Сигнатура (s) может составлять часть метаданных кэшированного или сохраненного контента. В некоторых вариантах осуществления открытая идентичность (p_id) издателя также может быть включена как часть метаданных контента. Опубликованный контент может быть затем перенаправлен в маршрутизатор 214 контента и сохранен или кэширован в CON 210.

Второй узел/сайт 250 заказчика, который может быть абонентом, может затем получить контент из CON 210. Второй узел/сайт 250 заказчика может абонировать контент в том же или другом маршрутизаторе 214 контента, используя, например, алгоритм/функцию Subscribe (m, name). p_id издателя может быть известен абоненту или может быть получен из метаданных контента. В частности, абонент может получить МК из PKG 270, например, используя алгоритм/функцию GetMK, и затем проверить целостность и аутентичность абонированного контента путем проверки сигнатуры (сигнатур), используя p_id и МК, например, используя алгоритм/функцию Verify (p_id, МК, m, s). Абонент может получить МК из PKG 270, используя GetMK только один раз, например, в режиме офлайн, независимо от процесса публикации контента (обозначен сплошными линиями со стрелкой на фиг. 2). В некоторых сценариях абонент может проверять целостность абонируемого контента путем генерирования вначале открытого ключа издателя (pb-p), например, используя алгоритм/функцию GeneratePbK (МК, p_id), и с последующей проверкой контента на основе pb-p, например, используя Verify (pb-p, m, s). Это может быть эквивалентно использованию Verify (p_id, МК, m, s), поскольку pb-p генерируется внутренне абонентом и представляет собой функцию p_id и МК.

В схеме 200 аутентификации контента операция установки для генерирования МК и MSK может представлять собой однократно выполняемую операцию, например, выполняемую только один раз. Например, параметры MK/MSK могут представлять собой общие параметры для всех объектов (издателей и абонентов) в системе. Операция GetPrk может представлять собой однократно выполняемую операцию для издателя и использовать для издателя весь контент одного и того же издателя. Операция GetMK может представлять собой однократно выполняемую операцию для абонента, поскольку она не зависит от конкретного издателя или объекта контента. Операция GeneratePrK () также может представлять собой однократно выполняемую операцию для одной идентичности, например, издателя. Кроме того, получение частного ключа для издателя (pr-p) из PKG 270 может потребовать использования защищенного канала между издателем и PKG 270. Однако получение МК из PKG 270 может не требовать защищенного канала между абонентом и PKG 270.

На фиг. 3 иллюстрируется вариант осуществления другой схемы 300 аутентификации контента для обеспечения целостности и аутентичности контента для пользователей CON. Схема 300 аутентификации контента может быть воплощена в CON 310, которая может быть аналогична CON 100. CON 310 может содержать множество внутренних узлов 312 и маршрутизаторов 314 контента, которые могут быть выполнены аналогично внутренним узлам 112 и маршрутизаторам 114 контента, соответственно. Маршрутизаторы 314 контента могут быть соединены с множеством узлов/сайтов 350 заказчика, аналогично узлам 120 заказчика/сайтов 150 заказчика, например, через множество сетей доступа (не показаны). Узлы/сайты 350 заказчика могут быть сконфигурированы с возможностью публикации/абонирования контента в CON 310. CON 310 может содержать или может быть соединена с PKG 370, которая может быть сконфигурирована для генерирования множества частных ключей для множества издателей контента. CON 310 также может содержать или может быть соединена с услугой 380 регистрации названия контента (NRS), которая может быть сконфигурирована для регистрации множества названий контента для издателей. Названия контента могут быть выбраны издателями. NRS 380 может представлять собой локальный или глобальный объект в пределах организации издателей и может получать из PKG 270 множество частных ключей для издателей (pr-m), ассоциированных с зарегистрированными наименованиями контента издателей. NRS 380 может проверять, что наименование контента от издателя является новым и не было ранее зарегистрировано до регистрации наименования контента, и может получать частный ключ для издателя, ассоциированный с или соответствующий зарегистрированному наименованию контента.

В схеме 300 аутентификации контента каждый узел/сайт 350 заказчика может использовать общие алгоритмы или функции, такие как функции для подписи контента, публикации контента, абонирования контента и проверки контента, как описано ниже. Алгоритмы или функции могут представлять собой любые криптографические алгоритмы или функции, известные или используемые в существующей CON, например, используя библиотеки алгоритма, такие как openSSL. Каждый узел/сайт 350 пользователя или заказчика может получать частный ключ для издателя (pr-m) для подписи контента на основе наименования контента или префикса (наименования). Наименование контента или префикс могут быть известны и могут использоваться абонентом для проверки контента.

Например, первый узел/сайт 350 заказчика может представлять собой издателя, который публикует контент для пользователя в CON 310 через маршрутизатор 314 контента. Издатель может выбрать наименование контента и может зарегистрировать наименование контента в NRS 380, например, используя алгоритм/функцию RegisterName (name). NRS 380 может затем получить соответствующий частный ключ для издателя (pr-m) из PKG 370, например, используя алгоритм/функцию GetPrK (name). Впоследствии издатель может получать или принимать pr-m из NRS 380, например, используя алгоритм/функцию GetPrk (name). Аналогично PKG 270, PKG 370 может генерировать открытый параметр для всей системы или главный ключ (МК) и частный параметр или главный секретный ключ (MSK), например, используя алгоритм/функцию Setup:Generate (МК, MSK). MK/MSK могут быть сгенерированы как часть операции установки PKG 370, например, в момент запуска, перед обработкой какого-либо запроса заказчика. МК также может быть опубликован в CON 310, например, используя алгоритм/функцию Publish(MK), без распределения MSK.

Затем NRS 380 может запрашивать из PKG 370 частный ключ для подписи контента издателя из PKG 370, используя GetPrk (name), как описано выше. PKG 370 затем может использовать MSK и наименование контента или префикс для генерирования pr-m, например, используя алгоритм/функцию GeneratePrK (MSK, name). Генерирование МК и MSK, используя Setup: Generate (MK, MSK), и получение pr-m, используя GetPrk (name), могут быть выполнены только один раз PKG 370 и издателем, соответственно, например, в режиме офлайн, независимо от процесса публикации контента (обозначено сплошными линиями со стрелкой на фиг. 3). Издатель может затем подписать объект контента, например, используя алгоритма/функцию Sign (pr-m, m), и опубликовать контент с сигнатурой (сигнатурами), используя алгоритм/функцию Publish (m, name, s). Сигнатура (s) может представлять собой часть метаданных кэшированного или сохраненного контента. Опубликованный контент может затем быть передан маршрутизатором 314 контента и сохранен или кэширован в CON 310.

Второй узел/сайт 350 заказчика, который может представлять собой абонента, может затем получить контент. Второй узел/сайт 350 заказчика может абонировать контент, используя тот же или другой маршрутизатор 314 контента, например, используя алгоритм/функцию Subscribe (m, name). В частности, абонент может получать МК из PKG 370, например, используя алгоритм/функцию GetMK, и затем может проверять целостность и аутентичность абонируемого контента путем проверки сигнатуры (сигнатур), используя наименование или префикс контента и МК, например, используя алгоритм/функцию Verify (name, МК, m, s). Абонент может получить МК из PKG 370, используя GetMK только один раз, например, в режиме офлайн, независимо от процесса публикации контента (обозначено сплошными линиями со стрелками на фиг. 3). Абоненту может не потребоваться аутентификация с PKG 370 для получения МК. В некоторых сценариях абонент может проверять целостность абонируемого контента путем генерирования вначале открытого ключа издателя (pb-p), например, используя алгоритм/функцию GeneratePbK (МК, name), и с последующей проверкой контента на основе pb-p, например, используя Verify (pb-p, m, s). Это может быть эквивалентно использованию Verify (name, МК, m, s), поскольку pb-p интегрально сгенерирован абонентом и представляет собой функцию наименования контента или префикса и МК.

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

На фиг. 4 иллюстрируется вариант осуществления схемы 400 шифрования контента для защиты контента и обеспечения безопасности и конфиденциальности для пользователей CON. Схема 400 шифрования контента может быть воплощена в CON 410, которая может быть аналогична CON 100. CON 410 может содержать множество внутренних узлов 412 и маршрутизаторов 414 контента, которые могут быть сконфигурированы аналогично внутренним узлам 112 и маршрутизаторам 114 контента, соответственно. Маршрутизаторы 414 контента могут быть соединены с множеством узлов/сайтов 440 заказчика, аналогично узлам 120 заказчиков/сайтов 140 заказчика, например, через множество сетей доступа (не показаны). Узлы/сайты 440 заказчика могут быть сконфигурированы для публикации/абонирования контента в CON 410. CON 410 также может содержать или может быть соединена с генератором (PKG) 470 частного ключа, который может быть сконфигурирован для генерирования множества частных ключей для множества издателей контента.

В схеме 400 аутентификации контента каждый узел/сайт 440 заказчика может использовать общие алгоритмы или функции, такие как для подписи контента, публикации контента, абонирования контента и проверки контента, как описано ниже. Алгоритмы или функции также могут содержать алгоритмы или функции, для шифрования контента и дешифрования контента. Каждый пользователь или узел/сайт 440 заказчика, который может представлять собой издателя, также может иметь открытую идентичность (p_id), которая может использоваться для шифрования контента издателем. Открытая идентичность (p_id) также может быть известна и может использоваться абонентом для получения частного ключа для издателя (pr-p) для дешифрования контента. Например, открытая идентичность может представлять собой широко известную идентичность, ассоциированную с издателем, как описано в схеме 200 аутентификации контента.

В схеме 400 шифрования контента первый узел/сайт 440 заказчика может представлять собой издателя, который публикует контент для пользователя в CON 410 через маршрутизатор 414 контента. Издатель может вначале получить открытый параметр для всей системы или главный ключ (МК) из PKG 470, например, используя алгоритм/функцию GetMK. PKG 470 может генерировать МК и частный параметр или главный секретный (или частный) ключ (MSK), например, используя алгоритм/функцию Setup:Generate (MK, MSK). MK/MSK может быть сгенерирован как часть операции установки PKG 470. Например, когда PKG 470 начинает работу или переходит в режим онлайн, PKG 470 может запустить установку для генерирования МК и MSK до обработки какого-либо запроса заказчика. МК также может быть опубликован в CON 410, например, используя алгоритм/функцию Publish (MK), без распределения MSK. Издатель может получать МК из PKG 470, используя GetMK, только один раз, например, в режиме офлайн, независимо от процесса публикации контента (обозначено сплошными линиями со стрелкой на фиг. 4). Издатель может шифровать контент (m), используя p_id и МК для получения зашифрованного контента (с), например, используя алгоритм/функцию Encrypt (p_id, МК, m). Издатель может затем опубликовать зашифрованный контент (с) с наименованием контента (или префиксом), например, используя алгоритм/функцию Publish(c, name). В некоторых вариантах осуществления открытая идентичность (p_id) издателя может быть включена как часть метаданных контента. Кроме того, издатель также может подписывать контент, например, как описано в схеме 200 аутентификации контента, перед или после шифрования и публикации контента. Опубликованый контент может быть затем направлен маршрутизатором 414 контента и сохранен или кэширован в CON 210.

Второй узел/сайт 440 заказчика, который может представлять собой абонента, может затем получать зашифрованный контент из CON 410. Второй узел/сайт 440 заказчика может абонировать зашифрованный контент, используя тот же или другой маршрутизатор 414 контента, например, используя алгоритм/функцию Subscribe (c, name). Издатель может запрашивать из PKG 470 частный ключ для дешифрования зашифрованного контента, используя p id, например, используя алгоритм/функцию GetPrk (p_id). p_id издателя может быть известен абоненту или может быть получен из метаданных контента. PKG 470 может затем использовать MSK и p_id для генерирования частного ключа для издателя (pr-p), например, используя алгоритм/функцию GeneratePrK (MSK, p_id). Операция GeneratePrK () может представлять собой однократно выполняемую операцию для одной идентичности, например, издателя. Далее, получение частного ключа для издателя (pr-р) из PKG 470 может потребовать защищенного канала между абонентом и PKG 470. Однако получение МК из PKG 470 может не потребовать защищенного канала между издателем и PKG 470. Абонент может затем дешифровать зашифрованный контент (с) для получения оригинального контента m, используя pr-p, например, используя алгоритм/функцию Decrypt (c, pr-p). Кроме того, если контент был подписан издателем, абонент может проверить подписанный контент, например, как описано в схеме 200 аутентификации контента.

На фиг. 5 иллюстрируется вариант осуществления другой схемы 500 шифрования контента для обеспечения безопасности и конфиденциальности контента для пользователей CON. Схема 500 шифрования контента может быть воплощена в CON 510, которая может быть аналогична CON 100. CON 510 может содержать множество внутренних узлов 512 и маршрутизаторы 514 контента, которые могут быть сконфигурированы аналогично внутренним узлам 112 и маршрутизаторам 114 контента, соответственно. Маршрутизаторы 514 контента могут быть соединены с множеством узлов/сайтов 550 заказчика, аналогично узлам 120 заказчиков/сайтов 150 заказчиков, например, через множество сетей доступа (не показаны). Узлы/сайты 550 заказчиков могут быть сконфигурированы для опубликования/абонирования контента в CON 510. CON 510 может содержать или может быть соединена с PKG 570, который может быть выполнен с возможностью генерировать множество частных ключей для множества издателей контента. CON 510 также может содержать или может быть соединена с NRS 580, который может быть выполнен с возможностью регистрации множества наименования контента для издателей. Наименования контента я могут быть выбраны издателями. NRS 580 может представлять собой локальный или глобальный объект внутри организации издателей и может получать из PKG 570 множество частных ключей для издателей (pr-m), ассоциированных с зарегистрированными наименованиями контента издателей. NRS 580 может проверять, что наименование контента от абонента является новым и не было ранее зарегистрировано до регистрации наименования контента, и получать частный ключ для издателя, ассоциированный с или соответствующий зарегистрированному наименованию контента.

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

Например, первый узел/сайт 550 заказчика может представлять собой издателя, который публикует контент для пользователя в CON 510, через маршрутизатор 514 контента. Издатель может вначале получить открытый для всей системы параметр или главный ключ (МК) из PKG 570, например, используя алгоритм/функцию GetMK. PKG 570 может генерировать МК и частный параметр или главный секретный ключ (MSK), например, используя алгоритм/функцию Setup: Generate (MK, MSK) только один раз, как часть операции установки, как описано в представленных выше схемах. МК также может быть опубликован в CON 510, например, используя алгоритм/функцию Publish (MK), без распределения MSK. Издатель также может получать МК из PKG 570, используя GetMK только один раз, как описано выше. Издатель может шифровать контент (т), используя наименование контента (или префикс) и МК, для получения зашифрованного контента (с), например, используя алгоритм/функцию Encrypt(name, МК, m). Издатель может затем опубликовать зашифрованый контент (с) с наименованием (или префиксом) контента, например, используя алгоритм/функцию Publish (c, name). В некоторых вариантах осуществления открытая идентичность (p-id) издателя может быть включена как часть метаданных контента. Кроме того, издатель также может подписывать контент, например, как описано в схеме 300 аутентификации контента, перед или после шифрования и публикации контента. Опубликованный контент затем может быть передан маршрутизатором 514 контента и сохранен или кэширован в CON 510.

Второй узел/сайт 550 заказчика, который может представлять собой абонента, может затем получать зашифрованный контент из CON 510. Второй узел/сайт 550 заказчика может абонировать зашифрованный контент с тем же или другим маршрутизатором 514 контента, например, используя алгоритм/функцию Subscribe (c, name). Издатель может запрашивать из PKG 570 частный ключ для дешифрования зашифрованного контента, используя наименование контента (или префикс), например, используя алгоритм/функцию GetPrk (name). PKG 570 может затем использовать MSK и наименование контента (или префикс) для генерирования частного ключа для издателя (pr-m), например, используя алгоритм/функцию GeneratePrK (MSK, name). Операция GeneratePrK () может представлять собой однократную операцию для одного наименования или префикса контента. Абонент может затем дешифровать зашифрованный контент (с) для получения оригинального контента m, используя pr-m, например, используя алгоритм/функцию Decrypt (c, pr-m). Кроме того, если контент подписан издателем, абонент может проверить абонируемый контент, например, как описано в схеме 300 аутентификации контента.

На фиг. 6 иллюстрируется вариант осуществления гибридной схемы 600 аутентификации контента, которая может использоваться для поддержки CON или ICN больших размеров и для улучшения масштабируемости схем 200 и 300 аутентификации контента. Крупномасштабные CON или ICN могут содержать множество доменов, каждый из которых может содержать множество маршрутизаторов контента, узлов/сайтов заказчика и соответствующий PKG. Гибридная схема 600 аутентификации контента может содержать элементы и компонент схемы 200 или 300 аутентификации контента, и PKI, и может обеспечивать возможность аутентификации контента между доменами, также называемой здесь аутентификацией контента с пересечением доменов или между доменами. Аутентификация контента с пересечением доменов или между доменами может обеспечить абоненту в первом домене возможность проверки аутентичности подписанного издателем контента во втором домене, используя подписанный, открытый для всей системы параметр или главный ключ (МК) второго домена (в соответствии со схемой 200 или 300 аутентификации контента). Абонент также может аутентифицировать подписанный МК, используя PKI, например, используя открытый ключ, для проверки МК, подписанного публикующим доменом, используя частный ключ.

Например, абонент (Боб) в первом домене (DomB) может запрашивать кэшированный контент, опубликованный издателем (Элис) во втором домене (DomA). Таким образом, абонент может запрашивать наименование объекта контента /DomA/Alice/объект-контента из маршрутизатора контента в CON. Маршрутизатор контента может возвращать требуемый объект контента, который может быть подписан частным ключом для издателя (Alice.SK), используя схемы 200 или 300 аутентификации контента. Абонент может также получать (из PKG DomA) МК (/DomA/pkg/sp), который может быть подписан частным ключом для DomA (DomA.prK), используя PKI. Абонент может проверять аутентичность принятого подписанного контента (данных), используя подписанный МК. Абонент также может проверять аутентичность подписанного МК, используя открытый ключ для DomA (DomA.pbK), соответствующий открытому ключу для DomA (DomA.prK). Открытый ключ для DomA (DomA.pbK) также может быть получен, используя PKI. Абонент также может использовать сертификат из доверенного СА для проверки аутентичности открытого ключа для DomA (DomA.pbK).

В гибридной схеме 600 аутентификации контента PKG и NRS могут представлять собой домен или организационные объекты, которые вырабатывают частный ключ издателя, МК, MSK и регистрируют наименование или префиксы для локальных пользователей в соответствующем домене. Например, предприятие может иметь свой собственный PKG, как в случае решения TrendMicro, основанном на идентичности решения шифрования электронной почты для предприятия, как описано в публикации под названием ″The true costs of e-mail encryption: Trend micro ibe (identity-based) vs. pki encryption,″ published Oct. 2010 in http://us.trendmicro.com/imperia/md/content/us/pdf/products/enterprise/emailencryption/the_true_cost_of_email_encryption_6-2010.pdf. В некоторых вариантах осуществления гибридная схема шифрования контента может использоваться на основе PKI и схемы 400 или 500 шифрования контента, используя ключи шифрования PKI, в дополнение к МК, и известную идентичность издателя или наименование контента (или префикс).

Гибридная схема 600 аутентификации контента может быть воплощена, как протокол CCN, и может быть масштабируемой на основе тог факта, что PKI развернут в домене или на уровне автономной системы (AS) в текущей Интернет - инфраструктуре. Например, расширение для безопасности системы наименований домена (DNSSEC), безопасность протокола интернет (IPsec) и уровень безопасных сокетов на стороне сервера (SSL)/безопасность уровня транспортирования (TLS) для услуг Интернет на основе сети основаны на инфраструктуре доверия PKI. В этих протоколах открытые ключи доменов сертифицируют, используя доверенные СА, которые показали себя, как соответствующее масштабируемое решение. PKI может использоваться для администрирования доверием на уровне домена, в то время как аутентификация контента на основе идентичности (используя схемы 200 и 300 аутентификации контента) и шифрование на основе идентичности (используя схемы 400 и 500 аутентификации контента) могут быть пригодны для конечного пользователя и администрирования доверием на уровне устройства. В CONS или ICN требование каждого провайдера контента или потребителя иметь сертификат с открытым ключом может быть дорогостоящим, и администрирование ключом может, таким образом, стать препятствием для множества применений. В этом случае представленная выше гибридная схема позволяет преодолеть такие ограничения. Кроме того, гибридная схема, представленная выше, может не нарушать преимущество доверия на основе контента и защиты конфиденциальности, используя аутентификацию контента на основе идентичности и шифрование контента на основе идентичности. Например, заказчику может потребоваться только сертификат открытого ключа домена для проверки аутентичности МК PKG. После этого доверие все еще может быть построено поверх доверия к идентичности провайдера контента или наименованию контента (или префикса), вместо сертификата индивидуального открытого ключа пользователя. Таким образом, нагрузка администрирования сертификата может быть ограничена на уровне домена.

На фиг. 7 иллюстрируется вариант осуществления формата 700 метаданных контента, который может быть кэширован или сохранен с данными контента в CON в любой из схем аутентификации контента и шифрования, представленных выше. Формат 700 метаданных контента может содержать наименование 702 контента и метаданные 720. Наименование 702 контента может обозначать наименование или префикс сохраненного/кэшированного контента или объекта контента. Например, наименование 702 контента может содержать /huawei.com/cona/security-report. Метаданные 720 могут содержать ID 704 знака (идентификатор знака sign-id), PKG МК 706 (pkg_mk), временную метку/версию 708 и сигнатуру (sig) 710. Идентификатор 704 знака может соответствовать известной для издателя открытой идентичности (p-id) или наименованию контента или префиксу, которые могут использоваться для получения закрытого ключа для издателя (pr-p или pr-m) для подписи контента. PKG МК 706 может быть сгенерирован PKG один раз во время установки, как описано выше, и может использоваться для всех издателей в домене. PHG МК 706 может обозначать значение МК или наименование МК, которое может затем использоваться для получения значения МК из CON. Временная метка/версия 708 может обозначать временную метку и/или версию для кэшированного/сохраненного контента. Сигнатура 710 может соответствовать подписанному значению хэш-функции наименования 702 контента, метаданным 710 и данным контента.

На фиг. 8 иллюстрируется вариант осуществления способа 800 аутентификации контента, который может использоваться для обеспечения целостности и аутентичности контента в CON. Способ 800 аутентификации контента может быть воплощен с помощью CON или маршрутизатора контента в CON. Способ 800 аутентификации контента может быть основан на схеме 200 аутентификации контента или схеме 300 аутентификации контента. Способ 800 может начинаться в блоке 802, где объект контента с сигнатурой, которая основана на известной идентичности, может быть принят в CON, например, с помощью маршрутизатора контента. Принятый объект контента может быть подписан и может быть опубликован пользователем или издателем. Сигнатура может быть основана на известной идентичности издателя, такой как ID издателя (например, адрес электронной почты или номер телефона), или на известном наименовании или префиксе контента. Сигнатура может быть подписана с использованием частного ключа издателя, который может быть сгенерирован с использованием известной идентичности и получен из PKG. Если известная идентичность представляет собой наименование контента или префикс, тогда известная идентичность может быть зарегистрирована в NRS.

В блоке 804 объект контента может быть кэширован или сохранен с сигнатурой в CON. Объект контента может быть кэширован или сохранен с метаданными, которые включают в себя сигнатуру. Объект контента может быть кэширован/сохранен без шифрования, например, как открытый текст, или может быть зашифрован перед кэшированием/сохранением, например, как зашифрованный текст.В некоторых вариантах осуществления метаданные также могут включать в себя известную идентичность, которая использовалась для получения сигнатуры. В блоке 806 запрос контента может быть принят в CON, например, тем же или вторым маршрутизатором контента. Запрос контента может быть принят от пользователя или абонента для кэшированного/сохраненного объекта контента. В блоке 808 запрашиваемый контент с сигнатурой может быть передан дальше. Маршрутизатор контента может передавать кэшированный/сохраненный контент абоненту с сигнатурой, включенной в контент. Абонент может затем проверить эту сигнатуру, используя известную идентичность, как описано выше. Идентичность может быть уже известна абоненту или может быть получена из метаданных контента. Способ 800 затем может закончиться.

На фиг. 9 иллюстрируется вариант осуществления способа 900 шифрования контента, который может использоваться для предоставления безопасности и конфиденциальности контента в CON. Способ 900 шифрования контента может быть воплощен с помощью CON или маршрутизатора контента в CON. Способ 900 шифрования контента может быть основан на схеме 400 шифрования контента или схеме 500 шифрования контента. Способ 900 может начинаться в блоке 902, где объект контента, зашифрованный на основе открытого для всей системы параметра или главного ключа (МК), может быть принят в CON, например, маршрутизатором контента. Принятый объект контента может быть зашифрован и опубликован пользователем или издателем. Шифрование может быть основано на МК, который может быть передан из PKG издателю.

В блоке 904 объект зашифрованного контента может быть кэширован или сохранен в CON, например, как зашифрованный текст.В некоторых вариантах осуществления зашифрованный контент может быть кэширован/сохранен с метаданными, которые включают в себя известную идентичность издателя или наименования контента или префикс. В блоке 906 запрос на контент может быть принят в CON, например, с использованием того же или другого маршрутизатора контента. Запрос на контент может быть принят от пользователя или абонента для кэшированного/сохраненного объекта контента. В блоке 908 может быть передано дальше запрашиваемый зашифрованный контент. Маршрутизатор контента может направлять кэшированное/сохраненное зашифрованное контента абоненту. Абонент может затем получить закрытый ключ для издателя из PKG, используя известную идентичность издателя или наименование контента или префикс. Абонент может затем использовать закрытый ключ для дешифрования принятого зашифрованного контента. Идентичность издателя по наименованию контента или префиксу может уже быть известна абоненту или может быть получена из метаданных зашифрованного контента. Способ 900 может затем закончиться.

На фиг. 10 иллюстрируется вариант осуществления модуля 1000 сети, который может представлять собой любое устройство, которое транспортирует и обрабатывает данные через сеть. Например, модуль 1000 сети может быть размещен в маршрутизаторе контента или в любом узле в CON 100 или в любом узле в схемах CON, описанных выше. Маршрутизатор контента быть может также выполнен с возможностью осуществления или поддержки способов и системы CON, описанных выше. Модуль 1000 сети может содержать один или больше портов или модулей 1010 ввода, соединенных с приемником (R10) 1012 для приема сигналов и фреймов/данных из других сетевых компонентов. Модуль 1000 сети может содержать модуль 1020 определения наличия контента для определения, в какой из компонентов сети передать контент.Модуль 1020 определения наличия контента может быть воплощен с использованием аппаратных средств, программных средств или обоих подходов. Модуль 1000 сети может также содержать один или больше портов или модулей 1030 вывода, соединенных с передатчиком (Т10) 1032 для передачи сигналов и фреймов/данных в другие сетевые компонентам. Приемник 1012, модуль 1020 определения наличия контента и передатчик 1032 также могут быть сконфигурированы с возможностью воплощения, по меньшей мере, некоторых из раскрытых способов, которые могут быть основаны на аппаратных средствах, программных средствах или обоих подходах. Компоненты модуля 1000 сети могут быть расположены, как показано на фиг. 10.

Модуль 1020 определения наличия контента также может содержать программируемый блок 1028 плоскости перенаправления контента и один или более блоков 1022 сохранения, которые могут быть соединены с программируемым блоком 1028 плоскости перенаправления контента. Программируемый блок 1028 плоскости перенаправления контента может быть выполнен с возможностью воплощения функций направления и обработка контента, таких как на уровне приложения или L3, где контент может быть передан на основе наименования контента или префикса 10 и, возможно, другой, относящейся к контенту информации, которая отображает контент на сетевой трафик. Такая информация отображения может поддерживаться в таблице контента, как модуль 1020 определения наличия контента или модуль сети 1000. Программируемый блок 1028 плоскости направления контента может интерпретировать запросы пользователя на контент и, соответственно, предоставлять контент, например, на основе метаданных и/или наименования контента, из сети или других маршрутизаторов контента, и может сохранять контент, например, временно, в блоках 1022 сохранения. Программируемый блок 1028 плоскости направления контента может затем направлять кэшированный контент пользователю. Программируемый блок 1028 плоскости направления контента может быть воплощен с использованием программных средств, аппаратных средств или обоих этих подходов и может работать выше уровня IP или L2. Блоки 1022 сохранения могут содержать кэш 1024 для временного сохранения контента, такого как контент, который запрашивает заказчик. Кроме того, блоки 1022 сохранения могут содержать долговременный накопитель 1026 для относительно длительного сохранения контента, такого как, например, контент, переданный издателем. Например, кэш 1024 и долговременный накопитель 1026 может включать в себя динамические оперативные запоминающие устройства (DRAM), твердотельные устройства (SSD), жесткие диски или их комбинации.

По меньшей мере, некоторые из способов и сетевых компонентов, описанных выше, могут быть воплощены в любом сетевом компоненте общего назначения, таком как компьютер или сетевой компонент, с достаточной мощностью обработки, ресурсами памяти и пропускной способностью сети для обработки необходимой рабочей нагрузки, установленной в нем. На фиг. 11 иллюстрируется типичный компонент 1000 сети общего назначения, пригодный для воплощения одного или больше вариантов осуществления компонентов, раскрытых здесь. Компонент 1100 сети включает в себя процессор 1102 (который может называться центральным процессорным устройством или CPU), который сообщается с запоминающими устройствами, включающими в себя внешний накопитель 1104, постоянное запоминающее устройство (ROM) 1106, оперативное запоминающее устройство (RAM) 1108, устройства 1110 ввода-вывода (I/O) и устройства 1112 соединения с сетью. Процессор 1102 может быть воплощен, как одна или более микросхем CPU или может представлять собой часть из одной или больше специализированных интегральных схем (ASIC).

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

По меньшей мере, был раскрыт один вариант осуществления, и варианты, комбинации и/или модификации, в соответствии с вариантом (вариантами) осуществления и/или свойствами варианта (вариантов) осуществления, выполненные специалистом в данной области техники, находятся в пределах объема раскрытия. Альтернативные варианты осуществления, которые могут быть получены в результате комбинирования, интегрирования и/или выполнения варианта (вариантов) осуществления, также находятся в пределах объема раскрытия. В случае, когда цифровые диапазоны или ограничения выражены в явном виде, такие выраженные диапазоны или ограничения следует понимать, как включающие в себя итеративные диапазоны или ограничения одинаковой магнитуды, попадающие в пределы явно выраженных диапазонов или ограничений (например, диапазон от приблизительно 1 до приблизительно 10 включает в себя 2, 3, 4 и т.д.; больше чем 0,10 включает в себя 0,11, 0,12, 0,13 и т.д.). Например, всякий раз, когда раскрыт цифровой диапазон с нижним пределом, R₁, и верхним пределом, R_u, любое число, попадающее в пределы этого диапазона, в частности, раскрыто. В частности, следующие числа в пределах диапазона, в частности, раскрыты: R=R₁+k*(R_u-R₁), где k представляет собой переменную в диапазоне от 1 процента до 100 процентов с приращением 1 процент, то есть k равняется 1 процент, 2 процента, 3 процента, 4 процента, 7 процентов, …, 70 процентов, 71 процент, 72 процента, …, 97 процентов, 96 процентов, 97 процентов, 98 процентов, 99 процентов или 100 процентов. Кроме того, любой цифровой диапазон, определенный двумя числами R, определенными выше, также, в частности, раскрыт. Использование термина ″в случае необходимости″ в отношении любого элемента формулы изобретения означает, что этот элемент требуется или, в качестве альтернативы, этот элемент не требуется, при этом обе альтернативы находятся в пределах формулы изобретения. Использование более широких терминов, таких как содержит, включает в себя и имеющий, следует понимать, как обеспечение поддержки для более узких терминов, таких как состоящий из, состоящий, по существу, из, и состоящий, в частности, из. В соответствии с этим, объем защиты не ограничен описанием, представленным выше, но определен формулой изобретения, которая следует ниже, при этом этот объем включает в себя все эквиваленты предмета формулы изобретения. Каждый пункт формулы изобретения внедрен в описание, как дополнительное раскрытие, и пункты формулы изобретения представляют вариант (варианты) осуществления настоящего раскрытия. Описание ссылок в раскрытии не представляет собой допущение того, что оно представляет собой предшествующий уровень техники, в частности, какой-либо ссылки, которая имеет дату публикации после даты приоритета данной заявки. Раскрытие всех патентов, заявок на патент и публикаций, цитируемых в раскрытии, таким образом, представлено здесь по ссылке в той степени, что они представляют собой примерные, процедурные или представляющие другие детали, дополняющие раскрытие.

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

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

Изобретение относится к области передачи данных. Технический результат - снятие нагрузки с абонента по проверки степени доверия к открытому ключу издания. Маршрутизатор контента, содержащий накопитель, выполненный с возможностью кэшировать в сети, ориентированной на контент (CON), объект контента с сигнатурой, подписанной издателем на основе идентификационных данных, известных абоненту; и передатчик, соединенный с накопителем и выполненный с возможностью направления объекта контента с сигнатурой по запросу абонента, при этом сигнатура выполнена с возможностью ее использования абонентом для проверки целостности объекта контента на основе известных идентификационных данных без проверки степени доверия ключа издателя для упомянутого издателя, причем известные идентификационные данные вызывают доверие издателя и не требуют проверки доверия со стороны издателя. 4 н. и 26 з.п. ф-лы, 11 ил.

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

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

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

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

5. Маршрутизатор контента по п. 4, в котором секретный ключ издателя получен при помощи генератора секретных ключей (PKG), генерирующего главный ключ (МК), распространяемый в CON, и секретный главный ключ (MSK), который не распространяется, при этом секретный ключ издателя получен с использованием MSK и известных идентификационных данных.

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

7. Маршрутизатор контента по п. 1, в котором открытый ключ издателя не распространяется в CON, при этом абоненту не требуется и абонентом не используется открытый сертификат из доверенной сертификационной организации (СА) для установления доверия.

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

9. Сетевой компонент по п. 8, в котором контент кэширован с метаданными, содержащими сигнатуру и идентификационные данные.

10. Сетевой компонент по п. 8, в котором идентификационные данные представляют собой наименование контента или префикс, регистрируемые в службе регистрации наименований (NRS) контента, если наименование или префикс контента являются новыми.

11. Сетевой компонент по п. 10, в котором NRS выполнена с возможностью получения секретного ключа для наименования или префикса контента из PKG и передачи секретного ключа абоненту для дешифровки зашифрованного контента с использованием секретного ключа.

12. Сетевой компонент по п. 11, в котором секретный ключ получен без использования инфраструктуры открытых ключей (PKI).

13. Сетевой компонент по п. 8, в котором идентификационные данные представляют собой идентификационные данные абонента.

14. Сетевой компонент по п. 8, в котором идентификационные данные представляют собой идентификационные данные наименования контента.

15. Сетевой компонент по п. 8, в котором идентификационные данные представляют собой идентификационные данные префикса.

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

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

18. Способ по п. 17, в котором издатель получает секретный ключ из PKG только один раз и использует один и тот же секретный ключ для подписания множества объектов контента, причем издатель получает секретный ключ из PKG.

19. Способ по п. 17, в котором абонент проверяет сигнатуру с использованием открытых идентификационных данных и МК из PKG без использования защищенного канала между PKG и абонентом, при этом абонент получает МК из PKG только один раз и использует один и тот же МК для проверки множества объектов контента.

20. Способ по п. 17, в котором CON содержит множество доменов, содержащих множество соответствующих издателей, абонентов и PKG, причем абонент в первом домене проверяет сигнатуру объекта контента, подписанного издателем во втором домене с использованием МК, сгенерированного PKG во втором домене, и подписанного с использованием второго секретного ключа во втором домене, сгенерированного инфраструктурой открытых ключей (PKI) CON, при этом абонент проверяет аутентичность подписанного МК с использованием открытого ключа во втором домене, сгенерированного PKI и соответствующего второму секретному ключу, и проверяет аутентичность открытого ключа с использованием сертификата от доверенной сертификационной организации (СА).

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

22. Способ по п. 16, в котором абонент использует одни и те же открытые идентификационные данные для проверки одного и того же объекта контента, опубликованного группой пользователей или множеством издателей с использованием одного и того же наименования или префикса.

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

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

25. Система по п. 24, в которой известные идентификационные данные представляют собой идентификационные данные издателя, известные абоненту, или идентификационные данные объекта контента, содержащие полное наименование или префикс наименования объекта контента.

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

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

28. Система по п. 27, в которой секретный ключ издателя получен при помощи генератора секретного ключа (PKG), генерирующего главный ключ (МК), распространяемый в CON, и главный секретный ключ (MSK), который не распространяется, при этом секретный ключ издателя получен издателем с использованием MSK и известных идентификационных данных.

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

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