Безопасность – это фундаментальное требование мобильной сети любого стандарта (и IMS в этом случае не является исключением).
Структура безопасности VoLTE включает в себя четыре блока:
1. Блок безопасности на уровне доступа (сети LTE). Обеспечивает:
- аутентификацию пользователя сетью,
- аутентификацию сети пользователем,
- шифрование и контроль целостности сигнального трафика NAS и RRC,
- шифрование и контроль целостности пользовательского трафика на PDCP уровне,
а также защиту каналов связи между ядром сети и базовыми станциями (интерфейсы S1-MME, S1-U) посредством IPSec.
2. Блок безопасности на уровне сети IMS. Обеспечивает:
- аутентификацию пользователя сетью,
- шифрование и контроль целостности сигнального трафика между пользовательским терминалом (UE) и прокси сервером (PCSCF) – на уровне интерфейса Gm;
- скрытие сетевой топологии.
3. Блок архитектуры начальной загрузки (Generic Bootstrapping Architecture – GBA, 3GPP TS 3220). Обеспечивает аутентификацию пользователя на сетевом приложении (NAF) и последующее шифрование трафика между пользовательским терминалом (UE) и сетевым приложением (NAF).
4. Блок сетевой безопасности (Network Domain Security – NDS, 3GPP TS 33.210). Обеспечивает:
- защиту интерфейса между HSS и CSCF (Cx), используемого для передачи секретных ключей пользователей, генерируемых в рамках AKA процедуры,
- защиту связанности между элементами IMS сети,
- защиту связанности между PCSCF, размещенным в гостевой сети и I/SCSCF домашней сети,
- скрытие сетевой топологии.
Архитектура безопасности сети LTE
В основе обеспечения безопасности в сетях LTE лежит механизм, при котором необходимые секретные ключи вычисляются непосредственно перед каждой операцией и изменяются от сеанса к сеансу. По сравнению с сетями GSM в сетях LTE (также, как и native UMTS) реализуется протокол взаимной аутентификации, т.е. дополнительно к проверке обслуживающей сетью идентичности абонента выполняется процедура проверки терминалом легитимности обслуживающей сети. Также относительно новым аспектом безопасности в сетях LTE (также, как и native UMTS) является механизм контроля целостности (integrity protection). Данный механизм позволяет осуществить проверку идентичности отправителя сигнальных сообщения.
Рис. 24:
Механизм взаимной аутентификации основан на совместном использовании мастер-ключа (KI), длиной 128 бит абонентским модулем (USIM) и базой данных домашней сети (HSS/AUC). Процедура аутентификации приведена на рисунке ниже.
Рис. 25:
На первом шаге MME посылает запрос в центр аутентификации HSS/AUC домашней сети, который содержит базу мастер-ключей пользователей и может генерировать векторы аутентификации. Процесс генерации вектора начинается с установки порядкового номера SQN (Sequence Number), который должен выбираться в возрастающем порядке и показывает пользователю, что генерированный вектор аутентификации является "свежим" и не использовался ранее.
Алгоритм MILENAGE
Для вычисления вектора аутентификации используются пять односторонних функций f1-f5, реализуемых на основе блокового шифра MILENAGE. Выбор типа генерируемого вектора (UMTS AV или EPS AV) осуществляется на основе старшего бита поля AMF (Authentication management field) – "AMF separation bit". При значении равным "1" генерируется EPS AV при значении, равном "0" – UMTS AV.
Рис. 26 (схема генерирования векторов аутентификации в HSS):
Рис. 27 (схема аутентификации в абонентском модуле USIM):
Длины различных элементов:
- ключ KI – 128 бит;
- случайное число RAND – 128 бит;
- номер последовательности SQN – 48 бит;
- анонимный ключ AK (anonymity key) – 48 бит;
- поле управления аутентификацией AMF (authentication management field) – 16 бит;
- код сообщения аутентификации MAC (message authentication code) – 64 бит;
- ключ шифрования CK (cipher key) – 128 бит;
- ключ контроля целостности IK (integrity key) – 128 бит;
- маркер аутентификации AUTN (authentication token – 128 бит;
- ключ управления защитой доступа KASME (access security management entity) – 256 бит;
- отклик аутентификации RES (authentication response) – 416 октетов.
Алгоритм MILENAGE использует следующие компоненты:
- функцию блокового шифрования, которая преобразует 128ми битное входное значение в 128-ми битное выходное значение с применением 128-ми битного ключа;
- 128ми битное поле конфигурирования алгоритма – OP (operatorvariant algorithm configuration field). OP позволяет сделать уникальную (секретную) реализацию алгоритма для каждого оператора.
Структурная схема алгоритма приведена на рисунке ниже.
Рис. 28:
Здесь:
- rotate by ri– функция циклического сдвига на ri позиций;
- Ek – функция блокового шифра;
- с1, с2, с3, с4, с5 – 128ми битные константы, используемые при выполнении операций "исключающих ИЛИ" (XOR) в структуре алгоритма;
- r1, r2, r3, r4, r5 – целые числа в диапазоне 0127, используемые для задания величины сдвига в структуре алгоритма;
- OPc – 128ми битное значение, вычисляемое из OP и KI через функцию блочного шифрования.
Определены две возможности вычисления и хранения значения OPc на USIM:
- хранение на USIM непосредственно OPc (рекомендуется);
- хранение на USIM OP и вычисление значения OPc в процессе работы алгоритма.
Для проверки легитимности обслуживающей сети в абонентском модуле USIM посредством функции f1 производится вычисление значения поля XMAC, которое сравнивается с кодом аутентификации MAC, полученным из сети как часть параметра AUTN в составе вектора аутентификации. Если они совпадают (и кроме того, произошло обновление значения SQN), то идентичность запроса подтверждается.
Для проверки идентичности абонента в MME посредством функции f2 производится вычисление значения поля XRES, которое сравнивается с полем RES, полученным от абонента. Если они совпадают, то идентичность абонента подтверждается.
На основании параметра KASME в абонентском терминале (UE), базовой станции (eNodeB) и MME посредством криптографической функции KDF (Key Derivation Function) рассчитываются ключи KeNB, KNASint, KNASenc, KUPinc, KUPenc, KRRCinc, KRRCenc, используемые для защиты (шифрования и контроля целостности) пользовательского и сигнального трафика. Длины ключей составляют 128 бит.
Иерархия ключей приведена на рисунке ниже.
KeNB – промежуточный ключ, используемый для вычисления ключей шифрования и контроля целостности пользовательского трафика и RRC сигнального трафика (KUPint, KUPenc, KRRCint, KRRCenc).
Ключи для защиты NAS сигнального трафика:
- KNASint – ключ, используемый для контроля целостности NAS сигнального трафика; вычисляется абонентским терминалом (UE) и MME из KASME.
- KNASenc – ключ, используемый для шифрования NAS сигнального трафика; вычисляется абонентским терминалом (UE) и MME из KASME.
Ключи для защиты RRC сигнального трафика:
- KRRCint – ключ, используемый для контроля целостности RRC сигнального трафика; вычисляется абонентским терминалом (UE) и базовой станцией (eNodeB) из KeNB.
- KRRCenc – ключ, используемый для шифрования RRC сигнального трафика; вычисляется абонентским терминалом (UE) и базовой станцией (eNodeB) из KeNB.
Ключи для защиты пользовательского трафика
- KUPint – ключ, используемый для контроля целостности пользовательского трафика; вычисляется абонентским терминалом (UE) и базовой станцией (eNodeB) из KeNB.
- KUPenc – ключ, используемый для шифрования пользовательского трафика; вычисляется абонентским терминалом (UE) и базовой станцией (eNodeB) из KeNB.
Перед началом шифрования трафика и контроля целостности между сетью и абонентским терминалом (UE) происходит согласование поддерживаемых алгоритмов. Определены два обязательных алгоритма:
- 128EEA1 и 128-EIA1 – на основе SNOW 3G,
- 128EEA2 и 128-EIA2 – на основе AES,
а также 128-EEA0 и 128-EIA0 – отсутствие шифрования и контроля целостности.
Согласование алгоритмов осуществляется между абонентским терминалом и базовой станцией (AS уровень), а также между абонентским терминалом и MME (NAS уровень).
Модуль шифрования
Структурная схема модуля шифрования трафика приведена на рисунке ниже.
Рис. 30:
Входными данными модуля служат:
- 128ми битный ключ KEY (KNASenc или KRRCenc);
- 32х битный счетчик (COUNT);
- 5ти битный идентификатор виртуального соединения (BEARER);
- идентификатор направления (DIRECTION: 0 – uplink. 1 downlink);
- длина блока (LENGTH).
Модуль контроля целостности
Структурная схема модуля контроля целостности приведена на рисунке ниже.
Рис. 31:
Входными данными модуля служат:
- 128ми битный ключ KEY (KNASint или KRRCint);
- 32х битный счетчик (COUNT);
- 5ти битный идентификатор виртуального соединения (BEARER);
- идентификатор направления (DIRECTION: 0 – uplink. 1 downlink);
- Сигнальное сообщение (MESSAGE).
Алгоритм вычисляет 32-х битный аутентификационный код (MAC-I/NAS-MAC или XMAC-I/XNAS-MAC), который добавляется к передаваемому сообщению на исходящей стороне. Приемная сторона в свою очередь также вычисляет аутентификационный код, сравнивает его с принятым кодом и принимает решение о достоверности сообщения.
Детальную информацию можно подчерпнуть в спецификациях 3GPP TS 33.401, TS 33.220, TR 35.909.
Архитектура безопасности сети IMS
В IMS используется схема аутентификации и согласования ключей IMS AKA, реализуемая в рамках процедуры SIP регистрации (см. рисунок ниже).
Рис. 32:
По аналогии с EPS AKA используется алгоритм MILENAGE:
- На шаге 2 процедуры SIP регистрации HSS/AuC вычисляет вектор аутентификации, включающий 5 полей RAND, XRES, CK, IK и AUTN.
- На шаге 3c PCSCF передает в пользовательский терминал сообщение "401 (Unauthorized)", включающее поля RAND и AUTN вектора аутентификации.
- На шаге 4 в модуле ISIM/USIM пользовательского терминала происходит вычисление полей RES, CK, IK и XMAC. Далее XMAC используется для аутентификации пользовательским терминалом сети (посредством сравнения XMAC и MAC поля AUTN). RES передается на SCSCF через P/ICSCF в повторном сообщении REGISTER (шаг 6).
- На шаге 7 сервером SCSCF выполняется аутентификация пользователя посредством сравнения поля RES, полученного от UE, с полем XRES, вычисленным HSS/AuC. При их совпадении аутентификация считается успешно пройденной.
В соответствии с политикой безопасности оператора связи на сети IMS может быть реализована защита сигнального SIP трафика с использованием протокола IPSec ESP, определенного в RFC 4303. С этой целью на шаге 5 процедуры SIP регистрации между P-CSCF и UE устанавливаются четыре однонаправленные ассоциации (security associations SAs). Две ассоциации с единым 128-ми битным ключом CKESP, соответствующим ключу CK, генерируемому на этапе процедуры IMS-AKA, используются для шифрования сигнального SIP трафика. Еще две ассоциации с единым 160-ти битным ключом IKESP используются для контроля целостности SIP сообщений. IKESP рассчитывается из 128-ми битного ключа IK, генерируемому на этапе процедуры IMS-AKA, дополнив его нулевыми битами.
Также в соответствии с политикой безопасности оператора связи на сети IMS может быть реализован механизм скрытия сетевой топологии. Данный механизм предусматривает шифрование заголовков SIP сообщений, содержащих адреса SIP proxy (Via, Record-Route, Route и Path). Шифрование выполняют узлы I-CSCF/IBCF при отправке SIP запросов или ответов за пределы внутреннего IMS домена. Узлы I-CSCF/IBCF на приемной стороне выполняют дешифрацию. Для скрытия топологии используется алгоритм AES-CBC со 128-ми битным ключом Kv.
Более детально архитектура безопасности сети IMS описана в 3GPP TS 33.203.
Архитектура начальной загрузки
Архитектура начальной загрузки (Generic Bootstrapping Architecture – GBA) используется для безопасного обмена данными между аппликацией, установленной на пользовательском терминале (Ua Application), и сетевым приложением (NAF). GBA также используется для аутентификации пользователя и защиты данных между XCAP клиентом и XCAP сервером в рамках процедур управления абонентом профилем доступных ему услуг через Ut интерфейс (см. раздел "Менеджер дополнительных услуг").
Общая модель архитектуры начальной загрузки приведена на рисунке ниже.
Рис. 33:
Здесь:
- BSF (Bootstrapping Server Function) – сервер начальной загрузки;
- NAF (Network Application Function) – сетевое приложение;
- HSS (Home Subscriber Server) – домашний сервер базы данных пользователей;
- UE (User Equipment) – пользовательский терминал.
Процедура начальной загрузки инициируется пользовательским терминалом посредством http запроса к серверу начальной загрузки (BSF) – см. рисунок ниже. При этом процедура аутентификации и согласования ключей (HTTP AKA) выполняется в соответствии со спецификациями 3GPP TS 33.102 и RFC 3310 и в целом схожа с процедурами EPS-AKS и IMS-AKA. В качестве имени пользователя используется временный частный идентификатор пользователя (Temporary IP Multimedia Private Identity – TMPI) или частный идентификатор пользователя (PrUI).
Рис. 34:
По завершении процедуры начальной загрузки пользовательский терминал (UE) и сетевое приложение могут обмениваться сообщениями – см. рисунок ниже.
Рис. 35:
Здесь:
- BTID (Bootstrapping Transaction Identifier) – идентификатор транзакции начальной загрузки, используется для привязки идентификатора пользователя к контексту безопасности. Вычисляется на основании случайного числа RAND, сгенерированного HSS в ходе процедуры AKA и преобразованного в текстовый формат посредством кодировки base64 и имени BSF сервера:
base64encode(RAND)@BSF_servers_domain_name.
- Ks – секретный ключ, вычисляемый путем объединения параметров CK и IK, и в свою очередь используемый для расчета ключа безопасности Ks_NAF посредством криптографической функции KDF. Секретный ключ Ks_NAF в дальнейшем будет использоваться для обеспечения безопасности интерфейса Ua.
- lifetime – время жизни ключа безопасности.
- NAF_Id – идентификатор функции NAF. Содержит полное DNSимя функции NAF и идентификатор безопасности протокола Ua (см. Annex H 3GPP TS 33.220).
- Prof – специфичные для конкретного NAF данные пользовательского профиля.
- Msg – специфичный для конкретного NAF набор данных.
Детально архитектура безопасности сети IMS описана в 3GPP TS 33.220.
Архитектура доменов сетевой безопасности
Архитектура доменов сетевой безопасности подразумевает обеспечение защиты интерфейсов между различными доменами безопасности, а также (в зависимости от политики оператора связи) интерфейсов, используемых для передачи секретных ключей внутри одного домена. С этой целью спецификация 3GPP TS 33.210 вводит следующие сетевые интерфейсы:
- Za – интерфейс между шлюзами безопасности (SEGs), принадлежащими различным доменам безопасности. На Za интерфейсе аутентификация и контроль целостности должны применяться в обязательном порядке, использование шифрования – опционально.
- Zb – интерфейс между шлюзами безопасности (SEGs) и сетевыми элементами (NEs), а также между сетевыми элементами (NEs) одного домена безопасности. Если оператор использует на своей сети Zb интерфейс, то должны применяться аутентификация и контроль целостности, а также (опционально) может применяться шифрование.
Здесь: Security Gateways (SEGs), шлюзы безопасности – представляют собой объекты, размещаемые на границах доменов безопасности и обеспечивающие защиту IP трафика, передаваемого между различными доменами.
Для аутентификации, контроля целостности и шифрования должен использоваться IPSec ESP (Encapsulating Security Payload). Для управления ключами безопасности, установления и поддержания ESP туннеля должен использоваться Internet Key Exchange Internet Key Exchange (IKEv2).
Реализация концепции безопасности сетевого домена для IMS сети приведена на рисунках ниже.
Рис. 36 (P-CSCF – в гостевой сети):
Рис. 37 (P-CSCF – в домашней сети):
Детально архитектура безопасности сетевого домена описана в 3GPP TS 33.210, а также в 3GPP TS 33.203.