Процедура аутентификации и согласования ключей

Целью процедуры аутентификации и согласования ключей (Authentication and Key Agreement – AKA) является выполнение взаимной аутентификации между пользовательским терминалом и сетью, а также генерация ключа функции безопасности KSEAF (см. Рис. 7). Единожды сгенерированный ключ KSEAF, может использоваться для формирования нескольких контекстов безопасности, в т.ч. для 3GPP и non-3GPP доступа.
Release 15 3GPP определяет два обязательных метода процедуры аутентификации и согласования ключей – EPS-AKA' и 5G-AKA, которые будут рассмотрены ниже.
В рамках обоих методов вызывается функция деривации (KDF), которая на основании управляющей строки символов осуществляет преобразование криптографического ключа. В состав управляющей строки символов может входить имя обслуживающей абонента гостевой сети (Serving Network Name – SN-name). В частности, SN-name используется при вычислении:
- ключа функции безопасности KSEAF;
- отклика аутентификации (RES*, XRES*);
- промежуточных ключей CK’ и IK’.
SN-name конструируется путем объединения сервисного кода (service code ="5G") и идентификатора гостевой сети, которая аутентифицирует пользователя (network identifier или SN Id). SN Id вычисляется на основе мобильного кода страны (MCC) и мобильного кода сети (MNC) – см. Рис. 3.
Network identifier или SN Id

Рис. 3 (network identifier или SN Id)

Использование имени обслуживающей сети (SN-name) позволяет однозначно привязывать результаты работы криптографических алгоритмов к конкретной гостевой сети.

Инициация и выбор метода аутентификации

В соответствии с политикой безопасности оператора связи функциональный модуль SEAF может инициировать аутентификацию пользовательского терминала (UE) в рамках любой процедуры, предусматривающей установку сигнального соединения с UE, например, при регистрации в сети (attach), либо обновлении зоны слежения (tracking area update). Для "выхода в эфир" UE должен использовать либо скрытый идентификатор SUCI (в случае первичной регистрации в сети), либо 5G-GUTI (в иной ситуации).
Для аутентификации пользовательского терминала SEAF использует ранее созданный и еще незадействованный вектор аутентификации, либо направляет запрос "Authentication Initiation Request" (5G-AIR) в AUSF, устанавливая в качестве идентификатора пользователя SUCI (в случае первичной регистрации в сети), либо SUPI (при получении от UE валидного 5G-GUTI). Запрос аутентификации (5G-AIR), помимо идентификатора пользователя должен также включать в себя тип доступа (3GPP или non-3GPP), а также имя обслуживающей сети (SN-name).
Далее AUSF проверяет правомочность использования имени обслуживающей сети (SN-name) и при успешной проверке – транслирует полученный запрос в блок унифицированной базы данных (UDM), где (при необходимости) функциональным модулем извлечения идентификатора пользователя (SIDF) выполняется расшифровка скрытого идентификатора пользователя (SUCI), после чего репозиторий учетных данных аутентификации (ARPF) осуществляется выбор соответствующего алгоритма аутентификации – 5G-AKA, либо EAP-AKA'.

Метод аутентификации EAP-AKA'

Метод аутентификации EAP-AKA' представляет собой дальнейшее развитие EAP-AKA и вводит новую функцию деривации, обеспечивающую привязку криптографических ключей к имени сети доступа. Запуск метода EAP-AKA', описанного в RFC 5448, осуществляется UDM/ARPF при получении им от AUSF запроса на аутентификацию пользователя (сообщения Authentication Information Request – Auth Info-Req). На Рис. 4 приведена диаграмма, включающая нижеперечисленные шаги.

Метод аутентификации EPS-AKA

Рис. 4 (Метод аутентификации EPS-AKA)

1. Модуль репозитория и обработки учетных данных пользователя (UDM/ARPF) генерирует вектор аутентификации, включающий в себя RAND, AUTN, XRES, CK, IK. Для вычисления вектора аутентификации используются пять односторонних функций f1-f5, реализуемых на основе блокового шифра MILENAGE (в соответствии с 3GPP TS 33.102 – см. Рис. 5) с установленным в значение "1" битом AMF. При вычислении f1-f5 используется 128-ми битное поле конфигурирования алгоритма – OP (operator-variant algorithm configuration field). OP позволяет сделать уникальную (секретную) реализацию алгоритма для каждого оператора. Значение OP (либо OPc, вычисляемое из OP и KI через функцию блочного шифрования) должно храниться в ARPF и на USIM пользователя.

Вектор аутентификации

Рис. 5 (Вектор аутентификации)

2. UDM/ARPF посредством функции деривации и с использованием имени обслуживающей сети (SN-name) вычисляет "привязанные" значения CK', IK' и передает вектор (RAND, AUTN, XRES, CK', IK') серверу аутентификации (AUSF) от которого был получен запрос.
3. AUSF запускает криптографическую функцию PRF метода EAP-AKA', описанную в RFC5448. Входными параметрами функции являются ключи CK' и IK', а также имя обслуживающей сети (SN-name). На выходе функции получаются следующие поля:
- K_encr – ключ (128 бит), используемый для шифрования отдельных атрибутов сообщений EAP-AKA' (в соответствии с политикой безопасности оператора связи);
- K_aut – ключ (256 бит), используемый для вычисления кодов контроля целостности сообщений EAP-AKA' (MAC – Message Authentication Code);
- K_re – ключ (256 бит), используемый при реаутентификации;
- MSK (Master Session Key) – мастер ключ (512 бит);
- EMSK (Extended Master Session Key) – расширенный мастер ключ (512 бит).
4. AUSF посылает якорной функции безопасности (SEAF) запрос EAP-Request/AKA'-Challenge, который далее прозрачно транслируется пользовательскому терминалу в NAS-сообщении. EAP-Request/AKA'-Challenge содержит следующие атрибуты:
- AT_RAND (случайное число);
- AT_AUTN (токен аутентификации);
- AT_KDF (идентификатор используемой функции деривации, где 1 – соответствует использованию функции деривации по умолчанию);
- AT_KDF_INPUT (имя обслуживающей сети – SN-name);
- AT_MAC (код контроля целостности сообщения – Message Authentication Code).
5. Пользовательский терминал:
- вычисляет значения XMAC, RES, CK' и IK';
- запускает криптографическую функцию PRF алгоритма EAP-AKA' (аналогичную функции, выполняемой сервером аутентификации);
- проверяет корректность кода контроля целостности сообщения (атрибут AT_MAC);
- проверяет установку бита AMF атрибута AT_AUTN в значение "1";
- выполняет аутентификацию сети путем сравнения вычисленного и принятого значений AUTN;
- посылает якорной функции безопасности (SEAF) отклик EAP-Response/AKA'-Challenge с атрибутами AT_RES и AT_MAC, который далее прозрачно транслируется серверу аутентификации (AUSF).
6. AUSF проверяет корректность кода контроля целостности сообщения (атрибут AT_MAC) и выполняет аутентификацию пользовательского терминала, посредством сравнения значений RES и XRES, полученных от UE и ARPF/UDM соответственно.
7. В случае успеха AUSF через якорную функцию безопасности (SEAF) направляет UE отклик EAP-Success. Если политика безопасности оператора связи подразумевает передачу EAP-Success в зашифрованном виде – "protected successful result indications", предварительно выполняется обмен сообщениями нотификации. Также (при необходимости), через вызов функции SIDF выполняется дешифрация скрытого идентификатора (SUCI) и извлечение 5G SUPI.
8. На заключительном шаге ARPF/UDM формирует ключ функции аутентификации KAUSF, в качестве которого используются первые 256 бит расширенного мастер ключа (EMSK). В дальнейшем на основе KAUSF вычисляются ключи шифрования и контроля целостности в соответствии с иерархией криптографических ключей, приведенной на Рис. 7.


Метод аутентификации 5G-AKA

Метод аутентификации 5G-AKA представляет собой дальнейшее развитие EPS-AKA, описанного в рекомендации 3GPP TS 33.401 и применяемого на сетях 4G-LTE. Запуск метода 5G-AKA осуществляется UDM/ARPF при получении им от AUSF запроса на аутентификацию пользователя (сообщения Authentication Information Request – Auth Info-Req). На Рис. 6 приведена диаграмма, включающая в себя нижеперечисленные шаги.

Метод аутентификации 5G-AKA

Рис. 6 (Метод аутентификации 5G-AKA)

1. По аналогии с алгоритмом EAP-AKA' модуль репозитория и обработки учетных данных пользователя (UDM/ARPF) на основе блокового шифра MILENAGE генерирует вектор аутентификации, включающий в себя RAND, AUTN, XRES, CK, IK (бит AMF должен быть установлен в единицу).
2. UDM/ARPF посредством функции деривации и с использованием имени обслуживающей сети (SN-name) вычисляет:
- привязанное значение ожидаемого отклика XRES*,
- значение ключа функции аутентификации KAUSF,
формирует вектор "5G HE AV" (Home Environment Authentication Vector), включающий в себя RAND, AUTN, XRES*, KAUSF и направляет его серверу аутентификации (AUSF).
3. AUSF вычисляет:
- значение HXRES*, представляющего собой усеченный до 128-ми бит хэш от конкатенации ожидаемого отклика аутентификации XRES* и случайного числа RAND: HXRES*  младшие 128 бит от SHA-256[RAND || XRES*];
- значение ключа функции безопасности KSEAF.
Далее AUSF формирует вектор "5G AV" (5G Authentication Vector), включающий в себя RAND, AUTN, HXRES*, KSEAF и направляет его якорной функции безопасности (SEAF) посредством сообщения 5G-AIA (Authentication Initiation Answer). В случае, если запрос на аутентификацию (5G-AIR) содержал скрытый идентификатор пользователя (SUCI), AUSF через вызов функции SIDF, получает 5G SUPI и добавляет его в 5G-AIA.
4. SEAF осуществляет контроль таймера времени жизни полученного вектора и направляет пользовательскому терминалу NAS сообщение Auth-Req с включенными параметрами RAND и AUTN.
5. Пользовательский терминал:
- через вызов соответствующих функций USIM модуля вычисляет значения RES, AUTN, CK, IK;
- выполняет аутентификацию сети путем сравнения вычисленного и принятого значений AUTN;
- вычисляет значения ключей KAUSF и KSEAF;
- вычисляет привязанное значение отклика аутентификации RES*;
- направляет якорной функции безопасности (SEAF) сообщение Auth-Resp, содержащее RES*.
6. SEAF вычисляет хэш HRES* (по аналогии с AUSF) и осуществляет аутентификацию пользовательского терминала посредством сравнения HRES* и HXRES*.
7. При успешной аутентификации SEAF направляет AUSF сообщение подтверждения 5G-AC (Authentication Confirmation), содержащее в т.ч. значение отклика RES*, полученное от UE. Данный шаг является опциональным и может не использоваться при регистрации пользователя в домашней сети.
8. AUSF осуществляет проверку таймера времени жизни вектора аутентификации, сравнивает значения вычисленного (XRES*) и полученного (RES*) откликов, после чего завершает процедуру аутентификации.
3GPP рекомендует в рамках одной процедуры аутентификации генерировать и использовать только один вектор. Это позволит завершать каждую процедуру аутентификации сообщением подтверждения.