Результат интеллектуальной деятельности: УПРАВЛЕНИЕ КЛЮЧАМИ БЕЗОПАСНОСТИ В ОСНОВАННЫХ НА 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 не требуется аутентифицировать UE 11, так как UE было аутентифицировано IMS. В дополнение сообщение HTTP POST так же указывает BM-SC_1, что SCF авторизовало UE на регистрацию в указанных Пользовательских Услугах MBMS.

BM-SC_1 сохраняет принятую информацию и возвращает SCF 21 сообщение 71 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 принимает сообщение 71 HTTP 200 OK и включает тело XML из сообщения HTTP 200 OK и использованный NAF-Id в сообщение 72 SIP 200 OK, и отправляет UE 11 сообщение SIP 200 OK через подсистему 32 IM CN. Когда UE принимает сообщение SIP 200 OK, то на этапе 73 UE использует принятый NAF-Id для выведения ключей NAF, соответствующих услуге и выводит MUK, как определено в TS 33.246.

В процедуре 74 MIKEY MSK BM-SC_1 22a теперь может начать отправку UE сообщений 75 MIKEY MSK (защищенных при помощи MUK), сообщений 76 MTK (защищенных при помощи MSK) и Данных 77 MBMS (защищенных при помощи MTK) для указанных Пользовательских Услуг MBMS в соответствии с процедурами, указанными в TS 33.246. В сообщении 75 MIKEY MSK BM-SC должно использовать NAF-Id (FQDN) и B-TID, принятые от SCF 21 в сообщение 70 HTTP POST.

Фиг.7 является высокоуровневой исходной моделью, иллюстрирующей вариант осуществления изобретенной системы и способа распространения ключей в пользовательских услугах MBMS, основанных на IMS и PSS. На этапе 1 UE 11 и BSF 12 запускают процедуры самонастройки GBA, как определено в TS 33.220. Результатом является ключ Ks и B-TID. На этапе 2 UE выводит для конкретного NAF ключевой материал (Ks_NAF), как определено в TS 33.220. На этапе 3 UE инициирует сессию Протокола Инициации Сессии (SIP) посредством отправки SCF 21 (которое выступает в роли NAF) сообщения SIP INVITE (включающего B-TID). На этапе 4 SCF запрашивает Ks_NAF из BSF, используя B-TID. На этапе 5 BSF выводит для конкретного NAF ключевой материал (Ks_NAF), как определено в TS 33.220. На этапе 6 BSF отправляет Ks_NAF к SCF.

На новом этапе 6b SCF 21 определяет, какой BM-SC должен принять запрос. Данная информация может быть доступна из запроса UE или SCF может принять локальное решение на основании его локальной политики. SCF выводит для конкретного BM-SC ключ Ks_AS из Ks_NAF и одноразового значения, используя функцию выведения ключа, такую как Ks_AS=KDF(Ks_NAF, одноразовое значение). Одноразовым значением может быть, например, идентификационные данные BM-SC, такие как: Полностью Определенное Имя Домена (FQDN), (псевдо)случайное значение выбранное SCF или некое другое значение, приемлемое в качестве одноразового значения.

На этапе 7 SCF 21 отправляет Ks_AS и идентификационные данные BM-SC (например, FQDN) в запросе HTTP к идентифицированному BM-SC 22a. Также в запросе отправляется прочая информация, предписанная в CR S4-090148 (за исключением того, что Ks_NAF заменяется на Ks_AS). Должно быть отмечено, что B-TID и FQDN, принадлежащие BM-SC 22a, отправляются BM-SC таким образом, что BM-SC может включить их в полезную нагрузку ID сообщения MIKEY к UE 11. UE будет использовать эти данные для идентификации корректного MUK, т.е. Ks_AS. Отправка FQDN от SCF к BM-SC дает возможность UE и SCF узнавать BM-SC при помощи разных FQDN. Вследствие этого, требуется гарантировать, что BM-SC отправляет UE то же самое FQDN, что BM-SC приняло от SCF.

На этапе 8 BM-SC 22a сохраняет информацию и подтверждает запрос HTTP с помощью сообщения SIP 200 OK для SCF 21. На этапе 9 SCF отправляет сообщение SIP 200 OK к UE 11. Сообщение 200 OK включает в себя одноразовое значение и идентификационные данные BM-SC. Эти два параметра могут быть одним и тем же значением, если в качестве одноразового значения используется FQDN. На этапе 9b UE выводит для конкретного BM-SC ключ Ks_AS из Ks_NAF и одноразового значения, используя функцию выведения ключа, такую как Ks_AS=KDF(Ks_NAF, одноразовое значение). UE сохраняет ключ Ks_AS с идентификационными данными BM-SC. В заключении на этапе 10 BM-SC 22a отправляет UE сообщение управления ключами MIKEY, защищенное с помощью Ks_AS в качестве MUK (см. TS 33.246). BM-SC включает FQDN BM-SC и B-TID, принятые от SCF 21, в полезную нагрузку ID сообщения MIKEY. Затем UE 11 способно расшифровать и проверить сообщение, используя Ks-AS. UE использует полезные нагрузки ID сообщения MIKEY для идентификации корректного MUK (т.е. Ks_AS).

Фиг.8 является высокоуровневой исходной моделью, иллюстрирующей второй вариант осуществления изобретенной системы и способа получения для конкретного AS ключей применительно к сценарию Сервера-Посредника Аутентификации (AP). Данный вариант осуществления предназначен в основном для сценария AP-AS, при котором несколько AS 16a и 16b могут размещаться за AP 15. Между UE 11 и AP 15 может быть установлен тоннель TSL, но тоннель не является значимым для изобретения.

На этапе 1 UE 11 и BSF 12 запускают процедуры самонастройки GBA, как определено в TS 33.220. Результатом является ключ Ks и B-TID. На этапе 2 UE выводит для конкретного NAF ключевой материал (Ks_NAF), как определено в TS 33.220. На этапе 3 UE отправляет запрос HTTP (включающий B-TID) к AP (который выступает в роли NAF). На этапе 4 AP запрашивает Ks_NAF из BSF, используя B-TID. На этапе 5 BSF выводит для конкретного NAF ключевой материал (Ks_NAF), как определено в TS 33.220. На этапе 6 BSF отправляет Ks_NAF к AP.

На новом этапе 6b, AP 15 определяет, какой AS должен принять запрос. Данная информация может быть доступна из запроса UE или AP может принять локальное решение на основании своей локальной политики. AP выводит для конкретного AP ключ Ks_AS из Ks_NAF и одноразового значения, используя функцию выведения ключа, такую как Ks_AS=KDF(Ks_NAF, одноразовое значение). Одноразовым значением могут быть, например, идентификационные данные AS такие как: FQDN, (псевдо)случайное значение, выбранное AP, или некое другое значение, приемлемое в качестве одноразового значения.

На этапе 7 AP 15 отправляет Ks_AS и идентификационные данные AS (например, FQDN) в запросе HTTP к идентифицированному AS 16a. Должно быть отмечено, что AP требуется отправлять FQDN от AP к AS, что дает возможность UE 11 и AP 15 узнавать AS при помощи разных FQDN. Вследствие этого, требуется гарантировать, что точно одинаковое FQDN отправляется от AP к AS и от AS к UE.

На этапе 8 AS 16a сохраняет информацию и подтверждает запрос HTTP с помощью сообщения SIP 200 OK для AP 15. На этапе 9 AP отправляет UE 11 сообщение SIP 200 OK. Сообщение 200 OK включает в себя одноразовое значение и идентификационные данные AS. Эти два параметра могут быть одним и тем же значением, если в качестве одноразового значения используется FQDN. На этапе 9b UE выводит для конкретного AS ключ Ks_AS из Ks_NAF и одноразового значения, используя функцию выведения ключа, такую как Ks_AS=KDF(Ks_NAF, одноразовое значение). UE сохраняет ключ Ks_AS с идентификационными данными AS. В заключении на этапе 10 AS 16a отправляет UE сообщение, защищенное с помощью Ks_AS. Затем UE 11 способно расшифровать и проверить сообщение, используя Ks-AS. UE использует идентификационные данные AS для идентификации корректного Ks_AS.

Фиг.9 является упрощенной структурной схемой примерного варианта осуществления системы настоящего изобретения. Система включает в себя UE 11, SCF 21, BSF 12 и BM-SC_1 22a. Функционирование каждой из этих единиц может управляться, например, процессором, выполняющим инструкции компьютерной программы, хранящиеся в памяти. В примерном варианте осуществления, проиллюстрированном на фиг.9, UE включает в себя процессор 81 и память 82; SCF включает в себя процессор 83 и память 84; BSF включает в себя процессор 85 и память 86; и BM-SC_1 включает в себя процессор 87 и память 88.

UE 11 также показано как включающее в себя Модуль 91 Выведения Ks_NAF. В варианте осуществления, проиллюстрированном на Фиг.6, UE принимает NAF-Id (FQDN выделенное SCF) в описание услуги от SSF 41, и выводит Ks_NAF до начала процедуры 46 SIP INVITE. В варианте осуществления, проиллюстрированном на Фиг.7, UE принимает NAF-Id в сообщение 72 SIP 200 OK и затем выводит Ks_NAF.

UE 11 отправляет SCF 21 сообщение SIP INVITE через IM CN 32. Сообщение принимается Модулем 92 Связи SIP INVITE. Модуль Связи SIP INVITE переадресует userServiceId и B-TID из сообщения INVITE в Модуль 93 Отображения Услуга-NAF-Id, который отображает userServiceId в NAF-Id_1. NAF-Id_1 и B-TID переадресовываются Модулю 94 Связи Использования GBA, который переадресует эти параметры BSF 12. Модуль 95 Связи Использования GBA в BSF принимает параметры и переадресует их Модулю 96 Выведения Ks_NAF, который выводит Ks_NAF. Затем Ks_NAF возвращается в SCF, где он переадресовывается Модулю 97 Связи Регистрации HTTP.

Модуль 97 Связи Регистрации HTTP отправляет BM-SC_1 22a сообщение HTTP POST, где оно принимается Модулем 98 Связи Регистрации HTTP. Сообщение HTTP POST включает в себя userServiceId, NAF-Id_1, IP адрес UE, B-TID, MUK (=Ks_NAF) и Срок действия MUK. BM-SC_1 получает состояние каждой Пользовательской Услуги MBMS из Модуля 99 Состояния Услуги и отправляет SCF 21 список, включающий в себя один код состояния для каждого кода Пользовательской Услуги MBMS, в сообщении HTTP 200 OK совместно с userServiceId. SCF переадресует данную информацию UE 11. Модуль 98 Связи Регистрации HTTP также отправляет информацию Модулю 101 MIKEY MSK. Информация включает в себя MSK-Id_1, NAF-Id_1, B-TID и MUK (=Ks_NAF).

Используя данную информацию, Модуль 101 MIKEY MSK имеет возможность отправить UE 11 сообщения MIKEY MSK (защищенные с помощью MUK), сообщения MTK (защищенные с помощью MSK) и Данные MBMS (защищенные с помощью MTK), причем UE 11 имеет выведенный MUK (=Ks_NAF) при помощи Модуля 91 Выведения Ks_NAF.

Таким образом, настоящее изобретение решает задачу предоставления для конкретного BM-SC ключей NAF в том случае, когда более чем один BM-SC 22 подсоединен к SCF 21. В дополнение изобретение решает задачу, связанную с недостатком информации в сообщении MIKEY для указания UE того, какой MUK (т.е. ключ NAF) использовался для защиты сообщения MIKEY MSK. SCF 21 отправляет B-TID и выбранный NAF-Id к BM-SC 22, который в дальнейшем использует их внутри сообщения MIKEY для указания UE того, какой использовался ключ NAF.

В вариантах осуществления, проиллюстрированных на Фиг.6 и 7, настоящее изобретение имеет дополнительное преимущество, заключенное в том, что не требуется дополнительного выведения ключей NAF. Дополнительное выведение ключей NAF могло бы потребовать внесение изменений в интеллектуальные карты стандарта Универсальной Карты со Встроенной Микросхемой (UICC), используемых в мобильных терминалах в сетях GSM и UMTS. Если используется управление ключами на основе UICC, то ключи NAF обрабатываются внутри UICC. Это может быть в некоторых случаях проблематично, так как в целом влияние на UICC нежелательно в стандартизации. Данные варианты осуществления настоящего изобретения позволяют избежать этой потенциальной проблемы.

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