Desenvolvimento Formal de Aplicações para Smart
Cards
Natal-RN
PROGRAMA DE PÓS-GRADUAÇÃO EMSISTEMAS ECOMPUTAÇÃO
Bruno Emerson Gurgel Gomes
Desenvolvimento Formal de Aplicações para Smart
Cards
Tese de doutorado em ciência da computação.
Orientador:
Prof. Dr. David Boris Paul Déharbe
Natal-RN
A pesquisa que deu origem a este trabalho teve início no ano de 2005, quando tive a oportu-nidade de ingressar como bolsista de iniciação científica, sob orientação de Anamaria Moreira e colaboração de David Déharbe. A eles o meu especial agradecimento, pelo conhecimento ad-quirido e pela amizade durante todos esses anos. Com eles aprendi bastante e amadureci como pesquisador e como pessoa.
Gostaria de agradecer a toda a minha família, Wellington e Elizabeth (pais), Edmundo e Vládina (sogro e sogra), que me forneceram suporte material e emocional para seguir adiante. O carinho e incentivo dedicados foram fundamentais para mim.
À Vanessa, minha esposa, que esteve ao meu lado desde o início, pelo companheirismo, respeito e amor. Você pacientemente suportou meu mal-humor e, dia após dia, me deu forças para seguir adiante, mesmo em face das dificuldades e angústias no decorrer da construção da tese. Apesar de não compreender a parte técnica do trabalho, as suas revisões criteriosas no texto foram de fundamental importância.
Agradeço também a todos os que colaboraram com o trabalho, dentre os quais destaco Kátia Moraes, Thiago Dutra, Giuliano Vilela e Simone Santos. O auxílio e a troca de conhecimentos com vocês foi inestimável.
Aos professores membros externos da banca, Augusto Sampaio, Marcel Oliveira e Rohit Gheyi, pelas observações que ajudaram a melhorar o resultado final deste trabalho, e que servi-rão de base para o seu aprimoramento daqui em diante.
Aos colegas (amigos) da pós-graduação, Cleverton, Plácido, Isaac, Macilon, Fred, dentre tantos outros, pelos momentos de descontração, de compartilhamento de ideias e de ajuda em diversos momentos. Em especial agradeço a Cleverton Hentz, pelo apoio no desenvolvimento inicial da especificação da tradução em ASF+SDF.
As aplicações para smart cards representam um mercado que cresce a cada ano.
Nor-malmente, essas aplicações manipulam e armazenam informações que requerem garantias de segurança, tais como valores monetários ou informações confidenciais. A qualidade e a segurança dosoftware para cartões inteligentes pode ser aprimorada através de um processo
de desenvolvimento rigoroso que empregue técnicas formais da engenharia desoftware. Neste
trabalho propomos o método BSmart, uma especialização do método formal B dedicada ao
desenvolvimento de aplicações parasmart cardsna linguagemJava Card. O método descreve,
em um conjunto de etapas, como uma aplicação smart card pode ser gerada a partir de
refinamentos em sua especificação formal. O desenvolvimento é suportado por um conjunto de ferramentas, automatizando a geração de parte dos refinamentos e a tradução para as aplicações
Java Cardcliente (host) e servidora (applet). Ressalta-se que o processo de especificação e
re-finamento descrito no método foi formalizado e verificado utilizando o próprio método B, com o auxílio da ferramentaAtelier B[Cle12a]. Destaca-se que a aplicaçãoJava Cardé traduzida a
partir do último passo de refinamento, denominado de implementação. A especificação dessa tradução foi feita na linguagem ASF+SDF [BKV08]. Inicialmente, descreveu-se as gramáticas das linguagens B e Java (SDF) e, em uma etapa posterior, especificou-se as transformações de B paraJava Card através de regras de reescrita de termos (ASF). Essa abordagem foi um
importante auxílio durante o processo de tradução, além de servir ao propósito de documentá-lo. Cumpre destacar a bibliotecaKitSmart [Dut06, San12], componente essencial ao método BSmart, que inclui modelos em B de todas as 93 classes/interfaces da API Java Card na
versão 2.2.2, dos tipos de dados Java e Java Card e de máquinas que podem ser úteis ao
especificador, mas que não estão presentes naAPI padrão. Tendo em vista validar o método,
seu conjunto de ferramentas e a bibliotecaKitSmart, procedeu-se com o desenvolvimento,
se-guindo o métodoBSmart, de uma aplicação de passaporte eletrônico. Os resultados alcançados
neste trabalho contribuem para o desenvolvimento smart card, na medida em que
possibi-litam a geração de aplicaçõesJava Cardcompletas (cliente e servidor) e menos sujeitas a falhas.
Palavras-chave: Smart Cards, Java Card, Método Formal B, Refinamento,
Smart card applications represent a growing market. Usually this kind of application manipulate and store critical information that requires some level of security, such as financial or confidential information. The quality and trustworthiness of smart card software can be improved through a rigorous development process that embraces formal techniques of software engineering. In this work we propose the BSmart method, a specialization of the
B formal method dedicated to the development of smart card Java Card applications. The method describes how a Java Card application can be generated from a B refinement process of its formal abstract specification. The development is supported by a set of tools, which automates the generation of some required refinements and the translation to Java Card client (host) and server (applet) applications. With respect to verification, the method development
process was formalized and verified in the B method, using the Atelier B tool [Cle12a]. We emphasize that theJava Cardapplication is translated from the last stage of refinement, named
implementation. This translation process was specified in ASF+SDF [BKV08], describing the grammar of both languages (SDF) and the code transformations through rewrite rules (ASF). This specification was an important support during the translator development and contributes to the tool documentation. We also emphasize theKitSmartlibrary [Dut06, San12], an essential
component ofBSmart, containing models of all 93 classes/interfaces of Java Card API 2.2.2,
of Java/Java Card data types and machines that can be useful for the specifier, but are not part of the standard Java Card library. In other to validate the method, its tool support and the
KitSmart, we developed an electronic passport application following the BSmart method. We
believe that the results reached in this work contribute to Java Card development, allowing the generation of complete (client and server components), and less subject to errors, Java Card applications.
Keywords: Smart Cards, Java Card, B Formal Method, Refinement, Formal Development,
Lista de Figuras
1 Introdução p. 16
1.1 Justificativa . . . p. 18
1.2 Desenvolvimento com o Método BSmart . . . p. 20
1.3 Objetivos . . . p. 21
1.3.1 Objetivo geral . . . p. 21
1.3.2 Objetivos específicos . . . p. 21
1.4 Artigos Publicados . . . p. 23
1.5 Resumo dos Capítulos . . . p. 24
2 Java Card p. 26
2.1 O Modelo de Comunicação Smart Card . . . p. 27
2.2 Desenvolvimento de Aplicações Java Card . . . p. 28
2.3 O applet Java Card . . . p. 30
2.3.1 Applet APDU . . . p. 30
2.3.2 Applet RMI . . . p. 33
2.4 Aplicação Host . . . p. 35
3 O Método Formal B p. 38
3.1 Especificação Abstrata (Máquina B) . . . p. 40
3.1.1 Substituições e obrigações de prova . . . p. 43
3.2.1 Obrigações de prova . . . p. 49
3.2.2 Implementação . . . p. 50
3.3 O Formalismo Event-B . . . p. 51
4 O Método BSmart p. 56
4.1 Processo de Desenvolvimento . . . p. 57
4.2 Especificação Abstrata . . . p. 59
4.3 Desenvolvimento da Aplicação Java Card . . . p. 61
4.3.1 Geração do refinamento Full Function . . . p. 63
4.3.2 Implementação em B do desenvolvimento Java Card dos Serviços . . p. 65
4.3.3 Implementação B do applet Java Card . . . p. 66
4.4 Verificação da Mudança de Interface entre os ModelosJavaeJava Card . . . p. 67
4.4.1 Um método de “refinamento” para permitir a mudança de interface . p. 68
4.5 Geração da API para a Aplicação Host . . . p. 70
4.5.1 Exemplo de classes geradas . . . p. 73
4.6 Suporte de Ferramentas ao Método BSmart . . . p. 75
4.6.1 Ferramentas e APIs Desenvolvidas . . . p. 76
4.7 Uso deRetrenchmentpara a verificação da mudança de interface . . . p. 78
4.8 Avaliação do Método e Perspectivas Futuras . . . p. 83
5 Especificação da Tradução para Java Card p. 85
5.1 Definição Sintática de Linguagens com SDF . . . p. 86
5.1.1 Símbolos . . . p. 88
5.1.2 Seções da gramática . . . p. 89
5.2 ASF . . . p. 91
5.3 Traduzindo de B para Java Card . . . p. 94
5.3.1 Parte SDF da tradução . . . p. 95
5.3.2 Regras de reescrita globais . . . p. 96
5.3.3 Predicados . . . p. 98
5.3.4 Termos . . . p. 99
5.3.5 Cláusulas . . . p. 100
5.3.6 Condições . . . p. 105
5.3.7 Instruções . . . p. 106
5.4 Considerações Finais . . . p. 109
6 KitSmart: uma biblioteca de auxílio ao desenvolvimento Java Card em B p. 111
6.1 Módulos Básicos . . . p. 112
6.1.1 Tipos primitivos . . . p. 112
6.1.2 Outros Módulos de Biblioteca . . . p. 114
6.2 Especificação das classes da API Java Card . . . p. 114
6.2.1 Características gerais dos modelos . . . p. 116
6.2.2 Exemplo: modelo da classe APDU . . . p. 117
6.2.3 Abordagem para exceções . . . p. 119
6.2.4 Atribuição de tipos a objetos . . . p. 120
6.2.5 Sobrecarga e sobrescrita de métodos . . . p. 121
6.3 Módulos para tarefas úteis ao desenvolvedor . . . p. 122
6.4 Considerações Finais e Desenvolvimentos Futuros . . . p. 123
7 Estudo de Caso: Passaporte Eletrônico p. 125
7.1 Principais referências utilizadas . . . p. 127
7.2.2 Estrutura para armazenamento de dados (LDS) . . . p. 129
7.2.3 Mecanismos de Segurança das Informações Armazenadas . . . p. 131
7.2.4 Protocolos de Segurança . . . p. 134
7.3 Especificação inicial dos serviços do Passaporte . . . p. 137
7.3.1 Serviço de geração de número randômico . . . p. 138
7.3.2 Serviço de autenticação mútua (cliente-cartão) . . . p. 138
7.3.3 Serviço de leitura de arquivos . . . p. 140
7.4 Especificação Formal Abstrata . . . p. 140
7.5 Versão Java Card da Máquina Passport . . . p. 144
7.6 Refinamento Full Function . . . p. 145
7.7 Implementação B do Passaporte . . . p. 147
7.7.1 Máquinas externas e estado da implementação . . . p. 147
7.7.2 OperaçõesprocessGetChallengeeprocessSelectFile . . . p. 149
7.7.3 Desenvolvimento do Applet Java Card . . . p. 151
7.8 Verificação do Refinamento entre Especificação Abstrata e o Modelo Java Cardp. 155
7.9 Considerações Finais . . . p. 157
8 Trabalhos Relacionados p. 159
8.1 Ferramentas de Suporte ao Desenvolvimento Formal de Software em B e
Event-B . . . p. 160
8.2 Verificação de Aplicações Smart Cards . . . p. 163
8.3 Geração de Código . . . p. 167
9 Considerações Finais p. 172
9.1 Principais Contribuições da Tese . . . p. 173
9.1.1 Correção do Método BSmart . . . p. 174
9.2 O Método Formal B aplicado ao Desenvolvimento Smart Card . . . p. 176
9.3 Trabalhos Futuros . . . p. 178
9.3.1 Método BSmart . . . p. 178
9.3.2 Ferramentas . . . p. 178
9.3.3 Otimização de Código . . . p. 179
9.3.4 KitSmart . . . p. 180
9.3.5 Estudo de Caso . . . p. 181
Referências p. 182
Apêndice A -- Alguns componentes do KitSmart p. 190
A.1 Tipos básicos - JShort . . . p. 190
A.2 Tipos Básicos - JBoolean . . . p. 191
A.3 API Java Card - APDU . . . p. 192
Apêndice B -- Especificação da Tradução para Java Card em ASF+SDF p. 196
B.1 B02Java.sdf . . . p. 196
B.2 B02Java.asf . . . p. 198
B.2.1 Regras Globais . . . p. 198
B.2.2 Cláusulas . . . p. 198
B.2.3 Instruções . . . p. 201
B.2.4 Termos . . . p. 205
B.2.5 Condições . . . p. 206
B.2.6 Predicados . . . p. 207
Apêndice C -- Especificação do Passaporte Eletrônico p. 210
C.3 Refinamento Full Function - Passport_JC_FF_ref . . . p. 214
C.4 Implementação Principal dos Serviços - Passport_JC_imp . . . p. 216
C.4.1 Passport_JC_imp - Operação processReadBinary . . . p. 217
C.4.2 Passport_JC_imp - Operação processGetChallenge . . . p. 218
C.4.3 Passport_JC_imp - Operação processMutualAuthenticate . . . p. 219
C.5 Máquina Abstrata Applet . . . p. 220
C.6 Refinamento Applet . . . p. 222
C.7 Implementação Applet . . . p. 223
C.8 Refinamento para a verificação da conformidade entre o modelo abstrato
2.1 Componentes da plataforma Java Card. Adaptado de: [Ort03a] . . . p. 27
2.2 Comando e resposta APDU. Fonte: [Ort03a] . . . p. 28
2.3 Um applet Java Card APDU para bilhetagem eletrônica - definição de
atri-butos e métodos herdados da classeApplet. . . p. 31
2.4 Método de serviçoaddCreditdoapplet Transport. . . p. 32
2.5 Método de serviçogetCreditsdoapplet Transport. . . p. 33
2.6 Interface remota do Applet RMI . . . p. 34
2.7 Implementação dos serviços do applet RMI . . . p. 34
2.8 Implementação da classe applet na versão RMI . . . p. 35
2.9 Um exemplo simples de aplicaçãohostpara oapplet Transport. . . p. 36
3.1 Um modelo de uma máquina B simples. . . p. 41
3.2 Esquema genérico de um refinamento. . . p. 48
3.3 Um protótipo do módulo de implementação. . . p. 51
3.4 MáquinaEvent-B Transport(esq.) e contextoTransport_Constants(dir.) . . . p. 52
3.5 Eventos da especificaçãoTransport . . . p. 53
3.6 Ações presentes em Event-B. . . p. 54
4.1 Desenvolvimento com o método BSmart. . . p. 57
4.2 Definição do tipo Java e das propriedades para a formalização dos
compo-nentes da especificação abstrata. . . p. 60
4.3 Representação da especificação abstrata que inicia o desenvolvimento BSmart. p. 60
4.4 Uma visão dos artefatos que compõem o desenvolvimento da aplicação Java
4.6 Definição do tipo Java Card e das propriedades para a formalização dos
com-ponentes da especificação concreta. . . p. 63
4.7 Versão full function de JC_App (esq.) e máquina de contexto (dir.). . . p. 64
4.8 Implementação B da aplicação Java Card. . . p. 65
4.9 Refinamento da máquinaAppletda API Java Card. . . p. 66
4.10 Implementação B do applet Java Card. . . p. 67
4.11 Refinamento da especificação abstrata inicial para verificar a correção da
mu-dança de interface pelo módulo Java Card. . . p. 69
4.12 A máquinaInterfaceContext. . . p. 70
4.13 Diagrama de classes UML descrevendo os componentes da API para a
apli-cação cliente. . . p. 72
4.14 Especificação abstrata Transport. . . p. 73
4.15 Classe TransportCommunication. . . p. 74
4.16 Classe TransportProxy - operação addCredit. . . p. 74
4.17 Classe TransportProxy - operações debit e getBalance. . . p. 75
4.18 Ferramentas de suporte ao método BSmart. . . p. 77
4.19 Máquina B padrão (esquerda) e máquinaretrenchment(direita). . . p. 80
4.20 Retrenchment Java Card da especificação abstrata principal J_App (Fig. 4.2). p. 82
5.1 Componentes das gramáticas B0 e Java . . . p. 87
5.2 Elementos básicos de uma definição SDF . . . p. 88
5.3 Módulo Lexical da gramática B0 em SDF. . . p. 90
5.4 Módulo Instruction da gramática B0 em SDF. . . p. 92
5.5 Símbolos iniciais das gramáticas B e Java. . . p. 95
5.6 Parte SDF especificação da tradução. . . p. 96
5.7 Regras iniciais do processo de tradução . . . p. 97
5.10 Regras para rescrita de termos funcionais . . . p. 100
5.11 Regras para rescrita de expressões aritméticas. . . p. 100
5.12 Regras de reescrita para uma sequência de zero ou mais cláusulas . . . p. 101
5.13 Equações de reescrita para cláusulas de inclusão de máquinas. . . p. 101
5.14 Regras de reescrita para uma lista de conjuntos . . . p. 102
5.15 Regras para reescrita de conjuntos adiados e enumerados. . . p. 103
5.16 Regras para tradução de constantes. . . p. 103
5.17 Tradução do invariante e da inicialização . . . p. 104
5.18 Parte das regras de rescrita para tradução de operações. . . p. 104
5.19 Regra auxiliar para tradução dos parâmetros das operações . . . p. 105
5.20 Regra para a tradução de condições. . . p. 105
5.21 Equação de reescrita para uma lista de instruções. . . p. 106
5.22 Reescrita das instruções skip, begin-end e becomes equal to. . . p. 106
5.23 Reescrita das instruções chamada de operação e definição de variável local. . p. 107
5.24 Equação de reescrita para condicional (versão com else). . . p. 107
5.25 Equação de reescrita para condicional (versão com elsif). . . p. 108
5.26 Reescrita da instrução case. . . p. 108
5.27 Equação para tradução da instrução while. . . p. 109
6.1 Modelo em B para o tipo short. . . p. 113
6.2 Parte da máquina JBoolean. . . p. 114
6.3 Definição do estado e algumas operações da biblioteca para sequência de byte. p. 115
6.4 Quantidade de classes por pacote na API 2.2.2. Fonte [San12]. . . p. 116
6.5 Máquina Apdu_Properties. . . p. 117
6.6 Definição do estado da máquina Apdu. . . p. 118
6.9 Definição do estado da máquina APDU com uma estrutura representando o
tipo APDU. . . p. 121
6.10 Duas versões do métodoregisterda máquina Applet. . . p. 122
6.11 Sobrescrita do métodoprocesscomo um refinamento de Applet. . . p. 122
6.12 Parte da máquina Date. . . p. 123
7.1 Exemplo de página de dados de um passaporte. Fonte [ICA06] . . . p. 129
7.2 Máquina Passport - máquinas referenciadas e variáveis de estado. . . p. 141
7.3 Máquina Passport - operação processGetChallenge. . . p. 142
7.4 Máquina Passport - operação processMutualAuthenticate. . . p. 143
7.5 Máquina Passport - operação selectFile. . . p. 143
7.6 Máquina Passport - operação processReadBinary. . . p. 144
7.7 Interface das operações da máquina Passport_JC. . . p. 144
7.8 Máquinas referenciadas pelo refinamento Full Function. . . p. 145
7.9 Máquina de contexto Passport_JC_FF_Context. . . p. 146
7.10 Versão full function (direita) da operaçãoprocessSelectFile. . . p. 146
7.11 Visão geral dos módulos principais do desenvolvimento Passport. . . p. 147
7.12 Máquinas referenciadas e especificação do estado da implementação
Pass-port_JC_imp. . . p. 148
7.13 Passport_JC_imp - operação concreta processGetChallenge. . . p. 149
7.14 Passport_JC_imp - operação concreta processSelectFile. . . p. 150
7.15 Módulos referenciados e estado da máquina Applet. . . p. 151
7.16 Operações abstratasprocesseprocessAPDU(parte). . . p. 152
7.17 Implementação do métodoprocess- obtenção de parâmetros e entrada de dados.p. 153
7.18 Implementação do métodoprocess- chamada deprocessAPDU . . . p. 154
7.21 Refinamento Passport_ref, máquinas inclusas e invariante. . . p. 156
7.22 Máquina Interface Context. . . p. 156
1
Introdução
Um smart card é um dispositivo computacional portátil, sob a forma de um chip de pe-quenas dimensões, normalmente embutido em um cartão plástico. O poder de processamento e armazenamento dos smart cards atuais é bastante limitado. Em sua maioria, eles possuem
processadores com frequência de até 32MHz e memória não-volátil de até 128K. Apesar de limitados, esses recursos são suficientes para atender ao principal propósito da tecnologia, a saber, possibilitar a portabilidade de informações confidenciais em um ambiente com maiores garantias de segurança, quando comparado com os cartões de tarja magnética tradicionais. Os
smart cardsainda se diferenciam pelo fornecimento de serviços através de pequenas aplicações
inseridas no cartão.
Nos últimos anos, os serviços fornecidos pelas aplicações parasmart cardsvêm se tornando
cada vez mais presentes no cotidiano de boa parte da população mundial, em uma vasta gama de setores, tais como, finanças, transporte público, Internet e aplicações governamentais. De acordo com uma pesquisa conduzida pela Eurosmart [Eur12], uma associação de empresas
da indústria smart card que tem por objetivo propor e regular padrões para essa tecnologia,
no ano de 2011, cerca de 6,3 bilhões de smart cards foram vendidos em todo o mundo. Em
sua maioria, esses cartões foram adquiridos pelos setores de telecomunicações (cartões para a tecnologia GSM), finanças (cartões de crédito e pagamento) e governo (passaporte e assistência à saúde). Para o ano de 2012, a associaçãoEurosmartestima que o número de cartões vendidos
possa ultrapassar a marca de 7 bilhões de unidades.
Observa-se em relação ao Brasil a mesma tendência de crescimento do uso de cartões in-teligentes em nível mundial. O bilhete eletrônico no transporte público de massa, a telefonia celular e o governo federal são os principais usuários da tecnologia. O setor governamental recentemente vem adotando duas importantes aplicações que utilizamsmart cardspara
identi-ficação pessoal e autenticação, a saber, o passaporte eletrônico e o registro de identidade civil (RIC).
se-guindo os padrões e recomendações daInternational Civil Aviation Organization(ICAO). Ele
consiste no documento tradicional de passaporte incluindo umchip smart card que armazena
as informações pessoais do portador, dados biométricos (fotografia e impressões digitais) e um certificado digital que permite a autenticação dochipperante os terminais de leitura nos
aero-portos ao redor do mundo, dentre outros mecanismos de segurança. No capítulo 7 detalha-se um estudo de caso desenvolvido neste trabalho com base em uma implementação de código aberto do passaporte eletrônico.
Outra interessante aplicaçãosmart cardé o registro de identidade civil (RIC), uma solução
segura que irá gradativamente substituir os documentos de identidade (RG). Cada brasileiro será identificado por um número nacional único, gerado a partir dos seus dados biométricos. Assim como o passaporte, o RIC contém elementos de identificação pessoal, biométrica e um certificado digital pessoal nochip smart card. Esse novo documento irá possibilitar uma maior
segurança e menor burocracia na identificação pessoal, permitindo a assinatura de contratos e documentos por meio eletrônico [dJ12], até mesmo sem a presença física do interessado.
Evidencia-se que uma das formas de se desenvolver aplicações para smart cards é
utili-zar a linguagem nativa do processador do cartão [RE03] ou uma linguagem de alto nível que compile para umhardwareespecífico. Essa abordagem possui como principal vantagem o fato
do programa desenvolvido ser capaz de ter acesso direto aos recursos do processador. Em contrapartida, a aplicação mencionada não é diretamente portável para outras arquiteturas e, normalmente, é mais difícil de codificar e manter do que aquelas desenvolvidas em linguagens de alto nível.
Em outra abordagem de desenvolvimento, utilizada pela linguagemJava Card, a
compila-ção é feita para um código intermediário que deve ser interpretado por uma máquina virtual. A linguagemJava Cardpossui ampla aceitação no mercado [RE03] e foi a escolha deste trabalho
para o desenvolvimentosmart card. Trata-se de uma versão da plataformaJava, com restrições
quanto a recursos da linguagem, API fornecida e máquina virtual otimizada, tendo em vista pos-sibilitar a sua utilização em dispositivos com recursos dehardware limitados, como ossmart cards.
Em comparação a linguagens nativas,Java Cardgera aplicações que demandam um maior tempo de execução e consomem maiores recursos de processamento e memória. Entretanto, ela se beneficia das vantagens da linguagem Javapadrão, como produtividade, portabilidade,
linguagem segura quanto a tipos, desenvolvimento orientado a objetos e a ampla variedade de ferramentas disponíveis. O ambienteJava Card ainda fornece benefícios adicionais, dentre os
card, a possibilidade de múltiplas aplicações serem instaladas em um mesmo cartão e
meca-nismos de segurança, como o controle de transação e oapplet firewall, que possibilita que uma
aplicação instalada tenha seus dados e código protegidos do acesso por outras aplicações.
O restante desta introdução é divida nas seções descritas a seguir. A justificativa da tese é apresentada na seção 1.1. Posteriormente, na seção 1.2, introduz-se o métodoBSmart. Por sua
vez, a seção 1.3 apresenta os objetivos da tese. Em seguida, a seção 1.4 descreve os trabalhos que foram publicados durante o desenvolvimento do trabalho. Por fim, a seção 1.5, apresenta um resumo dos capítulos que se seguem a esta introdução.
1.1 Justificativa
A importância econômica desse mercado em contínua expansão torna evidente uma preocu-pação no domínio de aplicações parasmart cards: a segurança das informações que
encontram-se armazenadas no cartão e que são enviadas ou recebidas no momento de uma transação. Essas informações, se interceptadas, alteradas, ou removidas, podem causar prejuízos graves ao por-tador do cartão, como perdas financeiras e a exposição de informações privilegiadas, como elementos de identificação pessoal, histórico de saúde, etc. A natureza portável dossmart cards
os tornam ainda mais vulneráveis a ataques externos porsoftwaremal-intencionado. Essas
apli-cações podem ser instaladas em um cartão com o objetivo de explorar falhas nohardware ou
em qualquersoftwarepresente no cartão.
De forma complementar aos mecanismos de segurança oferecidos pelo hardware smart cardou por plataformas específicas, comoJava Card, um meio de se prevenir comportamentos
indesejáveis ou o acesso indevido a informações decorrente de erros introduzidos no desenvol-vimento, é melhorar a qualidade do desenvolvimento das aplicaçõessmart cards. A adoção de
processos, métodos e ferramentas rigorosos da engenharia desoftwarepode assegurar a entrega de um produto final com menos erros e em conformidade com os requisitos especificados.
Nesse contexto, é possível inserir métodos formais no processo de desenvolvimento, que consistem em linguagens, técnicas e ferramentas, com forte embasamento matemático, utiliza-das na especificação e verificação de sistemas [CW96]. Normalmente, eles não são aplicados ao desenvolvimento de todo um sistema, mas apenas em partes dele que definem funcionalidades críticas. Em regra, as técnicas formais não são empregadas de forma isolada, mas em conjunto com métodos tradicionais da engenharia desoftwarepara verificação e validação, como testes
desoftwaree inspeção de código.
desenvol-vimento de sistemas, tal comoZ [Spi92], B [Abr96] ou Event-B [Abr10], não garante
neces-sariamente que osoftwaredesenvolvido (ou parte dele) estará completamente livre de defeitos.
Por outro lado, é um meio de assegurar a correção do seu comportamento de acordo com o que foi especificado [BH94]. Destaca-se que outro importante incentivo à utilização desses méto-dos formais reside no fato deles fornecerem um meio de documentação precisa adicional ao sistema.
Nessa esteira, uma pesquisa conduzida por Lanet [Lan00] concluiu que as aplicaçõessmart cardsconstituem-se em um domínio ideal para a adoção de métodos formais. Ele aponta como
principais razões para isso o fato das aplicações e dos sistemas operacionais parasmart cards
serem de pequeno porte, a necessidade de segurança e a possibilidade de instalação de múltiplas aplicações em um mesmo cartão oferecida por tecnologias comoJava CardouMultOS[Mul10].
Conforme discutiu-se anteriormente, essa característica pode ser a porta de entrada para código mal-intencionado.
Lanet argumenta que os métodos formais podem ser aplicados para reduzir erros no soft-ware smart card, certificar partes da aplicação em um alto nível de confiabilidade,
submetendo-as a entidades que utilizam-se de processos de certificação como oCommon Criteria[Com10],
e para reduzir a necessidade e o custo de testes. A pesquisa de Lanet também evidencia que o desenvolvimento de componentes reutilizáveis, de metodologias e ferramentas, bem como a integração de métodos formais com técnicas tradicionais, como a especificação emUnified Modelling Language (UML), é um meio de minimizar algumas restrições a uso de métodos
formais, como o aumento do tempo de desenvolvimento e a sua adoção, em maior escala, na indústria.
Nesse sentido, a Verified Software Initiative(VSI) [HMLS09] materializa-se em uma
im-portante contribuição na direção de fornecer maior maturidade aos métodos formais, visando facilitar e disseminar a sua utilização emsoftware de larga escala. Trata-se de um projeto de
longo prazo que convida toda a comunidade da engenharia desoftwaree métodos formais,
as-sim como parceiros industriais, a contribuir com estudos de caso, teorias, técnicas e ferramentas para o desenvolvimento desoftwareconfiável e, de forma ideal, livre de erros.
O projeto VSI, inicialmente, propôs a implementação de diversos estudos de caso desa-fiadores, como forma de se criar um repositório de especificações (Verifyed Software Reposi-tory[VSI10]) que posteriormente serão utilizadas na validação das novas ferramentas e técnicas
um marcapasso cardíaco [MLF08, GO09] e do Posix [FFW07], um sistema de arquivos em
memóriaflash.
1.2 Desenvolvimento com o Método BSmart
Evidencia-se que a presente tese utiliza o método formal B [Abr96] como fundamento para um método de desenvolvimento de aplicações parasmart cardsna linguagemJava Card,
denominado deBSmart. O método B possui uma boa utilização, tanto na academia quanto na
indústria, no que concerne à especificação e ao desenvolvimento (com base em refinamentos) de aplicações e partes de sistemas críticos. A base de ferramentas de suporte ao método também é bastante rica, possibilitando a verificação de tipos, geração e verificação de obrigações de prova, animação, geração de código, dentre outras funcionalidades. Além disso, B mostra-se adequado ao desenvolvimento de aplicaçõesJava Card, por elas serem aplicações de pequeno
porte e possuírem linguagem simples e enxuta.
Observa-se que o trabalho desenvolvido no doutorado teve início na dissertação de mestrado do autor desta tese [Gom07]. Na dissertação, definiu-se a versão inicial do métodoBSmart, que descreve, em um conjunto de etapas de refinamento em B, o desenvolvimento da aplicaçãoJava Card. Essa primeira versão foi apresentada em [GMD05] e [DGM06]. Ferramentas de apoio ao
método também foram implementadas. Destacam-se um gerador dos módulos de refinamento e um tradutor que possibilita a geração da aplicação cartão (applet) a partir do refinamento
con-creto (implementação B) do desenvolvimento. A ferramenta de tradução também é responsável pela geração de uma API para possibilitar a comunicação da aplicação cliente (host) com o
cartão de forma transparente ao usuário.
Cumpre destacar que o processo de especificação e refinamento no métodoBSmarté
verifi-cado a cada etapa por meio da resolução das obrigações de prova de cada módulo. No entanto, no trabalho desenvolvido na dissertação, a formalização desse processo não foi realizada. Ou-tro ponto negativo diz respeito à sobrecarga da ferramenta de tradução, que ficou responsável por realizar diversas tarefas além da simples tradução entre as duas linguagens, dessa forma aumentando o risco de introdução de erros na etapa de síntese de código. Dentre elas, é pos-sível destacar a introdução dos tipos compatíveis comJava Card(short, byte, boolean, etc.), a
inserção na classe gerada de métodos requeridos peloframework Java Card e a codificação e
decodificação das informações enviadas e recebidas pelas aplicações host eapplet. De outro
Ressalta-se que este trabalho concentra-se no processo de especificação e desenvolvimento da aplicaçãoJava Cardenquantosoftwarede alto nível. Aspectos da formalização dohardware smart card, de verificação do ambiente de execução ou dobytecodeda aplicação cartão não são tratados de forma direta. O trabalho proposto diferencia-se de outras abordagens similares da literatura (discutidas no capítulo 8) por proporcionar o desenvolvimento completo da aplicação
Java Card, desde a sua especificação formal de alto nível, passando pelos refinamentos que
gradativamente introduzem os aspectos da aplicação Java Card, até a geração de código para os componentes servidor (applet) e cliente (aplicaçãohost).
1.3 Objetivos
1.3.1 Objetivo geral
O presente trabalho tem por objetivo contribuir com o métodoBSmart, uma especialização
do método formal B para o desenvolvimento de aplicações smart cards na linguagem Java Card com maior segurança e confiabilidade. Visando atingir esses requisitos de qualidade, a
tese prioriza a melhoria do processo de desenvolvimento com método através das seguintes ações:
• Introdução dos aspectos relacionados ao ambiente de execução Java Card diretamente
nos refinamentos introduzidos pelo método;
• Formalização do processo de desenvolvimento;
• Desenvolvimento da bibliotecaKitSmartque provê módulos B reutilizáveis que auxiliam
no processo de verificação e geração de código.
1.3.2 Objetivos específicos
Os objetivos específicos do trabalho, apresentados nos tópicos posteriormente menciona-dos, representam o detalhamento das contribuições desta tese:
1. Formalizar o processo de desenvolvimento com o métodoBSmart, o que engloba:
B[Cle12a]. Observa-se que a representação utilizada tem a vantagem de
documen-tar e verificar o método sem atrelá-lo a um estudo de caso em particular. Desse modo, uma aplicação que pretenda usar o método deve seguir todas as etapas de-monstradas, especificando cada módulo requerido e verificando as suas obrigações de prova.
(b) Desenvolvimento de uma biblioteca de componentes, denominada de KitSmart,
composta por modelos em B das 93 classes/interfaces da API Java Card, dos
ti-posJavaeJava Carde de módulos que especificam tarefas úteis ao desenvolvedor Java Card, mas que não se encontram na API padrão. Além de servir de suporte ao desenvolvimento, fornecendo módulos reutilizáveis, a biblioteca também auxi-lia o processo de verificação do método permitindo a tipagem correta de variáveis para tipos compatíveis com Java Card e a verificação da chamada de métodos de
biblioteca durante os refinamentos.
2. Especificação da tradução do desenvolvimento em B para a aplicação cartão. Esta etapa compreende a descrição da tradução de cada elemento da notação B para o seu correspon-dente na notação da linguagem Java Card. Com os propósitos de documentar a geração
de código e aprimorar o entendimento do processo de tradução, utilizou-se a linguagem ASF+SDF [BKV08] para descrever a gramática de cada linguagem e especificar as re-gras de transformação entre os elementos da notação B para Java Card. É importante
observar que o conjunto de regras não fornecem uma prova da tradução, tendo em vista que, nesse caso, seria necessário a descrição da semântica formal de ambas as linguagens, um processo que requer demasiado esforço, o que extrapolaria o tempo disponível para a conclusão desta tese.
3. Proceder com a reengenharia das ferramentas de suporte ao método. Anteriormente, utilizou-se a ferramenta JBtools[Voi02] para realizar a manipulação de um módulo B.
No entanto, essa solução apresentava falhas devido à instabilidade do seu parsere
veri-ficador de tipos e a intervenções que foram introduzidas no tradutor B que prejudicavam a confiabilidade do desenvolvimento. Além disso, o JBTools é compatível apenas com
a notação clássica da linguagem B, conforme descrito no B-Book [Abr96]. A solução encontrada foi migrar o código para utilizar a API BCompiler[Cle12b], fornecida pela
empresa Clearsy, que também desenvolve o Atelier B, uma das principais ferramentas
para desenvolvimento em B disponíveis no mercado. Dessa forma, conseguiu-se uma solução estável e alinhada à notação do Atelier B.
validar o método e o seu suporte de ferramentas. Optou-se pelo passaporte eletrônico, uma importante aplicação que está em uso atualmente no mundo inteiro para permitir a identificação segura de migrantes nos diversos países que adotam o sistema. Para tanto, utilizou-se como base a documentação oficial fornecida pela ICAO [ICA11] e uma versão código-aberto da aplicação desenvolvida na UniversidadeRadboud[MP10]
1.4 Artigos Publicados
Nesta seção descreve-se os trabalhos que foram publicados, desde o início do estudo, em março de 2008, até o presente momento.
SBES-2008 [MdMJD+08]: A ferramenta Batcave para a verificação formal com o método
B A ferramentaBatcavefoi desenvolvida por um estudante do grupo de métodos formais da
UFRN e tem por objetivo gerar as obrigações de prova de um módulo B em diversas notações. Utilizando essa abordagem, o usuário da ferramenta não fica restrito a um provador específico, de modo que obrigações de prova que poderiam ser trabalhosas de se verificar em um provador, podem ser facilmente verificadas em outra ferramenta. Neste artigo, o autor desta tese colaborou com a integração da ferramenta Batcave à primeira versão do ambiente de desenvolvimento BSmart.
ABZ-2008 [DGM08]: BSmart: a tool for the rigorous development of Smart Card ap-plications Apresentou-se a versão inicial da ferramentaBSmartna sessão de ferramentas da
conferênciaAbstract Machine, B and Z(ABZ).
FM-2009 [Gom09]: Rigorous Development of Smart Card Applications with the B method Este trabalho foi apresentado no simpósio de doutorado da Conferência Mundial de Métodos Formais (Formal Methods2009). Uma comissão formada por importantes pesqui-sadores da área de métodos formais analisou o trabalho e, em conjunto com os demais estu-dantes que participaram do simpósio, teceu interessantes críticas e sugestões que auxiliaram no aprimoramento desta tese.
da bibliotecaKitSmartdesenvolvidos até então, o que compreende as máquinas de tipos, e um
esboço inicial do modelo daAPI Java Card.
1.5 Resumo dos Capítulos
Apresenta-se abaixo um resumo dos capítulos da tese que se seguem a esta introdução.
Capítulo 2: Java Card Este capítulo introduz os componentes do ambiente smart card e a
linguagemJava Card. Ao final, demonstra-se o desenvolvimento de uma aplicaçãoJava
Card simples, porém completa. A aplicação cartão é desenvolvida tanto em Java Card APDU, versão em que se manipulam diretamente os pacotes para troca de dados entre
as aplicações, quanto em Java Card RMI, em que a comunicação é feita por invocação
remota de métodos (RMI). No caso do cliente (aplicação host), utilizou-se a APIsmart
Card I/Opara realizar a comunicação com a aplicação cartão.
Capítulo 3: O Método Formal B Expõe o método B para desenvolvimento formal de aplica-ções. A linguagem B é extensa, sendo assim, neste capítulo introduz-se apenas a notação B que é relevante para a compreensão deste trabalho. Enfatiza-se também os importan-tes conceitos de substituição e obrigação de prova. Na última seção do capítulo, é feita uma pequena introdução ao formalismo Event-Be são discutidos os motivos pelos quais continuou-se a desenvolver o método BSmart em B clássico, ao invés de migrá-lo para Event-B.
Capítulo 4: O Método BSmart Descreve detalhadamente a formalização do processo de de-senvolvimento com o método BSmart, desde a especificação B inicial até o módulo de
implementação. O capítulo demonstra também o suporte de ferramentas ao método.
Capítulo 5: Tradução para Java Card Apresenta a tradução da linguagem da implementação B paraJava Cardutilizando o formalismo ASF+SDF [BKV08]. Inicialmente,
apresenta-se a fundamentação do capítulo, o que compreende a especificação de gramáticas em SDF, com exemplos de trechos da gramática B, assim como o uso de ASF para a transformação de código entre linguagens. Posteriormente, detalham-se o conjunto de regras de reescrita que descrevem a tradução de cada produção da gramática de implementação B para a sua produção correspondente emJava Card.
Capítulo 6: KitSmart Detalha os componentes da bibliotecaKitSmart, que provê módulos B
Capítulo 7: Estudo de Caso O estudo de caso do passaporte eletrônico é descrito neste ca-pítulo. Inicialmente, descreve-se a aplicação e os seus componentes mais importantes (estrutura de dados e protocolos). Posteriormente, a especificação e desenvolvimento da aplicação seguindo o métodoBSmarté detalhada.
Capítulo 8: Trabalhos Relacionados Os trabalhos que estão no escopo do tema da tese são descritos e comparados. São relatados trabalhos em diversas áreas, tais como, verifica-ção, geração de código, políticas de segurança e o estado da arte em ferramentas para desenvolvimento formal desoftware.
2
Java Card
Inicialmente, destaca-se que umsmart card é um dispositivo computacional portátil capaz de executar pequenas aplicações e armazenar informações de forma segura. Fisicamente, um
smart cardconsiste em um pequenochip, geralmente envolto em um revestimento plástico, que
o deixa com a aparência de um cartão de crédito comum. A tecnologiasmart card é
padroni-zada pelaInternational Organization of Standartization (ISO)através do seu padrãoISO 7816
que especifica as características físicas, elétricas, mecânicas, os protocolos para transmissão de dados e comunicação com o cartão, dentre outras.
Ressalta-se que o chip do smart card é composto por um microprocessador e memórias ROM (Read Only Memory),RAM (Random Access Memory)eEEPROM (Electrical Erasable Programmable Read Only Memory) [HNS+02]. A memória ROM é escrita no momento da manufatura do cartão e não pode ser modificada posteriormente. Nesta memória usualmente estão presentes o sistema operacional do cartão e algum aplicativo pré-instalado. A memória
RAM é uma memória volátil utilizada para armazenamento temporário de dados. Por fim, a
memóriaEEPROM é responsável por armazenar dados persistentes, mesmo quando o cartão encontra-se sem alimentação de energia [Che00] [HNS+02].
É importante observar que Java Card [Che00] é uma das principais linguagens utilizadas
para desenvolvimento de aplicações parasmart cards. Java Cardé uma versão restrita e
otimi-zada da plataformaJava, tendo em vista possibilitar que dispositivos com baixa capacidade de
processamento e memória possam armazenar e executar pequenas aplicações. O desenvolvedor que usaJava Cardbeneficia-se de muitas das características deJava, tais quais portabilidade,
linguagem segura quanto a tipos, desenvolvimento orientado a objetos e disponibilidade de fer-ramentas. Todo esse suporte possibilita uma maior rapidez no ciclo de desenvolvimento, teste e instalação de aplicações. Dessa forma, é possível obter melhores ganhos quanto ao custo e ao tempo na produção desoftwareparasmart cards.
Figura 2.1: Componentes da plataforma Java Card. Adaptado de: [Ort03a]
Card (JCVM), uma pequena API e, normalmente, por classes fornecidas pelo fabricante do
cartão [Che00]. OJCREatua como um pequeno sistema operacional, sendo responsável pelo
controle do ciclo de vida da aplicação e de aspectos de segurança e gerenciamento de recursos.
Em virtude das restrições de processamento e armazenamento dos smart cards atuais, a
linguagem e aAPI Java implementada para Java Card são bastante limitadas. Dentre outros
recursos, os tipos de ponto flutuante (float e double) e caractere (char) não estão disponíveis, assim como não há arrays multidimensionais, carga dinâmica de classes e múltiplos fluxos
de execução (threads). Como recursos opcionais, a depender do fabricante do cartão, tem-se a
implementação do tipo inteiro (int) e de coleta de lixo. Os detalhes dos componentes e restrições
da plataformaJava Cardpodem ser encontrados na especificação oficial da tecnologia [Ora11].
Ressalta-se que este capítulo aborda os aspectos da plataforma Java Card relevantes ao
presente trabalho. Inicialmente, na seção 2.1, detalha-se a comunicação entre os componentes do sistemasmart card, com foco no protocoloAPDU. O processo geral de desenvolvimento de
aplicaçõesJava Card é apresentado na seção 2.2. A classeapplet, componente que fornece os
serviços da aplicação, é descrita na seção 2.3. Por fim, a seção 2.4 apresenta a aplicaçãohost
que utiliza os serviços doapplet.
2.1 O Modelo de Comunicação Smart Card
A aplicação smart cardpossui uma arquitetura cliente-servidor, sendo o componente
ser-vidor interno ao cartão, e o cliente, externo. A aplicação serser-vidora, denominadaapplet, provê
os serviços que são requisitados pela aplicação cliente, conhecida na literatura comoaplicação
host, que reside em um computador ou terminal eletrônico. Entre essas duas aplicações há um
dispositivo de hardware, chamado de leitor ou Card Acceptance Device (CAD), responsável
comunicar [Ort03a], o que pode ser feito por contato elétrico (cartões por contato) ou por rádio frequência (cartões sem contato).
A troca de informações entre as aplicações é feita por meio de um protocolo conhecido comoApplication Protocol Data Unit (APDU). A normaISO 7816-4 especifica dois tipos de
APDU’s (figura 2.2), um para que a aplicaçãohost possa requisitar algum serviço do cartão
(comandoAPDU) e outro que é enviado no sentido contrário, do cartão para ohost, contendo o
resultado do processamento do serviço (respostaAPDU).
Destaca-se que um comando APDU é composto por um cabeçalho obrigatório contendo
quatro campos de 1bytecada. O campoCLAidentifica uma classe de instrução (definida pelo
desenvolvedor, para acesso a arquivos, etc.), sendo cada instrução específica dentro de uma classe identificada pelo campoINS(normalmente um serviço oferecido). Os camposP1 eP2
podem ser utilizados opcionalmente para fornecer dados de 1bytecada. Informações adicionais
devem ser fornecidas noarray data (na figura 2.2,data field). Nesse caso, deve-se informar,
no campoLc, o número debytesque serão enviados. De forma semelhante, caso seja esperada alguma informação como resposta, o campoLedeve conter seu tamanho esperado.
A resposta APDU é dividida em um campo datapara se enviar dados na resposta e dois bytes SW1eSW2, que são sempre retornados contendo ostatusdo processamento do comando.
Uma execução sem falhas retorna ostatus 0x9000(SW1=90 e SW2=00). Qualquer outro código
destatusindica que ocorreu uma exceção durante o processamento da requisição.
Figura 2.2: Comando e resposta APDU. Fonte: [Ort03a]
2.2 Desenvolvimento de Aplicações Java Card
Ressalta-se que uma aplicação Java Card pode ser desenvolvida de duas maneiras. Na
primeira, de mais baixo nível, o desenvolvedor tem que lidar diretamente com o aspecto de co-municaçãosmart cardpor meio do protocoloAPDU. Na outra, a comunicação entre a aplicação
hoste oapplet é efetivada através de invocação remota de métodos (RMI), sendo o protocolo APDU abstraído para o desenvolvedor, que tem que lidar apenas com objetos [Ort03b]. Para
Java Card APDUe o segundo deJava Card RMI.
O processo completo de desenvolvimento de uma aplicaçãoJava Card, em suas duas
ver-sões, pode ser dividido em quatro etapas, a saber:
1. Desenvolvimento do applet Java Card e de classes Java Card auxiliares necessárias à
implementação dos serviços.
2. Compilação e teste (simulação/emulação) do código desenvolvido.
3. Conversão doapplete das classes auxiliares no formato apropriado para a instalação em um cartão.
4. Desenvolvimento da aplicaçãohost.
A primeira etapa corresponde ao desenvolvimento da aplicação que será instalada no cartão, denominada deapplet, e de outras classes que ela necessite. O applet é o componente mais
importante de uma aplicaçãoJava Card, uma vez que nele encontra-se implementado todo o
núcleo funcional dessa aplicação. Por este motivo, esta etapa do desenvolvimento será coberta em maior profundidade neste trabalho.
A compilação do applet é feita da mesma maneira que qualquer classe Java. A etapa de
teste é opcional e pode ser feita por meio de simuladores do ambiente de execuçãoJava Card
disponibilizados pela Sun em seu Java Card Development Kit. No kit de desenvolvimento
também encontram-se conversores que empacotam oapplete suas classes em um formato para ser instalado no cartão.
A última etapa do desenvolvimento corresponde à implementação da aplicação host. Um
problema enfrentado pelos desenvolvedores destas aplicações consiste na ampla diversidade de fabricantes de cartões e deCADs, cada um com as suasAPIs proprietárias e complexas, o
que dificulta a criação de aplicações que possam ser utilizadas entre hardware de diferentes
fabricantes sem necessidade de modificação. Com o propósito de contornar esse problema existem APIs como o OpenCard Framework e o PC/SC que permitem que essas aplicações
sejam construídas de forma que a comunicação com oapplet Java Cardseja efetivada de modo
interoperável entre dispositivos de diversos fabricantes.
A seção 2.3 a seguir apresenta o desenvolvimento de aplicações Java Card nas versões
APDU e RMI através de um exemplo de aplicação de bilhetagem eletrônica. Posteriormente, na seção 2.4, detalha-se o desenvolvimento da aplicação cliente.
2.3 O applet Java Card
O applet Java Card é uma subclasse de javacard.framework.Applet implementada sob as
restrições impostas pela especificaçãoJava Card. A conformidade de uma classe com a
especi-ficaçãoJava Cardé verificada apenas durante a conversão doappletantes da sua instalação no
cartão.
Nas versões iniciais da plataforma existia apenas um único meio de se desenvolver um ap-plet, no qual o desenvolvedor lidava diretamente com as estruturas do protocolo APDU. No entanto, a partir da versão 2.2, foi disponibilizado um applet que utiliza a comunicação por
invocação remota de métodos (RMI), abstraindo os detalhes internos dos protocolos. Por intro-duzir uma camada adicional, essa última versão costuma ser menos eficiente e, por este motivo, ainda é menos utilizada que a versãoAPDU.
Nas subseções a seguir os modelos de aplicação APDUeRMI são exemplificados através de uma aplicação de bilhetagem eletrônica. O usuário da aplicação dispõe de uma quantidade de créditos em passagens (atributo balance) que são debitados a cada viagem. Observa-se
que há três tipos de cartão: gratuidade, passagem inteira e estudante, sendo essa informação armazenada no atributo cardType. Foram implementados três métodos de serviço, são eles
addCredit,debitegetCredits. O primeiro adiciona créditos no cartão, o segundo debita o valor
de uma unidade de crédito de um cartão que não seja de gratuidade e o métodogetCreditspode
ser utilizado para consultar o saldo atual do cartão.
2.3.1 Applet APDU
Nas figuras 2.3, 2.4 e 2.5 apresenta-se o código doappletna versão APDU para a aplicação
de bilhetagem eletrônicaTransport. É importante destacar a função de alguns métodos herdados
da classeApplet e que são geralmente implementados na subclasse, são eles, install, process,
select e deselect. Desses, apenas process é de implementação obrigatória, por se tratar de
um método abstrato (abstract). No entanto, o método install, devido a sua importância para
a aplicação, também é normalmente sobrescrito. A introdução dos métodosselect e deselect
execução da aplicação.
O método installé chamado peloJava Card Runtime Environment (JCRE) apenas na
pri-meira vez em que oapplet é executado. Em uma implementação mínima, deve-se criar uma
instância da classeapplete registrá-la junto ao ambiente de execução, através da chamada a um
dos métodos de registro da classeApplet. Apenas uma instância doapplet é registrada, sendo
a gerência dessa instância controlada pelo JCRE. Observa-se que oapplet permanece em um
estado inativo após ser registrado, aguardando até que seja selecionado.
p u b l i c c l a s s T r a n s p o r t A p p l e t e x t e n d s j a v a c a r d . framework . A p p l e t {
s h o r t b a l a n c e ; C a r d s c a r d T y p e ;
p u b l i c s t a t i c f i n a l s h o r t ENTIRE_CARD = (s h o r t) 0 x0 ;
p u b l i c s t a t i c f i n a l b yt e OP_ADD_CREDIT = (by te) 0 x20 ; / / ( . . . )
p r i v a t e T r a n s p o r t A p p l e t (by te[ ] b a r r a y , s h o r t b O f f s e t , by te bLength ) {
super( ) ;
b a l a n c e = (s h o r t) 0 ;
c a r d T y p e . s e t C a r d T y p e ( ENTIRE_CARD ) ; }
p u b l i c s t a t i c vo id i n s t a l l (by te[ ] bArray , s h o r t b O f f s e t , by te bLength ) { T r a n s p o r t A p p l e t t r a n s p o r t = new T r a n s p o r t A p p l e t ( bArray , b O f f s e t , bLength ) ; t r a n s p o r t . r e g i s t e r ( ) ;
}
p u b l i c vo id p r o c e s s (APDU apdu ) throws I S O E x c e p t i o n {
by te b u f f e r [ ] = apdu . g e t B u f f e r ( ) ; / / ( . . . )
s w i t c h ( b u f f e r [ ISO7816 . OFFSET_INS ] ) {
c a s e OP_ADD_CREDIT : a d d C r e d i t ( apdu ) ; break;
c a s e OP_DEBIT : d e b i t ( apdu ) ; break;
c a s e OP_GET_CREDITS : g e t C r e d i t s ( apdu ) ; break;
d e f a u l t: I S O E x c e p t i o n . t h r o w I t ( ISO7816 . SW_INS_NOT_SUPPORTED ) ; }
} / / ( m é t o d o s de s e r v i ç o . . . )
}
Figura 2.3: Umapplet Java Card APDU para bilhetagem eletrônica - definição de atributos e
métodos herdados da classeApplet.
Tendo em vista otimizar o uso da memória e minimizar operações de escrita de dados na memória persistente, é desejável que os objetos utilizados peloapplet sejam instanciados em
seu construtor ou no métodoinstalldiretamente. Uma vez que cada novo objeto ouarray
instan-ciado é salvo na memória persistente do cartão, a sua criação através do métodoinstallgarante
que essa operação será efetuada apenas uma vez, sendo o estado desses atributos recuperado em utilizações subsequentes. Outra boa prática é o uso de atributos transientes quando não houver a necessidade da persistência de determinado objeto ouarray. Um objeto transiente é criado
atra-vés de um dos métodosmakeTransientArrayda classejavacard.framework.JCSystem[Che00].
O métodoselecté chamado sempre que umappleté requisitado para ser selecionado (apdu SELECT FILE). A implementação padrão fornecida pela classeAppletretornatrue, dessa forma
ou não a seleção. Por sua vez, o métododeselect do applet selecionado (caso haja algum) é
chamado sempre que um novoappletrequisita ao JCRE a sua seleção. Dessa forma, ele pode
ser utilizado para alguma operação de limpeza de memória ou de alteração do estado de algum atributo antes que oappletem execução seja retirado de seleção.
Uma vez selecionado, o applet encontra-se pronto para receber as requisições aos seus
serviços através do seu métodoprocess. Ele recebe do JCRE um objeto APDU, o que permite o
acesso aobuffer APDU, umarraydebytescontendo os campos do comando que foram enviados
na requisição pela aplicaçãohost. Cada elemento doarraycontém a informação de um campo
específico do comando APDU, sendo o índice desses campos no array facilmente acessado
através de constantes presentes na interfacejavacard.framework.ISO7816. Observa-se que, por
meio da instrução (INS) dobuffer, a requisição é direcionada ao serviço apropriado, que obtém
os dados necessários para a sua execução diretamente dos camposp1,p2 oudatacontidos no
array.
Os métodos de serviço do applet são específicos de cada aplicação. É importante obser-var que os serviços que necessitam acessar os campos do comando APDU devem fazer uma
chamada ao métodogetBuffer dejavacard.framework.APDUpara obter oarray buffer.
Um método que recebe algum dado encapsulado no campodatado comandoAPDU deve
invocar o métodosetIncomingAndReceivepara que oJCREtorne esse dado adicional acessível
através dobuffer APDUrecebido. O número debytesrecebidos é retornado pelo método
setIn-comingAndReceivee pode ser usado para verificar se esse número é igual ao número debytes
que se esperava receber. Como exemplo, na figura 2.4, tem-se a implementação do método
addCredit, que deve receber a informação da quantidade de créditos que serão adicionados ao
cartão.
p u b l i c voi d a d d C r e d i t (APDU apdu ) {
by te[ ] b u f f e r = apdu . g e t B u f f e r ( ) ;
s h o r t c r = (s h o r t) U t i l . makeShort ( (by te) b u f f e r [ ISO7816 . OFFSET_P1 ] , (by te) b u f f e r [ ISO7816 . OFFSET_P2 ] ) ;
s h o r t sum = (s h o r t) ( b a l a n c e + c r ) ;
s h o r t c t = (s h o r t) c a r d T y p e . g e t C a r d T y p e ( ) ;
i f ( ! ( c t != GRATUITOUS_CARD ) ) {
I S O E x c e p t i o n . t h r o w I t ( EXCEPTIONS . CARD_TYPE_INVALID ) ; } e l s e i f ( ! ( sum <= 3 2 7 6 7 ) ) {
I S O E x c e p t i o n . t h r o w I t ( EXCEPTIONS . BALANCE_EXCEEDED ) ; } e l s e i f ( ! ( c r > 0 ) ) {
I S O E x c e p t i o n . t h r o w I t ( EXCEPTIONS . NEGATIVE_CREDIT ) ; } e l s e {
b a l a n c e = sum ; }
}
Caso um método precise enviar alguma informação para a aplicaçãohostele deve,
inicial-mente, invocar o métodosetOutgoing, responsável por notificar oJCRE que algo será enviado
no campodatada respostaAPDU. O métodosetOutgoingtambém retorna o tamanho do dado que a aplicaçãohostespera receber. Posteriormente, o métodosetOutgoingLengthdeve ser
cha-mado para informar o número debytesa serem enviados. Por fim, deve-se inserir a informação
nobuffer apdu. No métodogetCreditsdo exemplo (figura 2.5), a variável contendo a
informa-ção da quantidade de créditos restantes no cartão é inserida nobuffer apduatravés do método
setShort, da classe javacard.framework.Util. Finalmente, através da chamada a sendBytes, a
resposta é enviada.
p u b l i c voi d g e t C r e d i t s (APDU apdu ) {
by te[ ] b u f f e r = apdu . g e t B u f f e r ( ) ;
s h o r t r e s = amount . g e t S h o r t V a l u e ( ) ;
s h o r t l e = apdu . s e t O u t g o i n g ( ) ; apdu . s e t O u t g o i n g L e n g t h ( (s h o r t) 2 ) ;
U t i l . s e t S h o r t ( b u f f e r , (s h o r t) 0 , (s h o r t) r e s ) ; apdu . s e n d B y t e s ( (s h o r t) 0 , (s h o r t) 2 ) ;
}
Figura 2.5: Método de serviçogetCreditsdoapplet Transport.
2.3.2 Applet RMI
Destaca-se que aAPI Java Cardpara Invocação Remota de Métodos (RMI) foi introduzida
somente na especificaçãoJava Card 2.2, consistindo em um subconjunto daAPI RMI deJava
e classesRMI específicas paraJava Card.
No modelo RMI, a aplicação servidora (oapplet Java Card) cria e torna acessíveis objetos
que podem ser acessados remotamente através de uma interface pública. A aplicação cliente pode obter as referências a esses objetos e então invocar os seus métodos [Ort03b].
O desenvolvimento de umapplet Java Card RMIcompreende a especificação dos serviços
providos pela aplicação remota como uma interfaceJava, a implementação dessa interface e o
desenvolvimento doapplet(subclasse deApplet) e demais classes auxiliares.
A interface remota (figura 2.6) especifica os serviços que serão fornecidos peloappletpara
a aplicação host. Para tanto, ela deve estender a interface java.rmi.Remote. Observa-se que
os métodos da interface remota são exatamente os mesmos encontrados no applet APDU. A diferença é que, agora, esses não serão mais implementados dentro da classe applet e que a
sua assinatura foi modificada para incluir o lançamento de exceções. A RemoteException é
quando da execução de uma chamada remota de método. Já a especificação daUserException
foi incluída para que se possa reportar os erros específicos da lógica de negócio da aplicação.
p u b l i c i n t e r f a c e T r a n s p o r t R e m o t e I n t e r f a c e e x t e n d s Remote {
p u b l i c vo id a d d C r e d i t (s h o r t c r ) throws RemoteException , U s e r E x c e p t i o n ;
p u b l i c vo id d e b i t ( ) throws RemoteException , U s e r E x c e p t i o n ;
p u b l i c s h o r t g e t C r e d i t s ( ) throws RemoteException , U s e r E x c e p t i o n ; }
Figura 2.6: Interface remota do Applet RMI
A implementação dos métodos da interface remota é feita pela classe TransportRemoteIm-plementation(figura 2.7), subclasse dejavacard.framework.service.CardRemoteObject. Herdar
deCardRemoteObjecttem o efeito de exportar automaticamente o objeto remoto, possibilitando
o acesso a ele e aos seus métodos pela aplicaçãohost.
p u b l i c c l a s s T r a n s p o r t R e m o t e I m p l e m e n t a t i o n
e x t e n d s C ar dR em ot eO bj ec t implements T r a n s p o r t R e m o t e I n t e r f a c e {
p r i v a t e s h o r t b a l a n c e ; C a r d s c a r d T y p e ;
/ / ( . . . )
p u b l i c vo id a d d C r e d i t (s h o r t c r ) throws RemoteException , U s e r E x c e p t i o n {
s h o r t c t = (s h o r t) c a r d T y p e . g e t C a r d T y p e ( ) ;
i f ( ! ( c t != GRATUITOUS_CARD ) ) {
U s e r E x c e p t i o n . t h r o w I t ( EXCEPTIONS . CARD_TYPE_INVALID ) ; } e l s e i f ( ! ( sum <= 3 2 7 6 7 ) ) {
U s e r E x c e p t i o n . t h r o w I t ( EXCEPTIONS . BALANCE_EXCEEDED ) ; } e l s e i f ( ! ( c r > 0 ) ) {
U s e r E x c e p t i o n . t h r o w I t ( EXCEPTIONS . NEGATIVE_CREDIT ) ; } e l s e {
b a l a n c e = (s h o r t) ( b a l a n c e + c r ) ; }
}
/ / ( . . . )
p u b l i c s h o r t g e t C r e d i t s ( ) throws RemoteException , U s e r E x c e p t i o n {
r e t u r n b a l a n c e ; }
}
Figura 2.7: Implementação dos serviços do applet RMI
Por fim, a figura 2.8 apresenta o código do applet Java Card na versãoRMI. A estrutura
doapplet não é modificada com relação ao APDU. A principal diferença é a instanciação de
classes específicas para implementação da comunicação porRMI. A classe Dispatcher regis-tra um serviço remoto e encaminha todo comandoAPDU para a classe de serviço registrada.
Neste caso, temos a classe de serviçoRMIService, que então recebe esteAPDUe o traduz em
p u b l i c c l a s s T r a n s p o r t A p p l e t e x t e n d s j a v a c a r d . framework . A p p l e t {
p r i v a t e D i s p a t c h e r d i s p a t c h e r ;
p r i v a t e R e m o t e S e r v i c e s e r v i c e ;
p r i v a t e Remote r e m o t e I m p l ;
p r i v a t e T r a n s p o r t A p p l e t (by te[ ] bArray , s h o r t b O f f s e t , by te bLength ) {
super( ) ;
r e m o t e I m p l = new T r a n s p o r t R e m o t e I m p l e m e n t a t i o n ( ) ; s e r v i c e = new RMIService ( r e m o t e I m p l ) ;
d i s p a t c h e r = new D i s p a t c h e r ( (s h o r t) 1 ) ;
d i s p a t c h e r . a d d S e r v i c e ( s e r v i c e , D i s p a t c h e r .PROCESS_COMMAND ) ; }
p u b l i c s t a t i c vo id i n s t a l l (by te[ ] bArray , s h o r t b O f f s e t , by te bLength ) { T r a n s p o r t A p p l e t t r a n s p o r t = new T r a n s p o r t A p p l e t ( bArray , b O f f s e t , bLength ) ; t r a n s p o r t . r e g i s t e r ( ) ;
}
p u b l i c vo id p r o c e s s (APDU apdu ) throws I S O E x c e p t i o n { d i s p a t c h e r . p r o c e s s ( apdu ) ;
} }
Figura 2.8: Implementação da classe applet na versão RMI
2.4 Aplicação Host
A compatibilidade entre um applet Java Carde um cartão será obtida desde que o applet
seja implementado de acordo com a versão da plataforma suportada pelo cartão. Todavia, a ampla interoperabilidade entre aplicaçõesJava Card será alcançada apenas se todo o sistema smart cardfor compatível, incluindo cartões, leitores (CAD), protocolos e aplicaçãohost. Nesse
sentido, surgiram algumas iniciativas formadas pela associação de fabricantes e interessados no mercadosmart card, tais como aPS/SC[PC/09] e aGlobal Platform[Glo09].
O grupo PC/SC, composto por empresas comoMicrosoft, IBM, HP, Gemplus, dentre
ou-tras, possui interesse na compatibilidade dohardware smart cardcom computadores pessoais.
Por sua vez,Global Platform é uma iniciativa da empresaVisa, com o objetivo de prover
so-luções seguras e interoperáveis para cartões smart card com múltiplas aplicações e terminais eletrônicos de pagamento [HNS+02]. Do ponto de vista do desenvolvedor, ambas as platafor-mas são soluções completas para inicializar os leitores e cartões e para gerenciar a comunicação por meio do protocoloAPDU, levando em consideração aspectos de segurança para o sistema
como um todo.
AAPI Smart Card I/OdoJava6 foi uma contribuição recente para permitir o
desenvolvi-mento de uma aplicaçãohostsimples, mas que atende à necessidade da maioria das aplicações e
é compatível com leitores (CAD)PS/SC. Na Figura 2.9, tem-se um exemplo de aplicaçãohost,
1 p u b l i c c l a s s T r a n s p o r t H o s t {
2 p r i v a t e s t a t i c CommandAPDU SELECT_APDU =
3 new CommandAPDU( 0 x00 , 0 xa4 , 0x04 , 0x00 , / / T r a n s p o r t AID :
4 new by te[ ] { (by te) 0 x0A , (by te) 0X0B , (by te) 0X0C , 5 (by te) 0X0D , (by te) 0 X0E , (by te) 0 X1F } ) ; 6 p u b l i c s t a t i c vo id main ( ) {
7 T e r m i n a l F a c t o r y f a c t o r y = T e r m i n a l F a c t o r y . g e t D e f a u l t ( ) ; 8 L i s t < C a r d T e r m i n a l > t e r m i n a l s ;
9
10 t r y {
11 t e r m i n a l s = f a c t o r y . t e r m i n a l s ( ) . l i s t ( ) ;
12 System . o u t . p r i n t l n ( " T e r m i n a l s a v a i l a b l e : " + t e r m i n a l s ) ; 13 C a r d T e r m i n a l t e r m i n a l = t e r m i n a l s . g e t ( 0 ) ;
14
15 / / e s t a b l i s h a c o n n e c t i o n w i t h t h e c a r d
16 Card c a r d = t e r m i n a l . c o n n e c t ( "T=0 " ) ; 17 System . o u t . p r i n t l n ( " c a r d : " + c a r d ) ;
18 C ardC hann el c h a n n e l = c a r d . g e t B a s i c C h a n n e l ( ) ; 19
20 / / e n v i a o APDU SELECT p a r a s e l e c i o n a r o a p p l e t T r a n s p o r t .
21 ResponseAPDU r a = c h a n n e l . t r a n s m i t (SELECT_APDU ) ;
22 / / E n v i a comando apdu p a r a chamar o s e r v i ç o g e t C r e d i t s : CLA , INS , P1 , P2 , LE
23 CommandAPDU g e t _ c r _ c m d = new CommandAPDU( 0 x80 , 0x50 , 0 , 0 , 2 ) ;
24 ResponseAPDU r e s p = c h a n n e l . t r a n s m i t ( g e t _ c r _ c m d ) ; 25
26 System . o u t . p r i n t l n ( " Q u a n t i d a d e de c r é d i t o s : " + arrayToHex ( r e s p . g e t B y t e s ( ) ) ) ; 27 c a r d . d i s c o n n e c t (f a l s e) ;
28 } c a t c h ( C a r d E x c e p t i o n e ) { 29 e . p r i n t S t a c k T r a c e ( ) ;
30 }
31 }
32 }
Figura 2.9: Um exemplo simples de aplicaçãohostpara oapplet Transport.
O primeiro passo em direção à comunicação com a aplicação cartão é obter a referência do leitor onde o cartão está inserido (linhas 11-13). Para tanto, deve-se utilizar a classe Terminal-Factoryque busca e retorna a lista dos leitores conectados ao terminal eletrônico ou computador.
A partir da lista obteve-se a referência para o primeiro leitor conectado (terminals.get(0)).
O segundo passo consiste em estabelecer a conexão com o cartão através do método con-nectda referência ao leitor (linha 16). Esse método necessita da informação do protocolo de
transporte (T=0 ou T=1) que o cartão utiliza. Uma vez conectado ao cartão, deve-se obter um canal de comunicação com ele, pela chamada ao métodocard.getBasicChanneldo objeto que
representa o cartão (linha 18). A partir daí, é possível enviar e receber comandosAPDU.
Um comando APDU pode então ser criado utilizando-se um dos construtores da classe CommandAPDU. Inicialmente, enviou-se um comandoAPDU select para selecionar o applet Transport(linha 21). Para tanto, utilizou-se o métodotransmitda classeCardChannel,
respon-sável por enviar o comando e retornar um objeto do tipoResponseAPDUcontendo o resultado
do processamento do comando. O segundo comando enviado correponde à chamada ao serviço
getCredits(linha 23). Uma vez que getCreditsretorna dados na resposta (a quantidade de
umarraydebytescontendo essa informação (linha 26).
O exemplo simplificado de aplicaçãohost acima demonstra os requisitos mínimos para se
comunicar com oappletpor meio da API Smart Card I/O. Entretanto, como pode-se perceber,
nessa aplicação o código de lógica de negócio encontra-se entrelaçado com o código para co-municação de baixo-nível com o cartão. No capítulo 4 apresenta-se uma abordagem para gerar a aplicaçãohost a partir daAPI da sua especificação formal que abstrai para o desenvolvedor
todos os aspectos de comunicação de baixo nível.
Neste capítulo apresentou-se a plataforma Java Card para desenvolvimento de aplicações
parasmart cards. Foram descritos os componentes básicos do sistema smart carde a
lingua-gem Java Card. O capítulo concentrou-se no desenvolvimento da aplicação, uma vez que o objetivo maior do trabalho é possibilitar o desenvolvimento dessas aplicações através de uma especialização do método formal B. O próximo capítulo fornece uma visão geral do método formal B, com ênfase na sua aplicação ao desenvolvimento desoftware, desde a especificação
