Способ осуществления аутентификации услуг высокоскоростной передачи пакетных данных

Изобретение относится к способу осуществления аутентификации услуг высокоскоростной передачи пакетных данных. Способ включает в себя следующие шаги: терминал пользователя, который установил физическое соединение с сетью доступа с помощью пользовательской информации, сохраненной в его собственном модуле идентификации пользователя UIM в качестве идентификатора пользователя, и запускает аутентификацию посредством аутентифицирующего объекта (АУ), основанного на UIM; АУ, в соответствии с указанным идентификатором пользователя, получает второе случайное число для аутентификации терминала пользователя и второй аутентифицирующий номер, соответствующий второму случайному числу и вычисленный в соответствии с общими секретными данными SSD, сохраненными на сетевой стороне; указанный терминал пользователя получает первый аутентифицирующий номер вычислением на основе второго случайного числа и самостоятельно сохраненных SSD; аутентифицирующий объект сравнивает первый аутентифицирующий номер со вторым аутентифицирующим номером; если они идентичны, то аутентификация терминала пользователя АУ проходит успешно, в противном случае аутентификация не происходит. Данный способ делает аутентификацию надежной с точки зрения безопасности при невысокой ее стоимости и удобной эксплуатации. 2 н. и 21 з.п. ф-лы, 8 ил.

 

Предмет изобретения

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

Предпосылки создания изобретения

CDMA является прогрессивной технологией цифровой сотовой мобильной связи и одной из самых важных технологий радиопередачи (RTT - Radio Transmission Technologies) 3G, принятой Международным Союзом Электросвязи (International Telecommunications Union - ITU). С момента первой публикации стандартов CDMA корпорацией QUALCOMM в 1990 г. в развитии технологии CDMA было два важных этапа, т.е. IS95 и CDMA2000 1х.

Как показано на фиг.1, архитектура сети CDMA2000 1х состоит из подвижной станции (Mobile Station - MS), базовой станции приемопередатчика (Base Transceiver Station - BTS), блока управления базовой станции (Base Station Controller - BSC), функции управления пакетами (Packet Control Function - PCF), узла услуги пакетных данных (Packet Data Service Node - PDSN), сервера аутентификации, авторизации, учета (Authentication, Authorization, Accounting - AAA) и базовой сети IS-41, где базовая сеть IS-41 включает в себя центр коммутации подвижной связи (Mobile Switching Center - MSC), визитный регистр местоположения (Visiting Location Register - VLR) и домашний регистр местоположения (Home Location Register - HLR).

Аутентификацию пользователя в сетях CDMA IS95 и CDMA 2000 1х выполняют совместно MSC/VLR и HLR/центр аутентификации AuC (Authentication Center - AuC). Кроме того, общие секретные данные (Shared Secret Data - SSD) сохраняют на терминале и HLR/AuC в качестве одного из входных параметров для аутентификации, в то время как идентичные пароли (A-key) сохраняют в терминале и HLR/AC специально для использования при обновлении SSD. Когда необходимо проведение аутентификации, результат аутентификации получают путем вычисления по алгоритму сотовой аутентификации и голосового кодирования (Cellular Authentication и Voice Encryption - CAVE) с такими параметрами, как SSD, случайное число, электронный серийный номер (Electronic Serial Number - ESN) и идентификационный номер подвижной станции (Mobile Station Identity Number - MIN), и MSC/VLR или HLR/AuC выполняют сравнение результата аутентификации для проверки его согласования; если результат несогласованный, то система инициирует обновление SSD. После успешного обновления SSD, т.е. достижения согласования SSD на стороне терминала и SSD на сетевой стороне, следующая аутентификация будет успешной только в том случае, если результат аутентификации, вычисленный пользователем с помощью SSD, будет согласован с результатом, вычисленным HLR/AuC.

CDMA 2000 HRPD (CDMA 2000 1xEV-DO), упрощенно HRPD, является усовершенствованной технологией CDMA 2000 1х, предоставляющей услугу высокоскоростной передачи пакетных данных со скоростью потока данных для одного пользователя, достигающей 2,4 Мб/с.

Как показано на фиг.2, сетевая архитектура HRPD состоит из терминала доступа (Access Terminal - AT), сети доступа (Access Network - AN), AN AAA, PCF, PDSN и AAA. Аутентификацию пользователя осуществляют в сети HRPD, главным образом, посредством AN AAA. После успешной аутентификации AN AAA возвращает AT уникальный международный идентификатор абонента (International Mobile Subscriber Identity - IMSI) терминала для использования при последующих процедурах коммутации и начисления оплаты. В процессе аутентификации HRPD между BSC/PCF и AN AAA применяют интерфейс А12, и этот интерфейс принимает протокол услуги дистанционного набора номера аутентификации в службе пользователя (Remote Access Dial User Service - RADIUS), где основными механизмами аутентификации являются протокол аутентификации пароля (Password Authentication Protocol - PAP) и протокол аутентификации запроса (Check-Handshake Authentication Protocol - CHAP). Поскольку протокол CHAP имеет относительно лучшие характеристики безопасности, для аутентификации больше применяют CHAP.

CHAP принимает алгоритм аутентификации объекта, основанный на 35 индивидуальном ключе со сверткой сообщений (Message Digest - MD). Как показано на фиг.3, выбор протокола CHAP в качестве примера и процедура аутентификации посредством протокола RADIUS включает в себя конкретно следующее:

Шаг 301: Терминал пользователя обращается к сетевой стороне через PPP/LCP и принимает решение об использовании CHAP для аутентификации;

Шаг 302: AN отправляет сообщение с запросом терминалу пользователя для инициирования аутентификации, и сообщение содержит случайное число, сгенерированное AN;

Шаг 303: Терминал пользователя вычисляет свертку со случайным числом посредством алгоритма кодирования, принятого CHAP, а затем отправляет имя пользователя и свертку в AN посредством ответного сообщения;

Шаг 304: AN в интерфейсе А12 использует сообщение Access Request (запрос доступа) протокола RADIUS для передачи имени пользователя, случайного числа и свертки и отправляет сообщение на AN AAA;

Шаг 305: AN AAA вычисляет свертку со случайным числом с использованием того же самого алгоритма и посредством сравнения выясняет, согласована ли эта свертка со сверткой, отправленной с терминала; если согласована, то аутентификация проходит успешно, и AN AAA отправляет сообщение Access Accept (принятие доступа) в AN, в противном случае аутентификация не происходит;

Шаг 306: AN отправляет на терминал пользователя сообщение Success, уведомляя пользователя об успешности аутентификации.

Из вышеописанной процедуры видно, что аутентификация пользователей HRPD на известном уровне техники требует использования AN AAA и эта аутентификация является односторонним процессом.

В настоящее время наряду с развитием рыночной экономики и технологии все большее число операторов стремится работать с разными сетями одновременно. Например, оператор сети IS95/CDMA 2000 1х хотел бы распространить свои услуги на сеть CDMA 2000 1xDO, несмотря на то, что аутентификация в CDMA 2000 1xDO требует установки специального AN AAA для аутентификации. Для пользователей многорежимного терминала этот подход к аутентификации требует открытия учетных записей как в HLR, так и на AN AAA, делая неединообразными режимы аутентификации и неудобным техническое обслуживание, что не способствует единообразию процессов управления. Более того, этот подход для аутентификации пользователей HRPD требует специальной общенациональной сети AN AAA, что приводит к большим затратам по созданию сети. Кроме того, поскольку аутентификация при этом подходе является односторонним процессом к пользователю, она ненадежна с точки зрения безопасности.

Помимо этого, беспроводная локальная сеть (Local Area Network - WLAN) становится все более привлекательной как техника высокоскоростного беспроводного доступа к данным. WLAN обычно используют для передачи IP-пакетов данных, т.е. для осуществления беспроводного доступа терминала пользователя через точку доступа (Access Point - АР) и последующей передачи IP-пакетов через сетевой адаптер и соединительные устройства. Во WLAN были применены различные методики, среди них техническим стандартом, имеющим большее число применений, является IEEE 802.11b. Этот стандарт использует диапазон частот 2,4 ГГц со скоростью передачи данных до 11 Мб/с. К другим техническим стандартам, использующим эту же частоту, относятся IEEE 802.11g и Bluetooth, где скорость передачи данных по IEEE 802.11g достигает 54 Мб/с. Другие новые стандарты, такие как IEEE 802.11а и ETSI BRAN Hiperlan2, используют диапазон частот 5 ГГц также со скоростью передачи 54 Мб/с.

Наряду с появлением и развитием WLAN происходит смещение центра исследований к обеспечению межсетевого обмена WLAN с различными беспроводными сетями мобильной связи, например GSM, CDMA, WCDMA, TD-SCDMA и CDMA2000. В организации по стандартизации 3GPP2 проводят исследование доступа пользователей WLAN в сети 3GPP2.

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

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

А. предварительно сконфигурированный сервер аутентификации выполняет аутентификацию терминала пользователя, устанавливая физическое соединение с AN посредством механизма, основанного на модуле идентификации пользователя (User Identity Module - UIM) и использует пользовательскую информацию, сохраненную в самом UIM терминала пользователя в качестве идентификатора пользователя;

Б. предварительно сконфигурированный сервер аутентификации в соответствии с указанным идентификатором пользователя получает второе случайное число для аутентификации терминала пользователя и вычисляет второй аутентифицирующий номер, соответствующий второму случайному числу в соответствии с SSD данного терминала пользователя, сохраненными в HLR/AuC или предварительно сконфигурированном сервере аутентификации;

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

В данном способе предварительно сконфигурированный сервер аутентификации включает в себя основанный на UIM сервер аутентификации, авторизации и учета (U-AAA).

Данный способ дополнительно содержит следующий шаг:

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

Данный способ дополнительно содержит следующий шаг:

После неудачи при аутентификации на шаге В обновляют SSD, затем выполняют шаг В.

В данном способе процедура обновления SSD включает в себя следующие шаги:

Г1. HLR генерирует случайное число SSD-обновления и вычисляет аутентифицирующий номер, соответствующий случайному числу SSD-обновления;

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

Г3. оценивают посредством сравнения согласования аутентифицирующего числа, вычисленного терминалом пользователя, и аутентифицирующего числа, вычисленного в HLR; если они согласованы, то происходит обновление SSD на стороне терминала пользователя, в противном случае SSD-обновление не происходит.

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

А. центр аутентификации (AuC) в подвижной сети мобильной связи выполняет аутентификацию терминала пользователя, устанавливая физическое соединение с AN посредством механизма аутентификации, основанного на UIM, и использует пользовательскую информацию, сохраненную в самом терминале пользователя в качестве идентификатора пользователя;

Б. данный AuC генерирует второе случайное число для аутентификации терминала пользователя и вычисляет второй аутентифицирующий номер, соответствующий второму случайному числу в соответствии с SSD данного терминала пользователя, сохраненному в HLR, причем данный SSD совместно используется терминалом пользователя и AuC;

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

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

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

В данном способе процедура обновления SSD включает в себя следующие шаги:

Г1. HLR генерирует случайное число SSD-обновления и вычисляет аутентифицирующий номер, соответствующий случайному числу SSD-обновления;

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

Г3. оценивают посредством сравнения согласования аутентифицирующего числа, вычисленного терминалом пользователя, и аутентифицирующего числа, вычисленного в HLR; если они согласованы, то происходит обновление SSD на стороне терминала пользователя, в противном случае SSD-обновление не происходит.

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

1. Данное изобретение поддерживает общенациональный роуминг посредством использования существующей базовой сети CDMA IS-41, и не возникает необходимости создания новой общенациональной специальной сети из AN AAA. Таким образом, снижена сумма затрат на создание.

2. В многорежимной сети проводят единообразную аутентификацию, и не возникает необходимости во вводе пользователем имени пользователя и пароля вручную, поэтому пользование становится удобным. Кроме того, поскольку единообразное открытие учетных записей, аутентификация и авторизация могут быть проведены в HLR посредством IMSI для услуг HRPD и услуг других сетей, метод удобен для операторов. В то же время пользователи HRPD могут продолжать использовать свои прежние карты UIM сети IS95/CDMA2000 1х, следовательно, это способствует переходу пользователей IS95/CDMA2000 1х в сети HRPD.

3. Посредством протокола EAP-UIM терминал пользователя может также осуществлять аутентификацию сетевой стороны для обеспечения взаимной аутентификации между сетью и терминалом, т.е. аутентификация терминала сетью и аутентификация сети терминалом. Следовательно, метод является более надежным с точки зрения безопасности.

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

На фиг.1 приведена схема, иллюстрирующая организацию системы сети IS95/CDMA2000 1х;

На фиг.2 приведена схема, иллюстрирующая организацию сети HRPD;

На фиг.3 приведена схема, иллюстрирующая процесс аутентификации HRPD на известном уровне техники;

На фиг.4 приведена схема, иллюстрирующая сетевую архитектуру в соответствии с данным изобретением;

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

На фиг.6 приведена схема, иллюстрирующая процесс аутентификации при вторичном подключении в реализации 1 данного изобретения;

На фиг.7 приведена схема, иллюстрирующая процесс аутентификации при первоначальном подключении питания в реализации 2 данного изобретения;

На фиг.8 приведена схема, иллюстрирующая пример процесса установления связи между терминалом пользователя и сетью доступа посредством CHAP в соответствии с данным изобретением.

Реализации изобретения

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

Сеть, посредством которой получают доступ к терминалу пользователя, может содержать WLAN. Аутентифицирующий объект может содержать предварительно сконфигурированный сервер аутентификации или исходный центр аутентификации. В раскрытых реализациях заявленного изобретения в качестве предпочтительного варианта исполнения предварительно сконфигурированного сервера аутентификации рассмотрен U-AAA. Для специалиста в данной области техники очевидно, что U-AAA является предварительно сконфигурированным сервером аутентификации. Сервер аутентификации может быть связан с HLR посредством протокола ANSI-41D. Второе случайное число можно генерировать любым объектом на сетевой стороне, например HLR/AuC, AAA и т.д. SSD можно сохранить в HLR/AuC на сетевой стороне или на сервере аутентификации. Когда HLR/AuC генерируют второе случайное число, второй аутентифицирующий номер может быть получен непосредственно из HLR/AuC. Когда AAA генерирует второе случайное число, второй аутентифицирующий номер может быть получен из HLR/AuC в соответствии с идентификатором пользователя и первым случайным числом. Терминал пользователя и AN могут быть связаны друг с другом посредством CHAP или ЕАР или посредством исходных сообщений CDMA2000 для интерфейса беспроводного канала.

Техническое решение в соответствии с настоящим изобретением подробно описано далее со ссылками на сопроводительные чертежи и конкретные реализации.

Как показано на фиг.4, архитектура сети в соответствии с данным изобретением включает AT (терминал пользователя), AN, основанный на UIM сервер аутентификации, авторизации и учета (U-AAA), PCF, PDSN, AAA, HLR, где AN обеспечивает информационную связь между терминалом и сетью коммутации пакетов данных, т.к. она эквивалентна BTS и BSC в CDMA2000 1х и, очевидно, также эквивалентна WLAN; U-AAA предварительно конфигурируют и включают для аутентификации и учета. В данной реализации заявленного изобретения предпочтительным вариантом исполнения предварительно сконфигурированного сервера аутентификации является U-AAA.

Используемые здесь сетевые элементы, такие как BTS, PCF, PDSN, HLR, не должны быть изменены; терминал пользователя должен быть терминалом HRPD или гибридным терминалом, поддерживающим HRPD, например терминалом HRPD/GSM, HRPD/CDMA2000 1х или HRPD/WLAN, в то время как его аппаратная часть должна поддерживать возможность считывания карт UIM или обеспечивать интерфейс с внешним устройством считывания карт и поддерживать протокол EAP-UIM, так же как аутентификацию посредством GSM HLR или CDMA HLR; AN должна поддерживать протокол аутентификации в интерфейсе беспроводного канала и интерфейс А12, где интерфейс беспроводного канала является EAP-UIM в РРР, а А12 является EAP-UIM в RADIUS. AAA может быть удален, при этом предварительно сконфигурированный U-AAA выполняет функцию учета. Замена AN AAA элементом сети U-AAA обусловлена главным образом требованием поддержки протокола CDMA IS41, так же как протокола аутентификации EAP-UIM в RADIUS. Кроме того, HLR и AuC обычно находятся в одном и том же объекте, поэтому далее обозначены как HLR.

Следует отметить, что процесс аутентификации после первичного включения питания состоит из трех частей, т.е. первичной аутентификации, SSD-обновления и вторичной аутентификации. Аутентификация, проводимая при первичном включении питания AT, является первичной аутентификацией, и, поскольку SSD, сохраненные на системной стороне, и SSD, сохраненные на стороне AT, не согласованы при первичном подключении AT, то первичная аутентификация AT никогда не происходит. Поэтому необходимо обновить SSD после неудачи при первичной аутентификации, т.е. получить RANDSSD посредством сообщения ЕАР-Request/UIM/Update и вычислить новые в AT и HLR посредством того же самого алгоритма генерации SSD с RANDSSD, ESN, A-key (А-ключом). Поскольку эти параметры на стороне AT и на стороне HLR идентичны и идентичны используемые алгоритмы, то выведенные SSD будут одинаковыми. После обновления SSD выполняют вторичную аутентификацию. На этот раз, поскольку гарантирована идентичность SSD на стороне AT и SSD на стороне HLR, вторичная аутентификация успешно проходит в обычных условиях. Для пользователей, осуществляющих повторное включение, SSD на системной стороне и SSD на стороне AT одинаковы, поэтому не возникает необходимости в обновлении SSD и вторичной аутентификации, и для достижения успеха достаточно выполнить аутентификацию только один раз.

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

Шаг 801: Сеанс HRPD установлен между AT и AN, и AT подготовлен к обмену данными в проходящем потоке.

Шаг 802: AT и AN инициируют запрос РРР и LCP для аутентификации доступа.

Шаг 803: AN инициирует Random Challenge и отправляет его в AT посредством сообщения CHAP Challenge.

Шаг 804: AT проводит аутентификацию на основе CAVE и отправляет сообщение CHAP Response.

Шаг 805: AN отправляет на U-AAA сообщение A12-Access Request.

Шаг 806: U-AAA создает сообщение AUTHREQ на основе информации в сообщении A12-Access Request и отправляет сообщение AUTHREQ в HLR/AuC.

Шаг 807: HLR/AuC выполняет процедуру аутентификации, основанную на CAVE, если аутентификация проходит успешно, то HLR/AuC отправляет на U-ААА сообщение с параметром SSD.

Шаг 808: U-AAA сохраняет SSD, заданные регистром HLR/AuC.

Шаг 809: U-AAA отправляет в AN сообщение A12-Access Accept.

Шаг 810: AN отсылает в AT команду об успешном завершении аутентификации на основе CHAP.

Шаг 811: AT и AN продолжают выполнение последующих шагов обработки данных.

Техническое решение в соответствии с настоящим изобретением подробно описано далее со ссылками на сопроводительные чертежи и реализацию 1 изобретения. В данной реализации заявленного изобретения предпочтительным вариантом исполнения предварительно сконфигурированного сервера аутентификации является U-AAA.

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

Шаг 501: Происходит установление физического соединения между WLAN MS и WLAN.

Шаг 502: WLAN MS инициирует запрос аутентификации к WLAN, т.е. WLAN MS отправляет в сеть сообщение EAPoL-Start.

Шаг 503: WLAN отправляет в WLAN MS сообщение EAP-Request/Identity, запускает процедуру аутентификации и запрашивает у WLAN MS предоставление идентификатора пользователя.

Шаг 504: После получения сообщения EAP-Request/Identity WLAN MS считывает информацию, сохраненную в UIM через соответствующий интерфейс, использует эту информацию в качестве собственного идентификатора пользователя и отправляет этот идентификатор в WLAN посредством сообщения ЕАР-Response/Identity.

Шаг 505: После получения сообщения EAP-Response/Identity WLAN инициирует запрос аутентификации посредством сообщения Access-Request в протоколе Radius, и сообщение Access-Request содержит вложенное сообщение EAP-Response/Identity.

Шаг 506: После получения сообщения Access-Request, отправленного из WLAN, U-AAA извлекает идентификатор пользователя, содержащийся в нем, и затем определяет тип идентификатора пользователя в соответствии с собственной информацией о подходящей конфигурации; если это тип UIM, то вкладывает сообщение ЕАР-Request/UIM/Start (ЕАР-Запрос/UIM/Запуск) в сообщение Access-Challenge и отправляет его в WLAN, в противном случае никакая обработка не происходит.

Шаг 507: После получения сообщения Access-Challenge, WLAN выделяет из него сообщение ЕАР-Request/UIM/Start и затем отправляет выделенное сообщение в WLAN MS.

Шаг 508: После получения сообщения ЕАР-Request/UIM/Start, отправленного из WLAN, WLAN MS вводит самостоятельно сгенерированное случайное число Nonce_MT в атрибут AT_NONCE_MT, а затем отправляет в WLAN сообщение EAP-Response/UIM/Start, содержащее это случайное число, что указывает на согласие использовать протокол аутентификации EAP-UIM.

Шаг 509: После получения сообщения EAP-Response/UIM/Start, отправленного из WLAN MS, WLAN вкладывает это сообщение в сообщение Access-Request, a затем отправляет сообщение Access-Request на U-AAA.

Шаг 510: После получения сообщения Access-Request, отправленного из WLAN, U-AAA принимает решение о принятии режима единого запроса, т.е. U-ААА генерирует случайное число для аутентификации WLAN MS (RANDU) - второе случайное число и вычисляет второй аутентифицирующий номер, соответствующий этому случайному числу, в соответствии с самостоятельно сохраненными SSD, создавая таким образом, аутентифицирующий числовой комплект.

Шаг 511: U-AAA вкладывает RANDU в сообщение ЕАР-Request/UIM/Challenge, а затем отправляет RANDU и MAC в WLAN посредством сообщения Access-Challenge, где U-AAA генерирует MAC в соответствии с полученным случайным числом Nonce_MT и сообщением EAP-Request, которое должно быть отправлено.

Шаг 512: После получения сообщения Access-Challenge, отправленного из U-ААА, WLAN выделяет сообщение EAP-Request/UIM/Challenge из него и отправляет выделенное сообщение в WLAN MS.

Шаг 513: После получения сообщения EAP-Request/UIM/Challenge WLAN MS сначала проверяет правильный ли MAC в сообщении ЕАР; если он неточный, то WLAN MS отправляет сети сообщение Incorrect и завершает эту процедуру, в противном случае WLAN MS извлекает из сообщения RANDU и вычисляет первый аутентифицирующий номер (AUTHU1) на основе RANDU и ESN, SSD, MIN, полученных из UIM.

Шаг 514: WLAN MS отправляет AUTHU1, ESN, MIN и пересчитанный MAC во WLAN посредством сообщения EAP-Response/UIM/Challenge.

Шаг 515: WLAN вкладывает полученное сообщение EAP-Response/UIM/Challenge в сообщение Access-Request протокола Radius и отправляет сообщение Access-Request с вложением на U-AAA.

Шаг 516: После получения сообщения Access-Request, отправленного из WLAN, U-AAA получает из него AUTHU1 и оценивает согласован ли AUTHU1 с самостоятельно вычисленными AUTHU2; если согласован, то аутентификация WLAN MS посредством U-AAA проходит успешно, в противном случае аутентификация не происходит.

Шаг 517: U-AAA отправляет на сетевую сторону сообщение Access-Accept (Доступ-Принять), содержащее сообщение EAP-Success (аутентификация проходит успешно); или U-AAA отправляет во WLAN сообщение Access-Reject (Доступ-Отклонить), содержащее сообщение EAP-Failure (аутентификация не происходит).

Шаг 518: После получения сообщения Access-Accept, отправленного из U-ААА, WLAN выделяет из него сообщение EAP-Success и отправляет его во WLAN MS, информируя WLAN MS об успешном завершении аутентификации; если получено сообщение Access-Reject, то WLAN выделяет из него сообщение ЕАР-Failure и отправляет его каждой WLAN MS, информируя WLAN MS о том, что аутентификация не происходит.

Как показано на фиг.6, когда AT находится в состоянии первичного включения питания, характерный процесс аутентификации заключен в следующем:

Шаги 601-615 точно такие же, как шаги 501-515 на фиг.5.

Шаги 616-617: U-AAA сравнивает полученный AUTHU1 с AUTHU1, сохраненный локально; если они идентичны, аутентификация клиента проходит успешно, и U-AAA отправляет сообщение EAP-Success на WLAN MS no WLAN, в противном случае U-AAA посылает обратно в HLR сообщение о том, что аутентификация не происходит. После получения возвращенного сообщения HLR генерирует два случайных числа, RANDSSD и RANDU, случайным образом, вычисляет соответствующий AUTHU на основе RANDU, а затем отправляет RANDSSD/RANDU/AUTHU на U-AAA, запуская процедуру обновления SSD.

Шаг 618: U-AAA отправляет в WLAN сообщение Access-Challenge, которое содержит сообщение EAP-Request/UIM/Update, содержащее случайное число RADNSSD.

Шаг 619: WLAN отправляет сообщение EAP-Request/UIM/Update на WLAN MS.

Шаг 620: После получения из WLAN сообщения EAP-Request/UIM/Update WLAN MS преобразует в нем RADNSSD, затем вычисляет свои собственные новые SSD, случайным образом генерирует случайное число RANDBS, вычисляет соответствующий аутентифицирующий номер AUTHBS на основе новых SSD и отправляет RANDBS в WLAN посредством сообщения ЕАР-Response/UIM/Challenge, запуская процедуру аутентификации U-AAA.

Шаг 621: WLAN отправляет сообщение EAP-Response/UIM/Challenge на сервер аутентификации U-AAA в формате сообщения ЕАР Over RADIUS.

Шаг 622: После получения сообщения EAP-Response/UIM/Challenge U-AAA получает случайное число запроса BS (RANDBS) и соответствующий результат запроса аутентификации (AUTHBS) посредством взаимодействия с HLR, при этом HLR генерирует RANDBS случайным образом и получает AUTHBS посредством вычисления на основе этого случайного числа и самостоятельно сохраненных SSD.

Шаг 623: U-AAA отправляет во WLAN сообщение Access-Challenge с вложенным сообщением EAP-Request/UIM/Challenge, содержащим AUTHBS.

Шаг 624: После получения сообщения EAP-Request/UIM/Challenge WLAN отправляет это сообщение в WLAN MS.

Шаг 625: После получения из WLAN сообщения EAP-Request/UIM/Challenge WLAN MS преобразует в нем AUTHBS и сравнивает преобразованный AUTHBS с самостоятельно вычисленным AUTHBS; если они идентичны, аутентификация U-ААА посредством WLAN MS проходит успешно, и WLAN MS отправляет сообщение EAP-Request/UIM/Success.

Шаг 626: После получения этого сообщения WLAN отправляет сообщение EAP-Request/UIM/Success на сервер аутентификации U-AAA в формате сообщения Access-Request, содержащее соответствующие атрибуты RADIUS, что указывает на завершение процедуры обновления SSD.

Шаг 627: После получения сообщения Access-Request, отправленного из WLAN, U-AAA принимает решение о принятии режима единого запроса в соответствии с RANDU и AUTHBS, полученными из HLR на шаге 616. Шаги 628-635 точно такие же, как шаги 511-518 на фиг.5.

На шаге 632 U-AAA одновременно выдает команду HLR/AuC обновить SSD, сохраненные в AuC, и AuC обновляет локальные SSD в соответствии с полученным в команде сообщением.

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

Как показано на фиг.7, этот вариант исполнения принимает глобальный режим аутентификации и процесс аутентификации WLAN MS заключен в следующем:

Шаг 701: Происходит установление физического соединения между WLAN MS и WLAN.

Шаг 702: WLAN MS выдает запрос сети для аутентификации, т.е. WLAN MS отправляет в сеть сообщение EAPoL-Start (.EAPoL-Запуск).

Шаг 703: WLAN отправляет на WLAN MS сообщение EAP-Request/Identity, запускает процедуру аутентификации и запрашивает у WLAN MS предоставление идентификатора пользователя.

Шаг 704: После получения сообщения EAP-Request/Identity WLAN MS считывает информацию, сохраненную в UIM через соответствующий интерфейс, использует эту информацию в качестве собственного идентификатора пользователя и отправляет этот идентификатор во WLAN посредством сообщения EAP-Request/Identity.

Шаг 705: После получения сообщения EAP-Request/Identity WLAN инициирует запрос аутентификации посредством сообщения Access-Request в протоколе Radius, и это сообщение содержит сообщение EAP-Request/Identity.

Шаг 706: После получения сообщения Access-Request, отправленного из WLAN, U-AAA извлекает из него идентификатор пользователя и затем определяет тип идентификатора пользователя в соответствии с собственной информацией о конфигурации; если это тип UIM, то вкладывает сообщение EAP-Request/UIM/Start в сообщение Access-Challenge и отправляет его во WLAN, в противном случае не производит процесс обработки.

Шаг 707: После получения сообщения Access-Challenge WLAN выделяет из него сообщение EAP-Request/UIM/Start и затем отправляет выделенное сообщение на WLAN MS.

Шаг 708: После получения из WLAN сообщения EAP-Request/UIM/Start WLAN MS отправляет во WLAN сообщение EAP-Response/UIM/Start, указывающее на согласие использовать протокол аутентификации EAP-UIM.

Шаг 709: После получения сообщения EAP-Response/UIM/Start, отправленного из WLAN MS, WLAN вкладывает его в сообщение Access-Request, а затем отправляет сообщение Access-Request на U-AAA.

Шаг 710: После получения сообщения Access-Request, отправленного из WLAN, U-AAA принимает решение об использовании глобального режима аутентификации, т.е. U-AAA генерирует случайное число для аутентификации WLAN MS (RAND) - второе случайное число и вычисляет в соответствии с самостоятельно сохраненными SSD второй аутентифицирующий номер (AUTHR2), создавая, таким образом, аутентифицирующий числовой комплект. Кроме того, U-ААА вычисляет соответствующий код аутентификации сообщения (Message Authentication Code - MAC) посредством определенного алгоритма.

Шаг 711: U-AAA вкладывает RAND и MAC в сообщение ЕАР-Request/UIM/Challenge, а затем отправляет его во WLAN посредством сообщения Access-Challenge.

Шаг 712: После получения сообщения Access-Challenge, отправленного из U-ААА, WLAN выделяет из него сообщение EAP-Request/UIM/Challenge и отправляет выделенное сообщение на WLAN MS.

Шаг 713: После получения сообщения EAP-Request/UIM/Challenge WLAN MS выделяет из него RAND и вычисляет первый аутентифицирующий номер (AUTHR1) на основе RAND и пароля, считанного из UIM.

Шаг 714: WLAN MS отправляет AUTHU1, ESN, MIN, MAC и RANDC во WLAN посредством сообщения EAP-Response/UIM/Challenge, где WLAN MS определяет RANDC в соответствии с полученным RAND.

Шаг 715: WLAN вкладывает полученное сообщение EAP-Response/UIM/Challenge в сообщение Access-Request протокола Radius и отправляет данное сообщение с вложением на U-AAA.

Шаг 716: После получения сообщения Access-Request, отправленного из WLAN, U-AAA определяет соответствующий RAND в соответствии с содержащимся в нем RANDC, а затем выясняет, получены ли SSD пользователя; если да, то преобразует содержащийся в нем AUTHR1 и оценивает согласован ли полученный AUTHR1 с самостоятельно вычисленным AUTHU2 терминала пользователя; если согласован, то аутентификация WLAN MS посредством U-AAA проходит успешно, в противном случае аутентификация не происходит.

Шаг 717: U-AAA отправляет во WLAN сообщение Access-Accept, содержащее сообщение EAP-Success и значение MAC; или U-AAA отправляет во WLAN сообщение Access-Reject, содержащее сообщение EAP-Faiure и значение MAC.

Шаг 718: После получения сообщения Access-Accept, отправленного из U-ААА, WLAN выделяет из него сообщение EAP-Success и отправляет выделенное сообщение на WLAN MS, информируя WLAN MS об успешном завершении аутентификации, при получении сообщения Access-Reject WLAN выделяет из него сообщение EAP-Failure и отправляет выделенное сообщение на каждую WLAN MS, информируя WLAN MS о том, что аутентификация не происходит. WLAN MS сначала проверяет MAC и подтверждает правильность сообщения EAP-request, только если полученный MAC идентичен MAC, вычисленному локально.

Из вышеупомянутых реализаций видно, что процесс аутентификации бывает запущен, когда пользователь намерен получить доступ в обеспечивающую межсетевой обмен сеть WLAN-3GPP2 или сеть намерена повторить аутентификацию пользователя WLAN, прошедшего аутентификацию.

Реализация 1 является процессом единственного запроса, а реализация 2 является процессом глобальной аутентификации. Эти два процесса, в основном, одинаковы, за исключением различий типов случайного числа, генерируемого, когда U-AAA выполняет аутентификацию WLAN MS и различий некоторых параметров, передаваемых в сообщениях аутентификации между WLAN MS и U-ААА.

Главные различия между реализацией 1 и реализацией 2 заключены в следующем:

(1) Типы генерируемых случайных чисел различны. В режиме единственного запроса U-AAA генерирует RANDU и AUTHU, в то время как в режиме глобальной аутентификации U-AAA генерирует RAND и AUTHR.

(2) В режиме единственного запроса, когда U-AAA отправляет сгенерированное RANDU на WLAN MS, WLAN MS генерирует AUTHU посредством алгоритма CAVE с RANDU, A-key (А-ключом), MIN и ESN в качестве входных параметров, в то время как в режиме глобальной идентификации, когда U-ААА отправляет сгенерированное RAND на WLAN MS, WLAN MS генерирует AUTHR посредством алгоритма CAVE с RAND, A-key (А-ключом), MIN и ESN в качестве входных параметров.

(3) В режиме единственного запроса после получения AUTHU посредством вычисления WLAN MS отправляет этот параметр на U-AAA, в то время как режиме глобальной идентификации после получения AUTHR посредством вычисления WLAN MS отправляет на U-AAA этот параметр наряду с параметром RANDC, полученным из RAND.

Реализация 1 и реализация 2 одинаковы в следующем:

(1) После получения посредством вычисления AUTHU или AUTHR WLAN MS отправляет на U-AAA сообщение-отклик, которое в любом случае содержит ESN и MIN из WLAN MS.

(2) После получения сообщения EAP-Request/UIM/Start, запускающего процесс аутентификации UIM, отправленного из U-AAA, WLAN MS внутри генерирует случайное число, AT_NONCE_MT, и отправляет это случайное число на U-AAA посредством сообщения EAP-Response/UIM/Start для использования в качестве параметра для аутентификации сети терминалом.

(3) После получения AT_NONCE_MT, отправленного с WLAN MS, U-AAA вычисляет по алгоритму ответный MAC и отправляет этот MAC на WLAN MS посредством последующего сообщения EAP-request. WLAN MS сначала проверяет MAC и подтверждает правильность сообщения EAP-request только в случае, если полученный MAC идентичен MAC, вычисленному локально.

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

1. Способ осуществления аутентификации услуг высокоскоростной передачи пакетных данных, включающий в себя следующие шаги:

А. предварительно сконфигурированный сервер аутентификации выполняет аутентификацию терминала пользователя, устанавливая физическое соединение с сетью доступа AN посредством механизма, основанного на модуле идентификации пользователя (User Identity Module - UIM) и использует пользовательскую информацию, сохраненную в самом UIM терминала пользователя в качестве идентификатора пользователя;

Б. предварительно сконфигурированный сервер аутентификации в соответствии с указанным идентификатором пользователя получает второе случайное число для аутентификации терминала пользователя и вычисляет второй аутентифицирующий номер, соответствующий второму случайному числу в соответствии с общими секретными данными SSD данного терминала пользователя, сохраненными в HLR/AuC или предварительно сконфигурированном сервере аутентификации, где HLR - домашний регистр местоположения, a AuC - центр аутентификации;

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

2. Способ по п.1, отличающийся тем, что предварительно сконфигурированный сервер аутентификации содержит основанный на UIM сервер аутентификации, авторизации и учета (U-AAA).

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

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

5. Способ по п.3 или 4, отличающийся тем, что процесс обновления SSD включает в себя:

Г1. HLR генерирует случайное число SSD-обновления и вычисляет аутентифицирующий номер, соответствующий этому случайному числу SSD-обновления;

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

Г3. оценка посредством сравнения согласования аутентифицирующего числа, вычисленного терминалом пользователя, и аутентифицирующего числа, вычисленного в HLR; если они согласованы, происходит обновление SSD на стороне терминала пользователя, в противном случае SSD-обновление не происходит.

6. Способ по п.5, отличающийся тем, что шаг Г1 далее включает в себя:

Г11. HLR отправляет случайное число SSD-обновления (RADNSSD) и соответствующее аутентифицирующее число предварительно сконфигурированному серверу аутентификации;

Г12. предварительно сконфигурированный сервер аутентификации отправляет в AN сообщение Access-Challenge, содержащее сообщение ЕАР-Request/UIM/Update с RADNSSD.

Г13. AN отправляет сообщение EAP-Request/UIM/Update на терминал пользователя.

7. Способ по п.6, отличающийся тем, что шаг Г2 включает в себя:

Г21. после получения сообщения EAP-Request/UIM/Update, отправленного AN, терминал пользователя вычисляет новые SSD с использованием RADNSSD, случайным образом генерирует случайное число RANDBS, вычисляет аутентифицирующий номер AUTHBS, соответствующий RANDBS, на основе новых SSD, а затем отправляет RANDBS в AN посредством сообщения EAP-Response/UIM/Challenge;

Г22. AN отправляет сообщение EAP-Response/UIM/Challenge предварительно сконфигурированному серверу аутентификации; предварительно сконфигурированный сервер аутентификации получает случайное число RANDBS запроса базовой станции и соответствующий аутентифицирующий номер запроса AUTHBS посредством взаимодействия с HLR, при этом указанный AUTHBS получен посредством вычисления на основе RANDBS и самостоятельно сохраненных SSD;

Г23. предварительно сконфигурированный сервер аутентификации отправляет в AN сообщение Access-Challenge, содержащее ЕАР-Request/UIM/Challenge с аутентифицирующим номером AUTHBS; после получения этого сообщения AN отправляет это сообщение на терминал пользователя.

8. Способ по п.6, отличающийся тем, что шаг Г3 включает в себя:

Г31. после получения сообщения EAP-Request/UIM/Challenge терминал пользователя оценивает посредством сравнения согласован ли выделенный из него AUTHBS с AUTHBS, вычисленным им самим; если он согласован, происходит обновление SSD на стороне терминала, терминал пользователя успешно проходит аутентификацию предварительно сконфигурированным сервером аутентификации и отправляет сообщение ЕАР-Response/UIM/Success в AN;

Г32. после получения этого сообщения AN отправляет предварительно сконфигурированному серверу аутентификации сообщение ЕАР-Response/UIM/Success, содержащее атрибуты соответствующего RADIUS; после получения этого сообщения предварительно сконфигурированный сервер аутентификации обновляет SSD пользователя.

9. Способ по п.5, отличающийся тем, что указанные собственные SSD на шаге Г2 вычислены на основе указанного случайного числа SSD-обновления, электронного серийного номера ESN и A-key.

10. Способ по п.1, отличающийся тем, что шаг А включает в себя:

А1. AN отправляет запрос аутентификации на терминал пользователя;

А2. после получения этого запроса аутентификации терминал пользователя считывает пользовательскую информацию, сохраненную в UIM, берет эту пользовательскую информацию в качестве собственного идентификатора пользователя и затем отправляет указанную пользовательскую информацию предварительно сконфигурированному серверу аутентификации через AN.

11. Способ по п.11, отличающийся тем, что указанная AN соединена с терминалом пользователя посредством расширенного протокола аутентификации ЕАР или протокола аутентификации запроса CHAP.

12. Способ по п.10, отличающийся тем, что при направлении запроса аутентификации посредством ЕАР, отправка запроса аутентификации терминалу пользователя по AN на шаге А1 происходит посредством сообщения EAP-Request/Identity; и

шаг А2 включает в себя:

А21. указанный терминал пользователя отправляет идентификатор пользователя в AN посредством сообщения EAP-Request/Identity;

А22. после получения этого сообщения AN отправляет сообщение на предварительно сконфигурированный сервер аутентификации посредством сообщения Access-Request, инициируя запрос аутентификации к предварительно сконфигурированному серверу аутентификации.

13. Способ по п.1, отличающийся тем, что шаг Б далее включает в себя: предварительно сконфигурированный сервер аутентификации отправляет терминалу пользователя по AN полученное второе случайное число для аутентификации терминала пользователя.

14. Способ по п.13, отличающийся тем, что шаг отправки второго случайного числа на терминал пользователя посредством AN на шаге Б включает в себя:

Б1. предварительно сконфигурированный сервер аутентификации вкладывает указанное второе случайное число в сообщение ЕАР-Request/UIM/Challenge и отправляет это сообщение в AN посредством сообщения Access-Challenge;

Б2. после получения сообщения Access-Challenge, отправленного из предварительно сконфигурированного сервера аутентификации, AN выделяет сообщение EAP-Request/UIM/Challenge из сообщения Access-Challenge и отправляет выделенное сообщение на терминал пользователя.

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

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

В1. терминал пользователя отправляет первый аутентифицирующий номер в AN посредством сообщения EAP-Response/UIM/Challenge;

В2. AN вкладывает полученное сообщение EAP-Response/UIM/Challenge в сообщение Access-Request и отправляет это сообщение с вложением предварительно сконфигурированному серверу аутентификации.

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

18. Способ по п.3, отличающийся тем, что между указанным предварительно сконфигурированным сервером аутентификации и HLR установлена связь посредством протокола ANSI-41D.

19. Способ по п.1, отличающийся тем, что указанная AN включает в себя беспроводную локальную сеть WLAN.

20. Способ осуществления аутентификации услуг высокоскоростной передачи пакетных данных, включающий в себя следующие шаги:

А. центр аутентификации (AuC) в подвижной сети мобильной связи выполняет аутентификацию терминала пользователя, устанавливая физическое соединение с AN посредством механизма аутентификации, основанного на UIM, и использует пользовательскую информацию, сохраненную в самом терминале пользователя в качестве идентификатора пользователя;

Б. данный AuC генерирует второе случайное число для аутентификации терминала пользователя и вычисляет второй аутентифицирующий номер, соответствующий второму случайному числу в соответствии с SSD данного терминала пользователя, сохраненному в HLR, причем данные SSD совместно используются терминалом пользователя и AuC;

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

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

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

23. Способ по п.21 или 22, отличающийся тем, что процедура обновления SSD включает в себя следующие действия:

Г1. HLR генерирует случайное число SSD-обновления и вычисляет аутентифицирующий номер, соответствующий случайному числу SSD-обновления;

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

Г3. оценивают посредством сравнения согласования аутентифицирующего числа, вычисленного терминалом пользователя, и аутентифицирующего числа, вычисленного в HLR; если они согласованы, то происходит обновление SSD на стороне терминала пользователя, в противном случае SSD-обновление не происходит.