СПОСОБ И УСТРОЙСТВО ДЛЯ УСТАНОВЛЕНИЯ БЕЗОПАСНОЙ АССОЦИАЦИИ Российский патент 2010 года по МПК H04L29/08 

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

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

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

Для облегчения обеспечения услуг терминалам пользователя сеть мобильной связи, такая как сеть связи 3G, должна часто осуществлять запрос на установление защищенного канала связи или "безопасной ассоциации" между клиентскими терминалами (то есть мобильными терминалами) и узлами услуги на основе сети, которые обеспечивают услуги. Архитектура Общей Самонастройки (GBA, АОС) описана в Техническом Описании 3GPP TS 33.220 и обеспечивает механизм, посредством которого может быть аутентифицирован клиентский терминал (UE) для Функции Аутентификации (в) Сети (узла услуги), и защищенные ключи сеанса, полученные для использования между клиентским терминалом и Функцией Аутентификации Сети. Фиг.1 иллюстрирует простую модель сети для этой архитектуры. Этот механизм осуществляет самонастройку при известной процедуре Аутентификации и Соглашения относительно Ключей (AKA, АСК) [3GPP TS 33.102], что обеспечивает возможность аутентификации клиентского терминала для Функции Сервера Самонастройки (BSF, ФСС) домашней сети клиента на основе секретной информации K, которую используют совместно между USIM клиентского терминала и Домашней Системой Подписки (HSS, ДСП) домашней сети абонента. Процедура AKA дополнительно устанавливает ключи сеанса, из которых получают то, что впоследствии применяют между клиентским терминалом и Функцией Сетевого Приложения (NAF, ФСП). Когда клиентскому терминалу и NAF требуется получить ключи сеанса из BSF, NAF передает в BSF идентификатор транзакции, который содержит индекс, используемый BSF для идентификации клиентского терминала и соответствующих ключей, которые она направляет в NAF.

Согласно механизму GBA UE инициализирует процесс формирования ключа посредством передачи запроса, содержащего идентификатор пользователя, в BSF. Запрос также содержит идентификатор NAF. BSF восстанавливает вектор аутентификации из Домашней Системы Подписчика (HSS), каждый вектор аутентификации состоит из случайного числа RAND, ожидаемого ответа XRES, ключа к шифру CK, ключа целостности ИК и символа аутентификации AUTN. BSF формирует ключевой материал KS посредством соединения CK и IK, которые содержатся внутри вектора аутентификации. BSF формирует идентификатор ключа B-TID в формате NAI посредством кодирования Base-64 значения RAND и объединения кодированного значения с именем сервера BSF, то есть в виде:

base64encode(RAND)@BSF_servers_domain_name.

BSF поддерживает ассоциацию ключа KS с идентификатором транзакции B-TID и идентификатором NAF. BSF передает B-TID и AUTN в UE, USIM клиентского терминала верифицирует значение AUTN с использованием совместно используемой секретной информации K и возвращает “дайджест” ожидаемого результата XRES в BSF. USIM также формирует ключевой материал KS с использованием секретной информации K и значения RAND (восстановленного из B-TID).

После завершения этой процедуры UE осуществляет связь с NAF, принявшей B-TID. NAF и BSF аутентифицированы друг другом, и NAF передает в BSF принятый B-TID совместно со своим собственным идентификатором. BSF использует B-TID и идентификатор NAF для локализации правильного ключа KS и использует KS для формирования ключа NAF. При формировании ключа NAF также используют другую информацию, такую как идентификатор NAF. Сформированный ключ NAF возвращают в NAF. Подобным образом, UE выполнен с возможностью формирования ключа NAF с использованием ключа KS, который уже сформирован.

После того как первый раз отработал механизм GBA, последующие запросы на установление безопасной ассоциации между UE и той же или другой NAF могут использовать уже установленный ключевой материал KS, если не истекло действие этого ключа. Однако продолжает требоваться инициализация терминалом UE запроса на установление безопасной ассоциации посредством передачи своего B-TID в NAF.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

передачу запроса на формирование и инициализацию (конфигурирование) ключа услуги из первого узла в функцию формирования ключа, запрос содержит идентификаторы первого и второго узлов;

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

направление упомянутой дополнительной информации и упомянутого идентификатора первого узла из первого узла во второй узел; и

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

Очевидно, что функция формирования ключа может быть автономным узлом или может быть распределенным сервером. В случае, когда 3G-сеть применяет Архитектуру Общей Самонастройки, Функция Сервера Самонастройки и Домашний Сервер Подписки могут совместно обеспечивать функцию формирования ключа, где Функция Сервера Самонастройки осуществляет связь с узлом услуги и с Домашним Сервером Подписки. В случае сети связи 2G функцией формирования ключа может быть комбинация Функции Сервера Самонастройки и сервера AuC.

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

формирования ключевого материала KS с использованием упомянутой базовой секретной информации; и

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

Этап формирования ключа услуги в клиенте также содержит два указанных этапа.

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

Упомянутая дополнительная информация может содержать один или большее количество из (следующего):

случайного значения;

временной метки;

порядкового номера;

других идентификаторов.

В случае Архитектуры Общей Самонастройки упомянутое случайное значение является параметром RAND и переносится внутри B-TID.

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

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

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

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

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

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

Согласно второму аспекту настоящего изобретения, обеспечен узел услуги для поставки услуги (активной) доставки клиенту через защищенную линию связи, узел услуги содержит:

средство для передачи запроса на формирование и инициализацию ключа услуги в функцию формирования ключа, запрос идентифицирует клиента и узел услуги;

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

средство для направления упомянутой дополнительной информации клиенту; и

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

В случае Архитектуры Общей Самонастройки упомянутая дополнительная информация содержит B-TID, содержащий значение RAND. Упомянутое средство для направления также скомпоновано для направления клиенту идентификатора узла услуги.

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

средство памяти для хранения секретной информации, которую используют совместно с функцией формирования ключа;

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

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

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

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

средство памяти для хранения секретной информации, которую используют совместно с упомянутым клиентом;

средство для приема запроса на формирование и инициализацию ключа услуги из упомянутого узла услуги, запрос идентифицирует клиента и узел услуги; и

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

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

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

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

направление упомянутой дополнительной информации из первого узла во второй узел; и

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

Согласно шестому аспекту настоящего изобретения, обеспечен способ защиты узла от атак повторного воспроизведения, способ содержит:

формирование ключа услуги в функции сервера самонастройки;

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

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

прием упомянутого сообщения формирования ключа в упомянутом втором узле и сохранение содержащегося в нем значения предотвращения повторного воспроизведения; и

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 иллюстрирует простую модель сети для Архитектуры Общей Самонастройки.

Фиг. 2-6 иллюстрируют потоки сигнализации, ассоциированные с соответствующими процедурами для установления безопасной ассоциации между клиентом (UE) и NAF.

Фиг.7 и фиг.8 иллюстрируют потоки сигнализации, ассоциированные с соответствующими процедурами для установления безопасной ассоциации между парой клиентов (UE_A и UE_B).

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

Обычная Архитектура Общей Самонастройки (GBA) для сетей связи 3G была описана согласно фиг.1, которая иллюстрирует интерфейсы (Ua, Ub, Zn и Zh) между различными объектами. Следует иметь в виду, что описание приведено на относительно высоком уровне, и фактические реализации могут "выглядеть" отлично при использовании идентичных общих функциональных возможностей. Например, существует возможность, что при приеме BSF запроса на ключ услуги из NAF (как будет описано ниже), принимающая BSF должна выполнить этап преобразования адресов для идентификации "обслуживающей" BSF для NAF или клиента (UE), и если принимающая BSF не является обслуживающей BSF, то запрос направляют в обслуживающую BSF.

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

В предложенном здесь первом решении используют подход, при котором NAF запрашивает BSF на ключ NAF (или услуги). BSF возвращает в NAF ключ NAF совместно с идентификатором транзакции клиента (B-TID) и соответствующим значением аутентификации сети (AUTN). Как было изложено выше, B-TID содержит кодированное значение RAND (в виде префикса NAI), которое может быть использовано клиентом для получения базового ключа (KS). Теперь NAF может составить сообщение, содержащее B-TID, AUTN и дополнительные данные, содержащие идентификатор NAF, которые требуются клиенту для получения ключа NAF, и передать это сообщение клиенту. Это сообщение может быть сообщением, которое только вызывает установку SA (то есть совместное использование ключа услуги), или оно может содержать данные услуги (то есть данные полезной нагрузки), шифрованные с использованием ключа услуги. В обоих случаях значения B-TID, AUTN и другие данные, требуемые клиенту для формирования KS, передают обычным текстом, но "подписывают" Кодом Аутентификации Сообщения. Следует отметить, что ключ(и) в SA получают с использованием ключа, совместно используемого HSS и UE, и что в сообщении содержится AUTN. Следовательно, не существует возможности “мистификации” сообщения даже при том, что ключ, используемый для защиты целостности сообщения получают, из самой SA для установления которой ключ предназначен.

При приеме клиентом сообщения он восстанавливает часть RAND из B-TID (осуществляя действие, обратное кодированию) и AUTN и применяет их к USIM/ISIM для получения базового ключа Ks. Затем он использует дополнительные данные для получения ключа NAF и верифицирует принятое сообщение с использованием MAC.

Фиг.2 иллюстрирует обмены сигнализацией, ассоциированные с этой процедурой.

Для предотвращения манипулирования NAF дополнительными данными (требуемыми клиенту) BSF может подписывать эти данные с использованием производной от Ks. Это может быть существенным, например, для предотвращения продления функцией NAF срока действия ключа.

Представленное выше решение обеспечивает возможность доставки клиенту функцией NAF информации, требуемой для установления безопасной ассоциации между этими двумя сторонами. Соответственно, клиент не должен устанавливать соединение с BSF для выполнения этих задач. Это представляет решение, чрезвычайно эффективное в отношении времени. Однако это требует, чтобы NAF передавала всю информацию, относящуюся к ключу (срок действия ключа, дополнительную информацию и т.д.), в защищенном виде из BSF в UE. Тогда B-TID и другие данные могут содержать достаточно большую структуру данных. Это может быть проблематичным в случае, где объем данных, которые могут содержаться в структуре сообщения, используют между клиентом и NAF, например, где указанной структурой является СМС.

Для уменьшения объема требуемых данных, обмен которыми происходит между NAF и клиентом для установления безопасной ассоциации, вышеупомянутое решение может быть изменено посредством опускания значения AUTN из данных, передаваемых BSF в NAF. Теперь NAF составляет сообщение, содержащее B-TID и другие необходимые данные (включая идентификатор NAF), которые требуются терминалу для получения ключа NAF, и передает его клиенту. Вновь, это сообщение может быть сообщением, которое только вызывает установку безопасной ассоциации, или оно может содержать шифрованные данные полезной нагрузки.

При приеме клиентом сообщения из NAF, он соединяется с BSF, передающей в него B-TID, аутентифицирует себя и запрашивает оставшуюся информацию, необходимую для получения ключевого материала, ассоциированного с B-TID, то есть, например, AUTN. После приема этой информации он получает ключ услуги (NAF) и верифицирует целостность сообщения. Так как клиент должен соединиться с BSF, он может одновременно получить всю информацию, относящуюся к ключевому материалу, то есть дополнительную информацию, срок действия ключа и т.д, соответственно сокращая количество "административной" информации, которая должна быть передана из NAF клиенту.

Фиг.3 изображает обмен сигнализацией, ассоциированный с этой процедурой, при предположении сценария формирования Ks (то есть подобный фиг.2).

В некоторых обстоятельствах может быть нежелательным раскрытие значения RAND для NAF. Этого можно избежать при формировании B-TID с использованием ссылки на фактическое значение RAND (или реальное RAND, RANDe), так чтобы NAF наблюдала только опорное значение. Тогда реальное RAND (RANDe) должно быть передано из BSF клиенту совместно с AUTN. Эту измененную процедуру иллюстрирует фиг.4.

Основное преимущество решений, описанных согласно фиг.3 и фиг.4, состоит в том, что BSF должна иметь дополнительную возможность для управления формированием ключа в клиенте. Для получения ключа клиенту требуется AUTN. С другой стороны, клиент должен соединиться с BSF и аутентифицировать себя в отношении BSF, требующей новой версии протокола GBA по интерфейсу Ub.

Одна опасность в отношении решений фиг.3 и фиг.4 состоит в том, что атакующий может формировать группу сообщений (подразумевая, что в ней содержится допустимый B-TID) и передавать сообщения различным клиентам для запуска атаки Отказ в Обслуживании (DoS). Так как клиенты не имеют средства для аутентификации сообщений (то есть AUTN), они должны соединяться с BSF при попытке аутентифицировать принятые сообщения. Такая атака, если она не отвергнута, должна потреблять существенные ресурсы со стороны BSF. Чтобы сделать такое нападение DoS более затруднительным, должно быть предпочтительным обеспечение возможности мгновенной проверки клиентом MAC сообщения, доставку которого осуществляет NAF, для подтверждения достоверности сообщения без необходимости соединения с BSF. Для достижения этого клиент должен быть обеспечен возможностью получать ключ, который используют для осуществления MAC в отношении сообщения. Так как клиенту не передают AUTN в сообщении, доставка которого осуществляется, это получение (ключа) должно быть основано только на RAND (или полученном значении, фиг.4) в B-TID.

Решение состоит в том, чтобы использовать RAND (или полученное значение) в B-TID для получения в BSF двух ключей Ck' и Ik'. Тогда BSF с использованием указанных ключей получает ключ MAC и передает его в NAF. Предпочтительно, этот ключ целостности должен также зависеть от идентификатора NAF. Одним способом достижения указанного без необходимости передачи всей информации в UE должно быть использование при получении ключа целостности "отпечатка пальца" другой необходимой информации, необходимой для получения ключа NAF. NAF вычисляет второй (короткий) MAC по меньшей мере по части данных, которые должны быть переданы клиенту, и включает MAC в сообщение, передаваемое клиенту. В клиенте, USIM/ISIM использует алгоритмы AKA для формирования Ck' и Ik' и, следовательно, второго ключа MAC, и тогда клиент может верифицировать сообщение. В виде варианта, BSF может обеспечивать ключи Ck' и Ik' в NAF для обеспечения возможности формирования второго ключа MAC непосредственно функцией NAF. Это не останавливает повторное воспроизведение старого сообщения (хотя данная (проблема) может быть решена с использованием временных меток), но это останавливает формирование атакующими случайных сообщений.

В альтернативном решении, иллюстрированном диаграммой сигнализации фиг.5, BSF не формирует и не передает в NAF непосредственно ключ NAF в ответ на запрос NAF на ключ PUSH (активной доставки) для данного пользователя. Скорее, BSF передает открытое значение Diffie-Hellman g^{ключ NAF}, основанное на Ключе NAF (или на некотором другом значении, основанном на ассоциированной совместно используемой секретной информации Ks), и данные, относящиеся к идентификации вовлеченных сторон, для которых предназначено использование ключа. Теперь NAF может самостоятельно выбирать секретное значение RAND и добавлять соответствующее открытое значение Diffie-Hellman g^RAND для этого секретного значения в информацию, передаваемую в UE. Тогда обе стороны могут получать общий совместно используемый ключ, S_Key = g^{RAND * ключ NAF}, S_Key используют для ключа MAC. Следует отметить, что схемы Diffie-Hellman могут быть реализованы по различным типам групп. Здесь использовано стандартное представление, когда группу обозначают Zp, и используемый элемент формирования g обозначают g.

Согласно еще одному дополнительному альтернативному решению, иллюстрируемому диаграммой сигнализации фиг.6, при запросе NAF на ключ PUSH для данного пользователя, BSF скорее не содержит стандартный ключ NAF, а получает ключ, который дополнительно основан и на идентификаторе UE, и на идентификаторе NAF (в дополнение к любым дополнительным данным). Такой ключ на чертеже обозначен "NAF_UE_Key". Для защиты поставки ключа из BSF в NAF, BSF включает в сообщение в BSF (информацию) MAC, вычисленную с использованием NAF_UE_Key.

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

Согласно одному решению, инициирующий UE, то есть UE_A, использует способ, иллюстрируемый в общем фиг.6. Этот подход основан на явных доверительных отношениях между BSF_A и BSF_B. Сначала инициирующая сторона выполняет стандартную процедуру GBA с BSF_A своей домашней сети для получения базового ключа Ks_A. Затем UE_A использует базовый ключ для получения RAND, привязанного к другой стороне UE_B, в которую UE_A требуется осуществить доставку сообщения. Это может быть сделано таким же образом, как получены ключи NAF. Вторым действием, выполняемым UE_A, должен быть запрос на информацию ключа для UE_B. Этот запрос, содержащий идентификаторы обоих клиентов, передают в BSF_A, которая направляет запрос в BSF внутри домашней сети UEB, то есть в BSF_B.

BSF_B возвращает в UE_A через BSF_A открытое значение Diffie-Hellman для UE_B, а именно g^{ключ NAF}. Также она возвращает B-TID (содержащий значение RAND', используемое для формирования Ключа NAF), AUTN и требуемые дополнительные данные. Затем инициирующая сторона UE_A формирует сообщение, содержащее свое открытое значение Diffie-Hellman g^RAND и информацию, необходимую приемнику для получения KS_B, соответствующий Ключ NAF и, следовательно, ключ сеанса

g^{RAND * ключ NAF}. Безусловно, UE_A может получить идентичный ключ сеанса.

Альтернативное решение управления ключами p2p иллюстрирует фиг.7, согласно которой требуется формирование BSF_B ключа, который должен совместно использоваться одноранговыми участниками. Первым действием инициализирующей стороны UE_A должен быть запрос на ключ для другой стороны UE_B. Этот запрос передают в BSF_A инициирующей стороны, которая направляет запрос в BSF_B принимающей стороны. Инициирующая сторона включает в запрос свой идентификатор, а также идентификатор принимающей стороны, и BSF_B получает ключ, который должен использоваться совместно, то есть NAF_UE_Key. Затем полученный ключ совместно с B-TID, AUTN и т.д. передают в UE_A.

С использованием этой схемы принимающая сторона принимает неявную верификацию идентификатора, заявленного отправителем, так как этот идентификатор используют при получении NAF_UE_Key. Принимающая сторона может также получить явную аутентификацию, если BSF_B содержит MAC на основе "NAF_Key" (Ключа NAF), охватывающего все данные, как описано выше.

Для знающих технику очевидно, что, не выходя из контекста настоящего изобретения, в варианты осуществления, описанные выше, могут быть внесены различные изменения. Например, хотя представленные выше решения относились к GBA, изобретение может быть применено в общем к тем архитектурам, где должна быть осуществлена доставка информации от поставщика услуги и где поставщик услуги и клиент не используют совместно общую секретную информацию. В другой модификации, там где несколько решений реализуют параллельно, запрос на аутентификацию, передаваемый в BSF, содержит селектор, указывающий, какое решение должно быть применено NAF/UE.

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

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

2. Способ по п.1, в котором упомянутым клиентом является клиентский терминал сети связи 3G, применяющей Архитектуру Общей Самонастройки, при этом упомянутый узел услуги содержит Функцию Сетевого Приложения, а упомянутый сервер ключей содержит Функцию Серверной Самонастройки.

3. Способ по п.2, в котором упомянутый сервер ключей дополнительно содержит Домашнюю Абонентскую Систему или Домашний Регистр определения местонахождения/Центр Аутентификации, причем упомянутая базовая секретная информация известна или доступна Домашней Абонентской Системе или Домашнему Регистру определения местонахождения/Центру Аутентификации.

4. Способ по п.2 или 3, в котором упомянутый этап формирования ключа услуги на сервере ключей содержит этапы, на которых:
формируют ключевой материал KS с использованием упомянутой базовой секретной информации; и
формируют ключ услуги с использованием упомянутого ключевого материала KS, идентификатора узла услуги, и упомянутой дополнительной информации.

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

6. Способ по п.5, в котором упомянутая базовая секретная информация хранится в ISIM/USIM клиента, и упомянутый этап формирования ключевого материала KS выполняют в ISIM/USIM.

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

8. Способ по п.7, в котором, по меньшей мере, некоторые из упомянутых отличных значений клиент получает из сервера ключей.

9. Способ по п.1, в котором упомянутая дополнительная информация содержит один или более из:
идентификатора транзакции; и
значения аутентификации сети.

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

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

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

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

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

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

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

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

18. Терминал клиента по п.17, в котором упомянутое средство для формирования ключа услуги содержит USIM/ISIM.