Результат интеллектуальной деятельности: ДЕЛЕГИРОВАНИЕ IP АДРЕСА

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

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

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

Адреса IPv6 составляют 128 битов длиной. Первые 64 бита адреса формируют префикс маршрутизации, который уникальным образом идентифицирует узел доступа в Интернет (или так называемую "местную связь"), используемый IP терминалом или узлом, последние 64 бита формируют индекс главного узла, который уникальным образом идентифицирует мобильный терминал для узла доступа (или в пределах местной связи). Индекс главного узла упоминается как "идентификатор интерфейса", поскольку он опознает главный узел уникальным образом по интерфейсу доступа. Как правило, когда главный узел регистрируется в узле доступа, главный узел изучает префикс маршрутизации узла доступа из пробного сообщения, посланного узлом доступа. Согласно IETF RFC3041, затем главный узел генерирует идентификатор интерфейса, используя случайное число, сгенерированное главным узлом. Главный узел может дополнительно использовать адрес уровня линии связи, чтобы генерировать идентификатор интерфейса, адрес уровня линии связи, являющийся, например, адресом уровня MAC, используемым сетью доступа.

WO 02/076060 описывает, как узел может генерировать криптографическую версию идентификатора интерфейса, используя одностороннюю кодирующую функцию, такую как хеш-функцию, и предоставить ее другому одноранговому пользователю, который может проверить, является ли узел владельцем части идентификатора интерфейса IP-адреса. Такие криптографически генерированные адреса известны как CGAs. CGAs обеспечивают уровень безопасности, чтобы помочь предотвратить, например, отклонение атаки службы, в которой нападающий утверждает, что является владельцем IP-адреса, который узел хочет использовать. Подход CGA был стандартизирован в IETF RFC3972 и используется среди прочего в протоколе безопасного обмена данными между соседними узлами (SeND), стандартизированном в IETF RFC 3971.

Согласно RFC 3972, CGAs генерированы следующим образом:

Хеш1=хеш (модификатор | префикс | открытый ключ | расширения)

IPv6 адрес=префикс | хеш1 (с определенным набором бит, согласно уровню безопасности и другим требованиям).

Где "префикс" является префиксом маршрутизации сети, "хеш" является криптографической хеш-функцией (SHA-I), "открытый ключ" - это открытый ключ узла, генерирующего адрес, и "расширения" - это в настоящее время неиспользованная область для стандартизированной информации. "Модификатор" - 128 битовых значений, генерированных узлом для повышения безопасности и увеличения уровня случайности. Более подробно, в зависимости от необходимого уровня безопасности, отбирается значение модификатора, что приводит к определенной связи данных (включая модификатор и открытый ключ), хешированных к значению ("Hash2"), которое имеет конкретное количество "0" в крайних левых битах.

Чтобы доказать владение CGA, узел должен предоставить свидетельство, содержащее часть адреса CGA с идентификатором интерфейса (IID), модификатор, открытый ключ и любое расширение, выполненное как структура данных CGA. Свидетельство содержит цифровую подпись (SHA-1), пересекающую сообщение, которое будет послано (связанное с тегом типа CGA 128-бит) с использованием закрытого ключа узла. Одноранговый узел, принимающий свидетельство, сначала вычисляет Hash2 и проверяет, что он имеет правильное количество "0" в крайних левых битах. В таком случае, он вычисляет Hashl и сравнивает его с IID, таким образом, проверяя, что IID принадлежит паре открытого и закрытого ключа, затем проверяет подпись, посредством обращения процесса подписания, используя проверенный открытый ключ. Этот второй шаг подтверждает, что отправитель является владельцем открытого ключа, а не просто незаконно его присвоил, так же как доказывая, что сообщение создано заявленным отправителем.

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

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

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

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

Варианты осуществления настоящего изобретения позволяют главному узлу делегировать ответственность за IPv6 адрес дополнительному главному узлу, даже если эти адреса еще не сгенерированы.

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

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

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

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

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

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

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

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

Фиг.1 схематично изображает структуру в качестве примера нового свидетельства делегирования CGA.

Фиг.2 схематично иллюстрирует компоненты системы связи, вовлеченной в производство и использование свидетельства делегирования CGA.

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

Подробное описание чертежей

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

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

Предполагая, что уровень безопасности, требуемый для CGA, установлен на его самой низкой величине (то есть момент=0 согласно RFC3972), алгоритм для произведения модификатора может быть легко определен. Более сложные рассмотрения возникают, когда момент>0.

Делегирующий полномочия узел включает в свидетельство подпись, созданную с ее закрытым ключом, и предоставляет свидетельство наделенному полномочиями узлу. Это может быть осуществлено любым соответствующим механизмом, например, используя механизм, описанный в Разделе 6 IETF RFC3972. Как будет оценено специалистами в этой области техники, подпись связана со структурой данных CGA. Позднее делегирующий полномочия узел сгенерирует для себя CGA. Чтобы осуществить это, он, в случае необходимости, генерирует модификатор (и любые расширения), используя указанный алгоритм(ы), и выбирает или генерирует соответствующий префикс маршрутизации сети и выполняет процедуру, описанную в разделе 4 RFC 3972.

В это время делегирующий полномочия узел уведомит наделенный полномочиями узел о его новом адресе IPv6. Впоследствии, когда наделенный полномочиями узел просит узел третьей стороны (узел "подтверждения") действовать относительно нового CGA, наделенный полномочиями узел должен включать свидетельство с запросом. Узел подтверждения выполняет следующие действия, чтобы проверить запрос:

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

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

• Поскольку величина реального количества столкновений, используемая во время генерации CGA, не будет известной во время проверки, узел подтверждения должен установить количество столкновений последовательно 1, 1 и 2 и затем выполнить алгоритм, описанный в Разделе 5 IETF RFC3972, чтобы подтвердить, что CGA принадлежит открытому ключу делегирующего полномочия узла.

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

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

Предполагая, что уровень безопасности установлен на низкий уровень, то есть момент=0, нет необходимости, чтобы узел подтверждения вычислял Hash2. Однако, если момент>0, процедура, описанная в шагах 6 и 7 Секции 5 RFC3972, должна быть выполнена.

Фиг.2 схематично иллюстрирует делегирующий полномочия узел 1, который включает в себя первый процессор 2, выполненный с возможностью генерировать свидетельство делегирования, как описано выше. Второй процессор 3, выполненный с возможностью генерировать CGA, используя параметры, содержащиеся в вышеупомянутом свидетельстве. Свидетельство и уведомление о генерации CGA отправляются по выводу 4 к наделенному полномочиями узлу 5. Этот узел 5 принимает свидетельство на первом вводе 6 и принимает уведомления на втором вводе 7. Процессор 9 отвечает за генерацию запросов относительно наделенного полномочиями CGA и за их отправку узлу подтверждения 10 вместе со свидетельством. Запросы принимаются узлом подтверждения 10 на вводе 11. Выполняется процесс проверки свидетельства, а именно: проверка, что префикс маршрутизации сети в пределах диапазона 12, проверка, что IID соответствует открытому ключу 13, и проверка подписи 14.

Фиг.3 - блок-схема последовательности операций, иллюстрирующая процесс проверки свидетельства. Проиллюстрированные этапы включают в себя прием запроса (относительно CGA) в узле подтверждения от наделенного полномочиями узла (этап 100), извлечение префикса маршрутизации от CGA (этап 101), проверка, что префикс маршрутизации находится в пределах диапазона, определенного в свидетельстве (этап 102), проверка IID CGA (этап 103) и проверка подписи (этап 104). Если проверка дает сбой на любом из этапов, запрос отклоняется (этап 106). Если все этапы проверки успешны, запрос принимается и обрабатывается (этап 105).

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