BR112012019384B1 - método para executar uma aplicação e portador de dados portátil - Google Patents

Abstract

MÉTODO PARA EXECUTAR UMA APLICAÇÃO E PORTADOR DE DADOS PORTÁTIL. A presente invenção descreve um método para executar uma aplicação (A) que compreende código interpretável ou nativo executável e chama funções de um sistema operacional (BS), em que o sistema operacional (BS) transmite um resultado de uma respectiva chamada de função (f1) à aplicação (A). O método, de acordo com a invenção, é caracterizado pelo fato de que a aplicação (A) verifica o resultado de uma respectiva chamada de função para uma falsificação, de modo a detectar um ataque.

Description

[0001] A presente invenção refere-se a um método para executar uma aplicação compreendendo código interpretável ou nativo executável e chama funções de um sistema operacional em que o sistema operacional transmite um resultado de uma respectiva chamada de função à aplicação. Além disso, a invenção refere-se a um portador de dados portátil, em particular a um cartão de chip ou módulo de segurança.

[0002] No campo de cartões de chip, os chamados ataques de erros induzidos são conhecidos, que manipulam a sequência do programa ou o conteúdo da memória de uma memória de um cartão de chip. Por exemplo, em um ataque pode ser tentado, com o auxílio da análise de falha diferencial (DFA), espiar chaves secretas intercalando seletivamente cálculos errôneos. Com o auxílio de um ataque leve tenta-se mudar o status de segurança do cartão de chip de forma orientada para ler os dados secretos que por outro lado seriam legíveis somente na presença de uma autenticação. Contra tais ataques, vários mecanismos de defesa foram desenvolvidos, que são baseados em ambas as medidas de software e hardware. Aqui, a detecção de ataque é regularmente efetuada por um sistema operacional do cartão de chip ou pelas funções do sistema operacional que podem ser chamadas de aplicações no cartão de chip.

[0003] Diferentes medidas defensivas contra ataque de falhas são descritas em The Sorcerer’s Apprentice Guide to Fault Attacks de Hagai Bar-El et al., de 2004.

[0004] No WO 2009/138892, os conteúdos de uma primeira memória de endereço são lidos novamente após leitura de uma segunda memória de endereço a fim de detectar um possível ataque.

[0005] Um sistema operacional de cartão inteligente que fornece uma aplicação com uma interface para acessar funções do sistema operacional, é conhecido de Smart Card Manual, W. Rankl, 2008.

[0006] Em um portador de dados portátil com uma aplicação chamando funções de um sistema operacional e contendo um código interpretável ou nativo executável, o resultado da chamada de função pode ser falsificado por um ataque, por exemplo, por um ataque leve, sem que seja possível para a aplicação detectar a falsificação.

[0007] É então, o objetivo da presente invenção especificar um método com o qual a segurança, ao executar uma aplicação, possa ser ainda melhorada. É ainda o objetivo da invenção especificar um portador de dados portátil que possui segurança melhorada ao executar uma aplicação.

[0008] Esses objetos são alcançados através de um método de acordo com as descrições da reivindicação 1 da patente, assim como um portador de dados portátil de acordo com as descrições da reivindicação 11 da patente. Modalidades vantajosas resultam a partir das reivindicações dependentes.

[0009] A invenção cria um método para a execução de uma aplicação que compreende código interpretável ou nativo executável e chama funções de um sistema operacional, pelo qual o sistema operacional transmite um resultado de uma respectiva chamada de função para a aplicação. De acordo com a invenção, a aplicação verifica o resultado de uma respectiva chamada de função para uma falsificação, de modo a detectar um ataque. Procedendo de acordo com a invenção, a segurança contra manipulações pode ser aumentada. Diferentemente do estado da técnica, uma verificação para manipulação não é efetuada pelo sistema operacional, mas pela própria aplicação, a qual chama funções do sistema de operação.

[0010] Em particular, um aprimoramento da segurança é criado em tais aplicações em que o sistema operacional fornece para a aplicação, somente uma variável Booleana como resultado. Esse é o caso, por exemplo, da verificação das assinaturas. Aqui, todo valor do resultado que seja diferente de zero é interpretado como verdadeiro pela aplicação. A probabilidade de um ataque bem sucedido no valor do resultado transmitido pelo sistema operacional à aplicação é aqui fortemente aumentada, uma vez que cada resultado falsificado leva à verificação bem sucedida de uma assinatura inválida. De acordo com a invenção, a verificação dos resultados transmitidos para a aplicação é efetuada pela própria aplicação, em que no caso de um ataque detectado possam ser tomadas contramedidas adequadas.

[0011] O método, de acordo com a invenção, é executado em particular, em um portador de dados portátil, em particular um cartão de chip ou um módulo seguro.

[0012] De forma apropriada, para a verificação do resultado de uma respectiva chamada de função, uma função adicional do sistema operacional é solicitada pela aplicação. A esse respeito é, em particular, provido que a chamada da respectiva função do sistema operacional pela aplicação ocorra através de uma primeira interface e a chamada de uma função adicional pela aplicação ocorra através de uma segunda, em particular, interface própria. Através da segunda interface, os resultados dos processo relevantes para a segurança anteriores podem ser verificados de uma maneira simples, sem ter que influenciar o modo de trabalho e funcionamento da primeira interface. Através da extensão da segunda interface, com isso também uma verificação dos resultados transmitidos por um sistema operacional, pode ocorrer em determinados ambientes os quais são padronizados e não alteráveis.

[0013] Uma modalidade adicional fornece que uma verificação central, uniforme dos respectivos resultados das diferentes chamadas de função seja executada. Em particular, é provido que uma verificação da última chamada de função ocorra. Mediante essa verificação, pode ser confirmado se as funções chamadas foram realmente executadas, e se, o valor do retorno recebido corresponde ao resultado real. Desta forma ataques podem ser detectados com uma alta probabilidade.

[0014] Uma modalidade adicional provê que para verificação dos resultados da respectiva chamada de função, o resultado determinado pelo sistema operacional e transmitido para a aplicação é transmitido para o sistema operacional e verificado por este último. A transmissão do resultado da aplicação para o sistema operacional, aqui ocorre preferivelmente através da segunda interface, pela qual padrões existentes no que se refere à comunicação entre a aplicação e o sistema operacional através da primeira interface não necessitam ser trocados ou estendidos.

[0015] Em uma forma vantajosa, o comportamento adicional do portador de dados portátil pode ser controlado pela aplicação na dependência do resultado da verificação. O controle do comportamento adicional do portador de dados portátil compreende um tempo de atraso e/ou o desligamento do portador de dados. A reação respectivamente selecionada pode ocorrer na dependência do resultado da verificação pela aplicação.

[0016] Um ataque na chamada da função pode até mesmo mudar a função chamada. Proteção adicional é possível a partir de resultados (corretos) de uma função errada, isto é, uma função exceto aquela chamada pela aplicação. Além do resultado de uma chamada de função, a aplicação pode também verificar se realmente a função chamada foi executada. A aplicação transmite um parâmetro de verificação para o sistema operacional que identifica a função chamada. O sistema operacional tem armazenado um parâmetro de referência para a função chamada (passada) e verifica o dito parâmetro de referência contra o parâmetro de verificação. O parâmetro é preferivelmente transmitido para o sistema operacional junto com o resultado, e o parâmetro é verificado dentro da estrutura de verificação do resultado. Dessa forma, se uma função diferente da função chamada tiver fornecido o resultado, este é detectado dentro da estrutura da verificação.

[0017] A chamada de função verificada deve ser preferivelmente a última chamada de função. Contudo, nem todas as chamadas de função da aplicação tem que ser funções de segurança relevantes. As chamadas de função adicionais não são asseguradas como sugerido aqui, porém, com os seus resultados não sendo armazenados pelo sistema operacional para uma verificação. Em particular, a verificação dos resultados é para ser possível respectivamente pela última chamada de função de segurança relevante. Somente os resultados de chamadas de função relevantes podem ser verificados. Chamadas de função de adicionais (não de segurança relevante) podem ocorrer entre a função de chamada da função de segurança relevante e a verificação dos resultados da última chamada função de segurança relevante pela aplicação.

[0018] Em uma modalidade concreta como aplicação um miniaplicativo de cartão Java e como um sistema operacional um Cartão Java VM (máquina virtual) é usado. O portador de dados em que a aplicação e o sistema operacional são executados é preferivelmente um cartão Java.

[0019] Um portador de dados, de acordo com a invenção, o qual é, em particular, configurado na forma de um cartão de chip ou de um módulo de segurança, é configurado de modo a executar o método acima descrito de acordo com a invenção.

[0020] A invenção será descrita a seguir, mais detalhadamente com referências às figuras. As figuras são descritas como a seguir:

[0021] Figura 1 uma sequência esquemática do método de acordo com a invenção, e

[0022] Figura 2 uma representação esquemática de um portador de dados portátil de acordo com a invenção.

[0023] A presente invenção procede a partir de uma aplicação A a qual chama funções de um sistema operacional BS. A aplicação A, para esta finalidade, compreende um código interpretável ou nativo executável. Embora a invenção possa ser geralmente empregada à qualquer aplicação que execute um sistema operacional, a modalidade exemplificative descrita a seguir procede de um cartão Java como um portador de dados portátil, no qual uma máquina virtual processa chamadas de função de um miniaplicativo Java.

[0024] A aplicação A pode acessar o sistema operacional BS do cartão Java CC por meio de duas interfaces ST1, ST2 (conforme Figura 2). Através das primeiras funções de interface ST1 do sistema operacional BS são chamadas pela aplicação A. A primeira interface ST1 é, por exemplo, um cartão Java API. A segunda interface ST2, a qual é, em particular, de uma natureza proprietária, oferece funções adicionais para a aplicação que são adequadas para aumentar a segurança. Em particular, a aplicação pode verificar, por meio da interface ST2, um resultado transmitido do sistema operacional BS para a aplicação A na sequência de uma chamada de função.

[0025] O fornecimento da segunda interface ST2 adicional remedia deficiências críticas de segurança tais como existem, por exemplo, no cartão Java API da Sun Microsystems. Por exceção do comando "verificar PIN", no qual um estado é modificado que pode ser consultado do sistema de operação pela aplicação, o cartão Java API fornece um valor Booleano de volta para a aplicação A. Em relação às funções relevantes de segurança, tais como, por exemplo, a verificação de assinaturas, assim como retornar apenas um valor Booleano é usado o qual é retomado para a aplicação A. É verdade que esse dito valor é estendido internamente para formar um valor de 2-bytes. No entanto, todo valor diferente de zero é interpretado como verdadeiro. Além disso, a probabilidade de um ataque bem sucedido no valor de retorno é fortemente aumentada, visto que todo resultado falsificado conduz a uma verificação bem sucedida de uma assinatura inválida, sem a aplicação A estar em posição de detectar tal ataque.

[0026] Através da segunda interface proprietária ST2, a segurança contra manipulações pode ser aumentada na medida em que os resultados devolvidos para a aplicação A através do sistema operacional BS são verificados. Dependendo do resultado da verificação do cartão Java pode ser configurado para um estado de segurança, se necessário.

[0027] A segunda interface ST2 permite realizar novas funções disponíveis para a verificação dos resultados dos processos relevantes de segurança precedentes. Para esse propósito, independente do valor do resultado, que é retomado pelo sistema operacional BS para a aplicação A através da primeira interface ST1, internamente um valor de resultado adicional pode ser mantido, o qual pode ser consultado pela aplicação A em um ponto adequado na sequência do programa. Por meio deste valor de resultado pode ser verificado se as funções chamadas da aplicação foram realmente executadas pelo sistema operacional. Com isso, uma verificação ocorre se o valor do resultado recebido a partir do sistema operacional corresponde ao resultado atual. Além disso, pelos métodos disponibilizados pela segunda interface ST2, é oferecida a possibilidade de reagir ao resultado da verificação. Por exemplo, o cartão Java pode ser desligado ou o tempo de resposta do cartão Java pode ser modificado.

[0028] Disponibilizando a segunda interface ST2, os valores de resultados transmitidos pelo sistema operacional BS à aplicação A podem ser verificados independentemente. Dessa maneira, a detecção bem sucedida do ataque e/ou manipulações é possível.

[0029] A segunda interface ST2 pode permitir que uma aplicação informe um ataque detectado.

[0030] A Figura 1 representa o comportamento descrito do cartão Java descrito esquematicamente. A aplicação A na etapa do processo S1 chama uma função f1 do sistema operacional BS. Na etapa S2 o sistema operacional BS executa a função f1 e fornece seus resultados resultantes deste. Em seguida o resultado é transmitido através da primeira interface ST1 para a aplicação A. Quando como valor de resultado meramente um valor Booleano é transmitido para a aplicação A como resultado, isso pode ser falsificado de uma maneira simples.

[0031] Isto é assumido na Figura 1, e esquematicamente indicado pela seta. A aplicação A, dessa forma, recebe primeiramente como resultado de um sistema operacional BS o valor “resultado*”. Na etapa S3 o valor do resultado “resultado*” é verificado no dito valor é transmitido para o sistema operacional BS. O sistema operacional BS verifica o valor do resultado “resultado*” recebido a partir da aplicação A. Aqui é verificado que o “resultado*” não corresponde ao valor de resultado “resultado” transmitido para a aplicação A na etapa S2. Reagindo a isto, o sistema operacional BS na etapa S4 envia uma informação “NIO”, o qual sinaliza uma discrepância de valor do resultado transmitido na etapa S2 para a aplicação A e o valor do resultado verificado. Assim, na etapa S5 um ataque é detectado pela aplicação A.

[0032] A comunicação entre a aplicação A e o sistema operacional BS nas etapas S3, S4 e S5 ocorre através da segunda interface ST2. Através da segunda interfase ST2 a aplicação A é ainda habilitada para reagir ao ataque detectado na etapa S5. Opcionalmente, a aplicação pode comunicar o ataque detectado ao sistema operacional. O sistema operacional poderia reagir diretamente a essa mensagem. Contudo, preferivelmente o sistema operacional primeiro aguarda que a aplicação controle a reação ao ataque.

[0033] Na etapa S6 uma solicitação para um atraso de tempo é transmitida ao sistema operacional BS. A etapa anterior adiciona um atraso de tempo da sequência do cartão Java na etapa S7. O atraso de tempo referente à aplicação A pode ter duração aleatória.

[0034] Alternativamente ou adicionalmente, de acordo com a etapa S8 o pedido para o desligamento do cartão Java pode ser transmitido ao sistema operacional BS. Depois do recebimento do pedido, o cartão Java é desligado pelo sistema operacional na etapa S9.

[0035] A interface ST2 oferece para uma aplicação, em particular, também as seguintes funções adicionais que não estão representadas na figura 2: - relatório de um ataque detectado pela aplicação, - pedido de desligamento condicional ao sistema operacional, o qual causa o desligamento pelo sistema operacional no caso de um erro ter sido detectado ou informado antes, e - reinicialização da memória do valor do resultado da última chamada de função para um estado pré-definido.

[0036] Relatar a detecção de ataque torna possível um controle mais flexível pela aplicação e/ou oferece para o sistema operacional uma melhor base de tomada de decisão para suas próprias possíveis medidas de controle.

[0037] Em uma modalidade de segurança o resultado da verificação de ataque é informado independentemente do resultado. Também, um pedido de desligamento condicional pode sempre ser executado pela aplicação. A partir dessas duas etapas parciais a sequência é realizada independentemente do resultado de verificação.

[0038] A reinicialização de uma memória do valor de resultado, finalmente ainda permite que a aplicação detecte um ataque dirigido na verificação do resultado da chamada de função. Quando a memória do valor do resultado do sistema operacional é reinicializada para o valor “0”, por exemplo, a aplicação pode testar a sua própria função com uma solicitação com um resultado “1”. Esta verificação seria então ainda possível independentemente das chamadas de funções reais.

Claims (13)

1. Método para executar uma aplicação (A) que compreende código interpretável ou nativo executável e chama funções de um sistema operacional (BS), em que o sistema operacional (BS) transmite um resultado de uma respectiva chamada de função (f1) à aplicação (A), em que o método é executado em um cartão de chip, um token USB ou um módulo de segurança, caracterizado pelo fato de a aplicação (A) verificar o resultado de uma respectiva chamada de função para uma falsificação, de modo a detectar um ataque, e para verificar o resultado de uma respectiva chamada de função (f1) uma função adicional do sistema operacional (BS) é chamada pela aplicação (A), que desempenha uma verificação central, uniforme dos resultados respectivos de diferentes chamadas de função.

2. Método, de acordo com a Reivindicação 1, caracterizado pelo fato de que a chamada de uma respectiva função do sistema operacional (BS) pela aplicação (A) ocorre através de uma primeira interface (ST1) e a chamada da função adicional pela aplicação (A) ocorre através de uma segunda, interface proprietária (ST2).

3. Método, de acordo com a Reivindicação 1 ou 2, caracterizado pelo fato de que a aplicação (A) reporta um ataque detectado pela aplicação ao sistema operacional.

4. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que a aplicação transmite uma verificação de parâmetro ao sistema operacional que identifica a função chamada.

5. Método, de acordo com quaisquer das Reivindicações de 1 a 4, caracterizado pelo fato de que uma verificação da última chamada de função é realizada.

6. Método, de acordo com a Reivindicação 5, caracterizado pelo fato de que a aplicação chama um reinicio de uma memória de valor de resultado da última chamada de função para um estado predefinido.

7. Método, de acordo com quaisquer das Reivindicações de 1 a 6, caracterizado pelo fato de que para verificação do resultado de uma respectiva chamada de função o resultado determinado e transmitido à aplicação (A) pelo sistema operacional (BS) é transmitido ao sistema operacional (BS) e verificado por este.

8. Método, de acordo com quaisquer das Reivindicações de 1 a 7, caracterizado pelo fato de que na dependência no resultado da verificação, o comportamento adicional do portador de dados portátil (CC) é controlado pela aplicação (A).

9. Método, de acordo com a Reivindicação 8, caracterizado pelo fato de que o controle do comportamento adicional do portador de dados portátil (CC) compreende um atraso de tempo e/ou um desligamento.

10. Método, de acordo com quaisquer das Reivindicações de 1 a 9, caracterizado pelo fato de que são usados como aplicação um miniaplicativo Java e como sistema operacional uma máquina virtual Java.

11. Método, de acordo com quaisquer das Reivindicações de 1 a 10, caracterizado pelo fato de que para verificação do resultado de uma respectiva chamada de função um parâmetro é transmitido ao sistema operacional (BS) e verificado por este, no qual o parâmetro identifica a chamada de função.

12. Portador de dados portátil (CC), em particular um cartão de chip, módulo de segurança ou tokenUSB, caracterizado pelo fato de ser configurado para executar um método conforme definido em quaisquer das reivindicações de 1 a 11.

13. Portador de dados portátil (CC), em particular um cartão de chip, módulo de segurança ou tokenUSB, com um sistema operacional (BS) e uma primeira interface (ST1) que possibilita uma aplicação (A), que é executável no portador de dados e que compreende código interpretável ou nativo executável, para chamar funções do sistema operacional (BS), pelo qual o sistema operacional (BS) é configurado para transmitir um resultado da respectiva chamada de função (f1) à aplicação (A), caracterizado pelo fato de o sistema operacional tornar possível uma segunda interface (ST2) para a aplicação, através da qual a aplicação pode relatar um ataque detectado ao sistema operacional e a aplicação (A) pode ter uma verificação central, uniforme de resultados respectivos de diferentes chamadas de função realizados.

Images