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

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

Иллюстрации

Показать все

Реферат

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

Изобретение относится к способу и устройству Протокола Идентификации Хост-узла (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 Идентификации Хост-узла Инициат