Способ и устройство для реализации защиты в беспроводном устройстве lte

Способ и устройство для реализации защиты в беспроводном устройстве lte

Иллюстрации

Показать все

Реферат

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

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

В частности, настоящий способ и устройство относятся к безопасной связи в беспроводном устройстве, соответствующем стандарту Долгосрочной Эволюции (Long Term Evolution, LTE).

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

Текущими целями программы Долгосрочной Эволюции (Long Term Evolution, LTE) Проекта Партнерства 3-го Поколения (Third Generation Partnership Project, 3GPP) является создание новых технологий, архитектуры и методов для новых настроек и конфигураций LTE в целях обеспечения более высокой спектральной эффективности и сокращения задержек для более эффективного использования радиоресурсов, чтобы обеспечить более быстрое взаимодействие с пользователем и более насыщенные приложения и службы при меньшей стоимости.

Как часть этого процесса эволюции группа 3GPP будет использовать в LTE архитектуры безопасности, которые отличаются от соответствующих архитектур безопасности, применяемых в стандартах Универсальной Системы Мобильной Связи (Universal Mobile Telephone System, UMTS) и Глобальной Системы Мобильной Связи (Global System for Mobile Communications, GSM). В целях сравнения, в качестве опорной точки для предлагаемых новых процедур LTE примем процедуры Аутентификации и Согласования Ключа (Authentication and Key Agreement, AKA) UMTS в области Коммутируемой Передачи Пакетов (Packet Switched, PS).

Фиг.1 представляет собой иллюстрацию набора 100 протоколов слоя с доступом UMTS. Процедуры AKA и шифрования UMTS распределены по множеству протокольных уровней и используют как сигнализацию Слоя Без Доступа (Non-Access Stratum, NAS), так и сигнализацию Управления Радио Ресурсами (Radio Resource Control, RRC). Обычно, идентификация и аутентификация Беспроводного Блока Передачи Приема (Wireless Transmit Receive Unit, WTRU) осуществляется путем сигнализации NAS. После выполнения аутентификации на уровне NAS шифрование и/или защита целостности активируется посредством сети, используя Команду Безопасного Режима (Security Mode Command), которая представляет собой сообщение RRC. После активации защиты на уровне RRC посредством Команды Безопасного Режима WTRU передает Ключ Шифрования (Ciphering Key, CK) и Ключ Целостности (Integrity Key, IK) в Слой с Доступом (Access Stratum, AS), используя примитив GMMAS-SECURITY-RES через тракт GMMAS-SAP (который определен между Управлением Мобильностью GPRS (GPRS Mobility Management (GMM)) и AS). После получения этих ключей, RRC 110 передает их в Контроллер Радио Линии (Radio Link Controller, RLC) 120 и уровень Управления Доступом к Среде (Medium Access Control, MAC) 130, используя примитив CRLC-CONFIG (через тракт C-SAP между RRC и RLC) примитив CMAC-CONFIG (через тракт C-SAP между RRC и MAC). C-SAP (не показана) представляет собой Служебную Точку Доступа для сигнализации C-плоскости между RRC и нижними уровнями. В действительности шифрование и защита целостности обычно выполняется в RLC 120, но в случае прозрачного режима RLC это реализуется в MAC 130. Нижние уровни (то есть MAC/RLC) несут ответственность за то, чтобы в сообщениях, предназначенных для верхних уровней (например, сообщения NAS Уровня 3), была обеспечена защита целостности и/или шифрование. В противном случае нижние уровни игнорируют/отбрасывают это сообщение. После активации защиты безопасность C-плоскости и U-плоскости реализуется в RLC или MAC.

Для LTE была предложена радикально другая архитектура. Главное отличие заключается в том, что вместо одного уровня защиты (то есть в MAC/RLC) присутствует три уровня защиты: защита NAS, защита RRC и защита U-плоскости. Каждый уровень имеет свои собственные ключи. Защита NAS ограничивается Объектом Управления Мобильностью (Mobility Management Entity, MME) и реализуется в уровне NAS. Защита RRC ограничивается в Усовершенствованном Узле B (Evolved Node B, e-NB) и реализуется в Протоколе Сходимости Пакетных Данных (Packet Data Convergence Protocol, PDCP). Защита U-плоскости состоит только из шифрования (без защиты целостности) и она также реализуется в PDCP. Вкратце, процедуры AKA выполняются в NAS, и выводятся ключи защиты NAS. Параметры защиты RRC/U-плоскости выводятся криптографическим образом из ключей NAS. Сведения о ключах RRC/U-плоскости не позволяют взломщику определить ключи NAS. Основной причиной этого является то, что в LTE несколько e-NB могут находиться в уязвимых местах, таких как дома. RRC и, следовательно, защита ограничивается в e-NB, так что это рассматривается как риск безопасности. Соответственно, для данного стандарта было принято два уровня защиты.

Фиг.2 представляет собой структурную схему иерархии ключей в LTE 200. Как показано на Фиг.2, Универсальный Модуль Идентификации Абонента (Universal Subscriber Identity Module, USIM) (в WTRU) и Центр Аутентификации (Authentication Centre, AuC) 205 используют общий секретный ключ K 210. Как часть сигнализации Аутентификации и Согласования Ключей (Authentication and Key Agreement, AKA) NAS (аналогично текущим процедурам UMTS AKA), USIM и AuC/HSS выводят Ключ Шифрования (Ciphering Key, CK) 215 и Ключ Целостности (Integrity Key, IK) 220. Процедура для выведения CK 215 и IK 220 схожа с соответствующей процедурой в UMTS, где AuC/HSS выводит Вектор Аутентификации и передает запрос в WTRU в сообщении NAS, на которое WTRU отвечает и HSS/AuC верифицирует. Однако в отличие от UMTS, где CK 215 и IK 220 предоставляются в уровни MAC/RLC для выполнения шифрования и/или защиты целостности, в LTE ключи CK 215 и IK 220 используются для выведения остальных ключей в иерархии, начиная с главного ключа - так называемого ключа K_ASME 225. Остальные ключи выводятся из ключа K_ASME с использованием различных Функций Выведения Ключа (Key Derivation Function, KDF) и округления.

K_eNB 230 представляет собой ключ, который выводится посредством WTRU и MME из ключа K_ASME 225 или посредством WTRU и целевым eNB из ключа KeNB* в течение эстафетного переключения eNB. K_eNB 230 используется для выведения ключей для потока обмена RRC и для выведения ключей для потока обмена восходящей линии связи, или для выведения переходного ключа K_eNB* в течение эстафетного переключения eNB.

K_NASint 235 представляет собой ключ, который используется для защиты целостности сигнализации NAS с конкретным алгоритмом защиты. Этот ключ выводится посредством WTRU и MME 237 из ключа K_ASME 225, а также идентификатора для алгоритма целостности с использованием KDF.

K_NASenc 240 представляет собой ключ, который используется для шифрования сигнализации NAS посредством конкретного алгоритма шифрования. Этот ключ выводится посредством WTRU и MME 237 из ключа K_ASME 225, а также идентификатора для алгоритма шифрования с использованием KDF.

K_UPenc 245 представляет собой ключ, который используется для шифрования потока обмена восходящей линии связи посредством конкретного алгоритма шифрования. Этот ключ выводится посредством WTRU и eNB 247 из ключа K_eNB 230, а также идентификатора для алгоритма шифрования с использованием KDF.

K_RRCint 250 представляет собой ключ, который используются для защиты целостности потока обмена RRC посредством конкретного алгоритма защиты. K_RRCint 250 выводится посредством WTRU и eNB 247 из ключа K_eNB 230, а также идентификатора для алгоритма защиты целостности с использованием KDF.

K_RRCenc 255 представляет собой ключ, который используется для шифрования сигнализации RRC посредством конкретного алгоритма шифрования. K_RRCenc 255 выводится посредством WTRU и eNB 247 из ключа K_eNB 230, а также идентификатора для алгоритма шифрования с использованием KDF.

Ключи RRC и U-плоскости могут быть выведены с использованием C-RNTI в качестве ввода.

В существующей архитектуре безопасности UTRAN в RLC или MAC выполняется проверка корректности шифрования и/или защиты целостности. Единственный сценарий сбоя защиты, имеющий место в текущее время в NAS, обусловлен сбоями аутентификации. Тем не менее, при наличии отдельной процедуры шифрования и защиты целостности в NAS желательно определить процедуры NAS для сценариев, в которых сообщение NAS принимается без корректного шифрования и/или защиты целостности.

NAS полагается на AS, то есть на RLC или MAC, для верификации того, что все принятые сообщения Уровня 3 (Layer-3, L3) имеют корректные мандаты защиты, то есть что было обеспечено должное шифрование и защита целостности. Поскольку в новой архитектуре LTE имеется защита уровня NAS, независящая от защиты AS, и NAS верифицирует безопасность сообщений L3, этот подход является неадекватным, поскольку проверка защиты NAS выполняется как часть процедур, определенных в поведении NAS. Соответственно, желательно определить действия для NAS в случае сбоя.

Поскольку ключи NAS не зависят от ключей RRC/U-плоскости (далее AS-ключей), представляется возможным запустить/реконфигурировать шифрование NAS независимо от шифрования/защиты целостности AS. Было бы желательным предоставить новые сообщения и процедуры для этого процесса. Кроме того, истечение срока действия ключа может быть ассоциировано с состоянием NAS/RRC блока WTRU. Было бы желательным предоставить процедуры для обработки ключа WTRU.

RRC, как правило, принимает новые ключи CK и IK из NAS и передает их в MAC и RLC, где выполняется шифрование/защита целостности. Тем не менее, в LTE шифрование и защита целостности AS будет выполняться посредством PDCP. Соответственно, было бы желательным предоставить новые межуровневые процедуры и примитивы для должного функционирования защиты.

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

Настоящий способ и устройство относятся к системе беспроводной связи, которая включает себя Беспроводной Блок Передачи Приема (Wireless Transmit Receive Unit, WTRU), который сконфигурирован для приема нешифрованных и шифрованных сообщений. Нешифрованные сообщения могут включать в себя запросы идентичности, запросы аутентификации, команды режима защиты Слоя Без Доступа (Non-Access Stratum, NAS) и ответы на запросы обновления отслеживаемой области. Шифрованные сообщения могут исходить из NAS и Контроллера Радио Ресурсов (Radio Resource Controller, RRC). Упомянутые сообщения, предпочтительно, шифруются посредством ключей защиты.

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

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

фиг.1 - набор протоколов слоя с доступом согласно существующему уровню техники;

фиг.2 - структурная схема иерархии ключей в LTE согласно существующему уровню техники;

фиг.3 - структурная схема одного варианта осуществления, где агент может представлять собой уровень, эквивалентный уровню Управления Мобильностью, в LTE NAS или новый подуровень для защиты, либо некоторый другой агент, и параметры защиты, заданные для данного сообщения, некорректны;

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

фиг.5 - структурная схема, иллюстрирующая процедуры обработки ключа в WTRU при переходе из режима EMM_Connected в режим EMM_Idle;

фиг.6 - структурная схема набора протоколов слоя с доступом для LTE; и

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

Подробное описание

В использованном здесь значении термин "Беспроводной Блок Передачи/Приема" (Wireless Transmit/Receive Unit, WTRU) включает в себя, но не ограничивается перечисленным, Пользовательское Оборудование (User Equipment), мобильную станцию, фиксированную или мобильную абонентскую станцию, пейджер, сотовый телефон, Персональный Цифровой Секретарь (Personal Digital Assistant, PDA), компьютер или любой другой тип пользовательских устройств, способных работать в беспроводной среде. В использованном здесь значении термин "базовая станция" включает в себя, но не ограничивается перечисленным, Узел-B (Node-B, NB), Усовершенствованный Узел-B (Evolved Node-B, eNB), локальный контроллер, точку доступа или любой другой тип интерфейсного устройства, способного работать в беспроводной среде.

Обработка Сбоев Защиты в NAS

Нижеописанные процедуры могут быть использованы, если возникают проблемы с защитой на некотором другом уровне, например на уровне PDCP, выполняющем шифрование/защиту целостности RRC. Согласно одной процедуре для обработки сбоя защиты в NAS предоставляется группа сообщений NAS, которая может быть принята блоком WTRU без активации шифрования и/или защиты целостности в NAS. Подобный список существует только для сообщений UTRAN NAS, которые отличаются от сообщений LTE NAS и которые могут быть приняты без активации шифрования RLC/MAC. Группа сообщений NAS, которая может быть принята блоком WTRU без активации шифрования и/или защиты целостности в NAS, может включать в себя, не ограничиваясь перечисленным:

Запрос Идентичности;

Запрос Аутентификации;

Команду Режима Защиты NAS (которая может быть принята, когда в NAS активирована, по меньшей мере, защита целостности); и

Ответ на Запрос Обновления Отслеживаемой Области.

В MME без шифрования и/или защиты целостности могут быть приняты следующие сообщения:

Ответ на Запрос Идентичности;

Ответ на Запрос Аутентификации; и

Запрос Обновления Отслеживаемой Области.

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

Некоторые другие сообщения NAS могут быть переданы только тогда, когда актирована и защита NAS, и защита RRC. Некоторые сообщения NAS могут быть переданы, если была актирована защита NAS (независимо от защиты RRC).

Фиг.3 представляет собой структурную схему 300 одного варианта осуществления, где агент может представлять собой уровень, эквивалентный уровню Управления Мобильностью, в LTE NAS или новый подуровень для защиты, либо некоторый другой агент. Когда принимается 305 сообщение NAS, агент, несущий ответственность за проверку статуса защиты сообщения NAS, выполняет проверку 310, чтобы определить корректность параметров защиты для этого сообщения. Если параметры защиты, заданные для этого сообщения, некорректны 315, то есть, если проверка целостности завершается неуспешно или если сообщение не зашифровано или если сообщение (в зависимости от дискриминатора протокола и полей типа сообщения в заголовке) должно быть принято с шифрованием и/или защитой целостности, но шифрование и/или защита целостности отсутствует, то уровень NAS, его подуровень или агент может предпринять любое или все из нижеперечисленных действий в любой последовательности. Эти действия могут зависеть от типа сообщения, параметры защиты которого некорректны. Определенные ниже процедуры также могут быть использованы, если есть проблемы с защитой в некотором другом уровне (например, сбои защиты RRC):

Действия агента могут быть определены реализацией 320;

Агент может игнорировать и/или отбросить сообщение 325;

Агент может сообщить о сбое в некоторый другой протокольный уровень (например, RRC), объект в WTRU (например, USIM/UICC) сети 330. Если агент проверяет защиту и обнаруживает ошибку, то он может запустить, например, сообщение в сеть, указывающее об ошибке. Ответ может включать в себя причину сбоя. Если некоторый другой уровень протокола/объект был проинформирован о подобном сбое, то их реакция может быть схожа с описанной в настоящем документе.

Агент может инициировать повторную аутентификацию с сетью 335;

Агент может перейти в режим Evolved Packet System (EPS) Mobility Management (EMM_Idle) или состояние EMM_Deregistered 340;

Агент может выполнять подсчет количества сбоев и предпринять некоторые действия в зависимости от повторения сбоев 345. Эти действия могут совпадать с описанными в настоящем документе;

Агент может предпринять попытку повторного присоединения к сети 350; или

Агент может удалить некоторые и/или все хранимые параметры защиты (ключи/порядковые номера/идентификаторы набора ключей) или он может напрямую, либо через промежуточное звено, сигнализировать объекту в WTRU, который хранит/управляет этими параметрами защиты, выполнить их удаление 355.

Если же параметры защиты корректны, то сообщение NAS может быть обработано так, как определено для конкретного протокола и типа сообщения 360. Например, этот агент может представлять собой уровень, эквивалентный уровню Управления Мобильностью, в LTE NAS или новый подуровень для защиты, или некоторый другой агент.

Воздействие протокола уровня 3

Существующий заголовок протокола L3 не содержит порядкового номера. Заголовок стандартного сообщения L3 состоит из двух октетов. Заголовок структурирован в трех главных частях - дискриминаторе протокола (1/2 октета), октете типа сообщения и еще одной половине октета. Последняя половина октета используется в некоторых случаях как Идентификатор Транзакции, в некоторых других случаях - как дискриминатор подпротокола, и в остальных случаях ее называют индикатором пропуска. Например, если Дискриминатор Протокола установлен в значение GMM, то он может быть использован как индикатор пропуска. Если дискриминатор протокола установлен в значение SM, то он может быть использован как TI или как дискриминатор подпротокола. Если он используется как индикатор пропуска, это означает, что для сообщений GMM первые 4 бита не имеют значения и они "пропускаются".

Дискриминатор протокола определяет различия между сообщениями Управления Мобильностью (Mobility Management, MM), Управления Мобильностью GPRS (GPRS Mobility Management, GMM), Управления Сессией (Session Management, SM) и т.п. Наряду с тем, что тип сообщения указывает вид сообщения, например Запрос Присоединения или Активация контекста PDP, идентификатор транзакции позволяет одноранговым объектам в WTRU и в сети различать до 16 разных двунаправленных потоков сообщений для заданного дискриминатора протокола и заданной Служебной Точки Доступа (Service Access Point, SAP). Подобный поток сообщений называют транзакцией. Также задан механизм расширения для Идентификатора Транзакции (Transaction Identifier, TI). Этот механизм позволяет различать до 256 разных двунаправленных потоков сообщений для заданного дискриминатора протокола и заданной SAP. Например, когда WTRU пытается получить IP-адрес, объект SM присутствует в WTRU и в сети. Так, если WTRU пытается получить еще один IP-адрес, то в WTRU и в сети создается еще одна пара объектов SM. TI идентифицирует, для какой транзакции, то есть для какой пары, предназначено конкретное сообщение SM.

Фиг.4 представляет собой структурную схему усовершенствованного заголовка L3, включающего в себя порядковый номер 410 NAS. Как и существующий заголовок протокола L3, данный усовершенствованный заголовок состоит из двух октетов и структурирован в трех основных частях. Этими тремя частями являются дискриминатор 420 протокола (1/2 октета), октет типа сообщения и половина октета, которая в некоторых случаях используется как Идентификатор 430 Транзакции, в некоторых других случаях - как дескриптор подпротокола, в остальных же случаях она называется индикатором пропуска. Например, если Дискриминатор Протокола установлен в значение GMM, то он может быть использован как индикатор пропуска. Если дискриминатор протокола установлен в значение SM, то он может быть использован как TI или как дискриминатор подпротокола. Если он используется как индикатор пропуска, это означает, что для сообщений GMM первые 4 бита не имеют значения и они "пропускаются". Усовершенствованный заголовок включает в себя порядковый номер 410 для сообщения NAS, который обозначается аббревиатурой NAS SN. Этот номер может быть включен в заголовок протокола сообщения NAS, либо он может быть в содержимом сообщения в качестве Информационного Элемента (Information Element, IE). Идентификатор транзакции также может выполнять функцию порядкового номера. Номер NAS SN может иметь предварительно заданный или согласовываемый период приращения. Например, он может быть основан на каждом отдельном NAS PDU (то есть сообщении). Уровень NAS может выполнять детектирование копий на основании порядкового номера или путем использования любого другого номера, который увеличивается приращениями посредством NAS SN, где принимаемые дублирующие блоки NAS PDU отбрасываются.

Номер NAS SN может сохраняться по каждой радионесущей сигнализации AS или по каждому SAP, независимо от дискриминатора протокола или типа сообщения. Он также может сохраняться по каждому TI.

В уровне NAS может быть использована величина COUNT. Приращение величины COUNT на предварительно заданной/согласовываемой основе, например, для каждого сообщения L3, может защитить от атак с передачей или атак под видом законного пользователя. Это осуществимо посредством шифрования на уровне NAS. Для множества SAP может быть задана одна величина COUNT. Для всех SAP может быть задана одна величина COUNT-C для шифрования и одна величина COUNT-I для защиты целостности. Для всех SAP может быть задана комбинация величин COUNT-C и/или COUNT-I и/или одна величина COUNT. Величина COUNT может состоять из двух параметров: Порядкового Номера (Sequence Number, SN) NAS, который увеличивается приращениями в предварительно заданном/согласовываемом порядке, например, для каждого Блока Протокольных Данных (Protocol Data Unit, PDU) NAS или для каждого NAS PDU на заданном SAP и Номера Гиперкадра (Hyper-Frame Number, HFN) NAS. Номер NAS HFN может представлять собой счетчик, который увеличивается на единицу при x приращениях номера NAS SN. Параметр COUNT целиком или частями может быть инициализирован на основании величины START в течение начального доступа/выведения ключа/аутентификации/перехода из состояния простоя в активное состояние. В целях обеспечения защиты, параметр COUNT может быть использован в качестве ввода для алгоритмов шифрования/дешифрования и защиты целостности/проверки целостности.

Величина COUNT может требовать предварительной установки до активации защиты NAS. Длина параметра Count-C может составлять 32 бита, или она может быть сокращена, поскольку для сообщений NAS может не требоваться большой номер NAS. Кроме того, длина самого поля SN и поля HFN может быть модифицирована внутри параметра Count-C, чтобы оптимизировать ее для процедур уровня NAS. Для NAS могут использоваться механизмы шифрования по предшествующему уровню техники. В механизме шифрования должны быть сделаны соответствующие изменения для использования меньшей величины Count-C или изменений величины SN и HFN.

Альтернативно, величина NAS COUNT может представлять собой NAS SN, если NAS SN может быть защищен посредством шифрования RRC, чтобы он не был открытым, и, следовательно, не будет необходимости в скрытом номере HFN. Защита NAS может быть активирована только после активации защиты RRC, а номер NAS SN может быть переустановлен при активации защиты NAS. В добавление, посредством величины NAS COUNT может быть выполнено детектирование копий в NAS.

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

Альтернативно, на стороне WTRU вместо 2 отдельных механизмов шифрования для RRC и NAS, может использоваться один механизм шифрования, который может обрабатывать как параметры RRC, так и параметры NAS.

Дополнительное шифрование сообщения на уровне NAS может быть опциональным, и WTRU может указывать в информации о своих способностях, поддерживает ли он шифрование уровня NAS.

Обработка ключей в WTRU при переходе из режима EMM_Connected в режим EMM_Idle

Как правило, когда WTRU переходит из режима EMM_Connected в режим EMM_Idle, соединение RRC обрывается. При переходе из активного режима в режим простоя eNB, как правило, не сохраняет информацию состояния о соответствующем блоке WTRU. eNB, как правило, удаляет текущие ключи из своей памяти.

В частности, для этого варианта осуществления при переходе из активного режима в режим простоя eNB может удалить, по меньшей мере, один из ключей K_eNB, K_RRCenc, K_RRCint и K_UPenc. Тем не менее MME может сохранить ключ K_ASME.

Фиг.5 представляет собой структурную схему, иллюстрирующую процедуры 500 обработки ключа в WTRU при переходе из режима EMM_Connected в режим EMM_Idle. До сих пор процедуры WTRU не были определены для этого перехода. Согласно одной из возможных процедур, при переходе 510 в режим EMM_Idle посредством WTRU может быть предоставлена индикация в объект, который сохраняет 520 ключи защиты в WTRU, такие как UICC, USIM или Мобильное Оборудование. Согласно еще одной возможной процедуре, WTRU предоставляет 520 индикацию в объект хранения, когда обслуживающий e-NB меняется 530 в режиме EMM_Idle, как, например, в течение повторного выбора ячейки в другой e-NB. Индикация, предоставляемая из WTRU в объект хранения, может включать в себя идентичность e-NB, так что могут быть выведены ключи e-NB, RRC и U-плоскости. Например, эти индикации могут быть предоставлены посредством NAS и/или AS. Для этой цели между протокольными уровнями индицирующего объекта и/или между индицирующим объектом и объектом хранения могут быть заданы предопределенные примитивы, включающие в себя сообщения, информационные элементы IE, интерфейсы и точки SAP. Очевидно, что упомянутые предопределенные примитивы могут включать в себя как новые, так и существующие примитивы. При получении подобной индикации перехода, объект хранения в WTRU, предпочтительно, удалит 540 соответствующие ключи, например, по меньшей мере, один из ключей K_eNB, K_RRCenc, K_RRCint и K_UPenc. Объект хранения может сохранить или удалить 550 ключи защиты NAS и ключи ASME.

Объект хранения может удалить ключи K_RRCenc, K_RRCint и K_UPenc при получении индикации о переходе из активного состояния в состояние простоя, и удалить ключ K_eNB, когда принимается индикация о смене обслуживающей e-NB, как, например, в течение повторного выбора другой e-NB. Объект хранения может сохранить или удалить ключи защиты NAS и ключи ASME. При повторном выборе ячейки, принадлежащей другой e-NB, определенной путем считывания идентификации e-NB по широковещательному каналу, WTRU может сгенерировать новый ключ K*_Enb, используя K_eNB и "идентификатор следующего сегмента".

Объект хранения может не удалить какие-либо ключи при переходе из активного состояния в состояние простоя или при переходе на новую e-NB в режиме простоя, тогда как он может удалить эти ключи при переходе из состояния простоя в активное состояние.

Объект хранения может не удалить какие-либо ключи при переходе из активного состояния в состояние простоя или при переходе на новую e-NB в режиме простоя. Вместо этого он может удалить их, когда генерируются новые ключи, например, когда e-NB принимает запрос RRC_Connection или назначается новый идентификатор C-RNTI.

Смена ID/C-RNTI обслуживающей ячейки может быть указана 560 объекту хранения. Эта индикация может быть предоставлена посредством NAS и/или AS. Альтернативно, упомянутые ключи могут быть сохранены 570 с ассоциированной величиной таймера. Когда WTRU переходит из состояния простоя в активное состояние или наоборот, таймер может контролировать период, в течение которого ключ будет действительным до его удаления.

Воздействия на уровень PDCP из-за предложенной архитектуры шифрования

Как правило, шифрование для потока обмена RRC и U-плоскости может быть выполнено на уровне PDCP. Из-за этого в PDCP возникает множество архитектурных изменений.

В этом варианте осуществления уровень PDCP может принимать ключи защиты RRC и ключи защиты U-плоскости с верхних уровней. При необходимости могут быть определены соответствующие примитивы. В частности, RRC или NAS или USIM может предоставить в PDCP требуемые ключи шифрования, а также требуемые величины START или COUNT или HFN или SN. Уровень PDCP также может сам вычислить эти величины на основании информации заголовка RRC.

Ссылаясь на фиг.1, поток обмена C-плоскости не проходит через PDCP. Поскольку разные радионесущие могут быть защищены посредством разных параметров COUNT, предпочтительно, чтобы уровень PDCP имел способность различения между разными типами потока обмена. Для этого входящие пакеты SDU или примитивы, несущие эти пакеты SDU, могут содержать явную информацию относительно целевых радионесущих. Уровень PDCP может определить это и выполнить шифрование/защиту целостности, соответственно.

Фиг.6 представляет собой структурную схему набора 600 протоколов слоя с доступом для LTE. Ссылаясь на фиг.6, поток обмена C-плоскости проходит через уровень 610 PDCP. Уровень 610 PDCP выполняет проверку защиты входящих блоков PDCP PDU. Если уровень 610 PDCP определяет, что параметры защиты входящего PDU (который должен быть сопоставлен либо Радио Несущей для Передачи Данных, либо Радио Несущей Сигнализации) некорректны (то есть если, например, проверка целостности PDCP PDU завершается неуспешно), он может выполнить, по меньшей мере, одно из следующих действий в любой последовательности. Эти действия могут зависеть от типа сообщения, параметры защиты которого некорректны. Определенные ниже процедуры также могут быть использованы, если есть проблемы с защитой в некотором другом уровне (например, при сбоях защиты NAS):

действия PDCP могут быть определены конкретной реализацией;

PDCP может игнорировать и/или отбросить сообщение;

он может сообщить о сбое в некоторый другой протокольный уровень, такой как объект RRC в WTRU; другой протокольный уровень может быть проинформирован о подобном сбое;

он может вести счет количества сбоев и при повторных сбоях (например, X сбоев в Y сообщениях или в единицах времени) предпринимать некоторые действия, такие как описанные в настоящем документе или некоторые другие действия;

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

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

Номер PDCP HFN может быть использован для формирования величины COUNT. Упомянутая величина COUNT может быть использована в алгоритмах шифрования и/или защиты целостности PDCP 510, и она может быть инициализирована посредством величины START. Существует множество величин COUNT для каждой радио несущей, которую может защитить PDCP. Уровни RRC 620 и PDCP 610 могут быть способны обменяться информацией относительно величины COUNT или ее составляющих.

Уровень 610 PDCP может выполнить проверку защиты целостности сообщения. Это согласуется с предположением, что защита целостности выполняется в PDCP 610. Тем не менее, в текущее время слово Кода Аутентификации Сообщения (Message Authentication Code, MAC), прикрепленное к сообщению для верификации его целостности, вычисляется в RRC 620, прикрепляется к сообщению RRC и передается в уровень RLC 630/Управления Доступом к Среде (Medium Access Control, MAC) 640. Сообщение, включая слово MAC, шифруется целиком. Кроме того, уровень 610 PDCP может не иметь возможности определения необходимости защиты сообщения RRC.

На стороне передачи уровень 620 RRC может указать уровню 610 PDCP о том, требует ли заданное сообщение RRC защиты целостности и/или шифрования. Уровень 610 PDCP может использовать эту информацию для определения того, следует ли выполнить шифрование и/или защиту целостности сообщений RRC, которые должны быть переданы как блоки PDCP PDU.

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

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

Альтернативно или в добавление, уровень 620 RRC может указывать уровню 610 PDCP, что все сообщения RRC, начиная с заданного сообщения RRC, будут зашифрованы.

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

Альтернативно или в добавление, уровень 620 RRC может предоставить в уровень 610 PDCP список общих сообщений RRC и их соответствующие параметры защиты. Этот список может включать в себя сообщения, которые могут быть приняты без шифрования и/или защиты целостности, такие как, например, сообщение Повторного Установления Соединения RRC. Этот список может включать в себя сообщения, которые могут быть приняты с шифрованием и/или защитой целостности.

Альтернативно или в добавление, уровнем 620 RRC опционально может быть определен флаг проверки шифрования и/или защиты целостности, при установке которого уровень 610 PDCP выполнит проверку шифрования и/или защиты целостности всех сообщений RRC. Таким образом, уровень 610 PDCP проверит этот флаг до выполнения проверки шифрования и защиты целостности. Для шифрования и защиты целостности могут быть заданы отдельные флаги.

Для всех вышеперечисленных механизмов индикации индикация может быть предоставлена для каждой Радио Несущей Сигнализации (Signaling Radio Bearer, SRB), то есть уровень 620 RRC может указывать уровню 610, что индикация для шифрования и/или защиты целостности применима к сообщениям RRC, которые сопоставлены уровнем 610 PDCP к конкретной несущей SRB.

Для передаваемого сообщения уровень 610 PDCP может сначала выполнить защиту целостности и, далее, выполнить шифрование, либо сначала зашифровать, и после этого выполнить защиту целостности. До выполнения любой операции он может заполнить сообщение незначащей информацией, чтобы обеспечить оптимальную длину для шифрования и/или защиты целостности. До выполнения операции защиты уровень 610 PDCP может назначить номер SN. Этот SN может представлять собой номер PDCP SN или RRC SN, либо может быть использован другой порядковый номер, такой как, например, общий порядковый номер. До выполнения операции защиты уровень 610 PDCP может выполнить сжатие заголовка для потока обмена U-плоскости.

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

Шифрование может быть выполнено по всему сообщению, включающему в себя слово MAC, и/или по сообщению нешифрованного текста и/или их частям.

Шифрование также может быть выполнено по всему заголовку PDCP или части заголовка PDCP, за исключением SN.

Также может присутствовать индикация о том, было ли выполнено шифрование и/или защита целостности полезной нагрузки. Например, уровень 610 PDCP на стороне передачи может включать в себя IE, указывающий наличие шифрования и/или защиты целостности. Эта индикация может быть зашифрована. Эта индикация может указывать позицию MAC-слова в сообщении для проверки слоем PDCP. Уровень 610 PDCP на принимающей стороне может использовать эту индикацию, чтобы определить, следует ли выполнить расшифровку и/или проверку целостности.

Уровень 610 PDCP и протокол может включать в себя MAC-слово для проверки целостности в предопределенной позиции в заголовке/сообщении PDCP для приемника. Альтернативно, позиция MAC-слова может быть указана принимающему уровню 610 PDCP. Подобной индикацией, например, может быть смещенное поле в заголовке.

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

Уровень 610 PDCP может определить, что для конкретного сообщения шифрование и/или защита целостности неудовлетворительны. Это означает, что PDCP определит, корректно ли выполнено шифрование и/или защита целостности заданного сообщения.

Уровень 610 PDCP может указать уровню RRC статус защиты сообщения, которое он передает в уровень 620 RRC, например, если это сообщение принято с шифрованием и/или защитой целостности. Или, например, была ли успешна проверка защиты целостности. Эта индикация может быть явной, то есть она может предоставляться только тогда, когда возникает ошибка, напри