BRPI0807361A2 - Dispositivo pessoal de autenticação, e método para implementar uma aplicação de cartão-java em um dipositivo pessoal de autenticação. - Google Patents

Description

I TOKEN PESSOAL ARMAZENANDO UM CÓDIGO DE APLICATIVO JAVACARD RESIDENTE NUMA ÁREA DA MEMÓRIA DO TOKEN PESSOAL, MÉTODO PARA IMPLEMENTAR UM APLICATIVO JAVACARD EM UM TOKEN PESSOAL, E MÉTODO PARA IMPLEMENTAR UM APLICATIVO JAVACARD 5 EM UM TOKEN PESSOAL, DE ACORDO COM A REIVINDICAÇÃO PRECEDENTE

A invenção diz respeito a tokens pessoais de segurança, quando hospedam aplicativos Javacard para fornecer páginas em HTML a um determinado dispositivo. Tais tokens pessoais são geralmente conhecidos como tokens pessoais incluindo um servidor HTML ou web.

Tokens pessoais são usados para autenticar um usuário, quando tal usuário acessa um equipamento de recursos limitados ou privados, como uma rede de 15 telecomunicação móvel, uma instalação ou rede bancária, um servidor remoto armazenando dados secretos, ou mesmo uma área protegida com acesso físico limitado à mesma.

0 dispositivo mais conhecido desse tipo é o cartão IC, tal como, p. ex., um cartão SIM (Módulo de 20 Identificação do Assinante) ou um cartão de crédito, mas ele pode ser também uma chave USB, um cartão de memória em massa, ou qualquer tipo de token contendo algumas credenciais necessárias.

Tais tokens são tipicamente compatíveis com a norma internacional ISO 7816. O dispositivo imaginado é tipicamente o terminal móvel numa rede de telefonia móvel, mas pode ser também um PC hospedeiro ou um terminal remoto numa rede IT, quer na internet, quer numa rede interna de companhia.

Javacard é um sistema de linguagem e programação,

que é derivado do Java, isto é, com funcionalidades simplificadas devido às reduzidas capacidades de cartões inteligentes, mas retendo os principais aspectos de Java, tal como descarregamento de arquivo .cap, inicialização, 10 registro, uso de Ids de aplicativo, e, mais importante, um grupo selecionado das instruções originais da linguagem Java, que fazem com que o Javacard mantenha a natureza orientada para objetos do Java original. Cartões inteligentes ou adaptadores USB ativados por Javacard são 15 bem conhecidos.

Muitas vezes, o Javacard é usado para fornecer dados em HTML a um dispositivo hospedeiro, cujo dispositivo hospedeiro roda um motor HTML, cujo motor lê esses dados em HTML fornecidos e constrói uma página em HTML a partir 20 desses dados fornecidos. Os dados em HTML fornecidos são dados suficientes para descrever o conteúdo a ser encontrado na página em HTML, isto é, objetos estáticos, objetos dinâmicos, e um modelo para organizar os objetos estáticos e dinâmicos na página.

Aplicativos Javacard são carregados em tokens de

segurança, quer pelo ar, quer por meios com fio, isto é, na fábrica durante a customização do token, ou mesmo em um ponto de vendas por meio de um computador local com algumas conexões dedicadas e um driver para esse fim.

Aplicativos Javacard são difíceis de serem 5 atualizados. Alguns dados de Javacard, que já estão presentes no token, são muitas vezes impossíveis de serem modificados, o que significa que todo aplicativo deve ser baixado numa nova versão que englobe os dados modificados. Isso também significa que o token precisa ser retornado à 10 fábrica, ou a um ponto de vendas, ou que um novo descarregamento do código de aplicativo completo, isto é, do arquivo . cap, precisa ser realizado pelo ar, o que é demorado e enfadonho para o operador, e demanda uma difícil gestão de memória no token.

Isso parece ser particularmente verdadeiro para

códigos de aplicativos, que são dedicados a fornecer dados de página em HTML, quando parece ser necessário emendar a página em HTML.

Por exemplo, a troca de um objeto na página em HTML, ou emenda do modelo da página em HTML para enfatizar um objeto específico ao invés de outro, requer que o aplicativo Javacard seja novamente baixado no cartão e interpretado pelo cartão na sua versão modificada.

0 objetivo da invenção é resolver esse problema, isto é, propor uma implementação de um aplicativo Javacard num token pessoal, que facilite o processo de emendar páginas em HTML a serem exibidas, quando um token pessoal for inferido.

Tal objetivo é alcançado pela invenção através das características, conforme descritas nas reivindicações 5 apensas.

Outros aspectos, objetivos e vantagens da invenção surgirão através da descrição a seguir, que é feita com referência às figuras, dentre as quais:

- a fig. 1 representa um cartão SIM incorporando um aplicativo Javacard, de acordo com a técnica anterior,

- a fig. 2 representa um cartão SIM incorporando um aplicativo Javacard, de acordo com uma modalidade da presente invenção,

- a fig. 3 é um diagrama representando uma série de tarefas, conforme executadas pelo cartão SIM, de acordo com

a mesma modalidade da invenção.

Conforme representado na fig. 1, para hospedar um aplicativo Javacard, tal como um aplicativo de jogo, e- purse (carteira eletrônica) ou catálogo telefônico, um 20 cartão SIM 10, de acordo com a técnica anterior, é primeiro descarregado com um arquivo .cap 11, isto é, um conjunto de instruções Javacard, que foram previamente compiladas e convertidas em um servidor remoto. Tal arquivo .cap 11 ainda precisa ser interpretado, a fim de ser tornado 25 executável, isto é, o arquivo .cap precisa ser inicializado por uma Máquina Virtual Javacard, cuja Máquina Virtual Javacard se achava presente no cartão antes do descarregamento. 0 arquivo .cap então se torna, o que é chamado de, um miniaplicativo Javacard, como representado pela referência 12 na fig. 1.

5 Esse miniaplicativo Javacard 12 é feito de uma

série de instruções, que são agora acopladas a parâmetros, raças à etapa de iniciação realizada, cujos parâmetros também foram descarregados no arquivo .cap, mas não inicialmente acoplados às instruções correspondentes.

As instruções do miniaplicativo Javacard 12

descrevem dados em HTML a serem transmitidos ao terminal móvel hospedando o cartão SIM, após uma página em HTML ser solicitada por um usuário final. Tal página em HTML pode ser uma tela de proteção de boas vindas, projetada para ser 15 exibida, quando o usuário final ligar a sua unidade móvel, ou um menu permitindo que o usuário final escolha entre diversas funcionalidades implementadas no cartão SIM 10.

Esses dados em HTML no miniaplicativo Javacard compreendem dados de modelo 13, que descrevem o formato 20 global da página em HTML, bem como os locais onde alguns objetos devem estar na pagina, isto é, cada local reservado para um objeto estático ou para um objeto dinâmico na página.

O miniaplicativo Javacard também compreende instruções para construir objetos dinâmicos da página, que podem resultar tipicamente de um cálculo, ou de um estado particular do miniaplicativo Javacard, no momento em que a página é solicitada pelo usuário final.

0 miniaplicativo Javacard também compreende dados de objetos estáticos, isto é, dados que descrevem objetos, que não são projetados para mudança, nem ser adaptados durante a execução do miniaplicativo Javacard.

Esses objetos estáticos possuem as referências 14 na fig. 1.

Um cartão SIM rodando um aplicativo Javacard, de acordo com uma modalidade da invenção, será agora descrito com referência à fig. 2.

O cartão SIM da fig. 2 hospeda um miniaplicativo Javacard inicializado e registrado 12. O arquivo .cap original 11 é representado na fig. 2, mas não existe mais em termos operacionais no cartão 10, após o miniaplicativo Javacard ser inicializado.

O miniaplicativo Javacard 12 é salvo numa parte da memória do cartão SIM, que é normalmente dedicado aos miniaplicativos Javacard. Essa parte dedicada é localizada 20 dentro da porção não-volátil da memória do cartão, normalmente implementada como memória EEPROM (Memória Programável Somente de Leitura Eletricamente Apagável).

No lado direito da fig. 2, outra parte física da memória não-volátil é representada, que hospeda uma série de arquivos contíguos 17. Cada um desses arquivos está no formato TLV, isto é, é constituído de três partes. Uma primeira parte de cada arquivo TLV é uma parte de Etiqueta, a parte seguinte é uma parte de Comprimento, que inclui um valor de Comprimento, e a última parte do arquivo TLV é uma parte de Valor, que compreende um valor, cujo volume 5 determina o comprimento, conforme colocado na parte de Comprimento precedente do arquivo TLV.

Os arquivos TLV dessa parte da memória são normalmente usados para armazenar parâmetros de comunicação, conforme listados e requeridos nas normas de telecomunicação.

Além desse objetivo, esses arquivos TLV são aqui usados para armazenar dados, que são destinados ao miniaplicativo Javacard 12 e necessários à construção dos dados de página em HTML. O miniaplicativo Javacard 12 é 15 programado para buscar esses dados em HTML nos arquivos TLV durante a evolução da execução do miniaplicativo 12.

Aqui, os dados em HTML, assim armazenados nos arquivos TLV, são de dois tipos. Alguns arquivos TLV armazenam dados de modelos HTML, isto é, dados em HTML que descrevem o formato e a construção global da página.

Outros arquivos TLV armazenam dados, que descrevem objetos estáticos em HTML.

Um arquivo TLV descreve um modelo, diversos modelos sendo atualmente descritos em diversos arquivos TLV respectivos no presente caso. Um arquivo TLV também descreve um objeto estático, diversos objetos estáticos sendo atualmente descritos em diversos arquivos TLV respectivos no presente caso.

Em cada arquivo TLV de objeto estático, cada porção de Valor do arquivo é uma cadeia em HTML, que descreve c 5 conteúdo do objeto estático propriamente dito, cada porção de Comprimento armazena o comprimento real dessa cadeia em HTML, e cada porção de Etiqueta armazena um identificador do objeto estático propriamente dito, cujo identificador é usado para recuperar o objeto estático correto, que é 10 buscado.

Uma cadeia em Javacard é um conjunto de caracteres alfanuméricos compreendidos entre "<" e que descreve

um objeto visual, tal como um objeto estático a ser colocado numa pagina HTML.

Diferentes formatos de arquivos podem ser

considerados para a armazenagem dos modelos HTML e os objetos estáticos HTML, desde formatos binários até BER- TLV. BER-TLV é o formato preferido. Um formato de leve peso padrão é geralmente mais vantajoso.

A fim de recuperar os dados de modelo e os dados

dos objetos estáticos, o cartão 10 hospeda e roda uma API (interface de programação de aplicativo) identificada comor 18. A API 18 lê os dados do modelo, os analisa, e transmite os dados para o terminal móvel, ou de volta ao 25 miniaplicativo Javacard, dependendo do processamento que precisa ser feito nos dados considerados. Por exemplo, quando o modelo compreender dados estáticos e também identificar a necessidade de dados dinâmicos por meio de identificadores, os dados estáticos são transferidos pela API 18 diretamente para o terminal 5 móvel, e os identificadores de dados dinâmicos são transmitidos ao aplicativo 12 para posterior processamento desses dados dinâmicos.

Na fig. 3, as etapas identificadas como AaE são representadas, que correspondem às tarefas sucessivas executadas pelo terminal móvel, o miniaplicativo Javacard

12, a API 18. A fig. 3 também representa os dados recuperados pelos arquivos TLV 14 no processo de coletar os dados de página em HTML.

Como uma primeira etapa A, o terminal móvel faz uma solicitação em HTTP ao aplicativo 12. 0 código do aplicativo 12 inclui uma parte 12a, que é dedicada ao processamento da solicitação em HTTP. Essa parte processadora da solicitação em HTTP 12a evoca, na etapa B, a API 18. A API 18 então lê, na etapa C, o arquivo de modelo no arquivo de dados TLV correspondente, cujo modelo compreende dados estáticos incluindo cadeias estáticas, algumas delas descrevendo respectivos objetos estáticos, mas que podem também identificar dados estáticos em outros arquivos TLV, cujos dados estáticos podem descrever objetos estáticos.

A API de modelo 18, ou mecanismo de modelagem, então analisa o arquivo de modelo nos dados estáticos, na etapa D, e nos identificadores dinâmicos, que identificam objetos dinâmicos a serem criados. A API passa diretamentre os dados estáticos para o terminal móvel, e transfere os 5 identificadores dinâmicos ao aplicativo 12.

O aplicativo 12 compreende um módulo callback de modelo 12b, que gera os objetos dinâmicos identificados, quando evocado pela API de modelo 18. O aplicativo 12 implementa, assim, uma interface de callback. Para evocar o 10 módulo callback 12b, a API de modelo 18 transfere os identificadores de dados dinâmicos, bem como o objeto de solicitação em HTTP, ao módulo callback de modelo 12b, na etapa E.

Na etapa F, o módulo callback de modelo 12b gera os 15 dados dinâmicos identificados, baseado nos identificadores de dados dinâmicos e no objeto de solicitação em HTTP, e com base em qualquer fonte de dados específicos de aplicativos adicionais. Em outras palavras, a lógica de aplicativos usa as informações recebidas pela API, bem como 20 suas próprias fontes, a fim de gerar os dados dinâmicos. Os dados dinâmicos são então automaticamente adicionados à página em HTML emitida.

A invenção foi descrita, no caso dos objetos estáticos e modelos serem armazenados em locais, que não sejam incorporados ao código do aplicativo.

No escopo da invenção, o código do aplicativo Javacard pode incluir os dados de objetos estáticos neles incorporado, somente os dados de modelo sendo armazenados num local separado. Ao contrário, e ainda no escopo da invenção, um aplicativo Javacard pode buscar dados num 5 local separado para recuperar dados de objetos estáticos, mas englobar os dados de modelo dentro do código do aplicativo.

Nessa modalidade alternativa, os objetos estáticos usados pelo aplicativo são armazenados em um ou diversos 10 arquivos separados dedicados a essas cadeias, e cada cadeia é identificada por um identificador, p. ex. , um valor escalar. Uma API de Javacard similar à API 18 acima descrita permite que o miniaplicativo 12 recupere os dados de objetos estáticos no arquivo separado, na forma de uma 15 matriz de bytes constituindo a cadeia, pelo uso do identificador dessa cadeia. A API abre o arquivo contendo tal recurso de cadeia estática, e obtém uma matriz de bytes de identificador da cadeia, conforme extraída do aplicativo.

Nessas modalidades distintas, as vantagens são as

seguintes:

Construção de páginas em HTML dinâmicas, demandando previamente intensas manipulações e concatenações de cadeia. A maioria das cadeias usadas em páginas dinâmicas da web é na verdade estática. A única possibilidade para descrever uma cadeia era uma matriz de bytes no código de aplicativo. Partes estáticas das páginas em HTML tinham que ser descritas em matrizes de bytes estáticas e ser codificadas no aplicativo Javacard. Por exemplo, cadeias estáticas usadas para construir páginas em HTML eram 5 codificadas no código de fonte do aplicativo, elas não podiam ser facilmente atualizadas para fins de customização/ internacionalização. A customização das cadeias estáticas é também útil, p. ex., para reparar um defeito.

Além de reinstalar um novo arquivo ".cap" com

constantes atualizadas, a internacionalização era também alcançada por codificação das diferentes cadeias de linguagem dentro do código do miniaplicativo, ou pelo gerenciamento das diversas versões do mesmo aplicativo no token.

0 Javacard também não oferecia qualquer modo eficiente para concatenar cadeias estáticas para construir páginas complexas em HTML. Assim, a lógica do aplicativo estava encarregada de concatenar as matrizes de bytes de 20 cadeias com elementos dinâmicos, a fim de construir o conteúdo dinâmico. Devido à falta de suporte para concatenação da matriz de bytes em Javacard, e não compreendendo nenhum objeto de cadeia em separado, conforme aqui proposto, a construção de uma página dinâmica em HTML 25 demandava muitas operações manuais de memória intermediária, sendo assim muito lenta. Em termos de tamanho de código e desempenho, a API descrita, que busca recursos de cadeia, permite limitar a manipulação da matriz de bytes em aplicativos Javacard. Além disso, identificadores escalares constantes são 5 usados, ao invés das cadeias de matrizes de bytes estáticas no aplicativo, o que reduz o tamanho do código e aumenta o desempenho.

As cadeias incluídas nos arquivos de recursos separados podem ser customizadas, de acordo com asa demandas do cliente. Por exemplo, uma cadeia contendo o nome do operador pode ser facilmente alterada, sem emendar o código do aplicativo.

Arquivos de cadeias estáticas podem ser atualizados a distância através das técnicas clássicas do gerenciamento de arquivos a distância, a fim de reparar defeitos em potencial, ou atualizar ligeiramente o aplicativo.

Diversos arquivos com recursos de

internacionalização podem existir no cartão, um para cada linguagem nacional. 0 aplicativo Javacard pode escolher 20 aquele adaptado às preferências de linguagem do usuário atual. Novas linguagens podem ser também facilmente desenvolvidas após a emissão, como atualizações baixadas de objetos estáticos em arquivos correspondentes.

Devido à armazenagem do modelo num local de arquivo separado, um modelo pode ser internamente processado pela API, usando serviços nativos. Isso também reduz a necessidade da manipulação de memória intermediária no Javacard e melhora o desempenho.

Modelos podem ser facilmente customizados, com base nas demandas do cliente, sem alterar o código do aplicativo.

Modelos podem ser atualizados a distância, através das técnicas clássicas do gerenciamento de arquivos a distância, a fim de reparar defeitos em potencial ou atualizar ligeiramente a aparência do aplicativo.

Diversos modelos podem existir no cartão, uma para

cada linguagem nacional. O aplicativo Javacard pode escolher aquele adaptado às preferências de linguagem do usuário atual. Novas linguagens podem ser também facilmente desenvolvidas após a emissão, como modelos de nova linguagem baixada num arquivo correspondente.

Claims (13)

1. TOKEN PESSOAL ARMAZENANDO UM CÓDIGO DE APLICATIVO JAVACARD RESIDENTE NUMA ÁREA DA MEMÓRIA DO TOKEN PESSOAL, caracterizado pelo fato do token pessoal ser capaz de rodar esse aplicativo javacard (12), a fim de fornecer dados de página em HTML a um dispositivo externo, para o dispositivo externo exibir uma página em HTML com base nesses dados de página em HTML fornecidos, dito token pessoal ainda armazenando dados a serem usados como uma parte construtora da página em HTML, e pelo fato dos dados, a serem usados como uma parte contribuidora da página em HTML, estarem em pelo menos um arquivo (17), que é separado da área de memória, sobre a qual o código de aplicativo Javacard está residindo, e do token pessoal ser programado para abrir pelo menos um arquivo armazenando a parte contribuidora da página em HTML, quando tais dados forem solicitados para fornecimento dos ditos dados de página em HTML ao dito dispositivo externo.

2. Token pessoal, de acordo com a reivindicação 1, caracterizado pelo fato dele compreender uma API, que abre e lê o conteúdo de pelo menos um arquivo separado (17) armazenando a parte contribuidora, em resposta à solicitação dessa abertura para a dita API por parte do aplicativo Javacard.

3. Token pessoal, de acordo com a reivindicação 1, caracterizado pelo fato da parte contribuidora da página em HTML ser constituída de pelo menos um objeto estático (17) a ser introduzido na página em HTML a ser processada.

4. Token pessoal, de acordo com a reivindicação 1, caracterizado pelo fato da parte contribuidora (17) da página em HTML ser constituída de um modelo de página em HTML.

5. Token pessoal, de acordo com a reivindicação 1, caracterizado pelo fato da parte contribuidora (17) da página em HTML compreender um modelo da página em HTML e pelo menos um objeto estático a serem introduzidos na página em HTML.

6. Token pessoal, de acordo com as reivindicações 2 e 4, caracterizado pelo fato do aplicativo compreender um módulo callback (12b) para fornecer um objeto dinâmico da página em HTML, e da API ser programada para iniciar o módulo callback, toda vez que a API identificar que um objeto dinâmico é solicitado no modelo de leitura em HTML.

7. Token pessoal, de acordo com as reivindicações 2, 5 e 6 combinadas, caracterizado pelo fato de pelo menos um arquivo separado compreender pelo menos um identificador para um objeto dinâmico demandado da página em HTML, e da API analisar pelo menos um arquivo separado, que armazena a modelo dentro de pelo menos um objeto estático e pelo menos um identificador de objeto dinâmico, a API transmitindo pelo menos um objeto estático ao dispositivo de processamento externo, e transmitindo pelo menos um identificador de objeto dinâmico ao módulo callback do aplicativo.

8. Token pessoal, de acordo com a reivindicação 7, caracterizado pelo fato da API transmitir pelo menos um objeto estático ao dispositivo de processamento externo, sem transmiti-lo ao aplicativo.

9. Token pessoal, de acordo com a reivindicação 1, caracterizado pelo fato de pelo menos um arquivo armazenando a parte contribuidora ser um arquivo do tipo de Valor de Comprimento da Etiqueta - TLV.

10. Token pessoal, de acordo com a reivindicação 4, caracterizado pelo fato de pelo menos um arquivo compreender diversos modelos, e do código de aplicativo compreender um identificador para o correto modelo a ser usado como uma parte contribuidora da página em HTML.

11. MÉTODO PARA IMPLEMENTAR UM APLICATIVO JAVACARD EM UM TOKEN PESSOAL, caracterizado pelo fato do aplicativo Javacard ser projetado para fornecer dados de página em HTML a um dispositivo de processamento externo, método de implementação compreendendo o descarregamento de um código de aplicativo (12) e dados a serem usados como uma parte contribuidora da página em HTML, e pelo fato do método compreender as etapas, que consistem de: a) descarga de um código do aplicativo Javacard sobre uma área da memória do token pessoal, b) descarga dos dados a serem usados como uma parte contribuidora da página em HTML para dentro de pelo menos um arquivo (17), que é separado da área de memória, sobre a qual o código de aplicativo javacard é baixado, c) programação do token pessoal para abertura de pelo menos um arquivo armazenando a parte contribuidora da página em HTML, quando tal parte contribuidora for solicitada pelo aplicativo.

12. MÉTODO PARA IMPLEMENTAR UM APLICATIVO JAVACARD EM UM TOKEN PESSOAL, DE ACORDO COM A REIVINDICAÇÃO PRECEDENTE, caracterizado pelo fato do código de aplicativo Javacard (12) e da parte contribuidora (17) da página em HTML serem baixados para dentro do token pessoal em diferentes momentos.

13. MÉTODO PARA IMPLEMENTAR UM APLICATIVO JAVACARD EM UM TOKEN PESSOAL, de acordo com a reivindicação 11, caracterizado pelo fato dele compreender a etapa, que consiste da atualização da parte contribuidora (17) da página em HTML, por descarregamento de uma parte contribuidora atualizada da página em HTML, sem baixar qualquer código de aplicativo javacard atualizado (12), conforme já armazenado na dita área de memória.