BRPI0812675B1

BRPI0812675B1 - método e dispositivo para implementar segurança em um dispositivo sem fio de evolução de longo termo

Info

Publication number: BRPI0812675B1
Application number: BRPI0812675A
Authority: BR
Inventors: Sammour Mohammed; S Wang Peter; P Mukherjee Rajat; Somasundaram Shankar
Original assignee: Interdigital Tech Corp
Priority date: 2007-07-18
Filing date: 2008-07-16
Publication date: 2020-04-14
Also published as: BRPI0812675A2; JP2010534959A; AU2008276061A1; KR20130114258A; WO2009012281A2; KR101468352B1; TW200920053A; WO2009012281A3; US8699711B2; EP2579635A3; EP2172069A2; MY152794A; ES2573257T3; CN104105091A; TW201244434A; CN101755469B; KR101102708B1; US9420468B2; KR101560848B1; CA2693185C

Abstract

método e dispositivo para implementar segurança em um dispositivo sem fio de evolução de longo termo. uma unidade de transmissão e de recepção sem fio (wtru) é configurada para receber mensagens codificadas e não codificadas. as mensagens não codificadas incluem uma requisição de identidade, uma requisição de autenticação e um modo de comando de estrato de não acesso à rede (nas), e respostas de atualização de acompanhamento na área. as mensagens codificadas podem vir de um nas e um controle de recurso do rádio (rrc). as mensagens sã codificadas por meio do uso de chaves de segurança.

Description

MÉTODO E DISPOSITIVO PARA IMPLEMENTAR SEGURANÇA EM UM DISPOSITIVO SEM FIO DE EVOLUÇÃO DE LONGO TERMO

CAMPO TECNOLÓGICO DA PRESENTE INVENÇÃO [001] O método e o dispositivo são relacionados aos sistemas de comunicação sem fio. De uma forma mais particular, o método e o dispositivo são relacionados à segurança em um dispositivo sem fio de acordo com a tecnologia de evolução de longo termo. ANTECEDENTES DA PRESENTE INVENÇÃO [002] O objetivo atual da evolução de longo termo (LTE) pertencente ao Projeto de Parceria para a Terceira Geração (3GPP) é o de trazer uma nova tecnologia, uma nova arquitetura e níveis métodos para novos ajustes e configurações LTE para que se propicie uma melhor eficiência espectral, e para que se reduza a latência para uma melhor utilização de recursos de rádio para uma que o usuário experimente uma sensação de maior velocidade e serviços a menor custo.

[003] Como uma parte deste projeto de evolução, o grupo 3GPP irá usar arquitetura diferente no LTE, da que é usada no sistema de telecomunicação móvel universal (UMTS). Com o propósito de comparação, use-se a chave de autenticação e de concordância (AKA) da autenticação UMTS, no domínio de pacote chaveado (PS), ser a linha de base para esta nova proposta LTE.

[004] A figura 1 exibe uma pilha de protocolo de acesso ao estrato 100 UMTS. O UMTS AKA e os procedimentos de codificação são distribuídos sobre múltiplas camadas de protocolos, e usam a sinalização tanto o estrato de não acesso à rede (NAS) como o controle de recurso do rádio (RRC), para alcançar os seus objetivos. Normalmente, a identificação e a autenticação de uma unidade de transmissão e de recepção sem fio (WTRU) é feito por meio de sinalização NAS. Uma vez que se ontem a autenticação ao nível NAS é conseguida, a codificação e/ou a proteção de integridade é ativada pela rede por meio do uso do comando Secutity mode Comand, o qual é uma mensagem RRC. Uma vez que a segurança é ativada por meio do uso do comando Secutity mode Comand à camada RRC, a WTRU passa a codificação e as chaves de integridade (CK e IK) para o acesso de camada (AS) usando a primitiva GMMAS-SECURITY-RESISTÊNCIA sobre o GMMAS-SAP (definido entre o gerenciamento de mobilidade GPRS (GMM) e o AS).

Petição 870190112661, de 04/11/2019, pág. 14/41

2/21 [005] Após a recepção destas chaves, o controle de recurso do rádio (RRC) 110 as repassa ao protocolo de controle de conexão de rádio (RLC) 120 e o controle de acesso ao meio (MAC) 130 usando a primitiva CRLC-CONFIG (sobre o C-SAP entre o RRC e o RLC) e a primitiva CMAC-CONFIG (sobre o C-SAP entre o RRC e o MAC). O C-SAP (o qual não é exibido) é uma sinalização de serviço de ponto de acesso para o C - plane sinalizando entre o RRC e a camada inferior. A codificação e a proteção à integridade é normalmente executada no protocolo de controle de conexão de rádio (RLC) 120, mas é feito no controle de acesso ao meio (MAC) 130 no caso de modo de trafego transparente do RLC. As camadas baixas (isto é, MAC/RLC) são responsáveis por garantir que a mensagem é dirigida às camadas superiores (por exemplo, as mensagens NAS da camada 3), tiveram a integridade protegida e/ou corrigida da forma adequada. Se não, as camadas mais baixas ignoram/cancelam a mensagem. Uma vez que a segurança foi ativada em todo o C plane e em todo U - plane a segurança é feita no RLC ou no MAC.

[006] Para o LTE, uma arquitetura radicalmente diferente para a segurança foi proposta. A maior diferença é que ao invés de uma única camada de segurança (isto é, no MAC/RLC), passam a existir três níveis de segurança: segurança NAS, segurança RRC e segurança de U - plane. Cada camada possui suas próprias chaves. A segurança NAS termina na entidade de gerenciamento de mobilidade (MME) e é executada na camada NAS. A segurança RRC termina no nó-B evoluído (E-Nó-B) e é executada no protocolo de convergência de pacotes de dados (PDCP). A segurança do U - plane consiste somente da codificação (nenhuma proteção à integridade) e também é executada Np PDCP. Em resumo, os procedimentos AKA são completados no NAS, e as chaves de segurança NAS são então derivadas. Os parâmetros de segurança RRC/U - plane são derivados em uma forma de codificação separadas das chaves NAS. O conhecimento das chaves RRC/U plane não permite a um atacante determinar as chaves NAS. A principal razão para essa decisão foi que em LTE alguém pode possuir Nós-B em localizações vulneráveis, tal como em uma casa. O RRC, e por tanto a segurança, é encerrada no nó-B evoluído, então isto é considerado como risco à segurança. Assim, dois níveis de segurança foram adotados para a norma.

[007] A figura 2 exibe um diagrama de blocos de hierarquia no LTE 200. Da forma

Petição 870190112661, de 04/11/2019, pág. 15/41

3/21 como é exibida na figura 2, o módulo de identificação universal de assinante (USIM) (em uma unidade de transmissão e de recepção sem fio (WTRU)) e o centro de autenticação (AuC) 205 compartilham um segredo K 210. Como parte de sinalização de uma chave de autenticação e de concordância (AKA) (similar aos atuais AKA para UMTS) o USIM e o AuC/HSS derivam uma chave codificada (CK) 215 e uma chaves de integridade (IK) 220 o procedimento para derivar a chave codificada (CK) 215 e a chaves de integridade (IK) 220 são similares, de tal forma que no UMTS, onde o AuC/HSS deriva um vetor de autenticação e envia um desafio para a WTRU em uma mensagem NAS, ao qual a WTRU responde, e o HSS/AuC verifica. Ao contrário do sistema de telecomunicação móvel universal (UMTS), no entanto onde a chave codificada (CK) 215 e a chaves de integridade (IK) 220 são fornecidas às camadas MAC/RLC para que executem a codificação e/ou a proteção de integridade, no LTE a chave codificada (CK) 215 e a chaves de integridade (IK) 220 são usadas para derivar as chaves remanescentes na hierarquia de chaves com uma chave mestre - a assim chamada chave KASME 225. As chaves restantes são derivadas da chave KASME usando diferentes funções de derivação de chave (KDF) e truncamento.

[008] A chave KeNB chave 230 é uma chave definida pela WTRU e a entidade de gerenciamento de mobilidade (MME) a partir da chave Kasme 225, ou pela WTRU e o nó-B evoluído de destino a partir da KeNB* durante um processo de handover de nó-B evoluído. A chave KeNB 230 é usada para a derivação das chaves para o tráfego RRC e a derivação das chaves para o tráfego UP, ou para derivar uma chave de transição KeNB* durante um processo de handover entre nós-B evoluídos.

[009] A chave KNASint 235 é uma chave a qual é usadap a proteção da integridade da sinalização NAS com um particular algoritmo de integridade. Esta chave é derivada pela WTRU e a entidade de gerenciamento de mobilidade (MME) 237, a partir da chave Kasme 225, da mesma forma que um identificador para um algoritmo de integridade que usa o KDF.

[0010] A chave KNASenc 240 é uma chave a qual é usada para a codificação NAS, sinalizando com um particular algoritmo de codificação. Esta chave é derivada da WTRU e da MME 237 a partir da chave Kasme 225, da mesma forma que um identificador para o

Petição 870190112661, de 04/11/2019, pág. 16/41

4/21 algoritmo de codificação usando uma funções de derivação de chave (KDF).

[0011] A chave KUPenc 245 é a chave a qual é usada para a codificação do tráfego UP com um particular algoritmo de codificação. Esta chave é derivada pela WTRU e o nó-B evoluído 247 a partir da chave KeNB túnel 230, da mesma forma que um identificador para o algoritmo de codificação usando uma funções de derivação de chave (KDF).

[0012] A chave KRRCint 250 é a chave a qual é usada para a proteção da integridade do tráfego RRC com um particular algoritmo de integridade. A chave KRRCint 250 é derivada, pela WTRU e usa o nó-B evoluído 247 a partir da chave KeNB túnel 230, da mesma forma que um identificador para o algoritmo de integridade que usa uma KDF.

[0013] A chave KRRCenc 255 é a chave que é usada para codificar a sinalização RRC com um particular algoritmo de codificação. A chave KRRCenc 255 é derivada pela WTRU e o nóB evoluído 247 a partir da chave KeNB 230, da mesma forma que um identificador para o Alf de codificação usando a KDF.

[0014] As chaves para o controle de recurso do rádio (RRC) e do U - plane podem ser derivadas usando o C-RNTI como entrada.

[0015] Em uma arquitetura de segurança de uma rede de acesso de rádio terrestre (UTRAN), uma verificação deve ser feita para a correta codificação e/ou integridade de proteção é feita na RLC ou na MAC. A única possível situação de falha no manuseio no NAS é se uma autenticação falhar. No entanto, com a codificação e proteção de integridade separadas no NAS, passa a ser desejável que se definam processos NAS em resposta às possibilidades nas quais uma magnéticos NAS é recebida sem que seja corretamente codificação e/ou ter a sua proteção de integridade.

[0016] O estrato de não acesso à rede (NAS) depende no acesso de camada (AS), isto é, na RLC ou na MAC, para verificar que qualquer mensagem recebida pela camada-3 (L3) tenha as credenciais corretas de segurança, isto é, onde a codificação e a proteção de integridade sejam adequadas. Uma vez que a nova arquitetura LTE, a qual a camada NAS possui segurança independente da segurança AS e que o NAS verifica a segurança das mensagens L3, esta abordagem não é adequada, pois a verificação da segurança do NAS é feita como uma parte de processos definidos no comportamento do NAS. Desta forma, é desejável para ações para o NAS venham a ser definidos, para o caso de uma falha.

Petição 870190112661, de 04/11/2019, pág. 17/41

5/21 [0017] Uma vez que as chaves NAS são independentes do RRC/chaves de U - plane (deste ponto em diante mencionados como chaves AS), é possível que se inicie/reconfigure a codificação NAS de forma independente da codificação AS/proteção de integridade. Também é desejável que se tenha novas mensagens e procedimentos para este processo. Além do mais, a perda da validade das chaves pode ser conectada ao estado NAS/RRC da WTRU. É desejável que se tenha um procedimento para a manipulação da chave pela WTRU.

[0018] O RRC normalmente recebe as novas CK e IK a partir do NAS e que os passe para a MAC e a RLC, onde codificação/proteção de integridade são executadas. No entanto, na LTE, a codificação e proteção de integridade AS serão executadas pelo protocolo de convergência de pacotes de dados (PDCP). Desta forma, é desejável que se tenham procedimentos e primitivas para uma nova camada cruzada, por motivos de segurança de funcionamento.

[0019] O escopo do documento 3GPP, 3rd Generation Partnership Project; Technical Specification Group \ Services and System Aspects; Rationale and track of security decisions in Long Term Evolved (LTE) RAN / 3GPP System Architecture Evolution (SAE) (Release 8), 3GPP TR 33.821.V0.4.0 é um justificativa e controle das decisões de segurança na Evolução de Longo Prazo (LTE) RAN/3GPP Evolução de Arquitetura do Sistema (SAE) (versão 8).

RESUMO [0020] Um método e um dispositivo relacionados aos sistemas de comunicação sem fio, os quais incluem uma unidade de transmissão e de recepção sem fio (WTRU) configurada para receber mensagens codificadas e não codificadas. As mensagens não codificadas podem incluir a requisição de identidade, a requisição de autenticação, os comandos de segurança do estrato de não acesso à rede (NAS) e as respostas de atualização de área. As mensagens codificadas podem vir do NAS e do controle de recurso do rádio (RRC). As mensagens, de uma forma preferível são codificadas por meio do uso de chaves de segurança.

BREVE DESCRIÇÃO DOS DESENHOS [0021] Uma compreensão mais detalhada da presente invenção pode ser obtida a

Petição 870190112661, de 04/11/2019, pág. 18/41

6/21 partir das seguintes descrições, dados por meio de exemplos, e para que sejam entendidas em conjunto com as figuras que acompanham o presente trabalho, onde:

- a figura 1 exibe uma pilha de protocolo de acesso ao estrato, de acordo com com o estado anterior da arte;

- a figura 2 exibe um diagrama de blocos de hierarquia de chave em ambiente LTE, de acordo com o estado anterior da arte;

- a figura 3 exibe um diagrama de blocos de uma das formas de realização para a presente invenção onde o agente pode ser o Gerenciador de Mobilidade equivalente na camada em LTE NAS, ou uma nova sub-camada para segurança, ou algum outro agente, e os parâmetros de segurança definidos para uma dada mensagem são incorretos;

- a figura 4 exibe um diagrama de blocos de um cabeçalho de protocolo de uma camada 3 melhorada, incluindo um número de seqüência NAS;

- a figura 5 exibe um diagrama de blocos ilustrando os procedimentos de manipulação de uma WTRU quando da transmissão de um modo EMM_Connected para o modo EMM_Idle;

- a figura 6 exibe um diagrama de blocos de uma pilha de protocolo de acesso ao estrato para LTE; e

- a figura 7 exibe um diagrama de blocos de um sistema de comunicação sem fio configurado para mensagens em LTE, tanto codificadas quanto não codificadas.

DESCRIÇÃO DETALHADA DA PRESENTE INVENÇÃO [0022] Quando for referido a partir deste ponto em diante, a terminologia unidade de transmissão e de recepção sem fio (WTRU) inclui, mas não está somente limitada a: a um equipamento de usuário (EU), a uma estação móvel, a uma unidade assinante fixa ou móvel, a um Pager, a um telefone celular, a um assistente digital pessoal (PDA), a um computador, ou a qualquer outro tipo de dispositivo de usuário o qual seja capaz de operar em um ambiente sem fio. Quando for referido a partir deste ponto em diante, a terminologia estação base, inclui, mas não está somente limitada a: um nó-B, um nó-B evoluído, um controlador de sítio, um ponto de acesso (AP), ou qualquer outro tipo de dispositivo de interface capaz de operar em um ambiente sem fio.

Falhas na segurança quando da manipulação NAS

Petição 870190112661, de 04/11/2019, pág. 19/41

7/21 [0023] Os procedimentos discutidos abaixo podem ser usados caso existam questões com relação à segurança em alguma outra camada, por exemplo, na camada PDCP, executando codificação/proteção de integridade. Um procedimento para manipular uma falha na segurança no NAS é o de proporcionar um grupo de mensagens NAS as quais podem ser recebidas por uma WTRU sem codificação e/ou proteção de integridade na NAS que está sendo ativada. Tal lista somente existe para mensagens UTRAN NAS, as quais são diferentes das mensagens LTE NAS, e podem ser recebidas sem que a codificação RLC/MAC seja ativada. O grupo de mensagens NAS as quais podem ser recebidas pela WTRU sem que a codificação e/ou a proteção de integridade na NAS venha a ser ativada pode incluir, mas não está somente limitada a:

Requisição de identidade;

Requisição de autenticação;

[0024] Modo de comando de segurança NAS (este pode somente ser recebido se ao menos uma proteção de integridade NAS esteja ativa); e

Resposta de atualização de posição.

[0025] Na entidade de gerenciamento de mobilidade (MME) as seguintes mensagens podem ser recebidas sem a codificação e/ou a proteção de integridade:

Resposta de identidade;

Resposta da autenticação; e

Requisição de atualização de posição.

[0026] Em adição, pode ser mandatório que enquanto as mensagens acima possam ser recebidas sem que o algoritmo de codificação e/ou proteção de integridade estejam ativos, se a codificação/proteção de integridade já esteja ativa, então estas mensagens devem ser codificadas/receber proteção de integridade.

[0027] Algumas outras mensagens NAS podem ser somente enviadas se a segurança tanto NAS como a RRC estiverem ativadas. Algumas mensagens NAS podem ser enviadas se a segurança NAS estiver ativa (independente da segurança RRC).

[0028] A figura 3 exibe um diagrama de blocos 300 de uma forma de realização onde o agente pode ser o equivalente à camada Gerenciamento de Mobilidade no LTE NAS, ou uma nova sub-camada para segurança ou algum outro agente. Uma vez que uma

Petição 870190112661, de 04/11/2019, pág. 20/41

8/21 mensagem seja recebida (305) o agente responsável pela verificação do estado da segurança da mensagem NAS será verificado, para que se confirme que a proteção de integridade para a mensagem seja apropriada (310). Se os parâmetros de segurança definidos por uma dada mensagem não são corretos (315), isto é, a verificação da integridade tenha falhado, ou a mensagem não está codificada, ou a mensagem (dependendo do protocolo discriminador e os tipos dos campos da mensagem, no cabeçalho) tenha sido recebida codificação e/ou com a proteção de integridade correta, mas não o seja, a camada NAS, suas sub-camadas ou o agente, pode tomar uma, ou todas, as ações que se seguem em qualquer seqüência. As ações tomadas podem depender do tipo de mensagem da qual os parâmetros de segurança falharam. Os procedimentos definidos abaixo também podem ser usados, caso existam questões com a segurança em alguma outra camada (por exemplo falha na segurança RRC):

[0029] A ação do agente pode ser definida pela implementação 320;

[0030] O agente pode ser desconsiderado e/ou eliminar a mensagem 325;

[0031] O agente pode relatar que a falha para algum outra camada de protocolo (por exemplo, RRC) entidade na WTRU (por exemplo, USIM/UICC) da rede 330. Caso o agente verifique a segurança e encontra um erro, pode-se acionar uma ação, por exemplo, uma mensagem para a rede informando a rede do erro. O relato pode incluir o motivo da falha. Se outros protocolos camadas/entidades tenham sido informadas de tal falha, a sua resposta pode ser similar àquelas descritas aqui;

[0032] O agente pode iniciar um processo de re-autenticação com a rede 355;

[0033] O agente pode mover para o modo de gerenciamento de mobilidade (EMM_Idle) do sistema de pacotes evoluído (EPS), ou o estado EMM_Deregistered 340;

[0034] O agente pode manter uma contagem do número de falhas e tomar alguma atitude quanto as falhas repetidas 345. Essa ações tem o mesmo efeito do que aquelas definidas aqui;

[0035] O agente pode tentar re-conectar com a rede 350; ou [0036] O agente pode apagar alguns, ou todos, os parâmetros de segurança (chaves, seqüências de números, conjunto de identificadores de chave) os quais podem estar armazenados, ou podem sinalizar a entidade na WTRU, tanto de forma direta com via um

Petição 870190112661, de 04/11/2019, pág. 21/41

9/21 intermediários, o qual armazena/gerencia os parâmetros de segurança, para fazê-lo 355. [0037] Caso os parâmetros de segurança estiverem corretos, a mensagem NAS pode ser processada como definida para o protocolo específico e tipo de mensagem 360. Como um exemplo, este agente pode especial ou reservado a camada de Gerenciamento de Mobilidade no LTE NAS, ou uma nova sub-camada para segurança ou algum outro agente. Impactos do protocolo da camada 3 [0038] O cabeçalho existente para a L3 não contém uma seqüência de números. Os cabeçalhos de uma mensagem padrão L3 são compostos por dois octetos. O cabeçalho é estruturado em três partes principais, o discriminador do protocolo (1/2 octeto), um octeto contendo um tipo de mensagem, e meio octeto. O meio octeto é usado em alguns casos como um Identificador de Transações, em alguns outros casos, como discriminar de subprotocolo, e chamado como indicador skip de outra forma. Por exemplo, se o Discriminador de Protocolo é definido para GMM, então ele pode ser usado como indicador de salto. Se o discriminador de protocolo é definido para SINAL MISTO, então ele pode ser usado como um TI ou como um discriminador de sub-protocolo. Caso seja usado como um indicador de salto, isso significa para as mensagens GMM, os 4 primeiros bits não tem significado e são então 'saltados'.

[0039] O discriminador de protocolos distingue entre mensagens de Gerenciamento de Mobilidade (MM), gerenciamento de mobilidade GPRS (GMM), gerenciador de seção (SM) e similares. Enquanto que o tipo de mensagem indica o tipo de mensagens, por exemplo, Attach Request ou ativação de contexto PDP, o identificador de transação permite as entidades pares na WTRU e na rede para distinguir até 16 diferentes fluxos de mensagens bi-direcionais diferentes, para um dado discriminador de protocolo e um dado serviço de ponto de acesso (SAP). Tal fluxo de mensagem é chamado uma transação. Um mecanismo de extensão para um identificador de transação (TI) também é definido. Este mecanismo permite distinguir até 256 fluxos de mensagens bi-direcionais diferentes para um dado protocolo e um dado SAP. Por exemplo, quando uma WTRU tenta obter um endereço IP, existe uma entidade SM na WTRU e na rede. Se a WTRU tentar obter outro endereço IP, outro par de entidades SM são criadas na WTRU e na rede. A TI identifica a transação, isto é, par, uma mensagem SM particular é intencionada.

Petição 870190112661, de 04/11/2019, pág. 22/41

10/21 [0040] Na figura 4 está exibido um diagrama de blocos de um cabeçalho 400 de protocolo L3 melhorado, incluindo um número de seqüência NAS 410. Como no existente cabeçalho de protocolo L3, o cabeçalho melhorado é composto por dois octetos, e estruturado em três partes principais. As três partes principais são o discriminador de protocolo 420 (1/2 octeto), um octeto identificador de tipo de mensagem, e 1/2 octeto usado em alguns casos como um identificar de transação 430, em alguns outros casos como um discriminador de sub-protocolos, e chamado indicador de salto, de outra forma. Por exemplo, se o discriminador de protocolo é definido para GMM então pode ser usado como indicador de salto. Se o discriminador de protocolo é definido para SM então pode ser usado como um TI ou um discriminador de sub-protocolo. Se é usado como indicador para salto, significa que, para mensagens GMM os primeiros 4 bits não tem significado e devem ser 'saltados'. O cabeçalho melhorado inclui um número de seqüência para a mensagem NAS 410, deste ponto em diante referido como NAS SN. Pode ser incluído no cabeçalho do protocolo de uma mensagem NAS ou como elemento de informação (EI) em seu conteúdo. O elemento identificador de transação pode também funcionar como número seqüencial. O NAS SN pode ter um período de incremento pré-definido ou negociado. Como um exemplo, ele pode ser por base me NAS PDU (isto é mensagem). A camada NAS pode ser capaz de executar detecção duplicada com base na seqüência de números ou usando qualquer outro número o qual incrementa usando o NAS SN, onde os PDUs NAS recebidos são descartados.

[0041] O NAS SN pode ser mantido por portadora de radio sinalizando AS, ou por SAP, independente do protocolo discriminador ou do tipo da mensagem. Ele também pode ser mantido por TI.

[0042] Um valor COUNT pode ser usado na camada NAS. Incrementando o valor de COUNT em uma forma pré-definida e/ou negociada, por exemplo, em cada mensagem L3, pode proteger contra repetição ou ataques de impersonificação. Isto é possível com o nível de codificação NAS. Um único valor para COUNT pode ser definido por todos os SAPs. Um único COUNT-C pode ser definido para codificação e um único COUNT-I para a proteção de integridade, para todos os SAPs.

[0043] Uma combinação de COUNT-C e/ou COUNT-I e/ou valores únicos para COUNT

Petição 870190112661, de 04/11/2019, pág. 23/41

11/21 podem ser definidos para os SAPs. O COUNT pode consistir de dois parâmetros: um número seqüencial NAS (SN) o qual incrementa de uma forma regular por meio de prédefinição e/ou negociado, por exemplo: por protocolo de unidade de dados (PDU) NAS período de oportunidade por NAS PDU em um dado SAP, a um número hiper-frame NAS (NAS HFN). O NAS HFN pode ser um contador o qual incrementa por 1 por x números de NAS SN incrementados. O parâmetro COUNT, no seu todo, ou em, partes, pode ser inicializado com base em um valor START durante a transição acesso-inicial/derivação de chave/autenticação/transição ocioso-para-ativo (initial-accesslkey-derivationlauthentication lidle-to-active transition). O parâmetro COUNT pode ser usado como entrada para os algoritmos codificação/descodificação proteção de integridade/verificação de integridade, para que se assegure a segurança.

[0044] O valor COUNT pode necessitar que venha a ser definido antes da ativação sistema de acesso segurança NAS. O comprimento do parâmetro COUNT-C pode ser de 32 bits, ou pode ser reduzido para um valor menor uma vez que um grande SN pode não ser requerido para as mensagens NAS. Também, o comprimento do campo SN e do próprio campo HFN podem ser modificados dentro do parâmetro COUNT-C, para que o otimize para os procedimentos para os procedimentos de nível NAS. As máquinas de codificação de acordo com o estado anterior da arte podem ser usadas para o NAS. uma mudança apropriadadeve ser feita no motos de codificação para que se acomode um valor menor o COUNT-C, ou mude o valor dos campos do SN e do HFN.

[0045] De uma forma alternativa, o valor para o NAS COUNT, pode ser o NAS sinal dado que o NAS SN pode ser protegido pele codificação RRC, assim ele não é aberto e portanto nenhum HFN escondido é necessário. A segurança NAS pode ser ativada não antes que a segurança RRC e o NAS SN possam ser redefinidos quando das ativações de segurança NAS. Em adição, detecções duplicadas no NAS pode ser executada usando valor NAS COUNT.

[0046] Parâmetros adicionais no lugar do comprimento da mensagem ou portadora ID as quais são entradas para o motor de codificação precisam ser definidos, ou procedimentos adicionais precisam ser definidos no NAS, para que se extraiam esses parâmetros quando a camada NAS codifica a mensagem.

Petição 870190112661, de 04/11/2019, pág. 24/41

12/21 [0047] De uma forma alternativa, do lado da WTRU, ao invés de ser ter dois motores de codificação separados, para o RRC e o NAS, um único motor de codificação pode funcionar tanto com os parâmetros RRC quanto com os do NAS.

[0048] Codificação adicional das mensagens no nível NAS pode ser opcional e a WTRU pode indicar, na informação das suas capacidades, se suporta codificação no nível NAS, ou não.

Manipulação da chave na WTRU quando da transição do modo EMM Cinnected para o modo EMM Idle [0049] Normalmente, quando a WTRU faz a transição do medido EMM_Connected para o modo EMM_Idle, a conexão com o RRC é liberada. Na transição de ativo para ocioso, um nó-B evoluído normalmente não armazena informação de estado sobre a WTRU correspondente. O nó-B evoluído normalmente apaga as chaves do dado momento de sua memória.

[0050] Para esta forma de realização, em particular, na transição de ativo para ocioso, o nó-B evoluído pode apagar ao menos um dos seguintes elementos: keNB, Krrc e KRRCint e KUPenc. No entanto, o MME pode armazenar o Kasme.

[0051] A figura 5 exibe um diagrama de blocos ilustrando os procedimentos de manipulação de chaves 500 em uma WTRU, quando da transição do modo EMM_Connected para o modo MME_Idle. Até então, os procedimentos das WTRUs não foram definidos em resposta a esta transição. Um procedimento possível seria o de, quando da transição para o estado MME_Idle 510, uma indicação da transição pode ser fornecida pela WTRU para a entidade a qual armazena a chaves de segurança chave de segurança 520 na WTRU, tal como o UICC, o USIM ou equipamento móvel. Outro procedimento possível é o de uma identificação que pode ser fornecida chave de segurança 520 pela WTRU, para a entidade de armazenamento quando o nó-B evoluído servente muda enquanto que em modo MME_Idle 530, tal como durante uma re-seleção de célula para um diferente nó-B evoluído. A indicação a partir da WTRU para a entidade de armazenamento pode incluir a identidade do nó-B evoluído de tal forma que se pode derivar as chaves do novo nó-B evoluído, do RRC e do U - plane. O método de acordo com qualquer uma das formas de realização exemplo, a indicação pode ser fornecida pelo

Petição 870190112661, de 04/11/2019, pág. 25/41

13/21

NAS e/ou AS. Para este propósito, primitivas pré-determinadas, incluindo mensagens, elementos de informação, e SAPs entre as camadas de protocolo de indicação da identidade e/ou entre a entidade de indicação e a entidade de armazenamento podem ser definidas. É entendido que primitivas pré-determinadas incluem ambos, as primitivas existentes e as novas, as quais podem ser usadas. Quando da recepção de uma indicação, a entidade de armazenamento dentro da WTRU, de forma preferível irá apagar a chave apropriada 540, por exemplo, ao menos um dentre os KeNB, o KRRCenc, e o KUPenc. Pode ser decidido manter ou apagar as chaves de segurança NAS e mas chaves ASME 550.

[0052] A entidade de armazenamento pode eliminar KRRCenc, o KRRInt e o KUPenc quando da recepção de uma indicação da transição de ativo para ocioso e apaga o KeNB quando uma indicação de uma mudança na nó-B evoluído servente é recebida, tal como durante a re-seleção, para um nó-B evoluído diferente. Pode-se optar por manter, ou apagar a chaves de segurança NAS e as chaves ASME. Quando da re-seleção de uma célula que pertença a um diferente nó-B evoluído, determinada pela leitura da identificação do nó-B evoluído no canal de transmissão, a WTRU pode gerar um novo K*Enb usando o KeNB e um próximo identificador de salto.

[0053] A entidade de armazenamento não pode apagar qualquer chave durante a transição de Ativa para Ociosa, ou quando da transição para um novo nó-B evoluído no modo Ocioso, enquanto que ele pode apagar chaves quando da transição de Ocioso para Ativo.

[0054] A entidade de armazenamento não pode apagar qualquer chave durante a transição de Ativa para Ociosa, ou quando da transição para um novo nó-B evoluído no modo Ocioso. Ao invés, pode apagar-las quando novas chaves são geradas, por exemplo, quando um nó-B evoluído recebe uma requisição RRC_Connection ou uma nova C-RNTI é alocada.

[0055] Uma mudança de ID/C-RNTI na célula servente pode estação repetidora indicada 560 para a entidade de armazenamento. Essa indicação pode ser fornecida pelo NAS e/ou AS. De uma forma alternativa, as chaves podem ser armazenadas com um valor de temporizador 570. Quando a WTRU passa de Ociosa para Ativa , o tempo pode controlar quanto tempo uma chave permanece válida antes que venha eventualmente a

Petição 870190112661, de 04/11/2019, pág. 26/41

14/21 ser apagada.

Impactos da camada PDCP devido a arquitetura de codificação proposta [0056] Normal mente, o tráfego para a codificação é para RRC e U - plane pode ser feita na camada PDCP. Isto impõe muitas mudanças na arquitetura no PDCP.

[0057] Nesta forma de realização para a presente invenção, a camada PDCP tem a capacidade de receber as chaves de segurança RRC e as chaves de segurança do U plane, das camadas superiores. Primitivas podem ser definidas conforme a necessidade. Mais especificamente, o RRC ou o NAS ou o USIM podem fornecer o PDCP com as chaves de codificação necessárias, e o START ou COUNT necessários, ou os valores HFN ou SN. A camada PDCP pode também possuir a habilidade com calcular esses valores por si, com base na informação do cabeçalho RRC.

[0058] Fazendo-se referência a figura 1, o trafego do C - plane não passa através do PDCP. Uma vez que diferentes portadoras de rádio podem estar seguras usando diferentes parâmetros COUNT, é preferível que a camada PDCP seja capaz de distinguir entre diferentes tipos de tráfegos. Para estes SDUs que chegam ou as primitivas transportando os SDUs pode ter informação explícita, com relação às portadoras de rádio destinadas. A camada PDCP pode definir que para si mesma e codificar/proteção de integridade.

[0059] A figura 6 exibe um diagrama de blocos de uma pilha de protocolo de acesso ao estrato para o LTE 600. Fazendo-se referência a figura sexto trafego do plano-U passa através da camada PDCP 610. A camada PDCP 610 verifica a segurança dos PDUs PDCP que estão chegando. Se a camada PDCP 610 percebe que os parâmetros de segurança de uma PDU que está chegando (isto é, deve ser mapeada tanto a uma Portadora de Rádio para Dados, ou uma Portadora de Rádio para Sinalização) não estão corretas, (isto é, se, por exemplo, a verificação da integridade da PDU PDCP falha) pode executar ao menos uma das seguintes ações, em qualquer seqüência. As ações tomadas podem depender do tipo de mensagem das quais os parâmetros se segurança falharam. Os procedimentos definidos abaixo podem também ser usados se existem questões com a segurança em alguma outra camada, por exemplo, se a segurança NAS falhar:

As ações de PDCP podem ser definidas pela implementação;

O PDCP pode ser desconsiderado e/ou elimina-se a mensagem;

Petição 870190112661, de 04/11/2019, pág. 27/41

15/21

Podem-se relatar as falhas para alguma outra camada de protocolo, tal como a entidade RRC na WTRU; qualquer camada de protocolo pode ser informada de tal falha;

Pode-se manter a contagem do número de falhas e tomar algumas ações quando das falhas repetidas (por exemplo, X número de falhas em Y mensagens, ou unidades de tempo), de tal forma que aqui foi definido, ou algumas outras ações;

Pode-se eliminar alguns ou todos os parâmetros de segurança, tais como: chaves e números de seqüência, os quais estão armazenados, ou podem sinalizar a entidade na WTRU, direta ou indiretamente, que armazena ou gerencia os parâmetros de segurança para fazê-lo, e [0060] Um relatório de falha para outra camada de protocolo pode incluir o motivo dessa falha.

[0061] O PDCP HFN pode ser usado para constituir um valor COUNT. Este valor COUNT pode ser usado nos algoritmos de codificação/e/ou proteção de integridade do PDCP 510 e pode ser inicializado pelo valor START. Pode haver múltiplos valores COUNT para cada portadora de rádio que o PDCP pode proteger. O RRC 620 e as camadas PDCP 610 podem ser capazes de trocar informação relacionada para o valor COUNT ou os seus constituintes.

[0062] A camada PDCP 610 pode fazer uma verificação, para a proteção de integridade da mensagem. Isto está de acordo com a assunção que a proteção de integridade está Na camada PDCP 610. No entanto, a palavra de código de autenticação de mensagem (MAC) anexada a uma mensagem, para que se verifique a sua integridade, é calculada no RRC 620, anexado a mensagem RRC e passada para baixo, para a RLC 630/controle de acesso ao meio (MAC) 640. Toda a mensagem , incluindo a palavra MAC é codificada. Também, a camada PDCP 610 pode não ser capaz de definir se uma mensagem RRC necessita proteção.

[0063] Do lado da transmissão, a camada RRC 620 pode indicar que a camada PDCP 610, se uma dada mensagem RRC necessita ou não necessita de proteção de integridade e/ou codificação. A camada PDCP 610 pode usar esta indicação para definir se deve ou não executar codificação e/ou proteção de integridade na mensagem RRC para ser enviada como PDUs PDCP.

Petição 870190112661, de 04/11/2019, pág. 28/41

16/21 [0064] Esta indicação pode ser uma indicação explícita fornecida pelo RRC para a camada PDCP, em cada mensagem RRC enviada pelo RRC para o PDCP usando novos bits. De uma forma alternativa ou adicional, a indicação pode ser implícita, por exemplo, codificação e/ou proteção de integridade no PDCP irá sempre ativa, a não ser que indicado, ou estará sempre desativado a não ser que indicada de outra forma pelo RRC. Como um exemplo, um indicador pode ser usado pela camada RRC 620 para indicar qualquer combinação de codificação e de proteção de integridade sendo ativas. Tal indicação pode ser enviada com cada mensagem RRC passada para o PDCP, ou pode ser aplicada a todas as mensagens RRC e, de forma preferível como algumas mensagens RRC podem não ser codificação e/ou ter a proteção de integridade.

[0065] De uma forma alternativa, ou em adição, a camada RRC 620 pode indicar para a camada PDCP 610 que todas as mensagens RRC iniciando com uma dada mensagem RRC devem ter a proteção de integridade.

[0066] De uma forma alternativa, ou em adição, a camada RRC 620 pode indicar à camada PDCP 610 que todas as mensagens RRC iniciando com uma dada mensagem RRC serão codificadas.

[0067] De uma forma alternativa, ou em adição, a camada RRC 620 pode indicar para a camada PDCP 610 que todas as mensagens RRC iniciando com uma dada mensagem RRC serão codificadas e terão a proteção de integridade.

[0068] De uma forma alternativa, ou em adição, a camada RRC 620 pode proporcionar uma lista de mensagens RRC genéricas para a camada PDCP 610 e os seus parâmetros de segurança associados. A lista deve incluir mensagens que podem ser recebidas sem codificação e/ou proteção de integridade, tal como, por exemplo, um re-estabelecimento de conexão RRC. A lista pode incluir mensagens as quais podem ser recebidas com codificação e/ou proteção de integridade.

[0069] De uma forma alternativa, ou em adição, um marcador de uma codificação e/ou proteção de integridade pode ser definido, de forma opcional pela camada RRC 620, o qual, se definido, fará com que a camada PDCP 610 codificação e/ou proteção de integridade todas as mensagens RRC. A camada PDCP 610 irá, desta forma verificar esse marcador antes de codificar e efetuar a proteção de integridade. Pode haver marcadores

Petição 870190112661, de 04/11/2019, pág. 29/41

17/21 separados definidos para codificação e a proteção de integridade.

[0070] Para todos os mecanismos de indicação acima, a indicação pode ser fornecida com base em sinalização de portadora de rádio (CRB), isto é, a camada RRC 620 pode indicar para a camada PDCP 610 que a indicação para codificação e/ou proteção de integridade se aplica a mensagens RRC mapeadas pela camada PDCP 610 para um SRB específico.

[0071] Por todos estes mecanismos diferentes de indicação acima, a indicação deve ser fornecida de uma forma de por base na sinalização de portadora de rádio (SRB), isto é, a camada RRC 620 pode indicar a camada PDCP 610 que uma indicação para codificação e/ou proteção de integridade se aplica às mensagens RRC mapeadas pela camada PDCP 610 para um SRB específico.

[0072] Para uma mensagem ser transmitida, a camada PDCP 610 pode primeiramente proteger a integridade e então codificar, ou pode ser primeiramente codificação e então fazer a proteção de integridade. Anteriormente a ambos, ela pode trimar a mensagem de tal forma que atinja o comprimento ótimo, para a codificação e/ou a proteção de integridade. Antes da operação de segurança a camada PDCP 610 pode designar um SN. O SN pode ser um SN PDCP, ou pode reutilizar um SN RRC, ou pode usar uma outra seqüência de números, tal como, por exemplo, uma seqüência comum de números. Antes da operação de segurança, a camada PDCP 610 pode executar uma compreensão no cabeçalho para o tráfego do plano-U.

[0073] A palavra MAC para a proteção de integridade pode ser calculada sobre dados de testo normal, dos dados codificados e/ou uma parte do cabeçalho PDCP.

[0074] A codificação pode ser executada sobre toda a mensagem, incluindo a palavra MAC, e/ou mensagens simples de texto e/ou as suas partes.

[0075] A codificação pode também ser executada sobre toda, ou uma parte do cabeçalho PDCP, por exemplo, excluindo para SN.

[0076] Uma indicação se a carga paga foi codificação e/ou teve a proteção de integridade, pode ser incluída. Por exemplo, a camada PDCP 610 do lado transmissor pode incluir um elemento de informação indicando informação sobre a presença de proteção de integridade e/ou a codificação sendo ativada. Esta indicação pode ser codificada.

Petição 870190112661, de 04/11/2019, pág. 30/41

18/21 [0077] Esta indicação pode indicar a posição da palavra MAC, dentro da mensagem para a camada PDCP para verificar. A camada PDCP 610 do lado do receptor pode usar esta indicação para decidir se decodifica e/ou verifica a proteção de integridade.

[0078] A camada PDCP 610 e protocolo podem incluir uma palavra MAC para a verificação da integridade em uma posição PDCP pré-definida, dentro do cabeçalho/mensagem a ser recebida.

[0079] Dependendo da ordem da segurança da operação no lado da transmissão, o PDCP receptor poderá tanto primeiramente decodificar uma primeira mensagem que chega e depois verifica a sua integridade, ou primeiramente verifica a integridade e depois decifra a mensagem. As operações de segurança na unidade receptora, de uma forma preferível, é executada na ordem inversa com relação aquela da unidade de transmissão. A posição da palavra MAC dentro do cabeçalho/mensagem PDCP pode ser assistida por um como por de indicação.

[0080] A camada PDCP 610 pode decidir se a codificação e/ou a integridade de proteção não é satisfatória para uma mensagem em particular. Isto significa que o PDCP irá definir se, ou não, a mensagem foi decodificada e/ou teve a proteção de integridade da forma correta.

[0081] A camada PDCP 610 pode indicar para a camada RRC, o estado da segurança das mensagens que estão passando para a camada RRC 620, por exemplo, se a mensagem foi recebida com a codificação e a proteção de integridade. Ou como outro exemplo, se a proteção de integridade foi feita com sucesso, ou não. A indicação pode ser implícita, isto é, somente fornecida quando existe um erro, por exemplo, se a proteção de integridade falhou. A camada RRC 620 pode então decidir se a proteção para uma mensagem em particular é aceitável. O comportamento da RRC, quando notificada de que um erro pode ser definido para o PDCP no parágrafo [0064]. De uma forma alternativa, ou em adição, a camada RRC pode notificar a rede de uma falha na verificação de integridade, para,da adição de um elemento de informação (para a mensagem RRC ela envia para a rede) a qual informa a rede da falha.

[0082] No caso de erro, a camada PDCP 610 pode tomar os passos descritos NAS situações de manipulação de falha, descritos acima. Se a mensagem RRC é codificada

Petição 870190112661, de 04/11/2019, pág. 31/41

19/21 como ASNtraje (1) e a palavra MAC está incluída na camada RRC 620, a ;610 pode verificar concessão agendada camada RRC e verificar a palavra MAC. Ela também pode fazê-lo se o marcador indicando proteção de integridade está ativo.

Procedimentos de segurança em camadas [0083] A camada RRC/PDCP pode receber as chaves do nó-B evoluído/RRC/plano-U da camada NAS ou do USIM. De forma alternativa, o RRC/PDCP pode gerar suas próprias chaves. Como um exemplo, a camada RRC pode gerar as chaves do nó-B evoluído/RRC/plano-U por meio do uso de parâmetros recebidos a partir da rede RRC, sinalizando e o KASME recebido a partir da NAS e outros parâmetros recebidos a partir de outras camadas de protocolos (por exemplo, identidade física da célula da célula a qual a WTRU se encontra acampada naquele dado momento, ou acessando, pode ser obtida a partir da camada física). Estas chaves de segurança podem ser passadas entre o NAS e o RRC/PDCP, ou entre o RRC e o PDCP usando primitivas pré-determinadas, incluindo novas primitivas existentes, sobre um SAPs novos, ou já existentes. Cada camada pode ter a habilidade de indicar um erro, isto é, uma falha na segurança, NAS camadas superiores/interiores.

[0084] A figura 7 exibe um diagrama de blocos de um sistema de comunicação sem fio 700, configurado para codificar e descodificar mensagens em LTE. O sistema inclui uma estação base 705 e uma unidade de transmissão e de recepção sem fio (WTRU) 710. A estação base 705 e a unidade de transmissão e de recepção sem fio (WTRU) 710 se comunicam por meio de conexão de comunicação sem fio.

[0085] Como foi exibido na figura 7, a unidade de transmissão e de recepção sem fio (WTRU) 710 inclui um transmissor 720, um receptor 730 e um processador 740. O processador 740 é conectado a um buffer 750 e a uma memória 760. O processador 740 é configurado para processar mensagens NAS contendo parâmetros de segurança, usando ao menos uma das técnicas descritas acima.

[0086] Também exibido na figura 7, está a estação base 705 a qual inclui um transmissor 765, um receptor 770, e um processador 780. O processador 780 é anexado ao buffer 790 e a uma memória 795. O processador 780 é configurado para processar mensagens NAS contendo parâmetros de segurança, usando ao menos uma das técnicas

Petição 870190112661, de 04/11/2019, pág. 32/41

20/21 descritas acima.

[0087] Apesar de que todas as características e elementos da presente invenção sejam descritas na forma das formas preferenciais de realização, e em combinações em particular, cada característica ou elemento podem ser usados sozinhos, sem outras características e elementos das formas preferenciais de realização, ou então em diversas combinações, com ou sem outras características e elementos da presente invenção. Os métodos ou os gráficos de fluxos oferecidos na presente invenção podem vir a ser implementados por meio de programa de computador, software, ou firmware que sejam tangívelmente incorporados em um meio de armazenamento capas de ser lido por meio de computador, para a execução por meio de um computador de propósito geral ou um processador. Exemplos para meio de armazenamento capas de ser lido por meio de computador incluem as memórias de somente leitura (ROM), as memórias de acesso aleatório (RAM), um registrador, uma memória cache, um dispositivo semicondutor de memória, meios magnéticos tais como um disco rígido interno, um disco removível, meios óptico-magnéticos, e meios ópticos tais como discos CD-ROM, e discos versáteis digitais (DVDs).

[0088] Como processadores adequados pode-se incluir, mas não limitar, por meio de exemplos, um processador para propósito geral, um processador para propósito específico, um processador convencional, um processador de sinal digital (DSP), uma grande variedade de processadores, um ou mais processadores em associação com um núcleo DSP, um controlador, um micro controlador, um circuito integrado para aplicações específicas (ASIC), um circuito Gate Array programável em campo (FPFA), ou qualquer outro tipo de circuito integrado (CI), e/ou maquina de estado.

[0089] Um processador em associação com software pode ser usado para que se implementes os transceptores de rádio freqüência para o uso em uma unidade de transmissão e de recepção sem fio (WTRU), um equipamento de usuário (EU), um terminal, uma estação base, um controlador de rede de rádio (RNC), ou qualquer computador hospedeiro. A WTRU pode ser usada em conjunto com módulos implementados por meio de hardware e/ou software, tais como uma câmera, um módulo de câmera de vídeo, um videofone, um telefone de fala, um dispositivo de vibração, um

Petição 870190112661, de 04/11/2019, pág. 33/41

21/21 alto-falante, um microfone, um transceptor de televisão, um auricular de mãos livres, um teclado, um módulo Bluetooth®, uma unidade de rádio freqüência modulada (FM), uma unidade de visor de cristal liquido (LCD), uma unidade de exibição diodo emissor de luz orgânico (OLED), um reprodutor de música digital, um reprodutor de mídias, um modulo para vídeo-game, um navegador para a Internet, e/ou qualquer módulo de rede de área local sem fio (WLAN).

Claims

Reivindicações

1. Método para executar um procedimento de segurança NAS (estrato de não acesso à rede) em comunicações sem fio, o método sendo caracterizado por compreender:

- receber (305) uma mensagem NAS que inclui um número de sequência NAS (SN NAS) (410) e um cabeçalho de protocolo (400);

- executar uma verificação de integridade (310) na mensagem NAS por meio do uso de um valor COUNT como entrada para um algoritmo de integridade, sendo que o valor COUNT compreende um SN NAS (410) e um contador NAS que incremente em um por um número predeterminado de incrementos no SN NAS;

- em resposta à mensagem NAS recebida que falhe (315) na verificação de integridade (310), descartar a mensagem NAS; e

- em resposta à mensagem NAS recebida que passe na verificação de integridade (310), processar a mensagem NAS.
2. Método, de acordo com a reivindicação 1, caracterizado por a mensagem NAS adicionalmente inclui um cabeçalho de mensagem (400), o qual compreende um discriminador de protocolo (420), um octeto do tipo de mensagem, um identificador de transação (TI) (430) e um sub-protocolo discriminador.
3. Método, de acordo com a reivindicação 1, caracterizado por o SN NAS estar no cabeçalho do protocolo (400) recebido da mensagem NAS.
4. Método, de acordo com a reivindicação 1, caracterizado por o SN NAS (410) ser recebido como conteúdo de um elemento de informação (IE).
5. Método, de acordo com a reivindicação 2, caracterizado por as TI (30) funcionarem como SN NAS.
6. Método, de acordo com a reivindicação 1, caracterizado por o SN NAS (410) possuir um período de incremento pré-definido, ou um incremento de período negociado.
7. Método, de acordo com a reivindicação 1, caracterizado por o valor de COUNT aumentar em uma base predefinida ou negociada.
8. Método, de acordo com a reivindicação 1, caracterizado por, quando não processar a mensagem NAS incluir ao menos um dos seguintes elementos: desconsiderar

Petição 870190112661, de 04/11/2019, pág. 35/41

2/3 (325) a mensagem NAS, eliminar (325) a mensagem NAS, relatar (330) a falha para outra camada de protocolo, iniciar (335) uma re-autenticação, mover (340) para o modo Mobility Management (EMM_Idle) do sistema de pacotes evoluído (EPS), movendo-se (340) para o estado EMM_Deregisted, manter (345) a contagem do número de falhas, proceder com a re-conexão (350) para a rede, e eliminar (355) os parâmetros de segurança.
9. Unidade de transmissão/recepção sem fio (WTRU) configurada para executar um procedimento de segurança no estrato de não acesso à rede (NAS) em comunicações sem fio, a WTRU (710) sendo caracterizada por compreender:

- um receptor (730) configurado para receber uma mensagem NAS que inclui um número de sequência NAS (SN NAS) e um cabeçalho de protocolo;

- um processador (740) configurado para executar uma verificação de integridade na mensagem NAS por meio do uso de um valor COUNT como entrada para um algoritmo de integridade, sendo que o valor COUNT compreende um SN NAS e um contador NAS que aumenta em um por um número predeterminado de incrementos no SN NAS;

- em resposta à mensagem NAS recebida que falhe na verificação de integridade, o processador (740) é configurado ainda para descartar a mensagem NAS; e

- em resposta à mensagem NAS recebida que passe na verificação de integridade, processador (740) é configurado ainda para processar a mensagem NAS.
10. WTRU, de acordo com a reivindicação 9, caracterizada por a mensagem NAS adicionalmente incluir uma mensagem de cabeçalho a qual compreende o discriminador de protocolo, um octeto do tipo de mensagem, um identificador de transação (TI) e um discriminador de sub-protocolo.
11. WTRU, de acordo com a reivindicação 9, caracterizada por o SN NAS estar no cabeçalho do protocolo recebido da mensagem NAS.
12. WTRU, de acordo com a reivindicação 9, caracterizada por o SN NAS ser recebido como um elemento de informação (IE).
13. WTRU, de acordo com a reivindicação 10, caracterizada por o TI funcionar como o SN NAS.
14. WTRU, de acordo com a reivindicação 11, caracterizada por o SN NAS ter um

Petição 870190112661, de 04/11/2019, pág. 36/41

3/3 período de incremento pré-definido, ou um período de incremento negociado.
15. WTRU, de acordo com a reivindicação 9, caracterizada por o valor de COUNT aumentar em uma base predefinida ou negociada.
16. WTRU, de acordo com a reivindicação 9, caracterizada por, quando não processar a mensagem NAS incluir ao menos um dos seguintes elementos: desconsiderar a mensagem NAS, eliminar a mensagem NAS, relatar a falha para outra camada de protocolo, iniciar uma re-autenticação, mover para o modo Mobility Management (EMM_Idle) do sistema de pacotes evoluído (EPS), movendo-se para o estado EMM_Deregisted, manter a contagem do número de falhas, proceder com a re-conexão para a rede, e eliminar os parâmetros de segurança.