RU2406251C2 - Способ и устройство для установления безопасной ассоциации - Google Patents

Способ и устройство для установления безопасной ассоциации Download PDF

Info

Publication number
RU2406251C2
RU2406251C2 RU2008118495/09A RU2008118495A RU2406251C2 RU 2406251 C2 RU2406251 C2 RU 2406251C2 RU 2008118495/09 A RU2008118495/09 A RU 2008118495/09A RU 2008118495 A RU2008118495 A RU 2008118495A RU 2406251 C2 RU2406251 C2 RU 2406251C2
Authority
RU
Russia
Prior art keywords
key
client
service
service node
information
Prior art date
Application number
RU2008118495/09A
Other languages
English (en)
Other versions
RU2008118495A (ru
Inventor
Рольф БЛОМ (SE)
Рольф БЛОМ
Карл НОРМАН (SE)
Карл НОРМАН
Original Assignee
Телефонактиеболагет Лм Эрикссон (Пабл)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/248,589 external-priority patent/US20070086590A1/en
Application filed by Телефонактиеболагет Лм Эрикссон (Пабл) filed Critical Телефонактиеболагет Лм Эрикссон (Пабл)
Publication of RU2008118495A publication Critical patent/RU2008118495A/ru
Application granted granted Critical
Publication of RU2406251C2 publication Critical patent/RU2406251C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

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

Description

Область техники, к которой относится изобретение
Настоящее изобретение относится к способу и устройству для установления безопасной ассоциации между клиентским терминалом и узлом услуги для доставки услуги типа доставки и, в частности, но не обязательно, к такому способу и устройству, которые используют Архитектуру Общей Самонастройки.
Уровень техники
Для облегчения обеспечения услуг терминалам пользователя сеть мобильной связи, такая как сеть связи 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 иллюстрируют потоки сигнализации, ассоциированные с соответствующими процедурами для установления безопасной ассоциации между парой клиентов (UEA и UEB).
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
Обычная Архитектура Общей Самонастройки (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 gRAND для этого секретного значения в информацию, передаваемую в UE. Тогда обе стороны могут получать общий совместно используемый ключ, S_Key = gRAND * ключ 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, то есть UEA, использует способ, иллюстрируемый в общем фиг.6. Этот подход основан на явных доверительных отношениях между BSFA и BSFB. Сначала инициирующая сторона выполняет стандартную процедуру GBA с BSFA своей домашней сети для получения базового ключа KsA. Затем UEA использует базовый ключ для получения RAND, привязанного к другой стороне UEB, в которую UEA требуется осуществить доставку сообщения. Это может быть сделано таким же образом, как получены ключи NAF. Вторым действием, выполняемым UEA, должен быть запрос на информацию ключа для UEB. Этот запрос, содержащий идентификаторы обоих клиентов, передают в BSFA, которая направляет запрос в BSF внутри домашней сети UEB, то есть в BSFB.
BSFB возвращает в UEA через BSFA открытое значение Diffie-Hellman для UEB, а именно gключ NAF. Также она возвращает B-TID (содержащий значение RAND', используемое для формирования Ключа NAF), AUTN и требуемые дополнительные данные. Затем инициирующая сторона UEA формирует сообщение, содержащее свое открытое значение Diffie-Hellman gRAND и информацию, необходимую приемнику для получения KSB, соответствующий Ключ NAF и, следовательно, ключ сеанса
gRAND * ключ NAF. Безусловно, UEA может получить идентичный ключ сеанса.
Альтернативное решение управления ключами p2p иллюстрирует фиг.7, согласно которой требуется формирование BSFB ключа, который должен совместно использоваться одноранговыми участниками. Первым действием инициализирующей стороны UEA должен быть запрос на ключ для другой стороны UEB. Этот запрос передают в BSFA инициирующей стороны, которая направляет запрос в BSFB принимающей стороны. Инициирующая сторона включает в запрос свой идентификатор, а также идентификатор принимающей стороны, и BSFB получает ключ, который должен использоваться совместно, то есть NAF_UE_Key. Затем полученный ключ совместно с B-TID, AUTN и т.д. передают в UEA.
С использованием этой схемы принимающая сторона принимает неявную верификацию идентификатора, заявленного отправителем, так как этот идентификатор используют при получении NAF_UE_Key. Принимающая сторона может также получить явную аутентификацию, если BSFB содержит MAC на основе "NAF_Key" (Ключа NAF), охватывающего все данные, как описано выше.
Для знающих технику очевидно, что, не выходя из контекста настоящего изобретения, в варианты осуществления, описанные выше, могут быть внесены различные изменения. Например, хотя представленные выше решения относились к GBA, изобретение может быть применено в общем к тем архитектурам, где должна быть осуществлена доставка информации от поставщика услуги и где поставщик услуги и клиент не используют совместно общую секретную информацию. В другой модификации, там где несколько решений реализуют параллельно, запрос на аутентификацию, передаваемый в BSF, содержит селектор, указывающий, какое решение должно быть применено NAF/UE.

Claims (18)

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.
RU2008118495/09A 2005-10-13 2006-10-10 Способ и устройство для установления безопасной ассоциации RU2406251C2 (ru)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US11/248,589 US20070086590A1 (en) 2005-10-13 2005-10-13 Method and apparatus for establishing a security association
US11/248,589 2005-10-13
US11/305,329 2005-12-19
US11/305,329 US8122240B2 (en) 2005-10-13 2005-12-19 Method and apparatus for establishing a security association

Publications (2)

Publication Number Publication Date
RU2008118495A RU2008118495A (ru) 2009-11-20
RU2406251C2 true RU2406251C2 (ru) 2010-12-10

Family

ID=37309618

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2008118495/09A RU2406251C2 (ru) 2005-10-13 2006-10-10 Способ и устройство для установления безопасной ассоциации

Country Status (8)

Country Link
US (3) US8122240B2 (ru)
EP (2) EP2437469B1 (ru)
JP (2) JP5118048B2 (ru)
BR (1) BRPI0617286A2 (ru)
CA (1) CA2624591C (ru)
ES (1) ES2424474T3 (ru)
RU (1) RU2406251C2 (ru)
WO (2) WO2007042345A1 (ru)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013159086A1 (en) * 2012-04-20 2013-10-24 Synabee, Inc. Secure identification system and method
RU2697645C1 (ru) * 2015-08-13 2019-08-15 Хуавэй Текнолоджиз Ко., Лтд. Способ защиты сообщений и соответствующее устройство и система
RU2756304C2 (ru) * 2016-07-28 2021-09-29 Конинклейке Филипс Н.В. Идентификация сетевого узла, на который будут реплицироваться данные

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070086590A1 (en) * 2005-10-13 2007-04-19 Rolf Blom Method and apparatus for establishing a security association
WO2007085779A1 (en) * 2006-01-24 2007-08-02 British Telecommunications Public Limited Company Method and system for recursive authentication in a mobile network
EP1835688A1 (en) * 2006-03-16 2007-09-19 BRITISH TELECOMMUNICATIONS public limited company SIM based authentication
US7936878B2 (en) 2006-04-10 2011-05-03 Honeywell International Inc. Secure wireless instrumentation network system
CN101102186B (zh) * 2006-07-04 2012-01-04 华为技术有限公司 通用鉴权框架推送业务实现方法
GB0705494D0 (en) * 2007-03-22 2007-05-02 Ibm A method and system for a subscription to a symmetric key
CN101043525B (zh) * 2007-04-26 2010-08-11 北京航空航天大学 在p2p网络环境中实现文件共享的方法
WO2009004590A2 (en) * 2007-07-03 2009-01-08 Nokia Siemens Networks Oy Method, apparatus, system and computer program for key parameter provisioning
CN101378591B (zh) 2007-08-31 2010-10-27 华为技术有限公司 终端移动时安全能力协商的方法、***及装置
CN101399767B (zh) 2007-09-29 2011-04-20 华为技术有限公司 终端移动时安全能力协商的方法、***及装置
ES2589112T3 (es) * 2007-11-30 2016-11-10 Telefonaktiebolaget Lm Ericsson (Publ) Gestión de claves para comunicación segura
US8547848B2 (en) * 2008-07-09 2013-10-01 Telefonaktiebolaget L M Ericsson (Publ) Traffic control within a network architecture providing many-to-one transmission with denial-of-service protection
US8429403B2 (en) 2008-08-12 2013-04-23 Juniper Networks, Inc. Systems and methods for provisioning network devices
WO2010027589A2 (en) * 2008-08-25 2010-03-11 Motorola, Inc. Method for multi-factor assertion generation and usage
WO2010090569A1 (en) 2009-02-05 2010-08-12 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses and a method for protecting a bootstrap message in a network
EP3051857A1 (en) * 2009-03-05 2016-08-03 Interdigital Patent Holdings, Inc. Secure remote subscription management
US20120047262A1 (en) 2009-04-27 2012-02-23 Koninklijke Kpn N.V. Managing Undesired Service Requests in a Network
UA106642C2 (uk) * 2009-12-11 2014-09-25 Нокіа Корпорейшн Профіль засобу безпеки смарт-картки у сервері абонентських даних
EP2656648B1 (en) * 2010-12-21 2018-05-09 Koninklijke KPN N.V. Operator-assisted key establishment
FR2973637A1 (fr) * 2011-03-31 2012-10-05 France Telecom Mise en place d'une association de securite de type gba pour un terminal dans un reseau de telecommunications mobiles
WO2012173539A1 (en) * 2011-06-16 2012-12-20 Telefonaktiebolaget L M Ericsson (Publ) Authentication server and communication device
WO2013003535A1 (en) * 2011-06-28 2013-01-03 Interdigital Patent Holdings, Inc. Automated negotiation and selection of authentication protocols
CN102869015B (zh) 2011-07-04 2017-12-15 中兴通讯股份有限公司 一种mtc设备触发的方法和***
US8627076B2 (en) * 2011-09-30 2014-01-07 Avaya Inc. System and method for facilitating communications based on trusted relationships
GB2500720A (en) * 2012-03-30 2013-10-02 Nec Corp Providing security information to establish secure communications over a device-to-device (D2D) communication link
EP2675106A1 (en) * 2012-04-23 2013-12-18 ABB Technology AG Industrial automation and control device user access
FR2992811A1 (fr) * 2012-07-02 2014-01-03 France Telecom Mise en place d'une association de securite lors de l'attachement d'un terminal a un reseau d'acces
US9438572B2 (en) 2012-09-06 2016-09-06 Koninklijke Kpn N.V. Establishing a device-to-device communication session
EP2912866B1 (en) 2012-10-29 2019-04-17 Koninklijke KPN N.V. Intercepting device-to-device communication
EP2954646B1 (en) * 2013-02-07 2019-07-24 Nokia Technologies OY Method for enabling lawful interception by providing security information.
EP2785011A1 (en) * 2013-03-27 2014-10-01 Gemalto SA Method to establish a secure voice communication using generic bootstrapping architecture
GB2518257A (en) * 2013-09-13 2015-03-18 Vodafone Ip Licensing Ltd Methods and systems for operating a secure mobile device
US9602508B1 (en) * 2013-12-26 2017-03-21 Lookout, Inc. System and method for performing an action based upon two-party authorization
EP3114806B1 (en) 2014-03-06 2020-06-17 Telefonaktiebolaget LM Ericsson (publ) Network node, device and methods for providing an authentication module
EP3248404B1 (en) * 2015-01-19 2020-07-22 Telefonaktiebolaget L M Ericsson (publ) Method and apparatus for direct communication key establishment
JP2018507646A (ja) * 2015-02-27 2018-03-15 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 通信デバイスとネットワークデバイスとの間の通信におけるセキュリティ構成
GB201506045D0 (en) * 2015-04-09 2015-05-27 Vodafone Ip Licensing Ltd SIM security
EP3284232B1 (en) * 2015-04-13 2021-06-09 Telefonaktiebolaget LM Ericsson (publ) Wireless communications
EP3326322B1 (en) * 2015-07-17 2019-12-18 Robert Bosch GmbH Method and system for secure key generation over an insecure shared communication medium
CN106487501B (zh) * 2015-08-27 2020-12-08 华为技术有限公司 密钥分发和接收方法、密钥管理中心、第一和第二网元
CN106714152B (zh) 2015-11-13 2021-04-09 华为技术有限公司 密钥分发和接收方法、第一密钥管理中心和第一网元
EP3414927B1 (en) * 2016-02-12 2020-06-24 Telefonaktiebolaget LM Ericsson (PUBL) Securing an interface and a process for establishing a secure communication link
US10225359B2 (en) * 2016-09-22 2019-03-05 International Business Machines Corporation Push notifications from multiple tenant servers
US10728756B2 (en) * 2016-09-23 2020-07-28 Qualcomm Incorporated Access stratum security for efficient packet processing
US11538031B2 (en) 2017-03-31 2022-12-27 Vijay Madisetti Method and system for identity and access management for blockchain interoperability
CN108200085B (zh) * 2018-01-31 2019-03-08 北京深思数盾科技股份有限公司 一种数据分发、转发方法及装置
EP3726873A1 (en) * 2019-04-18 2020-10-21 Thales Dis France SA Method to authenticate a user at a service provider
CN110492988B (zh) * 2019-07-03 2020-07-21 特斯联（北京）科技有限公司 一种多路并行复用的大数据***及其处理方法
CN113570467B (zh) * 2021-06-09 2024-04-26 上海淇玥信息技术有限公司 资源特享信息推送方法、装置及电子设备

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2514593B1 (fr) * 1981-10-09 1986-12-26 Bull Sa Procede et dispositif pour authentifier la signature d'un message signe
JPS6126111A (ja) 1984-07-16 1986-02-05 Shin Meiwa Ind Co Ltd 産業用ロボツト
WO1988001120A1 (en) * 1986-07-31 1988-02-11 Kabushiki Kaisya Advance System for generating a shared cryptographic key and a communication system using the shared cryptographic key
US7389412B2 (en) 2001-08-10 2008-06-17 Interactive Technology Limited Of Hk System and method for secure network roaming
US8140845B2 (en) * 2001-09-13 2012-03-20 Alcatel Lucent Scheme for authentication and dynamic key exchange
US8117450B2 (en) * 2001-10-11 2012-02-14 Hewlett-Packard Development Company, L.P. System and method for secure data transmission
JP3989364B2 (ja) * 2002-11-28 2007-10-10 株式会社エヌ・ティ・ティ・ドコモ データ復号端末、秘密鍵提供端末、データ暗号化端末、暗号データ復号システム、及び復号鍵更新方法
KR100610317B1 (ko) 2004-01-06 2006-08-09 삼성전자주식회사 홈 네트워크를 구성하는 기기들에 대한 인증 장치 및 방법
US7769995B2 (en) * 2004-01-07 2010-08-03 Microsoft Corporation System and method for providing secure network access
US7747862B2 (en) * 2004-06-28 2010-06-29 Intel Corporation Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks
US7624269B2 (en) * 2004-07-09 2009-11-24 Voltage Security, Inc. Secure messaging system with derived keys
JP2006108903A (ja) * 2004-10-01 2006-04-20 Hiromi Fukaya 暗号化データ配布方法、暗号化装置、復号化装置、暗号化プログラム及び復号化プログラム
US8726023B2 (en) * 2005-02-03 2014-05-13 Nokia Corporation Authentication using GAA functionality for unidirectional network connections
JP2008530879A (ja) 2005-02-11 2008-08-07 ノキア コーポレイション 通信ネットワークにおいてブートストラッピング手順を提供する方法及び装置
US20070042754A1 (en) * 2005-07-29 2007-02-22 Bajikar Sundeep M Security parameter provisioning in an open platform using 3G security infrastructure
US20070086590A1 (en) * 2005-10-13 2007-04-19 Rolf Blom Method and apparatus for establishing a security association

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM (UMTS)", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. 3-SA3, №V500, *
"UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM (UMTS)", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. 3-SA3, №V660, *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013159086A1 (en) * 2012-04-20 2013-10-24 Synabee, Inc. Secure identification system and method
RU2697645C1 (ru) * 2015-08-13 2019-08-15 Хуавэй Текнолоджиз Ко., Лтд. Способ защиты сообщений и соответствующее устройство и система
RU2756304C2 (ru) * 2016-07-28 2021-09-29 Конинклейке Филипс Н.В. Идентификация сетевого узла, на который будут реплицироваться данные

Also Published As

Publication number Publication date
EP1949651A2 (en) 2008-07-30
WO2007042512A2 (en) 2007-04-19
RU2008118495A (ru) 2009-11-20
BRPI0617286A2 (pt) 2011-07-19
EP2437469B1 (en) 2013-05-22
CA2624591A1 (en) 2007-04-19
ES2424474T3 (es) 2013-10-02
US20120166802A1 (en) 2012-06-28
JP5470429B2 (ja) 2014-04-16
US20150143126A1 (en) 2015-05-21
WO2007042345A1 (en) 2007-04-19
JP2009512296A (ja) 2009-03-19
JP2013034220A (ja) 2013-02-14
WO2007042512A3 (en) 2007-07-26
JP5118048B2 (ja) 2013-01-16
US8868912B2 (en) 2014-10-21
US8122240B2 (en) 2012-02-21
EP2437469A1 (en) 2012-04-04
EP1949651B1 (en) 2012-07-04
US20070086591A1 (en) 2007-04-19
CA2624591C (en) 2015-05-19

Similar Documents

Publication Publication Date Title
RU2406251C2 (ru) Способ и устройство для установления безопасной ассоциации
US20070086590A1 (en) Method and apparatus for establishing a security association
US8144874B2 (en) Method for obtaining key for use in secure communications over a network and apparatus for providing same
US7269730B2 (en) Method and apparatus for providing peer authentication for an internet key exchange
US8683194B2 (en) Method and devices for secure communications in a telecommunications network
US20060059344A1 (en) Service authentication
US20140351595A1 (en) Key Management in a Communication Network
US20060005033A1 (en) System and method for secure communications between at least one user device and a network entity
EP1933498B1 (en) Method, system and device for negotiating about cipher key shared by ue and external equipment
US8144875B2 (en) Method and system for establishing real-time authenticated and secured communications channels in a public network
CN110808829A (zh) 一种基于密钥分配中心的ssh认证方法
Mustafa et al. An enhancement of authentication protocol and key agreement (AKA) for 3G mobile networks
CN112954679B (zh) 基于DH算法的LoRa终端安全接入方法
El-Sakka et al. Double Evolved Packet System Authentication and Key Agreement Protocol Based on Elliptic Curve for 4G (LTE) Networks
Larafa et al. Light and distributed AAA scheme for mobile ad-hoc networks
CN101719894B (zh) 一种安全发送延迟媒体的实现***及方法
Keung Design and analysis of security protocols against off-line guessing attacks