Управление ключами безопасности в основанных на ims услугах широковещания и многоадресного вещания мультимедиа (mbms)

Управление ключами безопасности в основанных на ims услугах широковещания и многоадресного вещания мультимедиа (mbms)

Иллюстрации

Показать все

Реферат

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

Данная заявка испрашивает приоритет по Предварительной Заявке США № 61/165809, поданной 01 апреля 2009 г.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение в целом относится к сетям связи и в частности к системе, способу и сетевому узлу для управления совместно используемыми ключами безопасности в основанной на Подсистеме Передачи Мультимедиа по IP (Интернет Протоколу) (IMS) пользовательской услуге Услуги Широковещания/Многоадресного вещания Мультимедиа (MBMS).

УРОВЕНЬ ТЕХНИКИ

Существующие процедуры, относящиеся к настоящему изобретению, описаны в нескольких Технических Описаниях Проекта Партнерства Третьего Поколения (3GPP). Они включают в себя:

- 3GPP TS 33.220 v8.5.0 Техническое Описание Групповых Услуг и Аспектов Системы; Базовая Архитектура Аутентификации (GAA); Базовая архитектура самонастройки (Вариант 8);

- 3GPP TS 33.222 v8.0.0 Техническое Описание Групповых Услуг и Аспектов Системы; Базовая Архитектура Аутентификации (GAA); Доступ к функциональным средствам сетевого приложения с использованием Протокола Передачи Гипертекста по Протоколу Безопасности Транспортного Уровня (HTTPS) (Вариант 8);

- 3GPP TS 33.246 v8.2.0 Техническое Описание Групповых Услуг и Аспектов Системы; Безопасность 3G; Безопасность Услуги Широковещания/Многоадресного вещания Мультимедиа (MBMS) (Вариант 8); и

- 3GPP TS 26.237 v8.0.0 Техническое Описание Групповых Услуг и Аспектов Системы; Потоковой Передачи Данных с Коммутацией Пакетов (PSS) и Пользовательской Услуги, Услуги Широковещания/Многоадресного вещания Мультимедиа (MBMS), основанных на Подсистеме Передачи Мультимедиа по IP (IMS); Протоколы (Вариант 8).

Фиг.1 является высокоуровневой исходной моделью из TS 33.222, иллюстрирующей Функциональное Средство Сетевого Приложения (NAF), использующее услугу самонастройки. Сетевые объекты определены в 3GPP TS33.220, которое предписывает Базовую Архитектуру Самонастройки (GBA), в которой устройство мобильной связи, такое как Оборудование 11 Пользователя (UE) и Функциональное Средство 12 Сервера Самонастройки (BSF), выполняют дайджест-аутентификацию HTTP по протоколу Аутентификации и Согласования Ключа (AKA) по опорной точке Ub и, как результат, устанавливают совместно используемый ключ Ks. Совместно используемый ключ Ks используется позже для выведения ключей для конкретного NAF (именуемых ключи Ks_NAF) для обеспечения безопасности связи между UE и NAF 13 по опорной точке Ua. NAF извлекает ключ для конкретного NAF по опорной точке Zn.

Статья 6 3GPP TS 33.222 предписывает использование Сервера-Посредника Аутентификации (AP) в NAF 13. AP совместим с архитектурой GBA, предписанной в TS 33.220. Когда в данной архитектуре используется AP, то AP освобождает Сервер Приложений (AS) от задач обеспечения безопасности, играя роль NAF.

Фиг.2 является высокоуровневой исходной моделью из TS 33.222, иллюстрирующей окружение и опорные точки Сервера-Посредника 15 Аутентификации (AP). TS 33.222 предполагает использование безопасности Транспортного Уровня (TLS) между UE 11 и AP 15 в NAF 13. Когда запрос HTTPS предназначен серверу 16a-16n приложений (AS), находящемуся за AP, то AP завершает тоннель 17 TLS, извлекает ключ NAF (Ks_NAF) из BSF 12 и выполняет аутентификацию UE. AP является посредником для запросов HTTPS, принятых от UE, к одному или более AS. AP может добавлять подтверждение идентификационных данных абонента для использования AS, когда AP переадресует запрос от UE к AS.

Проблема процедуры, определяемой TS 33.222 для использования ключа NAF, состоит в том, что UE 11 и AS 16a-16n не используют совместно никакой ключевой материал, даже несмотря на то, что могут существовать случаи, при которых такой совместно используемый ключевой материал мог бы потребоваться. AP 15 в TS 33.222 играет роль NAF 13. Вследствие этого, ключ NAF (Ks_NAF) является конкретным для AP в соответствии с правилами выведения ключей, предписанными в TS 33.220, и не известен UE.

Фиг.3 является высокоуровневой исходной моделью из TS 26.237, иллюстрирующей действующее решение для совместного использования ключа. Данная проблема, определенная выше в отношении использования ключа NAF с AS, также применима к сетевым объектам, определенным в TS 26.237. В данном случае Функциональное Средство 21 Управления Услугой (SCF) играет роль измененного варианта NAF/AP (и вследствие этого обозначено как SCF/NAF), а Центр 22 Услуги Широковещания/Многоадресного вещания MBMS (BM-SC) играет роль AS (и вследствие этого обозначен как BM-SC/AS). Подобно AS на фиг.2 BM-SC/AS требуется совместно используемый ключ с UE 11 для того, чтобы иметь возможность отправки сообщений управления ключами MIKEY непосредственно от BM-SC/AS к UE по одноадресному или широковещательному каналу.

Должно быть отмечено, что TS 26.237 не упоминает данную аналогию с AP 15 и AS 16 TS 32.222. Настройка в TS 26.237 не в точности такая же, как в TS 33.222; например, между UE 11 и SCF 21 не обязательно используется тоннель TLS. Тем не менее аналогичные проблемы остаются.

В TS 26.237 было внесено решение, по которому SCF 21 отправляет свой собственный ключ NAF (Ks_NAF) к BM-SC 22. BM-SC использует Ks_NAF в качестве MUK (Пользовательского Ключа MBMS), который используется для защиты сообщений управления ключами MIKEY от BM-SC к UE 11. Этапы 1-6 фиг.3 выполняются в соответствии с действующими процедурами GBA, а этап 6 описывает отправку Ks_NAF и подтвержденных идентификационных данных абонента к BM-SC.

Действующее решение в TS 26.237 прекрасно работает до тех пор, пока к SCF 21 подсоединен только один BM-SC 22 (и до тех пор, пока SCF может допускать достаточное доверие по отношению к BM-SC, так что BM-SC не использует не по назначению ключ NAF для конкретного SCF). Проблема возникает, когда к SCF прикрепляются два или более BM-SC. Это происходит, так как в соответствии с действующим решением, SCF отправляет свой собственный Ks_NAF к BM-SC, и вследствие этого, SCF будет отправлять тот же самый Ks_NAF всем подсоединенным BM-SC. Давать один и тот же ключ разным узлам не является хорошим решением с точки зрения обеспечения безопасности. Это может привести к ситуации, где один и тот же ключ Ks_NAF используется между UE 11 и всеми связанными BM-SC. Это откроет угрозы, такие как взаимная подмена BM-SC по отношению к UE.

Фиг.4 является схемой передачи сообщений, иллюстрирующей сообщения, отправляемые между различными сетевыми объектами во время существующей процедуры регистрации MBMS, основанной на IMS. Фигура основана на предпосылках, что UE 11 было зарегистрировано и аутентифицировано в IMS в соответствии с 3GPP TS 33.203; UE осуществило связь с Функциональными Средствами Планирования Услуги (SSF) (не показано) и приняло список доступных услуг, как определяется 3GPP TS 26.237; UE должно запустить самонастройку GBA с BSF 12, как определено в 3GPP TS 33.220; и сетевые интерфейсы защищены при помощи Безопасности Сетевого Домена (NDS/IP), как определено в 3GPP TS 33.210.

Процедура выглядит следующим образом, с учетом того, что показана информация, соответствующая процедурам безопасности. UE 11 отправляет сообщение 31 SIP INVITE (Приглашения по Протоколу Инициации Сессии) к SCF 21 через подсистему 32 Базовой Сети передачи Мультимедиа по IP (IM CN). Сообщение INVITE (Приглашение) указывает «SCF» в Запросе-URI и сообщение включает в себя в документе XML в теле сообщения SIP идентификационные данные запрашиваемых пользовательских услуг MBMS (userServiceId), в отношении которых UE хочет зарегистрироваться. Документ XML является точно таким же, как тот, что используется для Регистрации MBMS в TS 33.246, и предписан в TS 26.346. В дополнение существует документ XML, несущий в себе Идентификатор Транзакции Самонастройки (B-TID). Документ XML, несущий в себе B-TID, определен в Приложении I 3GPP TS 26.237.

SCF 21 принимает IP адрес UE 11 и подтвержденные идентификационные данные или множество данных UE из заголовков сообщения 31 SIP INVITE. SCF выполняет проверку на основании хранящейся информации о подписке, чтобы определить, авторизовано ли UE на получение доступа к запрашиваемым пользовательским услугам MBMS. Если UE авторизовано, то процедура продолжается; если нет, процедура прекращается. Если для UE не храниться B-TID или если принятые B-TID отличаются от тех, что хранятся для UE, то SCF 21 запускает на этапах 33 и 34 процедуру использования GBA с BSF 12 по опорной точке Zn, чтобы извлечь ключи NAF, соответствующие UE, как определено в TS 33.220. SCF выводит пользовательские ключи MBMS (MUK) из ключа NAF, как определено в TS 33.246.

SCF 21 отправляет сообщение 35 HTTP POST к BM-SC 22. SCF заполняет сообщение HTTP POST в соответствии со следующим:

- версия HTTP должна быть 1.1, которая предписана в RFC 2616;

- основа Запроса-URI должна содержать весь URI управления ключом BM-SC (например, http://bmsc.home1.net:1234);

- Запрос-URI должен содержать параметр «requesttype» («тип запроса») URI, который должен быть задан как «authorized-register» («авторизован-регистрировать»), т.е. Запрос-URI принимает вид «/keymanagement?requesttype=authorized-register»;

- SCF может добавить дополнительные параметры URI в Запрос-URI;

- заголовок X-3GPP-Asserted-Identity, который включает в себя идентификационные данные UE;

- заголовок HTTP Content-Type (Тип-Содержимого) должен быть типа MIME, соответствующего полезной нагрузке, т.е. «application/mbms-authorized-register+xml»;

- полезная нагрузка HTTP должна содержать документ XML, включающий в себя: список из одного или более userServiceId Пользовательских Услуг MBMS, в отношении которых UE хочет зарегистрироваться; IP адрес UE; пользовательский ключ MBMS (MUK); и срок действия MUK. Схема XML полезной нагрузки предписана в Приложении I 3GPP TS 26.237;

- SCF может добавлять дополнительные заголовки HTTP в запрос HTTP POST.

BM-SC 22 принимает сообщение 35 HTTP POST, проверяет, что HTTP POST верное, и извлекает запрос для дальнейшей обработки. Так как сообщение HTTP POST приходит от SCF 21 с подтвержденными идентификационными данными, то BM-SC не требуется аутентифицировать UE 11, так как UE было аутентифицировано посредством IMS. В дополнение сообщение HTTP POST также указывает BM-SC, что SCF авторизовало UE для регистрации в указанных Пользовательских Услугах MBMS.

BM-SC сохраняет принятую информацию и возвращает SCF 21 сообщение 36 HTTP 200 OK. BM-SC должно заполнять сообщение HTTP 200 OK в соответствии со следующим:

- код состояния HTTP в строке состояния HTTP должен быть 200;

- заголовок HTTP Content-Type должен быть типа MIME полезной нагрузки, т.е. «application/mbms-register-response+xml»;

- полезная нагрузка HTTP должна содержать документ XML, который включает в себя список, включающий в себя один код состояния для каждой Пользовательской Услуги MBMS. Схема XML полезной нагрузки является точно такой же, как и та, что используется для Регистрации MBMS в TS 33.246, и предписана в TS 26.346.

SCF 21 принимает сообщение 36 HTTP 200 OK и включает тело XML из сообщения HTTP 200 OK в сообщение 37 SIP 200 OK, и отправляет UE 11 сообщение SIP 200 OK через подсистему 32 IM CN. BM-SC 22 теперь может начать отправку сообщений 38 MIKEY MSK (защищенных при помощи MUK), сообщений 39 MTK (защищенных при помощи MSK) и Данных 40 MBMS (защищенных при помощи MTK) к UE для указанных Пользовательских Услуг MBMS в соответствии с процедурами, указанными в TS 33.246.

Проблема с данной процедурой точно такая же, как та, что описана выше в отношении фиг.3, то есть не существует возможности предоставить для конкретного BM-SC ключи NAF, если к SCF подсоединен более чем один BM-SC. Если SCF 21 отправляет один и тот же Ks_NAF всем подсоединенным BM-SC, то тот же самый ключ Ks_NAF будет использован между UE 11 и всеми связанными BM-SC. Это откроет угрозы, такие как взаимная подмена BM-SC по отношению к UE.

В дополнение отсутствует достаточно информации в сообщении 38 MIKEY MSK, чтобы указать UE 11, какой MUK (т.е. ключ NAF) был использован для защиты сообщения MIKEY MSK. В MBMS TS 33.246 для указания этого используются NAF-Id и B-TID; но в TS 26.237, BM-SC 22 не действует как NAF, и вследствие этого, он не обладает данной информацией.

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

В одном варианте осуществления настоящего изобретения SCF/NAF 21 извлекает Ks_NAF из BSF 12, как обычно в GBA. Затем вместо отправки SCF/NAF своего собственного ключа Ks_NAF к (одной или более) BM-SC/AS, SCF/NAF делает дополнительные выведения ключа, чтобы создать для конкретного BM-SC/AS ключи Ks_AS из Ks_NAF для конкретного SCF. Например, Ks_AS=KDF(Ks_NAF, одноразовое значение), где одноразовое значение является значением, определяемым SCF/NAF, и конкретным для привязанного BM-SC/AS. SCF/NAF указывает одноразовое значение UE 11, которое затем может сделать то же самое выведение Ks_AS. SCF/NAF также указывает UE идентификационные данные BM-SC/AS так, что UE может отобразить выведенные ключи Ks_AS с правильным BM-SC/AS. В результате UE и BM-SC/AS совместно используют ключи для конкретного BM-SC/AS.

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

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

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

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

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

В конкретном примерном варианте осуществления применительно к распространению ключей в пользовательских услугах MBMS, основанных на IMS и PSS, настоящее изобретение преимущественно предоставляет более безопасную систему, в которой UE совместно использует разные (конкретные) ключи с каждым из множества BM-SC, вместо совместного использования одного и того же ключа со всеми вовлеченными BM-SC. В связанном варианте осуществления для получения ключей для конкретного AS при сценарии Сервера-Посредника Аутентификации (AP) настоящее изобретение преимущественно предоставляет способ реализации совместно используемого ключа между UE и Сервером Приложений (AS). Это позволяет осуществлять разработку новых видов приложений для сценария с AP. Изобретение предоставляет более безопасную систему, в которой UE совместно использует разные (конкретные) ключи с каждым AS, вместо совместного использования одного и того же ключа со всеми вовлеченными AS.

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

Фиг.1 является высокоуровневой исходной моделью из TS 33.222, иллюстрирующей Функциональное Средство Сетевого Приложения (NAF), использующее услугу самонастройки;

Фиг.2 является высокоуровневой исходной моделью из TS 33.222, иллюстрирующей окружение и опорные точки Сервера-Посредника Аутентификации (AP);

Фиг.3 является высокоуровневой исходной моделью из TS 26.237, иллюстрирующей действующее решение в отношении совместного использования ключей;

Фиг.4 является схемой передачи сообщений, иллюстрирующей сообщения, отправляемые между различными сетевыми объектами во время существующей процедуры регистрации MBMS, основанной на IMS;

Фиг.5A-5B являются частями схемы передачи сообщений, иллюстрирующей сообщения, отправляемые между различными сетевыми объектами во время первого варианта осуществления изобретенной процедуры регистрации MBMS, основанной на IMS, когда NAF-Id (FQDN выделенное SCF) указывается UE в описании услуги;

Фиг.6A-6B являются частями схемы передачи сообщений, иллюстрирующей сообщения, отправляемые между различными сетевыми объектами во время первого варианта осуществления изобретенной процедуры регистрации MBMS на основе IMS, когда NAF-Id (FQDN выделенное SCF) указывается для UE в сообщении SIP 200 OK;

Фиг.7 является высокоуровневой исходной моделью, иллюстрирующей вариант осуществления изобретенной системы и способа распространения ключей в пользовательских услугах MBMS, основанных на IMS и PSS;

Фиг.8 является высокоуровневой исходной моделью, иллюстрирующей вариант осуществления изобретенной системы и способа получения для конкретного AS ключей применительно к сценарию Сервера-Посредника Аутентификации (AP); и

Фиг.9 является упрощенной структурной схемой примерного варианта осуществления системы настоящего изобретения.

ПОДРОБНОЕ ОПИСАНИЕ

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

A) NAF-Id (FQDN выделенное SCF) может быть указан для UE в описании услуги. В зависимости от того, какую услугу выбирает UE, UE затем будет использовать соответствующий NAF-Id. Это аналогично действующим процедурам в MBMS TS 33.246, но в которых указывается FQDN BM-SC.

B) SCF может указывать NAF-Id (FQDN выделенное SCF) для UE в рамках процедуры SIP INVITE, так как UE нет необходимости использовать NAF-Id до того, как будет закончена процедура SIP INVITE. Данное альтернативное решение имеет преимущество, состоящее в том, что SCF может динамически выделять BM-SC пользователям, когда принимаются запросы услуги. Это может быть выгодным, например, при балансировке нагрузки.

Фиг.5A-5B являются частями схемы передачи сообщений, иллюстрирующей сообщения, отправляемые между различными сетевыми объектами во время первого варианта осуществления изобретенной процедуры регистрации MBMS, основанной на IMS, когда NAF-Id (FQDN выделенное SCF) указывается UE 11 в описании услуги (т.е. Вариант A, выше). Чертеж основан на предпосылках, что UE было зарегистрировано и аутентифицировано в IMS в соответствии с 3GPP TS 33.203; процедуры SIP защищаются посредством обеспечения безопасности IMS, как определено в 3GPP TS 33.203; UE выполняет самонастройку GBA с BSF 12, как определено в 3GPP TS 33.220; и сетевые интерфейсы защищены при помощи Безопасности Сетевого Домена (NDS/IP), как определено в 3GPP TS 33.210.

В дополнение SCF 21 создало соединения с одним или более BM-SC 22a, 22b, которые обеспечивают фактическую пользовательскую услугу MBMS для UE. В отличие от обеспечения безопасности MBMS, определенного в TS 33.246, где BM-SC выступает в роли NAF, SCF выступает в роли NAF от имени BM-SC. BSF 12 использует NAF-Id (который включает в себя FQDN для NAF и идентификатор протокола обеспечения безопасности Ua) в качестве входных данных для выведения ключа NAF. Для того чтобы получить для конкретного BM-SC ключи NAF от BSF, SCF выделяет отдельное FQDN (из пространства FQDN, которое она администрирует) для каждого BM-SC. SCF локально привязывает эти выделенные FQDN к подсоединенным BM-SC, например в таблице.

Эти выделенные отдельные FQDN необходимы по двум причинам. Во-первых, SCF 21 не может использовать один и тот же (например, свой собственный) FQDN, так как затем два BM-SC будут получать один и тот же ключ NAF, который может подвергнуть опасности обеспечение безопасности системы. Во-вторых, SCF не может использовать FQDN BM-SC, так как BSF 12 будет осуществлять проверку для определения, дано ли NAF право использовать NAF-Id, который предлагает NAF. В качестве примера SCF может выделять NAF-Id для BM-SC_1 22a и BM-SC_2 22b в соответствии со следующим:

NAF-Id_1(FQDN)<=>BM-SC1(FQDN)

NAF-Id_2(FQDN)<=>BM-SC2(FQDN)

где, например, NAF-Id_1 может быть server1.scf.operatorA.com, а BM-SC1 может быть bmsc123.operatorB.com.

Обращаясь к фиг.5A, следуя за процедурой 42 самонастройки GBA, выполняется процедура 43 получения описания услуги. UE 11 осуществляет связь с SSF 41 и получает описание 44 услуги, т.е. список доступных услуг и их параметры, такие как описание защиты услуги. Описание защиты услуги аналогично тому, что определено в TS 33.246 за исключением того, что вместо FQDN BM-SC включается FQDN, выделенный для SCF. Предполагается, что в данном случае также необходим FQDN SCF 21, чтобы UE знало, куда отправлять сообщение 47 SIP INVITE.

На этапе 45 пользователь выбирает услугу из описания услуги и выводит ключи NAF, соответствующие NAF-Id, указанному в описании услуги для выбранной услуги. В качестве альтернативы после процедуры 46 SIP INVITE может делаться выведение ключа NAF.

UE 11 отправляет SCF 21 сообщение 47 SIP INVITE в Запросе-URI, и сообщение включает в себя: документ XML в теле сообщения SIP, идентификационные данные запрашиваемых пользовательских услуг MBMS (userServiceId), в отношении которых UE хочет зарегистрироваться. Документ XML является точно таким же, как тот, что используется применительно к Регистрации MBMS в TS 33.246 и который предписан в TS 26.346. В дополнение существует документ XML, несущий в себе идентификатор транзакции самонастройки (B-TID). Документ XML, несущий в себе B-TID, определяется Приложением I 3GPP TS 26.237.

SCF 21 принимает IP адрес UE 11 и подтвержденные идентификационные данные или множество данных UE из заголовков сообщения 47 SIP INVITE. SCF выполняет проверку на основании хранящейся информации подписки, чтобы определить, авторизовано ли UE на доступ к запрашиваемым пользовательским услугам MBMS. В положительном случае процедура продолжается. В отрицательном случае процедура завершается.

Обращаясь к фиг.5B, если для UE не существует сохраненного B-TID или если принятый B-TID отличается от того, что хранится для UE, то SCF запускает процедуру 48 использования GBA с BSF 12 по опорной точке Zn для выведения ключа NAF, соответствующего UE, как определено в TS 33.220. SCF отправляет BSF сообщение 49 запроса авторизации и включает NAF-Id, который указан в описании услуги для данной услуги. На этапе 50 BSF использует NAF-Id для выведения ключа NAF и затем возвращает ключ NAF в сообщении 51 ответа авторизации. Затем SCF выводит MUK из ключа NAF, как определено в TS 33.246. Должно быть отмечено, что для данных целей требуется зарегистрировать в 3GPP TS 33.220 новый протокол обеспечения безопасности Ua.

Затем, в процедуре 52 регистрации HTTP, SCF 21 отправляет BM-SC (в проиллюстрированном случае к BM-SC_1 22a) сообщение 53 HTTP POST. SCF заполняет сообщение HTTP POST в соответствии со следующим:

- версия HTTP должна быть 1.1, которая предписана в RFC 2616;

- основа Запроса-URI должна содержать весь URI управления ключом BM-SC (например, http://bmsc.home1.net:1234);

- Запрос-URI должен содержать параметр «requesttype» URI, который должен быть задан как «authorized-register», т.е. Запрос-URI принимает вид «/keymanagement?requesttype=authorized-register»;

- SCF может добавить дополнительные параметры URI в Запрос-URI;

- заголовок X-3GPP-Asserted-Identity, который включает в себя идентификационные данные UE;

- заголовок HTTP Content-Type должен быть типа MIME, соответствующего полезной нагрузке, т.е. «application/mbms-authorized-register+xml»;

- полезная нагрузка HTTP должна содержать документ XML, включающий в себя список из одного или более userServiceId Пользовательских Услуг MBMS, в отношении которых UE хочет зарегистрироваться, IP адрес UE, пользовательский ключ MBMS (MUK) и срок действия MUK, NAF-Id и B-TID. NAF-Id и B-TID включаются, так как они далее включаются в сообщение MIKEY от BM-SC к UE для идентификации того, какой MUK (т.е. ключ NAF) был использован. Схема XML полезной нагрузки предписана в Приложении I 3GPP TS 26.237;

- SCF может добавлять дополнительные заголовки HTTP в сообщение запроса HTTP POST.

BM-SC_1 22a принимает сообщение 53 HTTP POST, проверяет, что сообщение HTTP POST верное, и извлекает запрос для дальнейшей обработки. Так как сообщение HTTP POST приходит от SCF 21 с подтвержденными идентификационными данными, то BM-SC_1 не требуется аутентифицировать UE 11, так как UE было аутентифицировано IMS. В дополнение сообщение HTTP POST также указывает BM-SC_1, что SCF авторизовало UE на регистрацию в указанных Пользовательских Услугах MBMS.

BM-SC_1 сохраняет принятую информацию и возвращает для SCF 21 сообщение 54 HTTP 200 OK. BM-SC_1 должно заполнять сообщение HTTP 200 OK в соответствии со следующим:

- код состояния HTTP в строке состояния HTTP должен быть 200;

- заголовок HTTP Content-Type должен быть типа MIME, соответствующего полезной нагрузке, т.е. «application/mbms-register-response+xml»;

- полезная нагрузка HTTP должна содержать документ XML, который включает в себя список, включающий один код состояния для каждой Пользовательской Услуги MBMS. Схема XML полезной нагрузки является точно такой же, как и та, что используется для Регистрации MBMS в TS 33.246, и предписана в TS 26.346.

SCF 21 принимает сообщение 54 HTTP 200 OK и включает тело XML из сообщения HTTP 200 OK в сообщение 55 SIP 200 OK, и отправляет UE 11 сообщение SIP 200 OK через подсистему 32 IM CN. В процедуре 56 MIKEY MSK BM-SC_1 22a теперь может начать отправку UE сообщений 57 MIKEY MSK (защищенных при помощи MUK), сообщений 58 MTK (защищенных при помощи MSK) и Данных 59 MBMS (защищенных при помощи MTK) для указанных Пользовательских Услуг MBMS в соответствии с процедурами, указанными в TS 33.246. В сообщении 57 MIKEY MSK BM-SC должно использовать NAF-Id (FQDN) и B-TID, принятые от SCF 21 в сообщение 53 HTTP POST.

Фиг.6A-6B являются частями схемы передачи сообщений, иллюстрирующей сообщения, отправляемые между различными сетевыми объектами во время первого варианта осуществления изобретенной процедуры регистрации MBMS, основанной на IMS, когда NAF-Id (FQDN выделенное SCF) указывается UE 11 в сообщении SIP 200 OK (т.е. Вариант B выше). Применяются те же предпосылки, как описанные выше для фиг.5A-5B.

Обращаясь к фиг.6A, следуя за процедурой 42 самонастройки GBA, выполняется процедура 61 получения услуги. UE 11 осуществляет связь с SSF 41 и получает описание 62 услуги, т.е. список доступных услуг и их параметры, такие как описание защиты услуги. Описание защиты услуги аналогично тому, что определено в TS 33.246 за исключением того, что вместо FQDN BM-SC включенные FQDN указывают на SCF 21. Предполагается, что в данном случае также требуется FQDN SCF 21, чтобы UE знало, куда отправлять сообщение 47 SIP INVITE. Затем пользователь выбирает услугу из описания услуги.

В процедуре 63 SIP INVITE UE 11 отправляет SCF 21 сообщение 64 SIP INVITE через подсистему 32 IM CN. Сообщение INVITE указывает SCF в Запросе-URI и сообщение включает в себя в документе XML в теле сообщения SIP идентификационные данные запрашиваемых пользовательских услуг MBMS (userServiceId), в отношении которых UE хочет зарегистрироваться. Документ XML является точно таким же, как тот, что используется для Регистрации MBMS в TS 33.246, и предписан в TS 26.346. В дополнение существует документ XML, несущий в себе идентификатор (B-TID). Документ XML, несущий в себе B-TID, определен в Приложении I 3GPP TS 26.237.

SCF 21 принимает IP адрес UE 11 и подтвержденные идентификационные данные или множество данных UE из заголовков сообщения 64 SIP INVITE. SCF выполняет проверку на основании хранящейся информации о подписке, чтобы определить, авторизовано ли UE на получение доступа к запрашиваемым пользовательским услугам MBMS. В положительном случае процедура продолжается. В отрицательном случае процедура прекращается.

Обращаясь к фиг.6B, если для UE не хранится B-TID или если принятый B-TID отличается от тех, что хранятся для UE, то SCF запускает процедуру 65 использования GBA с BSF 12 по опорной точке Zn, чтобы извлекать ключ NAF, соответствующий UE, как определено в TS 33.220. SCF отправляет сообщение 66 запроса авторизации к BSF и включает NAF-Id, который SCF выделило данной услуге. На этапе 67 BSF использует NAF-Id для выведения ключа NAF и затем возвращает ключ NAF в сообщении 68 ответа авторизации. Затем SCF выводит MUK из ключа NAF, как определено в TS 33.246. Должно быть отмечено, что для данных целей в 3GPP TS 33.220 должен быть зарегистрирован новый протокол обеспечения безопасности Ua.

Затем в процедуре 69 регистрации HTTP, SCF 21 отправляет BM-SC (в проиллюстрированном случае к BM-SC_1 22a) сообщение 70 HTTP POST. SCF заполняет сообщение HTTP POST в соответствии со следующим:

- версия HTTP должна быть 1.1, которая предписана в RFC 2616;

- основа Запроса-URI должна содержать весь URI управления ключом BM-SC (например, http://bmsc.home1.net:1234);

- Запрос-URI должен содержать параметр «requesttype» URI, который должен быть задан как «authorized-register», т.е. Запрос-URI принимает вид «/keymanagement?requesttype=authorized-register»;

- SCF может добавить дополнительные параметры URI в Запрос-URI;

- заголовок X-3GPP-Asserted-Identity, который включает в себя идентификационные данные UE;

- заголовок HTTP Content-Type должен быть типа MIME, соответствующего полезной нагрузке, т.е. «application/mbms-authorized-register+xml»;

- полезная нагрузка HTTP должна содержать документ XML, включающий в себя список из одного или более userServiceId Пользовательских Услуг MBMS, в отношении которых UE хочет зарегистрироваться, IP адрес UE, пользовательский ключ MBMS (MUK), срок действия MUK, NAF-Id и B-TID. NAF-Id и B-TID включаются, так как они далее включаются в сообщение MIKEY от BM-SC к UE для идентификации того, какой MUK (т.е. ключ NAF) был использован. Схема XML полезной нагрузки предписана в Приложении I 3GPP TS 26.237

- SCF может добавлять дополнительные заголовки HTTP в сообщение запроса HTTP POST.

BM-SC_1 22a принимает сообщение 70 HTTP POST, проверяет, что сообщение HTTP POST верное, и извлекает запрос для дальнейшей обработки. Так как сообщение HTTP POST приходит от SCF 21 с подтвержденными идентификационными данными, то BM-SC_1 не требуется аутентифиц