СПОСОБ ЗАЩИТЫ ТРАФИКА ДАННЫХ МЕЖДУ СЕТЬЮ МОБИЛЬНОЙ СВЯЗИ И СЕТЬЮ IMS Российский патент 2008 года по МПК H04L29/06 

Изобретение относится к способу защиты трафика данных между сетью мобильной связи и сетью 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.

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

1. Способ защиты трафика данных между сетью (3) мобильной связи и сетью IMS (4), при котором

мобильный пользователь (UE) аутентифицирует себя в сети (3) мобильной связи,

мобильный пользователь (UE) аутентифицирует себя в сети IMS (4),

осуществляется проверка, согласуется ли идентификация аутентифицированного в сети IMS (4) мобильного пользователя (UE) с идентификацией пользователя (UE), аутентифицированного в сети (3) мобильной связи,

если идентификации совпадают, то мобильному пользователю (UE) посылается сообщение подтверждения из сети IMS (4),

при этом обмен данными между мобильным пользователем (UE) и сетью IMS (4) осуществляется по протоколу защиты, защищенному общим ключом, причем ключ для протокола защиты выводится из сообщения подтверждения.