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

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

 

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

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

В частности, настоящий способ и устройство относятся к безопасной связи в беспроводном устройстве, соответствующем стандарту Долгосрочной Эволюции (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, например, если это сообщение принято с шифрованием и/или защитой целостности. Или, например, была ли успешна проверка защиты целостности. Эта индикация может быть явной, то есть она может предоставляться только тогда, когда возникает ошибка, например, когда проверка целостности завершается неуспешно. Тогда уровень 620 RRC может определить, приемлема ли защита для конкретного сообщения. Поведение RRC при уведомлении об ошибке может быть определено согласно абзацу с описанием фиг.6 на странице 19. Альтернативно или в добавление, уровень RRC может уведомить сеть об ошибке проверки целостности путем добавления (в сообщение RRC, которое он передает в сеть) Информационного Элемента, который сообщает сети об этой ошибке.

В случае ошибки, уровень 610 PDCP может предпринять действия, описанные выше для сценариев обработки сбоев. Если сообщение RRC закодировано по стандарту ASN.1 и MAC-слово включено в уровень 620 RRC, то уровень 620 PDCP может проверить MAC-слово в уровне RRC. Это может быть выполнено, если установлен флаг, указывающий защиту целостности.

Межуровневые процедуры защиты

Уровень RRC/PDCP может получить ключи e-NB/RRC/U-плоскости из уровня NAS или из USIM. Альтернативно, уровень RRC/PDCP может сгенерировать свои собственные ключи. Например, уровень RRC может сгенерировать ключи e-NB/RRC/U-плоскости, используя параметры, которые были приняты из сети в сигнализации RRC, ключ K_ASME, принятый из NAS, а также другие параметры, принятые из других протокольных уровней (например, с физического уровня может быть получен идентификатор физической ячейки, в которой находится в текущее время WTRU или к которой он выполняет доступ). Эти ключи могут передаваться между NAS и RRC/PDCP или между RRC и PDCP посредством предопределенных примитивов, включающих в себя новые или существующие примитивы, через новые или существующие SAP. Каждый уровень может иметь возможность сообщать об ошибке, то есть о сбое защиты, в верхние/нижние уровни.

Фиг.7 представляет собой структурную схему системы 700 беспроводной связи, сконфигурированной для обмена шифрованными и нешифрованными сообщениями в LTE. Данная система включает в себя базовую станцию 705 и Беспроводной Блок Передачи Приема (Wireless Transmit/Receive Unit, WTRU) 710. Базовая станция 705 и WTRU 710 осуществляют связь через линию беспроводной связи.

Как показано на фиг.7, WTRU 710 включает в себя передатчик 720, приемник 730 и процессор 740. Процессор 740 присоединен к буферу 750 и памяти 760. Процессор 740 сконфигурирован так, чтобы обрабатывать сообщения NAS, содержащие параметры защиты, посредством, по меньшей мере, одного из вышеописанных методов.

На фиг.7 также показана базовая станция 705, которая включает в себя передатчик 765, приемник 770 и процессор 780. Процессор 780 присоединен к буферу 790 и памяти 795. Процессор 780 сконфигурирован так, чтобы обрабатывать сообщения NAS, содержащие параметры защиты, посредством, по меньшей мере, одного из вышеописанных методов.

Несмотря на то, что функции и элементы были описаны выше в конкретных комбинациях, каждая функция или элемент может быть использован в отдельности, без других функций и элементов, либо в различных комбинациях с другими функциями и элементами или без них. Способы или схемы последовательностей операций, представленные в настоящем изобретении, могут быть реализованы в компьютерной программе, программном обеспечении или встроенном программном обеспечении, реализованном в машиночитаемом носителе для выполнения компьютером общего назначения или процессором. Примеры машиночитаемых носителей включают в себя ПЗУ, ОЗУ, регистр, кэш-память, полупроводниковые запоминающие устройства, магнитные носители, такие как внутренние жесткие диски и съемные диски, магнитооптические диски, и оптические носители, такие как диски CD-ROM и DVD.

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

Процессор вместе с программным обеспечением может использоваться для реализации радиочастотного приемопередатчика для использования в Беспроводном Блоке Передачи Приема (Wireless Transmit Receive Unit, WTRU), пользовательском оборудовании, терминале, базовой станции, контроллере радиосети или в любом главном компьютере. Блок WTRU может использоваться в связи с модулями, реализованными аппаратным и/или программным образом, такими как камера, видеокамера, видеотелефон, телефон с громкой связью, вибрационное устройство, громкоговоритель, микрофон, телевизионный приемопередатчик, гарнитура "handsfree", клавиатура, модуль Bluetooth®, радиоблок с частотной модуляцией, жидкокристаллический дисплей, OLED-дисплей, цифровой музыкальный проигрыватель, медиа-проигрыватель, модуль видеоигр, Интернет-браузер и/или любой модуль беспроводной локальной сети.

Варианты осуществления

1. Беспроводной Блок Передачи Приема (Wireless Transmit Receive Unit, WTRU), сконфигурированный так, чтобы реализовать защиту в беспроводной связи стандарта Долгосрочной Эволюции (Long Term Evolution, LTE), причем упомянутый WTRU содержит:

приемник, сконфигурированный так, чтобы принимать сообщение Слоя Без Доступа (Non-Access Stratum, NAS), которое содержит параметры защиты; и

процессор, сконфигурированный так, чтобы:

определять, корректны ли упомянутые параметры защиты; и

выполнять процедуру защиты на основании этого определения.

2. WTRU согласно варианту осуществления 1, в котором процессор содержит:

механизм шифрования Контроллера Радио Ресурсов (Radio Resource Controller, RRC); и

механизм шифрования NAS.

3. WTRU согласно любому из вариантов осуществления 1-2, в котором процессор содержит:

механизм шифрования, сконфигурированный так, чтобы обрабатывать как параметры RRC, так и параметры NAS.

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

игнорирование сообщения, отбрасывание сообщения, передача отчета об ошибке на другой протокольный уровень, инициация повторной аутентификации, переход в режим Evolved Packet System (EPS) Mobility Management (EMM_Idle), переход в состояние EMM_Deregistered, ведение счета количества сбоев, повторное присоединение к сети и удаление параметров защиты.

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

принимают сообщение Слоя Без Доступа (Non-Access Stratum, NAS), которое содержит параметры защиты;

определяют, корректны ли упомянутые параметры защиты; и

выполняют процедуру защиты на основании этого определения.

6. Способ согласно варианту осуществления 5, в котором процедура защиты включает в себя, по меньшей мере, одно из следующего: игнорирование сообщения, отбрасывание сообщения, передача отчета о сбое на другой протокольный уровень, инициация повторной аутентификации, переход в режим Evolved Packet System (EPS) Mobility Management (EMM_Idle), переход в состояние EMM_Deregistered, ведение счета количества сбоев, повторное присоединение к сети и удаление параметров защиты.

7. Способ согласно любому из вариантов осуществления 5-6, в котором сообщение NAS содержит протокольный заголовок, включающий в себя порядковый номер NAS.

8. Способ согласно любому из вариантов осуществления 5-7, дополнительно содержащий этап, на котором:

выполняют детектирование копий на основании порядкового номера NAS.

9. Способ согласно любому из вариантов осуществления 5-8, в котором порядковый номер NAS выполняет роль идентификатора транзакции.

10. Способ согласно любому из вариантов осуществления 5-8, в котором порядковый номер NAS содержит предварительно определенный период приращения.

11. Способ согласно любому из вариантов осуществления 5-8, в котором порядковый номер NAS содержит согласовываемый период приращения.

12. Способ согласно любому из вариантов осуществления 5-11, в котором сообщение NAS коррелируется с величиной COUNT.

13. Способ согласно варианту осуществления 12, в котором величина COUNT предназначена для шифрования (COUNT-C).

14. Способ согласно любому из вариантов осуществления 11-12, в котором величина COUNT предназначена для защиты целостности (COUNT-I).

15. Способ согласно любому из вариантов осуществления 11-14, в котором величина COUNT представляет собой комбинацию COUNT-C и COUNT-I.

16. Способ согласно любому из вариантов осуществления 11-15, в котором величина COUNT содержит:

Порядковый Номер (Sequence Number, SN) NAS; и Номер Гиперкадра (Hyper-Frame Number, HFN) NAS.

17. Способ согласно любому из вариантов осуществления 11-16, в котором NAS HFN представляет собой счетчик.

18. Способ согласно любому из вариантов осуществления 12-17, в котором величина COUNT используется как ввод в алгоритм защиты целостности для шифрования.

19. Способ согласно любому из вариантов осуществления 12-18, в котором величина COUNT используется как ввод в алгоритм защиты целостности для расшифровки.

20. Способ согласно любому из вариантов осуществления 12-19, в котором величина COUNT конфигурируется до активации защиты NAS.

21. Способ согласно любому из вариантов осуществления 12-20, в котором величина COUNT состоит из 32 или менее битов.

22. Способ согласно любому из вариантов осуществления 16-21, в котором SN и NAS HFN могут быть сконфигурированы.

23. Способ согласно любому из вариантов осуществления 12-22, в котором величина COUNT представляет собой Порядковый Номер (Sequence Number, SN) NAS, и детектирование копий выполняется посредством величины COUNT.

24. Способ согласно любому из вариантов осуществления 5-23, в котором сообщение NAS указывает информацию о способностях Беспроводного Блока Передачи Приема (Wireless Transmit Receive Unit, WTRU).

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

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

принимают Блок Протокольных Данных (Protocol Data Unit, PDU) Протокола Сходимости Пакетных Данных (Packet Data Convergence Protocol, PDCP), который включает в себя параметры защиты;

определяют, корректны ли упомянутые параметры защиты; и

выполняют процедуру защиты на основании этого определения.

27. Способ согласно варианту осуществления 26, дополнительно содержащий этап, на котором:

передают из уровня Контролера Радио Ресурсов (Radio Resource Controller, RRC) в уровень PDCP индикацию, указывающую, требует ли сообщение RRC, по меньшей мере, одного из защиты целостности и шифрования.

28. Способ согласно любому из вариантов осуществления 26-27, дополнительно содержащий этап, на котором:

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

29. Способ согласно любому из вариантов осуществления 27-28, дополнительно содержащий этап, на котором:

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

30. Способ согласно любому из вариантов осуществления 27-29, дополнительно содержащий этап, на котором:

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

31. Способ согласно любому из вариантов осуществления 27-30, дополнительно содержащий этап, на котором:

устанавливают в RRC флаг шифрования или защиты целостности, чтобы выполнять шифрование или защиту целостности сообщений RRC.

32. Способ согласно варианту осуществления 31, дополнительно содержащий этап, на котором:

выполняют шифрование сообщений RRC на уровне PDCP до их передачи в виде блоков PDCP PDU и расшифровывают все принятые блоки PDCP PDU, соответствующие сообщениям RRC, если установлен флаг шифрования, и не выполняют шифрование и расшифровку, если флаг шифрования не установлен.

33. Способ согласно любому из вариантов осуществления 31-32, дополнительно содержащий этап, на котором:

прикрепляют Код Аутентификации Сообщения в блоки PDCP PDU, соответствующие передаваемым сообщениям RRC, и выполняют проверку всех принятых блоков PDCP PDU, которые соответствуют сообщениям RRC, если установлен флаг защиты целостности, и не выполняют прикрепление и защиту целостности, если этот флаг не установлен.

34. Способ согласно любому из вариантов осуществления 27-33, дополнительно содержащий этап, на котором:

устанавливают в RRC флаг шифрования и защиты целостности, чтобы выполнить шифрование и защиту целостности сообщений RRC.

35. Способ согласно варианту осуществления 34, дополнительно содержащий этап, на котором:

шифруют сообщения RRC до их передачи в виде блоков PDCP PDU, расшифровывают принятые блоки PDCP PDU, соответствующие сообщениям RRC, прикрепляют Код Аутентификации Сообщения в блоках PDCP PDU, соответствующих передаваемым сообщениям RRC, и выполняют проверку целостности всех принятых блоков PDCP PDU, которые соответствуют сообщениям RRC, если установлен флаг шифрования и защиты целостности, и не выполняют шифрование, расшифровку, прикрепления и защиту целостности, если этот флаг не установлен.

36. Способ согласно любому из вариантов осуществления 27-35, дополнительно содержащий этап, на котором:

предоставляют в PDCP список общих сообщений RRC и их соответствующих параметров защиты.

37. Способ согласно любому из вариантов осуществления 27-36, в котором уровень PDCP не выполняет, по меньшей мере, одного из шифрования и защиты целостности сообщений RRC, если из RRC не подается соответствующая инструкция.

38. Способ согласно любому из вариантов осуществления 27-37, дополнительно содержащий этапы, на которых:

шифруют сообщение RRC; и

выполняют защиту целостности сообщения RRC.

39. Способ согласно любому из вариантов осуществления 27-38, в котором сообщение RRC заполняют незначащей информацией, чтобы обеспечить оптимальную длину для шифрования или защиты целостности.

40. Способ согласно любому из вариантов осуществления 26-39, дополнительно содержащий этап, на котором:

вычисляют слово Кода Аутентификации Сообщения (Message Authentication Code, MAC) для защиты целостности по данным нешифрованного текста, зашифрованным данным, части заголовка PDCP или всему заголовку PDCP.

41. Способ согласно любому из вариантов осуществления 26-40, в котором шифрование выполняется по части данных нешифрованного текста.

42. Способ согласно любому из вариантов осуществления 26-41, дополнительно содержащий этап, на котором:

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

43. Способ согласно любому из вариантов осуществления 26-42, дополнительно содержащий этап, на котором:

предварительно определяют слово Кода Аутентификации Сообщения (Message Authentication Code, MAC) в позиции внутри блока PDCP PDU, который включает в себя заголовок.

44. Способ согласно варианту осуществления 43, в котором позиция предварительно определенного слова MAC находится в заголовке PDCP PDU.

45. Способ согласно любому из вариантов осуществления 26-44, в котором процедура защиты включает в себя, по меньшей мере, одно из следующего:

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

46. Способ согласно варианту осуществления 45, в котором отчет о сбое включает в себя причину сбоя.

47. Способ согласно любому из вариантов осуществления 26-46, дополнительно содержащий этап, на котором:

используют Номер Гиперкадра (Hyper-Frame Number, HFN) PDCP, чтобы сформировать величину COUNT.

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

принимают сообщение на уровне Протокола Сходимости Протокольных Данных (Protocol Data Convergence Protocol, PDCP);

расшифровывают сообщение; и

выполняют проверку целостности принятого сообщения.

49. Способ согласно варианту осуществления 48, в котором проверка целостности принятого сообщения выполняется до выполнения расшифровки сообщения.

50. Способ согласно любому из вариантов осуществления 48-49, дополнительно содержащий этап, на котором:

определяют позицию слова Кода Аутентификации Сообщения (Message Authentication Code, MAC) внутри принятого сообщения.

51. Способ согласно любому из вариантов осуществления 48-50, дополнительно содержащий этап, на котором:

определяют, удовлетворительны ли шифрование и защита целостности сообщения.

52. Способ согласно любому из вариантов осуществления 48-51, дополнительно содержащий этап, на котором:

указывают уровню Контроллера Радио Ресурсов (Radio Resource Controller, RRC) статус защиты принятого сообщения.

53. Способ согласно любому из вариантов осуществления 48-52, дополнительно содержащий этап, на котором:

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

54. Способ согласно любому из вариантов осуществления 48-53, дополнительно содержащий этап, на котором:

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

55. Способ согласно любому из вариантов осуществления 48-54, дополнительно содержащий этап, на котором:

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

56. Способ согласно любому из вариантов осуществления 48-55, дополнительно содержащий этап, на котором:

проверяют слово Кода Аутентификации Сообщения (Message Authentication Code, MAC) в уровне Контроллера Радио Ресурсов (Radio Resource Controller, RRC) PDCP, когда принятое сообщение закодировано по стандарту ASN.1.

57. Способ согласно любому из вариантов осуществления 48-56, в котором реализация процедуры защиты включает в себя, по меньшей мере, одно из следующего:

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

58. Способ согласно варианту осуществления 57, в котором отчет о сбое включает в себя причину сбоя.

59. Способ для обработки ключа в Беспроводном Блоке Передачи Приема (Wireless Transmit Receive Unit, WTRU) при переходе из режима EMM_Connected в режим EMM_Idle, содержащий этапы, на которых:

указывают объекту хранения в WTRU о переходе; и

удаляют первый набор ключей.

60. Способ согласно варианту осуществления 59, дополнительно содержащий этап, на котором:

сохраняют ключи защиты NAS и ключи ASME.

61. Способ согласно любому из вариантов осуществления 59-60, дополнительно содержащий этап, на котором:

удаляют ключи защиты NAS и ключи ASME.

62. Способ согласно любому из вариантов осуществления 59-61, в котором упомянутая индикация предоставляется посредством Слоя Без Доступа (Non-Access Stratum, NAS).

63. Способ согласно любому из вариантов осуществления 59-62, в котором упомянутая индикация предоставляется посредством Слоя с Доступом (Access Stratum, AS).

64. Способ согласно любому из вариантов осуществления 59-63, в котором упомянутая индикация предоставляется посредством предопределенных примитивов.

65. Способ согласно любому из вариантов осуществления 59-65, в котором упомянутая индикация предоставляется, когда меняется обслуживающий e-NB в режиме EMM_Idle.

66. Способ согласно любому из вариантов осуществления 59-66, в котором первый набор ключей включает в себя, по меньшей мере, один ключ из следующих: K_eNB, K_RRCenc, K_RRCint и K_UPenc.

67. Способ согласно любому из вариантов осуществления 59-67, в котором объект хранения удаляет K_RRCenc, K_RRCint и K_UPenc при получении упомянутой индикации.

68. Способ согласно любому из вариантов осуществления 59-68, в котором объект хранения удаляет K_eNB при получении упомянутой индикации.

69. Способ согласно любому из вариантов осуществления 59-69, дополнительно содержащий этап, на котором:

генерируют второй набор ключей при получении упомянутой индикации.

70. Способ согласно любому из вариантов осуществления 59-70, в котором упомянутая индикация указывает смену в обслуживающей ячейке.

71. Способ согласно любому из вариантов осуществления 59-71, в котором первый набор ключей включает в себя величину таймера.

72. Способ согласно любому из вариантов осуществления 5-72, дополнительно содержащий этап, на котором:

принимают ключи из уровня NAS или из USIM.

73. Способ согласно варианту осуществления 72, в котором принятые ключи передаются между уровнем Слоя Без Доступа (Non-Access Stratum, NAS) и уровнем RRC/PDCP посредством предопределенных примитивов.

74. Способ согласно любому из вариантов осуществления 73-75, в котором принятые ключи передаются между RRC и PDCP посредством предопределенных примитивов.

1. Способ для выполнения процедуры защиты Слоя Без Доступа (Non-Access Stratum, NAS) в беспроводной связи, содержащий этапы, на которых:
принимают сообщение NAS, которое включает в себя Порядковый Номер (Sequence Number, SN) NAS, протокольный заголовок и параметры защиты;
выполняют верификацию целостности сообщения NAS, причем упомянутое сообщение NAS коррелируется с величиной COUNT, которая включает в себя NAS SN и Номер Гиперкадра (Hyper-Frame Number, HFN) NAS;
в ответ на неуспешное завершение верификации целостности сообщения NAS не обрабатывают это сообщение NAS; и
в ответ на успешное завершение верификации принятого сообщения NAS обрабатывают это сообщение NAS согласно протокольному заголовку.

2. Способ по п.1, в котором сообщение NAS дополнительно включает в себя заголовок сообщения, который содержит дискриминатор протокола, октет типа сообщения, Идентификатор Транзакции (Transaction Identifier, TI) и дискриминатор подпротокола.

3. Способ по п.1, в котором NAS SN находится в принятом протокольном заголовке сообщения NAS.

4. Способ по п.1, в котором NAS SN принимается как содержимое Информационного Элемента (Information Element, IE).

5. Способ по п.2, в котором TI выполняет роль NAS SN.

6. Способ по п.1, в котором NAS SN имеет предварительно определенный период приращения или согласовываемый период приращения.

7. Способ по п.1, в котором величина COUNT увеличивается приращениями согласно предварительно определенной или согласовываемой схеме, и NAS увеличивается приращениями на некоторую величину через некоторое количество приращений NAS SN.

8. Способ по п.1, в котором невыполнение обработки сообщения NAS включает в себя, по меньшей мере, одно из игнорирования сообщения, отбрасывания сообщения, передачи отчета о сбое на другой протокольный уровень, инициации повторной аутентификации, перехода в режим Evolved Packet System (EPS) Mobility Management (EMM_Idle), перехода в состояние EMM_Deregistered, ведения счета количества сбоев, повторного присоединения к сети и удаления параметров защиты.

9. Беспроводной Блок Передачи Приема (Wireless Transmit Receive Unit, WTRU), сконфигурированный так, чтобы выполнять процедуру защиты Слоя Без Доступа (Non-Access Stratum, NAS) в беспроводной связи, причем упомянутый WTRU содержит:
приемник, сконфигурированный так, чтобы принимать сообщение NAS, которое включает в себя Порядковый Номер (Sequence Number, SN) NAS, протокольный заголовок и параметры защиты;
процессор, сконфигурированный так, чтобы выполнять верификацию целостности сообщения NAS, причем упомянутое сообщение NAS коррелируется с величиной COUNT, которая включает в себя NAS SN и Номер Гиперкадра (Hyper-Frame Number, HFN) NAS;
причем процессор дополнительно сконфигурирован так, чтобы в ответ на неуспешное завершение верификации целостности сообщения NAS не обрабатывать это сообщение NAS; и
процессор дополнительно сконфигурирован так, чтобы в ответ на успешное завершение верификации принятого сообщения NAS обработать сообщение NAS согласно протокольному заголовку.

10. Беспроводной Блок Передачи Приема (WTRU) по п.9, в котором сообщение NAS дополнительно включает в себя заголовок сообщения, который содержит дискриминатор протокола, октет типа сообщения, Идентификатор Транзакции (Transaction Identifier, TI) и дискриминатор подпротокола.

11. Беспроводной Блок Передачи Приема (WTRU) по п.9, в котором NAS SN находится в принятом протокольном заголовке сообщения NAS.

12. Беспроводной Блок Передачи Приема (WTRU) по п.9, в котором NAS SN принимается как содержимое Информационного Элемента (Information Element, IE).

13. Беспроводной Блок Передачи Приема (WTRU) по п.10, в котором TI выполняет роль NAS SN.

14. Беспроводной Блок Передачи Приема (WTRU) по п.11, в котором NAS SN имеет предварительно определенный период приращения или согласовываемый период приращения.

15. Беспроводной Блок Передачи Приема (WTRU) по п.9, в котором величина COUNT увеличивается приращениями согласно предварительно определенной или согласовываемой схеме, и NAS увеличивается приращениями на некоторую величину через некоторое количество приращений NAS SN.

16. Беспроводной Блок Передачи Приема (WTRU) по п.9, в котором невыполнение обработки сообщения NAS включает в себя, по меньшей мере, одно из игнорирования сообщения, отбрасывания сообщения, передачи отчета о сбое на другой протокольный уровень, инициации повторной аутентификации, перехода в режим Evolved Packet System (EPS) Mobility Management (EMM_Idle), перехода в состояние EMM_Deregistered, ведения счета количества сбоев, повторного присоединения к сети и удаления параметров защиты.