Variables de surface

O estudo da verificação de hardware e software é um tópico de extrema relevância de pes- quisa para smart cards. No caso particular de Java Card, seu ambiente de execução simplificado e a linguagem com notação simples, tornam o esforço de verificação menos complexo quando comparado com uma linguagem como o Java padrão. Java Card implementa apenas os tipos primitivos byte, short e int, possui uma API restrita, e não apresenta recursos como threads e coleta de lixopela máquina virtual. Sendo assim, a verificação pode concentrar-se em menos aspectos da linguagem e do ambiente de execução.

A Common Criteria é uma organização que tem por objetivo avaliar a segurança de produtos de tecnologia, de acordo com diversos níveis de segurança (EALs). Um produto é classificado em um certo nível (de 1 a 7) a partir da análise das técnicas de especificação e desenvolvimento que foram empregadas na sua construção e da avaliação de que o produto cumpre com os re- quisitos de segurança especificados. No nível mais alto de certificação, exigem-se a utilização de métodos formais e o seu relacionamento com a especificação de políticas de segurança.

Nesse sentido, o trabalho de Motré e Terí [MT00] estabelece modelos de políticas de se- gurança para o componente Java Card Runtime Environment (JCRE) da máquina virtual Java Cardvisando atingir os níveis 4, 5 e 7 de certificação no Common Criteria. O nível 6 não foi incluso por ser totalmente coberto pelo nível 7, o primeiro no qual se exige a aplicação de téc- nicas de verificação formal. Como estudo de caso, especificou-se a execução de instruções de bytecodegeradas para um applet. O acesso a uma instrução de bytecode pelo interpretador Java pode requerer a autorização do mecanismo de firewall para verificar, por exemplo, se o applet possui as permissões necessárias para executá-la. Para o nível 4, o modelo de segurança foi implementado utilizando-se um diagrama de estados UML. Visando atingir o nível 5, a política de segurança anteriormente especificada foi formalizada como uma máquina B. Nesse caso, os estados do diagrama UML foram associados às variáveis do modelo em B. Através do invariante da máquina, foram descritas as possíveis transições entre os estados do modelo. Por fim, para atingir o nível 7, é necessário atestar que os componentes funcionais do sistema relacionados à política de segurança realmente a implementam. Dessa forma, as variáveis das funcionalida-

des sujeitas à verificação de segurança foram associadas às variáveis do modelo da política de segurança, que também foi especificado em B. Além disso, foi verificado que cada função de segurança implementava transições de estados que eram possíveis no modelo de segurança.

Na mesma linha do trabalho anterior, Dadeau et. al. [DLMP08, DPT08] definem polí- ticas de segurança para controle de acesso em aplicações para smart cards. Inicialmente, implementou-se, na linguagem B, o modelo da política de acesso a um objeto da aplicação Java Cardpor um agente externo utilizando uma operação do modelo. A política de acesso foi então mapeada para a implementação da operação em Java Card. A conformidade da operação implementada com o modelo de segurança é verificada com referência a todo trace de execução da implementação poder também ser executado pelo modelo de segurança. A base teórica da abordagem é feita utilizando o método B, dessa forma, foi possível também verificar a correção dos mapeamentos entre o modelo de segurança e a sua implementação através de obrigações de prova.

Salienta-se que a especificação da API Java Card é uma área de aplicação de métodos formais a Java Card que vem recebendo bastante destaque. Uma vez que o código fonte da API normalmente não é fornecido, de uma forma geral, o objetivo desses trabalhos é permitir que verificações sejam feitas nas classes Java Card que a utilizam, por meio da especificação formal da API. Em Meijer [MP01] e Poll [PvdBJ01] pode-se vislumbrar a especificação, por meio de anotações em Java Modelling Language (JML) [Gar06], das classes JCSystem e APDU, respectivamente. O trabalho de Larsson [LM04] fornece como estudo de caso a especificação da classe para autenticação OwnerPin em JML e Object Constraint Language (OCL), fazendo uma comparação entre esses dois formalismos. Em sua dissertação de mestrado, Larsson [Lar03] especifica quase a totalidade da API Java Card 2.2.1 utilizando o formalismo OCL. Os trabalhos citados, bem como a especificação da API Java Card, foram utilizados como referência para a criação dos modelos da API Java Card da biblioteca KitSmart.

Uma especificação em B das propriedades funcionais e de segurança do mecanismo de transação para Java Card foi feita em [SL99]. Essa especificação foi submetida a 11 refinamen- tos, sendo o último nível a implementação em B. Em todo o desenvolvimento foram geradas e corretamente verificadas 1500 obrigações de provas. A partir da implementação B foi feita a geração “manual” de código para a linguagem C.

A verificação do bytecode Java Card geralmente é efetuada fora do cartão para assegurar que a aplicação a ser instalada segue a especificação Java Card e não compromete a segurança da máquina virtual ou de outros applets instalados no cartão [Ort01]. Em [CBR02] foi desen- volvido um verificador de bytecode gerado em linguagem C a partir da sua especificação em

B, com otimizações de código e de utilização de memória, visando a sua instalação e execu- ção dentro do cartão. Foram desenvolvidos modelos para a verificação estrutural e de tipos. A primeira forma de verificação visa garantir que o arquivo contendo a aplicação Java Card a ser inserido no cartão, denominado de Converted Applet (CAP), é válido, o que compreende a verificação de que as classes referenciadas realmente existem, que métodos final não sejam sobrescritos, a ausência de ciclos em hierarquias de herança, dentre outras. Já a verificação de tipos é utilizada para assegurar que a conversão de tipos em uma expressão seja feita so- mente entre tipos compatíveis. A interface entre esses modelos foi feita na especificação do arquivo CAP. O modelo do arquivo CAP é refinado pelo verificador estrutural, que especifica cada componente do arquivo CAP.

A geração automática de testes baseada em métodos formais para aplicações Java Card é também uma linha de pesquisa que vem recebendo certa atenção, como pode ser visto por meio dos trabalhos de Martin e Bousquet [MdB01] e de Weelden [vWOF+_05].

No trabalho de Martin e Bousquet [MdB01] inicialmente é feita a modelagem dos métodos do applet por meio de diagramas de estados UML. Estes são então traduzidos, com o auxílio da ferramenta UMLAUT [HPP00], em Labeled Transition Systems que servem como entrada para a ferramenta TGV [JJ05], que por sua vez gera os casos de teste. Os autores desenvolveram um pequeno programa para traduzir os casos de teste gerados em uma aplicação Java Card. Assim como no trabalho anterior, um estudo de caso de carteira eletrônica foi utilizado para a validação desta proposta. O programa gerado com base nos casos de teste inicializa as variáveis do applet e chama cada método, por meio de comandos APDU, passando diferentes parâmetros de teste. Por fim, as respostas enviadas pelos métodos são comparadas às saídas esperadas para cada resposta. Na validação da proposta de [MdB01], um processo manual de teste de caixa-preta feito diretamente na aplicação, ou seja, sem relação com o método proposto, foi feito e comparado com a proposta do artigo. De acordo com os autores, esta última mostrou-se superior em encontrar erros que aquela feita sem o auxílio das ferramentas.

Em Weelden [vWOF+_{05] foi feito um estudo sobre a aplicabilidade de testes caixa preta}

baseado em especificações formais em aplicações Java Card e foram feitas comparações com outras abordagens de teste para Java Card. Para a geração dos dados, execução e análise dos testes foi utilizada a ferramenta GAST [KATP02], que recebeu como entrada uma especificação com as propriedades do sistema como funções na linguagem CLEAN2. Um estudo de caso de carteira eletrônica foi utilizado na aplicação de testes de forma incremental. Uma membro da equipe do projeto ficou responsável por desenvolver a especificação da aplicação e, uma

outra pessoa, a sua implementação. A cada novo ciclo de especificação/desenvolvimento, era aplicado o teste para verificar a conformidade da especificação com a implementação. Ao final do processo verificou-se que essa abordagem era adequada, uma vez que ela conseguiu detectar as inconsistências entre o modelo e a implementação final, tendo como resultado, segundo o autor, uma aplicação livre de erros.

Alguns trabalhos que são parte do grupo de pesquisa do autor desta tese enveredam por esta área, tais quais os trabalhos de Fernanda Souza [Sou09] e de Ernesto Matos [dM12]. Até o presente momento, ainda não incorporou-se testes ao BSmart. No entanto, é interessante avaliar quais resultados desses trabalhos podem ser introduzidos no método.

Na dissertação de Souza estudou-se a aplicação de técnicas para a geração de casos de testes caixa preta a partir de especificações formais na linguagem B. Apenas as variáveis relacionadas à pré-condição de uma operação B que modifica o estado da especificação são selecionadas para o teste. Foram adotadas as técnicas de análise do valor limite e particionamento de equivalência como critério para a seleção dos dados de testes, o que é feito com o auxílio da animação da especificação na ferramenta ProB [LBBP10]. Finalmente, a construção manual dos casos a serem testados é feita e submetida à ferramenta JUnit [JUn10].

Observa-se que o trabalho de Souza teve sequência na dissertação de mestrado de Ernesto Matos [dM12], na qual desenvolveu-se um estudo de caso para validar a proposta de Souza, o que resultou na descoberta de pontos que poderiam ser melhorados. No caso, foram aperfeiçoa- dos os critérios de cobertura dos testes e acrescentou-se a extração de informações do corpo das operações durante a definição dos casos de testes (e não apenas das pré-condições). A disserta- ção de Matos também contribuiu com uma ferramenta para automatizar a geração dos casos de teste.

O módulo de implementação B0, apesar de oferecer muitas construções de linguagem de programação imperativas, ainda não possui a mesma expressividade apresentada por essas lin- guagens quanto à facilidade de uso e recursos de programação disponíveis. Tendo em vista proporcionar maior poder de expressão à linguagem B, de modo à torná-la mais atrativa para a indústria, Burdy e Requet [BR03] propuseram extensões à notação B, definindo a teoria e obri- gações de prova para os mecanismos de interrupção do fluxo de execução de instruções break, continuee return, semelhantes aos encontrados em linguagens como C e Java. Um mecanismo de especificação e lançamento de exceções em um módulo B também foi proposto. Nesse caso, as exceções podem ser utilizadas para se melhorar o entendimento da especificação, separando claramente os comportamentos “normais” de execução dos comportamentos de erro. Dessa forma, ao invés de retornar o comportamento de erro como um valor em um parâmetro de saída

de uma operação, especifica-se o comportamento de erro como uma exceção.

No presente trabalho, também lida-se com comportamentos excepcionais em Java Card, que são modelados por meio de máquinas que especificam as classes de exceção da API Java Card. Esses modelos são importados no refinamento full function e possuem uma operação para indicar o lançamento de uma exceção. Ressalta-se que o modelo proposto é bastante simples, sendo uma exceção representada por um número de status, no formato da resposta APDU, que identifica o erro para a aplicação host cliente.