BR102012007970A2 - Aparelhos e métodos para armazenamento de clientes de acesso eletrônico - Google Patents

Abstract

APARELHOS E MÉTODOS PARA ARMAZENAMENTO DE CLIENTES DE ACESSO ELETRÔNICO A presente invenção refere-se a aparelhos e métodos para armazenar e controlar clientes com controle de acesso. Em uma modalidade, dispositivos de transmissão e recepção garantem que somente uma cópia de um eSIM fique ativa em qualquer momento. Especificamente, cada eSIM transferido é criptografado para o dispositivo de destino; o eSIM do dispositivo fonte é excluído, desativado ou de outra forma inutilizado. Vários aspectos da infraestrutura de rede são também descritos, incluindo utensílios de Cartão de Circuito Integrado Universal eletrônico (eUICC) e dispositivos móveis. Vários cenários para transferência dos eSIMs são também revelados.

Description

Relatório Descritivo da Patente de Invenção para "APARELHOS E MÉTODOS PARA ARMAZENAMENTO DE CLIENTES DE ACESSO E- LETRÔNICO".

Esse pedido reivindica a prioridade para o Pedido de Patente 5 U.S. No. 13/093.722, depositado em 25 de abril de 2011, intitulado "APPA- RATUS AND METHODS FOR STORING ELECTRONIC ACCESS CLI- ENTS", que reivindica a prioridade para o Pedido de Patente Provisório U.S. No. 61/472.109, depositado em 5 de abril de 2011 e intitulado "APPARATUS AND METHODS FOR STORING ELECTRONIC ACCESS CLIENTS", cada 10 um dos precedentes sendo incorporado aqui por referência na sua íntegra.

Esse pedido é também relacionado com os Pedidos de Patente U.S. Nos. de Série 13/080.558, depositado em 5 de abril de 2011 e intitulado "APPARATUS AND METHODS FOR CONTROLLING DISTRIBUTION OF ELECTRONIC ACCESS CLIENTS"; 12/952.082, depositado em 22 de no- 15 vembro de 2010 e intitulado "WIRELESS NETWORK AUTHENTICATION APPARATUS AND METHODS"; 12/952.089, depositado em 22 de novem- bro de 2010 e intitulado "APPARATUS AND METHODS FOR PROVISIO- NING SUBSCRIBER IDENTITY DATA IN A WIRELESS NETWORK"; 12/980.232, depositado em 28 de dezembro de 2010 e intitulado "VIRTUAL 20 SUBSCRIBER IDENTITY MODULE DISTRIBUTION SYSTEM" e 12/353.227, depositado em 13 de janeiro de 2009 e intitulado "POSTPONED CARRIER CONFIGURATION" e Pedidos de Patente Provisórios U.S. Nos. de Série 61/472.115, depositado em 5 de abril de 2011 e intitulado "APPA- RATUS AND METHODS FOR DISTRIBUTING AND STORING ELECTRO- 25 NIC ACCESS CLIENTS" (agora Pedido de Patente U.S. No. de Série 13/095.716, depositado em 27 de abril de 2011, do mesmo título); 61/407.858, depositado em 28 de outubro de 2010 e intitulado "METHODS AND APPARATUS FOR ACCESS CONTROL CLIENT ASSISTED ROA- MING" (agora Pedido de Patente U.S. No. de Série 13/109.851, depositado 30 em 17 de maio de 2011, do mesmo título); 61/407.861, depositado em 28 de outubro de 2010 e intitulado "MANAGEMENT SYSTEMS FOR MULTIPLE ACCESS CONTROL ENTITIES" (agora Pedido de Patente U.S. No. de Série 13/079.614, depositado em 4 de abril de 2011, do mesmo título"); 61/407.862, depositado em 28 de outubro de 2010 e intitulado "METHODS E APPARATUS FOR DELIVERING ELECTRONIC IDENTIFICATION COM- PONENTS OVER A WIRELESS NETWORK" (agora Pedido de Patente U.S.

5 No. de Série 13/111.801, depositado em 19 de maio de 2011, do mesmo título); 61/407.866, depositado em 28 de outubro de 2010 e intitulado "ME- THODS E APPARATUS FOR STORAGE AND EXECUTION OF ACCESS CONTROL CLIENTS" (agora Pedido de Patente U.S. No. de Série 13/080.521, depositado em 5 de abril de 2011, do mesmo título); 61/408.504, 10 depositado em 29 de outubro de 2010 e intitulado "ACCESS DATA PROVI- SIONING SERVICE" (agora Pedido de Patente U.S. No. de Série 13/078.811, depositado em 1 de abril de 2011 e intitulado "ACCESS DATA PROVISIONING APPARATUS AND METHODS"); 61/409.891, depositado em 3 de novembro de 2010 e intitulado "METHODS AND APPARATUS FOR 15 ACCESS DATA RECOVERY FROM A MALFUNCTIONING DEVICE" (agora Pedido de Patente U.S. No. de Série 13/287.874, depositado em 2 de no- vembro de 2011, do mesmo título); 61/410.298, depositado em 4 de novem- bro de 2010 e intitulado "SIMULACRUM OF PHYSICAL SECURITY DEVICE AND METHODS" (agora Pedido de Patente U.S. No. de Série 13/080.533, 20 depositado em 5 de abril de 2011, do mesmo título) e 61/413.317, deposita- do em 12 de novembro de 2010 e intitulado "APPARATUS AND METHODS FOR RECORDATION OF DEVICE HISTORY ACROSS MULTIPLE SOFT- WARE EMULATION" (agora Pedido de Patente U.S. No. de Série 13/294.631, depositado em 11 de novembro de 2011, do mesmo título), cada 25 um dos precedentes sendo incorporado aqui por referência na sua íntegra. Antecedentes da Invenção

1. Campo da Invenção

A presente invenção refere-se, de forma geral, ao campo dos sistemas de comunicações e mais particularmente em um aspecto exemplar ao armazenamento e distribuição de clientes de controle de acesso aos dis- positivos.

2. Descrição da Tecnologia Relacionada O controle do acesso é requerido para comunicação segura na maior parte dos sistemas de comunicação por rádio sem fio da técnica ante- rior. Como um exemplo, um esquema de controle de acesso simples com- preenderia: (i) verificar a identidade de uma parte da comunicação e (ii) con- 5 ceder um nível de acesso proporcional à identidade verificada. Dentro do contexto de um sistema celular exemplar (por exemplo, Sistema de Teleco- municações Móvel Universal (UMTS)), o controle do acesso é governado por um cliente de controle de acesso, citado como um Módulo de Identidade do Assinante Universal (USIM) executando em um Cartão de Circuito Integrado 10 Universal (UICC) físico. O cliente do controle de acesso do USIM autentica o assinante para a rede celular do UMTS. Depois da autenticação bem- sucedida, o assinante obtém o acesso à rede celular. Como usado antes, o termo "cliente de controle de acesso" se refere, de forma geral, a uma enti- dade lógica, incorporada dentro de hardware ou software, adequada para 15 controlar o acesso de um primeiro dispositivo a uma rede. Exemplos comuns de clientes de controle de acesso incluem USIM, Módulos de Identificação do Assinante do CDMA (CSIM), Módulo de Identidade dos Serviços de Mul- timídia IP (ISIM), Módulos de Identidade do Assinante (SIM), Módulos de Identidade do Usuário Removíveis (RUIM), etc.

Tradicionalmente, o USIM (ou, mais geralmente, "SIM") desem-

penha o procedimento bem conhecido de autenticação e consentimento de chave (AKA), que verifica e decriptografa os dados aplicáveis e programas para garantir a inicialização segura. Especificamente, o USIM precisa tanto (i) responder com sucesso um desafio remoto para provar sua identidade 25 para o operador da rede quanto (ii) emitir um desafio para verificar a identi- dade da rede.

Embora soluções tradicionais de SIM sejam incorporadas dentro de um cartão de circuito integrado (ICC) removível (também chamado de "cartão SIM"), a pesquisa incipiente pelo procurador dessa é direcionada à 30 virtualização da operação do SIM dentro de um cliente de software execu- tando dentro do dispositivo móvel. A operação virtualizada do SIM pode re- duzir o tamanho do dispositivo, aumentar a funcionalidade do dispositivo e prover maior flexibilidade.

Infelizmente, a operação virtualizada do SIM também apresenta múltiplos novos desafios para operadores de rede e fabricantes de dispositi- vos. Por exemplo, cartões SIM tradicionais são fabricados e garantidos por 5 um fornecedor de confiança do SIM. Esses cartões SIM tradicionais execu- tam uma versão de software única segura que foi permanentemente "quei- mada” no cartão SIM. Uma vez queimado, o cartão não pode ser falsificado (sem também destruir o cartão SIM).

Em contraste, dispositivos móveis são fabricados por uma ampla 10 faixa de fabricantes de dispositivo, e podem executar software provido por múltiplos fornecedores de software ou até mesmo por terceiros desconheci- dos. Adicionalmente, os dispositivos móveis são frequentemente "conserta- dos" com software, que pode tanto reparar erros existentes quanto introduzir novos. Qualquer software é suscetível à corrupção, sabotagem e/ou abuso. 15 Além do mais, embora os cartões SIM físicos sejam muito difíceis de copiar, o software pode ser facilmente copiado, multiplicado, etc. Desde que cada SIM represente um contratado para uma quantidade de acesso aos recursos finitos da rede, o uso ilícito de um SIM virtualizado pode impactar grande- mente a operação da rede e a experiência do usuário.

Dessa forma, novas soluções são necessárias para prover pro-

teções e propriedades para SIMs virtualizados que sejam geralmente análo- gas a essas dos SIMs "rígidos" tradicionais. De forma mais geral, soluções melhoradas são necessárias para armazenar e distribuir clientes de controle de acesso virtualizados. Idealmente, tais soluções devem proporcionar os 25 benefícios da operação do cliente de controle de acesso tradicional, com as capacidades adicionais da operação virtualizada.

Sumário da Invenção

A presente invenção trata as necessidades precedentes forne- cendo, entre outros, aparelhos e métodos para o armazenamento e a distri- buição de clientes de controle de acesso para dispositivos.

Em um aspecto da presente invenção, um aparelho para arma- zenar um ou mais elementos de dados de acesso é revelado. Em uma mo- dalidade, o aparelho seguro inclui um elemento seguro adaptado para arma- zenar uma pluralidade de elementos de dados de acesso do usuário, cada elemento de dados de acesso do usuário criptografado para o elemento se- guro. O aparelho seguro ainda inclui um processador e um dispositivo de 5 armazenamento em comunicação de dados com o processador, o dispositi- vo de armazenamento incluindo instruções executáveis pelo computador que são configuradas para, quando executadas pelo processador: receber uma solicitação por um ou mais elementos de dados de acesso de um dispositivo par; verificar o dispositivo par; decriptografar o um ou mais elementos de 10 dados de acesso solicitados; criptografar novamente o um ou mais elemen- tos de dados de acesso decriptografados para o dispositivo par e transferir o um ou mais elementos de dados novamente criptografados para o dispositi- vo par verificado, a transferência causando a remoção do um ou mais ele- mentos de dados de acesso do elemento seguro.

Em uma variação, o elemento de dados de acesso do usuário é

um Módulo de Identidade do Assinante eletrônico (eSlM).

Em uma segunda variação, a verificação inclui conferir um certi- ficado associado com o dispositivo par, e gerar uma resposta de desafio.

Em uma terceira variação, as instruções executáveis pelo com- 20 putador incluem adicionalmente instruções que são configuradas para, quando executadas pelo processador, negociar um protocolo de transferên- cia. Em um exemplo, a nova criptografia do um ou mais elementos de dados de acesso decriptografados ê baseada pelo menos em parte no protocolo de transferência. Em outro exemplo, o protocolo de transferência inclui um ou 25 mais elementos de sinais de estabelecimento de comunicação. Em ainda outro tal exemplo, o protocolo de transferência negociado inclui a identifica- ção de um protocolo de transferência suportado pelo aparelho e o dispositivo par.

Em uma quarta variação, o aparelho inclui um Módulo de Segu- rança de Hardware (HSM).

Em uma quinta variação, o aparelho é personificado dentro de um telefone móvel. Em ainda uma sexta variação, o aparelho é personificado dentro de um fator de forma de cartão físico.

Em outra modalidade, o aparelho inclui um elemento seguro a- daptado para armazenar uma pluralidade de elementos de dados de acesso do usuário, cada elemento de dados de acesso do usuário criptografado pa- ra o elemento seguro. O aparelho ainda inclui um processador e um disposi- tivo de armazenamento em comunicação de dados com o processador, o dispositivo de armazenamento incluindo instruções executáveis pelo compu- tador que são configuradas para, quando executadas pelo processador: soli- citar um ou mais elementos de dados de acesso de um dispositivo par verifi- cado; receber o um ou mais elementos de dados de acesso solicitados do dispositivo par verificado; verificar se o um ou mais elementos de dados de acesso solicitados são criptografados para o elemento seguro; armazenar o um ou mais elementos de dados de acesso criptografados dentro do ele- mento seguro e decriptografar o um ou mais elementos de dados de acesso criptografados durante o protocolo de autenticação.

Em uma variação, o elemento de dados de acesso do usuário é um Módulo de Identidade do Assinante eletrônico (eSlM).

Em uma segunda variação, o aparelho é personificado dentro de um telefone móvel.

Em uma terceira variação, o aparelho é personificado dentro de um fator de forma de cartão físico, para uso dentro do telefone móvel.

Em uma quarta variação, a verificação inclui conferir um certifi- cado digital emitido por uma autoridade de certificação de confiança.

Em uma quinta variação, a verificação inclui a conclusão de uma

troca criptográfica de desafio e resposta.

Em uma sexta variação, o dispositivo par inclui um Serviço de Aprovisionamento SIM (SPS).

Em uma sétima variação, o dispositivo par inclui um utensílio

eUICC.

Em uma oitava variação, o dispositivo par inclui um computador de mesa em comunicação operativa com uma memória de aplicações mó- veis.

Em um terceiro aspecto da presente invenção, um método para transferir um ou mais elementos de dados de acesso é revelado. Em uma modalidade, o um ou mais elementos de dados de acesso tendo um identifi- 5 cador único associado com eles, e o método inclui: estar de acordo com um protocolo de transferência entre um dispositivo e um dispositivo par; receber o um ou mais elementos dos dados de acesso do dispositivo par seguro; verificar o um ou mais elementos de dados de acesso transferidos, o um ou mais elementos de dados de acesso e identificador único sendo criptografa- 10 dos para o dispositivo e armazenar o um ou mais elementos de dados de acesso transferidos.

Em uma primeira variação, o elemento de dados de acesso do usuário inclui um Módulo de Identidade do Assinante eletrônico (eSlM).

Em uma segunda variação, o identificador único do um ou mais elementos de dados de acesso transferidos é determinado pelo dispositivo.

Em uma terceira variação, o identificador único do um ou mais elementos de dados de acesso transferidos é fornecido para o dispositivo par.

Em uma quarta variação, o método adicionalmente inclui notifi- car o dispositivo par da recepção bem-sucedida do um ou mais elementos de dados de acesso.

Em uma quinta variação, o identificador único do um ou mais e- Iementos de dados de acesso transferidos é fornecido para o dispositivo par.

Em um quarto aspecto da invenção, um aparelho legível por 25 computador é revelado. Em uma modalidade, o aparelho inclui um meio de armazenamento com pelo menos um programa de computador disposto ne- le, que é configurado para, quando executado: transferir um ou mais elemen- tos de dados de acesso por pelo menos: estar de acordo com um protocolo de transferência com um dispositivo par e receber o um ou mais elementos 30 de dados de acesso do dispositivo par.

Características adicionais da presente invenção, sua natureza e várias vantagens ficarão mais evidentes a partir dos desenhos acompanhan- tes e da descrição detalhada seguinte.

Breve Descrição dos Desenhos

A figura 1 ilustra graficamente um procedimento de autenticação e consentimento de chave (AKA) exemplar usando um USIM da técnica an- terior.

A figura 2 é um diagrama de blocos de uma arquitetura de rede exemplar útil para distribuir clientes de controle de acesso.

A figura 3 é um diagrama de fluxo lógico ilustrando uma modali- dade de um método generalizado para transferir clientes de controle de a- cesso para dispositivos de acordo com a presente invenção.

A figura 4 é um diagrama de blocos ilustrando uma modalidade de um utensílio eUICC adaptado para armazenar um ou mais clientes de controle de acesso, de acordo com a presente invenção.

A figura 5 é um diagrama de blocos ilustrando uma modalidade de um dispositivo móvel adaptado para armazenar e usar um ou mais clien- tes de controle de acesso, de acordo com a presente invenção.

Todas as figuras © Copyright 2011 Apple Inc. Todos os direitos

reservados.

Descrição Detalhada da Invenção Agora é feita referência aos desenhos nos quais números iguais

se referem a partes iguais por todos eles.

Visão geral

A presente invenção proporciona, entre outras coisas, métodos e aparelhos para armazenar e distribuir clientes de controle de acesso para 25 dispositivos, tais como, por exemplo, dispositivos móveis ou "smartphones". Em um primeiro aspecto da invenção, os dispositivos usados para transferir os clientes de controle de acesso (por exemplo, eSIMs) impõem imparidade e conservação dos clientes, garantindo que a transferência seja somente executada com um dispositivo de confiança. Em uma modalidade, um uten- 30 sílio eUICC é revelado, que é implementado dentro de um módulo de segu- rança de hardware (HSM). Cada HSM pode armazenar um grande número de eSIMs para facilitar o seu armazenamento e distribuição, tal como para serviços a varejo. Os utensílios eUICC descritos verificam, primeiro, se seus utensílios eUICC pares estão operando de acordo com um protocolo con- sentido e de confiança. Se ambos os utensílios eUICC estão de acordo, en- tão, quando o utensílio eUICC fonte transfere o seu eSlM, ele excluirá o e- 5 SIM (ou de alguma forma tornará inativo o seu próprio eSIM). O utensílio eUICC de destino manterá somente o eSlM ativo.

Em um segundo aspecto da invenção, quando um cliente de controle de acesso é movido de um dispositivo para outro, o dispositivo re- ceptor emite um desafio ou identificador único. Em uma modalidade, o dis- 10 positivo emissor criptografa o cliente de controle de acesso usando a chave pública do dispositivo receptor e adiciona um identificador único ou desafio, a combinação do cliente de controle de acesso criptografado e identificador único ou desafio é ainda assinada. Depois da transmissão, o dispositivo e- missor deleta o seu cliente de controle de acesso. O dispositivo receptor ve- 15 rifica o cliente de controle de acesso criptografado, e o identificador único; se válidos, então o cliente de controle de acesso criptografado e o identificador único são armazenados para uso futuro.

Na configuração exemplar, os clientes de controle de acesso são somente transferidos entre dispositivos que se conformam com uma relação 20 de confiança padrão. Dessa maneira, desde que ambos os dispositivos este- jam operando de acordo com um protocolo consentido, o cliente de controle de acesso pode permanecer único e conservado por toda a transferência. Além do mais, garantindo que o cliente de controle de acesso seja criptogra- fado somente para o dispositivo de destino e excluído do dispositivo atual, 25 indivíduos maliciosos intermediários não podem subverter ou malograr o processo de transferência.

Vários outros cenários para transferência dos clientes de contro- le de acesso são também descritos em mais detalhes aqui.

Descrição detalhada das modalidades exemplares Modalidades exemplares e aspectos da presente invenção são

agora descritos em detalhes. Embora essas modalidades e aspectos sejam primariamente discutidos no contexto de módulos de identidade do assinante (SIMs) de um GSM, GPRS/EDGE ou rede celular UMTS1 será reconhecido por aqueles versados na técnica que a presente invenção não é, de tal for- ma, limitada. De fato, os vários aspectos da invenção são úteis em qualquer rede (quer celular sem fio ou outra) que pode se beneficiar do armazena- 5 mento e distribuição de clientes de controle de acesso para dispositivos.

Também será reconhecido que embora o termo "módulo de i- dentidade do assinante" seja usado aqui (por exemplo, eSlM), esse termo de forma alguma, necessariamente, conota ou requer (i) o uso por um assinante por si (isto é, a invenção pode ser praticada por um assinante ou não assi- 10 nante); (ii) a identidade de um único indivíduo (isto é, a invenção pode ser praticada em nome de um grupo de indivíduos, tal como uma família, ou en- tidade intangível ou fictícia, tal como uma empresa) ou (iii) qualquer equipa- mento de "módulo" tangível ou hardware.

Operação do Módulo de Identidade do Assinante (SIM) da técni- ca anterior -

Dentro do contexto da rede celular UMTS da técnica anterior e- xemplar, o equipamento do usuário (UE) inclui um dispositivo móvel e um Módulo de Identidade do Assinante Universal (USIM). O USIM é uma enti- dade lógica de software que é armazenada e executada a partir de um Car- 20 tão de Circuito Integrado Universal (UICC) físico. Uma variedade de informa- ção é armazenada no USIM, tal como informação do assinante, bem como as chaves e algoritmos usados para a autenticação com o operador de rede a fim de obter serviços de rede sem fio. Em uma modalidade, o software U- SIM é baseado na linguagem de programação Java CardP. Java Card é um 25 subconjunto da linguagem de programação Java® que foi modificada para dispositivos do tipo de "cartão" embutido (tal como o UICC antes menciona- do). Outras implementações podem incluir assim chamadas implementações de software "nativas" e/ou implementações que são patenteadas, etc.

Geralmente, UICCs são programados com um USIM antes da distribuição para o assinante; a pré-programação ou "personalização" é es- pecífica para cada operador de rede. Por exemplo, antes da disposição, o USIM é associado com um Identificador do Assinante Móvel Internacional (IMSI), um Identificador do Cartão de Circuito Integrado (ICC-ID) único e uma chave de autenticação específica (K). O operador da rede armazena a associação em um registro contido no centro de autenticação da rede (AuC). Depois da personalização, o UICC pode ser distribuído para os assinantes.

Com referência agora à figura 1, um procedimento exemplar de

autenticação e consentimento de chave (AKA) usando o USIM, da técnica anterior, antes mencionado é ilustrado em detalhes. Durante os procedimen- tos de autenticação normais, o UE adquire o Identificador do Assinante Mó- vel Internacional (IMSI) do USIM. O UE passa o IMSI para a rede de serviço (SN) do operador de rede ou para a rede núcleo visitada. A SN envia a soli- citação de autenticação para o AuC da Rede Residencial (HN). A HN com- para o IMSI recebido com o registro do AuC e obtém a K apropriada. A HN gera um número aleatório (RAND) e o assina com a K usando um algoritmo para criar a resposta esperada (XRES). A HN ainda gera uma Chave de Ci- fra (CK) e uma Chave de Cntegridade (IK) para uso na proteção da cifra e integridade, bem como uma ficha de autenticação (AUTN) usando vários algoritmos. A HN envia um vetor de autenticação, consistindo do RAND, XRES, CK e AUTN para a SN. A SN armazena o vetor de autenticação so- mente para uso em um processo de autenticação único. A SN passa o RANDeAUTNparaoUE.

Depois que o UE recebe o RAND e a AUTN, o USIM verifica se a AUTN recebida é válida. Se afirmativo, o UE usa o RAND recebido para computar a sua própria resposta (RES) usando a K armazenada e o mesmo algoritmo que gerou a XRES. O UE passa a RES de volta para a SN. A SN 25 compara a XRES com a RES recebida e se elas correspondem, a SN autori- za o UE a usar os serviços de rede sem fio do operador.

O procedimento precedente da figura 1 é personificado dentro dos meios físicos do cartão SIM. Cartões SIM da técnica anterior têm pelo menos duas (2) propriedades distintas e desejáveis: (i) cartões SIM proveem 30 armazenamento seguro do ponto de vista criptográfico para dados do SIM (por exemplo, informação de conta, chaves de criptografia, etc.) e (ii) cartões SIM não podem ser facilmente clonados. Um cartão SIM da técnica anterior inclui um processador e me- mória formados um cartão de circuito integrado universal (UICC). O cartão SIM pode ser preenchido com resina de epóxi para impedir sondagem exter- na dos sinais de dados no UICC. Outras estruturas à prova de falsificação 5 podem ser incluídas no UICC, se desejado (por exemplo, camadas de prote- ção, camadas de máscara, etc.). O cartão SIM tem uma interface segura com o processador, e o processador tem uma interface interna com a memó- ria. O UICC recebe força do dispositivo externo, o que possibilita que o pro- cessador execute o código do componente de memória. O próprio compo- 10 nente de memória não fica diretamente acessível (isto é, sistemas de arqui- vos internos ficam ocultos do usuário) e precisam ser acessados via o pro- cessador.

Durante a operação normal, o processador aceita um número li- mitado de comandos. Cada um dos comandos é somente acessível condi- 15 cionalmente. As condições de acesso são limitadas à execução dos coman- dos para impedir o acesso desautorizado. As condições de acesso podem ou não ser hierárquicas, por exemplo, autorização para um nível pode não conceder automaticamente autorização para outro nível. Por exemplo, um conjunto de condições de acesso pode incluir: (i) sempre acessível, (ii) nun- 20 ca acessível, (iii) acessível para uma primeira conta, (iv) acessível para uma segunda conta, etc. O acesso condicional é concedido somente depois da conclusão bem-sucedida de um protocolo de segurança apropriado. Méto- dos comuns para verificar a identidade podem incluir uma senha ou número de identificação pessoal (PIN), desafio de um segredo compartilhado, etc.

O acesso condicional, o conjunto de comandos limitado e o es-

paço protegido da memória garantem que a informação armazenada no car- tão SIM fique segura contra o acesso externo. A clonagem de um cartão SIM acarretaria a construção de um cartão físico e a construção do sistema de arquivos interno e dados. A combinação desses aspectos torna o cartão SIM físico impenetrável às tentativas práticas de falsificação.

Operação do Módulo de Identidade do Assinante eletrônico (e-

SIM)- Como um breve aparte, os termos "conservação", "conservar" e "conservado", como usados aqui, se referem a um elemento (físico ou virtu- al) que não pode ser trivialmente multiplicado ou diminuído. Por exemplo, um eSlM conservado não pode ser copiado ou replicado durante a operação normal.

Adicionalmente, como usado aqui, o termo "imparidade", quando aplicado a um elemento (físico ou virtual), se refere à propriedade pela qual o elemento é o único elemento tendo uma propriedade e/ou característica particular. Por exemplo, um eSlM único não pode ter um eSlM duplicado.

Como usado aqui, o termo "segurança" geralmente se refere à

proteção dos dados e/ou software. Por exemplo, a segurança dos dados de controle de acesso garante que os dados e/ou software associados com um cliente de controle de acesso sejam protegidos de roubo, abuso, corrupção, publicação e/ou falsificação, por atividades desautorizadas e/ou indivíduos maliciosos.

Além do mais, como usado aqui, o termo "autorização do usuá- rio" geralmente se refere à especificação do acesso de um usuário aos re- cursos. Como um breve aparte, com os cartões SIM físicos da técnica ante- rior, a autorização do usuário é imposta com a posse do cartão SIM físico; o 20 cartão físico representa a autorização do usuário aos recursos da rede de acesso. Por exemplo, quando um cartão SIM físico é movido de um primeiro telefone para um segundo telefone, é assumido que o movimento foi execu- tado pelo usuário (e implicitamente autorizado pelo usuário). Dentro do con- texto da operação do eSlM, capacidades análogas são necessárias para a 25 autorização do usuário das transferências do eSIM. Em particular, o "dono" do eSlM (e também a rede) precisa de garantias que o eSlM é somente transferido para dispositivos legítimos.

De forma geral, é verificado que o software é mais flexível do que o hardware; por exemplo, o software é fácil para copiar, modificar e dis- tribuir. Adicionalmente, o software pode ser fabricado frequentemente de maneira mais barata, com mais eficiência de energia e fisicamente menor do que os equivalentes de hardware. Dessa forma, embora a operação do SIM convencional faça uso de fatores de forma físicos, tais como cartões (UICCs), áreas atuais de pesquisa estão focalizadas na virtualização da ope- ração do SIM dentro do software. Entretanto, a natureza sensível dos dados do SIM (por exemplo, informação específica do assinante, etc.) exige consi- 5 deração especial. Por exemplo, várias porções dos dados do SIM são únicas para os assinantes e devem ser guardadas cuidadosamente contra indiví- duos maliciosos. Além do mais, como previamente declarado, cada SIM re- presenta um contratado para a quantidade de acesso aos recursos finitos da rede; assim, a duplicação, destruição e/ou reclamação dos SIMs precisam 10 ser controladas para impedir super e/ou subutilização dos recursos da rede, bem como sub-rogação das remunerações ou renda do provedor do serviço. Dessa forma, SIMs virtualizados devem satisfazer as propriedades seguin- tes: (i) segurança, (ii) imparidade e (iii) conservação. Além do mais, tais pro- priedades devem ser proporcionadas idealmente em um custo comparável 15 com infraestruturas de rede existentes.

%

Soluções incipientes para a operação do SIM emulam um UICC como uma entidade virtual ou eletrônica tal como, por exemplo, uma aplica- ção de software, a seguir chamada como um Cartão de Circuito Integrado Universal eletrônico (eUICC). O eUICC é capaz de armazenar e gerenciar 20 um ou mais elementos do SIM, citado a seguir como Módulos de Identidade do Assinante eletrônico (eSlM). Entretanto, as soluções para a operação do eSlM virtualizado precisam fornecer segurança equivalente (se não melho- rada) para capacidades de segurança existentes já fornecidas pelos UICCs da técnica anterior. Adicionalmente, a infraestrutura existente requer méto- 25 dos adequados para impor a conservação dos eSIMs virtualizados, tal que o número de eSIMs virtualizados seja controlado por toda a rede (isto é, eSIMs virtualizados não são duplicados, perdidos, etc.).

Considere o sistema ilustrado na figura 2: o sistema 200 inclui:

(i) vários fornecedores de SIM 202, (ii) vários servidores de aprovisionamen- 30 to de SIM (SPSs) 204 (tal como esses descritos em mais detalhes no Pedido de Patente U.S. copossuído e copendente Nos. 12/952.082, depositado em 22 de novembro de 2010 e intitulado "WIRELESS NETWORK AUTHENTI- CATION APPARATUS AND METHODS", e 12/952.089, depositado em 22 de novembro de 2010 e intitulado "APPARATUS AND METHODS FOR PROVISIONING SUBSCRIBER IDENTITY DATA IN A WIRELESS NET- WORK", previamente incorporado por referência) e (iii) uma população de 5 equipamentos do usuário (UE) 206, onde cada UE contém um eUICC segu- ro. As discussões seguintes descrevem esquemas diferentes para distribuir eSIMs do fornecedor do SIM para o eUICC seguro.

Em um primeiro esquema, o UE 206 solicita um eSlM de qual- quer SPS 204, e o SPS recupera um eSlM apropriado de uma entidade de confiança, tal como o fornecedor do SIM 202 (ou em outros casos, um ope- rador da rede móvel (MNO), gerenciador dos serviços de confiança (TSM), etc.). Nessa abordagem, o fornecedor do SIM pode controlar facilmente a distribuição dos eSIMs; cada eSlM recentemente solicitado é concedido so- mente pelo fornecedor do SIM. Entretanto, desde que o fornecedor do SIM seja a única parte que pode entregar eSIMs, o fornecedor do SIM pode criar "estrangulamentos" se uma grande população de assinantes sobrecarregou o fornecedor do SIM com solicitações dentro de um curto período de tempo (como é comum para versões de produto bem-sucedido). Similarmente, o fornecedor do SIM é um ponto de falha único. Consequentemente na even- tualidade de um desastre, a emissão do eSlM seria completamente parada.

Em um segundo esquema, cada SPS 204 recupera uma associ- ação de eSIMs do fornecedor do SIM 202, e armazena a associação de e- SIMs dentro de cada SPS (a associação de eSIMs é duplicada para cada SPS). A seguir, o SPS distribui os eSIMs para UEs 206 sob solicitação. O 25 eSlM pode ser somente decriptografado e usado pelo eUICC seguro. Esse modelo de servidor SPS distribuído não é estrangulado pelo fornecedor do SIM. Entretanto, esse segundo esquema requer substancialmente mais in- fraestrutura. Especificamente, a população de SPSs precisa garantir que nenhum eSlM duplicado seja distribuído. Dessa forma, sempre que um SPS 30 concede um eSlM, os outros SPSs precisam ser notificados para desativar os seus eSIMs duplicados via o elo de comunicação 208. Isso garante que os eSIMs sejam únicos (isto é, nenhum eSlM duplicado foi distribuído). A comunicação para manter a sincronização da informação do estado do eSlM entre os SPSs é uma quantidade significativa de tráfego na infraestrutura da rede. Além do mais, conexões de rede lentas ou interrupção de rede podem ainda causar "condições de corrida". Dentro do contexto da rede de compu- 5 tadores, condições de corrida geralmente se referem a riscos de dados re- sultantes do retardo da propagação entre a sincronização da entidade de rede. Por exemplo, a sincronização imperfeita pode fazer dois (2) SPSs ex- portarem o mesmo eSlM ao mesmo tempo (criando uma condição de corri- da); isso resultará no eSlM sendo clonado acidentalmente.

Em ainda um terceiro esquema (não mostrado), as infraestrutu-

ras do SPS 204 e do fornecedor do SIM 206 são combinadas em algum mo- do. Por exemplo, o fornecedor do SIM e a rede SPS podem ser alojados jun- tos em uma facilidade comum e livremente se acessarem ou ser, de outra forma, Iogisticamente entrelaçados. A operação bem-sucedida das facilida- 15 des entrelaçadas requer uma relação comercial de confiança entre o forne- cedor do SIM e o operador da rede SPS, o que pode ser indesejável (por exemplo, onde há conflito de interesses comerciais, devido às considerações legais antitruste, etc.).

Cada um dos esquemas precedentes requer recursos de comu- 20 nicações significativos para sincronizar as várias entidades de rede durante a transferência. Por exemplo, quando um eSlM é transferido com sucesso de um SPS para um dispositivo móvel, cada SPS precisa ser notificado que o eSlM não pode ser transferido novamente (para impedir múltiplas entregas do mesmo eSlM, por exemplo, como descrito acima).

Método -

Dessa forma, vários aspectos da presente invenção possibilitam vantajosamente a operação e a distribuição do cliente de controle de acesso virtualizado que proveem capacidades equivalentes e/ou melhoradas às so- luções da técnica anterior (por exemplo, clientes de controle de acesso ba- 30 seados em cartão físico). Em uma modalidade exemplar, uma entidade do serviço de aprovisionamento de SIM (SPS) independente pode operar em conjunto com outros dispositivos SPS pares, possibilitando modelos pares distribuídos para aprovisionamento do SIM (em oposição a um modelo cen- tralizado que acompanha os eSIMs a partir de um banco de dados centrali- zado ou esquemas distribuídos que exigem sincronização entre os dispositi- vos pares). Além do mais, como descrito em mais detalhes aqui, as modali- 5 dades da presente invenção não são específicas para qualquer infraestrutu- ra de rede particular, e podem acomodar com flexibilidade, virtualmente, qualquer configuração.

Em um aspecto da invenção, um cliente de controle de acesso pode ser armazenado e transferido somente para um elemento seguro de cada vez. Em uma modalidade, o elemento seguro armazena somente clien- tes de controle de acesso recebidos de outros elementos seguros que têm o mesmo protocolo ou comparáveis (descrito em mais detalhes subsequente- mente aqui). Similarmente, o elemento seguro limita a transferência dos cli- entes de controle de acesso para outros elementos seguros que têm os mesmos protocolos ou comparáveis. Por exemplo, os elementos seguros podem limitar as transações para outros elementos seguros que satisfazem certas exigências de segurança. Alguns operadores de rede móvel (MNO) podem impor maior segurança com seus dispositivos, do que outros MNOs. Em várias modalidades, elementos seguros poderiam ser certificados em níveis diferentes e os clientes de controle de acesso podem exigir um deter- minado nível de certificação. Durante o processo de transferência, o disposi- tivo remove (ou torna inativo) o seu próprio cliente de controle de acesso. Garantindo que ambos os clientes envolvidos na transferência sejam entida- des de confiança e honrem o mesmo protocolo, os clientes de controle de acesso não são multiplicados ou diminuídos na transferência.

Como um breve aparte, um elemento seguro pode ser personifi- cado como um processador ou aparelho de processamento executando software a partir de um meio de armazenamento protegido. Em algumas va- riações, o meio de armazenamento protegido é criptografado de modo a im- 30 pedir o acesso desautorizado ou falsificação. Além do mais, o elemento se- guro pode ser fisicamente endurecido ou protegido para impedir o acesso ao meio de armazenamento e/ou processador seguro. Exemplos comuns de endurecimento físico podem incluir um estojo físico ou outro mecanismo preparado para autodestruir ou tornar o dispositivo inacessível na eventuali- dade de tentativas de acesso desautorizado e/ou circuitos incorporados em uma resina ou outro material para impedir a sondagem externa.

Em algumas modalidades, o elemento seguro da presente in-

venção é configurado para ainda limitar e/ou monitorar/indicar o acesso a- nômalo. Por exemplo, em uma modalidade, a transferência ou armazena- mento de um cliente de controle de acesso no elemento seguro exige uma resposta de desafio e/ou identificador único. Uma resposta de desafio im- 10 própria ou um identificador incorreto pode indicar atividade anôma- la/fraudulenta. Similarmente, as transações entre os elementos seguros são criptografadas; assim, transações impropriamente criptografadas podem também indicar comportamento suspeito.

Com referência agora à figura 3, uma modalidade de um método 15 generalizado 300 para armazenar e transferir os clientes de controle de a- cesso para a invenção é mostrada. Em uma realização, pelo menos um dis- positivo é um utensílio eUICC que é personificado dentro de um Módulo de Segurança de Hardware (HSM) que pode controlar o armazenamento de um ou mais eSIMs. Em algumas modalidades, o HSM armazena eSlM criptogra- 20 fado localmente, ou alternadamente, criptografa o eSlM para armazenamen- to em meios remotos (em alguns casos, sistemas de arquivos inseguros). Em uma realização alternada, pelo menos um dispositivo é um utensílio eUICC que é personificado dentro de um fator de forma de cartão SIM físico (por exemplo, possibilitando reúso do receptáculo do fator forma legado). Em 25 ainda uma alternativa, pelo menos um dispositivo é um dispositivo endureci- do, tal como um telefone móvel incluindo um utensílio eUICC personificado dentro de um elemento seguro (isto é, o elemento seguro não pode ser re- movido do dispositivo sem destruir ou de outra forma comprometer a integri- dade do dispositivo).

Na etapa 302 do método 300, o dispositivo fonte e o dispositivo

de destino estão de acordo com um protocolo. Em uma modalidade, o tipo do protocolo é baseado em uma versão do software identificado, por exem- pio, em texto simples. Em outras modalidades, o tipo do protocolo é inerente a uma comunicação inicial de outra forma cifrada. Por exemplo, um desafio de 256 bits criptografado pode especificar inerentemente um protocolo parti- cular ou conjunto de protocolos, enquanto que um desafio não criptografado 5 pode especificar inerentemente um protocolo diferente. Em ainda outras mo- dalidades, o protocolo pode ser baseado em um processo de descoberta. Por exemplo, em algumas variações, os dispositivos podem ser registrados com um serviço de diretório, onde um registro inclui informação tais como identificador, endereço da rede, tipos de protocolos suportados, etc.

Em uma modalidade exemplar, o tipo do protocolo é determina-

do por um certificado assinado emitido por uma autoridade emissora mutu- amente de confiança. Um certificado digital pode incluir, mas não é limitado

a, por exemplo: (i) um número de série (para identificar unicamente o certifi- cado), (ii) o dispositivo sendo certificado, (iii) o algoritmo de assinatura usado 15 para criar a assinatura, (iv) o emissor que verificou a informação e assinou o certificado, (v) uma faixa de validade (por exemplo, válido de, válido até, etc.), (vi) uma chave de criptografia e/ou (vii) uma impressão digital ou prova de verificação (para verificar a legitimidade do certificado). Certificados digi- tais são bem conhecidos nas técnicas relacionadas e não serão mais descri- 20 tos.

Em tal variação, a autoridade emissora mutuamente de confian- ça é uma autoridade de ativação, por exemplo, o centro de autenticação (AuC) do operador da rede móvel (MNO). Em outras variações, a autoridade emissora mutuamente de confiança é um terceiro de confiança, por exemplo, 25 um fornecedor do SIM, o fabricante do dispositivo, etc. A autoridade emisso- ra mutuamente de confiança não precisa ser a mesma para ambos os dispo- sitivos. Por exemplo, em algumas modalidades, um sistema pode ter múlti- plas entidades de confiança (por exemplo, múltiplos MNOs aceitos, múltiplos fabricantes do dispositivo de confiança, etc.). Além do mais, em certos sis- 30 temas, uma entidade de confiança pode ser uma origem de confiança para outra entidade desconhecida (por exemplo, a entidade de confiança fornece garantia que a entidade desconhecida pode também ser de confiança). Tais "correntes" de confiança podem ser estendidas através de um número arbi- trário de dispositivos intermediários; cada dispositivo intermediário está sujei- to ao nível de confiança de seu predecessor, que se estende para a entidade de origem de confiança.

5 Em outros exemplos, os utensílios eUICC podem suportar qual-

quer dispositivo utensílio que seja complacente com uma especificação pa- dronizada, etc. Similarmente, para garantir compatibilidade inversa, corporifi- cações futuras de um utensílio eUICC podem também suportar utensílios eUICC legados, etc.

Os dispositivos disponíveis e/ou protocolos aceitos para disposi-

tivos disponíveis podem ser armazenados, por exemplo, dentro de um servi- ço de diretório de consulta. Tais aplicações do tipo de serviço de diretório são comuns dentro das técnicas de infraestrutura de rede. Por exemplo, múl- tiplas formações de utensílios podem ser ainda combinadas com um servidor 15 do serviço de diretório configurado para fornecer informação de conexão para cada um dos utensílios. Uma parte solicitante (fonte ou destino) pode solicitar informação do serviço de diretório.

Em algumas modalidades, os protocolos são codificados de a- cordo com uma versão ou revisão do software. Por exemplo, os dispositivos 20 podem verificar que o outro dispositivo é de uma versão ou revisão de soft- ware aceitável. Alternadamente, os dispositivos fonte e de destino podem estar de acordo com um protocolo informal; por exemplo, pode ser necessá- rio que os dispositivos negociem ou determinem um protocolo dinamicamen- te. Em ainda outras modalidades, nenhuma negociação de protocolo é ne- 25 cessária (isto é, sistemas que somente suportam um único protocolo de transferência).

O protocolo de transferência pode especificar, entre outras coi- sas, os tipos de protocolos de resposta de desafio, seleção de identificador único, criptografia de transferência, gerenciamento do cliente de controle de 30 acesso (por exemplo, procedimentos de exclusão, procedimentos de confir- mação, etc.) durante a transferência. Como previamente indicado, a fim de garantir que as propriedades de conservação e imparidade de um cliente de controle de acesso sejam mantidas durante a transferência, o cliente de con- trole de acesso é criptografado para o dispositivo de destino, e excluído do dispositivo de transferência. Por exemplo, o protocolo de transferência pode especificar: (i) se a confirmação da recepção é necessária, (ii) se a retrans- 5 missão é permitida quando a transmissão falha, (iii) um número aceitável de tentativas e/ou (iv) sob quais condições o dispositivo fonte pode excluir o cliente de controle de acesso criptografado.

Será verificado que o dispositivo fonte pode excluir e/ou desati- var o cliente de controle de acesso criptografado em tempos diferentes e/ou 10 sob condições diferentes, conforme seja conveniente ou exigido sob os vá- rios cenários. Em algumas modalidades, a exclusão pode ocorrer algum tempo depois da transferência. Tais modalidades podem ser de uso particu- lar em transferências em massa. Alternadamente, o cliente de controle de acesso pode ser desativado algum tempo antes da transferência. Similar- 15 mente, em outras modalidades, uma "janela de validade" pode também ser especificada para a transferência, tal que uma transferência particular preci- sa ser realizada dentro de uma janela temporal prescrita para ser considera- da válida.

Outras considerações incluem, entre outras coisas, considera- ções do dispositivo e/ou considerações do cliente de controle de acesso. Por exemplo, alguns dispositivos podem somente ter permissão para receber (ou transmitir) um cliente de controle de acesso. Em tal realização, um dispositi- vo móvel pode ser limitado a somente receber um eSlM (uma vez assinado, ele não pode ser retomado, etc.). Alternadamente, certos dispositivos podem ser usados somente como uma transferência "única" (por exemplo, um dis- positivo descartável para fornecer um eSlM uma vez). Em alguns casos, um dispositivo pode ser mais (ou menos) seguro do que o dispositivo par. Por exemplo, em uma modalidade exemplar, o equipamento do usuário pode ter exigências de segurança mais rígidas do que um utensílio eUICC; o utensílio eUICC pode ser protegido através de outras medidas (por exemplo, infraes- trutura segura, etc.). O equipamento seguro do usuário pode também trans- ferir um eSlM para um utensílio eUICC menos seguro, contanto que o uten- sílio eUICC menos seguro realize um nível mínimo de segurança. Similar- mente, em alguns casos, os clientes de controle de acesso têm limitações de transferência, incluindo, mas não limitado a: (i) um número total de transfe- rências permitidas, (ii) restrições do dispositivo de destino, etc.

Além do mais, é verificado que o método de comunicação pode

ter impacto significativo nas considerações do protocolo de transferência. As transferências da infraestrutura de rede podem usar protocolos de grande largura de banda e meios (por exemplo, T3, Tl, Sonet (rede ótica síncrona), Gigabit Ethernet, etc.), enquanto que as transferências com base no consu- 10 midor podem ser executadas através de conexões com menor largura de banda (por exemplo, acesso celular, WLAN (rede local sem fio), Ethernet, etc.). Cenários de uso diferentes podem também ter exigências diferentes para os sinais de estabelecimento de comunicação, exigências do tempo de transferência, etc. Por exemplo, um fornecedor do SIM pode transferir um 15 grande número de eSIMs para um utensílio eUICC (por exemplo, tal como para facilitar a entrega do SIM ou outras funções). Similarmente, em outro exemplo, um repositório grande centralizado de eSIMs pode ser livremente transferido entre vários utensílios eUICC. Os utensílios eUICC podem trans- ferir livremente eSIMs de utensílio para utensílio, para facilitar o gerencia- 20 mento da carga, etc. As exigências dos sinais de estabelecimento de comu- nicação para esses cenários de transferência em massa são menos impor- tantes, já que os eSIMs não estão circulando (confirmações podem ser a- grupadas no fim da transferência, ao invés de para cada eSlM individual).

Aplicações do consumidor podem ter taxas de transferência mui- 25 to mais lentas, mas os sinais de estabelecimento de comunicação são mais importantes, já que o eSlM deve ser entregue robustamente, e imediatamen- te disponível para uso. Em algumas variações, a falha para completar o pro- cesso dos sinais de estabelecimento de comunicação disparará automati- camente uma nova tentativa. Por exemplo, um utensílio eUICC, servidor de 30 aprovisionamento do SIM (SPS) ou entidade similar pode transferir direta- mente um eSlM para servir uma solicitação de eSlM improvisada provenien- te do equipamento do usuário (UE), ou uma aplicação executando a partir de um computador de mesa ou portátil. Em outro tal exemplo, aplicações base- adas no consumidor podem executar um pequeno utensílio internalizado capaz de armazenar um ou mais eSIMs (por exemplo, um para trabalho, um para uso pessoal, vários para acesso em viagem, etc.) possibilitando que um 5 consumidor transfira um eSlM entre seus vários dispositivos.

Na etapa 304 do método 300 da figura 3, os dispositivos fonte e de destino estabelecem um segredo compartilhado. Em uma modalidade exemplar, os dispositivos verificam a identidade do dispositivo par inspecio- nando uma assinatura digital, e se a assinatura é válida, troca (ou concorda 10 em trocar) um desafio, identificador único ou outra ficha de segurança para criptografia com o cliente de controle de acesso.

Por exemplo, os dispositivos podem utilizar os sinais de estabe- lecimento de comunicação do tipo desafio e resposta, onde qualquer disposi- tivo de confiança conhece um segredo comum (por exemplo, uma chave 15 comum, um conjunto de chaves, etc.), que pode ser usado para gerar vários desafios e respostas associadas. Os dispositivos podem confiar em um dis- positivo desconhecido, contanto que eles possam gerar desafios apropriados e/ou respostas apropriadas.

Em outro exemplo, os dispositivos podem utilizar um identifica- dor único que é gerado pelo dispositivo de destino com a solicitação do cli- ente de controle de acesso. O dispositivo fonte inclui o identificador único com o cliente de controle de acesso para identificar a solicitação prestada.

Em ainda outras modalidades, os dispositivos podem verificar o seu dispositivo par com um terceiro de confiança (por exemplo, o terceiro de 25 confiança fornece para cada um dos dispositivos uma chave de sessão). Tais relações podem ser verificadas direta ou indiretamente. Por exemplo, os dispositivos pares podem consultar diretamente um terceiro de confiança antes de executar a transferência, ou alternadamente cada dispositivo pode apresentar um certificado assinado pelos terceiros de confiança, etc.

Ainda outros tipos de disposições criptográficas e cenários de

confiança serão reconhecidos para uso com a invenção por aqueles versa- dos dada a presente revelação. Na etapa 306, o dispositivo fonte coloca em pacote o cliente de controle de acesso com o segredo (por exemplo, desafio, identificador único ou outra ficha de segurança). Em uma modalidade exemplar, o pacote é adi- cionalmente criptografado usando a chave pública do dispositivo de destino.

5 Em uma variação, o dispositivo fonte precisa decriptografar, primeiro, o clien- te de controle de acesso com sua própria chave privada, antes de criptogra- far novamente o cliente de controle de acesso.

Depois de criptografado com a chave pública do dispositivo de destino, somente o dispositivo de destino pode decriptografar o cliente de controle de acesso para uso. Um exemplo de uma criptografia com chaves pública e privada para transferência de clientes de controle de acesso é des- crito no Pedido de Patente Provisório U.S. No. 61/407.866, depositado em 28 de outubro de 2010 e intitulado "METHODS AND APPARATUS FOR STORAGE AND EXECUTION OF ACCESS CONTROL CLIENTS", previa- mente incorporado aqui. Por exemplo, cada utensílio eUICC tem um único par de chaves pública/privada do dispositivo e certificado de endosso. O par de chaves pública/privada é baseado em uma chave privada secreta e uma chave pública publicável. Os esquemas de chaves pública/privada são con- siderados "assimétricos", já que a chave usada para criptografar e decripto- grafar são diferentes, e assim, o mecanismo de criptografia e o de decripto- grafia não compartilham a mesma chave.

É ainda reconhecido que as etapas 306 e 304 (entre outras) po- dem ser também combinadas, subdivididas e/ou invertidas. Por exemplo, em uma modalidade, o dispositivo fonte determina uma chave de sessão e crip- 25 tografa o cliente de controle de acesso com a chave de sessão, o pacote resultante sendo ainda completado com a chave pública do dispositivo de destino. Em uma tal variação, a chave de sessão é determinada pelo dispo- sitivo de destino no momento da recepção.

Adicionalmente, em algumas modalidades, os pacotes são ainda digitalmente assinados para fornecer verificação adicional do dispositivo fon- te. O dispositivo de destino pode conferir a assinatura digital, para verificar se o pacote (por exemplo, o cliente de controle de acesso e o identificador único, etc.) originou do dispositivo fonte. Além do mais, é amplamente verifi- cado que as assinaturas digitais são meramente um subconjunto de assina- turas eletrônicas, consequentemente outras formas de verificação da fonte podem ser similarmente utilizadas incluindo, mas não limitado a: identifica- 5 ção do usuário (senha, biometria, etc.), identificação eletrônica, etc.

Na etapa 308, o cliente de controle de acesso em pacote é transferido do dispositivo fonte para o de destino. O dispositivo de destino verifica o segredo compartilhado e se a verificação é bem-sucedida, arma- zena o cliente de controle de acesso criptografado para uso futuro. Em uma 10 modalidade, o cliente de controle de acesso é excluído, desativado ou de outra forma tornado inutilizável, no dispositivo fonte antes de habilitar o clien- te de controle de acesso para o dispositivo de destino (por exemplo, antes da transferência, antes de completar a transferência, antes da confirmação do sucesso da transferência, etc.).

Operação exemplar -

Como um exemplo de operação típica de acordo com a inven- ção, durante a inicialização, os fornecedores do SIM fornecem uma coleção ou "lote" de eSIMs para os utensílios eUICC. Observe que múltiplos forne- cedores de SIM (e) podem fornecer independentemente eSIMs; não existe 20 colaboração requerida por parte dos fornecedores do SIM (embora tal cola- boração possa também ser usada sè desejada). Os fornecedores do SIM ainda criptografam cada um dos eSIMs com um desafio ou identificador úni- co para os utensílios eUICC.

Como previamente descrito, cada eSlM inclui um SIM virtualiza- 25 do e as associações de chave única e capacidades para executar o esque- ma antes mencionado de autenticação e consentimento de chave (AKA) pa- ra autenticar um dispositivo móvel para a rede celular (ver discussão da O- peração do módulo de identidade do assinante (SIM) da técnica anterior acima). Adicionalmente, cada eSlM é associado unicamente com um desafio 30 ou identificador que muda em uma base por transferência. Uma realização típica de um desafio ou identificador pode incluir um material criptográfico, contador, seqüência pseudoaleatória, máquina de grande estado, etc. Considere a operação seguinte - um primeiro utensílio eUICC i- nicia uma transferência de eSlM (que está atualmente criptografado para o primeiro utensílio eUICC) para um segundo utensílio eUICC. O primeiro u- tensílio eUICC inicia uma comunicação segura com o segundo utensílio 5 eUICC. Em um cenário, ambos os primeiro e segundo utensílios eUICC concordam com a transferência baseada em certificados assinados por um ou mais dos terceiros mutuamente de confiança. O segundo utensílio eUICC provê um identificador único para o primeiro utensílio eUICC. O primeiro u- tensílio eUICC decriptografa o eSlM com a sua própria chave privada, e de- 10 pois criptografa novamente o eSlM com a chave pública do segundo eUICC (a chave pública é livremente distribuída pelo segundo eUICC). A combina- ção do identificador único e do eSlM novamente criptografado é assinada pelo primeiro utensílio eUICC (a assinatura verifica a identidade do primeiro utensílio eUICC). A combinação assinada é colocada em pacote para o se- 15 gundo eUICC. Agora, somente o segundo eUICC pode decriptografar o e- SIM, e a combinação assinada prova que o pacote do eSlM criptografado corresponde com o identificador único. O primeiro utensílio eUICC transmite o eSlM recentemente criptografado para o segundo utensílio eUICC.

Em uma modalidade, o identificador único é usado para proteger 20 contra ataques de reprodução. Por exemplo, cada transferência de eSlM é unicamente identificada, assim a transação não pode ser "copiada" e repro- duzida (por exemplo, por um terceiro malicioso). Por exemplo, quando trans- ferindo um eSlM do utensílio A para o utensílio B, e depois do utensílio B para o utensílio C, a transferência entre o utensílio A para o utensílio B não 25 pode ser reproduzida enquanto o eSlM está ainda no utensílio C.

Similarmente, considere a transferência de um eSlM do primeiro utensílio eUICC para um dispositivo móvel. O dispositivo móvel emite uma solicitação para um eSlM com um desafio, e sua chave pública. O primeiro utensílio eUICC decriptografa um eSlM com sua própria chave privada e ge- 30 ra uma resposta de desafio apropriada. O eSlM é novamente criptografado com a chave pública do dispositivo móvel. O eSlM novamente criptografado é combinado com uma resposta do desafio e depois assinado. O dispositivo móvel verifica a resposta do desafio (que identifica o primeiro utensílio eUICC como uma fonte legítima) e, se bem-sucedida, decriptografa o eSlM para uso. Mesmo se um terceiro malicioso pudesse interceptar o eSlM crip- tografado, ele não seria capaz de usar ou falsificar o eSlM (desde que o e- 5 SIM esteja criptografado).

Finalmente, considere a transferência de um eSlM do primeiro dispositivo móvel para o segundo dispositivo móvel. O primeiro dispositivo móvel ativa uma solicitação para transferir o seu eSlM para o segundo dis- positivo móvel. Em um cenário, o usuário de qualquer um entre o primeiro ou 10 o segundo dispositivo móvel precisa aceitar manualmente a transferência. Se aceita, o segundo dispositivo móvel transmite um desafio para o primeiro dispositivo móvel. O primeiro dispositivo móvel decriptografa o seu eSlM criptografado armazenado com sua própria chave privada, então criptografa novamente o eSlM com a chave pública do segundo dispositivo móvel (a 15 chave pública do segundo dispositivo móvel está sempre disponível), inclu- indo a resposta apropriada. A combinação é assinada e transmitida. O se- gundo dispositivo móvel verifica a resposta do desafio (que identifica o pri- meiro dispositivo móvel como uma fonte legítima) e decriptografa o eSlM para uso.

Aparelho -

Vários aparelhos úteis em conjunto com os métodos acima des- critos são agora descritos em mais detalhes.

Utensílio eUICC -

A figura 4 ilustra uma modalidade exemplar de um utensílio 25 eUICC 400 de acordo com a presente invenção. O utensílio eUICC pode compreender uma entidade independente, ou ser incorporado com outras entidades de rede (por exemplo, um Serviço de Aprovisionamento de Servi- ço (SPS), etc.). Como mostrado, o utensílio eUICC 400 inclui geralmente uma interface de rede 402 para fazer interface com a rede de comunicações, 30 um processador 404 e um aparelho de armazenamento 408. A interface de rede é mostrada conectada à infraestrutura do MNO, de modo a proporcio- nar acesso a outros utensílios eUICC, e acesso direto ou indireto a um ou mais dispositivos móveis, embora outras configurações e funcionalidades possam ser substituídas.

Em uma configuração, o utensílio eUICC é um módulo de segu- rança de hardware (HSM). Um HSM inclui um ou mais elementos seguros 5 para gerenciar vários clientes de controle de acesso. Em algumas modalida- des, os clientes de controle de acesso são armazenados diretamente no HSM. Alternativamente, os clientes de controle de acesso são criptografados e armazenados em armazenamento externo. Em tais modalidades de arma- zenamento externo (por exemplo, remoto), a criptografia garante que os cli- 10 entes de controle de acesso sejam seguros, mesmo quando armazenados em meios fisicamente inseguros.

O HSM é configurado para possibilitar a transferência de clientes de controle de acesso para e de outro HSM, enquanto preserva a imparida- de e conservação dos clientes de controle de acesso. Além do mais, a trans- 15 ferência dos clientes de controle de acesso para outro HSM nessa modali- dade causa uma desativação e/ou exclusão dos clientes de controle de a- cesso localmente armazenados. Um HSM pode também ser configurado para autodestruir ou se desativar se falsificado.

Na modalidade ilustrada da figura 4, o utensílio eUICC 400 inclui 20 pelo menos um banco de dados do SIM 410 funcionando no processador 404. Embora ilustrado como uma aplicação única funcionando no utensílio eUICC, é verificado que a funcionalidade do banco de dados precedente pode compreender uma aplicação distribuída funcionando em uma pluralida- de de dispositivos em comunicação de dados entre si.

A aplicação do banco de dados do SIM processa solicitações

que incluem: (i) uma solicitação para armazenar um eSlM, (ii) uma solicita- ção para transferir um eSlM atualmente armazenado. A aplicação do banco de dados é também responsável por verificar as solicitações para garantir que a comunicação seja recebida de uma entidade autorizada a fazer tal solicitação (ver etapa 304, discutida acima).

Em uma modalidade, a aplicação do banco de dados do SIM é configurada para executar um protocolo de segurança de desafio e resposta. O protocolo de segurança de desafio/resposta é configurado para verificar solicitações feitas por um terceiro desconhecido, com base na geração a- propriada de desafios e/ou respostas. Alternadamente, em outra modalida- de, o elemento seguro pode verificar um certificado digital assinado por uma 5 autoridade de confiança.

Como mostrado, o aparelho de armazenamento 408 é adaptado para armazenar uma formação de clientes de controle de acesso. Em uma modalidade, um utensílio eUICC armazena uma formação de eSIMs. Em uma tal realização, cada eSlM inclui um pequeno sistema de arquivos que 10 inclui instruções legíveis por computador (o programa do eSlM) e dados as- sociados (por exemplo, chaves de cifra, chaves de integridade, etc.). Além disso, cada eSlM é adicionalmente criptografado com a chave pública do utensílio eUICC. Dessa forma, cada eUICC pode ser somente decriptografa- do pelo utensílio eUICC. Em algumas modalidades, cada eSlM criptografado 15 é ainda criptografado com um identificador único, desafio ou resposta do desafio. Em algumas modalidades, os componentes criptografados são ain- da armazenados como um Objeto Grande Binário (BLOB).

A aplicação do banco de dados do SIM é configurada para ge- renciar os eSIMs disponíveis. Como ilustrado na figura 4, o banco de dados 20 pode prover informação relacionada com o BLOB do eSlM particular, os dis- positivos autorizados para usar o eSlM, o estado atual e/ou a condição atual do eSlM ("disponível", "não disponível", "vencido", etc.). Informação adicio- nal pode ser mantida também. A aplicação do banco de dados é configurada para atualizar ou mudar a informação armazenada no banco de dados.

Quando outro dispositivo solicita um eSlM do utensílio eUICC

400, a aplicação do banco de dados recupera o estado atual do eSlM solici- tado. Essa informação pode ser usada para determinar se o eSlM solicitado pode ser fornecido. Essa conferência de validade pode ser executada em um serviço de ativação, no utensílio eUICC, ser compartilhada ou ocorrer em 30 ainda outras localizações; por exemplo, comparando o estado no serviço de ativação contra o último estado conhecido no utensílio eUICC. Similarmente, quando outro dispositivo transfere um eSlM para o utensílio eUICC 400, a aplicação do banco de dados é responsável por atualizar o estado atual do eSlM transferido.

Aparelho do usuário -

Com referência agora à figura 5, um aparelho exemplar do usuá- 5 rio 500 (por exemplo, um UE) de acordo com vários aspectos da presente invenção é ilustrado.

O aparelho do UE exemplar da figura 5 é um dispositivo sem fio com um subsistema de processador 502, tais como um processador de sinal digital, microprocessador, formação de portão programável no campo ou 10 pluralidade de componentes de processamento montados em um ou mais substratos. O subsistema de processamento pode também compreender uma memória cache interna. O subsistema de processamento fica em co- municação com um subsistema de memória 504 incluindo memória que po- de compreender, por exemplo, SRAM, flash e/ou componentes SDRAM. O 15 subsistema de memória pode implementar um ou mais de hardware tipo DMA, de modo a facilitar os acessos aos dados, como é bem conhecido na técnica. O subsistema de memória contém instruções executáveis por com- putador que são executáveis pelo subsistema do processador.

Em uma modalidade exemplar, o dispositivo pode compreender 20 de uma ou mais interfaces sem fio 506 adaptadas para conectar em uma ou mais redes sem fio. As múltiplas interfaces sem fio podem suportar tecnolo- gias de rádio diferentes, tais como GSM, CDMA, UMTS, LTE/LTE-A, Wi- MAX, WLAN, Bluetooth, etc. implementando os subsistemas apropriados de antena e modem.

O subsistema de interface do usuário 508 inclui qualquer número

de l/O bem conhecidos incluindo, sem limitação: uma base de teclas, tela de toque (por exemplo, interface de múltiplos toques), monitor de LCD, Iuz tra- seira, alto-falante e/ou microfone. Entretanto, é reconhecido que em certas aplicações, um ou mais desses componentes podem ser eliminados. Por 30 exemplo, modalidades de cliente do tipo PCMCIA podem carecer de uma interface do usuário (já que eles poderiam superpor a interface do usuário do dispositivo hospedeiro, ao qual eles são física e/ou eletricamente acopla- dos).

Na modalidade ilustrada, o dispositivo inclui um elemento seguro 510 que contém e opera a aplicação do eUICC. O eUICC é capaz de arma- zenar e acessar uma pluralidade de clientes de controle de acesso para se- 5 rem usados para autenticação com um operador de rede. O elemento segu- ro inclui, nessa modalidade, um processador seguro executando software armazenado em uma mídia segura. A mídia segura é inacessível para todos os outros componentes (diferentes do processador seguro). Além do mais, o elemento seguro pode ser ainda endurecido para impedir a falsificação (por 10 exemplo, envolvido em resina), como previamente descrito.

O elemento seguro 510 é capaz de receber e armazenar um ou mais clientes de controle de acesso. Em uma modalidade, o elemento segu- ro armazena uma formação ou pluralidade de eSIMs associados com um usuário (por exemplo, um para trabalho, um para pessoal, vários para aces- 15 so em viagem, etc.), e/ou de acordo com outro esquema lógico ou relação (por exemplo, um para cada um de múltiplos membros de uma família ou entidade comercial, um para cada um de uso pessoal e profissional para os membros da família e assim por diante). Cada eSlM inclui um pequeno sis- tema de arquivos incluindo instruções legíveis por computador (o programa 20 do eSlM) e dados associados (por exemplo, chaves de cifra, chaves de inte- gridade, etc.).

O elemento seguro é ainda adaptado para possibilitar a transfe- rência de eSIMs para e/ou do dispositivo móvel. Em uma modalidade exem- plar, o dispositivo móvel provê uma confirmação baseada na GUI para iniciar a transferência de um eSlM.

Além do mais, várias realizações da modalidade exemplar inclu- em instruções que quando executadas, disparam um protocolo de segurança de desafio/resposta. O protocolo de segurança de resposta do desafio é con- figurado para verificar solicitações feitas por um terceiro desconhecido, com 30 base na geração apropriada de desafios e/ou respostas. Alternadamente, em uma modalidade exemplar, o elemento seguro pode verificar um certifi- cado digital assinado por uma autoridade de confiança. Além do mais, em uma modalidade, o elemento seguro mantém uma listagem ou manifesto de clientes de controle de acesso armazenados. O manifesto pode incluir informação quanto à condição atual dos clientes de controle de acesso armazenados; tal informação pode incluir, por exemplo, 5 disponibilidade, integralidade, validade e/ou erros experimentados anterio- res. O manifesto pode ser ainda vinculado ou acoplado à interface do usuá- rio, de modo a possibilitar a seleção pelo usuário de um cliente de controle de acesso disponível.

Em uma modalidade exemplar, o elemento seguro tem chaves 10 criptográficas associadas do dispositivo. Essas chaves do dispositivo são usadas para assegurar trocas de clientes de controle de acesso. Em uma tal variação, as chaves criptográficas são um par assimétrico de chave públi- ca/privada. A chave pública pode ser livremente distribuída sem comprome- ter a integridade das chaves privadas. Por exemplo, o dispositivo pode ser 15 atribuído com (ou internamente gerar) uma chave pública/privada de RSA; a chave pública fica disponível para comunicação pós-desenvolvimento.

Será reconhecido que embora certos aspectos da invenção se- jam descritos em termos de uma seqüência específica de etapas de um mé- todo, essas descrições são somente ilustrativas dos métodos mais abran- 20 gentes da invenção, e podem ser modificadas como exigido pela aplicação particular. Certas etapas podem ser desnecessárias ou opcionais sob de- terminadas circunstâncias. Adicionalmente, certas etapas ou funcionalidade podem ser adicionadas às modalidades reveladas ou à ordem de desempe- nho de duas ou mais etapas trocada. Todas as tais variações são conside- 25 radas para serem abrangidas dentro da invenção revelada e reivindicada aqui.

Embora a descrição detalhada acima tenha mostrado, descrito e evidenciado novas características da invenção quando aplicadas em várias modalidades, será entendido que várias omissões, substituições e mudan- 30 ças na forma e detalhes do dispositivo ou processo ilustrado podem ser fei- tas por aqueles versados na técnica sem se afastar da invenção. A descri- ção precedente é do melhor modo atualmente considerado de execução da invenção. Essa descrição não é de forma alguma planejada para ser limita- dora, mas de preferência deve ser adotada como ilustrativa dos princípios gerais da invenção. O escopo da invenção deve ser determinado com refe- rência às reivindicações.

Claims (26)

1. Aparelho para armazenar um ou mais elementos de dados de acesso, que compreende: um elemento seguro adaptado para armazenar uma pluralidade de elementos de dados de acesso do usuário, cada elemento de dados de acesso do usuário criptografado para o elemento seguro; um processador; e um dispositivo de armazenamento em comunicação de dados com o processador, o dispositivo de armazenamento compreendendo instru- ções executáveis pelo computador que são configuradas para, quando exe- cutadas pelo processador: processar uma solicitação por um ou mais elementos de dados de acesso de um dispositivo par a fim de verificar o dispositivo par; decriptografar o um ou mais elementos de dados de acesso soli- citados; criptografar novamente o um ou mais elementos de dados de acesso decriptografados para o dispositivo par; e transferir o um ou mais elementos de dados novamente cripto- grafados para o dispositivo par verificado, a transferência causando a remo- ção do um ou mais elementos de dados de acesso do elemento seguro.

2. Aparelho, de acordo com a reivindicação 1, na qual cada um da pluralidade de elementos de dados de acesso do usuário está associado com uma rede diferente correspondente.

3. Aparelho, de acordo com a reivindicação 1, na qual cada um da pluralidade de elementos de dados de acesso do usuário está associado com um usuário diferente correspondente.

4. Aparelho, de acordo com a reivindicação 1, na qual cada um da pluralidade de elementos de dados de acesso do usuário está associado com um caso de uso diferente correspondente para um mesmo usuário.

5. Aparelho, de acordo com a reivindicação 1, na qual o elemen- to de dados de acesso do usuário compreende um Módulo de Identidade do Assinante eletrônico (eSlM).

6. Aparelho, de acordo com a reivindicação 1, na qual a verifica- ção compreende conferir um certificado associado com o dispositivo par, e gerar uma resposta de desafio.

7. Aparelho, de acordo com a reivindicação 1, na qual as instru- ções executáveis pelo computador compreendem adicionalmente instruções que são configuradas para, quando executadas pelo processador, negociar um protocolo de transferência.

8. Aparelho, de acordo com a reivindicação 7, na qual a nova criptografia do um ou mais elementos de dados de acesso decriptografados é baseada pelo menos em parte no protocolo de transferência.

9. Aparelho, de acordo com a reivindicação 7, na qual o protoco- lo de transferência compreende um ou mais elementos de sinais de estabe- lecimento de comunicação.

10. Aparelho, de acordo com a reivindicação 7, na qual o proto- colo de transferência negociado compreende a identificação de um protocolo de transferência suportado pelo aparelho e o dispositivo par.

11. Aparelho, de acordo com a reivindicação 1, na qual o apare- lho compreende um Módulo de Segurança de Hardware (HSM).

12. Aparelho, de acordo com a reivindicação 1, no qual o apare- Iho é personificado dentro de um telefone móvel.

13. Aparelho, de acordo com a reivindicação 1, na qual o apare- lho é personificado dentro de um fator de forma de cartão físico.

14. Aparelho para armazenar um ou mais elementos de dados de acesso, que compreende: um elemento seguro adaptado para armazenar uma pluralidade de elementos de dados de acesso do usuário, cada elemento de dados de acesso do usuário criptografado para o elemento seguro; um processador; e um dispositivo de armazenamento em comunicação de dados com o processador, o dispositivo de armazenamento compreendendo instru- ções executáveis pelo computador que são configuradas para, quando exe- cutadas pelo processador: solicitar um ou mais elementos de dados de acesso de um dis- positivo par verificado; receber o um ou mais elementos de dados de acesso solicitados do dispositivo par verificado; verificar se o um ou mais elementos de dados de acesso solici- tados são criptografados para o elemento seguro; armazenar o um ou mais elementos de dados de acesso cripto- grafados dentro do elemento seguro; e decriptografar o um ou mais elementos de dados de acesso crip- tografados durante o protocolo de autenticação.

15. Aparelho, de acordo com a reivindicação 14, na qual o ele- mento de dados de acesso do usuário compreende um Módulo de Identida- de do Assinante eletrônico (eSlM).

16. Aparelho, de acordo com a reivindicação 14, na qual o apa- relho é personificado dentro de um telefone móvel.

17. Aparelho, de acordo com a reivindicação 16, na qual o apa- relho compreende um fator de forma de cartão físico configurado para uso dentro do telefone móvel.

18. Aparelho, de acordo com a reivindicação 14, na qual a verifi- cação compreende conferir um certificado digital emitido por uma autoridade de certificação de confiança.

19. Aparelho, de acordo com a reivindicação 14, na qual a verifi- cação compreende a conclusão de uma troca criptográfica de desafio e res- posta.

20. Aparelho, de acordo com a reivindicação 14, na qual o dis- positivo par compreende um de (i) um Serviço de Aprovisionamento SIM (SPS), (ii) um utensílio eUICC ou (iii) um dispositivo móvel.

21. Aparelho, de acordo com a 14, na qual o dispositivo par compreende um computador de mesa em comunicação operativa com uma memória de aplicações móveis.

22. Método para transferir um ou mais elementos de dados de acesso, o um ou mais elementos de dados de acesso tendo um identificador único associado com eles, que compreende: estar de acordo com um protocolo de transferência entre um dispositivo e um dispositivo par; receber o um ou mais elementos dos dados de acesso do dispo- sitivo par seguro; verificar o um ou mais elementos de dados de acesso transferi- dos, o um ou mais elementos de dados de acesso e identificador único sen- do criptografados para o dispositivo; e armazenar o um ou mais elementos de dados de acesso transfe- ridos.

23. Método, de acordo com a reivindicação 22, no qual o ele- mento de dados de acesso do usuário compreende um Módulo de Identida- de do Assinante eletrônico (eSlM).

24. Método, de acordo com a reivindicação 22, no qual o identifi- cador único do um ou mais elementos de dados de acesso transferidos é determinado pelo dispositivo.

25. Método, de acordo com a reivindicação 22, no qual o identifi- cador único do um ou mais elementos de dados de acesso transferidos é fornecido para o dispositivo par.

26. Método, de acordo com a reivindicação 22, adicionalmente compreendendo notificar o dispositivo par da recepção bem-sucedida do um ou mais elementos de dados de acesso.