Продолжение. Часть 1 здесь, часть 2 здесь.

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

* * *

Архитектура безопасности в UMTS несколько улучшена относительно состояния безопасности в GSM (которая, как было показано в предыдущей публикации, не может похвастаться хорошей защитой от атак).

В UMTS улучшена защита от известных типов атак, таких как «ложная базовая станция» (false base station), «человек посередине» MitM (man-in-the-middle), а также атак повторения (replay attack). В UMTS также усовершенствована конфиденциальность данных пользователя и целостность данных сигнализации.

Однако, в UMTS были обнаружены некоторые новые уязвимости[1]. Например, в процессе установки сессии передачи данных перед выдачей команды о режиме безопасности, происходит модификация исходных сообщений. Это даёт возможность проводить атаки типа «отказ в обслуживании DoS, и «человек посередине» (man-in-the middle). Защита от нарушения целостности сообщения rrcConnectionReject, может также давать возможность организовывать DoS-атаки. Открытая передача IMSI может приводить к нарушению конфиденциальности пользователя и возможности определения его местоположения, а также к последующему отслеживанию потока всего трафика его данных. В дальнейшем открытая передача IMSI может использоваться и для других новых атак.

Возможности для возникновения уязвимостей 3G UMTS

1.      Включение мобильного устройства МЕ

При начальном включении мобильного оборудования абонента UMTS ME (Mobile Equipment), оно ищет базовую станцию UMTS (NodeB) с наивысшим уровнем сигнала и пытается к ней подключиться. Вначале выполняется процедура коррекции местоположения (Location Update Procedure), при которой может быть затребован международный идентификатор IMSI оборудования (International Mobile Subscriber Identity). Это может быть процедура нормальной коррекции местоположения (Normal Location Update), или периодической коррекции местоположения (Periodic Location Update)[2]. Эти процедуры начинаются с запроса подключения к радиоресурсу (Radio Resource Control RRC Connection Request, rrcConnectionRequest), который МЕ посылает на базовую станцию Node-B (операция 1 на рис. 4).

Выделенного канала для МЕ пока нет, поэтому запрос rrcConnectionRequest посылается через общий логический канал управления (Common Logical Control Channel), который размещается в случайно выбранном физическом канале для подключения к контроллеру радиосети RNC (Radio Network Controller).

Рис. 1. Процедура начального подключения мобильного оборудования абонента UMTS ME (Mobile Equipment).

Кроме прочего, rrcConnectionRequest содержит IMSI в явном виде, поэтому, как показано на рис. 4, это является уязвимостью для конфиденциальности данных пользователя.

2.      Процедура аутентификации и согласования ключей AKA (Authentication and Key Agreement)

После запроса rrcConnectionRequest выполняется процедура аутентификации и согласования ключей AKA (Authentication and Key Agreement). AKA одновременно обеспечивает двунаправленную аутентификацию, как для сети, так и для МЕ. Процедура начинается с запроса данных аутентификации от гостевого регистра местоположения VLR (Visitor Location Register), с узлом поддержки GPRS SGSN (Serving GPRS Support Node). VLR/SGSN передаёт IMSI из USIM (Universal Subscriber Identity Module) на домашний регистр местоположения с центром аутентификации HLR/AuC (Home Location Register/Authentication Center), чтобы убедиться в том, что МЕ действительно там зарегистрировано (операция 2 на рис. 1).

IMSI и ключ К предварительно доступны между USIM и HLR. На основе IMSI, в HLR генерируются пять векторов аутентификации AV (Authentication Vectors), которые передаются на VLR/SGSN (операция 3 на рис. 4). VLR/SGSN, в соответствии с одним из векторов, выбирает случайное число RAND и токен аутентификации (AUTN) и передаёт их на ME (операция 4 на рис. 1).

После этого ME по AUTN вычисляет ожидаемый код аутентификации X-MAC (Expected Message Authentication Code). Если МАС и Х-МАС совпадают, то есть, номер последовательности SQN (Sequence Number) находится в заданных пределах, то сеть считается аутентифицированной.

Одновременно ME вычисляет ответный код (RES) и посылает его на VLR/SGSN VLR/SGSN сравнивает код ответа RES с ожидаемым кодом X-RES (Expected Response), после этого пользователь считается аутентифицированным.

Затем VLR/SGSN передаёт цифровой ключ CK (Ciphering Key) и ключ целостности IK (Integrity Key) в контроллер радиосети RNC (Radio Network Controller), (операция 6 на рис. 1).

Только после этого этапа ME и RNC получают соответствующие друг другу ключи для шифрования и защиты целостности данных.

Следует отметить, что сообщения с 1 по 6 на рис. 1 не шифруются и их целостность не защищена, потому что они передаются до согласования ключей. Эти сообщения передаются по радио-интерфейсу Uu между ME и Node-B, и, следовательно, их можно перехватить или изменить. В частности, этот путь может быть использован злоумышленником для DoS-атаки на пользователя.

3.      Процедура установки режима безопасности  

Рис. 2. Процедура установки режима безопасности с шифрованием данных для защиты целостности данных.

Команда режима безопасности (Security Mode) выдаётся RNC для начала шифрования и защиты целостности данных на МЕ. Процедура показана на рис. 2.

Эта процедура обязательна для каждого нового подключения для начала защиты целостности данных сигнализации. RNC теперь обладает обеими версиями параметров безопасности, поддерживаемых ME и VLR/SGSN. RNC выбирает общие алгоритмы с наивысшим приоритетом и передаёт их в ME, как показано в сообщении 8 на рис. 2.

Следует отметить, что это самое первое сообщение, целостность которого защищена. До этого обмен сообщениями и командами проводился без защиты целостности данных. Сообщение содержит параметры безопасности, ранее переданные в МЕ, для снижения возможности намеренного или случайного изменения начальных параметров безопасности МЕ.  После верификации MAC-I, на RNC посылается подтверждение, который затем то же самое передаёт в VLR/SGSN (сообщения 10 и 11 на рис. 2).

Только после этого коммуникацию между ME и RNC можно считать безопасной.

Функция конфиденциальности f8 используется для шифрования данных трафика пользователя, в то время как функция f9 используется для защиты целостности данных сигнализации. Эти функции используются в USIM и RNC. Алгоритм Kasumi стандартизован для обеих этих функций[3].

В различных исследованиях была подтверждена адекватная безопасность алгоритма и функций f8 и f9 [4].

Угрозы для доступа МЕ к сети UMTS на радиоинтерфейсе

Радиоинтерфейс UMTS – это наиболее уязвимая часть соединения МЕ с сетью UMTS, которую наиболее сложно защитить.

3GPP различает следующие угрозы для связи UMTS [5]:

• Подслушивание (eavesdropping)
• Подмена пользователя (User impersonation)
• Подмена сети (network impersonation), в комбинированных сетях UMTS/GSM
• Атака «человек посередине» (man-in-the-middle)
• Компрометация вектора аутентификации в сети (compromising authentication vector).

Идентифицированные уязвимости в сети UMTS

Утечка идентификатора пользователя

UMTS не имеет достаточной защиты от перехвата идентификатора пользователя. Хотя уникальный IMSI пользователя заменяется на временные идентификаторы TMSI после запроса на подключение, IMSI передаётся в явном виде при запросе rrcConnectionRequest во время первого появления МЕ в сети, а также в случае сбоя базы данных в VLR сети обслуживания. Запрос rrcConnectionRequest посылается через общий канал сети радиодоступа (хотя и случайно выбранный), однако, перехватить это сообщение можно довольно легко.

В UMTS можно использовать те же самые перехватчики IMSI (IMSI Catcher), которые используются в сети GSM, как спецслужбами, так и злоумышленниками[6].

Кроме того, некоторые устройства отладки и тестирования сетей UMTS, например Air Protocol Analyzer AP-6000 и Protocol Tester K1297-G20 также имеют возможность запрашивать и перехватывать IMSI. Есть сообщения, что полиция может перехватывать IMSI при помощи простых программ[7].

Поэтому определить пользователя и его местоположение при помощи таких средств сравнительно просто.

Атака «отказ в обслуживании» для пользователя (User Specific DoS)

Такая атака может быть проведена путём модификации параметров безопасности или параметров аутентификации ME. Атака проводится в две фазы. Вначале злоумышленник получает IMSI, как было описано выше. Затем злоумышленник ждёт, когда МЕ жертвы выдаст запрос rrcConnectionRequest. После этого сообщение 1 на рисунке 2, которое содержит параметры безопасности, модифицируется, поскольку на этом этапе целостность данных ещё не защищается (шифрование устанавливается позднее). После доставки команды Security Mode (сообщение 8 на рис. 2), в случае несоответствия параметров безопасности МЕ и параметров сети, соединение сбрасывается, и процедура сообщений с 1 по 8 начинается снова. Это приводит к росту потребления полосы пропускания в радиоканале и вычислительных ресурсов МЕ.

Модификация параметров аутентификации AUTN, RAND, или RES (сообщения 4 и 5 на рис. 1) также даёт возможность проведения DoS-атаки на МЕ, поскольку на этом этапе сообщение не зашифрованы, и они могут быть модифицированы. Любые их изменения приводят к тому, что МЕ не будет аутентифицировано в сети. В любом случае, сеть сама по себе не сможет распознать наличие DoS-атаки.

Атака «отказ в обслуживании» с использованием сообщения rrcConnectionReject

Это также атака на пользователя (user specific DoS). После получения IMSI легального пользователя злоумышленником, он также ждёт получения запроса rrcConnectionRequest. Начальным идентификатором пользователя может быть не только IMSI, но и TMSI (Temporary Mobile Subscriber Identity), а также P-TMSI (Packet Temporary Mobile Subscriber Identity), или IMEI (International Mobile Equipment Identity).

Обычно первое сообщение rrcConnectionRequest содержит IMSI пользователя, в ответ злоумышленник посылает на МЕ сообщение отказа в соединении rrcConnectionReject. Целостность этого сообщения в стандарте 3GPP также не защищается[8]. Его правильность можно распознать только сравнением значения «Initial UE identity» в полученном сообщении rrcConnectionReject со значением переменной “INITIAL_UE_IDENTITY”, имеющейся в МЕ (UE). Если значения не совпадает, то UE должно отвергнуть сообщение и разорвать соединение[9].

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

Атака «отказ в обслуживании» с перегрузкой HLR/AuC оператора

Это более опасная атака, чем DoS-атака на пользователя, поскольку при этом может быть парализована работа всей сети оператора.

Атака проводится в две фазы.

Фаза 1. Злоумышленник создаёт базу данных идентификаторов IMSI, которые находятся в HLR домашнего оператора, по вышеописанной процедуре перехвата IMSI. В IMSI содержатся разряды, по которым можно идентифицировать домашнего оператора[10].

Фаза 2. Злоумышленник быстро генерирует сообщения rrcConnectionRequest, соответствующие каждому IMSI в созданной в Фазе 1 базе, при помощи скрипта автоматизации. В ответ на каждый запрос на подключение (кроме уже установленных), VLR/SGSN посылает IMSI на HLR/AuC (сообщение 2 на рис. 4). HLR/AuC проверяет соответствие каждого IMSI. Поскольку все IMSI – правильные, то проверка заканчивается положительно. После этого HLR рассчитывает пять векторов аутентификации для каждого IMSI. Этот процесс занимает время и ресурсы, поскольку требует расчёта RAND, MAC, XRES, CK, IK, и AK для каждого IMSI. Рассчитанные векторы посылаются на VLR/SGSN (сообщение 3 на рис. 1). Для каждого IMSI, VLR/SGSN выбирает один вектор аутентификации AV и посылает RAND и AUTN для аутентификации. Злоумышленника распознать пока нельзя, поскольку он не может рассчитать ответное сообщение RES без знания секретного ключа USIM. Но это ему и не нужно, поскольку его цель – лишь парализовать работу оператора, при помощи перегрузки вычислительных ресурсов HLR/AuC путём посылки всё большего числа сообщений rrcConnectionRequest, которые порождают вычисления всё большее число векторов аутентификации AV. При этом может также исчерпаться доступная полоса пропускания VLR/SGSN. Как следствие исчерпания ресурсов, пользователи будет вынуждены посылать запросы rrcConnectionRequest с IMSI в явном виде, что будет приводить к дальнейшему пополнению базы данных злоумышленника.

Подмена сети UMTS (Network Impersonation)

Это атака, аналогичная подмене базовой станции в сети GSM. Сценарий такой атаки следующий. Злоумышленник выдаёт своё устройство как реальную базовую станцию GSM для пользователя UMTS, а также для сетевых устройств UMTS. При этом, устройство пользователя UMTS (МЕ), которое имеет возможность подключаться как к GSM, так и к UMTS, будет посылать в сеть свои параметры безопасности. Затем эти параметры модифицируются злоумышленником, поскольку, как было показано выше, в процессе аутентификации АКА сообщения ещё не зашифрованы. Процедура UMTS AKA, как было показано выше, выполняется после получения параметров безопасности МЕ пользователя между ME, VLR/SGSN и HLR/AuC.

Ключ шифрования GSM Kc (cipher key), а также ключи CK и IK данных будут посланы на подменную базовую станцию GSM, а она будет посылать их в сеть от имени легального пользователя[11]. После этого, VLR/SGSN выдаст команду установки режима безопасности в соответствии с данными от подменной базовой станции, а не в соответствии с параметрами безопасности МЕ легального пользователя. При этом злоумышленник сможет выставлять алгоритмы шифрования по своему выбору. Ранее уже упоминалось, что алгоритмы GFSM A5/1 и A5/2 могут быть легко расшифрованы и изменены.

Защита целостности данных пользователя

Криптографическая защита данных пользователя выполняется только в ограниченной части системы UMTS. Причём, защищены только данные сигнализации на участке между контроллером радиосети RNC и устройством пользователя. Таким образом, целостность данных пользователя не защищена. Это может повлиять, например, на защиту данных банковских транзакций.

Уязвимость при нахождении мобильного устройства ME UMTS при подключении к базовой станции GSM в сети UMTS

При подключении к сети для мобильного устройства UMTS возможен вариант подключения к базовой станции GSM BTS, которая находится под управлением MSC UMTS. Как показано на рис. 6, мобильное устройство UMTS запрашивает безопасное подключение к базовой станции GSM BTS (1). Соответственно, центр мобильной коммутации MSC UMTS запрашивает вектор аутентификации UMTS RAND, XRES, CK, IK, AUTN) от центра аутентификации AuC домашней сети UMTS (2). Затем UMTS MSC получает вектор аутентификации от AuC (3) и генерирует ключ Кс для абонента GSM и передаёт его на базовую станцию GSM (4). Базовая станция GSM выполняет протокол аутентификации GSM с пользователем UMTS (5).

После этого МЕ UMTS и GSM BTS коммуницируют друг с другом с использованием алгоритмов шифрования GSM с ключом Кс.

Рис. 3. Аутентификация MЕ UMTS через базовую станцию GSM.

Такое подключение может создаваться либо при первой аутентификации в сети, либо при хэндовере от базовой станции UMTS на базовую станцию GSM. Единственным сетевым устройством, которое использует протоколы GSM в этом случае, будет базовая станция. MSC, мобильное устройство и AUC принадлежат к сети UMTS. MSC будет сохранять CK и IK, сгенерированные при аутентификации UMTS, но всё шифрование между мобильным устройством и базово станцией GSM выполняет при помощи ключа шифрования по контексту GSM. Kc создаётся мобильным устройством и UMTS MSC, а GSM BTS не участвует в этом процессе.

Коммуникация между мобильным устройством и базовой станцией может рассматриваться как безопасная, поскольку это обычная коммуникация GSM. При перемещении в другую сетевую конфигурацию MSC будет использовать CK и IK, которые были сгенерированы вместо Kc, который обычно генерируется базовой станцией. Однако, как показано выше, Kc может быть скомпрометирован во время коммуникации с базовой станцией по радиоканалу, поскольку состоит только из 64 битов.

Уязвимость при нахождении мобильного устройства ME UMTS при подключении к базовой станции GSM с MSC GSM в сети UMTS

Рис 4. Подключение мобильного устройства ME UMTS к базовой станции GSM с MSC GSM в сети UMTS

На рисунке 4 показан другой сценарий подключения мобильного устройства UMTS к базовой станции GSM, которая взаимодействует с центром мобильной коммутации MSC GSM. MSC GSM запрашивает от домашней сети UMTS вектор аутентификации GSM из триплета RAND, XRES, Kc, который генерируется на основе вектора аутентификации UMTS (RAND, XRES, CK, IK, AUTN). GSM MSC получает вектор аутентификации GSM и посылает ключ Kc на базовую станцию GSM BTS. Базовая станция GSM выполняет протокол аутентификации GSM для мобильного устройства UMTS. При успешной аутентификации, устройство UMTS и базовая станция GSM коммуницируют друг с другом с использованием алгоритмов шифрования GSM с ключом Kc.

Такая аутентификация происходит в случае хэндовера, когда сессия аутентификации UMTS перемещается в сеть GSM. Как GSM MSC, так и GSM BTS для коммуникации GSM могут использовать только ключ Kc. Поэтому центр аутентификации UMTS передаёт вычисленный Kc на GSM MSC. Новый Kc будет использоваться для получения CK и IK. При этом снижается безопасность поскольку в Kc будет только 64 бита. Это наихудший случай с самой высокой вероятностью компрометации при подключении устройства UMTS через сеть доступа GSM.

---

[1] Vulnerabilities of UMTS Access Domain Security Architecture Conference Paper · September 2008 DOI: 10.1109/SNPD.2008.78 · Source: IEEE Xplore (https://www.researchgate.net/publication/4371859)

[2] 3GPP TS 35.202 (7.0.0), “3G Security; Specification of the 3GPP confidentiality and integrity algorithms; Document 2: KASUMI specification”, Release 7, June, 2007.

[3] 3GPP TS 35.202 (7.0.0), “3G Security; Specification of the 3GPP confidentiality and integrity algorithms; Document 2: KASUMI specification”, Release 7, June, 2007.

[4] Abdul Bais, Walter T. Penzhorn, Peter Palensky, “Evaluation of UMTS security architecture and services” in proceedings of IEEE International Conference on industrial informatics 2006, стр. 570-575.

[5] 3GPP TR 33.900 (1.2.0), “A Guide to 3G Security” January, 2000.

[6] http://www.binrev.com/forums/index.php?showtopic=28559

[7] https://www.istaunch.com/imei-tracker/

[8] 3GPP TS 25.331 (8.0.0), “Radio Resource Control protocol for the UE-UTRAN radio interface”, Release 8, September, 2007.

[9] 3GPP TS 33.120 (7.5.0), “Technical Specification Group Core Network and Terminals; Numbering, addressing and identification” ,Release7, September, 2007

[10] 3GPP TS 33.120 (7.5.0), “Technical Specification Group Core Network and Terminals; Numbering, addressing and identification”, Release7, September, 2007

[11] 3GPP TS 33.102 (7.1.0), “3G Security; Security Architecture”, Release 7, December, 2006.