RU2328082C2 - Способ защиты трафика данных между сетью мобильной связи и сетью ims - Google Patents

Способ защиты трафика данных между сетью мобильной связи и сетью ims Download PDF

Info

Publication number
RU2328082C2
RU2328082C2 RU2006116515/09A RU2006116515A RU2328082C2 RU 2328082 C2 RU2328082 C2 RU 2328082C2 RU 2006116515/09 A RU2006116515/09 A RU 2006116515/09A RU 2006116515 A RU2006116515 A RU 2006116515A RU 2328082 C2 RU2328082 C2 RU 2328082C2
Authority
RU
Russia
Prior art keywords
network
ims
protocol
user
ims network
Prior art date
Application number
RU2006116515/09A
Other languages
English (en)
Other versions
RU2006116515A (ru
Inventor
Дирк КРЕСЕЛЬБЕРГ (DE)
Дирк Кресельберг
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 DE10356091A external-priority patent/DE10356091A1/de
Application filed by Сименс Акциенгезелльшафт filed Critical Сименс Акциенгезелльшафт
Publication of RU2006116515A publication Critical patent/RU2006116515A/ru
Application granted granted Critical
Publication of RU2328082C2 publication Critical patent/RU2328082C2/ru

Links

Images

Classifications

    • 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
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/02—Inter-networking arrangements

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)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

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

Description

Изобретение относится к способу защиты трафика данных между сетью мобильной связи и сетью IMS, а также к соответствующей сети передачи данных.
Стандартизованная Организацией 3GPP (Проект партнерства по созданию систем третьего поколения) подсеть IMS (Мультимедийная система на основе протокола Интернет) представляет мобильному пользователю мультимедийные услуги в сети мобильной связи. Для реализации аутентифицированной регистрации мобильного пользователя в сети IMS, в уровне техники известен протокол IMS-AKA (AKA=Соглашение об аутентификации и ключах) (см. документ [1]). В сети IMS версии 5 применяется архитектура защиты, в которой материал ключей содержится в так называемом модуле ISIM (модуле идентификации мультимедийных услуг протокола IP) на чип-карте мобильного оконечного устройства пользователя, причем этот материал ключей, кроме того, сохранен в компьютерах в сети IMS. Недостатком при этом является необходимость предоставления механизма, посредством которого обеспечивается то, что в сети и в модуле ISIM должен сохраняться идентичный материал ключей.
Поэтому задачей изобретения является создание способа защиты трафика данных между сетью мобильной связи и сетью IMS, который простым способом обеспечивает возможность предоставления идентичного материала ключей для сети IMS и мобильного пользователя.
Эта задача решается в соответствии с признаками независимых пунктов формулы изобретения. Возможные другие варианты осуществления изобретения определены в зависимых пунктах формулы изобретения.
В способе защиты трафика данных, соответствующем изобретению, мобильный пользователь сначала аутентифицирует себя в сети мобильной связи. Затем мобильный пользователь аутентифицирует себя в сети IMS. Наконец, проверяется, согласуется ли идентификация аутентифицированного в сети IMS мобильного пользователя с идентификацией пользователя, идентифицированного в сети мобильной связи. В случае совпадающих идентификаций производится обмен сообщением подтверждения между мобильным пользователем и сетью IMS. Проверка идентификации мобильного пользователя, а также обмен сообщением подтверждения известны из уровня техники, и здесь можно сослаться на документ [2]. Предпочтительно, сообщение подтверждения представляет собой случайное значение. При обмене данными между мобильным пользователем и сетью IMS применяется затем протокол защиты, защищенный общим ключом, причем ключ для протокола защиты выводится из сообщения подтверждения. В основе изобретения лежит идея, состоящая в том, что применяемое при проверке идентификации сообщение подтверждения вводится в протокол защиты в качестве ключа, так что больше нет необходимости предоставлять отдельно идентичные ключи для мобильного пользователя и сети IMS.
В особенно предпочтительном варианте осуществления изобретения ключ для протокола защиты сам является сообщением подтверждения, то есть вывод ключа из сообщения подтверждения состоит в применении сообщения подтверждения в качестве ключа. Тем самым обеспечивается особенно простая реализация соответствующего изобретению способа.
В другом варианте осуществления изобретения ключ является общим секретом между сетью IMS и мобильным пользователем. Аутентификация осуществляется, таким образом, без дополнительного ввода, осуществляемого мобильным пользователем. В качестве альтернативы, ключ может представлять собой вводимый мобильным пользователем пароль.
В другом варианте осуществления соответствующего изобретению способа производится аутентификация мобильного пользователя в сети IMS в соответствии с известным из уровня техники протоколом SIP (SIP = протокол инициирования сеанса) или посредством также известного протокола HTTP (протокола передачи гипертекста). Кроме того, в качестве особенно предпочтительного протокола защиты применяется HTTP-Digest, причем этот протокол также известен из уровня техники.
Наряду с вышеописанным способом защиты данных, изобретение также относится к сети передачи данных, которая включает в себя сеть мобильной связи и сеть IMS, причем сеть передачи данных выполнена таким образом, что трафик данных между сетью мобильной связи и сетью IMS защищен в соответствии с заявленным способом. Сеть мобильной связи, которая образует часть сети передачи данных, при этом предпочтительно выполнена как сеть протокола GPRS (Общие услуги пакетной радиосвязи) и/или UMTS (Универсальная телекоммуникационная система).
Примеры выполнения изобретения описаны ниже со ссылками на чертежи, на которых представлено следующее:
Фиг. 1 - схематичное представление сети передачи данных, в которой может быть использован способ защиты данных, соответствующий изобретению;
Фиг. 2 - поток сообщений согласно протоколу IMS-AKA, известному из предшествующего уровня техники;
Фиг. 3 - схематичное представление способа, соответствующего изобретению;
Фиг. 4 - поток сообщений согласно способу, соответствующему изобретению.
На фиг. 1 представлена сеть передачи данных, в которой производится обмен данными между пользовательским оконечным устройством (UE) и множеством подсетей сети передачи данных. Сеть передачи данных содержит радиоинтерфейсы 1 и 2, причем радиоинтерфейс 1 представляет собой интерфейс UMTS, а радиоинтерфейс 2 представляет собой интерфейс GPRS (UMTS = Универсальная телекоммуникационная система; GPRS = общие услуги пакетной радиосвязи). Через радиоинтерфейсы производится зашифрованная передача.
С радиоинтерфейсами связана подсеть 3, которая, в зависимости от используемого радиоинтерфейса, может представлять собой сеть GPRS или сеть UMTS. Такая сеть включает в себя в качестве входного компьютера сервер SGSN (SGSN = обслуживающий узел поддержки GPRS), с которым соединен сервер GGSN (GGSN = шлюзовой узел поддержки GPRS), а также сервер HLR (HLR = регистр исходного местоположения). Сервер GGSN соединен с сервером RADIUS, сервером DHCP (DHCP = протокол динамического конфигурирования хоста), маршрутизатором R и с сетью Интернет. Отдельные компоненты подсети 3 представляют собой известные компоненты из сети GPRS или UMTS, так что отдельные функции компонентов здесь не описываются подробно. Следует только отметить, что в сервере HLR сохранены пользовательские данные пользователя, и при регистрации пользовательского оконечного устройства UE с SIM-картой пользователя в сети они могут вызываться, за счет чего осуществляется аутентификация пользователя в сети 3.
С подсетью 3 связана сеть IMS 4, которая через сервер HSS (HSS = домашний сервер абонентов) или Ethernet-коммутатор ES связана с подсетью 3. Сеть IMS также включает в себя, в качестве других компонентов, сервер имен доменов (DNS), сервер P-/I-/S-CSCF (CSCF=функция управления сеансом вызова) а также сервер приложений (AS). Отдельные компоненты сети IMS также известны из уровня техники, так что они здесь не описываются подробно. Сеть IMS предоставляет платные услуги для пользователя оконечного устройства (UE). В случае этих услуг речь идет, в частности, о мультимедийных услугах, которые предоставляются пользователю через сервер AS приложений. К подсети 4 подсоединена также другая подсеть 5 (не определена более подробно). Сервер HSS в сети 4 представляет собой аналог сервера HLR в сети 3, причем на сервере HSS сохранен пользовательский профиль для регистрации и аутентификации в сети 4 IMS.
Для защиты трафика данных в версиях 5 или 6 сети IMS определены спецификации 3GPP. Одна из этих спецификаций представляет собой протокол IMS-AKA. Поток сообщений этого протокола представлен на фиг. 2, причем точные обозначения сообщений здесь детально не описываются, так как они понятны специалисту в данной области техники. В этом протоколе сначала производится посылка сообщения регистрации от пользовательского оконечного устройства UE через компьютеры P-CSCF, I-CSCF, HSS на компьютер S-CSCF. Этим сообщением оконечное устройство UE сообщает сети IMS, что оно хотело бы зарегистрироваться в этой сети. Это сообщение передается по протоколу SIP и содержит SIP-идентификацию пользовательского оконечного устройства UE. Компьютер S-CSCF посылает затем так называемый AV-запрос (AV = вектор аутентификации) на компьютер HSS, причем этот AV-запрос вновь содержит SIP-идентификацию пользовательского оконечного устройства UE. Затем компьютер HSS проверяет, сохранены ли пользовательские данные для SIP-идентификации AV-запроса, и посылает соответствующий ответ на AV-запрос назад на компьютер S-CSCF. Затем осуществляется аутентификация по протоколу АКА посредством посылки сообщений аутентификации между оконечным устройством UE и сервером S-CSCF. При этой аутентификации сначала посылается так называемый запрос аутентификации (Auth-Challenge) на оконечное устройство UE, на которое следует ответ сообщением регистрации. Если аутентификация успешна, то на оконечное устройство UE посылается сообщение Auth-OK, и затем может осуществляться обмен данными. В протоколе IMS-AKA пользователь оконечного устройства UE и сеть IMS выполняют взаимную аутентификацию, и генерируются два ключа, которые по завершению аутентификации применяются для защиты последующих сообщений сигнализации в сети IMS.
Наряду с защитой чисто сообщений сигнализации IMS-SIP согласно протоколу IMS-AKA, кроме того, между мобильным пользователем оконечного устройства UE и сервером приложений в сети может производиться обмен другими сообщениями. Например, пользователь может осуществлять связь по протоколу HTTP с сервером AS приложений в форме сервера HTTP. При этом сервер AS приложений применяется для целей администрирования или для других приложений. Примерами таких других приложений являются, наряду с обменом данными по протоколу HTTP, разговоры в режиме «нажми и говори» c использованием портативной дуплексной радиостанции через сотовую систему (PoC), списки доступа на серверах данных и тому подобное. Другие приложения включают в себя списки участников приложений интерактивных диалогов, а также услуги с групповым управлением или схемы конференций.
Для обмена защищенными сообщениями между сервером AS приложений и пользовательским оконечным устройством UE могут применяться известные протоколы защиты, такие как HTTP-Digest и т.п. В случае применения этих протоколов требуется, чтобы как пользовательское оконечное устройство, так и сервер приложений располагали общим материалом ключей или паролями, которые перед передачей первого защищенного сообщения должны предоставляться обеим сторонам. Решение, направленное на осуществление обмена защищенными данными между сервером AS приложений и пользовательским оконечным устройством UE, состоит в том, что ключ для защищенной передачи данных выводится из уже существующей инфраструктуры ключей сетевого оператора (см. документ [3]). Так как описанное в документе [3] решение доступно только для стандарта 3GPP версии 6 и в ближайшее время не будет поддерживаться, то в описываемом далее варианте осуществления соответствующего изобретению способа защиты трафика данных описывается альтернативное решение с применением уже существующей инфраструктуры ключей.
Схематично представленный на фиг.3 соответствующий заявленному способу обмен данными возник в рамках стандартизации вышеупомянутой услуги PoC, которая разрабатывается компанией OMA (Open Mobile Alliance). В ходе этой стандартизации определяются приложения, основанные на IMS, которые применяются в качестве протокола защиты HTTP-Digest. Протокол HTTP-Digest может обеспечивать защиту коммуникаций, основанных как на протоколе HTTP, так и на протоколе SIP. Релевантные для PoC спецификации содержатся также в документах [4], [5] и [6]. Показанный на фиг. 3 способ, кроме того, основывается на уже известных из уровня техники способах защиты трафика данных, которые описаны, в частности, в документах [2] и [7] и были разработаны заявителем.
На фиг.3 представлены релевантные для защиты трафика данных компоненты, показанной на фиг.1 сети передачи данных. Согласно фиг.3, пользователь мобильного оконечного устройства UE сначала регистрируется в сети 3 GPRS через радиоинтерфейс 2. В рамках этой регистрации пользователь аутентифицирует себя посредством своей SIM-карты, и устанавливается защищенный PDP-контекст с сетью GPRS. Кроме того, мобильному пользователю присваивается IP-адрес. PDP-контекст представляет собой туннель для передачи данных, в котором через радиоинтерфейс передаются пакеты данных в сеть 3 GPRS.
В сети GPRS, наряду с присвоенным IP-адресом, также известна идентификация MSISDN оконечного устройства UE в сети GPRS. IP-адрес и эта идентификация MSISDN передаются через сервер Radius на сервер HSS. Из GPRS-идентификации MSISDN сервер HSS может определить соответственно соотнесенную IMS-идентификацию оконечного устройства UE и текущий присвоенный IP-адрес. Присвоенный IP-адрес и IMS-идентификация передаются затем от сервера HSS на сервер S-CSCF.
Пользовательское оконечное устройство UE также регистрируется на сервере P-CSCF сети IMS, причем эта регистрация обозначена на фиг.3 стрелкой с надписью «IMS-регистрация». При этой регистрации серверу P-CSCF становится известным действительно применяемый IP-адрес пользователя сети IMS. Сервер P-SCSF посылает этот IP-адрес на сервер S-CSCF, который перепроверяет, являются ли идентичными этот адрес и переданный от сети HSS IP-адрес и соответствуют ли они IMS-идентификации, указанной при IMS-регистрации. За счет этой перепроверки может обеспечиваться то, что IMS-пользователь не примет идентификацию другого IMS-пользователя. Обеспечивается перепроверка, что IP-адреса соотнесены с одинаковой IMS-идентификацией, если между HSS и S-CSCF производится обмен сообщением подтверждения в форме маркера. При этом маркер формируется генератором случайных чисел и представляет собой случайное значение длиной 128 битов. В принципе, для маркера возможны и другие значения, которые имеют случайные свойства.
До этого этапа описываемый способ соответствует способу, описанному в документе [7]. Однако в отличие от способа согласно документу [7] маркер не используется непосредственно для защиты данных между пользовательским оконечным устройством UE и сетью IMS. Вместо этого маркер в соответствующем изобретению способе используется в качестве общего ключа для другого протокола защиты, который используется между пользовательским оконечным устройством UE и сетью IMS. При этом в описываемой форме выполнения применяется протокол защиты HTTP-Digest. Чтобы использовать маркер с этой целью, он сначала передается через сеть GPRS и радиоинтерфейс GPRS на пользовательское оконечное устройство UE. Радиоинтерфейс GPRS применяет зашифрованную передачу, так что можно исходить из того, что осуществляется надежная передача маркера на пользовательское оконечное устройство UE. Внутри сети IMS/GPRS, то есть от сервера S-CSCF до узла, в котором в сети GPRS вводится шифрование для радиоинтерфейса, прежде всего исходят из передачи в защищенной сетевой инфраструктуре. Эта защищенность может быть реализована, например, известными механизмами защиты, такими как «брандмауэры» (аппаратно-программные средства межсетевой защиты). Если нет возможности полагаться на достаточную защиту внутри этой инфраструктуры, то могут применяться дополнительные протоколы защиты, такие как IPsec (см. документ [8]).
После этого как сети IMS, так и пользовательскому оконечному устройству UE известен маркер, и следовательно, они обладают общим секретом. Этот маркер может, следовательно, использоваться в качестве ключа для протокола HTTP-Digest, причем для этого применяется 32-символьное шестнадцатеричное кодирование в текстовом представлении для маркера. Посредством соответствующего изобретению способа протокол HTTP-Digest может, таким образом, использоваться в качестве протокола защиты, не требуя предоставления перед этим общего секрета как для сети IMS, так и для пользовательского оконечного устройства UE с применением механизмов, связанных с высокими затратами. Вместо этого с выгодой используется тот факт, что в соответствующем изобретению способе, на основе уже существующей инфраструктуры ключей GPRS, сначала формируется маркер, который может использоваться для протокола HTTP-Digest в качестве общего секрета.
На фиг.4 показан поток сообщений, посредством которого пользователь, зарегистрированный в сети GPRS согласно фиг. 3, регистрируется в сети IMS. Сначала от пользовательского оконечного устройства UE посылается сообщение регистрации через серверы P-CSCF и I-CSCF на сервер S-CSCF сети IMS. Сообщение регистрации содержит IMS-идентификацию (IMS-ID) пользователя и заголовок авторизации протокола HTTP-Digest с параметром auth-param = "IMS_GPRS_KEY_Distr", посредством которого сети указывается, что соответствующий изобретению способ должен применяться для защиты трафика данных. Однако это может быть реализовано другим способом, например, посредством неизменной конфигурации сетей или посредством других заголовков или параметров в сообщении регистрации.
Затем проверяется аутентичность сообщения на сервере S-CSCF. Это осуществляется, как пояснено выше, путем сравнения IP-адреса, определенного на сервере P-CSCF, с IP-адресом, определенным на сервере HSS. В случае совпадающей IMS-идентификации посылается так называемый AV-запрос на сервер HSS сети IMS. В завершение, на сервер S-CSCF посылается AV-ответ. Это ответное сообщение содержит маркер. Этот маркер посылается, согласно документу [7], в неавторизованном сообщении пользователю.
В левой части фиг.4 серой областью указан радиоинтерфейс между пользовательским оконечным устройством UE и сервером CSCF сети GPRS. Передача данных через радиоинтерфейс зашифровывается с использованием известных механизмов. Вследствие этого передача маркера на пользовательское оконечное устройство UE через радиоинтерфейс GPRS является защищенной. В описываемом примере выполнения маркер передается в заголовке протокола HTTP-Digest. В качестве альтернативы, маркер также может передаваться в другом заголовке или посредством другого параметра. В частности, маркер может передаваться также в отдельном сообщении.
Затем от пользовательского оконечного устройства UE через серверы P-CSCF и I-CSCF вновь передается сообщение регистрации на компьютер S-CSCF. Это сообщение регистрации защищено с помощью протокола защиты HTTP-Digest, причем в качестве общего секрета между пользовательским оконечным устройством UE и сервером S-CSCF применяется переданный перед этим маркер. Это возможно потому, что маркер за счет передачи предшествующего сообщения регистрации известен как в оконечном устройстве UE, так и на сервере S-CSCF. В заключение осуществляется аутентификация оконечного устройства UE в сети IMS, что обозначено на фиг.4 символами AU. Затем от сервера S-CSCF на оконечное устройство UE посылается подтверждение ОК. После этого может осуществляться собственно обмен данными между оконечным устройством UE и сетью IMS, причем этот обмен данными защищен с помощью протокола HTTP-Digest. На фиг.4 для примера показано сообщение приглашения (Invite), которое посылается при последующем обмене данными.
В описанной форме выполнения для IMS-сигнализации в качестве механизма защиты используется протокол HTTP-Digest. Вместо протокола HTTP-Digest для IMS-сигнализации могут, однако, использоваться и другие механизмы защиты, если такие механизмы защиты применяют динамические ключи или пароли. Другим примером подобного механизма защиты является механизм CMS (криптозащищенный синтаксис сообщения).
Соответствующий изобретению способ может применяться, в частности, для защиты передач на основе протокола HTTP к серверам приложений. При этом исходят из того, что пользователь в текущий момент зарегистрирован в сети IMS или, по меньшей мере, был зарегистрирован и располагает действительным маркером, который был принят сетью IMS. Если теперь пользователь посредством оконечного устройства UE осуществляет связь с сервером приложений, основанным на протоколе HTTP и связанным с сетью IMS, то для защиты сообщений протокола HTTP может применяться протокол HTTP-Digest, причем в качестве пароля для протокола HTTP-Digest применяется маркер. Для того чтобы HTTP-сервер мог проверить сообщение, защищенное посредством протокола HTTP-Digest, ему также требуется этот маркер. Для этого он посылается либо от сервера S-CSCF, либо от сервера HSS сети IMS на сервер приложений. Соответствующие интерфейсы, используемые для этого, известны. Тем самым как для SIP-сигнализации, так и для HTTP-сигнализации, для ответов из сети IMS или от HTTP-сервера приложений выполняется защита с помощью протокола HTTP-Digest.
Дополнительно имеется возможность для протокола HTTP-Digest поменять местами функции клиента и сервера. Обычно защищаются сообщения, которые посылаются от пользовательского оконечного устройства UE в качестве клиента. Для ответов сети, которая действует в качестве сервера, сообщения защищаются только факультативным образом. Однако в случае сигнализации посредством протокола SIP может иметь место то, что оконечное устройство UE берет на себя функцию сервера, а сеть - функцию клиента. В этом случае протокол HTTP-Digest может вводиться соответственно в обратном направлении, так что, например, оконечное устройство UE посылает неавторизованное сообщение на сервер S-CSCF в сети IMS.
Источники информации
[1] 3GPP SA3 (Security) (2002-09):«Access security for IP-based services (Release 5)", Technical specification 33.203 V5.3.0.
[2] Siemens Paper on the IMS 2.0 early-start soluti-on: "early-start-ims-paper-final. zip".
[3] http://www.3gpp.org/ftp/tsg_sa/WG3_Security/.
TSGS3_30_Povoa/Docs/ZIP/S3-030551. zip.
[4] Ericsson, Motorola, Siemens, Nokia: "Push-To-Talk over Cellular (PoC); Signaling Flows; PoC Release 1.0", v 1.1.3, 8/2003.
[5] Ericsson, Motorola, Siemens, Nokia: "Push-To-Talk over Cellular (РОС); List management and do-not-disturb; PoC Release 1.0", V 1.1.3, 8/2003.
[6] Ericsson, Motorola, Siemens, Nokia: "Push-To-Talk over Cellular (PoC); Architecture; PoC Release 1.0", V 1.1.0, 8/2003.
[7] Siemens Presentation at Eurescom 2003: early-ims-slides-final-2003-09-17 (petri).ppt.
[8] 3GPP SA3 (Security) (2002-09): "Network domain security; IP network layer security (Release 5)", Technical specification 33.210 v5.3.0.

Claims (9)

1. Способ защиты трафика данных между сетью (3) мобильной связи и сетью IMS (4), при котором
мобильный пользователь (UE) аутентифицирует себя в сети (3) мобильной связи,
мобильный пользователь (UE) аутентифицирует себя в сети IMS (4),
осуществляется проверка, согласуется ли идентификация аутентифицированного в сети IMS (4) мобильного пользователя (UE) с идентификацией пользователя (UE), аутентифицированного в сети (3) мобильной связи,
если идентификации совпадают, то мобильному пользователю (UE) посылается сообщение подтверждения из сети IMS (4),
при этом обмен данными между мобильным пользователем (UE) и сетью IMS (4) осуществляется по протоколу защиты, защищенному общим ключом, причем ключ для протокола защиты выводится из сообщения подтверждения.
2. Способ по п.1, в котором ключ является сообщением подтверждения.
3. Способ по п.1 или 2, в котором ключ является общим секретом между сетью IMS (4) и мобильным пользователем (UE).
4. Способ по п.1 или 2, в котором ключ представляет собой вводимый мобильным пользователем (UE) пароль.
5. Способ по п.1, в котором сообщение подтверждения представляет собой случайное значение.
6. Способ по п.1, в котором мобильный пользователь (UE) аутентифицирует себя в сети IMS (4) посредством протокола SIP (протокола инициирования сеанса) и/или протокола HTTP (протокола передачи гипертекста).
7. Способ по п.1, в котором в качестве протокола защиты применяется протокол HTTP-Digest.
8. Сеть передачи данных, включающая в себя сеть мобильной связи и сеть IMS, причем сеть передачи данных выполнена таким образом, что трафик данных между мобильным пользователем сети (3) мобильной связи и сетью IMS (4) защищен согласно способу по любому из предыдущих пунктов.
9. Сеть передачи данных по п.8, в которой сеть (3) мобильной связи выполнена как сеть GPRS (Общие услуги пакетной радиосвязи) и/или сеть UMTS (Универсальная телекоммуникационная система).
RU2006116515/09A 2003-10-14 2004-10-13 Способ защиты трафика данных между сетью мобильной связи и сетью ims RU2328082C2 (ru)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE10347772.1 2003-10-14
DE10347772 2003-10-14
DE10356091A DE10356091A1 (de) 2003-10-14 2003-12-01 Verfahren zur Sicherung des Datenverkehrs zwischen einem Mobilfunknetz und einem IMS-Netz
DE10356091.2 2003-12-01

Publications (2)

Publication Number Publication Date
RU2006116515A RU2006116515A (ru) 2007-11-27
RU2328082C2 true RU2328082C2 (ru) 2008-06-27

Family

ID=34466017

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2006116515/09A RU2328082C2 (ru) 2003-10-14 2004-10-13 Способ защиты трафика данных между сетью мобильной связи и сетью ims

Country Status (5)

Country Link
US (1) US7466976B2 (ru)
EP (1) EP1673921B1 (ru)
JP (1) JP4384177B2 (ru)
RU (1) RU2328082C2 (ru)
WO (1) WO2005039141A1 (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2542578C2 (ru) * 2010-01-13 2015-02-20 Хуавэй Текнолоджиз Ко., Лтд. Система и способ обеспечения защиты беспроводных передач
RU2553420C2 (ru) * 2009-07-14 2015-06-10 Телефонактиеболагет Л М Эрикссон (Пабл) Способ и устройство, предназначенные для проверки номера телефона

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100369430C (zh) * 2005-06-21 2008-02-13 中兴通讯股份有限公司 一种ip多媒体子系统接入安全的保护方法
WO2007003140A1 (fr) 2005-07-05 2007-01-11 Huawei Technologies Co., Ltd. Procede d'authentification de sous-systeme multimedia sous protocole ip
US8285983B2 (en) 2006-05-15 2012-10-09 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatuses for establishing a secure channel between a user terminal and a SIP server
DE102006046017B4 (de) * 2006-09-28 2010-01-14 Siemens Ag Verfahren zum Bereitstellen eines symmetrischen Schlüssels zum Sichern eines Schlüssel-Management-Protokolls
US8307094B2 (en) * 2007-07-20 2012-11-06 Alcatel Lucent Method for processing register request, network element, and communication system
JP5034918B2 (ja) 2007-12-11 2012-09-26 日本電気株式会社 Ｉｍｓネットワークにおけるガイダンス確認装置および方法
US20100199341A1 (en) * 2009-02-02 2010-08-05 Telefonaktiebolaget Lm Ericsson (Publ) Methods, Subscriber Server, and User Equipment for Facilitating Service Provision
US8078870B2 (en) * 2009-05-14 2011-12-13 Microsoft Corporation HTTP-based authentication
CN101729528B (zh) * 2009-05-21 2012-11-28 中兴通讯股份有限公司 Ims会议电话的媒体安全实现方法和系统
US8631090B2 (en) * 2011-08-04 2014-01-14 International Business Machines Corporation Resource-conserving technique for as-available data delivery to a mobile device
WO2013082753A1 (zh) * 2011-12-06 2013-06-13 华为技术有限公司 移动终端的防盗方法及装置
EP3095060B1 (en) * 2014-01-13 2018-11-14 Nokia Solutions and Networks Oy Security for access to the ip multimedia subsystem (ims) with web real time communication (webrtc)
KR102172468B1 (ko) * 2014-03-14 2020-10-30 삼성전자 주식회사 WebRTC서비스를 위해 단말이 브라우저를 통해 IMS망에 접속하기 위한 방법

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020007411A1 (en) * 1998-08-10 2002-01-17 Shvat Shaked Automatic network user identification
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
FI980291A (fi) * 1998-02-09 1999-08-10 Nokia Mobile Phones Ltd Liikkuva internetpääsy
JP2001224070A (ja) * 2000-02-09 2001-08-17 Fujitsu Ltd モバイル通信システム及びその方法
US6925297B2 (en) * 2000-09-19 2005-08-02 Nortel Networks, Limited Use of AAA protocols for authentication of physical devices in IP networks
JP2003006168A (ja) * 2001-06-25 2003-01-10 Ntt Docomo Inc 移動端末認証方法及び移動端末
FI114276B (fi) * 2002-01-11 2004-09-15 Nokia Corp Verkkovierailun järjestäminen
US20030159067A1 (en) * 2002-02-21 2003-08-21 Nokia Corporation Method and apparatus for granting access by a portable phone to multimedia services
US8195940B2 (en) * 2002-04-05 2012-06-05 Qualcomm Incorporated Key updates in a mobile wireless system
DE10223248A1 (de) 2002-05-22 2003-12-04 Siemens Ag Verfahren zum Registrieren eines Kommunikationsendgeräts
US7930412B2 (en) * 2003-09-30 2011-04-19 Bce Inc. System and method for secure access

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2553420C2 (ru) * 2009-07-14 2015-06-10 Телефонактиеболагет Л М Эрикссон (Пабл) Способ и устройство, предназначенные для проверки номера телефона
RU2542578C2 (ru) * 2010-01-13 2015-02-20 Хуавэй Текнолоджиз Ко., Лтд. Система и способ обеспечения защиты беспроводных передач

Also Published As

Publication number Publication date
JP4384177B2 (ja) 2009-12-16
EP1673921B1 (de) 2018-11-28
EP1673921A1 (de) 2006-06-28
WO2005039141A1 (de) 2005-04-28
US20070140493A1 (en) 2007-06-21
US7466976B2 (en) 2008-12-16
RU2006116515A (ru) 2007-11-27
JP2007515854A (ja) 2007-06-14

Similar Documents

Publication Publication Date Title
US7574735B2 (en) Method and network element for providing secure access to a packet data network
US7610619B2 (en) Method for registering a communication terminal
CN101030854B (zh) 多媒体子系统中网络实体的互认证方法及装置
AU2008212898B2 (en) Support of UICC-less calls
US9264411B2 (en) Methods, apparatuses and computer program product for user equipment authorization based on matching network access technology specific identification information
RU2328082C2 (ru) Способ защиты трафика данных между сетью мобильной связи и сетью ims
CN101322428A (zh) 用于传递密钥信息的方法和设备
US8769281B2 (en) Method and apparatus for securing communication between a mobile node and a network
KR100928247B1 (ko) 통신 네트워크들 간의 보안 통신을 제공하기 위한 방법 및시스템
US20040043756A1 (en) Method and system for authentication in IP multimedia core network system (IMS)
EP1649661B1 (en) Transparent access authentification in GPRS core networks
Garcia-Martin Input 3rd-generation partnership project (3GPP) release 5 requirements on the session initiation protocol (SIP)
GB2411086A (en) Secure communication between terminals over a local channel using encryption keys exchanged over a different network
US20050132075A1 (en) Authentication of mobile communication devices using mobile networks, SIP and Parlay
CN100518182C (zh) 保护移动无线电网和ims网之间的数据通信业务的方法
Belmekki et al. Enhances security for IMS client
EP2104307B1 (en) Secure user-specific information transmission to a personal network server
Blanchard Wireless security
Sher et al. Secure access to IP multimedia services using generic bootstrapping architecture (GBA) for 3G & beyond mobile networks
Sher et al. Development of IMS privacy & security management framework for Fokus open IMS testbed
Garcia-Martin Rfc 4083: Input 3rd-generation partnership project (3gpp) release 5 requirements on the session initiation protocol (sip)
Sher et al. Enhanced SIP security for air interface (Gm) between IMS core and client
Sher et al. Security associations management (SAM) model for IP multimedia system (IMS)
Jadoon Evaluation of UICC-based IMS authentication schemes
Page Report Highlights

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20201014