Способ и устройство протокола идентификации хост-узла

Изобретение относится к области идентификации хост-узлов в сетях передачи данных. Технический результат заключается в уменьшении трафика при идентификации узла. Сущность изобретения заключается в том, что из первого хост-узла (Инициатора) во второй хост-узел (Ответчик) передается (S2) сообщение (I2') аутентификации, содержащее идентификатор (HIT) первого хост-узла (Инициатора) и криптографический элемент (PF). Сообщение (I2') аутентификации принимается (S3) во втором хост-узле (Ответчике). После получения идентификатор и информация, относящаяся к общему состоянию, используются (S4) для аутентификации криптографического элемента (PF). Если криптографический элемент и остальная часть сообщения аутентификации аутентифицируются, то из второго хост-узла (Ответчика) в первый хост-узел (Инициатор) передается сообщение (R2') подтверждения, чтобы указывать успешную аутентификацию. Эти два сообщения (I2' и R2') эквивалентны сообщениям I2 и R2 протокола базового обмена стандартного HIР, и необходимость в сообщениях I1 и R1 из протокола базового обмена стандартного HIP отпадает. 8 н. и 38 з.п. ф-лы, 5 ил.

 

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

Изобретение относится к способу и устройству Протокола Идентификации Хост-узла (Host Identity Protocol, HIP).

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

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

Принимая во внимание проблемы управления мобильностью и безопасности был представлен стандарт Mobile IP (см. C. Perkins, "IP Mobility Support for IPv4", RFC 3220, IETF, 2002) и стандарт Mobile IPv6 (см. D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", RFC3775, IETF, 2004). Планируется, что вместе эти спецификации предоставят поддержку мобильности для Интернета следующего поколения. Работы в части защищенности находятся в разработке в форме протокола IPsec и связанных мероприятий, таких как различные протоколы обмена ключами с целью обеспечения защищенности в уровне IP. Однако опыт показал, что, используя существующие стандарты, достаточно сложно достигнуть сочетания защищенности и мобильности.

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

Одним из решений этой проблемы является разделение функций идентификации и местоположения друг от друга, и этот подход лежит в основе предложения Протокола Идентификации Хост-узла (Host Identity Protocol, HIP)(см. R. Moskowitz, P. Nikander, P. Jokela, "Host Identity Protocol", Internet Draft, work in progress, draft-ietf-hip-base-02, IETF, 2005). Протокол HIP разделяет роли местоположения и идентификации IP-адресов путем представления нового пространства имен - Идентификации Хост-узла (Host Identity, HI). В протоколе HIP, HI, по существу, представляют собой общий криптографический ключ из криптографической пары ключей общий-личный, причем этот ключ генерируется из личного ключа и связывается с ним. Общий ключ идентифицирует сторону, которая держит единственную копию личного ключа. Хост-узел, владеющий личным ключом из криптографической пары, может непосредственно доказать, что он "владеет" общим ключом, который используется для его идентификации в сети. Разделение также предоставляет средство для обработки мобильности и множественной адресации защищенным образом.

HIP более подробно описан ниже, но это не единственное предложение, основанное на идее разделения местоположения и идентификации. Архитектура FARA (см. D. Clark, R. Braden, A. Falk, V. Pingali, "FARA: Reorganizing the Addressing Architecture", ACM SIGCOMM 2003 Workshops, August 25 & 27, 2003) представляет собой общую модель идей, которая предоставляет структуру, из которой может быть получена фактическая архитектура. FARA может использовать HIP, когда идентификации узлов изменяются, и, следовательно, HIP может быть частью определенной реализации FARA. В предложении PeerNet (см. J. Eriksson, M. Faloutsos, S. Krishnamurthy, "PeerNet: Pushing Peer-to-Peer Down the Stack", IPTPS '03, February 20 - 21, 2003) также рассматривается разделение местоположения и идентификации. Инфраструктура Internet Indirection Infrastructure, I³ (см. I. Stoica, et.al., "Internet Indirection Infrastructure", ACM SIGCOMM '02, August 19-23, 2002) также определяет разделение между информацией идентификации и маршрутизации.

HIP представляет разделение между информацией местоположения и идентификации на уровне IP. В добавление к разделению протокол согласовывает Защищенные Связи (Security Association, SA) между узлами с функцией HIP.

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

Будучи общим ключом, HI может быть достаточно длинной и, следовательно, непрактичной во всех ситуациях. В HIP HI представляется Меткой Идентификации Хост-узла (Host Identity Tag, HIT), которая генерируется из HI путем ее хэширования. Соответственно, существует небольшой риск конфликта, что две HI будут хэшированы в одну и ту же HIT. Таким образом, метка HIT идентифицирует HI. Принимая во внимание, что HIT имеет длину 128 битов, она напрямую может использоваться для приложений IPv6, поскольку она имеет ту же длину, что и адреса IPv6.

Еще одним представлением HI является Локальный Идентификатор Области (Local Scope Identifier, LSI), который является 32-битным представлением для HI. Целью LSI является облегчить использование HI в существующих протоколах и Интерфейсах Прикладной Программы (Application Program Interface, API). Например, поскольку LSI имеет ту же длину, что и адреса IPv4, он напрямую может использоваться для приложений IPv4. Несмотря на то, что большая часть этого описания основана на использовании более длинной HIT, совершенно очевидно, что те же или схожие соображения применимы для альтернативного представления LSI.

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

Приложения, как правило, не интересует информация местоположения, а им необходимо знать идентификацию их одноранговых узлов. Идентификация представляется посредством HIT. Это означает, что IP-адрес имеет значение только на низших уровнях, где затрагивается маршрутизация. HIT, которые используются приложениями, должны быть сопоставлены соответствующим IP-адресам до того, как какой-либо пакет покинет хост-узел. Это достигается в новом Уровне Идентификации Хост-Узла (Host Identity Layer), как описано ниже.

Фиг.1 из прилагаемых чертежей иллюстрирует различные уровни в HIP, включая стандартный транспортный уровень 4, сетевой уровень 8 и канальный уровень 10, где приложение или процесс 2 осуществляет связь с транспортным уровнем 4, находящимся под ним. С HIP новый Уровень 6 Идентификации Хост-узла размещается между транспортным уровнем 4 и сетевым уровнем 8.

Локально, каждая HI и ее связанная HIT сопоставляются IP-адресам узла. Когда пакеты покидают хост-узел, выбирается корректный маршрут (каким-либо средством), и соответствующие IP-адреса вставляются в пакет как адреса источника и назначения. Каждый пакет, поступающий из верхнего уровня, содержит HIT однорангового узла как адрес назначения. Сопоставление между HIT и информацией местоположения можно найти на Уровне 6 Идентификации Хост-узла. Следовательно, адрес назначения преобразуется в сопоставленный IP-адрес, и HIT источника преобразуется в IP-адрес источника.

HIP определяет базовый обмен сообщениями, содержащий четыре сообщения (четырехпроходное рукопожатие), и это используется для создания Защищенных Связей (Security Association, SA) между хост-узлами с функцией HIP. В течение обмена сообщениями используется процедура Диффи-Хеллмана, чтобы создать ключ сеанса и чтобы основать между узлами пару Защищенных Связей (Security Associations) IPsec Инкапсуляции Полезной Нагрузки Безопасности (Encapsulating Security Payload, ESP).

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

Когда Ответчик получает пакет I1, он передает обратно пакет R1, который содержит головоломку, которую должен решить Инициатор. Протокол устроен так, что Инициатор должен выполнить большую часть вычислений в течение решения головоломки. Это обеспечивает некоторую защиту от атак типа Отказ от Обслуживания (Denial of Service, DoS). Пакет R1 также содержит метки HIT узлов, участвующих в согласовании. В добавление, пакет R1 инициирует процедуру Диффи-Хеллмана, содержащую общий ключ PK_R Идентификации Хост-узла Ответчика, вместе с параметрами Диффи-Хеллмана, включающими в себя общий ключ DH_R Диффи-Хеллмана Ответчика.

При получении пакета R1 Инициатор решает головоломку и передает Ответчику ответ в пакете I2, включающем в себя решение вместе со значением IPsec SPI и его общим ключом PK_I Идентификации Хост-узла, зашифрованным с использованием ключа сессии, который был построен с только что полученным общим ключом DH_R Диффи-Хеллмана Ответчика (хотя в стандартном протоколе HIP шифрование общего ключа PK_I Идентификации Хост-узла становится опциональным). Пакет I2 также содержит метки HIT узлов, принимающих участие в согласовании, а также ключ DH_I Диффи-Хеллмана Инициатора. Ответчик верифицирует, что головоломка была решена, аутентифицирует, что отправителем сообщения является Инициатор, путем верификации, что подпись сообщения была создана посредством личного ключа, соответствующего общему ключу PK_I Идентификации Хост-узла Инициатора, и создает несколько IPsec ESP SA. Последнее сообщение R2 содержит значение Индекса Параметра Защищенности (Security Parameter Index, SPI) ответчика и метки HIT узлов, участвующих в согласовании. Очевидно, что создание IPsec ESP SA становится опциональным в стандартном базовом обмене HIP.

В добавление к пакетам I1, R1, I2 и R2 спецификация HIP определяет другие пакеты, включая пакет UPDATE. Когда между двумя осуществляющими связь хост-узлами с функцией HIP существует активная связь HIP, пакет UPDATE может использоваться, чтобы обновлять общее состояние. Например, пакет UPDATE используется, чтобы обновлять Защищенные Связи ESP. Существуют расширения базовой спецификации HIP, например, протоколы HIP Mobility и Multi-homing (см. P. Nikander, J. Arkko, P. Jokela, "End-Host Mobility and Multihoming with Host Identity Protocol", Internet Draft, work in progress, draft-ietf-hip-mm-01, IETF, 2005), которые используют пакеты UPDATE для различных целей. Примечательно, что хост-узел HIP игнорирует и отбрасывает пакеты UPDATE, если он не имеет какой-либо активной связи HIP с отправителем пакета UPDATE.

Связи SA между хост-узлами привязаны к Идентификациям Хост-узлов, представляемым метками HIT. Тем не менее, пакеты данных, проходящие в сети, не содержат действительной информации HI, а поступающий пакет идентифицируется и сопоставляется корректной SA, используя значение SPI в заголовке IPsec. Фиг.3 из прилагаемых чертежей иллюстрирует логическую и действительную структуры пакета, когда он перемещается в сети.

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

Когда исходящий пакет поступает на уровень HI с вышестоящего уровня, то HIT назначения верифицируется из Базы Данных Защищенных Связей (Security Association Database, SADB) IPsec. Если обнаруживается SA, соответствующая HIT назначению, то пакет зашифровывается с использованием ключа сессии, связанного с SA.

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

В принимающем хост-узле величина SPI используется, чтобы найти корректную SA из IPsec SADB. Если запись обнаруживается, то IP-адреса могут быть изменены на соответствующие метки HIT, и пакет может быть расшифрован, используя ключ сессии.

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

Другие технические вопросы возникают при реализации HIP в мобильных сетях связи третьего поколения (3^rd Generation, 3G), где не все Пользовательское Оборудование в окружении 3G имеет функцию HIP. В этом контексте Универсальная Система Мобильной Связи (Universal Mobile Telecommunications System, UMTS) является 3G наследником Глобальной Системы Мобильной Связи (Global System for Mobile Communications, GSM). Самым важным эволюционным шагом от GSM к UMTS является Общая Служба Пакетной Передачи Данных (General Packet Radio Service, GPRS). GPRS представляет коммутацию пакетов в базовую сеть GSM и предоставляет возможность прямого доступа к сетям пакетной передачи данных (Packet Data Network, PDN). Это обеспечивает возможность коммутируемой пакетной передачи через базовую сеть GSM на скорости, которая гораздо выше предела сети ISDN в 64 кбит/сек, что необходимо для скоростей передачи в 2 Мбит/сек и более для UMTS. GPRS является необходимым условием для представления UMTS. Схожие принципы в равной степени применимы как к UMTS, так и к GPRS. GPRS разрабатывалась как расширение существующей инфраструктуры сети GSM с целью предоставления службы пакетной передачи данных без необходимости установления соединения. По сравнению с GSM GPRS представляет несколько новых функциональных элементов, которые поддерживают сквозную пакетную передачу данных на основе IP.

Как упомянуто выше, полный протокол базового обмена является протоколом с четырьмя сообщениями и двумя циклами туда/обратно. В предложении Hi3 (см. Internet Draft, work in progress, draft-nikander-hiprg-hi3-00.txt) предлагается уменьшить на один количество циклов туда/обратно на конце Ответчика путем сохранения предварительно вычисленного сообщения R1 в промежуточном ящике и путем предоставления возможности промежуточному ящику отвечать на сообщения I1 напрямую, тем самым уменьшая общее количество сообщений, которые видит ответчик до I2 и R2, то есть до двух сообщений и одного цикла туда/обратно. Тем не менее, это решение не изменяет положения на конце Инициатора.

Рассматривая беспроводной базовый обмен HIP у Инициатора, два цикла туда/обратно в полном протоколе базового обмена HIP могут привести к проблеме производительности. Инициатор должен ожидать завершения двух циклов туда/обратно до того как он сможет осуществлять связь с Ответчиком, что является потенциальным узким местом производительности. Было бы желательным уменьшить количество требуемых сообщений и, таким образом, уменьшить задержку при установлении сессии.

Согласно первому аспекту настоящего изобретения предоставлен способ модифицированного базового обмена Протокола Идентификации Хост-узла (Host Identity Protocol, HIP), содержащий один цикл и два сообщения, для использования первым и вторым хост-узлами HIP, имеющими общее состояние из ранее существующей взаимосвязи, содержащий этапы, на которых: передают из первого хост-узла во второй хост-узел сообщение аутентификации, содержащее идентификатор первого хост-узла и криптографический элемент; принимают сообщение аутентификации во втором хост-узле и используют идентификатор и информацию, относящуюся к общему состоянию, чтобы аутентифицировать криптографический элемент; и после успешной аутентификации криптографического элемента передают из второго хост-узла в первый хост-узел сообщение подтверждения, которое указывает успешную аутентификацию. Идентификатор может быть меткой идентификации HIP. Метка идентификации HIP может быть Меткой Идентификации Хост-узла (Host Identity Tag, HIT) или Локальным Идентификатором Области (Local Scope Identifier, LSI).

Аутентификация криптографического элемента может содержать верификацию источника криптографического элемента.

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

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

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

Криптографическая функция может иметь в качестве ввода, по меньшей мере, идентификатор.

Криптографическая функция может быть хеш-функцией.

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

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

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

Цепочка хеширования может генерироваться в результате ранее существующей взаимосвязи.

Цепочка хеширования может быть выделена для взаимодействий между первым и вторым хост-узлами.

Цепочка хеширования может быть выделена для взаимодействий между первыми хост-узлами и множеством таких вторых хост-узлов.

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

Секретная информация может содержать криптографический ключ.

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

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

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

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

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

Информация общего состояния может храниться во втором хост-узле.

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

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

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

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

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

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

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

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

Способ может содержать этап, на котором после приема сообщения подтверждения в первом хост-узле создают Защищенную Связь (Security Association) HIP между первым и вторым хост-узлами.

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

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

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

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

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

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

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

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

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

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

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

Операционная программа может содержаться на носителе. Носитель может быть средством передачи. Средство носителя может быть запоминающим средством.

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

Фиг.1 - иллюстрация различных уровней в Протоколе Идентификации Хост-узла;

Фиг.2 - иллюстрация работы четырехпроходного рукопожатия в протоколе HIP;

Фиг.3 - иллюстрация логической и действительной структур пакета в HIP;

Фиг.4 - иллюстрация обзора способа модифицированного базового обмена HIP согласно настоящему изобретению; и

Фиг.5 - более подробная иллюстрация способа модифицированного базового обмена HIP согласно настоящему изобретению.

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

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

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

Во-вторых, оно предоставляет Инициатору головоломку, так что Инициатор может показать Ответчику свою "честность" путем решения головоломки.

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

В случае, когда Инициатор и Ответчик не имеют какой-либо ранее существующей взаимосвязи, улучшение маловероятно; Инициатор должен получить свежее сообщение R1, так чтобы он мог показать Ответчику свою "честность" и свежесть обмена.

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

Фиг.4 представляет собой обзорную схему, иллюстрирующую способ модифицированного базового обмена HIP согласно варианту осуществления настоящего изобретения. Из сравнения Фиг.2 и 4 можно увидеть, что этот способ, являющийся вариантом осуществления настоящего изобретения, почти соответствует способу стандартного базового обмена HIP, но в этом варианте осуществления настоящего изобретения этапы I1 и R1 способа базового обмена стандартного HIP не выполняются. Кроме того, решение головоломки в сообщении I2 заменяется новым параметром HIP, который называется Парной Свежестью (Paired Freshness, PF), который содержит свежий криптографический элемент. Источник криптографического элемента верифицируется Ответчиком, используя информацию, относящуюся к общему состоянию, являющемуся результатом предварительно существующей взаимосвязи между Инициатором и Ответчиком. Точная форма криптографического элемента и информации общего состояния варьирует, как описано ниже со ссылкой на конкретные варианты осуществления настоящего изобретения. Сверх того, примечательно, что общее состояние может быть ассиметричным в том смысле, что Инициатор и Ответчик могут держать различные части информации, и взаимосвязь между этими частями информации может быть криптографической.

Фиг.5 соответствует Фиг.4, но более подробно иллюстрирует этапы, выполняемые в варианте осуществления настоящего изобретения, и сообщения, обмениваемые между хост-узлами Инициатора и Ответчика. Первый вариант осуществления настоящего изобретения описан со ссылкой на Фиг.5. Каждый из этапов S1-S9 с Фиг.5 выполняется соответствующей частью хост-узла, выполняющего этот этап, и, следовательно, Фиг.5 может также интерпретироваться как иллюстрирующая структуру хост-узлов, однако на практике физический элемент хост-узла может выполнять более одного этапа.

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

Цепочки хеширования основаны на публичной функции, которую относительно легко вычислить, но с вычислительной точки зрения сложно или невозможно инвертировать. Такие функции называют односторонними функциями. Если результат функции является фиксированной длины, то на нее ссылаются как на одностороннюю хеш-функцию. Иначе говоря, функция hash(), которая сопоставляет строки битов (либо произвольной длины, либо предопределенной длины) строкам фиксированной длины, является хеш-функцией, если она имеет следующие три свойства: (a) при заданном x легко вычислить hash(x); (b) при заданном hash(x) сложно вычислить x; и (c) сложно найти два значения x и y, при которых hash(x) = hash(y), где x ≠ y. Больше информации можно найти в следующем документе: T.A. Berson, L. Gong and T.M.A. Lomas, Secure, "Keyed, and Collisionful Hash Functions, Technical Report" SRI-CSL-94-08, SRI International, May 1994.

Цепочка хеширования относится к такой, как описана, например, в следующем документе: L. Lamport, "Password Authentication with Insecure Communication", Communications of the ACM 24.11 (November 1981), pp 770-772. Цепочка хеширования длиной N строится путем рекурсивного применения односторонней хеш-функции hash() к исходной величине s: hash ^N (s) = hash(hash(hash(...hash(s)...))) (N раз). Для цепочки хеширования, генерируемой в обратном порядке, каждый элемент H_i в цепочке хеширования генерируется из ранее сгенерированного элемента H_i+1 путем вычисления H_i = hash(H_i+1).

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

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

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

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

В этом варианте осуществления изобретения цепочка хеширования строится, используя хеш-функцию с предшествующим элементом цепочки хеширования и Меткой HIT_I Идентификации Хост-узла Инициатора в качестве ввода:

H_i = hash(HIT_I, H_i+1).

Примеры таких хеш-функций включают в себя MD5, SHA-1 и SHA-256. В настоящее время HIP использует SHA-1 для других целей, и, следовательно, это будет одним из возможных выборов для использования в первом варианте осуществления настоящего изобретения. Хеш-функция hash() известна как Инициатору, так и Ответчику.

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

Вместо этого (Фиг.5), на этапе S1 выбирается предварительно сгенерированный криптографический элемент для включения в поле Спаренной Свежести (Paired Freshness, PF) сообщения I2' аутентификации на основании информации общего состояния. В первом варианте осуществления изобретения этот криптографический элемент представляет собой следующий неиспользованный элемент в цепочке хеширования, а информация общего состояния показывает, какой элемент в цепочке хеширования был использован последним. Следовательно, PF выбирается так, чтобы содержать в себе криптографический элемент H_i, чтобы выполнялось условие
H_i-1 = hash(HIT_I, H_i), где H_i-1 представляет собой предшествующую взаимно известную величину из цепочки хеширования (информации общего состояния).

На этапе S2 сообщение I2' аутентификации, содержащее PF, а также Метку HIT_I Идентификации Хост-узла Инициатора, передается Ответчику, и оно принимается Ответчиком на этапе S3. Сообщение I2' также содержит общий ключ DH_I Диффи-Хеллмана Инициатора и общий ключ PK_I Идентификации Хост-узла. (Несмотря на то, что протокол стандартного базового обмена HIP требует, чтобы сообщение I2 несло в себе общий ключ PK_I Идентификации Хост-узла Инициатора, в других вариантах осуществления настоящего изобретения ключ может быть исключен из сообщения I2' вследствие того, что Ответчику либо известен ключ PK_I как часть общего состояния, либо Ответчик в состоянии получить его из общего сервера.)

В первом варианте осуществления изобретения сообщение I2' имеет тот же тип пакета, что и сообщение I2 в способе стандартного базового обмена HIP. Соответственно, когда на этапе S3 Ответчик принимает сообщение I2', он, как правило, ожидает найти решение головоломки в сообщении и, впоследствии, верифицировать решение головоломки. Тем не менее, в способе модифицированного базового обмена HIP первого варианта осуществления настоящего изобретения, если Ответчик не находит решения головоломки, а вместо этого находит параметр Парной Свежести, то он может определить, что используется модифицированный базовый обмен HIP, а не стандартный. Примечательно, что в случае стандартного базового обмена HIP Ответчик, как правило, не создает какого-либо состояния при формировании ответа на сообщение I1 сообщением R1, и он, следовательно, обрабатывает все сообщения I2 как будто они поступают без какой-либо недавно предшествующей связи между хост-узлами.

На этапе S3, следовательно, Ответчик сканирует принятое сообщение, выполняя поиск параметра решения головоломки. Если сообщение является сообщением I2 из стандартного протокола, то Ответчик найдет параметр Решения и продолжит обработку сообщения в соответствии со стандартным протоколом. Однако, если Инициатор использует модифицированный протокол согласно варианту осуществления настоящего изобретения, то Ответчик найдет и извлечет параметр PF Свежести Однорангового Узла. Ответчик также извлекает из заголовка HIP Метку HIT_I Идентификации Хост-узла Инициатора.

Используя HIT_I, Ответчик выполняет в локальной базе данных поиск общего состояния, связанного с HIT_I. Информацией общего состояния в этом варианте осуществления изобретения является текущее значение H_i-1 цепочки хеширования. Если такого общего состояния не удается найти, то сообщение I2' отбрасывается, и опционально Ответчик может ответить сообщением Ошибки Параметра ICMP. Если удается найти состояние, относящееся к HIT_I, то Ответчик переходит к этапу S4.

Используя криптографический элемент H_i из параметра Парной Свежести, величину H_i-1 из локального состояния и Метку HIT_I Идентификации Хост-узла Инициатора, на этапе S4 Ответчик аутентифицирует криптографический элемент путем верификации того, что H_i-1 = hash(HIT_I, H_i). Если это отношение не удовлетворяется, то сообщение I2' отбрасывается, и может быть передано опциональное сообщение Ошибки Параметра ICMP.

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

Для обеспечения устойчивости в случае, когда Инициатор передает одно или более сообщений I2', которые не достигают Ответчика, если указанная выше верификация завершается неуспешно, то Ответчик может вычислить небольшое количество величин цепочки хеширования, предшествующих H_i-1, путем многократного применения хеш-функции и, таким образом, генерации других кандидатов для установления соответствия ранее использованному локальному состоянию. То есть вместо того, чтобы требовать наличия в локальном состоянии H_i-1, Ответчик может предоставить возможность содержать вместо этого H_i-2,..., H_i-k, для некоторой малой величины k. Несмотря на то, что этот способ также работает для больших величин k, тем самым предоставляя большую устойчивость в части потери пакетов, желание защитить Ответчика от атак DoS, истощающих ЦПУ, требует установления малого предела величины k, тем самым создавая более высокий порог количества циклов ЦПУ, которые Ответчик будет использовать при верификации криптографического элемента в каком-либо одном сообщении I2'. Сверх того, если Инициатору известна нижняя граница для k, то в случае многократной передачи сообщений I2' без получения сообщения R2 Инициатор может посчитать, что Ответчик, очевидно, не принял сообщения I2' и что, следовательно, общее состояние потеряло актуальность. Как результат Инициатор может перейти обратно к использованию стандартного базового обмена HIP.

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

После положительной аутентификации на этапе S4 на этапе S5 Инициатору передается сообщение R2' подтверждения. Сообщение R2' содержит общий ключ Диффи-Хеллмана Ответчика, так что Инициатор может создать материал общего ключа. В остальном сообщение R2' может быть таким же, как и для стандартного протокола.

Сообщение R2' подтверждения принимается Инициатором на этапе S6, и на этапе S7 Инициатор верифицирует подпись, использованную Ответчиком для сообщения R2'. Для этой цели Инициатор уже будет иметь в памяти общий ключ PK_R Идентификации Хост-узла Ответчика из ранее существующей взаимосвязи. Альтернативно, вместо сведений об общем ключе PK_R Идентификации Хост-узла Ответчика, Инициатор может получить его из общей памяти. Если Инициатору известна HIT_R Ответчика, то необязательно, чтобы общие ключи Идентификации Хост-узла в памяти были защищены по целостности (но они могут быть защищены). Либо PK_R может быть передан в сообщении R2'.

После положительной верификации на этапе S7 на этапе S8 устанавливаются Защищенные Связи HIP, и на этапе S9 осуществляется защищенная связь HIP.

Хотя вышеописано, что Ответчику известна (например, имеется в памяти) последняя использованная величина цепочки хеширования (информация общего состояния), Ответчик вместо этого может получить эту информацию из общей памяти, которая является защищенной по целостности. Получение информации, относящейся к цепочке хеширования, из общей памяти по такому способу может создать опасность атаки DoS, поскольку оно требует ресурсов и санкционирует временное состояние у Ответчика, то есть Ответчик должен помнить, что он обрабатывает сообщение I2' до тех пор, пока он не получает хеш-величину или индикацию, что хеш-величина, связанная с HIT_I Инициатора, не существует. Альтернативно, если Ответчик передает сообщение I2' в общую память вместе с запросом и получает его обратно с ответом, то этой проблемы можно частично избежать.

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

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

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

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

PF = [hash(HIT_I, K_IR, счетчик), счетчик]

где K_IR - это общий секрет, "счетчик" - это значение переменной счетчика, которой дается приращение после каждого использования, HIT_I - это Метка Идентификации Хост-узла Инициатора, а hash() - это любая подходящая хеш-функция. Хеш-функция hash() принимает три ввода (HIT_I, K_IR и "счетчик"), чтобы сгенерировать криптографический элемент, имеющий значение hash(HIT_I, K_IR, счетчик), для включения в параметр PF вместе со значением счетчика, использованным для генерации криптографического элемента. Общий секрет K_IR известен только Инициатору и Ответчику или группе доверяющих друг другу Ответчиков, и он разделяется между двумя хост-узлами (или Инициатором и группой Ответчиков) в результате ранее существующей взаимосвязи.

Параметр PF передается, принимается и извлекается на этапах S2 и S3, как описано выше в связи с первым вариантом осуществления изобретения. Тем не менее, в этом варианте осуществления изобретения, когда используя HIT_I, Ответчик выполняет поиск в локальной базе данных, чтобы найти общее состояние, связанное с HIT_I, информацией общего состояния, которая извлекается из общего секрета K_R, является последнее использованное значение счетчика. Ответчик также извлекает из параметра PF значение "счетчика", чтобы восстановить из случая, когда одно или более сообщений I2' были переданы Инициатором, но не достигли Ответчика. Как и раньше, если удается найти состояние, относящееся к HIT_I, то Ответчик переходит к этапу S4. В отличие от первого варианта осуществления изобретения разность между значением счетчика, хранимым у Ответчика, и значением счетчика, используемым Инициатором, может быть значительно больше параметра k из первого варианта осуществления изобретения, поскольку параметр счетчика является прямым вводом в хеш-функцию, и он не вовлекает многократного применения хеш-функции, как в первом варианте осуществления изобретения.

На этапе S4 Ответчик верифицирует источник криптографического элемента из принятого параметра PF путем вычисления хеш-функции, используя в качестве вводов следующие элементы: HIT_I из заголовка I2', значение "счетчика" - из параметра PF и K_IR - из поиска локального состояния. До вычисления хеша Ответчик верифицирует, что значение счетчика, принятое в параметре PF, больше или равно значению, хранимому в общем состоянии. Вычисленной хеш-функцией является hash(HIT_I, K_IR, счетчик), которая эквивалентна функции, вычисленной Инициатором, чтобы сгенерировать криптографический ключ в начальной стадии. Если верификация проходит успешно, то Ответчику становится известно, что общий секрет был использован корректно и недавно, и что сообщение I2' было недавно отправлено известным и верифицированным Инициатором. Ответчик сохраняет значение счетчика в общем состоянии. Обработка далее продолжается, как описано выше в связи с первым вариантом осуществления изобретения.

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

PF=[hash(HIT_I, K_IR, текущее время), текущее время]

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

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

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

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

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

Другие подходящие альтернативы для определения того, используется ли стандартная или модифицированная версия протокола базового обмена HIP, включают в себя тип пакета HIP (используя тип, отличающийся от стандартного пакета I2), номер версии HIP, резервное поле в заголовке HIP, управляющие биты HIP (Управление), кодирование информации либо в HIT Инициатора, либо в HIT Ответчика, например, с помощью другого префикса, отличающегося от префикса, который используется в стандартном протоколе, и используя другой тип IP-протокола для передачи сообщений модифицированной версии протокола.

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

Перейдем к вопросам защищенности, относящимся к использованию модифицированного базового обмена HIP согласно настоящему изобретению. Если Ответчик рассматривает Инициатора заслуживающим доверия и компетентным, так что Инициатор никогда не посылает сообщения I2, содержащего ложную информацию, никогда не посылает сообщения I2, если он не имеет намерения инициировать связь HIP с Ответчиком, и сохраняет защищенными неиспользованные величины цепочки хеширования и/или общий секрет, то протокол будет таким же безопасным, как и стандартный базовый обмен HIP. Модификации к способу стандартного базового обмена HIP в большей степени затрагивают часть защиты базового обмена от атак DoS и в меньшей степени другие части. Остальная часть протокола в большой степени соответствует стандартному базовому обмену HIP, за исключением двух основных различий:

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

Во-вторых, общий ключ DH_R Диффи-Халлмана Ответчика, несомый в сообщении R1 стандартного базового обмена HIP, сейчас передается в сообщении R2', поскольку сообщение R1 недоступно. В результате общий ключ PK_I Идентификации Хост-узла Инициатора в сообщении I2' не может быть зашифрован посредством ключа сессии, а шифрование ключа PK_I Идентификации Хост-узла Инициатора делается опциональным в протоколе стандартного базового обмена HIP.

Рассматривая защиту от атак DoS, можно сделать следующие наблюдения:

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

В стандартном базовом обмене HIP верификация головоломки предоставляет Ответчику уверенность в том, что Инициатор находится там и что он потратил некоторое время ЦПУ, решая головоломку. В модифицированном базовом обмене HIP согласно настоящему изобретению верификация параметра Парной Свежести предоставляет Ответчику уверенность в том, что Инициатор послал сообщение I2' через некоторое время после последней связи с Ответчиком. Если используется общий секрет с временным штампом, то Ответчик получает дополнительную уверенность в том, что либо взломщику ранее удалось перевести часы Инициатора вперед, или, альтернативно, Инициатор действительно послал сообщение сравнительно недавно, то есть в пределах дискретизации временного штампа.

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

Комбинируя уверенность, предоставленную посредством модифицированного сообщения I2', с предположением, что Инициатор является честным и компетентным, как показано выше, Ответчик может рассчитывать на, по меньшей мере, равную степень защищенности, как и в случае стандартного базового обмена HIP. Оба протокола, то есть стандартный и модифицированный согласно настоящему изобретению, имеют уязвимость DoS к атакам типа "человек в середине" (man-in-the-middle). Модифицированный базовый обмен HIP согласно настоящему изобретению без временного штампа имеет ограниченную уязвимость к атакам типа повторного воспроизведения: временной штамп помогает защищаться от таких атак. В частности, если Инициатор посылает сообщения I2', которые имеют параметр PF, но не имеют временного штампа, таким образом, что взломщик может принять сообщение, а Получатель не может, то взломщик может повторно один раз воспроизвести сообщение Получателю, тем самым приводя к тому, что Получатель создает ненужную связь HIP, то есть без необходимости растрачивает ресурсы. Однако эта остаточная атака не может рассматриваться как серьезная, поскольку каждое перехваченное сообщение может быть использовано только один раз, и, следовательно, вызванная дополнительная работа на стороне Получателя естественно ограничена.

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

Также следует отметить, что если хост-узлы ранее выполняли стандартный базовый обмен HIP, то они могут удерживать результирующую связь HIP в течение достаточно длительного времени и просто использовать сообщения HIP UPDATE, чтобы создать новые SA IPsec. Принципиальным различием между использованием HIP UPDATES и способом согласно настоящему изобретению является то, что в случае сообщения UPDATE материал ключа HIP (а именно, KEYMAT) не регенерируется, тогда как в случае варианта осуществления настоящего изобретения он регенерируется.

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

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

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

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

2. Способ по п.1, в котором идентификатор представляет собой метку идентификации HIP.

3. Способ по п.2, в котором метка идентификации HIP представляет собой Метку Идентификации сетевого узла (HIT) или Локальный Идентификатор Области (LSI).

4. Способ по п.1, в котором аутентификация криптографического элемента содержит верификацию источника криптографического элемента.

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

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

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

8. Способ по п.7, в котором криптографическая функция имеет в качестве ввода, по меньшей мере, упомянутый идентификатор.

9. Способ по п.7 или 8, в котором криптографическая функция представляет собой хеш-функцию.

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

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

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

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

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

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

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

17. Способ по п.16, в котором секретная информация содержит криптографический ключ.

18. Способ по п.16, в котором секретная информация используется как ввод в криптографическую функцию.

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

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

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

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

23. Способ по п.1, в котором информация общего состояния хранится во втором сетевом узле.

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

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

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

27. Способ по п.1, в котором сообщение аутентификации содержит общий ключ Диффи-Хеллмана первого сетевого узла.

28. Способ по п.1, в котором сообщение аутентификации содержит общий ключ Идентификации сетевого узла (HI) первого сетевого узла.

29. Способ по п.1, в котором сообщение подтверждения содержит общий ключ Диффи-Хеллмана второго сетевого узла.

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

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

32. Способ по п.31, в котором общий ключ Идентификации сетевого узла второго сетевого узла известен первому сетевому узлу в результате предварительно установленной взаимосвязи или он доступен из удаленного сервера.

33. Способ по п.1, содержащий этап, на котором после приема сообщения подтверждения в первом сетевом узле создают Защищенную Связь (SA) HIP между первым и вторым сетевыми узлами.

34. Способ по п.1, в котором предварительно установленная взаимосвязь получается из того, что предварительно была выполнена процедура стандартного базового обмена HIP между первым и вторым сетевыми узлами.

35. Способ по п.1, содержащий этап, на котором определяют, является ли сообщение аутентификации сообщением 12 стандартного базового обмена HIP или нет.

36. Способ по п.35, содержащий этап, на котором устанавливают отличие сообщения аутентификации от сообщения 12 стандартного базового обмена HIP путем определения типа параметра HIP, связанного с криптографическим элементом.

37. Способ по п.35, содержащий этап, на котором устанавливают отличие сообщения аутентификации от сообщения 12 стандартного базового обмена HIP на основании одного или более из следующих параметров: тип пакета HIP; поле версии протокола HIP; бит или некоторая комбинация битов из резервного поля заголовка HIP; управление HIP в поле Управления заголовка разновидность в каком-либо одном или в обоих идентификаторах первого и второго сетевых узлов и используемый IP-протокол.

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

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

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

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

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

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

44. Машиночитаемый носитель, хранящий компьютерную программу, который при загрузке в устройство приводит к тому, что это устройство становится устройством по п.40 или 42.

45. Машиночитаемый носитель по п.43 или 44, который является средством передачи.

46. Машиночитаемый носитель по п.43 или 44, который является запоминающим средством.