BRPI0707583A2 - obscurecimento de identidade temporÁrias de equipamento de usuÁrio - Google Patents

obscurecimento de identidade temporÁrias de equipamento de usuÁrio Download PDF

Info

Publication number
BRPI0707583A2
BRPI0707583A2 BRPI0707583-9A BRPI0707583A BRPI0707583A2 BR PI0707583 A2 BRPI0707583 A2 BR PI0707583A2 BR PI0707583 A BRPI0707583 A BR PI0707583A BR PI0707583 A2 BRPI0707583 A2 BR PI0707583A2
Authority
BR
Brazil
Prior art keywords
message
received
processor
ues
crc
Prior art date
Application number
BRPI0707583-9A
Other languages
English (en)
Inventor
Nathan Edward Tenny
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of BRPI0707583A2 publication Critical patent/BRPI0707583A2/pt
Publication of BRPI0707583A8 publication Critical patent/BRPI0707583A8/pt
Publication of BRPI0707583B1 publication Critical patent/BRPI0707583B1/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5038—Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/75—Temporary identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Medicines That Contain Protein Lipid Enzymes And Other Medicines (AREA)

Abstract

OBSCURECIMENTO DE IDENTIDADES TMPORÁRIAS DE EQUIPAMENTO DE USUÁRIO. São descritas técnicas para ocultar identificadores temporários (IDs) atribuidos a equipamentos de usuário (UEs) por um sistema de comunicação sem fio. Em uma entidade de rede, um primeiro ID atribuído a um UE e possivelmente um valor salt são transformados, por exemplo, com base em uma função hash, para obter um segundo ID para o UE. Uma mensagem de saída dirigida ao UE é gerada com base em uma mensagem de entrada, o segundo ID e o valor salt (caso presente). A mensagem de saída é enviada via um canal comum compartilhado pelo UE e outros UEs. No UE, uma mensagem é recebida via o canal comum, e um valor salt (caso enviado) é obtida a partir da mensagem recebida. O primeiro ID e o valor salt são transformados para obter o segundo ID, que é utilizado para determinar se a mensagem recebida é destinada ao UE.

Description

"OBSCURECIMENTO DE IDENTIDADES TEMPORÁRIAS DE EQUIPAMENTODE USUÁRIO"
O presente pedido reivindica prioridade paraPedido U.S. provisório Número de Série 60/771.974,depositado em 10 de fevereiro de 2006, intitulado"OBSCURING TEMPORARY USER EQUIPMENT IDENTITIES," e PedidoU.S. Provisório Número de Série 60/786.463, depositado em27 de março de 2006, intitulado "DOWNLINK DATA SCHEDULINGWITH OPAQUE UE IDENTITIES IN E-UTRAN," ambos cedidos àcessionária do presente pedido e incorporados aqui a titulode referência.
FUNDAMENTOS
I.Campo
A presente descrição refere-se, geralmente, àcomunicação, e mais especificamente a técnicas paraobscurecer identidades em comunicação sem fio.
II. Fundamentos
Redes, de comunicação sem fio são amplamenteaplicadas para prover vários serviços de comunicação comovoz, video, dados em pacote, troca de mensagens, broadcast,etc. Uma rede de comunicação sem fio pode incluir muitosNós Bs (ou estações base) que podem se comunicar com muitosequipamentos de usuário (UEs). Os UEs podem ser atribuídosa vários identificadores ou identidades (IDs) utilizadospara identificar exclusivamente esses UEs para váriasfinalidades. Em certas ocorrências, os IDs de UE podem serenviados pelo ar livre sem nenhuma cifragem. Isso podetornar possível,para um espião (eavesdropper) ou adversário(attacker) montar um ataque de capacidade de link pormonitorar um canal de comunicação para mensagens edeterminar quais mensagens são dirigidas ao mesmo UE com opassar do tempo. 0 ataque de capacidade de link pode sercapaz de ligar mensagens a UEs específicos porém pode nãoser capaz de determinar as verdadeiras identidades dos UEs.
0 ataque de capacidade de link pode ser utilizado pararastrear as localizações dos UEs e também pode ser a basede outros ataques de segurança mais severos. Por exemplo, oadversário pode ser capaz de determinar qual ID de UE éatribuído a um UE específico por iniciar uma chamada paraaquele UE e observar quais IDs de UE são utilizadosaproximadamente ao mesmo tempo.
Há, portanto, necessidade na área por técnicaspara combater ataques de capacidade de link sem imporcargas computacionais excessivas sobre os UEs e entidadesde rede.
SUMARIO
Técnicas para ocultar IDs temporários atribuídosaos UEs por uma rede de comunicação sem fio são descritasaqui. Essas técnicas podem ser utilizadas para vários tiposde mensagens endereçadas a UEs específicos e enviadas livresem cifragem via canais comuns. Essas técnicas podem serutilizadas para melhorar a segurança, por exemplo, parafrustrar ataques de capacidade de link.
Em um aspecto, em uma entidade de rede (porexemplo, um Nó Β), um primeiro ID atribuído a um UE podeser transformado para obter um segundo ID para o UE. 0primeiro ID pode ser um Identificador Temporário de RedeRádio (RNTI) atribuído ao UE no Sistema de TelecomunicaçãoMóvel Universal (UMTS) ou algum outro tipo de ID em algumoutro sistema de comunicação. 0 primeiro ID e possivelmenteum valor salt (que é um valor não-estático) pode sertransformado com base em uma função hash para obter osegundo ID. Uma mensagem de saída dirigida ao UE pode sergerada com base em uma mensagem de entrada, o segundo ID, eo valor salt (caso presente). A mensagem de entrada podeser uma mensagem de paging, uma mensagem de programação quecontém informações de programação, uma mensagem deatribuição de recursos, etc. A mensagem de saida pode serenviada via um canal comum compartilhado pelo UE e outrosUEs.
Em outro aspecto, no UE, uma mensagem pode serrecebida via canal comum, e um valor salt (caso enviado)pode ser obtido a partir da mensagem recebida. O primeiroID e o valor salt (se enviado) podem ser transformados paraobter o segundo ID, que pode ser utilizado para determinarse a mensagem recebida é destinada ao UE.
Vários aspectos e características da descriçãosão descritos em detalhes adicionais abaixo.
BREVE DESCRIÇÃO DOS DESENHOS
A figura 1 mostra uma rede UMTS.
A figura 2 mostra transmissões para Acesso emPacote Downlink com alta Velocidade (HSDPA).
As figuras 3A e 3B mostram dois desenhos paratransformar um RNTI.
A figura 4A mostra um processador que envia umRNTI transformado livre.
A figura 4B mostra um processador que incorporaum RNTI transformado em uma mensagem.
A figura 5 mostra um processo para enviarmensagens de sinalização para um UE.
A figura 6 mostra um aparelho para enviarmensagens de sinalização para um UE.
A figura 7 mostra um processo para recebermensagens de sinalização em um UE.A figura 8 mostra um aparelho para recebermensagens de sinalização em um UE.
A figura 9 mostra um diagrama de blocos de um UE,um Nó B e um RNC.
DESCRIÇÃO DETALHADA
As técnicas descritas aqui podem ser utilizadaspara várias redes de comunicação como redes de AcessoMúltiplo por Divisão de Código (CDMA), redes de AcessoMúltiplo por Divisão de Tempo (TDMA), redes de AcessoMúltiplo por Divisão de Freqüência (FDMA), redes FDMAOrtogonais (OFDMA), redes FDMA de Portadora Única (SC-FDMA), etc. Os termos "redes" e "sistemas sãofreqüentemente utilizados de forma intercambiável. Uma redeCDMA pode implementar uma tecnologia de rádio como Acessode Rádio Universal Terrestre (UTRA), UTRA evoluído (E-UTRA), cdma2000, etc. UTRA e E-UTRA fazem parte de UMTS.UTRA inclui CDMA-de banda larga (W-CDMA) e Taxa de ChipBaixa (LCR). Cdma2000 abrange padrões IS-2000, IS-95 e IS-856. Uma rede TDMA pode implementar uma tecnologia de rádiocomo Sistema Global para Comunicação Móvel (GSM). Uma redeOFDMA pode implementar uma tecnologia de rádio comoEvolução de Longa Duração (LTE), IEEE 802.20, Flash-OFDM®,etc. UTRA, E-UTRA, UMTS, GSM e LTE são descritos emdocumentos a partir de uma organização denominada "3rdGeneration Partnership Project" (3GPP). Cdma2000 é descritonos documentos a partir de uma organização denominada "3rdGeneration Partnership Project 2" (3GPP2). Essas váriastecnologias de rádio e padrões são conhecidas na técnica.
Para clareza, certos aspectos das técnicas são descritasabaixo para UMTS, e terminologia 3GPP é utilizado em grandeparte da descrição abaixo.
A figura 1 mostra uma rede UMTS 100 que incluiuma Rede de Acesso de Rádio Universal Terrestre (UTRAN) euma rede núcleo 140. A UTRAN inclui múltiplos Nós Bs 110 eum Controlador de Rede Rádio (RNC) 130. Um Nó B égeralmente uma estação fixa que se comunica com os UEs etambém pode ser referido como um Nó B intensificado, umaestação base, um ponto de acesso, etc. Cada Nó B 110 provêcobertura de comunicação para uma área geográficaparticular e suporta comunicação para os UEs localizadosdentro da área de cobertura. O termo "célula" pode sereferir a um Nó B e/ou sua área de cobertura dependendo docontexto no qual o termo é utilizado. RNC 130 acopla-se aosNós Bs 110 e provê coordenação e controle para esses NósBs. RNC 130 também origina e termina mensagens para certosprotocolos e aplicativos. Rede núcleo 140 pode incluirvárias entidades de rede que suportam várias funções comoroteamento de pacote, registro de usuário, gerenciamento demobilidade, etc.
UEs 120 podem ser dispersos por toda a rede UMTS,e cada UE pode ser estacionário ou móvel. Um UE pode sertambém referido como uma estação móvel, um terminal, umterminal de acesso, uma unidade de assinante, uma estação,etc. Um UE pode ser um telefone celular, um assistentedigital pessoal (PDA), um dispositivo sem fio, umdispositivo portátil, um modem sem fio, um computadorlaptop, etc. Um UE pode se comunicar com um ou mais Nós Bsno downlink e/ou uplink em qualquer dado momento. Odownlink (ou link direto) refere-se ao link de comunicaçãoa partir dos Nós Bs para os UEs, e o uplink (ou linkreverso) refere-se a um link de comunicação a partir dosUEs para os Nós Bs.
Em UMTS, dados e sinalização para os UEs sãoprocessados como canais lógicos em uma camada de Controlede Radioenlace (RLC). Os canais lógicos incluem um Canal deTráfego Dedicado (DTCH), um Canal Compartilhado de Downlink(DSCH), um Canal de Controle Dedicado (DCCH), um Canal deControle Comum (CCCH), etc. Os canais lógicos são mapeadospara transportar canais em uma camada de Controle de acessoao Meio (MAC). Os canais de transporte carregam dados paravários serviços como voz, video, dados em pacote, etc. Oscanais de transporte são mapeados para canais físicos emuma camada física. Os canais físicos são canalizados comdiferentes códigos de canalização e são ortogonais entre sino domínio de código.
Um UE em UMTS pode ser atribuído a uma variedadede IDs utilizados para identificar o UE para váriasfinalidades. Esses IDs de UE podem ter diferentes contextosou escopos (por exemplo, célula, área de paging, etc.) e/oudiferentes períodos de vida útil (por exemplo, temporárioou permanente) ; Por exemplo, o UE pode ser atribuído avários RNTIs que podem ser utilizados como IDs temporários.A tabela 1 lista alguns RNTIs que podem ser atribuídos aoUE e provê uma descrição curta de onde cada RNTI pode serutilizado. Os C^RNTI e U-RNTI podem ser atribuídos ao UEpor um RNC em serviço e pode ser estendido para uma conexãoRRC em uma célula particular. 0 C-RNTI pode ser utilizadopara mensagens enviadas no DTCH e DSCH. 0 U-RNTI pode serutilizado para mensagens paging enviadas em um Canal dePaging (PCH) e para mensagens enviadas no DCCH. Os DSCH-RNTI, H-RNTI e E-RNTI podem ser estendidos para uma célulaparticular e utilizados para sinalizar mensagens enviadasno DSCH, um Canal Compartilhado de Downlink com altaVelocidade (HS-DSCH) e um Canal de Concessão Absoluta E-DCH(E-AGCH), respectivamente. Esses vários RNTIs podem sercoletivamente referidos como "X-RNTIs" e podem serutilizados como IDs temporários em contexto local paraendereçar o UE para mensagens de sinalização enviadas porControle de Recursos de Rádio (RRC) e protocolos MAC. Os X-RNTIs podem ser atribuídos por diferentes entidades de rededentro do UTRAN (ou simplesmente, o UTRAN). Cada X-RNTIpode ser utilizado para sinalizar mensagens permutadasentre a entidade de rede de atribuição e o UE receptor.
Tabela 1
<table>table see original document page 8</column></row><table>
Os X-RNTIs podem ser atribuídos a um UE em váriostempos pela UTRAN. As atribuições podem ocorrer viasinali zação nao cifrada devido à ausência de uma relação desegurança preexistente entre a UTRAN e UE no momento deatribuição. Entretanto, na atribuição de uma X-RNTI, aUTRAN endereça tipicamente o UE por uma Identidade deAssinante Móvel Temporário (TMSI) ou uma TMSI de Pacote (P-TMSI), que é atribuída ao UE em sinalização cifrada em umacamada de Estrato de Não Acesso (NAS). Desse modo, umadversário pode observar qual X-RNTI foi atribuído por umamensagem downlink, porém, na ausência de conhecimentoadicional da TMSI ou P-TMSI, não seria capaz de determinarqual UE estava recebendo a atribuição.
Após um X-RNTI ser atribuído a um ÜE, o X-RNTIpode ser enviado livre sem cifragem em sinalização downlinke/ou uplink. Por exemplo, mensagens para UEs específicospodem ser enviadas no CCCH e endereçadas aos UEs receptorespor seus U-RNTIs. Essas mensagens podem ser enviadas emradioportador de sinalização 0 (SRBO) e seriam não cifradasuma vez que SRBO pode conter mensagens para UEs que não têmainda uma relação de segurança com a UTRAN. Para mensagensenviadas não cifradas em um canal comum, um adversário podeser capaz de determinar que uma mensagem foi dirigida paraum X-RNTI ou UE específico. Embora o adversário possa nãosaber a identidade desse UE fora do contexto de rádio, asinformações disponíveis podem tornar possível se agregarinformações sobre mensagens dirigidas ao mesmo UE em umdenominado "ataque de capacidade de link". 0 adversáriopode monitorar informações de programação não cifradasenviadas em um canal de controle e pode ser capaz dedeterminar transmissões de dados endereçadas ao mesmo UE. 0adversário pode então rastrear potencialmente a mobilidadede UEs individuais entre células durante uma sessão dedados. Em qualquer caso, mensagens enviadas livres em umcanal comum pode resultar em uma vulnerabilidade desegurança que pode levar a ameaças mais graves desegurança.
Técnicas para reduzir vulnerabilidade desegurança devido à transmissão de mensagens livres em umcanal comum são descritas aqui. Essas técnicas podem serutilizadas para várias mensagens de sinalização enviadas emvárias camadas, As técnicas podem ser também utilizadaspara downlink e uplink. Para clareza, as técnicas sãodescritas abaixo para transmissão de informações deprogramação e mensagens paging no downlink em UMTS.
3GPP Release 5 e posteriores suportam HSDPA, queé um conjunto de canais e procedimentos que permitem atransmissão de dados em pacote com alta velocidade nodownlink. Para HSDPA, um Nó V envia dados no HS-DSCH, que éum canal de transporte downlink que é compartilhado portodos os UEs tanto em tempo como em código. 0 HS-DSCH podeconter dados para um ou mais UEs em cada intervalo de tempode transmissão (TTI) . Para HSDPA, um quadro de 10milissegundos (ms) é dividido em cinco subquadros de 2 ms,cada subquadro cobre três partições de tempo, e cadapartição de tempo tem uma duração de 0,667 ms. Para HSDPA,um TTI é igual a um subquadro e é a menor unidade de tempona qual um UE pode ser programado e servido. A partilha doHS-DSCH é dinâmica e pode alterar de TTI para TTI. Dadospara o HS-DSCH são enviados em um Canal Compartilhado deDownlink Fisico em Alta Velocidade (HS-PDSCH), esinalização para o HS-PDSCH é enviada em um Canal deControle Compartilhado para HS-DSCH (HS-SCCH).
Para HSDPA, um Nó B pode utilizar até quinzecódigos de canalização de 16 chips com fator deespalhamento de 16 para o HS-PDSCH. 0 nó B pode utilizartambém qualquer número de códigos de canalização de 128chips com fator de espalhamento de 128 para HS-SCCH. 0número de códigos de canalização de 16 chips para o HS-PDSCH e o número de códigos de canalização de 128 chipspara o HS-SCCH são configuráveis. Os códigos de canalizaçãopara o HS-PDSCH e HS-SCCH são códigos de fator deespalhamento ,variável ortogonal (OVSF) que podem sergerados em um modo estruturado. 0 fator de espalhamento(SF) é o comprimento de um código de canalização. Umsímbolo é espalhado com um código de canalização decomprimento SF para gerar chips SF para o símbolo.
Na descrição a seguir, HSDPA é considerado comotendo (a) até quinze HS-PDSCHs, com cada HS-PDSCHcorrespondendo a um código de canalização de 16 chipsdiferentes, e (b) qualquer número de HS-SCCHs, com cada HS-SCCH correspondendo a um código de canalização de 128 chipsdiferentes. Um UE pode ser atribuído até quatro HS-SCCHs naconfiguração da chamada e pode monitorar os HS-SCCHsatribuídos durante a chamada. O UE pode ser atribuído atéquinze HS-PDSCHs em um dado TTI. Os HS-PDSCHs podem serdinamicamente atribuídos e transferidos para o UE viasinalização enviada em um dos HS-SCCHs atribuídos para oUE.
A figura 2 mostra transmissões de exemplo nos HS-SCCHs e HS-PDSCHs para HSDPA. Um nó B pode servir um oumais UEs em cada TTI. 0 Nó B envia uma mensagem desinalização para cada UE programado nos HS-SCCHs e enviadados para o UE nos HS-PDSCHs duas partições depois. Asmensagens de sinalização enviadas nos HS-SCCHs sãoendereçadas a UEs J específicos com base nos H-RNTIsatribuídos a esses UEs. Cada UE que poderia receber dadosnos HS-PDSCHs processa seus HS-SCCHs atribuídos em cada TTIpara determinar se uma mensagem de sinalização foi enviadapara aquele UE. Cada UE pode casar as mensagens desinalização recebidas nos HS-SCCHs com seu H-RNTI paradeterminar se qualquer mensagem de sinalização é destinadaàquele UE. Cada UE que é programado em um TTI dado podeprocessar os HS-PDSCHs para recuperar os dados enviadospara aquele UE.
No exemplo mostrado na figura 2, um UE deinteresse (UE #1) monitora quatro HS-SCCHs #1 até #4atribuídos ao UE. UE #1 não é programado em TTl n, enenhuma mensagem de sinalização é enviada para UE #1 emqualquer HS-SCCHs. UE #1 é programado em TTI η + 1, e umamensagem de sinalização é enviada para o UE em HS-SCCH #1.
A mensagem de sinalização pode transferir vários parâmetrospara a transmissão enviada nesse TTI. UE #1 não éprogramado em TTI η + 2, é programado em TTI η + 3, ereceber uma mensagem de sinalização em HS-SCCH #2, e não éprogramado em TTI η + 4.
Outros RNTIs podem ser utilizados para outrasmensagens de sinalização enviadas para UEs específicos emcanais comuns. Por exemplo, mensagens de atribuiçãoenviadas no E-AGCH são endereçadas a UEs específicos combase nas E-RNTIs atribuídas a esses UEs. Mensagens depaging são endereçadas a UEs específicos com base nos U-RNTIs atribuídas a esses UEs.
Em geral, um X-RNTI pode ser enviada em umamensagem de sinalização transmitida no downlink e pode serutilizada por cada UE para casar contra seu próprio X-RNTIpara determinar se a mensagem de sinalização é destinadaàquele UE, isto é, para determinar "essa mensagem é paramim?" Todas as informações no X-RNTI podem não sernecessárias para esse processo de casamento uma vez que oespaço possível de valores de X-RNTI não possa estar cheio.
O X-RNTI pode ter 16 bits (ou 32 bits) de comprimento epode prover identidades para muitos mais UEs do que um Nó Bpode ser capaz de endereçar a qualquer momento. Porexemplo, o Nó B pode ter atribuído somente 1024 identidadesna faixa de 0 a 1023. Nesse caso, somente 10 bits menossignificativos (LSBs) do X-RNTI podem ser utilizados paraidentificar exclusivamente um dado UE. O Nó B pode enviarentão valores aleatórios para os bits mais elevados epermitir que cada UE reconheça mensagens dirigidas àqueleUE olhando somente os bits inferiores, que contêm a porção"real" da identidade. O envio de valores aleatórios para osbits mais elevados pode resultar em muitos valores de X-RNTI diferentes sendo enviados para qualquer UE dado, o quepode mitigar ataque de capacidade de link. Entretanto, esseesquema de "truncamento" é essencialmente transparente. Umadversário que está ciente do esquema pode penetrartrivialmente no mesmo e examinar os bits inferiores paradeterminar quais mensagens são endereçadas aos mesmos UEs.
Em um aspecto, um X-RNTI pode ser transformadocom base em uma função, e um RNTI transformado (em vez doX-RNTI original) pode ser enviada em uma mensagem desinalização. Um UE que já conhece o X-RNTI pode ser capazde determinar se a mensagem de sinalização é destinada aoUE com base no RNTI transformada. Entretanto, um adversáriosem conhecimento prévio do X-RNTI pode ser incapaz dedeterminar a X-RNTI original com base no RNTI transformadoenviado na mensagem. A transformação pode ser executada devárias maneiras.
A figura 3A mostra um projeto para transformar umX-RNTI. Uma unidade 310 recebe o X-RNTI, transforma o X-RNTI com base em uma função de transformar Hr e provê umRNTI transformado que é indicado como H (X-RNTI) . A funçãode transformar pode ser uma função irreversível que tornadifícil determinar o X-RNTI original a partir do RNTItransformado. Por exemplo, a função de transformar pode seruma função hash segura/criptográfica que mapeia umamensagem (por exemplo, o X-RNTI) para uma compilação (porexemplo, o RNTI transformado) e tem propriedadescriptográficas de modo que (i) a função entre a mensagem esua compilação é irreversível e (ii) a probabilidade deduas mensagens mapeando para a mesma compilação é muitopequena. A saída da função hash pode ser mencionada comouma compilação, uma assinatura, um valor que sofreu hash,etc.
O RNTI transformado pode ser enviado em umamensagem de sinalização e pode permitir casamento damensagem pelas UEs. Cada UE pode aplicar a mesma função detransformar o seu X-RNTI para obter um RNTI transformado.
Cada UE pode casar então o RNTI transformado em umamensagem recebida com o RNTI transformado localmente geradopara determinar se a mensagem é destinada para aquele UE.
0 RNTI transformado pode evitar que um adversárioinfira o X-RNTI original. Entretanto, caso o mesmo RNTItransformado seja incluído em cada mensagem de sinalizaçãoenviada para um dado UE, então o adversário pode realizarum ataque de correlação. Para evitar isso, o RNTItransformado pode ser mudado com cada mensagem.
A figura 3B mostra um projeto para transformar umX-RNTI para obter diferentes RNTIs transformados. Umaunidade 320 recebe o X-RNTI e um valor salt σ, transforma oX-RNTI e o valor salt com base em uma função de transformarHa, e provê um RNTI transformado que é indicado como Ha
(X-RNTI). A função de transformar pode ser uma funçãoirreversível, yma função hash criptográfica, etc. Um valorsalt é um valor não estático que pode ser selecionado dequalquer modo. Valores salt diferentes podem ser utilizadospara diferentes mensagens de sinalização de modo que umúnico X-RNTI possa originar RNTIs transformadas diferentespara diferentes mensagens.
Um RNTI transformado e um valor salt σ podem serenviados em uma mensagem de sinalização e podem permitircasamento da mensagem pelos UEs. 0 valor salt σ pode serenviado livre juntamente com o RNTI transformado. O valorsalt σ e/ou o RNTI transformado pode ser também incorporadona mensagem de sinalização. Em qualquer caso, cada UE podecasar seu X-RNTI contra o RNTI transformado na mensagem desinalização. Cada UE pode aplicar a função de transformarHa em seu X-RNTI e o valor salt σ extraído a partir damensagem e pode então comparar o RNTI transformadogeralmente localizada com o RNTI transformado recebido namensagem de sinalização.
A figura 4A mostra iam diagrama de blocos de umprojeto de um processador de mensagem 410 que envia um RNTItransformado livre em uma mensagem de sinalização.Processador de mensagem 410 recebe uma mensagem de entradae um X-RNTI para um UE receptor e gera uma mensagem desaída dirigida ao UE.
No processador de mensagem 410, uma unidade 420recebe um X-RNTI e possivelmente um valor salt σ, aplicauma função de transformar no X-RNTI e possivelmente o valorsalt σ, e provê um RNTI transformado. Um multiplexador(Mux) 422 multiplexa o RNTI transformado, o valor salt σ(caso presente), e uma mensagem de entrada. Umencodificador 424 encodifica a saída de multiplexador 422 eprovê uma mensagem de saída. Processador de mensagem 410pode ser utilizado para mensagens de paging enviadas naPCH. Nesse caso, o ID de UE ou X-RNTI na figura 4A podecorresponder o U-RNTI.
A figura 4B mostra um diagrama de blocos de umprojeto de um processador de mensagens 450 que incorpora umRNTI transformado em uma mensagem de sinalização.Processador de mensagens 450 recebe uma mensagem de entradae um X-RNTI para um UE receptor e gera uma mensagem desaída dirigida ao UE. A mensagem de entrada podecompreender vários trechos de informações.
No processador de mensagens 4 50, uma unidade 460recebe um X-RNTI e possivelmente um valor salt σ, aplicauma função transformar no X-RNTI e possivelmente o valorsalt σ, e provê um RNTI transformado. Um multiplexador 4 62recebe e multiplexa informações de sinalização Xa e Xb e ovalor salt σ (caso presente) e provê informaçõesmultiplexadas X1. Um encodificador 464 encodifica asinformações multiplexadas Xi e provê informaçõescodificadas. Uma unidade 4 66 mascara as informaçõescodificadas com base no RNTI transformado e provêinformações mascaradas Si. Um multiplexador 472 recebe emultiplexa informações de sinalização Xc até Xf e provêinformações multiplexadas X2. Uma unidade 474 gera um testede redundância cíclica (CRC) com base em informações Xi eX2, a seguir mascara o CRC com o RNTI transformado paraobter um CRC específico de UE, e anexa o CRC específico deUE às informações X2. Um encodificador 47 6 encodifica asaída da unidade 474 e provê informações codificadas R2. Ummultiplexador 478 recebe e multiplexa as informaçõesmascaradas Si e as informações codificadas R2 e provê asinformações multiplexadas Si e R2 como uma mensagem desaída.
Processador de mensagens 450 pode ser utilizadopara mensagens de sinalização enviadas no HS-SCCHs. Nessecaso, Xa pode compreender informações de conjunto de códigode canalização, Xb pode compreender informações de esquemade modulação, Xc pode compreender informações de tamanho debloco de transporte, Xd pode compreender informações deprocesso HARQ, Xe pode compreender informações de versão deconstelação e redundância, Xf pode compreender informaçõesde indicador de dados novos, e o X-RNTI pode corresponderao H-RNTI. Informações Si podem ser enviadas na primeirapartição de um TTI, e informações R2 podem ser enviadas nasduas últimas partições do TTI. Nesse caso, o valor salt σpode ser multiplexado com informações Xa e Xb enviadas naprimeira partição do TTI, como mostrado na figura 4B. Issopode permitir detecção prematura da mensagem de sinalizaçãopelos UEs, sem ter de esperar para que a mensagem inteiraseja recebida.
A figura 4A mostra um projeto no qual um RNTItransformado é enviado livre em uma mensagem desinalização. 0 RNTI transformado pode ser também enviadolivre de outras maneiras. A figura 4B mostra um projeto noqual um RNTI transformado é incorporado em uma mensagem desinalização. A incorporação do RNTI transformado pode sertambém obtida de outras maneiras. Por exemplo, uma mensagemde sinalização enviada no E-AGCH pode incluir um CRCespecifico de UE que pode ser gerado com base em um E-RNTItransformado. Em geral, um RNTI transformado pode serenviado de várias maneiras (por exemplo, livre ouincorporado) em uma mensagem de sinalização de tal modo queum UE receptor possa identificar a mensagem como sendodirigida àquele UE.
Como mostrado na figura 2, um UE pode recebermúltiplas mensagens de sinalização (por exemplo, atéquatro) em cada TTI e pode verificar cada mensagem recebidapara determinar se a mensagem é destinada ao UE. A funçãode transformar deve ser simples de forma computacional demodo que o UE possa aplicar a função de transformar paracada mensagem recebida sem causar impacto adverso sobre odesempenho. De modo ideal, o casamento de mensagem com oRNTI transformado deve exigir somente algumas instruçõesadicionais além do que é normalmente feito para casar o X-RNTI.
Para o projeto mostrado na figura 3B, um UE podearmazenar uma tabela de consulta de RNTIs transformadosobtidas por hashing seu X-RNTI com todos os valores saltpossíveis. Os RNTIs transformados podem ser desse modo pré-computados uma vez e armazenados para uso posterior, em vezde ser computada sempre que mensagens de sinalização foremrecebidas. Para cada mensagem recebida, o UE pode extrair ovalor salt a partir da mensagem recebida, recuperar o RNTItransformado para aquele valor salt a partir da tabela deconsulta, e verificar a mensagem recebida com o RNTItransformado recuperado.
A UTRAN pode atribuir um novo X-RNTI para um UEvia sinalização cifrada no início de uma chamada epossivelmente durante a chamada. Versões transformadas donovo X-RNTI podem ser enviadas através do ar livremente umavez que somente o UE tem a versão que não sofreu hash. Umadversário pode não ter informações suficientes paraexecutar casamento de mensagens de sinalização enviadas comos RNTIs transformados. O adversário pode monitorar todasas mensagens de sinalização em uma célula durante umperíodo de tempo e correlacionar essas mensagens desinalização por manter um banco de dados de todos os X-RNTIs possíveis e checar cada mensagem recebida contratodos os X-RNTIs. Esse tipo de espionagem determinado podeser combatido por atribuir periodicamente novos X-RNTIs aosUEs.
Várias funções de transformar podem serutilizadas para gerar RNTIs transformados. Em geral, umafunção de transformar deve ter as seguintes qualidades:
Computação fácil e rápida (ou sensível a umatabela de consulta no UE);
RNTI transformado e valor salt devem serpequenos;
. Difícil ou impossível de reverter; e. Fácil para o UTRAN proteger contra colisões.Um equilíbrio pode ser feito entre as qualidadeslistadas acima para um dado aplicativo. Diferentes funçõesde transformar com diferentes características podem serutilizadas para diferentes aplicativos. Por exemplo, asinalização na Camada 2 pode favorecer alta eficiência debits e rápida decodificação e pode ser capaz de aceitar umnível de segurança mais baixo como resultado. Sinalizaçãona Camada 3 pode favorecer segurança mais forte às custasde maior overhead.
A importância de uma função altamenteirreversível pode depender do nível de determinaçãoassumido por parte de um adversário. Uma função detransformar pode simplesmente mascarar alguns bits emposições variáveis a partir do X-RNTI e pode utilizar ovalor salt para selecionar os bits mascarados. Essa funçãode transformar pode ser suscetível a um ataque de forçabruta no qual o adversário coleta mensagens de sinalização,experimenta todos os valores possíveis para os bitsdeletados, e observa para ver quais dos valores resultantessão repetidos., 0 adversário pode presumir que os valoresrepetidos são os X-RNTIs reais de vários UEs e podearmazenar esses valores para teste contra futuras mensagensde sinalização. Entretanto, isso pode representar um ataquesignificativamente mais laborioso do que a espionagemcasual normalmente associado a ataques de capacidade delink.
Mesmo se uma função de transformar for de umcerto modo fraca de modo criptográfico, o UTRAN podeatribuir novos X-RNTIs via sinalização cifrada. Nesse caso,um adversário pode não ter automaticamente um grupo de X-RNTIs conhecidos para testar mensagens recebidas contra. Àluz da capacidade de atribuir novos X-RNTIs, a intensidadecriptográfica da função de transformar pode ser consideradamenos importante do que a computação simples e conservaçãode bit através do ar.
Uma função de transformar pode ser definida combase em vários projetos. Por exemplo, uma função detransformar pode incorporar princípios de projetoutilizados em funções hash seguras/criptográficas como SHA-1 (Algoritmo Hash seguro), SHA-2 (que inclui SHA-224, SHA-256, SHA-384 e SHA-512), MD-4 (Compilação de mensagens),MD-5, ou outros algoritmos hash seguros conhecidos natécnica. Em um projeto, uma função de transformar única éutilizada e conhecida a priori tanto pela UTRAN como pelosUEs. Em outro projeto, um conjunto de funções detransformar é suportado, e uma função de transformar podeser selecionada a partir do conjunto, por exemplo, noinício de uma chamada, e transferido para um UE.
O comprimento do valor salt σ pode serselecionado com base em um equilíbrio entre overhead esegurança. Um valor salt mais longo pode resultar em maisRNTIs transformados para um dado X-RNTI, que pode melhorara segurança às custas de overhead maior e possivelmentemaior probabilidade de colisão. O inverso pode serverdadeiro para um valor salt mais curto.
Em um projeto, um RNTI transformado tem ocomprimento igual ou aproximadamente igual ao do X-RNTIoriginal. Para esse projeto, o valor salt σ pode serenviado utilizando bits adicionais. Em outro projeto, oRNTI transformado e o valor salt σ têm comprimento igual ouaproximadamente igual ao do X-RNTI original para manteroverhead igual ou aproximadamente igual. Para esse projeto,alguns bits podem ser "recuperados" fazendo o RNTItransformado mais curto do que o X-RNTI original. Porexemplo, o X-RNTI pode ser 16 bits, o RNTI transformadopode ser 10 bits, e o valor salt pode ser 6 bits. O X-RNTI,RNTI transformado, e valor salt podem ter também outroscomprimentos. A função de transformar pode ser projetadapara obter as propriedades criptográficas desejadas com oRNTI transformado mais curto.
Uma colisão ocorre quando dois X-RNTIs para doisUEs são transformados no mesmo RNTI transformado, porexemplo, Ησ(χ) = Ησ(γ), onde χ e y são as dois X-RNTIs. Osdois UEs podem não ter modo para resolver a colisão entreseus RNTIs transformados. O RNTI transformado pode serutilizado para enviar informações de programação para umdos dois UEs, por exemplo, como mostrado na figura 2. 0 UEreceptor pode detectar adequadamente as informações deprogramação como sendo para aquele UE e pode decodificar osdados enviados para o UE. 0 UE não-receptor pode detectarfalsamente as informações de programação, decodificar ósdados destinados para o UE receptor, e obter resultado semsentido após decriptografia (considerando que os dadosenviados no HS-DSCH foram criptografados). Nesse caso,colisões podem ou não causar impacto adverso sobre odesempenho, dependendo do comportamento da aplicação.
Em geral, o impacto devido a colisões de X-RNTIspode ser dependente do tipo de sinalização sendo enviadacom esses X-RNTIs. O UTRAN pode tentar evitar colisões paraevitar possíveis efeitos adversos.
Em um projeto para evitar colisões, o UTRANseleciona X-RNTIs e valores salt conhecidos como não tendocolisões. A UTRAN pode manter um conjunto de todos os X-RNTIs atribuídos ou atribuíveis aos UEs. Para cada valorsalt possível σ, o UTRAN pode gerar um conjunto de RNTIstransformados com base no conjunto de X-RNTIs e aquelevalor salt. O UTRAN pode varrer o conjunto transformadopara duplicatas e pode rejeitar esse valor salt casoduplicatas sejam detectadas. Em geral, um valor salt quecausa uma colisão para certos X-RNTIs pode ser aindautilizado para outros X-RNTIs. Entretanto, para simplificarimplementação, a UTRAN pode manter uma lista de valoressalt que resultam em nenhuma duplicata sobre todo oconjunto de X-RNTIs. Os valores salt nessa lista podem serselecionados para uso. Colisões também podem ser evitadasde outras maneiras.
A figura 5 mostra um processo 500 realizado poruma entidade de rede em uma rede de comunicação sem fiopara enviar mensagens de sinalização para os UEs. Aentidade de rede pode ser um Nó B, um RNC, etc., dependendodas mensagens de sinalização sendo enviadas.
Um primeiro ID atribuído a um UE pode sertransformado para obter um segundo ID para o UE (bloco512) . 0 primeiro ID pode ser um RNTI atribuído ao UE emUMTS ou algum outro tipo de ID em algum outro sistema decomunicação. O primeiro ID pode ser transformado com baseem uma função irreversível, uma função hash, ou algumaoutra função para obter o segundo ID. Uma mensagem de saídadirigida ao UE pode ser gerada com base em uma mensagem deentrada e o segundo ID (bloco 514). A mensagem de entradapode ser uma mensagem de paging, uma mensagem deprogramação carregando informações de programação, umamensagem de atribuição de recursos, etc. A mensagem desaída pode ser enviada através de um canal comumcompartilhado pelo UE e outros UEs (bloco 516).
Em upi projeto, o primeiro ID e um valor saltsofreram hash para obter o segundo ID. 0 valor salt podeser enviado livre na mensagem de saída. 0 valor salt podeser alterado cada vez que o primeiro ID é transformado epode ser selecionado para evitar colisões entre todos osprimeiros IDs atribuídos aos UEs. O primeiro ID pode ter umcomprimento que pode ser igual ao comprimento combinado dosegundo ID e o valor salt.
Em um projeto, a mensagem de saida pode incluir amensagem de entrada e o segundo ID livre, por exemplo, comomostrado na figura 4A. Em outro projeto, o segundo ID podeser incorporado na mensagem de saida, por exemplo, comomostrado na figura 4B. Por exemplo, toda ou uma porção damensagem de entrada pode ser mascarada com o segundo IDpara gerar a mensagem de saida. Alternativamente, um CRCespecifico de UE pode ser gerado com base na mensagem deentrada e o segundo ID, e a mensagem de saida pode sergerada com base na mensagem de entrada e o CRC especificode UE.
A figura 6 mostra um aparelho 600 para enviarmensagens de sinalização para os UEs. Aparelho 600 incluielemento para transformar um primeiro ID atribuído a um UEpara obter um segundo ID para o UE (módulo 612), elementopara gerar uma mensagem de saída dirigida ao UE com base emuma mensagem , de entrada e o segundo ID (módulo 614), eelemento para enviar a mensagem de saída via um canal comumcompartilhado pelo UE e outros UEs (módulo 616). Os módulos612 a 616 podem compreender processadores, dispositivoseletrônicos, dispositivos de hardware, componenteseletrônicos, circuitos lógicos, memórias, etc., ou qualquercombinação dos mesmos.
A figura 7 mostra um processo 700 realizado porum UE para receber mensagens de sinalização a partir de umarede de comunicação sem fio. Uma mensagem pode ser recebidavia um canal comum compartilhado por uma pluralidade de UEs(bloco 712) . Um primeiro ID atribuído ao UE pode sertransformado para obter um segundo ID para o UE (bloco714). A transformação pode ser alcançada com uma tabela deconsulta, hardware, software, firmware, etc. Em um projeto,um valor salt pode ser obtido a partir da mensagemrecebida, e o primeiro ID e o valor salt podem sofrer hashpara obter o segundo ID. 0 fato de se a mensagem recebida édestinada para o UE pode ser determinado com base nosegundo ID (bloco 716). Em um projeto de bloco 716, umterceiro ID pode ser obtido a partir da mensagem recebida ecomparado com o segundo ID para determinar se a mensagemrecebida é destinada ao UE. Em outro projeto de bloco 716,um CRC pode ser gerado com base na mensagem recebida e osegundo ID, um CRC especifico de UE pode ser obtido apartir da mensagem recebida, e o CRC gerado pode sercomparado com o CRC especifico de UE para determinar se amensagem recebida é destinada ao UE. A mensagem recebidapode ser uma mensagem de paging, uma mensagem deprogramação, uma mensagem de atribuição de recursos, etc.
Caso a mensagem recebida seja uma mensagem de programação,então informações de programação podem ser obtidas a partirda mensagem recebida e utilizadas para processar umatransmissão de dados enviada para o UE.
A figura 8 mostra um aparelho 800 para recebermensagens de sinalização. Aparelho 800 inclui elemento parareceber uma mensagem via um canal comum compartilhado poruma pluralidade de UEs (módulo 812), elemento paratransformar um primeiro ID atribuído a um UE para obter umsegundo ID para o UE (módulo 814), e elemento paradeterminar se a mensagem recebida é destinada para o UE combase no segundo ID (módulo 816) . Módulos 812 a 816 podemcompreender processadores, dispositivos eletrônicos,dispositivos de hardware, componentes eletrônicos,circuitos lógicos, memórias, etc., ou qualquer combinaçãodos mesmos.
A figura 9 mostra um diagrama de blocos de umprojeto de UE 120, Nó B 110, e RNC 130 na figura 1. Nouplink, dados e sinalização a serem enviados por UE 120 sãoprocessados (por exemplo, formatados, encodifiçados eintercalados) por um encodificador 922 e adicionalmenteprocessados (por exemplo, modulados, canalizados eembaralhados) por um modulador (MOD) 924 para gerar chipsde saida. Um transmissor (TMTR) 932 então condiciona (porexemplo, converte em analógico, filtra, amplifica, econverte ascendentemente em freqüência) os chips de saida egera um sinal uplink, que é transmitido via uma antena 934.No downlink, a antena 934 recebe um sinal downlinktransmitido por Nó B 110. Um receptor (RCVR) 936 condiciona(Por exemplo, filtra, amplifica, converte descendentementeem freqüência e digitaliza) o sinal recebido a partir daantena 934 e provê amostras. Um demodulador (DEMOD) 926processa (por exemplo, desembaralha, canaliza e demodula)as amostras é provê estimativas de símbolos. Umdecodificador 928 processa adicionalmente (por exemplo,deintercala e decodifica) as estimativas de símbolos eprovê dados decodificados. Encodificador 922, modulador924, demodulador 926, e decodificador 928 podem serimplementados por um processador de modem 920. Essasunidades podem realizar processamento de acordo com atecnologia de rádio (por exemplo, UMTS) implementada pelarede de comunicação sem fio.
Um controlador/processador 94 0 orienta a operaçãono UE 120. Controlador/processador 940 pode realizar oprocesso 700 na figura 7 e/ou outros processos para astécnicas descritas aqui. Uma memória 942 armazena códigosde programa e dados para UE 120 e também pode armazenar IDstemporários atribuídos ao UE 120, ou IDs de UE.
A figura 9 também mostra um projeto de Nó B 110 eRNC 130. Nó B 110 inclui um controlador/processador 950 querealiza várias funções para comunicação com os UEs, umamemória 952 que armazena códigos de programa e dados paraNó B 110, e um transceptor 954 que suporta comunicação derádio com os UEs. Controlador/processador 950 pode realizaro processo 500 na figura 5 e/ou outros processos para astécnicas descritas aqui. Memória 952 pode armazenar IDstemporários atribuídos aos UEs por Nó B 110, ou NB UE IDs.RNC 130 inclui um controlador/processador 960 que realizavárias funções para suportar comunicação para os UEs e umamemória 962 que armazena códigos de programa e dados paraRNC 130. Controlador/processador 960 pode realizar processo500 na figura 5 e/ou outros processos para as técnicasdescritas aqui. Memória 962 pode armazenar IDs temporáriosatribuídos aos UEs servidos pelo RNC 130, ou RNC UE IDs.
As técnicas descritas aqui podem ser utilizadaspara mensagens de sinalização enviadas no downlink bem comono uplink. As técnicas também podem ser utilizadas paramensagens enviadas via um plano de controle bem como umplano de usuário. Um plano de controle é um mecanismo paraportar sinalização para aplicativos de camada mais alta e étipicamente implementado com protocolos específicos derede, interfaces e mensagens de sinalização. Um plano deusuário é um mecanismo que porta sinalização paraaplicativos de camada mais alta e é tipicamenteimplementado com protocolos abertos como Protocolo deDatagrama de Usuário (UDP), Protocolo de Controle deTransmissão (TCP), e Protocolo de Internet (IP). Mensagenspodem ser portadas como parte de sinalização em um plano decontrole como parte de dados (a partir de uma perspectivade rede) em um plano de usuário.
As técnicas descritas aqui podem serimplementadas por vários elementos. Por exemplo, essastécnicas podem ser implementadas em hardware, firmware,software ou uma combinação dos mesmos. Para umaimplementação de hardware, as unidades de processamentoutilizadas para realizar as técnicas em uma dada entidade(por exemplo, um UE, um Nó B, um RNC, etc.) podem serimplementadas dentro de um ou mais circuitos integradosespecíficos de aplicação (ASICs) , processadores de sinaldigital (DSPs), dispositivos de processamento de sinaldigital (DSPDs), dispositivos de lógica programável (PLDs) ,arranjos de porta programável em campo (FPGAs),processadores, controladores, microcontroladores,microprocessadores, dispositivos eletrônicos, outrasunidades eletrônicas projetadas para realizar as funçõesdescritas aqui, um computador, ou uma combinação dosmesmos.
Para uma implementação de firmware e/ou software,as técnicas podem ser implementadas com módulos (porexemplo, procedimentos, funções, etc.) que realizam asfunções descritas aqui. Os códigos de firmware e/ousoftware podem ser armazenados em uma memória (por exemplo,memória 942, 952 ou 962 na figura 9) e executados por umprocessador (por exemplo, processador 940, 950 ou 960). Amemória pode ser implementada dentro do processador ouexternamente ao processador.
A descrição anterior da revelação é provida parapermitir que qualquer pessoa versada na técnica faça ouutilize a descrição. Várias modificações na descrição serãoprontamente evidentes para aqueles versados na técnica, eos princípios gerais definidos acima podem ser aplicados aoutras variações sem se afastar do espírito ou escopo dadescrição. Desse modo, a descrição não pretende serlimitada aos exemplos descritos aqui, porém deve estar deacordo com o escopo mais amplo compatível com os princípiose características novas aqui revelados.

Claims (37)

1. Um aparelho compreendendo:um processador configurado para transformar umprimeiro identificador (ID) atribuído a um equipamento deusuário (UE) para obter um segundo ID para o UE, gerar umamensagem de saída dirigida ao UE com base em uma mensagemde entrada e o segundo ID, e enviar a mensagem de saída viaum canal comum compartilhado pelo UE e outros UEs; euma memória acoplada ao processador.
2. O aparelho, de acordo com a reivindicação 1,em que o processador é configurado para transformar oprimeiro ID com base em uma função irreversível para obtero segundo ID.
3. O aparelho, de acordo com a reivindicação 1,em que o processador é configurado para hash o primeiro IDpara obter o segundo ID.
4. 0 aparelho, de acordo com a reivindicação 1,em que o processador é configurado para hash o primeiro IDe um valor salt para obter o segundo ID.
5. O aparelho, de acordo com a reivindicação 4,em que o processador é configurado para enviar o valor saltna mensagem de saída.
6. 0 aparelho, de acordo com a reivindicação 4,em que o processador é configurado para alterar o valorsalt cada vez que o primeiro ID é transformado.
7. O aparelho, de acordo com a reivindicação 4,em que o primeiro ID tem um comprimento igual a umcomprimento combinado do segundo ID e o valor salt.
8. 0 aparelho, de acordo com a reivindicação 4,em que o processador é configurado para selecionar o valorsalt para evitar colisões entre uma pluralidade deprimeiros IDs atribuídos a UEs ativos.
9. O aparelho, de acordo com a reivindicação 1,em que o processador é configurado para gerar a mensagem desaída para incluir a mensagem de entrada e o segundo IDlivre.
10. 0 aparelho, de acordo com a reivindicação 1,em que o processador é configurado para mascarar pelo menosuma porção da mensagem de entrada com o segundo ID paragerar a mensagem de saída.
11. O aparelho, de acordo com a reivindicação 1,em que o processador é configurado para gerar um teste deredundância cíclica (CRC) específico de UE com base namensagem de entrada e o segundo ID, e gerar a mensagem desaída com base na mensagem de entrada e o CRC específico deUE.
12. 0 aparelho, de acordo com a reivindicação 1,em que a mensagem de entrada é uma mensagem de paging, umamensagem de programação ou uma mensagem de atribuição derecursos.
13. O aparelho, de acordo com a reivindicação 1,em que o primeiro ID é um Identificador Temporário de RedeRádio (RNTI) atribuído ao UE em Sistema de TelecomunicaçãoMóvel universal (UMTS).
14. Um método compreendendo:transformar um primeiro identificador (ID)atribuído a um equipamento de usuário (UE) para obter umsegundo ID para o UE;gerar uma mensagem de saída dirigida para o UEcom base em uma mensagem de entrada e o segundo ID; eenviar a mensagem de saída via um canal comumcompartilhado pelo UE e outros UEs.
15. O método, de acordo com a reivindicação 14,em que a transformação do primeiro ID compreende hashing oprimeiro ID e um valor salt para obter o segundo ID.
16. O método, de acordo com a reivindicação 14,em que a geração da mensagem de saída compreendegerar a mensagem de saída para incluir a mensagemde entrada e o segundo ID livre.
17. 0 método, de acordo com a reivindicação 14,em que a geração de mensagem de saída compreendegerar um teste de redundância cíclica (CRC)específico de UE com base na mensagem de entrada e osegundo ID, egerar a mensagem de saída com base na mensagem deentrada e o CRC específico de UE.
18. Um aparelho compreendendo:elemento para transformar um primeiroidentificador (ID) atribuído a um equipamento de usuário(UE) para obter iam segundo ID para o UE;elemento para gerar uma mensagem de saídadirigida ao UE com base em uma mensagem de entrada e osegundo ID; eelemento para enviar a mensagem de saída via umcanal comum compartilhado pelo UE e outros UEs.
19. 0 aparelho, de acordo com a reivindicação 18,em que o elemento para transformar o primeiro ID compreendeelemento para efetuar hash o primeiro ID e umvalor salt para obter o segundo ID.
20. O aparelho, de acordo com a reivindicação 18,em que o elemento para gerar a mensagem de saída compreendeelemento para gerar a mensagem de saída paraincluir a mensagem de entrada e o segundo ID livre.
21. O aparelho, de acordo com a reivindicação 18,em que o elemento para gerar a mensagem de saída compreendeelemento para gerar um teste de redundânciacíclica (CRC) específico de UE com base na mensagem deentrada e o segundo ID, eelemento para gerar a mensagem de saída com basena mensagem de entrada e o CRC específico de UE.
22. Meio legível por computador incluindoinstruções armazenadas no mesmo, compreendendo:um primeiro conjunto de instruções paratransformar um primeiro identificador (ID) atribuído a umequipamento de usuário (UE) para obter um segundo ID para oUE.um segundo conjunto de instruções para gerar umamensagem de saída dirigida ao UE com base em uma mensagemde entrada e o segundo ID; eum terceiro conjunto de instruções para enviar amensagem de saida via um canal comum compartilhado pelo UEe outros UEs.
23. Um aparelho, compreendendo:um processador configurado para receber umamensagem via um canal comum compartilhado por umapluralidade de equipamentos de usuário (UEs), transformarum primeiro identificador (ID) atribuído a um UE para obterum segundo ID para o UE, e determinar se a mensagemrecebida é destinada ao UE com base no segundo ID; euma memória acoplada ao processador.
24. 0 aparelho, de acordo com a reivindicação 23,em que o processador é configurado para obter um valor salta partir da mensagem recebida e efetuar hash do primeiro IDe o valor salt para obter o segundo ID.
25. 0 aparelho, de acordo com a reivindicação 23,em que o processador é configurado para obter um terceiroID a partir da mensagem recebida e comparar o segundo IDcom o terceiro ID para determinar se a mensagem recebida édestinada ao UE.
26. Aparelho, de acordo com a reivindicação 23,em que o processador é configurado para gerar um teste deredundância cíclica (CRC) com base na mensagem recebida e osegundo ID, obter um CRC específico de UE a partir damensagem recebida, e comparar o CRC gerado com o CRCespecífico de UE para determinar se a mensagem recebida édestinada ao UE.
27. Aparelho, de acordo com a reivindicação 23,em que o processador é configurado para determinar que amensagem recebida é destinada ao UE, obter informações deprogramação a partir da mensagem recebida, e processar umatransmissão de dados com base nas informações deprogramação.
28. 0 aparelho, de acordo com a reivindicação 23,em que a mensagem recebida é uma mensagem de paging, umamensagem de programação, ou uma mensagem de atribuição derecursos destinada ao UE.
29. Um método compreendendo:receber uma mensagem via um canal comumcompartilhado por uma pluralidade de equipamentos deusuário (UEs);transformar um primeiro identificador (ID)atribuído a um UE para obter um segundo ID para o UE; edeterminar se a mensagem recebida é destinada aoUE com base no segundo ID.
30. O método, de acordo com a reivindicação 29,em que a transformação do primeiro ID compreendeobter um valor salt a partir da mensagemrecebida, eefetuar hash do primeiro ID e o valor salt paraobter o segundo ID.
31. O método, de acordo com a reivindicação 29,em que a determinação de se a mensagem recebida é destinadaao UE compreendeobter um terceiro ID a partir da mensagemrecebida, ecomparar o segundo ID com o terceiro ID paradeterminar se a mensagem recebida é destinada ao UE.
32. 0 método, de acordo com a reivindicação 29,em que a determinação de se a mensagem recebida é destinadaao UE compreendegerar um teste de redundância cíclica (CRC) combase na mensagem recebida e o segundo ID,obter um CRC específico de UE a partir damensagem recebida, ecomparar o CRC gerado com o CRC específico de UEpara determinar se a mensagem recebida é destinada ao UE.
33. Um aparelho compreendendo:elemento para receber uma mensagem via um canalcomum compartilhado por uma pluralidade de equipamentos deusuário (UEs);elemento para transformar um primeiroidentificador (ID) atribuído a um UE para obter um segundoID para o UE; eelemento para determinar se a mensagem recebida édestinada ao UE com base no segundo ID.
34. Ó aparelho, de acordo com a reivindicação 33,em que o elemento para transformação do primeiro IDcompreendeelemento para obter um valor salt a partir damensagem recebida, eelemento para efetuar hash o primeiro ID e ovalor salt para obter o segundo ID.
35. O aparelho, de acordo com a reivindicação 33,em que o elemento para determinação de se a mensagemrecebida é destinada ao UE compreendeelemento para obter um terceiro ID a partir damensagem recebida, eelemento para comparar o segundo ID com oterceiro ID para determinar se a mensagem recebida édestinada ao UE.
36. 0 aparelho, de acordo com a reivindicação 33,em que o elemento para determinação de se a mensagemrecebida é destinada ao UE compreendeelemento para gerar um teste de redundânciacíclica (CRC) com base na mensagem recebida e o segundo ID,elemento para obter um CRC específico de UE apartir da mensagem recebida, eelemento para comparar o CRC gerado com o CRCespecífico de UE para determinar se a mensagem recebida édestinada ao UE.
37. - Meio legível por computador incluindoinstruções armazenadas no mesmo, compreendendo:um primeiro conjunto de instruções para receberuma mensagem através de um canal comum compartilhado poruma pluralidade de equipamentos de usuário (UEs);.um segundo conjunto de instruções paratransformar um primeiro identificador (ID) atribuído a umUE para obter um segundo ID para o UE; eum terceiro conjunto de instruções paradeterminar se a mensagem recebida é destinada ao UE combase no segundo ID.
BRPI0707583A 2006-02-10 2007-02-09 obscurecimento de identidades temporárias de equipamento de usuário BRPI0707583B1 (pt)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US77197406P 2006-02-10 2006-02-10
US60/771,974 2006-02-10
US78646306P 2006-03-27 2006-03-27
US60/786,463 2006-03-27
PCT/US2007/061939 WO2007095471A2 (en) 2006-02-10 2007-02-09 Obscuring temporary user equipment identities

Publications (3)

Publication Number Publication Date
BRPI0707583A2 true BRPI0707583A2 (pt) 2011-05-10
BRPI0707583A8 BRPI0707583A8 (pt) 2019-01-08
BRPI0707583B1 BRPI0707583B1 (pt) 2019-08-13

Family

ID=38197847

Family Applications (2)

Application Number Title Priority Date Filing Date
BRPI0707581-2A BRPI0707581A2 (pt) 2006-02-10 2007-02-09 sinalizaÇço com identidades de equipamento de usuÁrio opacas
BRPI0707583A BRPI0707583B1 (pt) 2006-02-10 2007-02-09 obscurecimento de identidades temporárias de equipamento de usuário

Family Applications Before (1)

Application Number Title Priority Date Filing Date
BRPI0707581-2A BRPI0707581A2 (pt) 2006-02-10 2007-02-09 sinalizaÇço com identidades de equipamento de usuÁrio opacas

Country Status (13)

Country Link
US (2) US8195943B2 (pt)
EP (3) EP1992189B1 (pt)
JP (2) JP4960389B2 (pt)
KR (2) KR101038158B1 (pt)
CN (1) CN104768145A (pt)
AR (1) AR059568A1 (pt)
AT (1) ATE543318T1 (pt)
BR (2) BRPI0707581A2 (pt)
CA (2) CA2636309C (pt)
ES (1) ES2392854T3 (pt)
RU (2) RU2427103C2 (pt)
TW (2) TWI357270B (pt)
WO (2) WO2007095471A2 (pt)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4892884B2 (ja) * 2005-08-01 2012-03-07 日本電気株式会社 無線ｌａｎ内蔵型携帯電話端末、携帯電話システムおよびその個人情報保護方法
RU2427103C2 (ru) * 2006-02-10 2011-08-20 Квэлкомм Инкорпорейтед Скрытие временных опознавателей пользовательской аппаратуры
MY187397A (en) 2006-04-28 2021-09-22 Qualcomm Inc Method and apparatus for enhanced paging
US8682357B2 (en) 2006-05-02 2014-03-25 Intellectual Ventures Holding 81 Llc Paging in a wireless network
US8156332B2 (en) * 2007-05-29 2012-04-10 Apple Inc. Peer-to-peer security authentication protocol
JP4787792B2 (ja) * 2007-06-18 2011-10-05 株式会社エヌ・ティ・ティ・ドコモ 無線制御装置、無線通信システム、通信路設定方法
RU2471291C2 (ru) 2007-09-11 2012-12-27 Вай-Лэн, Инк. Распределение постоянных ресурсов
CN101426254B (zh) 2007-10-31 2010-12-08 华为技术有限公司 一种实现信息传输的方法、装置及系统
CN101426253B (zh) 2007-10-31 2013-08-07 华为技术有限公司 一种实现信息传输的方法、装置及系统
AU2008341208B2 (en) 2007-12-21 2013-07-18 Telefonaktiebolaget L M Ericsson (Publ) Methods and arrangements in a mobile telecommunications network
EP2280567B1 (en) * 2008-04-24 2014-06-11 Huawei Technologies Co., Ltd. Mobile station device, mobile communication system, and communication method
US8514818B2 (en) * 2008-04-25 2013-08-20 Nokia Corporation System and methods for generating masking sequences
EP2345263A4 (en) * 2008-11-07 2014-08-20 Ericsson Telefon Ab L M METHOD OF TRIGGERING EVENTS BASED ON LOCATION IN USER EQUIPMENT
US20100235689A1 (en) * 2009-03-16 2010-09-16 Qualcomm Incorporated Apparatus and method for employing codes for telecommunications
US8711751B2 (en) * 2009-09-25 2014-04-29 Apple Inc. Methods and apparatus for dynamic identification (ID) assignment in wireless networks
DE102009058446B4 (de) * 2009-12-16 2011-11-10 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Verfahren zur Anonymisierung von Verbindungsdaten in IP Paketen und Vorrichtung zur Durchführung des Verfahrens
WO2011134529A1 (en) * 2010-04-30 2011-11-03 Nokia Siemens Networks Oy Method of assigning a unique identifier to a mobile station in a communications network
US20120011229A1 (en) * 2010-06-04 2012-01-12 Peter Heller Enhanced network/domain name hashing techniques
US20120039185A1 (en) * 2010-08-12 2012-02-16 Futurewei Technologies, Inc. System and Method for Providing Security in a Wireless Communications System
WO2013102489A1 (en) * 2012-01-03 2013-07-11 Telefonaktiebolaget L M Ericsson (Publ) A radio communication system for assigning a short-lived c-rnti
US8885517B2 (en) * 2012-02-16 2014-11-11 Giri Prassad Deivasigamani Operational state mismatch identification for a mobile device
US20140036861A1 (en) * 2012-08-03 2014-02-06 Institute For Information Industry High-power base station and low-power base station for use in hererogeneous network and transmission methods thereof
US9386619B2 (en) 2013-02-22 2016-07-05 Htc Corporation Method of handling a cell addition for dual connectivity and related communication device
EP3512298B1 (en) 2013-02-22 2021-03-24 HTC Corporation Method and apparatus for the release of a cell
US10390333B2 (en) * 2013-05-02 2019-08-20 Huawei Technologies Co., Ltd. System and method for transmission source identification
CN104349308B (zh) * 2013-08-09 2018-06-05 宏达国际电子股份有限公司 双连结中分配无线网络暂时识别的方法、通信装置以及网络端
EP3066838B1 (en) * 2013-11-04 2018-06-13 Nagravision S.A. Device and method to mark digital audio or audio and/or video content
JP6844913B2 (ja) * 2015-12-31 2021-03-17 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 移動性管理の方法、端末および基地局
US11659563B2 (en) * 2017-01-04 2023-05-23 Huawei Technologies Co., Ltd. System and method for user equipment identifier configuration
US10361839B2 (en) 2017-01-06 2019-07-23 Blackberry Limited Encryption in wireless communication systems
US10277252B2 (en) 2017-01-09 2019-04-30 At&T Intellectual Property I, L.P. Encoding data with polar codes for control channels
JP7124679B2 (ja) * 2018-12-07 2022-08-24 トヨタ自動車株式会社 監視装置
FI129763B (en) * 2020-03-04 2022-08-15 Wirepas Oy Addressing system for a wireless data communications network
US11381391B2 (en) * 2020-06-15 2022-07-05 Cisco Technology, Inc. Pre-shared secret key capabilities in secure MAC layer communication protocols

Family Cites Families (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06337153A (ja) 1993-05-28 1994-12-06 Toshiba Corp 空気調和機
TW243553B (en) 1994-03-21 1995-03-21 United Microelectronics Corp Coding method for mask read only memory
JP3271460B2 (ja) * 1995-01-12 2002-04-02 ケイディーディーアイ株式会社 無線通信における識別子秘匿方法
AU1732597A (en) * 1996-02-21 1997-09-10 Card Call Service Co., Ltd. Communication method using common cryptographic key
US6510461B1 (en) * 1997-06-30 2003-01-21 Sun Microsystems, Inc. System for managing and automatically deleting network address identified and stored during a network communication session when the network address is visited
CA2276872A1 (en) * 1998-08-28 2000-02-28 Lucent Technologies Inc. Method for protecting mobile anonymity
US6463154B1 (en) 1998-08-28 2002-10-08 Lucent Technologies Inc. Method for determining temporary mobile identifiers and managing use thereof
US6256301B1 (en) 1998-10-15 2001-07-03 Qualcomm Incorporated Reservation multiple access
AU1590700A (en) 1998-11-12 2000-06-05 Telefonaktiebolaget Lm Ericsson (Publ) System and method for secured transference of temporary mobile subscriber information
FI114077B (fi) 1999-03-10 2004-07-30 Nokia Corp Tunnuksen varausmenetelmä
US6763112B1 (en) * 1999-09-28 2004-07-13 Nokia Networks Oy Security procedure in universal mobile telephone service
US7240202B1 (en) * 2000-03-16 2007-07-03 Novell, Inc. Security context sharing
JP2004509414A (ja) * 2000-09-14 2004-03-25 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ データ項目を記憶する方法及びシステム
US7065341B2 (en) 2000-11-16 2006-06-20 Telefonaktiebolaget Lm Ericsson (Publ) User authentication apparatus, controlling method thereof, and network system
US7046992B2 (en) * 2001-05-11 2006-05-16 Telefonaktiebolaget Lm Ericsson (Publ) Authentication of termination messages in telecommunications system
US20030172114A1 (en) 2001-10-24 2003-09-11 Leung Nikolai K. N. Method and apparatus for data packet transport in a wireless communication system using an internet protocol
US7363494B2 (en) 2001-12-04 2008-04-22 Rsa Security Inc. Method and apparatus for performing enhanced time-based authentication
US7515713B2 (en) * 2001-12-17 2009-04-07 Qualcomm Incorporated Secure generation of temporary mobile station identifiers
US6856604B2 (en) 2001-12-19 2005-02-15 Qualcomm Incorporated Efficient multi-cast broadcasting for packet data systems
US20060034456A1 (en) * 2002-02-01 2006-02-16 Secure Choice Llc Method and system for performing perfectly secure key exchange and authenticated messaging
KR100765123B1 (ko) * 2002-02-16 2007-10-11 엘지전자 주식회사 Ｓｒｎｓ 재할당 방법
US7508804B2 (en) 2002-04-05 2009-03-24 Alcatel-Lucent Usa Inc. Shared signaling for multiple user equipment
RU2292648C2 (ru) 2002-05-01 2007-01-27 Телефонактиеболагет Лм Эрикссон (Пабл) Система, устройство и способ, предназначенные для аутентификации на основе sim и для шифрования при доступе к беспроводной локальной сети
WO2003101000A1 (en) 2002-05-22 2003-12-04 Interdigital Technology Corporation Mobile unit having internet protocol functionality
KR100878764B1 (ko) 2002-07-06 2009-01-14 삼성전자주식회사 사용자의 익명성보장을 위한 무선 랜 시스템 및 사용자의익명성 보장방법
US6757722B2 (en) 2002-07-16 2004-06-29 Nokia Corporation System and method for providing partial presence notifications
KR100893070B1 (ko) 2002-09-19 2009-04-17 엘지전자 주식회사 무선통신 시스템의 멀티캐스트 서비스 제공 및 수신 방법, 그리고 그 장치
EP1401226A1 (en) * 2002-09-20 2004-03-24 Lucent Technologies Inc. A method, and apparatus, for addressing a message to mobile user terminals
RU2253948C1 (ru) 2003-09-02 2005-06-10 Войсковая часть 45807 Способ передачи сообщений с обеспечением конфиденциальности идентификационных признаков взаимодействующих объектов в сети связи
US7424467B2 (en) * 2004-01-26 2008-09-09 International Business Machines Corporation Architecture for an indexer with fixed width sort and variable width sort
JP3890398B2 (ja) 2004-02-19 2007-03-07 海 西田 ピアツーピア型匿名プロキシにおける安全性の高い匿名通信路の検証及び構築する方法
US20050243769A1 (en) 2004-04-28 2005-11-03 Walker Jesse R Apparatus and method capable of pre-keying associations in a wireless local area network
FI20040841A0 (fi) * 2004-06-17 2004-06-17 Nokia Corp Menetelmä tietoliikenteen valvomiseksi käyttäen verkkonoodiryhmää kommunikaatiojärjestelmässä
JP2006011989A (ja) 2004-06-28 2006-01-12 Ntt Docomo Inc 認証方法、端末装置、中継装置及び認証サーバ
KR20070074562A (ko) * 2004-09-10 2007-07-12 코닌클리케 필립스 일렉트로닉스 엔.브이. 조건적 액세스를 제공하는 방법
JP4598494B2 (ja) * 2004-11-26 2010-12-15 富士通株式会社 利用者仮識別子を用いるネットワークサービスシステム
GB2423220B (en) * 2005-02-11 2009-10-07 Ericsson Telefon Ab L M Method and apparatus for ensuring privacy in communications between parties
US20060248079A1 (en) * 2005-04-28 2006-11-02 Freescale Semiconductor Incorporated Method and apparatus for finding a perfect hash function and making minimal hash table for a given set of keys
US20070047478A1 (en) 2005-08-30 2007-03-01 Lucent Technologies Inc. Method for access assurance in a wireless communication system
US7827398B2 (en) * 2005-10-27 2010-11-02 Hewlett-Packard Company Method for offloading encryption and decryption of a message received at a message server to remote end devices
US8848912B2 (en) 2005-12-19 2014-09-30 Nippon Telegraph And Telephone Corporation Terminal identification method, authentication method, authentication system, server, terminal, wireless base station, program, and recording medium
US8788807B2 (en) * 2006-01-13 2014-07-22 Qualcomm Incorporated Privacy protection in communication systems
RU2427103C2 (ru) * 2006-02-10 2011-08-20 Квэлкомм Инкорпорейтед Скрытие временных опознавателей пользовательской аппаратуры
US8295243B2 (en) * 2006-08-21 2012-10-23 Qualcomm Incorporated Method and apparatus for random access in an orthogonal multiple-access communication system

Also Published As

Publication number Publication date
CA2636309A1 (en) 2007-08-23
JP4960389B2 (ja) 2012-06-27
KR20080092469A (ko) 2008-10-15
KR101038158B1 (ko) 2011-05-31
US20070218901A1 (en) 2007-09-20
US9154464B2 (en) 2015-10-06
RU2008136412A (ru) 2010-03-20
BRPI0707583A8 (pt) 2019-01-08
JP4927877B2 (ja) 2012-05-09
WO2007095473A1 (en) 2007-08-23
CN104768145A (zh) 2015-07-08
WO2007095471A3 (en) 2008-01-17
US8195943B2 (en) 2012-06-05
KR20080102177A (ko) 2008-11-24
RU2008136410A (ru) 2010-03-20
ATE543318T1 (de) 2012-02-15
ES2392854T3 (es) 2012-12-14
RU2427103C2 (ru) 2011-08-20
AR059568A1 (es) 2008-04-16
WO2007095471A2 (en) 2007-08-23
TWI340582B (en) 2011-04-11
CA2636270A1 (en) 2007-08-23
EP2437460B1 (en) 2013-10-23
JP2009526334A (ja) 2009-07-16
JP2009526449A (ja) 2009-07-16
CA2636270C (en) 2013-04-30
US20070226502A1 (en) 2007-09-27
EP1992189A1 (en) 2008-11-19
EP1992188B1 (en) 2012-09-19
EP1992188A2 (en) 2008-11-19
EP1992189B1 (en) 2012-01-25
TW200803394A (en) 2008-01-01
BRPI0707583B1 (pt) 2019-08-13
TWI357270B (en) 2012-01-21
TW200746774A (en) 2007-12-16
EP2437460A1 (en) 2012-04-04
BRPI0707581A2 (pt) 2011-05-10
RU2404540C2 (ru) 2010-11-20
KR101041241B1 (ko) 2011-06-14
CA2636309C (en) 2013-09-17

Similar Documents

Publication Publication Date Title
BRPI0707583A2 (pt) obscurecimento de identidade temporÁrias de equipamento de usuÁrio
ES2897125T3 (es) Cifrado del enlace ascendente durante un acceso aleatorio
CN112154624A (zh) 针对伪基站的用户身份隐私保护
ES2377823T3 (es) Método de acceso aleatorio y terminal para mejorar la eficacia de encriptación
US20120172002A1 (en) Method of supporting location privacy
BRPI0715661A2 (pt) mÉtodo e equipamento para acesso aleatàrio em um sistema de comunicaÇço de acesso méltiplo ortogonal
CN110169029A (zh) 用于在无线通信系统中进行寻呼的方法和网络节点
BRPI0821093B1 (pt) método e equipamento para transferência de uma mensagem em um canal de controle comum para acesso aleatório em uma rede de comunicação sem fio
CN104219650B (zh) 发送用户身份认证信息的方法及用户设备
US10855441B2 (en) Method of generating a pseudonym associated with a communication device, a network node, computer program and computer program product
WO2012031523A1 (en) System and method for providing security in a wireless communications system
Rajavelsamy et al. Privacy protection and mitigation of unauthorized tracking in 3GPP-WiFi interworking networks
Hamandi et al. W-AKA: Privacy-enhanced LTE-AKA using secured channel over Wi-Fi
KR20090024604A (ko) 무선 통신 시스템에서의 데이터 송수신 방법
Schoinas Secure military communications on 3G, 4G and WiMAX
CN115002776A (zh) 用于减轻未授权消息中继攻击的方法、系统和计算机可读介质
Oladayo et al. PA-AKA: Privacy-Aware and Lightweight Authentication Scheme for Long Term Evolution (LTE)

Legal Events

Date Code Title Description
B15K Others concerning applications: alteration of classification

Ipc: H04L 29/06 (2006.01), H04L 9/08 (2006.01), H04L 29

B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06T Formal requirements before examination [chapter 6.20 patent gazette]

Free format text: EXIGENCIA DE PRE-EXAME

B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 13/08/2019, OBSERVADAS AS CONDICOES LEGAIS. (CO) 10 (DEZ) ANOS CONTADOS A PARTIR DE 13/08/2019, OBSERVADAS AS CONDICOES LEGAIS

B21F Lapse acc. art. 78, item iv - on non-payment of the annual fees in time

Free format text: REFERENTE A 15A ANUIDADE.

B24J Lapse because of non-payment of annual fees (definitively: art 78 iv lpi, resolution 113/2013 art. 12)

Free format text: EM VIRTUDE DA EXTINCAO PUBLICADA NA RPI 2656 DE 30-11-2021 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDA A EXTINCAO DA PATENTE E SEUS CERTIFICADOS, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.