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

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

Иллюстрации

Показать все

Реферат

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

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

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

В сети, ориентированной на контент (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), например, использ