Способ и устройство для аутентификации и конфиденциальности

Изобретение относится к защите информации. Техническим результатом является повышение уровня защиты конфиденциальности и аутентификации относительно системы ОАА/ОАНЗ известного уровня техники. Результат достигается тем, что задают функцию сервера начальной загрузки (ФСНЗ), которая создает ваучер аутентификации, объявляющий для функции сетевого приложения ФСП аутентификацию. ФСНЗ генерирует ключи Ks и Ks NAF с соответствующими идентификаторами B-TID и B-TID-NAF ключей. Чтобы предотвратить отслеживание пользователя посредством сговора между несколькими объектами ФСП B-TID-NAF и ваучер могут быть уникальными для каждой ФСП. Интерфейс Ua дополнительно защищается шифрованием с использованием ключа Ks, и интерфейс Ub дополнительно защищается от атак соединением с подстановкой посредством использования подписей с ключом Ks и обеспечением обновленности. 3 н. и 20 з.п. ф-лы, 8 ил.

 

Область техники, к которой относится изобретение

Настоящее изобретение относится к способу и устройству для аутентификации пользовательских объектов в сети связи. В частности, изобретение относится к улучшенной защите в сети связи, реализующей обобщенную архитектуру аутентификации/обобщенную архитектуру начальной загрузки, ОАА/ОАНЗ.

Уровень техники

Инфраструктура аутентификации Проекта партнерства по системам 3-го поколения (ПП3П), включающая в себя центр аутентификации (ЦАУ) ПП3П, карту универсального модуля идентификации абонента (УМИА) или модуль идентификации мультимедийных услуг протокола Интернета (ПИ) (МИМУП), и протокол соглашения об аутентификации и ключе (САК) ПП3П, выполняемый между ними, представляют собой очень ценное достояние операторов ПП3П. Было признано, что эта инфраструктура может быть использована на новом уровне, предоставляя возможность функциям приложений в сети и на стороне пользователя устанавливать совместно используемые ключи. Поэтому ПП3П специфицировала «обобщенную архитектуру начальной загрузки» (ОАНЗ), предоставляющую возможность выполнять распределение совместно используемых секретных ключей оборудованию пользователя (ОП) и функции сетевого приложения (ФСП), используя основанные на САК механизмы ([1], [2]). Фиг.1 изображает простую эталонную модель согласно ссылки [2] для начальной загрузки ключей в ФСП и ОП с поддержкой от нового компонента сетевой инфраструктуры, функции сервера начальной загрузки (ФСНЗ) и домашней абонентской системы (ДАС). С ссылкой на фиг.1, блок-схема последовательности операций на фиг.2 объясняет этапы начальной загрузки известного уровня техники. На этапе 210 оборудование пользователя ОП обращается к функции сетевого приложения ФСП по интерфейсу Ua. На этапе 220 определяется, включало ли обращение идентификатор на данные аутентификации, которые уже доступны. Если это так, процесс продолжается на этапе 270. Иначе, на этапе 230, ФСП запрашивает ОП инициировать начальную загрузку, используя способ ОАНЗ для генерирования совместно используемых ключей. ОП перенаправляет запрос на ФСНЗ по интерфейсу Ub. Запрос на начальную загрузку может быть результатом перенаправления по команде от ФСП, как описано здесь, или, иначе, может выполняться до того, как ОП выполнит обращение к ФСП на этапе 210. Конфигурация ОП определяет, какой случай применить. На этапе 240 ФСНЗ запрашивает вектор аутентификации от ДАС по интерфейсу Zh. На этапе 250 ФСНЗ выполняет аутентификацию САК с ОП по интерфейсу Ub, используя вектор аутентификации. Генерируется совместно используемый ключ Ks, и ФСНЗ, кроме того, создает идентификатор B-TID транзакции, который идентифицирует сведения мандата, сгенерированные на ФСНЗ. На этапе 260 идентификатор B-TID передается на ФСП через ОП по интерфейсам Ub и Ua. На этапе 270 ФСП обращается к ФСНЗ по интерфейсу Zn, предоставляя идентификатор B-TID, посредством чего ФСНЗ отвечает соответствующими сведениями мандата. На этапе 280 ФСП отвечает на начальный запрос на этапе 210, включая результат аутентификации.

В этот момент ФСП может использовать распределенные мандаты. Эти сведения могут использоваться для дополнительной аутентификации конечного пользователя, которую ФСП может инициировать, например, процедуру http-digest, как определено в [3], используя распределенные совместно используемые секретные ключи. Мандаты также могут использоваться для других целей кроме аутентификации, например, для целостности, конфиденциальности или получения ключа.

ПП3П предлагает использование ОАНЗ для целей аутентификации конечного пользователя, определяя так называемую «обобщенную архитектуру аутентификации» ОАА, как описано в ссылке [1]. ОАА по-новому применяет процедуры ОАНЗ для установления совместно используемых секретных ключей на ОП и ФСП, так что эти мандаты могут дополнительно использоваться в качестве основы для последующих механизмов аутентификации конечного пользователя, исполняемых между ФСП и ОП.

ПП3П также исследовал использование ОАНЗ в системе подсистемы мультимедиа ПИ (ПМПИ), например, ссылка [4].

Существует две фундаментальные проблемы с ОАА/ОАНЗ:

• Она имеет слабую поддержку конфиденциальности пользователя, и возможен сговор, так как два или более независимых приложений третьих сторон могут отслеживать пользователя по интерфейсу Ua.

• Современная архитектура ОАА/ОАНЗ не обеспечивает явной поддержки для аутентификации конечного пользователя. Если приложение использует архитектуру ОАА/ОАНЗ исключительно для аутентификации, приложению ФСП необходимо реализовать дополнительные механизмы аутентификации конечного пользователя, основанные на изначально загруженном ключе. Кроме того, пользователь будет аутентифицирован, фактически, дважды: один раз посредством ФСНЗ и потом посредством ФСП.

Что касается конфиденциальности, то отмечается, что один и тот же B-TID используется для каждой ФСП. Этот факт может использоваться для построения профиля пользователя, указывающего подписанные услуги, таким образом нарушая требования конфиденциальности. Этот тип атаки на конфиденциальность известен как сговор. Будучи малой проблемой для приложений, которые предоставляются одним и тем же оператором, она становится серьезной проблемой, когда третьи стороны предоставляют приложения, или когда оператор хостирует услуги третьей стороны в своих владениях.

Далее, архитектура ОАА/ОАНЗ имеет проблему в том, что возможны атаки соединением с подстановкой, посредством чего мошеннический пользователь может запросить мандат, принадлежащий кому-то еще.

В основном, архитектура ОАА/ОАНЗ представляет собой архитектуру распределения ключей, основанную на модуле идентификации абонента (МИА). Термин «МИА» здесь подразумевается или как УМИА (3-е поколение), или МИМУП. ОАА/ОАНЗ не является обобщенной в отношении поддерживаемых механизмов аутентификации, так как она предполагает основанную на МИА аутентификацию. Кроме того, ОАА/ОАНЗ не является ориентированной на аутентификацию, так как предоставленные ключи могут использоваться или могут не использоваться для аутентификации.

Недостатком ОАА/ОАНЗ является то, что она требует приложений для реализации следующих механизмов, чтобы стать совместимой с ОАА/ОАНЗ:

- Управление ключами для безопасного хранения предоставленного ключа, отслеживания достоверности ключа, привязки ключа к заданному пользователю и приложению, обновления ключей, когда истечет достоверность.

- Протокол для выборки ключей из ФСНЗ, например, Diameter.

- Протокол аутентификации для аутентификации пользователя.

- Защищенные каналы для защиты распределения ключей.

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

Многие приложения даже не могут реализовать механизмы для аутентификации пользователя из-за нагрузки управления мандатами пользователя, такими как пароли. Фактически, проблема управления паролями (хранение, защита, обновление, потеря, недостоверность, кража) определялась как препятствие для развертывания приложения.

Другие недостатки архитектуры ОАА/ОАНЗ известного уровня техники относятся к оператору:

- Делегирование авторизации услуги приложению, тогда как может быть предпочтительной централизованная авторизация.

- Нет поддержки сбора статистики из-за отсутствия управления использованием приложения.

- Нет автоматического механизма объявления недействительной подписки на услугу.

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

Сущность изобретения

Настоящее изобретение устраняет недостатки устройств известного уровня техники.

В основном, целью настоящего изобретения является использование по-новому существующей инфраструктуры ОАА/ОАНЗ, чтобы улучшить защиту конфиденциальности и поддержку аутентификации, сводя к минимуму изменения в существующей процедуре ОАА/ОАНЗ.

Задачей изобретения является обеспечение ваучера аутентификации, объявляющего авторизацию пользователя в сети связи, которая реализует архитектуру ОАА/ОАНЗ.

Другой задачей является обеспечение идентификатора B_TID_NAF ключа, связанного с пользовательским объектом ОП, который является уникальным для каждого узла сетевого приложения ФСП.

Другой задачей является предотвращение атак соединением с подстановкой по интерфейсу Ua и предоставление возможности ФСНЗ проверять отправителя идентификатора B_TID_NAF начальной загрузки.

Еще другой задачей является организация связи ФСП с ФСНЗ для проверки, что требования ФСП на аутентификацию пользователя выполняются без выявления в упомянутой связи таких данных, которые позволяют отслеживать пользовательский объект ОП.

Другой задачей изобретения является групповое генерирование ключей Ks_NAF и соответствующих идентификаторов B_TID_NAF, связанных с множеством функций ФСП сетевого приложения.

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

Специфической задачей является обеспечение способа и системы для улучшенной защиты конфиденциальности и поддержки аутентификации в сети связи, реализующей архитектуру ОАА/ОАНЗ.

Специфической задачей также является обеспечение сетевого узла ФСНЗ для поддержки улучшенной защиты конфиденциальности и аутентификации.

Эти и другие задачи достигаются способом и устройством согласно прилагаемой формуле изобретения.

Вкратце, изобретение включает в себя функцию сервера начальной загрузки (ФСНЗ), которая создает, по запросу пользователя, ваучер аутентификации, объявляющий, что пользователь был аутентифицирован посредством использования любого способа для аутентификации. Следуя стандартной процедуре, ссылка [2], ФСНЗ генерирует ключи Ks и Ks_NAF, причем последний для использования при связи между пользователем и функцией сетевого приложения ФСП. Ключ Ks_NAF идентифицируется по интерфейсу Ua, согласно изобретению, посредством идентификатора B_TID_NAF, который является уникальным для каждой ФСП, в противоположность стандартной процедуре, при которой один и тот же идентификатор B_TID используется для любой ФСП. Пользователь, обращающийся к функции сетевого приложения ФСП, предоставляет идентификатор B_TID_NAF, позволяющий ФСП получать из идентификатора адрес его домашней ФСНЗ и запрашивать ваучер аутентификации у ФСНЗ. В ответ на идентификатор B_TID_NAF, ФСНЗ может идентифицировать ваучер аутентификации на установление статуса аутентификации ОП. Использование уникального идентификатора B_TID_NAF предотвращает создание профиля пользователя и повышает конфиденциальность.

Дополнительные необязательные повышения конфиденциальности, согласно изобретению, достигаются, например, подписанием идентификатора B_TID_NAF (или альтернативно B_TID), используя ключ Ks, известный ФСНЗ и пользователю ОП. Это предотвращает атаки соединением с подстановкой на интерфейсе между пользователем ОП и функцией сетевого приложения ФСП. Шифрование передачи мандата между пользователем ОП и ФСНЗ по интерфейсу Ub посредством использования ключа Ks представляет собой другой пример того, как дополнительно повысить защиту системы.

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

В другом примерном аспекте изобретения, ФСНЗ посылает ваучер аутентификации пользователю ОП по интерфейсу Ub. Пользователь представляет ваучер аутентификации ФСП, к которой обращается. Согласно изобретению, ФСП полагается на ФСНЗ для проверки достоверности ваучера аутентификации перед принятием дополнительной передачи от пользователя. Идентификация B_TID_NAF также может использоваться для извлечения ключа Ks_NAF с ФСНЗ, если ФСП, дополнительно, например, требует установление сеансовых ключей с ОП.

Изобретение, в основном, применимо к существующей инфраструктуре ОАА/ОАНЗ для улучшения защиты конфиденциальности и аутентификации. Так как ОАНЗ теперь обсуждается для использования в системах ПМПИ, предсказывается применение изобретения в таких системах.

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

Другим преимуществом изобретения является обеспечение улучшенной защиты конфиденциальности для текущей инфраструктуры ОАА/ОАНЗ, включая защиту от сговора объектов ФСП и атак соединением с подстановкой.

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

Краткое описание чертежей

Изобретение, вместе с его дополнительными задачами и преимуществами, легче понять путем ссылки на следующее описание, рассматриваемое вместе с прилагаемыми чертежами, на которых:

фиг.1 изображает простую сетевую модель объектов, включенных в принцип начальной загрузки, согласно известному уровню техники;

фиг.2 изображает блок-схему последовательности операций процедуры начальной загрузки согласно известному уровню техники;

фиг.3 иллюстрирует блок-схему имеющих отношение частей примерного сервера начальной загрузки согласно варианту осуществления изобретения;

фиг.4 изображает блок-схему последовательности операций процедуры начальной загрузки согласно варианту осуществления изобретения;

фиг.5 представляет собой блок-схему последовательности операций, которая изображает пользовательский объект, обращающийся к функции сетевого приложения;

фиг.6 представляет собой другой вариант осуществления, который изображает пользовательский объект, обращающийся к функции сетевого приложения;

фиг.7 изображает еще другой вариант осуществления, в котором пользовательский объект обращается к функции сетевого приложения;

фиг.8 иллюстрирует вариант осуществления, в котором ваучер аутентификации выполнен уникальным для каждой функции сетевого приложения.

Подробное описание примерных предпочтительных вариантов осуществления

В первом примерном аспекте изобретения вводится дополнительный идентификатор начальной загрузки к B_TID, в настоящее время определенный в спецификациях ОАА/ОАНЗ. B_TID и ключ Ks генерируются по стандарту ОАА. Однако, согласно изобретению, B_TID используется только между ОП и ФСНЗ, т.е. по интерфейсу Ub, тогда как дополнительный идентификатор B_TID_NAF начальной загрузки обычно используется между ОП и ФСП по интерфейсу Ua. B_TID_NAF отличается от B_TID и является характерным для каждой ФСП.

Согласно стандарту ОАА/ОАНЗ, ОП нет необходимости контактировать с ФСНЗ каждый раз, когда происходит обращение к новой ФСП, так как B_TID достаточен для определения расположения ФСП и идентификации мандата пользователя. Однако, как объяснено выше, такой подход компрометирует конфиденциальность по объектам ФСП. Поэтому, согласно примерному предпочтительному варианту осуществления изобретения, вводится дополнительная сигнализация с ФСНЗ для каждой новой ФСП. Однако объем сигнализации может быть уменьшен посредством групповой процедуры, которая дополнительно описана ниже.

ФСНЗ сохраняет связи между идентификацией ОП, B_TID, Ks и набором идентификаторов B_TID_NAF и связанными с ними ключами Ks_NAF, генерируемыми для соответствующего набора объектов ФСП.

Использование уникального B_TID_NAF для каждой ФСП предотвращает отслеживание пользователя по интерфейсу Ua.

Всякий раз, когда пользователь хочет обратиться к ФСП приложения, которая требует только идентификации/аутентификации пользователя, ФСП будет направляться ФСНЗ, которая тогда действует в качестве центра/органа аутентификации.

Согласно примерному предпочтительному варианту осуществления изобретения, ФСНЗ генерирует ваучер аутентификации, удостоверяющий, что пользователь был аутентифицирован. Ваучер аутентификации идентифицируется посредством B_TID по интерфейсу Ub. По интерфейсу Ua ваучер аутентификации идентифицируется посредством B_TID_NAF. ФСП может обращаться к ваучеру предоставлением идентификатора B_TID_NAF по интерфейсу Zn.

Фиг.3 изображает позицией 300 примерную блок-схему функции сервера начальной загрузки ФСНЗ согласно изобретению. Фиг.3 изображает только те части ФСНЗ, которые имеют отношение к изобретению.

Под позицией 310 представлено средство ввода/вывода для обмена данными с другими блоками. Система 370 внутренней шины соединяет между собой средства различных функций. Под позицией 320 показано средство для генерирования ключей и соответствующих идентификаторов ключей, например, ключа Ks и идентификатора B_TID. Под позицией 330 показано средство для генерирования ваучера аутентификации, и под позицией 340 - средство для проверки достоверности ваучера аутентификации. Средство для шифрования/расшифрования показано под позицией 380. Случайные числа генерируются средством 390. Средство 360 хранения хранит сгенерированную информацию, такую как данные идентификации пользователя, ключ Ks, ключи B_TID_NAF, идентификаторы ключей, и связывает данные, относящиеся к конкретному пользователю. Средство 350 обработки управляет выполнением внутренних операций блока 300. Понятно, что средство функций узла 300 может быть реализовано в виде аппаратных средств, программных средств или объединения обоих.

Примерный способ начальной аутентификации пользователя и создания сведений начальной загрузки, согласно изобретению, более ясен из фиг.4, которая изображает диаграмму потока сигналов для примерной связи между ОП, ФСНЗ, ДАС и ФСП.

На этапе 1 ОП инициирует процедуры начальной загрузки посредством посылки запроса на ФСНЗ. Запрос может посылаться при помощи ОП в результате установки конфигурации перед обращением к любой ФСП.

Альтернативно, согласно стандарту, ссылка [2], запрос может возникать в результате команды перенаправления ФСП в ответ на первоначальную попытку обращения, причем ФСП определяет, что не существует или истек срок действия данных предыдущей начальной загрузки.

Запрос может включать в себя явно заданные данные идентификации пользователя, например, международный идентификатор мобильной станции (МИМС) или персональный идентификатор мультимедиа ПИ (ПИМП), ссылка [5]. Генерируется по меньшей мере один идентификатор B_TID_NAF, который идентифицирует сгенерированные данные для конкретной ФСП, например, ключ, относящийся к ФСП.

Если запрос касается операции, задействующей ранее сгенерированный ключ Ks, например, для генерирования ключа, полученного из Ks, Ks_NAF, относящегося к заданной ФСП, или для извлечения ранее сгенерированного ключа Ks_NAF, запрос включает в себя идентификатор B_TID вместо явного идентификатора пользователя и по меньшей мере идентификатор одной конкретной ФСП. Отмечается, что B_TID достаточен для того, чтобы ФСНЗ извлекла идентификатор ОП. Эта процедура вводится для того, чтобы повысить конфиденциальность идентификации пользователя в дополнительной сигнализации, вводимой согласно изобретению.

Запрос также может включать в себя спецификацию «spec», предусматривающую дополнительные требования на запрос. Например, такая спецификация может относиться к конкретным требованиям, которые ФСП может иметь, например, требуется ли ключ Ks_NAF, ваучер аутентификации или оба, иначе должен ли использоваться заданный способ аутентификации, примерная аутентификация, основанная на карте УМИА.

На этапе 2 ФСНЗ инициирует процедуру аутентификации пользователя, если не существует достоверного ключа Ks начальной загрузки для пользователя, что указано идентификатором (ИД) пользователя или B_TID. В качестве примера может исполняться процедура аутентификации САК, что общеизвестно в данной области техники, или процедура аутентификации может использовать алгоритм открытого ключа.

На этапе 3 ФСНЗ генерирует изначально загруженный ключ Ks и, кроме того, ваучер аутентификации. Ваучер аутентификации, например, может включать в себя информацию о:

• времени аутентификации,

• способе аутентификации, и/или

• времени действия аутентификации.

Обычно время действия ваучера аутентификации и изначально загруженного Ks одинаково, но оно может устанавливаться индивидуально.

Информация о способе аутентификации указывает, например, имеет ли пользователь карту УМИА или МИМУП, или была ли аутентификация пользователя типа ОАНЗ-мо, основанная на мобильном оборудовании, или ОАНЗ-у, основанная на универсальной смарт-карте (УСК).

Далее, на этом этапе, B_TID генерируется, и извлекаются ключи Ks_NAF с соответствующими идентификаторами B_TID_NAF. Также устанавливается время действия для различных объектов, таких как ключи Ks, Ks_NAF и ваучер аутентификации.

На этапе 4 идентификаторы B_TID, (B_TID_NAF)n и время действия сведений начальной загрузки возвращаются к ОП.

Фиг.5 иллюстрирует примерный процесс, в котором ОП обращается к ФСП, запрашивая услуги. На этапе 1 ОП обращается к ФСП, представляя идентификатор B_TID_NAF, который позволяет ФСП извлечь с ФСНЗ мандат ОП.

Если требуется, или иным образом является подходящим, B_TID_NAF может быть защищен во время пересылки между объектами, например, при помощи протокола защиты транспортного уровня (ПЗТУ) / протокола безопасных соединений (ПБС). Также могут быть включены дополнительные характерные для приложения данные (msg).

ФСП представляет запрос для аутентификации пользователя на этапе 2, направляя принятый идентификатор B-TID-NAF. Чтобы исключить необходимость того, чтобы приложения ФСП, которые заинтересованы только в аутентификации пользователя, поддерживали и реализовывали дополнительное управление ключами и механизмы аутентификации пользователя, приложение ФСП может запросить ФСНЗ на представление только ваучера аутентификации пользователя. Таким образом, на этапе 2 ФСП может включить информацию (info), например, для указания необходимости ваучера аутентификации, ключ Ks_NAF или обои эти объекты.

На этапе 3 ФСНЗ возвращает ФСП запрашиваемые сведения. Ответ ФСНЗ для ФСП может быть защищен при помощи некоторой защиты транспортного уровня, например, ПЗТУ/ПБС. Кроме того, могут быть включены по меньшей мере часть профиля пользователя (Prof), время действия ключа (Key Lifetime), ваучер аутентификации и ответное сообщение (respmsg). Ваучер аутентификации дает возможность ФСП проверить аутентификацию пользователя. Как упомянуто в отношении фиг.4, ФСНЗ также может включать в себя инструкцию для перенаправления ОП запроса на ФСНЗ для генерирования нового мандата, если он отсутствует или его срок истек.

Альтернативно, только ваучер аутентификации возвращается ФСП, например, приложениям ФСП, которые заинтересованы только в аутентификации пользователя.

На этапе 4 ФСП обычно хранит по меньшей мере некоторые из принятых сведений. В частности, ФСП, может быть, не нужно хранить ваучер аутентификации после проверки. Это означает, что, если был возвращен только ваучер аутентификации, может быть необязательным хранение какой-либо информации. Если был принят ключ Ks_NAF, он может использоваться при последующих обращениях ОП до тех пор, пока будет действительным время существования ключа. ФСП, предпочтительно, проверяет информацию в ваучере аутентификации, чтобы проверить статус аутентификации конечного пользователя. Однако, что станет очевидным из описания альтернативных вариантов осуществления ниже, проверка ваучера аутентификации может, альтернативно, выполняться на ФСНЗ.

На этапе 5 ФСП может отвечать на начальный запрос на этапе 1, указывая, необходимо ли ОП запросить новый мандат у ФСНЗ согласно фиг.4. В этом случае, идентификатор B_TID используется на этапе 1 по фиг.4.

Во втором примерном аспекте изобретения ваучер аутентификации посылается на оборудование пользователя ОП по интерфейсу Ub. ОП представляет ваучер ФСП при запросе услуг с ФСП. С ссылкой на фиг.4, согласно данному второму аспекту изобретения, этап 4 предпочтительно включает в себя ваучер аутентификации, или, альтернативно, он посылается отдельно. Фиг.6 иллюстрирует пример ОП, обращающегося к ФСП, используя ваучер аутентификации. На этапе 1 ОП посылает запрос ФСП, включающий в себя ваучер. На этапе 2 ФСП извлекает из B_TID_NAF адрес для ФСНЗ и, например, проверяет достоверность ваучера при связи с ФСНЗ. Это указывается пунктирной линией на фиг.6.

Если ваучер достоверный, ФСП может запросить, на этапе 3, ключ у ФСНЗ, как указано посредством B_TID_NAF. На этапе 4 ФСНЗ обычно отвечает с ключом (Ks_NAF), временем действия ключа (Key Lifetime) и, предпочтительно, также по меньшей мере частью информации профиля (Prof). Запрос ключа и ответ на этапах 3 и 4 также могут быть включены в этап 2 как часть передачи между ФСП и ФСНЗ в процессе проверки ваучера. На этапе 5 принятые сведения сохраняются, и на этапе 6 ответ предоставляется пользовательскому объекту ОП. Снова отмечается, что запрос ключа Ks_NAF является необязательным, и что, только для аутентификации, достаточно ваучера.

Примерные альтернативные варианты осуществления

В примерном варианте осуществления изобретения, B_TID и B_TID_NAF на фиг.4, этап 4 шифруются посредством Ks. Так как ОП имеет такой же ключ, он может расшифровать эти объекты.

Согласно другому примерному варианту осуществления, множество NAF_ID может быть включено в запрос фиг.5, этап 1 для одновременного генерирования соответствующего множества ключей Ks_NAF и идентификаторов B_TID_NAF, тем самым уменьшая объем сигнализации посредством исключения конкретного запроса каждой индивидуальной ФСП.

Фиг.7 иллюстрирует другой примерный вариант осуществления, в котором, чтобы предотвратить атаки соединением с подстановкой на интерфейсе Ua, идентификатор B_TID_NAF характеризуется тем, что он только одноразовый. В качестве примера, B_TID_NAF подписывается с использованием ключа Ks, известного только ОП и ФСНЗ. Подпись может включать в себя признак обновленности. Подпись, согласно данному варианту осуществления, включаемая на этапах 1 и 2, как изображено на фиг.5, в качестве примера включается в параметр сообщения (msg).

На этапе 3 фиг.7 подпись и обновленность проверяются на ФСНЗ, используя ключ Ks.

Этапы 4-6 аналогичны этапам 3-5 на фиг.5.

Согласно альтернативному варианту осуществления первого аспекта изобретения, ваучер аутентификации ограничивается сообщением, что аутентификация была выполнена. Отмечается, что некоторая информация, как указано в первом аспекте изобретения, такая как способ аутентификации и время для аутентификации, может использоваться для отслеживания пользователя, и, таким образом, для выполнения атаки на конфиденциальность. Согласно альтернативному варианту осуществления, информация, содержащаяся в ваучере, ограничивается информацией, которая не позволяет выполнять никакое такое отслеживание. Если ФСП требует дополнительной информации, чтобы получить объявление аутентификации, она может послать ФСНЗ эти требования, после чего ФСНЗ проверяет, таким образом, требования, которые выполнены. В качестве примера, ФСП может потребовать, чтобы пользователь аутентифицировался на основе карты УМИА. Этот диалог вопроса/ответа может быть включен на этапах 2 и 3 фиг.5, в которых параметры (info) и (respmsg), соответственно, могут содержать требования ФСП и ответ на них ФСНЗ.

Что касается второго аспекта изобретения, этап 2 на фиг.6 может быть реализован так, как описывают следующие альтернативные варианты осуществления.

В одном варианте осуществления ключ Ks шифрует ваучер аутентификации, и проверка достоверности выполняется посредством ФСП, посылающей зашифрованный ваучер аутентификации на ФСНЗ. ФСНЗ имеет ключ Ks и может расшифровать ваучер аутентификации и проверить его достоверность. Таким образом, со ссылкой на фиг.6, на этапе 1 шифруется ваучер аутентификации. Передача, указанная пунктирной линией на этапе 2 фиг.6, теперь включает в себя посылку зашифрованного ваучера аутентификации на ФСНЗ для проверки.

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

С ссылкой на фиг.8, этап 1, ОП посылает запрос на обращение к ФСП1, включающий в себя зашифрованный ваучер аутентификации, посредством чего функция шифрования (Encr), в основном, зависит от ключа Ks шифрования, зашифрованных данных, т.е. ваучера аутентификации, и случайного числа (Rand1). В основном, шифрование имеет вид Encr(Ks, ваучер, Rand1). В одном конкретном варианте осуществления Rand1 сцепляется с ваучером и шифрование имеет вид Encr(Ks, Rand1 || ваучер), где «||» обозначает сцепление.

Так как ФСП не имеет ключа Ks и не может расшифровать ваучер аутентификации, ФСП направляет сообщение ФСНЗ на этапе 2 для проверки.

На этапе 3 ФСНЗ расшифровывает сообщение, извлекает ваучер аутентификации и проверяет достоверность ваучера аутентификации. После этого ФСНЗ определяет второе случайное число (Rand2) и выполняет двойное шифрование, используя ключ Ks, ваучер аутентификации, по формуле:

Encr(Ks, Encr(Ks, ваучер, Rand2)).

На этапе 4 ФСНЗ посылает обратное сообщение ФСП1 о результате проверки, включающее в себя ваучер аутентификации с двойным шифрованием. ФСП1 направляет обратное сообщение ОП на этапе 5. На этапе 6 ОП расшифровывает один раз сообщение с двойным шифрованием и получает:

Encr(Ks, ваучер, Rand2)Уравнение(1)

При предстоящем обращении, например, к ФСП2 на этапе 7, ОП предоставляет зашифрованный ваучер аутентификации по уравнению (1), теперь включающий в себя второе случайное число (Rand2). Та же процедура, что и раньше, повторяется, как изображено на этапе 8. Таким образом, каждое обращение к ФСП будет использовать уникальный ваучер аутентификации, предотвращая отслеживание пользователя.

Ссылки

1. Способ установления статуса аутентификации пользовательского объекта в сети связи, которая реализует ОАА/ОАНЗ (обобщенную архитектуру аутентификации/обобщенную архитектуру начальной загрузки), и в которой сетевой узел (120) ФСНЗ (функции сервера начальной загрузки) выполняет начальные этапы, по меньшей мере содержащие авторизацию пользовательского объекта ОП (140) и установление по меньшей мере одного ключа защиты, совместно используемого с ОП, содержащего первый ключ Ks и связанный с ним идентификатор В_TID ключа, и по меньшей мере один второй ключ Ks_NAF, полученный из Ks и связанный по меньшей мере с одной функцией сетевого приложения ФСП (130), для улучшенной защиты конфиденциальности и поддержки аутентификации, содержит этапы:
дополнительного генерирования сетевым узлом ФСНЗ ваучера аутентификации, объявляющего, что ОП было аутентифицировано;
генерирования по меньшей мере одного идентификатора B_TID_NAF ключа, связанного с упомянутым по меньшей мере одним вторым полученным ключом, причем идентификатор ключа является уникальным для каждой ФСП;
посылки сетевым узлом ФСНЗ идентификаторов B_TID и по меньшей мере одного идентификатора B_TID_NAF на ОП;
предоставления функцией сетевого приложения ФСП, в ответ на обращение ОП за услугами, включающее в себя по меньшей мере один идентификатор B_TID_NAF, по меньшей мере упомянутого идентификатора B_TID_NAF для ФСНЗ;
идентификации сетевым узлом ФСНЗ, в ответ на упомянутый идентификатор B_TID_NAF, ваучера аутентификации ОП для возможности установления статуса аутентификации ОП.

2. Способ по п.1, в котором пользовательский объект ОП идентифицируется, по интерфейсу Ub между ФСН3-ОП, упомянутым идентификатором В_TID.

3. Способ по п.1, в котором этап посылки идентификатора В_TID ключа и по меньшей мере одного идентификатора B_TID_NAF с ФСНЗ на ОП дополнительно содержит шифрование идентификаторов, используя ключ Ks.

4. Способ по п.1, в котором ваучер аутентификации является уникальным для каждой ФСП и идентифицируется упомянутым по меньшей мере одним идентификатором B_TID_NAF.

5. Способ по п.1, в котором этап предоставления дополнительно включает в себя предоставление подписи B_TID_NAF, причем подпись создается при помощи ОП, используя ключ Ks, и включается в упомянутое обращение за услугами.

6. Способ по п.5, в котором подпись включает в себя признак обновленности.

7. Способ по п.5, дополнительно содержащий этап проверки ФСНЗ подписи B_TID_NAF.

8. Способ по любому из пп.1-5, дополнительно содержащий этап установления ФСП статуса аутентификации посредством запроса ваучера аутентификации с сетевого узла ФСНЗ.

9. Способ по любому из пп.1-5, дополнительно содержащий этап установления ФСНЗ статуса аутентификации посредством анализа ваучера аутентификации.

10. Способ по любому из пп.1-5, в котором ФСП при упомянутом предоставлении дополнительно включает в себя запрос ключа Ks_NAF.

11. Способ по любому из пп.1-5, в котором ваучер аутентификации включает в себя информацию о, по меньшей мере, одном из: времени достоверности, времени для аутентификации и способа аутентификации.

12. Способ по п.8, дополнительно содержащий этапы:
представления ФСП для сетевого узла ФСНЗ дополнительных требований для подтверждения достоверности авторизации;
проверки ФСНЗ для ФСП, какие из дополнительных требований выполнены.

13. Способ по любому из пп.1-3, дополнительно содержащий этап посылки ФСНЗ на ОП ваучера аутентификации совместно с посылкой идентификаторов или отдельно от них.

14. Способ по п.13, в котором ваучер аутентификации выполнен уникальным для каждой ФСП и идентифицируется упомянутым по меньшей мере одним идентификатором B_TID_NAF.

15. Способ по п.14, в котором ваучер аутентификации выполнен уникальным посредством шифрования его ФСНЗ, используя ключ Ks и выбранное случайное число (Rand), различное для каждой ФСП, по формуле Encr (Ks, ваучер, Rand), где Encr представляет собой функцию шифрования, и в котором упомянутый способ дополнительно содержит установление статуса аутентификации посредством:
посылки зашифрованного ваучера аутентификации ФСНЗ;
расшифрования ФСНЗ ваучера аутентификации и проверки его достоверности;
выбора ФСНЗ нового случайного числа (Rand2) и повторного шифрования ваучера аутентификации во второй раз ключом Ks следующим образом: Encr (Ks, Encr (Ks, ваучер, Rand2));
возврата ФСНЗ повторно зашифрованного ваучера аутентификации на ОП через ФСП;
расшифрования ОП принятого ваучера аутентификации один раз для получения: Encr(Ks, ваучер, Rand2);
использования ОП расшифрованного один раз ваучера аутентификации при последующем обращении к ФСП.

16. Сетевой узел ФСНЗ (120) в сети связи, которая реализует архитектуру ОАА/ОАНЗ, выполняет аутентификацию пользовательского объекта ОП (140) и согласовывает совместно используемый ключ Ks с ОП (140), причем сетевой узел ФСНЗ (120) дополнительно содержит:
средство (320) для генерирования идентификатора В_TID, связанного с Ks;
средство (320) для генерирования по меньшей мере одного полученного ключа Ks_NAF, связанного с по меньшей мере одной функцией сетевого приложения ФСП (130) и для генерирования по меньшей мере соответствующего идентификатора B_TID_NAF, причем идентификатор является уникальным для каждой ФСП (130);
средство (330) для генерирования ваучера аутентификации, объявляющего, что ОП было аутентифицировано;
средство (360) для хранения ключей, идентификаторов ключей и ваучера аутентификации и для связывания этих объектов с ОП;
средство (310) для посылки B_TID и по меньшей мере одного B_TID_NAF на ОП;
средство (360) для извлечения, в ответ на прием по меньшей мере одного идентификатора B_TID_NAF, относящегося к оборудованию пользователя ОП, соответствующего ваучера аутентификации для возможности установления статуса аутентификации ОП.

17. Сетевой узел по п.16, дополнительно содержащий средство (380) для шифрования с использованием ключа Ks и алгоритма шифрования (Encr).

18. Сетевой узел по п.17, содержащий средство (390) для генерирования случайного числа Rand, и в котором упомянутое средство (380) для шифрования используется для шифрования ваучера аутентификации в виде Encr (Ks, ваучер, Rand).

19. Сетевой узел по п.16, содержащий средство (310) для приема и ответа на запрос от ФСП, касающийся подробностей аутентификации пользовательского объекта ОП, полученных от средства (340), анализирующего ваучер аутентификации.

20. Сетевой узел по п.19, в котором упомянутый запрос касается любого или всех из времени для аутентификации, способа аутентификации или времени действия аутентификации.

21. Система обеспечения улучшенной защиты конфиденциальности и аутентификации в сети связи, реализующей инфраструктуру (100) 0АА/0АНЗ, причем система содержит:
функцию сервера начальной загрузки ФСНЗ (120), которая предоставляет ваучер аутентификации, объявляющий аутентификацию пользовательского объекта ОП (140), и идентификаторы B_TID_NAF ключей Ks_NAF, связанных с по меньшей мере одной функцией сетевого приложения ФСП, причем идентификаторы являются уникальными для каждой ФСП (130);
интерфейс Ub между ФСНЗ (130) и ОП (140), который дополнительно защищен посредством шифрования с использованием ключа Ks, совместно используемого ФСНЗ (130) и ОП (140);
интерфейс Ua между ОП (140) и ФСП (130), который дополнительно защищен от атак соединением с подстановкой посредством подписания сообщений, используя ключ Ks и признак обновленности;
по меньшей мере одну функцию сетевого приложения ФСП (130), предназначенную для связи с ФСНЗ (120) в отношении достоверности ваучера аутентификации, так чтобы предотвратить сговор нескольких ФСП (130) с целью отслеживания пользовательского объекта ОП (140).

22. Система по п.21, в которой дополнительно содержится: средство (330) для ограничения информации в ваучере аутентификации только объявлением, что имела место аутентификация;
средство для предоставления ФСП (130) для задания дополнительных требований, относящихся к аутентификации пользователя, и средство (340) на ФСНЗ (130) для проверки выполнения каждого дополнительного требования.

23. Система по п.21, в которой дополнительно содержится средство (380) для шифрования ваучера аутентификации с использованием ключа Ks и в зависимости от случайного числа, так чтобы формировать уникальный ваучер аутентификации для каждой ФСП (130).