Post on 08-Nov-2018
DEPARTAMENTO DE ELECTRÓNICA E TELECOMUNICAÇÕES
Relatório final de projecto
Sistema de informação clínica e genética
suportada num cartão inteligente (JavaCard)
Autores: -Fernando Mostardinha, 16669 -Sandra Silva, 14285 Orientador: Prof. Doutor Carlos Costa Colaborador: Prof. Doutor José Luís Oliveira
Universidade de Aveiro, 15 de Julho de 2005
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 ii Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 iii Fernando Mostardinha * Sandra Silva
Agradecimentos (I)
Que se saiba, jamais alguma obra foi elaborada sem que o autor tivesse sido influenciado, ajudado, apoiado por alguém ou por algo... Como tal, de um modo muito resumido venho por este meio agradecer, enaltecer e reconhecer a algumas daquelas pessoas que de um modo ou de outro me marcaram e ajudaram, quando mais não seja pela sua paciência e compreensão, a concluir este documento e este circulo da minha vida, que teimosamente resistia a fechar, o curso. Enfim, levar o “Barco a bom porto” sem nunca perder de vista “Farol” que nos ilumina para a vida!
Não podia deixar de agradecer aos orientadores, Prof. Doutor Carlos Costa e Prof. Doutor José Luís Oliveira, por todo o incentivo e motivação dada ao longo deste projecto. Ao pessoal da melhor sala de projecto do DET, a “234” em geral, por todo o apoio, incentivo e pelo excelente ambiente que ajudaram a criar. Dentro da “234” um grande abraço para eles e um agradecimento especial para o grupo dos “5+1”, por toda a amizade, apoio, camaradagem e acima de tudo pela paciência demonstrada ao longo deste excelente ano lectivo de 2004/05. Tenho esperança que continuemos todos bons amigos… À minha colega de projecto... Trabalhar contigo fez-me pensar muitas vezes... e evoluir como homem e futuro profissional… Aos meus pais, um grande reconhecimento e admiração, pois demonstraram ser (e são!!!), muito mais do que uns bons pais, foram e serão os melhores amigos... Quero agradecer também ao meu avô “Alfredo”, Manuel Simões Mostardinha, pela sua amizade, inteligência e visão “futurista” que em muito influenciou a minha família... Aos meus irmãos, por serem como são... e a todas as outras pessoas que contribuíram directa ou indirectamente para que este círculo se feche e acima de tudo me ajudaram evoluir em todos os aspectos, quer como homem, quer como profissional… Quero agradecer também a uma pessoa muito especial, que foi uma boa influência para mim e que me ensinou a ficar mais tempo sentado para estudar, um sentimento sempre presente. Não há palavras suficientes para exprimir certas coisas que sentimos, apenas um obrigado por existires, por seres como és… Neste momento novos ventos se levantam, novos desafios se preparam, novas barreiras se avistam… levanto âncora, iço as velas e parto rumo à vida!..
Fernando A. M. Mostardinha
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 iv Fernando Mostardinha * Sandra Silva
Agradecimentos (II)
Quero agradecer àqueles que sempre acreditaram em mim e que sempre me apoiaram em tudo o que fiz. Que estiveram sempre ao meu lado, nos bons e nos maus momentos da minha vida. Mesmo durante os anos em que estivemos em continentes diferentes e milhares de quilómetros nos separavam, houve sempre uma palavra de conforto, de carinho e de coragem. Ainda hoje, com um deles ainda distante, a mesma força e a mesma mensagem de encorajamento. Aos pais, o meu maior agradecimento! Ao meu namorado, por toda a coragem que me deu e continua a dar durante estes anos. Por acreditar em mim, e sempre me apoiar. Por nunca deixar que a minha coragem e a minha força esmorecesse, mesmo quando tal parecia ser quase impossível. Por tudo, um enorme agradecimento! Aos meus amigos que me acompanharam durante estes anos, e que sempre me apoiaram. Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 v Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 vi Fernando Mostardinha * Sandra Silva
Índice geral
Índice geral
Agradecimentos (I) ____________________________________________________ iii
Agradecimentos (II)____________________________________________________ iv
Índice geral __________________________________________________________ vi
Índice figuras_________________________________________________________ ix
Índice tabelas _________________________________________________________ xi
Lista de acrónimos____________________________________________________ xii
Capítulo 1____________________________________________________________ 1 1.1 Introdução _________________________________________________________ 1 1.2 Objectivos:_________________________________________________________ 2
Capítulo 2____________________________________________________________ 3
2 Ferramentas Tecnológicas:__________________________________________ 3 2.1 ECLIPSE __________________________________________________________ 3
2.1.1 O Eclipse _______________________________________________________________3 2.1.2 Eclipse, o código aberto, open source _________________________________________4 2.1.3 Consórcio Eclipse ________________________________________________________5 2.1.4 Aspectos Técnicos da Plataforma Eclipse ______________________________________6 2.1.5 Componentes ____________________________________________________________7 2.1.6 Plataforma Runtime _______________________________________________________7 2.1.7 Workspace ______________________________________________________________7 2.1.8 Suporte de equipa ________________________________________________________8 2.1.9 Editor de texto ___________________________________________________________9 2.1.10 Fácil depuração com sugestões – Quick Fix suggestions ________________________9 2.1.11 Consola _____________________________________________________________10 2.1.12 Criação de uma classe no Eclipse_________________________________________10 2.1.13 Jigloo GUI Builder ____________________________________________________11
2.2 Cyberflex Access SDK 4.2 ___________________________________________ 14 2.3 OpenCard Framework ______________________________________________ 29
Capítulo 3___________________________________________________________ 32
3 SmartCard ______________________________________________________ 32 3.1 Introdução ________________________________________________________ 32 3.2 História do SmartCard______________________________________________ 34 3.3 Pontos de contacto de um Smart Card _________________________________ 34 3.4 Sistema operativo do Smart Card _____________________________________ 35
3.4.1 Sistemas Operativos do Smart Card no mercado _______________________________36
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 vii Fernando Mostardinha * Sandra Silva
3.5 Tipos de Smart Card _______________________________________________ 37 3.6 Segurança num Smart Card _________________________________________ 37
3.6.1 Princípios em segurança __________________________________________________38 3.6.1.1 Privacidade________________________________________________________38 3.6.1.2 Criptografia Simétrica _______________________________________________38 3.6.1.3 Criptografia Assimétrica _____________________________________________40
3.6.2 Integridade_____________________________________________________________42 3.6.2.1 Autentificação do código da mensagem__________________________________42
3.6.3 Não repúdio (Non-Repudiation) ____________________________________________42 3.6.3.1 Assinatura Digital __________________________________________________43
3.6.4 Autenticação ___________________________________________________________43 3.6.4.1 Certificados _______________________________________________________43
3.6.5 Verificação ____________________________________________________________44 3.6.5.1 Códigos de Identificação Pessoal (PIN)__________________________________45 3.6.5.2 Biometria _________________________________________________________46
3.7 Leitores / Terminais para Smart Card _________________________________ 49 3.8 Desenvolvimento de ferramentas para Smart Card ______________________ 51 3.9 Gestão do Smart Card ______________________________________________ 51 3.10 Alguns exemplos de aplicações para projectos Smart Card ________________ 52 3.11 Futuro dos Smart Cards_____________________________________________ 54 3.12 PC/SC____________________________________________________________ 56
3.12.1 Interface de Migração PC/SC ____________________________________________56 3.13 Comunicação Smart Card ___________________________________________ 57
3.13.1 Modelo de Comunicação Smart Card ______________________________________57 3.14 Protocolo APDU ___________________________________________________ 58
3.14.1 Comando APDU______________________________________________________59 U
3.14.2 Resposta APDU ______________________________________________________61 3.14.3 Processando APDUs___________________________________________________62
3.15 Limitações da linguagem Java Card___________________________________ 63 Capítulo 4___________________________________________________________ 64
4 JavaCard _______________________________________________________ 64 4.1 Arquitectura de um Javacard ________________________________________ 65 4.2 Características de segurança de um Java Card __________________________ 68 4.3 Máquina Virtual Javacard (JCVM) ___________________________________ 69
4.3.1 Ficheiros CAP e ficheiros de Exportação _____________________________________70 4.3.2 Conversor Javacard ______________________________________________________71 4.3.3 Descodificador/leitor Javacard _____________________________________________71
4.4 Instalador JavaCard e programa interface do instalador do cartão _________ 72 4.5 Java Card Runtime Environment _____________________________________ 72 4.6 Características do Java Card Runtime (JCRE)__________________________ 76 4.7 Java Card API_____________________________________________________ 77 4.8 Java Card Applets _________________________________________________ 79 4.9 Convenção de nomes para pacotes e aplicações __________________________ 80 4.10 Processo de desenvolvimento de uma applet ____________________________ 80 4.11 Limitações e problemas _____________________________________________ 81
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 viii Fernando Mostardinha * Sandra Silva
4.12 Rivais e futuro do JavaCard _________________________________________ 83 4.13 Conclusões ________________________________________________________ 84
Capítulo 5___________________________________________________________ 86
5 Protótipo desenvolvido_____________________________________________ 86 5.1 Introdução ________________________________________________________ 86 5.2 Início da aplicação, dos conceitos aprendidos e estudo do software disponível 86 o GET BALANCE APDU ____________________________________________________88 o DEBIT APDU ____________________________________________________________89
5.3 Estudo da plataforma Open Card Framework (OCF) ____________________ 90 5.4 Desenvolvimento da aplicação gestora dos dados administrativos do paciente 95
5.4.1 Desenvolvimento da aplicação do cartão _____________________________________96 5.4.2 Desenvolvimento da interface gráfica ________________________________________99 5.4.3 Desenvolvimento da interligação entre a aplicação do cartão e interface gráfica ______101
5.5 Desenvolvimento da aplicação gestora da informação clínica do paciente ___ 101 5.5.1 Desenvolvimento da aplicação do cartão ____________________________________101 5.5.2 Desenvolvimento da interface gráfica _______________________________________116
5.6 Conclusões _______________________________________________________ 116 Capítulo 6__________________________________________________________ 118
6 Conclusões _____________________________________________________ 118
Referências ______________________________________________________ 120
Anexos ____________________________________________________________ 122
Anexo 1 ___________________________________________________________ 122
Anexo 2 ___________________________________________________________ 125
Anexo 3 ___________________________________________________________ 130
Anexo 4 ___________________________________________________________ 134
Anexo 5 ___________________________________________________________ 141
Anexo 6 ___________________________________________________________ 151
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 ix Fernando Mostardinha * Sandra Silva
Índice figuras
Índice figuras Figura 2.1: Componentes principais e APIs da plataforma Eclipse ______________________________7 Figura 2.2: Workbench do Eclipse _______________________________________________________8 Figura 2.3: Editor de texto _____________________________________________________________9 Figura 2.4: Quick Fix _________________________________________________________________9 Figura 2.5: Consola _________________________________________________________________10 Figura 2.6: Criação de uma classe no Eclipse _____________________________________________11 Figura 2.7: Jigloo, plugin gráfico do Eclipse ______________________________________________13 Figura 2.8: Aspecto do programa Cyberflex Access Toolkit 4.3________________________________14 Figura 2.9: Informação de que o cartão Java Card foi inserido no reader _______________________15 Figura 2.10: Informação acerca do cartão inserido_________________________________________15 Figura 2.11: Estabelecimento de um canal seguro __________________________________________16 Figura 2.12: Escolha das chaves específicas do cartão utilizado_______________________________16 Figura 2.13: Introdução das chaves e estabelecimento do canal seguro _________________________17 Figura 2.14: Mensagem de informação que o canal foi estabelecido____________________________17 Figura 2.15: Visualização do conteúdo do cartão __________________________________________18 Figura 2.16: Passos principais para converter o código fonte numa aplicação [4] ________________18 Figura 2.17: Conversão do ficheiro class num program file __________________________________19 Figura 2.18: Adição do program file como um load file______________________________________19 Figura 2.19: Criação do load file _______________________________________________________20 Figura 2.20: Informação de que o programa foi carregado com sucesso ________________________20 Figura 2.21: Visualização do load file já carregado na pasta Load Files and Libraries_____________21 Figura 2.22: Início da instanciação da applet _____________________________________________21 Figura 2.23: Criação da instância ______________________________________________________22 Figura 2.24: Instância criada com sucesso________________________________________________22 Figura 2.25: Selecção da aplicação _____________________________________________________23 Figura 2.26: A aplicação seleccionada___________________________________________________23 Figura 2.27: APDU Manager __________________________________________________________24 Figura 2.28: Envio do comando getBalance_______________________________________________24 Figura 2.29: Envio do comando APDU __________________________________________________25 Figura 2.30: Resposta do comando______________________________________________________26 Figura 2.31: Janela de comunicações respectiva ao reader___________________________________26 Figura 2.32: Envio do comando Debit ___________________________________________________27 Figura 2.33: Resposta do comando______________________________________________________27 Figura 2.34: Nova consulta do saldo do cartão ____________________________________________28 Figura 3.1: Contacto de Smart Card [5.2]________________________________________________32 Figura 3.2: Smart Card sem fios (contactless) _____________________________________________33 Figura 3.3: Cartão Smart Card_________________________________________________________35 Figura 3.4: Pontos de contacto de um Smart Card__________________________________________35 Figura 3.5: Pontos de contacto do Cartão Inteligente (Smart Card) ____________________________35 Figura 3.6: Encriptação simétrica usando DES ____________________________________________39 Figura 3.7: Encriptação Simétrica usando o Triplo-DES_____________________________________40 Figura 3.8: Encriptação Assimétrica ____________________________________________________41 Figura 3.9: Atribuição da Assinatura Digital e Verificação___________________________________43 Figura 3.10: Terminal Smart Card com reconhecimento de impressão digital ____________________46 Figura 3.11 - Comparação dos diversos factores dos vários métodos de identificação tradicionais e biométricos ________________________________________________________________________48 Figura 3.12: Leitor Smart Card convencional ps/2 (à esquerda) e USB (à direita)_________________50 Figura 3.13: Interfaces de migração PC/SC vs PC/SC_______________________________________57
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 x Fernando Mostardinha * Sandra Silva
Figura 3.14: Comunicação através de APDU _____________________________________________58 U
Figura 3.15: Modelo de comunicação do Smart Card _______________________________________58 Figura 3.16: Modelo Comando-Resposta _________________________________________________58 Figura 3.17: Estrutura do Comando APDU _______________________________________________59 Figura 3.18: Valores CLA ISO 7816_____________________________________________________59 Figura 3.19: Valores ISO 7816-4 INS quando CLA = 0X_____________________________________60 Figura 3.20: Quatro possíveis estruturas do Comando APDU_________________________________61 U
Figura 3.21: Códigos de Resposta Status _________________________________________________62 Figura 3.22: Quatro possíveis estruturas do Comando APDU [9]______________________________62 Figura 3.23: Selecção do método _______________________________________________________63 Figura 4.1: Plataforma Global da Arquitectura de um cartão [5.1] ____________________________66 Figura 4.2: Arquitectura do sistema Java Card ____________________________________________67 Figura 4.3: Criação de uma aplicação __________________________________________________70 Figura 4.4: Conversão de um pacote ____________________________________________________71 Figura 4.5: Instalador JavaCard e programa de interface ao cartão [2] ________________________72 Figura 4.6: Arquitectura no cartão______________________________________________________73 Figura 4.7: A comunicação entre um applet e o host executado através de APDUs ________________73 Figura 4.8: Arquitectura Java Card e Runtime Environment [5.2] _____________________________75 Figura 4.9: Applet Firewall e partilha de objectos [5.2] _____________________________________77 Figura 4.10: Java Card Applet Life-Cycle Methods _________________________________________79 Figura 4.11: Identificador de aplicação __________________________________________________80 Figura 4.12: Processo de desenvolvimento de uma applet ____________________________________81 Figura 4.13: MULTOS, o principal rival do JavaCard e que deu origem ao Mondex, etc. ___________83 Figura 4.14: Arquitectura MULTUS_____________________________________________________83 Figura 4.15: Características técnicas do MUTUS __________________________________________83 Figura 5.1: Dados administrativos ______________________________________________________99 Figura 5.2: Interface da área clínica e administrativa final___________________________________99 Figura 5.3: Modelo de criação de apontadores ___________________________________________100 Figura 5.4: Estrutura de codificação do tipo BER-TLV _____________________________________103 Figura 5.5: Código TLV de um Apontador _______________________________________________104 Figura 5.6: Fluxograma do comando LINK ADD REQUEST ________________________________106 Figura 5.7: Fluxograma do comando ADD LINK _________________________________________108 Figura 5.8: Fluxograma do comando GET LINKS ID ______________________________________110 Figura 5.9: Fluxograma do comando GET LINK SIZE _____________________________________112 Figura 5.10: Fluxograma do comando GET LINK _________________________________________114 Figura 5.11: Adição de um Apontador __________________________________________________116
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 xi Fernando Mostardinha * Sandra Silva
Índice tabelas
Índice tabelas Tabela 3.1: Resposta APDU ___________________________________________________________61 Tabela 3.2: Sumário das limitações da linguagem Java Card _________________________________63 Tabela 4.1: Sumário das restrições do Java Card VM _______________________________________70 Tabela 4.2: Java Card v2.2 javacard.framework ___________________________________________78 Tabela 4.3: javacard.framework.service__________________________________________________78 Tabela 4.4: javacard.security __________________________________________________________78 Tabela 5.1: Comando APDU definido ___________________________________________________88 Tabela 5.2: Response APDU definido____________________________________________________89 Tabela 5.3: Comando APDU definido para o comando DEBIT ________________________________89 Tabela 5.4: Response APDU definido para o comando DEBIT ________________________________90 Tabela 5.5: Comando do APDU definido para o comando GET _______________________________96 Tabela 5.6: Response APDU definido para o comando GET __________________________________97 Tabela 5.7: Comando APDU definido para o comando SET __________________________________97 Tabela 5.8: Response APDU definido para o comando SET __________________________________98 Tabela 5.9: Estrutura de dados dos apontadores __________________________________________102 Tabela 5.10: Tabela de Interpretação da informação do apontador da Figura 5.4 ________________104 Tabela 5.11: Comando APDU definido para o comando LINK ADD REQUEST _________________106 Tabela 5.12: Response APDU definido para o comando LINK ADD REQUEST__________________107 Tabela 5.13: Comando APDU definido para o comando ADD LINK __________________________109 Tabela 5.14:Response APDU definido para o comando ADD LINK ___________________________109 Tabela 5.15: Comando APDU definido para o comando GET LINKS ID _______________________110 Tabela 5.16: Response APDU definido para o comando GET LINKS ID _______________________111 Tabela 5.17:Comando APDU definido para o comando GET LINK SIZE _______________________112 Tabela 5.18: Response APDU definido para o comando GET LINK SIZE_______________________113 Tabela 5.19: Comando APDU definido para o comando GET LINK ___________________________115 Tabela 5.20: Response APDU definido para o comando GET LINK ___________________________115
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 xii Fernando Mostardinha * Sandra Silva
Lista de acrónimos
AID Application IDentifier
ANSI American National Standards Institute
APDU Application Programming Data Unit
API Aplication Programmer’s InterfaceCAD Card Acceptance Device
ATM Asynchronous Transfer Mode
CAD Card Acceptance Device
CAP Converted APplet file
CHIP Abreviatura de microCHIP
CLA CLAsse
CLK Clock
CPL Common Public License v1.0
DES Data Encryption Standard
EEPROM Electrically Erasable Programmable Read-Only Memory
FIPS Federam Information Processing Standard
GNU General Public License
GSM Global System for Mobile communications
GUI Graphical User Interface
IDE Integrated Development Environment
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 xiii Fernando Mostardinha * Sandra Silva
IFD InterFace Device
INS Instruction
ISO International Organization for Standardization
JAR Java ARchive
JCRE Java Card Runtime Environment
JCVM Java Card Virtual Machine
JVM Java Virtual Machine
Lc Comprimento dos dados a enviar
Le Comprimento dos dados a receber
MAC Message Authentication Code
MFC Multi Function Card
MS-PDC Multi Service – Patient Data Card
OCF Open Card Framework
P1, P2 Parâmetros
PC/SC Personal Computer / Smart Card
PDC Patient Data Card
PIN Personal Identification Number
PIX Property Identifier eXtension
PMB Porta Moedas multiBanco
PUK Personal Unblocking code
RAM Random Access Memory
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 xiv Fernando Mostardinha * Sandra Silva
RID Resource IDentifier
ROM Read Only Memory
RS232 Recommended Standard 232 (computer serial interface, IEEE)
RSA Rivest Shamir Adleman, algoritmo de Criptografia assimétrica
SO Sistema Operativo
SSL Secure Sockets Layer
SWT Standard Widget Toolkit
TCP/IP Transmission Control Protocol / Internet Protocol
UA Universidade de Aveiro
UV Ultra Violeta
URL Unique Resource Locator
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 1 Fernando Mostardinha * Sandra Silva
Capítulo 1
1.1 Introdução
A informação de saúde dos cidadãos é gerada, manipulada e armazenada ao longo das
inúmeras instituições que prestaram cuidados de saúde ao utente durante o seu período
de vida. Neste cenário, existem vários problemas inerentes à construção de um sistema
integrado de acesso a esta informação.
Neste momento, existe já um protótipo de um sistema de integração e acesso seguro
baseada em tecnologia Web, Criptografia de Chaves Pública e Crypto Smart Cards.
A arquitectura do cartão de utente multi-serviço desenvolvido contempla vários
serviços:
-suporte para dados residentes no cartão; uma área (estrutura) reservada ao
armazenamento e gestão de meta-ponteiros para registos electrónicos do utente;
-identificação e autenticação digital do utente baseado em credenciais electrónicas
(certificados digitais);
- mecanismos de verificação da identidade do portador do cartão, utilizando PIN
ou Biometria;
Este sistema contempla informação dos utentes com carácter clínico e genético.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 2 Fernando Mostardinha * Sandra Silva
1.2 Objectivos:
− Migração do actual sistema baseado num cartão inteligente criptográfico orientado ao
sistema de ficheiros para cartões orientados às aplicações, isto é, cartões do tipo
Javacard. Com este tipo de cartões podemos desenvolver aplicações que são
armazenadas e executadas no interior do próprio cartão;
− Desenvolvimento de serviços para interligação com portal de suporte ao cartão;
− Aprofundamento da capacidade do sistema para informação do tipo genético;
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 3
Capítulo 2
2 Ferramentas Tecnológicas:
2.1 ECLIPSE
2.1.1 O Eclipse
O Eclipse é uma das plataformas mais poderosas
de desenvolvimento de software, extensível,
baseada em Java e implementada segundo uma
filosofia de open source. Na realidade é
simplesmente uma plataforma com
determinados serviços, que permite criar um ambiente de desenvolvimento integrado
(IDE) a partir de componentes, plugins facilmente instaláveis. O Eclipse traz incluído
um número de plugins nativos, entre os quais o JDT, Java Development Tool.
Apesar de na maioria das vezes, o Eclipse ser usado como um simples editor de
programação em Java, tem potencialidades para muito mais. O PDE, Plugin
Development Environment, funcionalidade que interessa principalmente aos
programadores de software, que queiram estender o Eclipse, já que permite criar
ferramentas que se integrem no próprio ambiente do Eclipse.
Uma vez que tudo no Eclipse não passa de um plugin, os criadores têm a possibilidade
de desenvolver extensões e assim criar um ambiente de desenvolvimento integrado,
consistente e unificado. O facto de ter sido desenvolvido em Java, não implica que
esteja limitado a essa linguagem. Existem plugins que suportam outras linguagens,
como por exemplo: C/C++, COBOL, entre outras mais. Pode também ser usado como
base para outras aplicações, onde um bom exemplo disso é o IBM WebSphere Studio
Workbench, aplicação base para o desenvolvimento de ferramentas Java.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 4 Fernando Mostardinha * Sandra Silva
Em suma, há uma frase que diz tudo:
“The Eclipse Platform is an IDE for anything, and for nothing in particular.”
Ou seja, o mesmo que dizer: O Eclipse é uma plataforma num ambiente de
desenvolvimento completo para tudo, e para nada em particular
2.1.2 Eclipse, o código aberto, open source
Open Source não significa apenas acesso ao código fonte. Os termos de distribuição de
um programa código aberto devem adoptar pelo menos os seguintes critérios:
• Redistribuição Gratuita - A licença de distribuição não se deve restringir a
nenhuma das partes interessadas em vender ou ceder o software como
componente de uma distribuição de um software agregado, contendo programas
de fontes diferentes. A licença não deve cobrar direitos de autor e propriedade
ou outras taxas pela venda do programa.
• Código Fonte - O programa deve incluir o seu código fonte e deve permitir a
sua distribuição assim como a distribuição em forma compilada. Quando o
produto não for distribuído com o código fonte, deve haver uma forma
claramente anunciada de obter o código fonte, sem qualquer custo adicional, de
preferência via Internet. O código fonte deve ser o recurso preferencialmente
utilizado pelo programador para modificar o programa, não sendo permitido
ofuscar o código fonte deliberadamente. Também não são permitidas formas
intermediárias, como a saída de um pré-processador ou tradutor.
• Integridade do Código Fonte do Autor - A licença apenas pode restringir a
distribuição do código fonte, em forma modificada, se ela permitir a distribuição
de patches(pequenos programas de ajuste) junto com o código fonte original,
com o objectivo de modificar o programa durante a compilação. A licença deve
permitir explicitamente, a distribuição de software compilado, a partir do código
fonte modificado. A licença pode exigir, que trabalhos derivados tenham
diferentes nomes ou diferentes números de versão que o software original.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 5 Fernando Mostardinha * Sandra Silva
Desde sempre que existiu um medo e dúvida sobre o uso de software em código
aberto, devido ao facto de as licenças contagiarem as partes proprietárias como as não
proprietárias de um todo. A ideia é de que se uma entidade desenvolver software código
aberto, que faz parte de um projecto, uma segunda entidade contribui também com
software mas neste caso proprietário, a segunda entidade perde os direitos, já que a
licença afecta o projecto global. Usando outro tipo de licenças, tais como a GNU
General Public License (sobre a qual o Linux por exemplo é distribuído), obtemos
assim um melhor balanço entre as preocupações comerciais e as da comunidade.
A iniciativa open source não tem fins lucrativos, logo vai explicitamente ao encontro do
significado de open source e certifica as licenças que vão de encontro deste critério. O
Eclipse é licenciado segundo CPL, Common Public License v1.0, com vista a facilitar o
uso comercial ao programa.
Aos construtores de componentes para o Eclipse, assim como aos que o usam como
uma ferramenta base de desenvolvimento, exige-se que todo o código desenvolvido seja
distribuído segundo a licença CPL. Portanto, apesar de a grande maioria dos
utilizadores não utilizar o Eclipse para desenvolver plugins ou mesmo produtos
baseados neste, a filosofia em código aberto, torna o Eclipse gratuito e disponível para
todos.
Para além disso a filosofia Open Source, para além de encorajar o espírito inovador,
incentiva também os criadores, mesmo aqueles que estão vinculados a entidades
comerciais. Deste modo, todos podem contribuir para os projectos da comunidade. Uma
consequência essencial a retirar do conceito de código aberto, é que quanto mais
colaboradores contribuem para o projecto, mais valioso este se torna para todos. Como
o projecto se torna mais útil, mais colaboradores usá-lo-ão, o que levará a criação de
uma comunidade em torno dele, como as que se criaram em torno do Apache e do
Linux com dimensões que ainda hoje são de admirar.
2.1.3 Consórcio Eclipse
O consórcio Eclipse.org, controla e dirige o Eclipse durante o seu desenvolvimento.
Criado pela IBM, depois de se terem gasto cerca de $40 milhões no seu
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 6 Fernando Mostardinha * Sandra Silva
desenvolvimento desenvolvendo o Eclipse e disponibilizando-o como um projecto
código aberto, a Eclipse.org recrutou um número de vendedores de ferramentas de
software incluindo Borland, Merant, Rational, RedHat, SuSE, TogetherSoft, e QNX.
Outras companhias vieram depois juntar-se, das quais Hewlett Packard, Fujitsu, e
Sybase. O projecto é dividido em sub-projectos e cada um destes tem um líder. Os
grandes sub-projectos são divididos em componentes e cada um destes tem também um
líder.
2.1.4 Aspectos Técnicos da Plataforma Eclipse
A plataforma Eclipse foi projectada e construída para obedecer às seguintes exigências:
Suportar a construção de uma variedade de ferramentas para o desenvolvimento
de aplicações.
Suportar um conjunto não restrito de ferramentas, incluindo vendedores
independentes do software.
Ferramentas de apoio para manipular tipos de conteúdos arbitrários (HTML,
Java, C, JSP, EJB, XML, e GIF).
Facilitar a integração de ferramentas de diferentes tipos e fornecedores.
Suportar o desenvolvimento de aplicações com ou sem interface gráfica.
Independente da plataforma, incluindo Windows e Linux.
Dar ênfase ao desenvolvimento de aplicações baseadas em linguagem Java.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 7
Figura 2.1: Componentes principais e APIs da plataforma Eclipse
2.1.5 Componentes
Um plugin é a mais pequena unidade funcional da plataforma que pode ser
desenvolvida e distribuída separadamente. Por norma, ferramentas simples são
desenvolvidas como plugins, enquanto que ferramentas mais complexas já são
constituídas por vários plugins, excepto o Platform Runtime (micro kernel), todas as
funcionalidades do Eclipse existem sobre a forma de plugins. São programados em Java
e tipicamente distribuídos num ficheiro JAR (Java Archive) com outro tipo de
informação, como imagens, web templates, bibliotecas, etc.
No entanto existem plugins que não contêm código, como por exemplo o responsável
pela ajuda on-line. Todos os plugins têm um ficheiro manifest, responsável pela
declaração da inter conectividade entre outros plugins.
2.1.6 Plataforma Runtime
Platform runtime é o kernel que descobre quais os plugins instalados no arranque da
plataforma, criando em seguida um registo informativo e também responsável pela
política de gestão dos plugins. De forma a poupar recursos os plugins só são carregados
quando são realmente precisos. Para além deste kernel, tudo o resto é implementado
como um plugin.
2.1.7 Workspace
O Workspace é o componente responsável por controlar os recursos do utilizador. Isto
inclui os projectos que o utilizador cria, os ficheiros desses projectos, e as alterações aos
ficheiros e outros recursos. É também responsável por notificar outros plugins
interessados nas modificações desses recursos, tais como ficheiros que foram criados,
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 8
apagados ou modificados. As várias ferramentas plugins usadas na plataforma
operam na área de workspace.
Figura 2.2: Workbench do Eclipse
O Workbench fornece ao Eclipse uma interface para o utilizador. A implementação do
workbench é feita recorrendo aos dois toolkits:
o SWT – conjunto de bibliotecas gráficas integradas com as janelas do sistema
operativo mas independentes das APIs do SO.
o JFace – toolkit de interface gráfico implementado usando SWT e que simplifica
as tarefas de programação simples (imagens, fontes, diálogos, acções, etc.).
2.1.8 Suporte de equipa
O componente de suporte de equipa é responsável pelo controlo de versão e
configuração da plataforma. Alguns plugins não necessitam deste componente, já que
trazem incluídos serviços de controlo de versão.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 9
2.1.9 Editor de texto
Editor de texto com funcionalidades interessantes (syntax checking e code completion)
que permitem o desenvolvimento simples e eficaz de código.
Figura 2.3: Editor de texto
2.1.10 Fácil depuração com sugestões – Quick Fix suggestions
O Quick Fix suggestions, funcionalidade que permite rapidamente fazer o debug do
código, com sugestões explícitas (coisa que não acontece no Visual C++) que permitem
corrigir o erro. Na figura em baixo, temos uma situação em que propositadamente se
introduziu um erro na declaração da variável tipo string título, para títulos. Como se
pode ver, o Quick Fix sugere de entre várias sugestões, uma de mudar o nome da
variável usada para títulos, de forma a igualar com a declarada.
Figura 2.4: Quick Fix
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 10
2.1.11 Consola
Por fim, depois de compilado, executa-se o programa e para isso o Eclipse tem incluído
uma consola que permite interagir com o utilizador como se tratasse de uma linha de
comandos. Esta consola, implementa o Standard Output e o Standard Input (STDOUT
e STDIN).
Figura 2.5: Consola
2.1.12 Criação de uma classe no Eclipse
Exemplo de um projecto criado no eclipse que implementa uma classe CLivro que
contém informação acerca do título do livro (string) assim como, o ano de publicação.
A criação de uma classe em perspectiva Java, como se pode ver na figura seguinte, tudo
está simplificado, pois o utilizador tem de introduzir o nome da classe, o nome do
pacote que engloba as várias classes, o tipo de classe (acesso) e por fim pretende-se um
método main (executável).
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 11
Figura 2.6: Criação de uma classe no Eclipse
2.1.13 Jigloo GUI Builder
Esta biblioteca potentíssima do Eclipse, como seria de esperar é grátis e para usos não
comerciais. É um plugin para o Java IDE do Eclipse e o para o WebSphere Studio,
permitindo que se construa e controle as classes Swing e SWT GUI.
O Jigloo cria e controla o código para todas as partes do Swing ou do SWT GUIs, como
também trata de eventos de código e os mostra enquanto estão a ser construídos. O
Jigloo analisa gramaticalmente os ficheiros Java da classe para construir a
figura/objecto pretendido e que se vai esboçando. Assim, pode-se trabalhar nas classes
que são geradas por outros construtores GUI ou por outras classes “programadas à
mão”. Além disso, pode-se também fazer a conversão de um Swing GUI para um SWT
GUI e vice-versa.
O Jigloo é intuitivo, rápido, poderoso, fácil de usar e facilmente integrável com o
Eclipse. A utilização dele pode siginificar grandes economias de tempo nas tarefas de
desenvolvimento e manutenção do GUI.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 12 Fernando Mostardinha * Sandra Silva
O Jigloo é muito versátil, pois há partes do código que o Jigloo cria e as quais podem
ser reescritas, ou alteradas. O código gerado pelo plugin é configurável.
As classes personalizadas podem ser adicionadas aos formulários e aos JavaBeans
(Programas em Java que permitem a criação de objectos/software reutilizável) pois está
suportada a possibilidade de configuração, bem como propriedades configuráveis. Além
disso, o Jigloo suporta o inheritance (herança) visual que pode projectar classes que se
podem estender a outras classes construídas, as quais podem ser públicas, abstractas ou
não públicas. A navegação entre o código e os editores pré definidos (formulários) é
muito fácil visto que o Jigloo destaca a secção relevante do código quando o editor de
formulário é apontado/seleccionado, ou o elemento em causa do formulário quando o
editor do código tem o foco.
Os componentes são adicionados, os layouts mudados etc., seleccionando menus, ou por
outras opções directas, nos menus do rato quando se clica o botão direito do rato. Pode-
se por exemplo, alterar o tamanho arrastando esboço pretendido, assim como alterar a
suas propriedades, confinantes à sua disposição. A Multi-selecção dos componentes faz
com que seja muito fácil fazer alterações. A mudança de Classe (por exemplo, de um
composto (Composite) para um grupo (Group), de uma caixa combo para um campo do
texto, ou para alguma outra classe pretendida pode também reduzir o tempo de projecto.
O GUI pode "ser pré-visualizado" ou executado usando o editor de acções.
O que pode significar um nome:
1) Jigloo = Jig + gloo - because a jig is used to hold pieces together while being
assembled-with_glue, or
2) Jigloo = J + igloo - because if you can't think of anything better, then start your Java
project with a J, and an igloo is a cool building. [10]
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 13
Figura 2.7: Jigloo, plugin gráfico do Eclipse
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 14
2.2 Cyberflex Access SDK 4.2
Este software permite uma interacção com o utilizador bastante
agradável e de fácil compreensão (figura 2.8). O reader utilizado
foi um Sclumberger Sema Reflex USB v.2.0.
Na janela Card Manager encontram-se identificados os readers.
Quando um cartão é inserido num reader, logo de imediato aparece no écran uma
mensagem a informar o utilizador do acontecido, onde identifica o reader em que foi
inserido o cartão e questiona o utilizador se quer ou não ligar o cartão, como se pode ver
pela figura 2.9.
Figura 2.8: Aspecto do programa Cyberflex Access Toolkit 4.3
Depois da permissão dada pelo utilizador para ligar o cartão, pode ser observado na
janela Card Manager o cartão e a sua identificação. Da figura 2.10 pode-se verificar que
se trata de um cartão Cyberflex Access Developer 32k.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 15
Figura 2.9: Informação de que o cartão Java Card foi inserido no reader
Quando se introduz um cartão, neste software ficam visíveis algumas características
dele, como se pode verificar na figura abaixo:
Figura 2.10: Informação acerca do cartão inserido
O passo seguinte consiste no estabelecimento de um canal seguro através da verificação
das chaves de AUTH, MAC e KEK (figura 2.11). Esta verificação pode ser realizada
através do botão Select Key que lista os conjuntos de chaves que se encontram na base
de dados do Card Manager (figura 2.12). O conjunto de chaves por defeito é adicionado
ao sistema quando o software é instalado, fornecendo assim uma forma rápida de
estabelecer um canal seguro. Depois do conjunto seleccionado, as chaves por defeito
são introduzidas competindo apenas ao utilizador carregar no botão Establish, de forma
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 16
a confirmar a opção feita (figura 2.13). Posto isto, uma mensagem de aviso
aparece no écran a informar que as chaves foram verificadas e o canal estabelecido
(figura 2.14).
Figura 2.11: Estabelecimento de um canal seguro
Figura 2.12: Escolha das chaves específicas do cartão utilizado
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 17
Figura 2.13: Introdução das chaves e estabelecimento do canal seguro
Figura 2.14: Mensagem de informação que o canal foi estabelecido
Após o canal estabelecido, pode ser visualizado na janela Card Manager todo o
conteúdo do cartão (figura 2.15).
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 18
Figura 2.15: Visualização do conteúdo do cartão
Os passos principais para carregar o programa no cartão, e assim poder testá-lo e
interagir com ele, encontram-se na figura seguinte.
Figura 2.16: Passos principais para converter o código fonte numa aplicação [4]
O primeiro passo efectua-se através da compilação do código fonte. A compilação
converte o código em ficheiro Java para ficheiro class. Este por sua vez contém a
informação convertida em bytes.
O segundo, converte o ficheiro class num program file. Para efectuarmos este passo,
utilizamos a caixa de diálogo Program File Generator do Cyberflex Access Toolkit 4.3.
Este, coloca o ficheiro a carregar num formato compreensível para o JVM (figura 2.9).
No entanto, convém salientar que para executar este passo não é necessário ter um
cartão introduzido no reader.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 19
Figura 2.17: Conversão do ficheiro class num program file
O terceiro passo fundamental consiste em adicionar o program file no cartão como um
load file. Para o efeito, utilizamos a opção New->Program File do ícone Load Files and
Libraries na janela Card Manager (figura 2.18). O load file contém os bytecodes da
classe ou das classes do program file. A criação do load file encontra-se ilustrada na
figura 2.19. Se não ocorrer nenhum erro, uma mensagem a informar que o programa foi
carregado com sucesso, aparece no écran (figura 2.20). Pela figura 2.21 pode ser
visualizado o load file na pasta Load Files and Libraries da janela Card Manager
Figura 2.18: Adição do program file como um load file
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 20
Figura 2.19: Criação do load file
Figura 2.20: Informação de que o programa foi carregado com sucesso
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 21
Figura 2.21: Visualização do load file já carregado na pasta Load Files and Libraries
Finalmente, o quarto passo consiste na instanciação da applet. Tal pode ser conseguido
seleccionando o load file com o botão do lado direito do rato, o qual fará aparecer um
menu pop-up. Seleccionando a opção New->Instance (figura 2.22), podemos então
iniciar a instanciação da applet. A criação da instância pode ser vista pela figura 2.23.
Se não ocorrer nenhum erro, a instância é criada e colocada na pasta Instance na janela
Card Manager (figura 2.24).
Figura 2.22: Início da instanciação da applet
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 22
Figura 2.23: Criação da instância
Figura 2.24: Instância criada com sucesso
Criada a instância, é então possível seleccioná-la e enviar comandos APDU, ou seja, é
agora possível interagir com cartão e assim testar a aplicação. Com o botão do lado
direito do rato é possível seleccionar a instância e através do menu pop-up, escolher a
opção Select Application (figura 2.25). A aplicação é seleccionada e uma mensagem
informando o utilizador aparece no écran (figura 2.26).
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 23
Figura 2.25: Selecção da aplicação
Figura 2.26: A aplicação seleccionada
Usando o APDU Manager do menu Tools, torna-se possível enviar comandos APDU e
obter os respectivos responses APDU de uma forma fácil de interpretar pelo utilizador
(figura 2.27).
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 24
Figura 2.27: APDU Manager
O passo seguinte foi o teste da aplicação. Enviar comandos e receber comandos. Na
figura 2.28 é possível observar o comando getBalance, onde foram introduzidos os
valores hexadecimais C0 10 00 00 nos campo CLA, INS, P1 e P2 respectivamente, tal
com foi definido acima na fase de projecção da aplicação. Como se trata de um
comando que não envia dados e apenas os recebe, os campos Send e Body ficam a zero.
O Send corresponde ao tamanho dos dados a enviar e o Body, aos dados propriamente
ditos. Por sua vez, selecciona-se o campo Receive e automaticamente um campo relativo
ao comprimento (Length) aparece ao seu lado. É aí que é introduzido o valor do
comprimento da resposta do APDU, ou seja, corresponde ao campo Le definido
anteriormente na fase de projecção.
Figura 2.28: Envio do comando getBalance
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 25
Através do botão Send APDU é possível enviar o comando e obter a resposta (figura
2.29). Esta aparece no campo Data Received, se forem esperados dados, como é o caso
deste comando e no campo Status aparece a informação sobre a status word. Se a
operação for bem sucedida aparecerá um OK, caso contrário aparecerá a status word
identificativa do erro. A figura 2.30 ilustra a resposta do comando getBalance. Como
pode ser observado pelo campo Data, foi retornado o número de viagens do cartão em
valor hexadecimal (0x0A) correspondente ao valor 10 em decimal. Como a operação foi
efectuada com sucesso, o OK apareceu assim no campo Status.
Salienta-se que todos os comandos APDU, sejam eles o de getBalance como o de
selecção de aplicação, podem ser observados na janela respectiva às comunicações do
reader utilizado (figura 2.31).
Figura 2.29: Envio do comando APDU
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 26
Figura 2.30: Resposta do comando
Figura 2.31: Janela de comunicações respectiva ao reader
Executado o comando getBalance, foi executado o comando Debit (figura 2.32). Os
campos CLA, INS, P1 e P2 receberam respectivamente, os valores hexadecimais C0 20
00 00. O campo Body foi preenchido com o valor 1 correspondente ao número de
viagens a debitar. O campo Send é actualizado automaticamente. Desta vez, a resposta
não conterá dados e portanto, o campo Receive não foi seleccionado. Seleccionando o
botão Send o comando foi então enviado. A resposta ao comando pode ser observada na
figura 2.33.
Finalmente, através da figura 2.34 verifica-se que o saldo do cartão foi decrementado,
passando agora a ser de nove viagens.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 27
Figura 2.32: Envio do comando Debit
Figura 2.33: Resposta do comando
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 28
Figura 2.34: Nova consulta do saldo do cartão
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 29
2.3 OpenCard Framework
Doze líderes de indústria (Bull Personal Transaction Systems,
Dallas Semiconductor Corporation, First Access, Gemplus, IBM,
NCI, Netscape Communications Corp, Schlumberger, SCM Microsystems, Sun
Microsystems, Inc., UbiQ Inc. e Visa International) uniram esforços para desenvolver
uma nova especificação tecnológica, chamada OpenCard Framework que vai ajudar o
software desenvolvido pelos seus designers, criado para aplicações dos cartões
inteligentes e que podem ser usadas por uma variedade de dispositivos para empresas e
para consumo doméstico, como PCs, computadores de rede, automático, máquinas de
caixa, terminais de ponto-de-venda.
O OpenCard Framework resultou do trabalho desenvolvido por um grupo ad hoc da
indústria para simplificar o uso de tecnologia de cartões inteligentes por diferentes
sistemas de fabricantes. A referência à Versão 1.0 da OpenCard Framework
implementada é datada de Abril de 1998.
O Consórcio do OpenCard foi estabelecido por uma plataforma de administração,
chamada de Secretária e estabeleceram vários grupos de trabalho, seleccionados dentro
dos sócios do consórcio, para desenvolver especificações adicionais do OpenCard
Framework. Estes grupos são:
• Core & Infrastructure Workgroup
• Card Services Workgroup
• Card Terminal Workgroup
• Industry Specific Applications
• Testing & Compliance Workgroup
A estrutura OpenCard fornece uma relação comum entre o leitor de cartões inteligentes
e a aplicação no cartão. Baseando a arquitectura na tecnologia Java, resultou no
aumento da portabilidade e da interoperabilidade, que são a chave da adopção
difundida. A execução referente à versão 1,0 permite também a interacção com o
Computador Pessoal existente/Cartão inteligente (PC/SC) 1,0, dispositivos suportados
pelo leitor.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 30 Fernando Mostardinha * Sandra Silva
A plataforma OpenCard pode ser dividida em duas componentes principais:
• A componente CartãoTerminal
• A componente CartãoServiço
Estes escondem detalhes específicos do Terminal/Cartão e deixam desenvolver
aplicações independentemente de qualquer terminal ou leitor e qualquer cartão
inteligente.
A componente CartãoTerminal contém classes e interfaces que permitem aceder a
terminais dos cartões e às suas slots. Usando estas classes, por exemplo pode-se
descobrir se um cartão inteligente é inserido num terminal.
A plataforma OpenCard oferece significativas vantagens para os fabricantes de
aplicações e serviços, assim como para fornecedores de terminais e de cartões.
Os fabricantes de aplicações e serviços, beneficiam da plataforma OpenCard como se
mostra a seguir:
• Independência do vendedor – o fabricante pode escolher cartões e terminais de
abastecedores diferentes
• Protecção do recurso – a extensibilidade da arquitectura permite os
colaboradores de participar nos desenvolvimentos futuros da tecnologia do
cartão inteligente a um custo mais baixo, migrando para o nível do API
• Melhor tempo-para-mercado – o criador de software lucra com uns ciclos de
desenvolvimento mais curtos, programando um API em alto nível
• Menor custo de desenvolvimento – os designers do software guardam os custos
extra de mover as suas aplicações para as diferentes plataformas e beneficiam
das baixas exigências da habilidade para realizar uma tarefa dada.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 31 Fernando Mostardinha * Sandra Silva
Os fornecedores de cartões e de terminais beneficiam da plataforma OpenCard
nos seguintes pontos:
• Incremento de mercado – os programadores ganham acesso a novos segmentos
de mercado, alcançando muitos mais clientes
• Melhor competição – os criadores podem competir em termos de funcionalidade
e são menos vulneráveis à predominância de um único vendedor
• Menor esforço no desenvolvimento – o programador herda assim a
funcionalidade fornecida pela estrutura, a qual reduz os custos de
desenvolvimento
Para mais informação sobre OpenCard Framework referente à execução e ao código
fonte, disponível na Web em http://www.opencard.org.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 32
Capítulo 3
3 SmartCard
3.1 Introdução
O SmartCard que se descreve, é um cartão de plástico, igual em tamanho e formato a
um cartão de crédito. Contém memória e um microprocessador integrado. Estes dois
componentes permitem o armazenamento e processamento de informação dentro do
cartão.
Figura 3.1: Contacto de Smart Card [5.2]
O Smart Card pode trocar dados com o mundo exterior de dois modos:
por contactos de ouro e são chamados cartões de contacto.
por rádio frequência, usando uma antena embutida no cartão. Este tipo de cartão
é chamado cartão contactless (sem fios).
Para trocar informação, o cartão tem que ou ser inserido dentro um leitor (no caso de
cartões de contacto) ou colocado na proximidade de um leitor contactless.
O cartão inteligente não tem bateria e a energia é-lhe fornecida do exterior, pelo leitor
de cartões, por contacto ou por contactless. O sinal de clock (relógio) do CPU também é
fornecido pelo leitor. O cartão possuí ainda uma EEPROM (Electrical Erasable
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 33
Programmable Read Only Memory), que reterá os conteúdos mesmo quando não
houver nenhuma tensão aplicada. Há cartões que são unicamente cartões de memória.
Figura 3.2: Smart Card sem fios (contactless)
Só os cartões cujo chip contém certos microprocessadores lógicos são chamados cartões
inteligentes, smart cards.
As duas características principais de um cartão inteligente são: segurança e mobilidade.
Uma vez que a característica da mobilidade é óbvia, vamo-nos concentrar mais nas suas
características de segurança.
Quase todas as aplicações que usam um cartão inteligente estão baseadas no facto de
que é muito difícil forjar o cartão ou aceder aos dados protegidos neste. Se por qualquer
razão, a segurança do cartão inteligente fosse posta em causa, então não haveria
qualquer motivo que justificasse o seu uso.
Os cartões inteligentes são usados numa grande variedade de aplicações, como por
exemplo:
• transacções financeiras
• porta moedas multibanco
• identificação biométrica
• credifones
• telefones
• armazenamento e controle de inventário
• etc...
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 34 Fernando Mostardinha * Sandra Silva
Governo, serviços financeiros, transportes, telecomunicações, cuidados médicos,
educação, venda a retalho e muitas outras indústrias estão a planear, ou então já usam
cartões inteligentes, como um meio de melhor promover a segurança nos serviços
prestados aos seus clientes e utilizadores.
3.2 História do SmartCard
Os cartões inteligentes, SmartCards, podem ser identificados desde 1968, com o uso de
cartões de plástico transportando microchips. O primeiro foi desenvolvido pelos
inventores alemães Jürgen Dethloff e Helmut Grötrupp. Dois anos mais tarde, em 1970,
Kunitaka Arimura desenvolveram uma aplicação semelhante. A primeira realidade
formal de um cartão inteligente veio com Roland Moreno’s que patenteia o cartão
inteligente em França em 1974. Com as suas patentes, a indústria dos semicondutores
pode fabricar e fornecer os circuitos integrados a um preço razoável.
A primeira tentativa de campo foi levada a cabo com sucesso em 1984, pelo PTT
francês (Serviço Postal e de Telecomunicações) com cartões de telefone. A Alemanha
três anos mais tarde levou a cabo o uso dos cartões nos telefones.
O uso na indústria financeira de Smart Cards como cartões bancários, progrediu muito
lentamente devido à complexidade e às infra-estruturas existentes nos sistemas dos
bancos. Até há bem pouco tempo, se não fossem os desenvolvimentos da criptografia
moderna, tecnologia esta, que permitiu que os cartões inteligentes passassem a ter um
grau de segurança mais alto, fez com que as associações bancárias começassem a levar
o cartão inteligente mais a sério. Outros ramos/indústrias, como a saúde, a educação, as
telecomunicações e os transportes, começaram a empregar cartões inteligentes como
parte integrante de uma solução total. Como se pode ver hoje em dia, o cartão
inteligente tem e terá cada vez mais, um papel preponderante no negócio electrónico.
3.3 Pontos de contacto de um Smart Card
O cartão inteligente é composto por vários pontos de contacto, os quais passaremos a
descrever:
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 35 Fernando Mostardinha * Sandra Silva
Figura 3.3: Cartão Smart Card
Vcc fornece a energia ao chip
RST ponto usado para enviar o sinal de reset ao
microprocessador
CLK fornece o sinal de clock externo, a partir do qual o sinal
interno de clock é derivado
GND ponto usado como tensão de referência e o seu valor é
considerado 0 volts
Vpp ponto opcional e usado unicamente em cartões antigos
I/O ponto de contacto usado para transferir dados e
comandos entre o Cartão Inteligente e o mundo
exterior, mas em modo half-duplex
RFU Ponto reservado para uso futuro Figura 3.4: Pontos de contacto de um Smart Card
Figura 3.5: Pontos de contacto do Cartão Inteligente (Smart Card)
3.4 Sistema operativo do Smart Card
O cerne de um cartão inteligente é o seu sistema operativo. Este, tem o código que
controla os sistemas de ficheiros, a segurança, o I/O, a manipulação das diferentes
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 36 Fernando Mostardinha * Sandra Silva
aplicações, etc... É semelhante aos sistemas operativos dos computadores
pessoais, só que limitado a uns modestos mil bytes.
Há várias companhias que desenvolvem e comercializam sistemas operativos como por
exemplo, a IBM que foi pioneira na área, desde 1984. Em 1990, a IBM introduziu o
sistema operativo MFC (Multi Function Card). Desde então, muitas outras versões de
sistemas operativos derivados do MFC foram desenvolvidas. Uma versão ímpar do
MFC foi desenvolvida para o Zentraler Kreditausschuess (ZKA), o Comité Central do
grupo de bancos da Alemanha, para sistemas de pagamento standarizados. Este
desenvolvimento permitiu a plataforma para o GeldKarte, ou seja, a aplicação de Smart
Cards com mais cartões no mundo.
3.4.1 Sistemas Operativos do Smart Card no mercado
Além do Sistema Operativo da IBM, o MFC, há muita oferta para os Smart Cards
disponíveis actualmente. Os vendedores de Smart Cards, têm as suas próprias versões
de sistemas operativos para os seus cartões inteligentes.
A título de exemplo, mostra-se uma lista de sistemas operativos oferecidos pelos vários
Smart Cards, não sendo como é óbvio uma lista completa dos vendedores.
o Bull: SmarTB, CC, Odyssey I (JavaCard), etc.
o DeLaRue: DS, DX, DXPLUS, CC, Mondex Card, JavaCard, etc.
o Gemplus: PCOS, MPCOS, GemVersion, GemXpresso(JavaCard), etc.
o Giesecke & Devrient: Starcos S, Starcos PK, Starcos X, etc.
o ODS: ODS-COS, etc.
o ORGA: ICC, etc.
o Schlumberger: ME2000, PayFlex, Multiflex, Cryptoflex, Cyberflex(JavaCard),
etc.
o Siemens: Card OS
Por vezes os vendedores dos Smart Cards, autorizam o uso de sistemas operativos de
outros fabricantes, permitindo estender e modificar os comandos para diferentes
aplicações. Por exemplo, quer a Gemplus quer a Schlumberger usam a licença da IBM,
a MFC.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 37 Fernando Mostardinha * Sandra Silva
3.5 Tipos de Smart Card
Desde os tempos em que não havia uma definição oficial para o termo “Smart Card”,
que muitos cartões foram apelidados de inteligentes, desde que para isso tivessem
algum tipo de circuitos inteligentes nos cartões, tal como um microprocessador.
3.6 Segurança num Smart Card
Há várias razões para se usar um Smart Card, mas como se disse anteriormente, uma
das principais razões é a segurança embutida (built-in) que o caracteriza. O
microprocessador do cartão inteligente tem chaves e algoritmos de encriptação
embutidos para melhorar a execução da codificação/descodificação (ciphering
/deciphering) de dados dentro do cartão. A estrutura de ficheiros do sistema operativo,
impede que as chaves secretas possam ser lidas fora do cartão inteligente.
Se várias aplicações residirem no mesmo cartão inteligente, elas estão protegidas umas
das outras, por uma barreira física (firewall) entre elas.
Para além do próprio Smart Card, é necessário endereçar com total segurança o sistema,
o qual vai incluir leitores, terminais, rede e suporte para sistemas de processamento. Por
outras palavras, para se assegurar um sistema global seguro é necessário fazer um
planeamento total do sistema, que deve cobrir todos os pontos possíveis e que podem
ser atacados por pessoas mal intencionadas.
Durante o processo de planeamento é necessário avaliar os riscos envolvidos versus
recompensas de estabelecimento de uma segurança forte, despesas de implementação e
a solução encontrada para uma possível quebra de segurança após exposição. O
processo de planeamento é provavelmente melhor executado por um consultor que não
tem qualquer interesse pessoal ou não, num determinado produto, do que ser por
vendedores que provavelmente terão maiores interesses num determinado produto, mas
aos quais depois faltará o conhecimento de segurança do sistema global.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 38 Fernando Mostardinha * Sandra Silva
3.6.1 Princípios em segurança
Há vários princípios que os sistemas com cartões inteligentes devem ter e pode mesmo
dizer-se que têm de ter:
• Privacidade
• Não repúdio (Non-repudiation)
• Autenticação
• Integridade
• Verificação
Os cartões inteligentes usam estes princípios para implementar vários tipos de
algoritmos de encriptação.
3.6.1.1 Privacidade
A privacidade é o acto de assegurar a não divulgação de informação entre duas partes, a
uma terceira parte externa às primeiras. Há duas técnicas criptográficas usadas para
assegurar a privacidade: a criptografia simétrica e a criptografia assimétrica; e cada
técnica criptográfica tem áreas de aplicação diferentes em cartões inteligentes
3.6.1.2 Criptografia Simétrica
Esta técnica de criptografia é denominada simétrica porque a mesma chave é usada para
encriptar e desencriptar a mensagem, como mostra a figura seguinte.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 39
Figura 3.6: Encriptação simétrica usando DES
O algoritmo simétrico mais conhecido é o Data Encryption Standard (DES) porque é
rápido, razoavelmente seguro e simples de implementar no hardware. O DES é um
algoritmo de encriptação, desenvolvido pela IBM e padronizado em 1977 pelo ANSI
(American National Standards Institute) como o FIPS (Federal Information Processing
Standard), também conhecido por DEA (Data Encyiption Processing), que significa
Algoritmo de Encriptação de Dados. Pode-se saber um pouco mais sobre ANSI e
padrões FIPS, na Web em http://www.ansi.org/ .
O DES pode usar diferentes comprimentos de chaves. A chave mais longa é mais difícil
de quebrar. Uma chave de 40 bits pode ser quebrada com apenas algumas horas de
processador, enquanto que uma chave de 56 bits, vai demorar um tempo
consideravelmente maior. Estes ataques brutalmente forçados estão a ser beneficiados
pelo aumento dramático da capacidade de processamento dos processadores. Então, é
um termo relativo afirmar-se que se trata de “um tempo consideravelmente maior”.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 40
Figura 3.7: Encriptação Simétrica usando o Triplo-DES
Nos casos que requerem uma segurança maior, como por exemplo a transmissão de
chaves de encriptação, é usado o Triplo-DES, processo este mostrado na figura acima.
Actualmente, quase todos os cartões inteligentes usam o software encriptação DES.
Todos os cartões da IBM MFC têm o algoritmo criptográfico DES implementado no
software do sistema operativo do cartão.
A desvantagem da encriptação simétrica reside no facto de que ambas as partes
precisam de saber a chave. A transferência da chave de uma parte para a outra pode
comprometer a segurança que de certa forma a encriptação fornece. Escrever uma chave
DES na altura da personalização do cartão é o método seguro típico de transferência de
chaves aos portadores de cartões. Se isto não for possível, deve-se então usar a
criptografia assimétrica. [8]
3.6.1.3 Criptografia Assimétrica
Em 1976, a ideia de dividir a chave de encriptação/desencriptação foi proposta
inicialmente num artigo intitulado “Novas Direcções na Criptografia”, (“New
Directions in Cryptography”) por W. Diffie e M.E. Hellman.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 41
Esta ideia desde cedo ficou conhecida como Criptografia Assimétrica. Esta
técnica de criptografia, usa duas chaves: uma para encriptar o texto normal e outra para
desencriptar o texto cifrado. As chaves estão matematicamente relacionadas.
Só as mensagens encriptadas com uma chave podem desencriptar com a outra chave. O
melhor e mais conhecido algoritmo de criptografia assimétrica é o RSA (nomeado após
os seus inventores Rivest, Shamir, e Adleman). O algoritmo é definido na especificação
Pkcs-1 publicada pelo RSA Ltd. Pode-se saber mais em http://ftp.rsa.com/pub/pkcs/doc/.
Figura 3.8: Encriptação Assimétrica
A criptografia assimétrica é usada em cartões inteligentes, mas raramente executa a
encriptação geral de dados. A criptografia simétrica tal como o DES, é usada para essa
finalidade. Em vez disso, a criptografia assimétrica é usada em cartões inteligentes para
finalidades de autenticação, tais como assinaturas digitais. A chave confidencial do par
de chaves de um certificado digital é por exemplo, normalmente armazenada no cartão
inteligente. Isto acontece porque esta pode ser protegida com segurança pelo sistema
operativo do cartão e não ser divulgada para fora do cartão inteligente
Na encriptação simétrica, as chaves podem ter comprimentos diferentes. Os três valores
mais comuns são 512, 768 e 1024 bits. Os últimos dois valores são considerados de
encriptação forte.
A desvantagem do algoritmo de RSA é a velocidade, ou seja, o algoritmo é muito mais
lento do que o algoritmo DES. Devido à velocidade limitada do processador do cartão
inteligente, não é prática corrente executar o algoritmo de geração da chave no software.
Há Smart Cards especiais que têm cripto-processadores para essa finalidade. Os MFCs
4,0 e 4,21 são exemplos de tais cartões.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 42 Fernando Mostardinha * Sandra Silva
As encriptações simétricas e assimétricas geralmente complementam-se. A
encriptação assimétrica é usada para emitir com segurança a chave DES de uma parte
para a outra. Assim que ambas as partes souberem a chave DES, os dados transmitidos
são simetricamente encriptados, permitindo melhorar significativamente o desempenho.
3.6.2 Integridade
As ligações de comunicações electrónicas estão sujeitas a erros e mesmo aos dados
serem alterados. As técnicas criptográficas são usadas de modo a assegurar de que o
conteúdo dos dados não muda quando for transmitido, do emissor para o receptor. A
isto chama-se integridade dos dados.
3.6.2.1 Autentificação do código da mensagem
Um código de autenticação da mensagem MAC (Message Authentication Code) é um
valor gerado de 8-bytes, para uma mensagem única e igual à mensagem anterior, porque
um algoritmo criptográfico de sentido único é usado para gerar o valor. Um algoritmo
criptográfico de sentido único é especial porque não pode ser usado em sentido inverso,
isto é, o texto original não pode ser recuperado do texto cifrado e o texto encifrado é
garantidamente único. O MAC usado nos cartões inteligentes é calculado com o
algoritmo DES, que usa uma chave partilhada pelo cartão inteligente e pelo leitor de
cartões. O MAC é anexado ao fim da mensagem de texto antes desta ser enviada.
Quando a mensagem é recebida, o receptor calcula um valor MAC dos conteúdos da
mensagem, comparando o resultado ao MAC que acompanhou a mensagem. Porque até
mesmo mudando um caractér na mensagem, o MAC muda de um modo imprevisível, e
assim o receptor pode estar seguro que a mensagem não foi alterada depois do MAC ter
sido gerado. O MAC é uma garantia de integridade, uma garantia que a mensagem não
foi falsificada. Todas as mensagens que são trocadas entre o cartão inteligente e o leitor
de cartões deve ser protegida por exemplo pelo MAC.
3.6.3 Não repúdio (Non-Repudiation)
A criptografia pode também fornecer a autenticação das partes acoplados e assegurar a
não-repudiação (non-repudiation) da transacção. A não-repudiação é a prova da
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 43
integridade e da origem das trocas de dados na transacção. É a prevenção da
falsificação.
3.6.3.1 Assinatura Digital
Figura 3.9: Atribuição da Assinatura Digital e Verificação
3.6.4 Autenticação
Antes que duas partes entrem em negociações, cada uma tem de se certificar que a outra
parte está autenticada.
Por exemplo, antes de um “fulano” aceitar uma mensagem com assinatura digital de
“sicrano”, quer ter a certeza que a chave pública pertence a “sicrano” e não a alguém
que se fez passar por “sicrano”. Isto é o que o certificado faz.
3.6.4.1 Certificados
Os certificados são garantias dadas pela autoridade que emite o certificado e que
assegura que o portador do certificado é quem declara ser. Em suma, um certificado é
simplesmente uma mensagem digital assinada que contém informação sobre o portador
do certificado e uma cópia da chave pública do proprietário. Qualquer um que receba o
certificado tem a garantia que a chave contida no certificado é autêntica, porque é
assinada pela autoridade emissora, que é também uma entidade de confiança.
Na Internet, por exemplo, os certificados usados são os SSL (Secure Sockets Layer). O
web browser obtém o certificado do web server e usa a chave pública que está dentro do
certificado para cifrar a chave inicial da codificação. Similarmente, quando o cartão
inteligente envia dados para um terminal de cartões com Módulo de Acesso Seguro, o
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 44 Fernando Mostardinha * Sandra Silva
cartão inteligente vai construir um canal encriptado, como o SSL, usando a chave
pública do terminal do cartão.
Os campos de informação num certificado são elásticos e podem ser extendidos, no
entanto alguns campos são obrigatórios. Um emissor de certificados, é conhecido como
uma autoridade certificada e pode adicionar tantos campos quantos quiser,
transformando-se assim um modo flexível para associar informação pessoal com um
indivíduo particular e manter a integridade da informação. Por exemplo, um certificado
pode guardar os nomes de pessoas e endereços, assim como a data de início do emprego
das pessoas, ou mesmo o número de empregado, como também o seu nível de acesso de
segurança e assim por diante.
Antes de um certificado ser emitido a uma pessoa, dependendo da classe do certificado,
a autoridade emissora vai requerer provas legais obrigatórias, relativamente à identidade
da pessoa. A aplicação para um certificado de baixo nível, por exemplo, requer apenas
um passaporte ou a carta de condução, como prova de identidade. Um certificado de
nível mais elevado, necessita possivelmente de um documento/certificado original
passado pelo “notário” ou mesmo por um advogado. Quanto mais elevada é a classe do
certificado emitido, maior é a garantia que o receptor tem de que a pessoa é realmente
quem ele /ela reivindica ser.
As correntes do certificado estão baseadas unicamente na confiança. O receptor tem de
confiar na autoridade que verificou a autenticidade do portador do certificado e que este,
não alterou a informação antes de assinar o certificado. Se o receptor não confiar na
autoridade emissora, então o certificado não tem nenhum valor.
3.6.5 Verificação
É uma vantagem para ambos, quer ao proprietário do cartão inteligente quer ao emissor
do cartão inteligente, que a identidade do portador esteja confirmada antes que o cartão
seja usado. Antes de ambas as partes transaccionarem negócios, estas devem estar
asseguradas da identidade da outra parte. Quando conhecemos uma pessoa, usamos
indícios visuais e verbais para nos ajudar a reconhecer a outra pessoa. Numa
comunicação electrónica, usa-se a tecnologia de codificação para verificar de forma não
ambígua que a outra pessoa ou coisa é quem reclama ser.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 45 Fernando Mostardinha * Sandra Silva
3.6.5.1 Códigos de Identificação Pessoal (PIN)
Um Código de Identificação Pessoal, PIN, (Personal Identification Number) tem
geralmente uns quatro ou um cinco dígitos numéricos e que o portador do cartão
inteligente tem de memorizar. O PIN é seguramente armazenado dentro do cartão
inteligente, de uma maneira que nunca possa ser lido no mundo exterior. Os dados e as
funções do cartão inteligente podem ser protegidos de uma maneira que permita o
acesso do mundo exterior unicamente depois do código PIN correcto ser introduzido.
A IBM MFC pode armazenar até dois códigos de PIN por aplicação mas normalmente
só um código de PIN é requerido. Isto simplifica a interface do utilizador. É portanto
possível programar o segundo código de PIN, como um código de PIN do
administrador. Por exemplo, isto pode ser usado para desbloquear o cartão (como o
código PUK dos cartões de telemóvel) caso o utilizador se tenha esquecido do primeiro
código de PIN, ou se deu entrada de um código incorrecto demasiadas vezes.
O PIN pode ser atribuído e armazenado no cartão durante a personalização. O programa
de aplicação pode fornecer o código de PIN de duas maneiras diferentes. Se o utilizador
tiver um leitor inteligente para cartões (por exemplo um leitor de cartão inteligente com
um teclado e um monitor), então a aplicação pode pedir que o leitor de cartão inteligente
indique um alerta da senha e a aceite a entrada do utilizador. Se o utilizador tiver um
leitor simples para cartões inteligentes, depois o código de PIN pode ser introduzido
dentro da própria aplicação do programa e enviar ao leitor de cartão esperto.
Com a abundância de aplicações para cartões inteligentes, as pessoas estão sujeitas para
memorizar cada vez mais números de PIN. Isto deixa alguns utilizadores à beira de “um
ataque de nervos”. Afinal de contas, quem é que consegue memorizar 15 ou 20 códigos
diferentes de PIN? Às vezes, as pessoas rabiscam o número de PIN no próprio cartão
como meio aliviar a sua memória. Isto é perigoso porque em primeiro lugar anula todas
as vantagens de se ter PIN. Por causa disto é que recentemente se começou a dar maior
ênfase às medidas de segurança que contemplam medidas técnicas biométricas, como
meio de identificar uma pessoa.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 46
3.6.5.2 Biometria
Biometria é a ciência e a tecnologia para medir as características biológicas humanas,
para identificar de forma não ambígua um indivíduo dentro de um grupo de pessoas.
Uma das forças condutoras atrás do desenvolvimento da tecnologia biométrica da
identificação, é a relutância dentro da comunidade de utilizadores, para memorizar
senhas e números de PIN para identificação. Também, um número de PIN não identifica
excepcionalmente um indivíduo porque os números de PIN podem ser partilhados entre
pessoas diferentes ( e às vezes inadvertidamente quando estas escrevem os seus
números de PIN nos próprios cartões e depois perdem o cartão). A biometria identifica
as pessoas de uma forma real e não o conhecimento das mesmas de um segredo
partilhado.
Algumas das características biológicas que são únicas num indivíduo e que podem ser
medidas são:
• Assinatura
• Impressões digitais
• Timbre de voz
• Geometria da mão
• Retina do olho
• Identificação facial
As assinaturas e as impressões digitais são duas técnicas que são conhecidas desde há
centenas de anos. Ambas as técnicas são de uso popular, a última mais associada com a
identificação para as polícias. Usar máquinas para automatizar a análise é relativamente
recente.
Figura 3.10: Terminal Smart Card com reconhecimento de impressão digital
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 47 Fernando Mostardinha * Sandra Silva
A impressão digital nunca é armazenada ou guardada mas sim encriptada e
registada. Quando se põe o dedo no sensor, a imagem das impressões digitais é
imediatamente convertida em pontos mestres (cutpoints) e detalhados para subsequente
encriptação ser registada como “template”. Na verificação, com o toque do dedo do
utilizador, o “template” original é recuperado da base de dados e os pontos mestres e
detalhes são comparados. Se a comparação for coincidente o sistema reconhece o
portador e diz que este está autorizado. [7]
A pré-compilada base de dados de cutpoints, pode ser armazenado num cartão
inteligente, porque os dados ocupam um espaço muito pequeno, ou seja,
aproximadamente 300-800 bytes. A impressão digital feita na estação biométrica pode
ser matematicamente comparada a uma referência e uma boa estatística será aceite
como individual.
O registo efectua-se com um toque de dedo apenas e o tempo total de cada registo é,
normalmente, 5 segundos. A verificação leva apenas 1 segundo. [7]
A técnica biométrica que usa a geometria da mão é uma técnica que usa as
características do tamanho e forma da mão das pessoas para escolher uma pessoa de um
grupo. A velocidade de reconhecimento é relativamente rápida. Também, o tamanho da
referência padrão é pequeno, normalmente de 10-30 bytes. Assim sendo pode
facilmente ser armazenada num cartão inteligente. A limitação principal da geometria
de reconhecimento da mão é que o tamanho do grupo deve ser pequeno. Esta técnica é
aplicada geralmente para facilitar o acesso aonde o número total de pessoas permitidas a
um acesso é relativamente pequeno, na maioria uma dúzia de pessoas.
O modelo padrão dos vasos sanguíneos na parte traseira da retina do olho funciona
também como se fosse uma impressão digital e é única a cada pessoa. Um laser de baixa
potência, pode fazer a digitalização da retina e gravar o modelo. Assim como num
sistema de análise da impressão digital, o modelo da retina pode ser comparado
estatisticamente e armazenado no cartão, para posterior comparação e respectiva
autenticação de um indivíduo.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 48
Hoje em dia, os cartões inteligentes contêm dados de referência que serão usados
pela estação biométrica. Esta, vai comparar os dados obtidos dinamicamente das
características biológicas com os dados de referência armazenados no cartão inteligente.
A comparação é feita na estação biométrica e não dentro do próprio cartão inteligente.
Assim, a segurança do sistema é dependente da segurança da própria estação
biométrica. Por exemplo, se um sensor da impressão digital for construído num teclado
da estação do computador, a segurança do sistema não é melhor do que as medidas
preventivas no lugar para impedir alterar o teclado e os seus fios a si ligados.
Figura 3.11 - Comparação dos diversos factores dos vários métodos de identificação tradicionais e
biométricos
O grupo do desenvolvimento do cartão inteligente da IBM montou a tabela acima para
comparar diversos factores dos vários métodos tradicionais e biométricos de
identificação. Esclarecendo melhor as colunas da tabela:
Acessibilidade A aceitação na comunidade de utilizadores para usar este método de
identificação. A percentagem da figura da tabela é probabilidade para
que um utilizador do sistema aceite essa tecnologia e a use. Claro que, a
taxa de aceitação é apenas aproximada, porque os factores sociais, país
de origem, idade e por aí adiante vai afectar estes números. Geralmente,
um número mais elevado é melhor.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 49 Fernando Mostardinha * Sandra Silva
Custo do registo O “preço de admissão” ou o investimento inicial que uma
companhia deve fazer para esta tecnologia.
Rejeita A probabilidade de falsas recusas. Esta figura é uma probabilidade que o
dispositivo vai rejeitar na tentativa de um usuário autorizado usar o
sistema. Um número mais baixo é melhor.
Substituições A probabilidade da falsa aceitação. Esta figura é a probabilidade que um
utilizador desautorizado será aceite pelo dispositivo em vez de ser
rejeitado. Um número mais baixo é melhor.
Tamanho do ficheiro O número aproximado de bytes que um ficheiro de referência
ocuparia no cartão inteligente. Obviamente, um número mais baixo é
melhor, pelo menos, nos termos do consumo da memória do cartão
inteligente.
Custo do dispositivo O preço relativo da unidade em quantidades grandes.
É provável que as técnicas biométricas sejam usadas de acordo com a entrada do código
de PIN. Há várias razões legais para isto. Introduzindo um código de PIN num terminal
do cartão, é mais do que um meio para identificar um indivíduo, é um consentimento
pela pessoa que introduz o PIN para o operador da aplicação inteligente do cartão que
ele/ela concorda com os termos e as condições da transacção. É inconcebível fazer uma
digitalização da retina de uma pessoa, de uma certa distância como se essa pessoa
passasse por um sensor, fosse considerado uma forma de consentimento por essa
pessoa, num sentido legal.
Os padrões da biometria estão sendo desenvolvidos pelo consórcio BioAPI
(http://www.bioapi.org), mas este esforço é ainda embrionário, uma vez que esta
entidade foi estabelecida em Abril de 1998.
3.7 Leitores / Terminais para Smart Card
Há vários tipos diferentes de leitores para cartões inteligentes, também conhecidos
como dispositivos de aceitação de cartões, ou IFDs (dispositivo de interface). O termo
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 50
"leitor" (reader) pode ser enganador, pois que estes dispositivos também podem
escrever nos cartões.
Um pouco da inteligência do sistema está presente no terminal do cartão, uma vez que o
leitor e o cartão têm que se autenticar um ao outro.
Há muitos modos de classificar os leitores de cartões inteligentes:
• Tipo de cartão: contacto ou sem fios(contactless)
• Funcionalidade : funções de simples a complexas
• Stand alone vs online
• Produto final ou em OEM para ser integrado noutra máquina, como ATM de
bancos,
• Quiosques, distribuidores automáticos de máquinas, etc.
• PC attachment: PCMCIA, RS232, etc
• Preço: desde uns escassos 100 US dólares para leitores RS232 até uns milhares
de dólares para leitores de máquinas de dinheiro
Figura 3.12: Leitor Smart Card convencional ps/2 (à esquerda) e USB (à direita)
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 51 Fernando Mostardinha * Sandra Silva
3.8 Desenvolvimento de ferramentas para Smart Card
Codificar aplicações para um cartão inteligente requer muita “ginástica”. O
programador não só tem que saber a linguagem de programação e a plataforma onde o
código é desenvolvido, mas também o sistema operativo do cartão inteligente, o leitor
de cartão inteligente, o protocolo de comunicação entre o cartão inteligente e o leitor, a
estrutura de arquivo do cartão inteligente, etc. Esta situação foi reconhecida pela
indústria e a maioria dos vendedores de Smart Cards fornecem ferramentas de
desenvolvimento para os seus clientes
O ToolKit da IBM para o Cartão Inteligente é dos mais completos e uma das
ferramentas mais importantes para desenvolvimento de aplicações para cartão
inteligente.
Usando o ToolKit da IBM, um colaborador de aplicações não precisa de saber em
detalhe o sistema operativo interno do cartão inteligente.
3.9 Gestão do Smart Card
O cartão inteligente tem um ciclo de vida, que vai desde o seu fabrico até à sua
destruição. Neste processo está incluído desde a personalização, à distribuição para o
utilizador, passando pela substituição, etc. Ao administrador do ciclo de vida de cartão é
chamado Sistema de Administração de Cartão (CMS) e este tem de passar por várias
fases participantes na vida de um cartão inteligente:
• Fabrico do Chip
• Fabrico do módulo
• Fabrico do cartão de plástico
• Departamento de serviço de emissão de cartão
• Companhia de software e sistemas de integração para disponibilização da
inicialização do Smart Card e respectivo software de personalização
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 52 Fernando Mostardinha * Sandra Silva
• Emissor de cartões
• Fornecedor de aplicações para o cartão
• Renovação/modificação/revogação do cartão
Algumas companhias podem desenvolver várias funções no processo de fabrico do
cartão, produção e emissão. Mas na prática, as companhias fazem alianças no processo
de fabrico para cada tecnologia (como chip, máscara, módulos, plástico, e
personalização), pois isto requer processos e ferramentas especiais. O investimento em
cada área pode ser muito grande e caro.
Para emitir um cartão inteligente a um titular de cartão de crédito, há normalmente dois
passos: inicialização e personalização. Durante o passo de inicialização, a estrutura de
arquivo e de algumas chaves estão carregadas. Durante o período da personalização, os
dados pessoais do titular de cartão de crédito, como nome, endereço, conta, etc., ou
mesmo chaves encriptadas, estão carregadas no chip. Parte desta informação também
está impressa no plástico e codificada na banda magnética, se o cartão a tiver.
3.10 Alguns exemplos de aplicações para projectos Smart Card
Há muitas aplicações e projectos para cartões inteligentes bem sucedidos, em todo o
mundo. Baseado no número dos cartões usados actualmente, há mais cartões
inteligentes emitidos na Europa do que em qualquer outro continente. Os cartões pré-
pagos de telefone (cartões de memória) são ainda a maior parte dos cartões existentes no
mercado.
Alguns exemplos das aplicações e dos projectos são listados abaixo para fornecer uma
ideia de onde os Smart Card são usados:
• Banca:
- Geldkarte – Alemanha
- Visa Cash – projecto piloto em Nova York, 1996 Atlanta Olympics
- Mondex – piloto em vários países
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 53 Fernando Mostardinha * Sandra Silva
- Proton – Bélgica e outros 11 países, US American Express pilot
• Campus Card:
- Cartão de estudante da universidade de Dutch – Holanda
- Cartão de estudante da universidade do estado da Flórida – EUA
- Cartão de estudante da universidade Michigan – EUA
- Cartão de empregado da IBM– Alemanha
• Transportes
- American Express Corporation Card pilot (Hilton, American Airline,
Continental Airline) – EUA
- Lufthansa, Alemanha
• Saúde:
- Sesam Vitale – França
- Diabcard
- RAMQ
- Mulheres e crianças – EUA, Western Governors Association
• Governamentais:
- Marc card – EUA
- Cartão de cidadão – Finlândia
• Telecomunicações:
- Chipper – Holanda
- Telecom, Malásia
- Telstra, Austrália
• Retalho (loyalty)
- IC One (EUA)
- Shell (Reino Unido)
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 54 Fernando Mostardinha * Sandra Silva
3.11 Futuro dos Smart Cards
Os analistas da indústria e a imprensa especializada previram um futuro sorridente para
os Smart Cards. Em apenas alguns anos biliões de cartões estão previstos circularem
entre nós.
Os analistas da indústria e os mass media especializados concordam também que os
cartões inteligentes têm ainda muito espaço de manobra para penetrar num dos
mercados mais interessantes do mundo: os EUA.
Há varias razões para tal facto:
• Nenhumas aplicações de grande escala usadas pelo governo, para uso dos
cidadãos, como por exemplo os serviços de saúde
• Nenhuma infra estrutura para cartões inteligentes: muitas lojas na Europa têm
algum tipo de leitores de cartão
• Os clientes e os comerciantes dos EUA estão mais dispostos a aceitar o custo de
cartões de crédito do que os seus colegas europeus
• Poucas infrastructuras com Smart Cards: poucas lojas na Europa têm poucos
leitores de cartões
Os telefones celulares nos EUA não seguem o padrão do GSM (Global System for
Mobile communications), que usa o cartão inteligente dentro do telefone. Na Europa os
telefones usam o GSM standart. Estes telefones usam cartões inteligentes com um
sistema operativo especial e o seu tamanho é menor do que o tamanho de um cartão de
crédito.
Uma outra razão para que esta situação aconteça nas comunicações dos EUA, são as
linhas directas ou mesmo comutadas não serem tão caras como no resto do mundo.
Nesta altura uma pergunta se pode levantar: o que é que isto tem a ver com o uso dos
cartões inteligentes?
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 55 Fernando Mostardinha * Sandra Silva
Muitas aplicações dos cartões requerem uma transacção online, por exemplo o
cartão de crédito pode requer verificar a validade do cartão. A parte pulcritude do cartão
inteligente é que ele permite uma verificação comercial online, permitindo
posteriormente a autenticação offline mantendo assim uma chamada de telefone. Em
França há cartões de crédito e de débito que usam cartões inteligentes com esta
finalidade.
Um bom exemplo de uma aplicação offline é Porta Moedas Multibanco. O utilizador
carrega a “bolsa inteligente” do cartão com o dinheiro e pode ir às compras com ele.
Quando o utilizador mostra o cartão PMB ao comerciante, este não tem necessidade de
verificar a autenticidade e credibilidade do cartão assim como do “dinheiro” existente
no cartão.
Outra pergunta que pode surgir nesta altura é: - Mas afinal porque é que as
comunicações nos EUA não são tão caras como na maior parte dos outros países?
A resposta é óbvia, pois são os governos que detêm esses monopólios, embora essa
situação tenha tendência a mudar com o aumento das privatizações.
É portanto necessário descobrir uma aplicação fora de série nos EUA que consiga
fomentar o aumento e a penetração de cartões inteligentes neste mercado. Claro, que
não sabemos que tipo de aplicação pode ser, mas como se disse anteriormente, a grande
vantagem das características do cartão inteligente, do ponto de vista de certos autores, é
a segurança e a mobilidade. Uma aplicação com estas características deve ser o
suficiente para entrar no mercado.
Há uma situação que pode ajudar este negócio no uso de cartões espertos: o medo de
que os hackers ataquem certa informação sensível na Internet. Outra é proteger os
recursos, negando o acesso a permissões que contêm a informação valiosa.
Neste documento dá-se particular ênfase a este tipo de aplicação, ou seja, o recurso,
como a assinatura digital, passando pelas características pessoais e intransmissíveis, a
biometria, passando pelo controle de acesso, etc.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 56 Fernando Mostardinha * Sandra Silva
Em resumo, para o futuro prevê-se:
• Na América do Norte o uso de cartões inteligentes para autenticação será
provavelmente um dos principais incentivadores no aumento do uso dos cartões.
• Nos países emergentes onde as telecomunicações ainda têm que alcançar certos
padrões e preços dos praticados nos EUA, o uso de cartões inteligentes para
transacções offline será o factor principal no aumento do uso do cartão
inteligente.
• Na Europa, o uso dos cartões por parte dos governos para os ramos da saúde e
assim como outros programas estatais será um factor decisivo na expansão do
mercado do cartão inteligente.
3.12 PC/SC
3.12.1 Interface de Migração PC/SC
A interface de migração da PC/SC permite que a pessoa que desenvolve aplicações para
escrever em determinadas interfaces específicas de PC/SC e usar os serviços
equivalentes num ambiente não Windows. O fabricante do leitor do cartão inteligente,
necessita fornecer drivers para o hardware que vai trabalhar com a interface de
migração da plataforma específica na PC/SC. A figura abaixo mostra uma comparação
entre a migração de PC/SC e de PC/SC. O gerente de recursos da migração de PC/SC
implementa só um subconjunto das funções da API de padrões de PC/SC.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 57 Fernando Mostardinha * Sandra Silva
Figura 3.13: Interfaces de migração PC/SC vs PC/SC
Alguns exemplos das aplicações que usam a relação de migração de PC/SC são:
• Solução da IBM para assinatura digital
• Plataforma OpenCard (OpenCard Framework)
• Ferramenta da IBM para o cartão inteligente
3.13 Comunicação Smart Card
3.13.1 Modelo de Comunicação Smart Card
O caminho de comunicação entre o cartão e o cliente (host) é half-duplex, ou seja, os
dados tanto podem ser enviados do host para o cartão, ou do cartão para o host, mas
nunca ao mesmo tempo.
Quando dois computadores estão a comunicar um com o outro, estão a trocar pacotes de
dados, os quais foram construídos para respeitarem o protocolo TCP/IP. Do mesmo
modo, os cartões comunicam para outros computadores usando os seus próprios pacotes
de dados, chamados APDU (Application Protocol Data Units). Uma APDU contém um
comando ou uma mensagem de resposta.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 58
Figura 3.14: Comunicação através de APDU
No mundo dos cartões, o modelo aplicado é o do mestre escravo (master-slave). O
cartão inteligente tem sempre um papel passivo (slave), esperando por um comando
APDU do cliente. Depois executa a instrução especificada no comando e responde para
o host com uma resposta APDU. Os comandos de APDUs e as suas respostas são
trocados alternativamente entre o cartão e o cliente, como mostra na figura seguinte:
Figura 3.15: Modelo de comunicação do Smart Card
3.14 Protocolo APDU
As comunicações APDU são baseadas num modelo da comando-resposta, como
apresentadas no modelo ISO 7816-4. Geralmente, uma applet permanece à espera até
que um comando APDU seja passado à aplicação, requerendo algum tipo de
processamento. As aplicações processam os comandos e retornam uma resposta.
Figura 3.16: Modelo Comando-Resposta
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 59
Uma comunicação entre o leitor e cartão é baseada geralmente num de dois
protocolos de ligação, o byte oriented T=0, ou o protocolo block-oriented T=1. Em
alternativa, os protocolos referidos como T=USB e T=RF podem ser usados. A classe
JCRE APDU esconde alguns detalhes do protocolo da aplicação, mas não de todos,
porque o protocolo T=0 é particularmente complexo.
3.14.1 Comando APDU
A estrutura de um comando APDU é controlada pelo valor do seu primeiro byte e na
maioria de casos e é parecido com:
Figura 3.17: Estrutura do Comando APDU
Um comando APDU requer um cabeçalho e um corpo opcional, contendo:
CLA (1 byte): Este campo obrigatório identifica uma aplicação específica da
classe de instruções. Valores CLA (classe) estão definidos nas especificações
ISO 7816-4:
Figura 3.18: Valores CLA ISO 7816
Em teoria, pode-se usar todos os valores CLA 0x80 ou superiores para
instruções de aplicações específicas, mas na maioria das implementações para
Java Card, só os apresentados a negro são actualmente reconhecidos.
INS (1 byte): Este campo obrigatório indica uma instrução específica dentro da
classe da instrução identificada pelo campo CLA. O modelo ISO 7816-4
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 60
especifica as instruções básicas para usar-se para o acesso aos dados no
cartão, quando é estruturado de acordo com um sistema de ficheiro on-card
como definido no padrão. As funções adicionais foram especificadas noutra
parte do padrão, algumas delas são funções da segurança. Na tabela abaixo,
pode-se ver uma lista de algumas instruções do ISO 7816. Podem-se definir os
próprios valores específicos para a aplicação INS, apenas quando se usa um
valor apropriado do byte CLA, de acordo com o padrão.
Figura 3.19: Valores ISO 7816-4 INS quando CLA = 0X
P1 (1 byte): Este campo obrigatório, define a instrução parâmetro 1. Pode-se
usar este campo para qualificar o campo INS ou para dados de entrada.
P2 (1 byte): Este campo obrigatório, define a instrução parâmetro 2. Pode-se
usar este campo para qualificar o campo INS ou para dados de entrada.
Lc (1 byte): Campo opcional que indica o número de bytes no campo do
comando
Data (variável, Lc número de bytes): Campo opcional que guarda o comando de
dados
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 61
Le (1 byte): Este campo opcional específica o número de bytes no campo
de dados da resposta esperada
Dependendo da presença do comando de dados e se uma resposta é exigida, há quatro
variações do comando APDU. Deve-se ter atenção e estar preocupado sobre estas
variações só quando se está a usar o protocolo T=0:
Figura 3.20: Quatro possíveis estruturas do Comando APDU
3.14.2 Resposta APDU
O formato de Resposta APDU, é muito mais simples, mas exige à semelhança do
Comando APDU campos obrigatórios e opcionais, ou seja:
SW1 (1 byte): Campo obrigatório que indica o status word 1
SW2 (1 byte): Campo obrigatório que indica o status word 2
Tabela 3.1: Resposta APDU
O valor das status words, estão especificados na norma ISO7816-4:
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 62
Figura 3.21: Códigos de Resposta Status
Figura 3.22: Quatro possíveis estruturas do Comando APDU [9]
3.14.3 Processando APDUs
Cada vez que chega um APDUs para um applet seleccionado, o JCRE invoca o método
process() do applet, passando o APDU que chegou como um argumento. O applet tem
de analisar o comando APDU, processar os dados, gerar uma resposta APDU e devolver
o controle ao JCRE.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 63 Fernando Mostardinha * Sandra Silva
Figura 3.23: Selecção do método
3.15 Limitações da linguagem Java Card
Há limitações na programação do modelo, como por exemplo se mostra na tabela
seguinte:
Tabela 3.2: Sumário das limitações da linguagem Java Card
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 64
Capítulo 4
4 JavaCard Um cartão JavaCard, não é mais que um Smart
Card que carrega e executa programas escritos em
Java. Ao contrário de um smart card tradicional,
que contém apenas ficheiros de dados e onde os
únicos programas executados no cartão são os
fornecidos pelo próprio sistema operativo, num
JavaCard, o programador pode codificar as suas funções em Java, testá-las fora do
cartão e depois carregar de forma segura o novo código no cartão. Este código pode ser
carregado em qualquer cartão Java Card sem necessidade de recompilação.
Embora os programas codificados para correr num Smart Card usem apenas um
subconjunto de Java, proporcionam mesmo assim, um grande avanço relativamente à
codificação de um programa para um sistema operativo de um smart card tradicional.
Com os cartões JavaCard, a segurança no cartão aumentou significativamente. Sendo a
linguagem Java, uma linguagem interpretativa, e todas as instruções poderem ser
verificadas antes de serem executadas, prevenindo assim que uma aplicação execute
funções ilegais, tais como aceder a dados de outras aplicações [1].
Um cartão JavaCard pode suportar múltiplas aplicações de diferentes fornecedores de
serviços. Devido ao mecanismo de firewall do JavaCard, as aplicações não podem
aceder umas às outras a menos que sejam explicitamente permitidas para tal.
Uma funcionalidade do cartão JavaCard é que este pode ser continuamente actualizado
com aplicações novas ou actualizadas, sem necessidade de adquirir um novo cartão.
Essencialmente, a tecnologia JavaCard define uma plataforma segura, portátil e multi-
aplicacional que incorpora muitas vantagens da linguagem Java.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 65 Fernando Mostardinha * Sandra Silva
Os benefícios desta tecnologia são portanto:
• A facilidade do desenvolvimento das aplicações, devido à plataforma aberta que
esta tecnologia oferece e que define aplicações standard de interfaces de
programação. A plataforma encapsula a complexidade subjacente e os detalhes
do sistema JavaCard. Os projectistas das aplicações trabalham com interfaces
de programação alto-nível, podendo assim concentrar grande parte do seu
esforço nos detalhes da aplicação.
• Segurança. Tal como foi referido anteriormente, as aplicações na plataforma
JavaCard encontram-se separadas por uma firewall, podendo assim o sistema
salvaguardar-se de possíveis tentativas, por parte de aplicações hostis, de
danificar outras partes do sistema.
• Independência de Hardware. Esta tecnologia é independente do tipo de
hardware usado. É capaz de correr em qualquer processador smart card.
• Capacidade de guardar e administrar múltiplas aplicações.
• Compatibilidade com os standards smart card existentes. A tecnologia smart
card é baseada no standard internacional de smart cards ISO7816, suportando
assim facilmente sistemas e aplicações smart card que são geralmente
compatíveis com o ISO7816 [2].
4.1 Arquitectura de um Javacard
A sua arquitectura é muito idêntica à de um smart card. Possui um CPU, uma memória
ROM, uma EEPROM e possivelmente um co-processador criptográfico no chip.
O seu sistema operativo consiste numa máquina virtual Java (JVM), que executa
programas escritos em Java. A máquina virtual JavaCard (JCVM) corre uma versão
especial e limitada de Java. Serviços, tais como comunicar com um leitor de smart card
ou criar dados em memória, são executados para a máquina virtual JavaCard por
bibliotecas de programas em Java chamadas classes. Estas classes podem ser carregadas
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 66
na ROM do smart card quando o chip é fabricado ou podem ser carregadas na
memória EEPROM depois, juntamente com aplicações do smart card.
Importa salientar que, enquanto num smart card tradicional todas as funções
encontram-se presentes no sistema operativo do cartão no momento em que este é
adquirido pelo utilizador, num JavaCard, a maioria das aplicações serão adicionadas
neste pelo próprio utilizador [1].
Figura 4.1: Plataforma Global da Arquitectura de um cartão [5.1]
A máquina virtual JavaCard encontra-se dividida em duas partes distintas, uma que
corre fora do cartão e uma outra que corre dentro do cartão. Muitas das tarefas de
processamento tais como linkagem e optimização, são dedicadas à máquina virtual que
corre fora do cartão onde os recursos normalmente não são uma preocupação.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 67
Figura 4.2: Arquitectura do sistema Java Card
Além de suportar a linguagem Java, a tecnologia JavaCard define um ambiente que
apoia a memória do smart card, a comunicação e segurança.
A característica mais significativa do ambiente JavaCard consiste na clara separação
entre o sistema e as aplicações. O runtime environment encapsula a complexidade
subjacente e os detalhes do sistema do smart card. As aplicações requerem serviços e
recursos através de uma bem definida interface de programação de alto nível.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 68
4.2 Características de segurança de um Java Card
A linguagem Java, por si própria é uma linguagem de
programação segura. O Java para além de deter programas
maliciosos garante a integridade dos dados. O acesso a todos
os métodos e aos exemplos disponibilizados, são controlados
pelos “modificadores” de acesso, que vão definir o nível do
controlo de acesso para cada método. Um método pode ser
declarado para ser público, protegido, confidencial, ou privado
e protegido.
Este tipo de declaração ajuda a tornar seguro o sistema, pois restringe o acesso ao
sistema por parte de objectos críticos e por códigos de Java não confiáveis, ou mesmo
duvidosos, cujos tempos de compilação seriam ainda significativos.
O compilador verifica também para se certificar de que o programa não acede a algumas
variáveis não inicializadas. Este avançado mecanismo protege o cartão inteligente dos
programas maliciosos. Para além disso, não há ponteiros que possam ser acedidos pelos
programadores ou mesmo pelos utilizadores. Assim, os programas maliciosos não
podem “forjar” os ponteiros da memória.
As funções principais da segurança do cartão Java são a verificação do seu portador, a
autenticação do cartão, a autenticação do mundo externo e codificação e descodificação
dos dados. Esta é a parte necessária para a segurança na Internet e para o comércio
electrónico. Um cartão inteligente parece ser um dispositivo intrinsecamente seguro. Os
cartões inteligentes são a resistência “tampão”, pois o cartão inteligente tem todas as
boas características de segurança para negar aos visitantes indesejados o acesso ao
cartão.
No entanto, os cartões inteligentes, não são à “prova de bala”, porque há certos métodos
estáticos para desvendar e revelar as verdades dentro do cartão inteligente. Vários
ataques lógicos e físicos a cartões inteligentes têm sido desenvolvidos. Desde que a
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 69 Fernando Mostardinha * Sandra Silva
chave seja guardada numa EEPROM, a tensão ou uma temperatura invulgar pode
afectar o seu correcto funcionamento e operações de escrita.
As mudanças nas tensões podem libertar a fechadura de segurança sem apagar dados.
Alguns chips, têm sensores implementados, que causam um reset, quando as condições
da tensão fogem de escala, mas pode ocorrer um falso alarme.
Para ataques físicos, a radiação ultra-violeta (UV), pode apagar a “fechadura” da
EEPROM, podendo assim permitir que os dados na memória possam ser lidos.
O chip pode ser removido do cartão de plástico usando uma faca afiada. Usando ácido o
chip pode ser lavado, examinado e directamente atacado.
Em condições de laboratório, as chaves criptográficas podem ser reveladas, havendo
muitos outros métodos para “atacar” cartões inteligentes. Todavia, a maioria destes
métodos necessitam de condições de laboratório caras e equipas especializadas. De
qualquer forma, não se pode dizer que temos a segurança garantida. As técnicas de
encriptação e de chave pública, melhoram a segurança, mas a encriptação torna as
operações com o Smart Card mais lentas, graças ao até agora inadequado processador
interno
4.3 Máquina Virtual Javacard (JCVM)
Uma diferença primária entre a máquina virtual Javacard (JCVM) e a máquina virtual
Java (JVM) é que a JCVM é implementada como duas partes separadas.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 70
Figura 4.3: Criação de uma aplicação A parte respeitante à máquina virtual dentro do cartão inclui o intérprete enquanto que o
conversor, respeitante à máquina virtual fora do cartão, corre num PC ou numa
workstation. Juntos, implementam todas as funções da máquina virtual. O conversor
carrega e processa os ficheiros class que compõem um pacote Java e produz um ficheiro
CAP (Converted Applet File). Este, por sua vez é carregado num JavaCard e executado
pelo tradutor. Além da criação do ficheiro CAP, o conversor gera um ficheiro de
exportação que representa as API’s (Application Programming Interfaces) do pacote
convertido.
Tabela 4.1: Sumário das restrições do Java Card VM
4.3.1 Ficheiros CAP e ficheiros de Exportação
O ficheiro CAP contém uma representação binária executável das classes num
determinado pacote. O formato JAR é usado como o formato recipiente para os
ficheiros CAP. Sendo assim, o ficheiro CAP é um ficheiro JAR que contém um
conjunto de componentes, cada um deles armazenado como um ficheiro individual no
ficheiro JAR. Cada componente descreve um aspecto do conteúdo do ficheiro CAP, tais
como a informação da classe, informação de linkagem, entre outras. O formato CAP é o
formato no qual o software é carregado nos cartões JavaCard.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 71
Os ficheiros de exportação não são carregados nos cartões e por isso não são
directamente usados pelo tradutor. Eles são produzidos e utilizados pelo conversor para
propósitos de verificação e de linkagem. Podem ser considerados como os ficheiros
cabeçalho da linguagem C. Um ficheiro de exportação contém informação pública para
um pacote inteiro de classes. Define o nome da classe, os campos desta, entre outra
informação relativa à mesma. Contém também informação de linkagem usada para
resolver referências entre pacotes no cartão.
4.3.2 Conversor Javacard
O conversor toma como entrada não apenas os ficheiros class para serem convertidos
como também um ou mais ficheiros de exportação. Além da criação de um ficheiro
CAP, o conversor gera um ficheiro de exportação para o pacote convertido. O conversor
carrega todas as classes num pacote Java. Se o pacote importa classes de outros pacotes,
o conversor carrega também os ficheiros de exportação desses pacotes. O conversor
produz um ficheiro CAP e um ficheiro de exportação para o pacote convertido.
Figura 4.4: Conversão de um pacote
4.3.3 Descodificador/leitor Javacard
O descodificador/leitor Javacard realiza as tarefas de executar applets, de controlar a
alocação de memória e a criação de objectos. O leitor não carrega ele próprio os
ficheiros CAP, apenas executa o código que se encontra no ficheiro CAP.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 72
4.4 Instalador JavaCard e programa interface do instalador do cartão
Na tecnologia Java Card, os mecanismos para download e instalação de um ficheiro
CAP estão embutidos numa unidade chamada de instalador. O Instalador Java Card
reside no interior do cartão e coopera com um programa interface do instalador.
O programa interface do cartão transmite o código binário executável num ficheiro para
o instalador correr através de um dispositivo do cartão, através de uma dispositivo
acreditado pelo cartão (CAD).
O instalador escreve o binário na memória, liga-o com outra classe já colocada no
cartão, cria e inicializa todas as estruturas de dados que forem usadas internamente pelo
Java Card Runtime Environment.
Figura 4.5: Instalador JavaCard e programa de interface ao cartão [2]
4.5 Java Card Runtime Environment
O Javacard Runtime Environment (JCRE) consiste numa componente de sistema
Javacard que corre dentro do cartão. O JCRE é responsável pela administração de
recursos do cartão, pelas comunicações de rede, execução das applets e segurança
destas.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 73
O JCRE situa-se no topo do hardware do smart card e o sistema nativo. O JCRE
consiste na máquina virtual Javacard (JCVM), as API’s e as classes de sistema JCRE. O
JCRE fornece um sistema standard e interfaces API para as applets. Como resultado
disto, as applets são mais fáceis de escrever e são portáteis em várias arquitecturas
smart cards.
Figura 4.6: Arquitectura no cartão
A camada inferior do JCRE contém a máquina virtual Javacard (JCVM) e os métodos
nativos. O JCVM executa bytecodes, controla a alocação da memória, administra os
objectos e assegura a segurança do runtime. Os métodos nativos fornecem suporte ao
JCVM e ao sistema de classes da camada seguinte. São responsáveis pelo controlo dos
protocolos de comunicação de baixo-nível, administração de memória, suporte
criptográfico, por aí adiante.
Os sistemas de classes actuam como executivo do JCRE. São análogos ao core de um
sistema operativo. São responsáveis pela administração de comunicação entre as
aplicações do host e as applets Javacard, pelo controlo da criação das applets, selecção
e des-selecção. Para completar tarefas, tipicamente invoca métodos nativos.
Figura 4.7: A comunicação entre um applet e o host executado através de APDUs
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 74 Fernando Mostardinha * Sandra Silva
A aplicação Javacard framework define as API’s. O framework consiste em
quatro pacotes API. As classes API são compactas e usadas para desenvolver applets
smart cards. A maior vantagem deste framework é que torna-se relativamente fácil criar
uma applet. As applets acedem aos serviços do JCRE através das classes API.
Uma indústria específica ou negócio pode fornecer bibliotecas para proporcionar
serviços adicionais ou para melhorar a segurança e o modelo do sistema.
O installer possibilita o downloading seguro de software e applets para dentro do cartão
depois do cartão ser feito e emitido ao seu proprietário. O installer coopera com o
programa de instalação fora do cartão. Juntos, realizam a tarefa de carregar os
conteúdos binários dos ficheiros CAP. É um componente opcional do JCRE. Sem ele,
todo o software do cartão, incluindo as applets, devem ser escritas na memória do cartão
durante o processo de fabrico do cartão.
As applets Javacard são aplicações do utilizador na plataforma Javacard. São
controladas pelo JCRE.
O JCRE é inicilaizado aquando da inicialização do cartão. A inicialização do JCRE é
realizada uma única vez durante o ciclo de vida do cartão. Durante este processo, o
JCRE inicializa a máquina virtual e cria objectos para providenciar os serviços do JCRE
e administração das applets. À medida que as applets são instaladas, o JCRE cria as
instâncias das applets, e as applets criam objectos para armazenar dados.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 75
Figura 4.8: Arquitectura Java Card e Runtime Environment [5.2]
A maior parte da informação no cartão deve ser preservada mesmo quando a energia é
retirada ao cartão. Memória tipo EEPROM é usada para realizar esta preservação. O
ciclo de vida do JCRE é equivalente ao ciclo de vida completo do cartão. Quando a
energia é removida, a máquina virtual é apenas suspensa. O estado do JCRE e dos
objectos criados no cartão são preservados.
Da próxima vez que o cartão receber energia, o JCRE reinicia a execução da máquina
virtual carregando os dados da memória. É bastante importante salientar aqui que, o
JCRE não retoma a operação da máquina virtual no ponto exacto onde ela perdeu
energia. A máquina virtual é reajustada e executa do princípio do loop principal. O reset
do JCRE difere da inicialização, pois preserva as applets e os objectos criados no cartão.
Durante o reset, se a transacção não for completa previamente, o JCRE realiza as
operações de limpeza necessárias para colocar o JCRE num estado consistente.
O período durante o qual o cartão é inserido num reader ou CAD (Card Acceptance
Device) até ser removido deste é chamado de sessão CAD. Durante uma sessão CAD, o
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 76 Fernando Mostardinha * Sandra Silva
JCRE opera como um típico smart card, ou seja, suporta comunicação I/O através
de APDU’s (Application Protocol Data Units) com a aplicação host.
As APDU’s são pacotes de dados trocados entre as applets e as aplicações do host.
Cada APDU contém ou um comando do host para a applet, ou a resposta de uma applet
para o host.
Depois do reset do JCRE, este entra num loop, esperando por comandos APDU do host.
Este por sua vez, envia comandos APDU para a plataforma Javacard, usando a interface
de comunicação série via o ponto de contacto do cartão de input/output. Quando um
comando chega, o JCRE ou selecciona uma applet para correr como definido no
comando ou reenvia o comando para a applet correntemente seleccionada.
Esta, por sua vez, toma controlo e processa comandos APDU’s. Quando terminado, a
applet envia uma resposta para a aplicação do host e devolve o controlo ao JCRE. Este
processo repete-se quando o próximo comando chega [2].
4.6 Características do Java Card Runtime (JCRE)
Além de suporte do modelo da linguagem de programação Java, o JCRE suporta três
características adicionais de funcionamento:
Objectos temporários e persistentes – Por defeito, os objectos JavaCard , são
persistentes e são criados na memória persistente. O espaço e os dados deles são
abarcados pelas sessões CAD. Por razões de segurança e performance, as
aplicações podem criar objectos na RAM. Tais objectos são chamados objectos
transientes. Objectos transientes contêm dados temporários, que não são
persistentes através de sessões CAD.
Operações e transacções nucleares – A máquina virtual de Java, garante que
cada operação de escrita para um campo único de um objecto ou numa classe é
nuclear. A actualização do campo, tanto busca o novo valor como repõe valor
anterior. Para além disso, o JCRE fornece transacções de APIs. Uma aplicação
pode incluir várias operações de escrita numa transacção. Qualquer uma das
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 77
actualizações são completas, ou (se a falha ocorrer no meio de uma
transacção) nenhuma delas prossegue.
Applet firewall e mecanismos de partilha – A aplicação de firewall isola
aplicações. Cada applet corre num espaço designado. A existência e operação de
um applet não tem qualquer efeito, nas outras aplicações do cartão. A applet
firewall é forçada pela máquina virtual de Java Card assim que os bytecodes são
executados. Nas situações onde as aplicações precisam de partilhar dados, ou
aceder a serviços JCRE, a máquina virtual permite que tais funções atravessem
mecanismos de partilha seguros
Figura 4.9: Applet Firewall e partilha de objectos [5.2]
4.7 Java Card API
As aplicações de Java, JavaCard APIs, consiste em colocar classes pré-definidas, para
programar aplicações SmartCard, de acordo com o modelo ISO 7816. As APIs contêm
três pacotes, packages, e um pacote de extensão. Os três pacotes são java.lang,
javacard.framework e javacard.security. O pacote estendido é o javacardx.crypto.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 78 Fernando Mostardinha * Sandra Silva
Tabela 4.2: Java Card v2.2 javacard.framework
Tabela 4.3: javacard.framework.service
Tabela 4.4: javacard.security
Os criadores/construtores, developers, que estão familiarizados com a plataforma Java,
têm notado que muitas das classes de plataformas não são suportadas nas APIs do
JavaCard. Por exemplo, a plataforma da classe GUI interfaces, rede I/O e sistemas de
ambiente de trabalho I/O não são suportados. A razão prende-se com o facto de os smart
cards não terem display e usarem diferentes protocolos de rede e estrutura de sistema de
ficheiros.
As classes são compactas e sucintas. Incluem classes adaptadas da plataforma Java para
providenciar suporte à linguagem Java e serviços criptográficos.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 79
4.8 Java Card Applets
Java Card applets não devem ser confundidas com Java applets só pela simples razão
de terem o nome de applets. A applet Java Card é um programa que serve para unir
convenções que as permitem executar com o JCRE. A razão pelo qual se chamou applet
para aplicações Java Card, foi porque as applet do Java Card podem ser carregadas no
JCRE, depois do cartão ter sido fabricado. Ao contrário de outras aplicações que
precisam de estar inseridos em sistemas, as applet não precisam de ser gravados na
ROM, durante o fabrico. Preferencialmente, podem ser dinamicamente descarregados
para o cartão mais tarde.
Figura 4.10: Java Card Applet Life-Cycle Methods Uma classe applet é derivada da classe javacard.framework.Applet. A classe base
Applet é a superclasse para todas applets residentes num Java Card. A classe Applet é o
projecto que define as variáveis e os métodos de uma applet. A execução de uma applet
no cartão é uma applet instance, um objecto de uma applet. Assim como qualquer
objecto persistente criado, uma vez criados, uma classe applet reside no cartão para
sempre.
O JCRE suporta ambientes multi-aplicação. Applets múltiplos podem coexistir num
único cartão inteligente Java e uma aplicação pode ter várias instâncias. Um bom
exemplo disso é a instância do porta moedas, que pode ser criado para suporte de
dólares americanos e outro pode ser criado para suporte do €uro.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 80
4.9 Convenção de nomes para pacotes e aplicações
Os nomes dos pacotes e programas da plataforma Java que normalmente se usam são
unicode strings e um esquema de nomes baseado no senso comum. No entanto, na
plataforma Java cada applet instance é identificada de um modo único e seleccionada
por uma aplicação de identificação (AID). Cada pacote Java é designado por uma AID.
Quando carregada no cartão, o pacote é ligado a outros pacotes no cartão através dos
seus AIDs.
A norma ISO 7816 específica AIDs para serem usados como forma de identificação
única e certos tipos de ficheiros num sistema de ficheiros do cartão. Uma AID é um
array de bytes que podem ser interpretados como duas peças distintas, como mostrado
na figura abaixo.
Figura 4.11: Identificador de aplicação
A primeira parte tem um valor de 5 bytes conhecido como identificador fonte, RID
(resource identifier). A segunda parte tem comprimento variável e é conhecido como
extensão ao identificador proprietário, PIX (proprietary identifier extension). A PIX
pode ter de 0 a 11 bytes de comprimento. Assim, um AID pode variar de 5 a 16 bytes no
comprimento total.
4.10 Processo de desenvolvimento de uma applet
O desenvolvimento de uma aplicação JavaCard começa como qualquer outro programa
em Java: o programador escreve uma ou mais classes de Java e compila o código fonte
com o compilador Java, produzindo um ou mais classes de ficheiros, tal como
demonstrado na figura seguinte.
Depois, o applet é executado, testado e verificado num ambiente de simulação. O
simulador executa o JCRE no PC ou workstation. No ambiente de simulação, a
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 81 Fernando Mostardinha * Sandra Silva
aplicação corre na máquina virtual de Java e então a classe de ficheiros da
aplicação são executados.
Figura 4.12: Processo de desenvolvimento de uma applet
4.11 Limitações e problemas
Os fabricantes de cartões inteligentes têm que levar em muita consideração as
limitações físicas impostas pela ISO. O cartão não deve sofrer nenhuns danos físicos
mesmo que se dobre até um ângulo de 15 graus 30 vezes por o minuto. Estas limitações
significam que os acordos devem ser feitos quando o espaço disponível no chip é
dividido entre o processador, possíveis co-processadores, ROM, RAM e EEPROM.
Hoje em dia, os 32 kB da EEPROM são comuns e também alguns cartões com 64kB
estão disponíveis. Os de 128kB são uma realidade e os já há protótipos com 2MB.[6]
O uso da memória pode ser reduzido usando técnicas da compressão de dados. Embora
o código byte de Java seja razoavelmente sucinto, os programas continuam a repetir
padrões de código. Outro facto é o processador do cartão inteligente ser lento quando
comparado ao dos computadores desktop. Os padrões precisam que o processador do
cartão esteja a funcionar externamente de 3-5 MHz, embora possa usar internamente
uma frequência mais elevada.
Algoritmos criptográficos fortes requerem um co-processador. Cada operação do utente
do cartão JavaCard não deve demorar mais do que em segundo, logo a optimização e a
selecção cuidada dos algoritmos são ainda necessários.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 82 Fernando Mostardinha * Sandra Silva
A pior limitação é a quantidade de RAM. A memória RAM ocupam mais espaço
físico do que uma ROM ou EEPROM. Consequentemente, um cartão típico tem umas
escassas centenas de bytes de RAM. Isto tem sido tomado em consideração, aquando do
projecto de aplicações, mas ainda é uma limitação. O Java é uma língua interpretada, o
que pode fazer com que alguns algoritmos sejam mais lentos do que seriam de outro
modo. Uma boa optimização permanece ainda na redução do tamanho das linhas de
código e no tempo de execução, minimizando o assim o problema.[3]
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 83
4.12 Rivais e futuro do JavaCard
O Java serviu de base à plataforma aberta do VISA, mas não é a única multi-plataforma
do cartão inteligente disponível.
Figura 4.13: MULTOS, o principal rival do JavaCard e que deu origem ao Mondex, etc.
O Mondex internacional apareceu com o MULTOS. Este, carece ainda da máquina
virtual para correr programas em Java, mas permite que programas em linguagem C
tornem os cartões inteligentes numa plataforma competitiva com o JavaCard, assim
como montes de aplicações escritas e linguagem C existentes, poderem ser usadas com
poucas modificações nos cartões inteligentes.
Figura 4.14: Arquitectura MULTUS
Figura 4.15: Características técnicas do MUTUS
O microprocessador dos cartões são caros quando comparados aos cartões de fita
magnética usados extremamente pelo mundo neste momento. Especialmente o Cartão
Java com o chip desenvolvido, tem um custo estimado para 10 a 15 US Dólares no
mercado, enquanto que os cartões de fita magnética custam apenas 0.2 a 0.75 US
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 84 Fernando Mostardinha * Sandra Silva
Dólares. Outros cartões inteligentes mais evoluídos custam aproximadamente 7 a
15 US Dólares neste momento.
A crescente procura é essencial para baixar o preço e permitir que o JavaCard seja uma
plataforma atraente e apelativa para o software do cartão inteligente.
A adopção e a distribuição do posicionamento estratégico do cartão Java requerem
promoção de marketing, mais aplicações e ferramentas desenvolvidas no tempo.
O número de JavaCards podia facilmente chegar aos milhões dentro de poucos anos. A
procura foi prevista crescer significativamente em 10 anos.
O microprocessador 32 bits é muito provável que substitua o microprocessador 8 bits
num futuro muito próximo. São aceitáveis mais aplicações avançadas sem limitações e
portanto permitir que o cartão inteligente, JavaCard assegure uns trabalhos mais
complicados.
Falando agora de hardware, a RAM Ferro-eléctrica (FeRAM) pode a curto prazo
substituir a EEPROM. A FeRAM, não só é 20 vezes mais rápida como também a sua
capacidade é já de 128 kB.[3 ]
4.13 Conclusões
Perante tudo o que foi escrito anteriormente, pode-se dizer que um cartão inteligente
com recursos e componentes limitados pode executar trabalhos poderosos. Neste
capítulo, a maioria de características do cartão Java foram explicadas.
As características físicas, a máquina virtual do cartão Java, as aplicações básicas e os
casos de segurança foram discutidos. Para quase tudo, o cartão Java tem uma multi-
facetada plataforma de aplicações e parece ser uma óptima escolha para aplicações com
o cartão inteligente.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 85 Fernando Mostardinha * Sandra Silva
Por enquanto, a pouca procura, o custo elevado, os problemas de segurança e a
existência do rival MULTOS, são até ao momento os assuntos mais problemáticos, mas
que devem ser provisórios.
O comércio electrónico não está necessariamente a travar a tecnologia inteligente do
cartão tão rapidamente quanto a indústria esperava. [3]
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 86 Fernando Mostardinha * Sandra Silva
Capítulo 5
5 Protótipo desenvolvido
5.1 Introdução
Uma vez que os conceitos tratados e necessários para a execução deste projecto, eram-
nos praticamente novos, iniciamo-lo através da leitura de toda a informação disponível
acerca dos mesmos.
Certo tipo de material de leitura foi disponibilizado pelos nossos orientadores de
projecto e outros ainda, retirados de alguma bibliografia e da Internet. Todos eles foram
usados e necessários para nos fornecer o background devido para a realização deste
projecto.
O estudo da linguagem Java foi também necessário pois não tínhamos qualquer
experiência com ela.
5.2 Início da aplicação, dos conceitos aprendidos e estudo do
software disponível
Através do software Cyberflex Access Toolkit 4.3, iniciámos o estudo do software, e da
“mecânica” dos cartões, isto é, como realmente funcionam, como se programam, como
se testam. Este estudo foi realizado a partir de alguns programas disponíveis no
software (demos), e culminou com a realização de um simples programa feito por nós.
Este, consistiu num cartão de autocarro, inicialmente com dez viagens, e que
posteriormente iam sendo debitadas de cada vez que fosse realizada uma viagem, ou
várias ao mesmo tempo (o utilizador tem a possibilidade de pagar o seu bilhete e o(s)
do(s) acompanhante(s)). É também disponível a opção de visualização do saldo do
cartão.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 87 Fernando Mostardinha * Sandra Silva
De forma a realizarmos o nosso programa, iniciamos a fase de projecção da
aplicação. Isto é, definir a arquitectura desta através de alguns passos importantes:
• Especificar as suas funções;
• Projectar a estrutura da aplicação;
• Definir a interface entre a aplicação e o host.
As funções desta pequena aplicação, como foram já referidas acima, consistiam no
débito de viagens (Debit) e na visualização do saldo do cartão (getBalance).
A estrutura da aplicação foi definida através de métodos pertencentes à classe
javacard.framework.Applet, e as quais referimos abaixo:
• public static void install (byte[ ] bArray, short bOffset, byte bLength);
• protected final void register( );
• public boolean select( );
• public abstract void process(APDU apdu);
Todas as aplicações Javacard devem derivar desta classe. A aplicação anula um ou mais
destes métodos públicos para executar o comportamento desejado. A applet tem de
definir e implementar o método static install de forma a criar a instância da applet e
registar a instância no JCRE invocando o método register.
No método process, a applet interpreta cada comando APDU e realiza a função
especificada pelo comando. O método select é invocado pelo JCRE quando a applet é
seleccionada. A applet pode anular este método para providenciar funções de
inicialização ou limpeza. Contudo, nem todas as applets requerem inicialização ou
limpeza.
Uma applet a correr num JavaCard comunica com o host do lado do CAD, usando
APDU’s, tal como referido anteriormente neste relatório. Essencialmente, a interface
entre a applet e a aplicação host consiste um conjunto de comandos APDU que são
acordados e suportado por ambos, a applet e o host. O conjunto de comandos são
definidos de acordo com as funções da applet.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 88 Fernando Mostardinha * Sandra Silva
Para cada comando APDU, a applet deve primeiro descodificar o valor de cada campo
do cabeçalho. Se o campo opcional de dados for incluído, a applet deve também
determinar o formato dos dados e o seu conteúdo. Sabendo como interpretar o comando
e ler os dados, a applet pode então executar a função pedida pelo comando.
Para o comando de resposta (response APDU), a applet deve definir um conjunto de
status words de forma a indicar o resultado do processamento do comando APDU
correspondente.
Durante um processamento normal, a applet retorna uma status words de sucesso
(0x9000, como especificada pela norma ISO7816). Se ocorrer um erro, a applet deve
retornar uma outra status word que identifique o estado interno ou o diagnóstico do
erro. Se o campo opcional de dados é requerido pelo response APDU, a applet deve
definir o que retornar.
o GET BALANCE APDU
O nosso programa suporta as funções de getBalance e de Debit, as quais definimos de
seguida.
Comando APDU
CLA INS P1 P2 Lc Data Field Le
0xC0 0x10 0x0 0x0 - - 1 Tabela 5.1: Comando APDU definido
• O campo CLA identifica a estrutura do comando, definida por nós, tais como
todos os outros campos do comando.
• O campo INS identifica a instrução a realizar, neste caso, a operação de
getBalance.
• P1 e P2 não são usados neste caso, e por isso têm os dois o valor zero.
• O campo Lc, neste comando não tem nenhum valor pois nenhuma
informação vai ser enviada para o cartão, mas sim recebida deste.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 89 Fernando Mostardinha * Sandra Silva
• O Data Field corresponde ao campo de dados e como referido no ponto
acima, não toma nenhum valor.
• O campo Le corresponde ao comprimento dos dados esperados pelo
response, e neste comando tem o comprimento de 1 byte.
Response APDU
Data Status words Significado das Status Words
Número de viagens 0x9000 Operação bem sucedida
Tabela 5.2: Response APDU definido
• O campo Data da response APDU contém o balanço das viagens.
o DEBIT APDU
Comando APDU
CLA INS P1 P2 Lc Data Field Le
0xC0 0x20 0x0 0x0 1 Viagem - Tabela 5.3: Comando APDU definido para o comando DEBIT
• O campo CLA identifica a estrutura do comando, tal como no comando GET
BALANCE
• O campo INS identifica a instrução a realizar, neste caso, a operação de
Debit.
• P1 e P2 não são usados neste caso e por isso têm os dois o valor zero.
• O campo Lc identifica o comprimento de dados a enviar para o cartão, nesta
aplicação, corresponde a 1 byte.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 90 Fernando Mostardinha * Sandra Silva
• O Data Field contém a viagem a descontar, ou seja, o número de
viagens a descontar, visto que existe a possibilidade de poder descontar mais
do que uma.
• O campo Le corresponde ao comprimento dos dados esperados pelo
response e neste comando não tem qualquer valor, dado que não são
esperados dados, apenas status words a identificarem se a operação foi ou
não bem sucedida.
Response APDU
Data Status Words Significado das Status Words
- 0x9000 Operação bem sucedida
- 0x6A83 Débito Inválido Tabela 5.4: Response APDU definido para o comando DEBIT
• O campo Data da response APDU não contém dados.
Depois da fase de projecção, passamos ao desenvolvimento do código, que pode ser
consultado em Anexo 1. A sua compilação foi realizada no Eclipse.
Depois de compilado, testamo-lo no Cyberflex Access Toolkit 4.3, programa este
explicado num capítulo anterior (ver ponto 2.2).
5.3 Estudo da plataforma Open Card Framework (OCF)
Como foi referido anteriormente no capítulo 3, a plataforma OpenCard Framework
favorece a interacção entre o reader dos cartões e a aplicação no cartão. A sua
arquitectura baseia-se na tecnologia Java, e resultou no aumento da portabilidade e da
interoperabilidade, pois permite a interacção entre utilizador e cartão sem recurso ao
software Cyberflex, ainda que este seja necessário para carregar inicialmente a
aplicação no cartão. Deste modo, é possível executar os comandos APDU com maior
facilidade.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 91 Fernando Mostardinha * Sandra Silva
Através da leitura do guia do programador do OpenCard Framework 1.0 e do
estudo dos exemplos nele incluídos, iniciou-se assim a odisseia nesta plataforma. Para
pormos em prática os conhecimentos adquiridos deste estudo, efectuaram-se alguns
programas que podem ser consultados nos Anexos 2 e 3.
Uma vez que nesta fase do trabalho o objectivo era o estudo da plataforma OCF,
baseando-nos em duas aplicações já existentes e previamente carregadas por nós no
cartão, realizamos então os programas que através do OCF seleccionam a aplicação
desejada e interagem com esta, enviando e recebendo APDU’s do cartão para o host e
vice-versa.
Todos os programas usados na plataforma OCF devem obedecer a uma determinada
estrutura pré-definida, sendo esta constituída pelos imports das livrarias necessárias para
a execução da aplicação, na definição da classe e no método principal onde o código da
aplicação será executado. Um bom exemplo será:
import java.util.*;
import opencard.core.service.*;
import opencard.core.terminal.*;
import opencard.opt.util.*;
public class SimpleOCF {
public SimpleOCF() {
//…
} //SimpleOCF
public void run() {
System.out.println("activate Smart Card");
//….
System.exit(0);
} // run
public static void main( String [] args ){
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 92 Fernando Mostardinha * Sandra Silva
System.out.println("---------------\nStart SimpleOCF\n");
SimpleOCF OCF = new SimpleOCF();
OCF.run();
} // main
} //class
Antes de podermos trabalhar com o OCF (OpenCard Framework), é necessário
inicializá-lo, e no final desligá-lo, de forma a libertar os recursos do sistema. Uma vez
que podem ocorrer erros (por exemplo, no caso do utilizador remover o cartão enquanto
este está a ser acedido), torna-se também necessário implementar tratamento de erros.
Um exemplo, pode ser visto no código abaixo:
try {
System.out.println("activate Smart Card");
SmartCard.start(); // activate smart card
//.....
System.out.println("\ndeactivate Smart Card");
SmartCard.shutdown();
} // try
catch (Exception e) {
System.err.println("Caught exception '" + e.getClass() + "' - " +
e.getMessage() );
} // catch
O OCF usa as excepções para indicar erros. Por essa razão, o código é colocado num
bloco try/catch. A segunda operação neste bloco (SmartCard.start()) inicializa o OCF.
Quaisquer excepções que são lançadas durante a inicialização, ou enquanto o OCF é
usado, são capturadas e visualizadas.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 93 Fernando Mostardinha * Sandra Silva
Depois de lidarmos com o código envolvente e necessário para a inicialização do
OCF, segue-se a execução de um CardRequest, de forma a que um cartão inserido no
reader possa ser lido:
CardRequest cr = new CardRequest(CardRequest.ANYCARD, null,
PassThruCardService.class);
cr.setTimeout(IFD_TIMEOUT); // set timeout for IFD
// wait for a smart card inserted into the terminal
System.out.println("wait for smart card - insert smart card in terminal\n");
SmartCard sc = SmartCard.waitForCard(cr);
O método waitForCard irá retornar um objecto SmartCard que será usado pela
aplicação para se referir ao cartão quando este for inserido no reader.
Os comandos APDU serão agora definidos como constantes dentro da classe. Um
exemplo:
public class SimpleOCF {
// command ISO7816 SELECT APPLICATION (select the application)
// CLA || INS || P1 || P2 || Lc || INPUT DATA
final byte[ ] CMD_SELECT_APPLICATION = {(byte)0x00, (byte)0xA4, (byte)0x04,
(byte)0x00, (byte)0x07, (byte)0x11, (byte)0x22, (byte)0x33, (byte)0x44,
(byte)0x55, (byte)0x66, (byte)0x77 };
// command ISO7816 VERIFY PIN (verify the pin inserted)
// CLA || INS || P1 || P2 || Lc || INPUT DATA
final byte[] CMD_VERIFY_PIN ={(byte)0x80, (byte)0x40, (byte)0x00, (byte)0x00,
(byte)0x04, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00 };
// command ISO7816 DEPOSIT (add value to the card balance)
// CLA || INS || P1 || P2 || Lc || INPUT DATA
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 94 Fernando Mostardinha * Sandra Silva
final byte[ ] CMD_DEPOSIT ={(byte)0x80, (byte)0x10, (byte)0x00, (byte)0x00,
(byte)0x01, (byte)0x07};
//command ISO7816 VIEW BALANCE (show the balance of the card)
// CLA || INS || P1 || P2 || Le (= length of expected data)
final byte[] CMD_VIEW_BALANCE ={(byte)0x80, (byte)0x30, (byte)0x00, (byte)0x00,
(byte)0x01};
//
}
A primeira constante SELECT APPLICATION corresponde à selecção da aplicação já
carregada na aplicação. Como pode ser observado pela análise dos campos CLA, INS,
P1 e P2, estes encontram-se preenchidos com os valores hexadecimais 00 A4 04 00 que
correspondem aos valores dados pela norma ISO7816 referentes à selecção da
aplicação. O campo seguinte (Lc) contém o valor hexadecimal 07 que indica, tal como
foi referido anteriormente neste relatório, o tamanho do campos de dados. E os sete
campos seguintes referem-se ao “nome” da aplicação a seleccionar, isto é, à sua
identificação (applet AID).
As restantes executam outro tipo de comandos (VERIFY PIN, ...), mas a estrutura é
semelhante e facilmente perceptível pois os comentários são intuitivos.
Finalmente, os comandos APDU são enviados e recebidos da seguinte forma:
// set APDU buffer size
CommandAPDU command = new CommandAPDU(MAX_APDU_SIZE); // create
APDU buffer and set size
// prepare command APDU - SELECT APPLICATION
command.append(CMD_SELECT_APPLICATION);
// send command and receive response
ResponseAPDU response = ptcs.sendCommandAPDU(command);
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 95 Fernando Mostardinha * Sandra Silva
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n<command.getLength(); n++) {
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show response apdu
System.out.print("Response-APDU: ");
for (n = 0; n < response.getLength(); n++) {
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " " );
} // for
System.out.println("\n");
5.4 Desenvolvimento da aplicação gestora dos dados
administrativos do paciente
Iniciamos aqui a migração propriamente dita do sistema anterior para o actual, isto é, do
cartão inteligente criptográfico orientado ao sistema de ficheiros para o JavaCard.
A primeira migração efectuou-se com os dados administrativos do paciente, ou seja, os
dados pessoais.
Esta aplicação teve algumas fases de desenvolvimento, sendo elas:
• Desenvolvimento da aplicação do cartão,
• Desenvolvimento da interface gráfica, e
• Desenvolvimento da interligação entre ambas (cartão e interface).
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 96 Fernando Mostardinha * Sandra Silva
5.4.1 Desenvolvimento da aplicação do cartão
A função principal da aplicação reside em ler e escrever os dados pessoais do paciente.
Em termos técnicos, faz os get’s e set’s dos dados pretendidos. É possível observar
abaixo as duas definições de get e set que são idênticas para todos os get’s e set’s.
o GET APDU
Comando APDU
CLA INS P1 P2 Lc Data Field Le
0x83 * 0x0 0x0 - - ** Tabela 5.5: Comando do APDU definido para o comando GET
• O campo CLA identifica a estrutura do comando, definida por nós, tais como
todos os outros campos do comando.
• O campo INS identifica a instrução a realizar. Nesta aplicação, os get’s
realizados são (*):
• PATIENT IDENTIFIER = 0x11
• FIRST NAME = 0x21
• LAST NAME = 0x31
• BIRTH DATE = 0x41
• COUNTRY = 0x51
• PATIENT PHONE = 0x71
• CONTACT PERSON = 0x81
• CONTACT ADDRESS = 0x91
• P1 e P2 não são usados neste caso e por isso têm os dois o valor zero.
• O campo Lc, neste comando não tem nenhum valor pois nenhuma
informação vai ser enviada para o cartão, mas sim recebida deste.
• O Data Field não toma nenhum valor.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 97 Fernando Mostardinha * Sandra Silva
• O campo Le (**) corresponde ao comprimento dos dados esperados
pelo response e terá comprimentos diferentes consoante o get a realizar.
Response APDU
Data Status words Significado das Status Words
Informação
pretendida 0x9000 Operação bem sucedida
Tabela 5.6: Response APDU definido para o comando GET
• O campo Dados da response APDU contém a informação relativa ao get
efectuado.
o SET APDU
Comando APDU
CLA INS P1 P2 Lc Data Field Le
0x83 * 0x0 0x0 ** Informação a guardar no
cartão -
Tabela 5.7: Comando APDU definido para o comando SET
• O byte CLA identifica a estrutura do comando, tal como no comando GET.
• O byte INS identifica a instrução a realizar, neste caso (*):
• PATIENT IDENTIFIER = 0x10
• FIRST NAME = 0x20
• LAST NAME = 0x30
• BIRTH DATE = 0x40
• COUNTRY = 0x50
• PATIENT PHONE = 0x70
• CONTACT PERSON = 0x80
• CONTACT ADDRESS = 0x90
• P1 e P2 não são usados neste caso, e por isso têm os dois o valor zero.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 98 Fernando Mostardinha * Sandra Silva
• O campo Lc (**) identifica o comprimento de dados a enviar para o
cartão e conforme o set a realizar terá comprimentos diferentes.
• O Data Field contém a informação a guardar no cartão.
• O campo Le corresponde ao comprimento dos dados esperados pelo
response e neste comando não tem qualquer valor, dado que não são
esperados nenhuns dados, apenas status words a identificarem se a operação
foi ou não bem sucedida.
Response APDU
Data Status Words Significado das Status Words
- 0x9000 Operação bem sucedida Tabela 5.8: Response APDU definido para o comando SET
• O campo Data da response APDU não contém dados.
O código respeitante a esta fase encontra-se no Anexo 4.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 99
5.4.2 Desenvolvimento da interface gráfica
Para facilitar a introdução de novos dados/campos
clínicos e administrativos, assim como a actualização
dos mesmos, sentiu-se necessidade de tornar o sistema
mais apelativo e intuitivo. Foi intuito nosso, o uso de
uma interface gráfica recorrendo a um sistema de
janelas. A título de exemplo mostramos uma primeira
janela numa fase embrionária, Figura 5.1, e
posteriormente um conjunto de janelas, semelhantes ao
protótipo final, Figura 5.2. Figura 5.1: Dados administrativos
A interface gráfica foi realizada no Eclipse com a ajuda do plugin Jigloo, com o
objectivo de tornar o sistema mais “user-friendly”, podendo ser observado pela Figura
5.1 um primeiro protótipo para testes e na Figura 5.2, uma interface mais evoluída e
próxima da pretendida.
Como se pode verificar na figura seguinte, este protótipo para além de permitir a
visualização e navegação dos seus conteúdos, permite também manualmente a
introdução e respectiva remoção dos dados.
Figura 5.2: Interface da área clínica e administrativa final
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 100
Neste mundo cada vez mais global, exigente e em constante mutação, vamos ser
obrigados a que num futuro muito próximo, toda a informação esteja passível de ser
acedida pelo exterior. Contando já com tal necessidade, o campo Electronic Location
está já reservado um espaço para colocação de um URL, cujo apontador poderá estar
incluído no cartão
Posteriormente, o potencial gestor/administrador do serviço de saúde para aceder à
informação indicada pelo apontador do cartão, necessitará apenas de ter acesso a um
computador pessoal, contemplado com um leitor de cartões inteligentes.
Figura 5.3: Modelo de criação de apontadores Com este tipo de solução, pode-se poupar muito dinheiro e tempo, e como tempo é
dinheiro então poupar-se-á muito!, mas muito mais importante do que €uros, podem-se
salvar vidas, pois toda a informação necessária ao médico sobre o paciente passa a estar
mais facilmente acessível.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 101 Fernando Mostardinha * Sandra Silva
5.4.3 Desenvolvimento da interligação entre a aplicação do cartão e interface gráfica
Depois de desenvolvida a aplicação do cartão e a interface gráfica, o último passo foi
interligá-las. Esta interligação foi realizada através do OCF e o código respeitante a esta
fase encontra-se no Anexo 5.
5.5 Desenvolvimento da aplicação gestora da informação
clínica do paciente
Seguidamente, inicializou-se a aplicação responsável pela informação clínica do
paciente. Esta é baseada numa estrutura de armazenamento e gestão de ponteiros para a
informação clínica do paciente, historicamente produzida e armazenada nas diversas
instituições onde o paciente beneficiou de serviços de saúde. Esta aplicação é
constituída por duas fases de desenvolvimento: desenvolvimento da aplicação do cartão
e desenvolvimento da interface gráfica.
5.5.1 Desenvolvimento da aplicação do cartão
Também aqui a função principal será ler e escrever informação para o cartão embora
esta informação seja guardada de forma particular, a qual passaremos a explicar.
Definiu-se uma estrutura de dados composta por uma tabela de apontadores e uma área,
a qual chamamos Memória, onde é guardada praticamente toda a informação relativa a
cada apontador alocado na tabela de apontadores. As razões principais para esta
aplicação ter sido definida deste modo, deveram-se sobretudo à necessidade de obter
uma caracterização clínica sumária da informação do paciente, como também para
facilitar a criação e aplicação de filtros de pesquisa. Esta estrutura pode ser analisada
com mais detalhe através da figura seguinte.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 102
Tabela de apontadores Apontador 1 Apontador 2 ............ Offset
Data de
criação do apontador
F.Rel
Cód.
doença
Offset
Data de
criação do apontador
F.Rel
Cód.
doença
...........
Memória
Informação do 1º
apontador da tabela
Fernando Mostardinha * Sandra Silva
Informação
do 2º apontador da tabela
Informação
do 3º apontador da tabela
.
.
.
.
.
.
Tabela 5.9: Estrutura de dados dos apontadores
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 103
A tabela de apontadores é definida por um tamanho fixo suportando um número
predefinido de elementos (apontadores). Cada elemento da tabela é também definido
por um tamanho fixo, igual para todos os elementos constituintes da tabela. Cada um
destes elementos contém a seguinte informação:
• Campo com a localização física (offset da Memória) da informação
relativa ao apontador,
• Data da criação do apontador,
• Factor de relevância do apontador (informação importante ou trivial),
• Detalhe clínico (contém o código clínico de doença).
A tabela foi assim definida de forma a ser possível a criação e aplicação de filtros de
pesquisa aos apontadores alocados, podendo essa pesquisa ser feita sobre os
apontadores por data da criação e/ou factor de relevância e/ou detalhes clínicos
(doenças).
O restante da informação relativa a cada apontador encontra-se alocada numa área
designada por Memória, tal como foi referido acima, definida pela aplicação, na qual os
dados se encontram codificados segundo a codificação tipo BER-TLV (Basic Encoding
Rules – Tag/Length/Value). Onde o campo Tag identifica o elemento ou um grupo, o
campo Length especifica o comprimento em bytes do campo Value e este último,
contém o elemento ou o grupo de elementos propriamente dito. A figura seguinte
mostra de forma mais detalhada esta estrutura de codificação.
Figura 5.4: Estrutura de codificação do tipo BER-TLV Apresenta-se seguidamente, na figura 5.5 abaixo, um exemplo baseado na estrutura
TLV de forma a ilustrar melhor a utilização desta codificação. Na figura pode-se
observar o conteúdo da informação de um apontador em hexadecimal. À direita da
figura encontra-se uma conversão ASCII dos valores hexadecimais. Analisando esta
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 104
figura com a ajuda da tabela 5.10, facilmente se interpreta byte a byte, a
informação deste apontador.
Figura 5.5: Código TLV de um Apontador
Tabela 5.10: Tabela de Interpretação da informação do apontador da Figura 5.4
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 105 Fernando Mostardinha * Sandra Silva
O motivo fundamental pela qual a informação relativa aos apontadores se
encontra codificada, prende-se sobretudo com o facto de que o espaço necessário à
alocação na Memória, da informação de um apontador seja realizada de forma a
aproveitar o espaço disponível. Ou seja, o armazenamento da informação de cada
apontador não desperdiça espaço de memória, pois o espaço necessário é criado com o
tamanho exacto da sequência de octetos codificada do apontador. Sendo assim,
podemos ter apontadores com mais ou menos informação, sem que por isso tenhamos
desperdício de espaço de alocação. Convém salientar que nesta fase, desenvolvimento
da aplicação do cartão, supõe-se que a informação do apontador que chega ao cartão se
encontre já neste formato. Sendo esta codificação sido realizada do lado do host.
As funções criadas para esta aplicação são as seguintes: adição de um apontador,
precedido de um request de adição, de forma a que o utilizador possa ter conhecimento
prévio da possibilidade ou não de alocação de novo apontador; a obtenção dos
identificadores de todos os apontadores; obtenção do tamanho de um dado apontador e a
obtenção de toda a informação relativa a esse apontador. Esta última, quando realizada
será sempre a seguir à operação de obtenção do tamanho do apontador, de forma a que o
host tenha conhecimento antecipado do tamanho da informação a obter e assim
monitorizar o processo. Mas a razão principal reside no facto de que cada response
APDU só ter capacidade de enviar 256 bytes de cada vez, o que na maioria dos casos,
para esta aplicação, não chega. De seguida, são definidas cada uma destas funções.
o LINK ADD REQUEST APDU
Antes de ser adicionado um novo apontador torna-se necessário averiguar se este pode
ou não ser alocado. O facto de a tabela de apontadores estar já totalmente alocada ou
não haver espaço na área Memória, seja porque esta esteja totalmente ocupada ou
porque o espaço necessário para alocar a informação relativa ao novo apontador não
seja suficiente, são alguns passos necessários para essa verificação e que se forem
realizados antes de ser enviada a informação relativa ao apontador evita trabalho ao
host, trabalho esse desnecessário. Sendo assim, tornou-se importante criar este
comando. A sua função é então averiguar se o novo apontador pode ou não ser alocado
devolvendo um Ok ao host caso afirmativo ou uma mensagem de falta de espaço, caso
contrário. O fluxograma relativo a este comando encontra-se na figura seguinte.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 106
Figura 5.6: Fluxograma do comando LINK ADD REQUEST O comando definiu-se da forma seguinte:
Comando APDU
CLA INS P1 P2 Lc Data Field Le
0xC0 0x40 0x0 0x0 * Tamanho dos
dados a enviar
-
Tabela 5.11: Comando APDU definido para o comando LINK ADD REQUEST
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 107 Fernando Mostardinha * Sandra Silva
• O campo CLA identifica a estrutura do comando • O campo INS identifica a instrução a realizar, neste caso, a operação de
LINK ADD REQUEST.
• P1 e P2 não são usados neste caso e, por isso, têm os dois o valor zero.
• O campo Lc identifica o comprimento dos dados a enviar para o cartão.
• O Data Field contém o tamanho dos dados a enviar.
• O campo Le corresponde ao comprimento dos dados esperados pelo response, e neste comando não tem qualquer valor, dado que não são esperados nenhuns dados, apenas status words a identificarem se a operação foi ou não bem sucedida.
Response APDU
Dados Status Words Significado das Status Words
- 0x9000 Operação bem sucedida
- 0x6A84 Sem espaço suficiente Tabela 5.12: Response APDU definido para o comando LINK ADD REQUEST
o ADD LINK APDU
Obtida a informação de que o novo apontador pode ser adicionado, o host envia então
os dados relativos a esse apontador. Os dados serão todos guardados na área Memória à
excepção da data de criação do apontador e do factor de relevância que serão guardados
na tabela de apontadores. O código da doença será guardado na tabela mas
contrariamente aos outros, será também guardado na Memória. O fluxograma respectivo
a este comando encontra-se na Figura 5.6.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 108 Fernando Mostardinha * Sandra Silva
Figura 5.7: Fluxograma do comando ADD LINK
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 109 Fernando Mostardinha * Sandra Silva
O comando foi definido como:
Comando APDU
CLA INS P1 P2 Lc Data Field Le
0xC0 0x50 0x0 0x0 * Dados a enviar -
Tabela 5.13: Comando APDU definido para o comando ADD LINK
• O campo CLA identifica a estrutura do comando
• O campo INS identifica a instrução a realizar, neste caso, a operação de
ADD LINK.
• P1 e P2 não são usados neste caso e, por isso, têm os dois o valor zero.
• O campo Lc identifica o comprimento dos dados a enviar para o cartão.
• O Data Field contém os dados a enviar.
• O campo Le corresponde ao comprimento dos dados esperados pelo
response, e neste comando não tem qualquer valor, dado que não são
esperados nenhuns dados, apenas status words a identificarem se a operação
foi ou não bem sucedida.
Response APDU
Dados Status Words Significado das Status Words - 0x9000 Operação bem sucedida - 0x6A80 Dados errados - 0x6984 Dados inválidos
Tabela 5.14:Response APDU definido para o comando ADD LINK
o GET LINKS ID APDU
Este comando foi pensado para devolver a identificação dos apontadores obtidos através
do filtro de pesquisa efectuado, ou seja, no caso de o utilizador pedir pelo GET LINK
todos os apontadores com o código de doença, por exemplo da Diabetes, o comando
devolverá apenas os apontadores existentes na tabela que obedeçam a este critério. A
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 110
pesquisa a realizar é indicada pelo utilizador através do offset P1 e P2 da APDU.
De momento, este comando apenas efectua a operação de devolução do número de
apontadores existentes na tabela, não realizando portanto nenhum tipo de pesquisa mais
elaborada. O fluxograma respectivo a este comando encontra-se na figura seguinte.
Início
O número de apontadores é igual ao número de elementos alocados na tabela
de apontadores
Fim
Devolve o número de apontadores
Figura 5.8: Fluxograma do comando GET LINKS ID De seguida, pode ser observada a definição do comando:
Comando APDU CLA INS P1 P2 Lc Data Field Le
0xC0 0x10 0x0 0x0 - - * Tabela 5.15: Comando APDU definido para o comando GET LINKS ID
• O campo CLA identifica a estrutura do comando.
• O byte INS identifica a instrução a realizar, neste caso, a operação GET
LINKS ID.
• P1 e P2 têm os dois o valor zero.
• O campo Lc, neste comando não tem nenhum valor pois nenhuma
informação vai ser enviada para o cartão, mas sim recebida deste.
• O Data Field não toma nenhum valor.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 111 Fernando Mostardinha * Sandra Silva
• O campo Le (*) corresponde ao comprimento dos dados esperados
pelo response.
Response APDU
Dados Status words Significado das Status Words
Número de apontadores 0x9000 Operação bem sucedida
Tabela 5.16: Response APDU definido para o comando GET LINKS ID
o GET LINK SIZE APDU
Através deste comando, é possível obter-se o comprimento de um determinado
apontador. A principal razão da existência deste comando consiste no facto de cada
APDU ter apenas capacidade de enviar 256 bytes para o host. Como na maioria dos
casos, para esta aplicação, este comprimento não é suficiente, torna-se necessário
efectuar o comando GET LINK várias vezes até que toda a informação respectiva ao
apontador seja enviada para o host. Sendo assim, o host pode controlar este processo
sabendo antecipadamente quantas vezes terá de repetir o comando e no final verificar se
a informação foi realmente recebida na totalidade. O fluxograma da figura seguinte
mostra de forma mais detalhada a construção deste comando.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 112
Início
Procura no offset P1 da APDU, o apontador desejado para retornar o
tamanho
Procura o seu offset da memória na tabela de apontadores
O comprimento intermédio (len_size, variável auxiliar necessária quando o
comprimento do apontador é demasiado grande e a sua informação tem de ser
enviada fraccionada) é inicializado com o valor do size
Posição do array temporário (pos_arr) inicializada a zero
Fim
Na memória, no elemento igual ao offset mais um, lê o comprimento do apontador
Envia o comprimento do apontador
Figura 5.9: Fluxograma do comando GET LINK SIZE O comando é definido da seguinte forma:
Comando APDU CLA INS P1 P2 Lc Data Field Le
0xC0 0x30 Identificador
do apontador
0x0 - - 2
Tabela 5.17:Comando APDU definido para o comando GET LINK SIZE
• O campo CLA identifica a estrutura do comando. • O byte INS identifica a instrução a realizar, neste caso, a operação GET
LINK SIZE.
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 113 Fernando Mostardinha * Sandra Silva
• P1 contém o identificador do apontador em questão.
• P2 não é usado neste caso e, por isso, têm o valor zero.
• O campo Lc, neste comando não tem nenhum valor pois nenhuma informação vai ser enviada para o cartão, mas sim recebida deste.
• O Data Field não toma nenhum valor.
• O campo Le corresponde ao comprimento dos dados esperados pelo
response e neste caso serão dois bytes correspondentes ao tamanho dos dados relativos ao apontador.
Response APDU
Dados Status words Significado das Status Words Tamanho do
apontador 0x9000 Operação bem sucedida Tabela 5.18: Response APDU definido para o comando GET LINK SIZE
o GET LINK APDU
É através deste comando que o host recebe informação relativa a um apontador. Como
foi já referido anteriormente, na maior parte das situações, este comando será chamado
mais que uma vez de forma a poder enviar a totalidade da informação respectiva ao
apontador desejado. Será o host a comandar esta transferência de informação e portanto
será ele a repetir o comando as vezes necessárias até que toda a informação seja
transferida. É de lembrar que o host tem conhecimento do comprimento da informação a
receber através do comando anterior (GET LINK SIZE). O fluxograma correspondente
a este comando pode ser analisado pela Figura 5.9.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 114 Fernando Mostardinha * Sandra Silva
Figura 5.10: Fluxograma do comando GET LINK
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 115
A definição do comando é realizada da seguinte forma:
Comando APDU CLA INS P1 P2 Lc Data Field Le
0xC0 0x20 Identificador
do apontador
0x0 - - *
Tabela 5.19: Comando APDU definido para o comando GET LINK
• O campo CLA identifica a estrutura do comando.
• O byte INS identifica a instrução a realizar, neste caso, a operação GET
LINK.
• P1 contém o identificador do apontador em questão.
• P2 não é usado neste caso e, por isso, têm o valor zero.
• O campo Lc, neste comando não tem nenhum valor pois nenhuma
informação vai ser enviada para o cartão, mas sim recebida deste.
• O Data Field não toma nenhum valor.
• O campo Le corresponde ao comprimento dos dados esperados pelo
response e neste caso será variável dependendo da informação a enviar.
Response APDU
Dados Status words Significado das Status Words
Toda a informação relativa ao apontador
0x9000 Operação bem sucedida
- 0x6B00 Parâmetros errados (P1, P2)
- 0x6A83 Erro ao executar a operação Tabela 5.20: Response APDU definido para o comando GET LINK
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 116
O código para esta fase encontra-se no Anexo 6.
5.5.2 Desenvolvimento da interface gráfica
No momento, encontra-se já concluída a interface gráfica capaz de adicionar um
apontador, como pode ser observado na figura seguinte.
Figura 5.11: Adição de um Apontador
5.6 Conclusões
Neste capítulo foi apresentada uma proposta de migração do protótipo existente
realizado em Visual Basic, baseado num cartão inteligente criptográfico orientado ao
sistema de ficheiros (Smart Cards) para cartões orientados às aplicações (Java Cards).
Uma vez que este tipo de cartões tem como base a linguagem de programação Java,
consequentemente, todo o projecto foi realizado neste tipo de linguagem, apesar de
neste trabalho a programação ser muito orientada para o cartão Java e por isso
Fernando Mostardinha * Sandra Silva
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 117 Fernando Mostardinha * Sandra Silva
específica. Este facto acarretou dificuldades acrescidas, pois existem
funcionalidades no Java em geral, que não são aplicáveis a este tipo de cartões (Java).
A proposta para a migração foi desenvolvida mas com alguns problemas, nem sempre
de solução acessível, pois existiram etapas no desenvolvimento das diversas aplicações,
as quais, até ao momento da realização deste documento não tinham sido ainda
resolvidas, apesar do esforço e tempo investidos, na procura pela melhor resolução. Por
exemplo, vários entraves fizeram-se sentir aquando do desenvolvimento do ponto 5.5
deste documento, ou seja, desenvolvimento da aplicação gestora da informação clínica
do paciente. No desenvolvimento da aplicação do cartão, um dos comandos elaborados
(Add Link), teve problemas na sua implementação, impossibilitando assim o teste de
outros comandos implementados, os quais estão dependentes/interligados da boa
implementação do comando Add Link.
O facto de este ser um projecto pioneiro na área, não ajuda muito, pois as fontes de
investigação são ainda escassas. A estreita colaboração dos nossos orientadores e a
Internet, foram os nossos maiores aliados.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 118 Fernando Mostardinha * Sandra Silva
Capítulo 6
6 Conclusões
Com a necessidade crescente que temos cada vez mais de migrar de meios físicos para
meios digitais/electrónicos, torna-se imperativo a implementação de serviços de e/em
ambientes seguros, pois indo para sectores mais sensíveis cuja informação é do foro
pessoal e clínico, onde a privacidade e/ou confidencialidade das pessoas pode ser posta
em causa, tem que ter muita coisa em especial atenção e garantir que certos
pressupostos são abrangidos!
Pretendeu-se com este projecto, contribuir com um modelo que ajude à integração e
concentração dos dados clínicos, pois a sua dispersão tal como hoje em dia se nota e de
facto acontece, não faz sentido. Ao mesmo tempo é perigoso é inseguro, uma vez que os
nossos dados clínicos se encontram espalhados pelos diversos centros de saúde e
hospitais, nas mãos de sabe-se lá de quem e com os mais diversos pensamentos
(duvidosos, ou não!!) sobre a sua utilização. Não nos podemos esquecer que quem tem
informação, tem poder! Para tal encarou-se este problema de dispersão e desenvolveu-se
uma estrutura para partilhar os dados de uma forma segura entre os vários prestadores
de serviços de saúde.
Com a elaboração deste trabalho conseguiu-se provar que a migração do anterior
sistema implantado para este, trás um valor acrescido. Essa migração conta com a
inovadora ajuda da tecnologia Java Card e consequentemente, toda a segurança nela
implícita.
A segurança é um dos factores primordiais do Java Card proporcionando um elevado
grau de controlo e confidencialidade dos dados. Possibilita também mecanismos de
credenciais digitais (certificados digitais e chaves privadas). Estes cartões permitem
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 119 Fernando Mostardinha * Sandra Silva
implementar procedimentos de verificação de identidade do portador do cartão
(PIN e/ou por um dispositivo biométrico).
A arquitectura proposta revelou que mesmo para a consulta dos conteúdos mais
sensíveis dos apontadores, era imperativo o consentimento do utente para tal,
evidenciando deste modo uma das mais valias desta arquitectura, a confidencialidade.
Trata-se portanto de um sistema de cartão de utente seguro, tecnologicamente baseado
num cartão inteligente de criptografia de chave pública capaz de: armazenar dados de
forma segura; suportar controlo de acessos a esses dados; propiciar um controlo da
identidade do portador do cartão com recurso a PIN ou Biometria; propiciar a
autenticação remota do utente com recurso a certificados digitais e a criptografia de
chave pública.
Este modelo de acesso integrado e seguro à informação sensível pelos utentes, tem
vantagens não exclusivas da área da saúde, podendo ser aplicado noutras área também
sensíveis, uma vez que toda a arquitectura desenvolvida pode ser adaptada a outras
áreas da sociedade, onde eventualmente estejamos a lidar com dados muitos sensíveis e
críticos para os cidadãos [11]. Bons exemplos de aplicação seriam: na Banca, no registo
criminal, etc.
Com este tipo de solução, pode-se poupar muito tempo e dinheiro, mas como tempo é
dinheiro então poupar-se-á muito mais dinheiro do que à primeira vista de pensa! Mas
acima de tudo e muito mais importante do que €uros, ou seja, poder-se-ão salvar muitas
vidas, pois toda a informação necessária ao médico sobre o paciente passa a estar mais
facilmente acessível.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 120 Fernando Mostardinha * Sandra Silva
Referências [1] Ferrari, Jorge, Susan Poh, Robert Mackinon, Lakshaman Yatawara, Smart Cards:A
Case Study, IBM,
[2] Chen, Zhiqun, Java Card Technology for Smart Cards: Architecture and
Programmer’s Guide, Addison-Wesley
[3] Juha-Pekka Ruuskanen, JAVACARD paper (PDF)
[4] Sistema Open-Source para Composição de Serviços, Relatório Semestral, Herlander
Jorge, Sónia, Fevereiro/05
[4a] Cyberflex Access Cards Programmers Guide
[5.1] http://wwwtcs.inf.tu-dresden.de/~ohme/dud/smartcard.pdf
[5.2] http://developers.sun.com/techtopics/mobility/javacard/articles/javacard1/
[6] CLAUSEN, L.R., SCHULTZ, U.P. et al., Java bytecode compression for
embedded systems. Institut de recherche en informatique et systémes aléatoires,
Campus Universitaire de Beaulieu, 1998. ftp://ftp.irisa.fr/techreports/1998/PI-
1213.ps.gz
[7] http://www.temporeal2000.com/paginas/biometria.htm
[8] Eclipse: http://www-106.ibm.com/developerworks/java/library/os-
ecov/?t=egrL262&p=starteclipseplat#N10049
[8a] http://www.ansi.org/
[9] http://developers.sun.com/techtopics/mobility/javacard/articles/javacard1/
[10] http://eclipse-plugins.2y.net/eclipse/plugin_details.jsp?id=472
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 121 Fernando Mostardinha * Sandra Silva
[11] Concepção, desenvolvimento e avaliação de um modelo integrado de
acessos a registos clínicos electrónicos, Dissertação de Doutoramento, Prof. Carlos
Costa, UA, 2004
[12] http://www.redbooks.ibm.com
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 122 Fernando Mostardinha * Sandra Silva
Anexos
Anexo 1 Código do programa BusTicket
/*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Style - Code Templates
*/
package src;
import javacard.framework.APDU;
import javacard.framework.ISO7816;
import javacard.framework.ISOException;
/**
* @author Projecto
*
* TODO To change the template for this generated type comment go to Window -
* Preferences - Java - Code Style - Code Templates
*/
public class BusTicket extends javacard.framework.Applet {
//declaracao de constantes
//codigo do byte CLA no comando APDU
final static byte BusTicket_CLA = (byte) 0xC0;
//codigo do byte INS no comando APDU
final static byte GET_BALANCE = (byte) 0x10;
final static byte DEBIT = (byte) 0x20;
// # maximo de viagens
final static short MAX_VIAGENS = 10;
//definicao de SW
final static short SW_INVALID_DEBIT_AMOUNT = 0x6A83;
//declaracao das variaveis
short balance;
//construtor privado
private BusTicket() {
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 123 Fernando Mostardinha * Sandra Silva
//inicializacao do # viagens
balance = 10;
register();
}//fim do construtor
//criacao da instancia
public static void install(byte[] bArray, short bOffset, byte bLength) {
new BusTicket();
}//fim do metodo install
//inicializacao da applet quando esta e seleccionada
public boolean select() {
//retorna true para o JCRE para indicar que a
//applet esta pronta a receber APDUs
return true;
}//fim do metodo select
//metodo process
public void process (APDU apdu){
//o objecto APDU transporta um array de bytes(buffer)
//para transferir headers APDU e bytes de dados entre
//o cartao e o host
byte[] buffer = apdu.getBuffer();
//retorna se o APDU e o comando SELECT
if (selectingApplet()) return;
//verifica o byte CLA
if (buffer[ISO7816.OFFSET_CLA] != BusTicket_CLA)
ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);
byte ins = buffer[ISO7816.OFFSET_INS];
if (ins == DEBIT) debit(apdu);
else if(ins==GET_BALANCE) getBalance(apdu);
else ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
}//fim do metodo process
//desconto das viagens
private void debit(APDU apdu) {
byte[] buffer = apdu.getBuffer();
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 124 Fernando Mostardinha * Sandra Silva
byte numBytes = (byte) (buffer[ISO7816.OFFSET_LC]);
byte byteRead = (byte) (apdu.setIncomingAndReceive());
if ((numBytes != 1) || (byteRead != 1))
ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
//faz o desconto da viagem
byte decremento = buffer[ISO7816.OFFSET_CDATA];
//verifica o # de viagens
if ((short) (balance - decremento) < (short) 1)
ISOException.throwIt(SW_INVALID_DEBIT_AMOUNT);
balance = (short) (balance - decremento);
}//fim do metodo debit
//retorna o balanço das viagens
private void getBalance(APDU apdu){
byte[] buffer = apdu.getBuffer();
apdu.setOutgoing();
//indica o # de bytes do campo de dados
apdu.setOutgoingLength((byte)1);
//escreve o balance no buffer no offset 0
buffer[0]=(byte)balance;
//envia 1 byte de dados no offset 0 no buffer APDU
apdu.sendBytes((short)0,(short)1);
}//fim do método getBalance
}//fim da classe BusTicket
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 125 Fernando Mostardinha * Sandra Silva
Anexo 2 Código do programa SimpleOCF
/*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Style - Code Templates
*/
/**
* @author Projecto
*
* TODO To change the template for this generated type comment go to
* Window - Preferences - Java - Code Style - Code Templates
*/
import java.util.*;
import opencard.core.service.*;
import opencard.core.terminal.*;
import opencard.opt.util.*;
public class SimpleOCF {
private static final int IFD_TIMEOUT = 10; // unit: seconds
private static final int MAX_APDU_SIZE = 100; // unit: byte
// command ISO7816 SELECT APPLICATION (select the application)
// CLA || INS || P1 || P2 || Lc || INPUT DATA
final byte[] CMD_SELECT_APPLICATION = {(byte)0x00, (byte)0xA4, (byte)0x04, (byte)0x00, (byte)0x07,
(byte)0x11, (byte)0x22, (byte)0x33, (byte)0x44,
(byte)0x55, (byte)0x66, (byte)0x77 };
// command ISO7816 VERIFY PIN (verify the pin inserted)
// CLA || INS || P1 || P2 || Lc || INPUT DATA
final byte[] CMD_VERIFY_PIN ={(byte)0x80, (byte)0x40, (byte)0x00, (byte)0x00, (byte)0x04, (byte)0x00,
(byte)0x00, (byte)0x00, (byte)0x00 };
// command ISO7816 DEPOSIT (add value to the card balance)
// CLA || INS || P1 || P2 || Lc || INPUT DATA
final byte[] CMD_DEPOSIT ={(byte)0x80, (byte)0x10, (byte)0x00, (byte)0x00, (byte)0x01, (byte)0x07};
//command ISO7816 VIEW BALANCE (show the balance of the card)
// CLA || INS || P1 || P2 || Le (= length of expected data)
final byte[] CMD_VIEW_BALANCE ={(byte)0x80, (byte)0x30, (byte)0x00, (byte)0x00, (byte)0x01};
private int n, x;
private byte[] i;
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 126 Fernando Mostardinha * Sandra Silva
public SimpleOCF() {
// create system properties object
Properties sysProps = System.getProperties();
// set system properties for OCF, PC/SC and PassThruCardService sysProps.put ("OpenCard.terminals",
"com.ibm.opencard.terminal.pcsc10.Pcsc10CardTerminalFactory");
sysProps.put ("OpenCard.services", "opencard.opt.util.PassThruCardServiceFactory");
} //SimpleOCF
public void run() {
try {
System.out.println("activate Smart Card");
SmartCard.start(); // activate smart card
CardRequest cr = new CardRequest(CardRequest.ANYCARD, null, PassThruCardService.class);
cr.setTimeout(IFD_TIMEOUT); // set timeout for IFD
// wait for a smart card inserted into the terminal
System.out.println("wait for smart card - insert smart card in terminal\n");
SmartCard sc = SmartCard.waitForCard(cr);
if (sc != null) { // no error occur and a smart card is in the terminal
PassThruCardService ptcs = (PassThruCardService) sc.getCardService(PassThruCardService.class, true);
System.out.print("ATR: ");
CardID cardID = sc.getCardID ();
i = cardID.getATR();
String s = new String();
for (n = 0; n < i.length; n++) {
x = (int) (0x000000FF & i[n]); // byte to int conversion
s = Integer.toHexString(x).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("\n");
// set APDU buffer size
CommandAPDU command = new CommandAPDU(MAX_APDU_SIZE); // create APDU buffer and set size
//----- prepare command APDU - SELECT APPLICATION
command.append(CMD_SELECT_APPLICATION);
// send command and receive response
ResponseAPDU response = ptcs.sendCommandAPDU(command);
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n<command.getLength(); n++) {
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show response apdu
System.out.print("Response-APDU: ");
for (n = 0; n < response.getLength(); n++) {
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 127 Fernando Mostardinha * Sandra Silva
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " " );
} // for
System.out.println("\n");
//----- prepare command APDU - VERIFY PIN
command.setLength(0);
command.append(CMD_VERIFY_PIN);
// send command and receive response
response = ptcs.sendCommandAPDU(command);
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n < command.getLength(); n++) {
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show int response apdu
System.out.print("Response-APDU: ");
for (n=0; n<response.getLength(); n++) {
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("\n");
//----- prepare command APDU - VIEW BALANCE
command.setLength(0);
command.append(CMD_VIEW_BALANCE);
// send command and receive response
response = ptcs.sendCommandAPDU(command);
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n < command.getLength(); n++) {
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show response apdu
System.out.print("Response-APDU: ");
for (n = 0; n < response.getLength(); n++) {
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
}//for
System.out.println("\n");
//----- prepare command APDU - DEPOSIT
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 128 Fernando Mostardinha * Sandra Silva
command.setLength(0);
command.append(CMD_DEPOSIT);
// send command and receive response
response = ptcs.sendCommandAPDU(command);
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n < command.getLength(); n++) {
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show response apdu
System.out.print("Response-APDU: ");
for (n = 0; n < response.getLength(); n++) {
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("\n");
//----- prepare command APDU - VIEW BALANCE
command.setLength(0);
command.append(CMD_VIEW_BALANCE);
// send command and receive response
response = ptcs.sendCommandAPDU(command);
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n < command.getLength(); n++) {
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show response apdu
System.out.print("Response-APDU: ");
for (n = 0; n < response.getLength(); n++) {
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
}//for
System.out.print("\n");
System.out.println("\ndeactivate Smart Card");
SmartCard.shutdown();
} // if
else System.out.println("could not create smart card object (e.g. no ICC in IFD)");
} // try
catch (Exception e) {
System.err.println("Caught exception '" + e.getClass() + "' - " + e.getMessage() );
} // catch
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 129 Fernando Mostardinha * Sandra Silva
finally {
System.exit(0);
} // finally
} // run
public static void main( String [] args ){
System.out.println("---------------\nStart SimpleOCF\n");
SimpleOCF OCF = new SimpleOCF();
OCF.run();
} // main
} //class
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 130 Fernando Mostardinha * Sandra Silva
Anexo 3 Código do programa StringOCF
/*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Style - Code Templates
*/
/**
* @author Projecto
*
* TODO To change the template for this generated type comment go to
* Window - Preferences - Java - Code Style - Code Templates
*/
import java.util.*;
import opencard.core.service.*;
import opencard.core.terminal.*;
import opencard.opt.util.*;
public class StringOCF {
private static final int IFD_TIMEOUT = 10; // unit: seconds
private static final int MAX_APDU_SIZE = 100; // unit: byte
// command ISO7816 SELECT APPLICATION (select the application)
// CLA || INS || P1 || P2 || Lc || INPUT DATA
final byte[] CMD_SELECT_APPLICATION = {(byte)0x00, (byte)0xA4, (byte)0x04, (byte)0x00, (byte)0x06,
(byte)0x01, (byte)0x02, (byte)0x03, (byte)0x04, (byte)0x05, (byte)0x06 };
// command ISO7816 SEND STRING
// CLA || INS || P1 || P2 || Lc || INPUT DATA
final byte[] CMD_SEND_STRING ={(byte)0x85, (byte)0x10,(byte)0x00,
(byte)0x00, (byte)0x08, (byte)0x29, (byte)0x2B, (byte)0x36, (byte)0x54, (byte)0x8E, (byte)0x30, (byte)0x2C, (byte)0x5F };
//command ISO7816 GET STRING
// CLA || INS || P1 || P2 || Le (= length of expected data)
final byte[] CMD_GET_STRING ={(byte)0x85, (byte)0x20, (byte)0x00, (byte)0x00, (byte)0x08};
private int n, x;
private byte[] i;
public StringOCF() {
// create system properties object
Properties sysProps = System.getProperties();
// set system properties for OCF, PC/SC and PassThruCardServce
sysProps.put ("OpenCard.terminals", "com.ibm.opencard.terminal.pcsc10.Pcsc10CardTerminalFactory");
sysProps.put ("OpenCard.services", "opencard.opt.util.PassThruCardServiceFactory");
} //SimpleOCF
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 131 Fernando Mostardinha * Sandra Silva
public void run() {
try {
System.out.println("activate Smart Card");
SmartCard.start(); // activate smart card
CardRequest cr = new CardRequest(CardRequest.ANYCARD, null, PassThruCardService.class);
cr.setTimeout(IFD_TIMEOUT); // set timeout for IFD
// wait for a smart card inserted into the terminal
System.out.println("wait for smart card - insert smart card in terminal\n");
SmartCard sc = SmartCard.waitForCard(cr);
if (sc != null) { // no error occur and a smart card is in the terminal
PassThruCardService ptcs = (PassThruCardService) sc.getCardService(PassThruCardService.class, true);
System.out.print("ATR: ");
CardID cardID = sc.getCardID ();
i = cardID.getATR();
String s = new String();
for (n = 0; n < i.length; n++) {
x = (int) (0x000000FF & i[n]); // byte to int conversion
s = Integer.toHexString(x).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("\n");
// set APDU buffer size
CommandAPDU command = new CommandAPDU(MAX_APDU_SIZE); // create APDU buffer and set size
//----- prepare command APDU - SELECT APPLICATION
command.append(CMD_SELECT_APPLICATION);
// send command and receive response
ResponseAPDU response = ptcs.sendCommandAPDU(command);
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n<command.getLength(); n++) {
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show response apdu
System.out.print("Response-APDU: ");
for (n = 0; n < response.getLength(); n++) {
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " " );
} // for
System.out.println("\n");
//----- prepare command APDU - GET STRING
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 132 Fernando Mostardinha * Sandra Silva
command.setLength(0);
command.append(CMD_GET_STRING);
// send command and receive response
response = ptcs.sendCommandAPDU(command);
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n < command.getLength(); n++) {
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show response apdu
System.out.print("Response-APDU: ");
for (n = 0; n < response.getLength(); n++) {
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("\n");
//----- prepare command APDU - SEND STRING
command.setLength(0);
command.append(CMD_SEND_STRING);
// send command and receive response
response = ptcs.sendCommandAPDU(command);
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n < command.getLength(); n++) {
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show response apdu
System.out.print("Response-APDU: ");
for (n = 0; n < response.getLength(); n++) {
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
}//for
System.out.println("\n");
//----- prepare command APDU - GET STRING
command.setLength(0);
command.append(CMD_GET_STRING);
// send command and receive response
response = ptcs.sendCommandAPDU(command);
// show command apdu
System.out.print("Command-APDU: ");
for (n = 0; n < command.getLength(); n++) {
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 133 Fernando Mostardinha * Sandra Silva
s = Integer.toHexString(command.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("");
// show response apdu
System.out.print("Response-APDU: ");
for (n = 0; n < response.getLength(); n++) {
s = Integer.toHexString(response.getByte(n)).toUpperCase();
if (s.length() == 1) s = "0" + s;
System.out.print(s + " ");
} // for
System.out.println("\n");
System.out.println("\ndeactivate Smart Card");
SmartCard.shutdown();
} // if
else System.out.println("could not create smart card object (e.g. no ICC in IFD)");
} // try
catch (Exception e) {
System.err.println("Caught exception '" + e.getClass() + "' - " + e.getMessage() );
} // catch
finally {
System.exit(0);
} // finally
} // run
public static void main( String [] args ){
System.out.println("---------------\nStart StringOCF\n");
StringOCF OCF = new StringOCF();
OCF.run();
} // main
}
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 134 Fernando Mostardinha * Sandra Silva
Anexo 4 Código da aplicação gestora dos dados administrativos do paciente definida para o cartão /* * TODO To change the template for this generated file go to * Window - Preferences - Java - Code Style - Code Templates */ /** * @author Projecto * * TODO To change the template for this generated type comment go to * Window - Preferences - Java - Code Style - Code Templates */ package PatientData; import javacard.framework.*; //import javacard.security.*; //Class Definition public class Patientcard extends javacard.framework.Applet { // This applet is designed to respond to the following // class of instructions. final static byte Patientcard_CLA = (byte)0x83; // Instruction set for Patientcard final static byte SET_PATIENT_IDENTIFIER = (byte)0x10; final static byte GET_PATIENT_IDENTIFIER = (byte)0x11; final static byte SET_FIRST_NAME = (byte)0x20; final static byte GET_FIRST_NAME = (byte)0x21; final static byte SET_LAST_NAME = (byte)0x30; final static byte GET_LAST_NAME = (byte)0x31; final static byte SET_BIRTH_DATE = (byte)0x40; final static byte GET_BIRTH_DATE = (byte)0x41; final static byte SET_COUNTRY = (byte)0x50; final static byte GET_COUNTRY = (byte)0x51; final static byte SET_PATIENT_PHONE = (byte)0x70; final static byte GET_PATIENT_PHONE = (byte)0x71; final static byte SET_CONTACT_PERSON = (byte)0x80; final static byte GET_CONTACT_PERSON = (byte)0x81; final static byte SET_CONTACT_ADDRESS = (byte)0x90; final static byte GET_CONTACT_ADDRESS = (byte)0x91; final static byte SELECT = (byte) 0xA4; byte TheBuffer[]; // This buffer contains the string data on the card byte TheBuffer1[], TheBuffer2[], TheBuffer3[], TheBuffer4[]; byte TheBuffer6[], TheBuffer7[], TheBuffer8[]; // The constructor. private Patientcard (byte buffer[],short offset,byte length) { TheBuffer = new byte[15]; TheBuffer1 = new byte[15]; TheBuffer2 = new byte[15]; TheBuffer3 = new byte[15]; TheBuffer4 = new byte[15]; TheBuffer6 = new byte[15]; TheBuffer7 = new byte[15]; TheBuffer8 = new byte[30]; if (buffer[offset] == (byte)0) { register(); } } // Every applet running JavaCard 2.0 must implement the following // three functions.
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 135 Fernando Mostardinha * Sandra Silva
// You create the one instance of your applet here. public static void install(byte buffer[],short offset,byte length) { new Patientcard(buffer, offset, length); } // This function is called when your applet is selected. public boolean select() { return true; } // The process method dispatches messages to your class methods // depending on the instruction type. public void process(APDU apdu) throws ISOException{ byte buffer[] = apdu.getBuffer(); // Implement a select handler if (selectingApplet()) { ISOException.throwIt(ISO7816.SW_NO_ERROR); } if (buffer[ISO7816.OFFSET_CLA] != Patientcard_CLA) ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED); byte ins = buffer[ISO7816.OFFSET_INS]; switch (ins) { case SET_PATIENT_IDENTIFIER: SetPatientIdentifier(apdu); break; case GET_PATIENT_IDENTIFIER: GetPatientIdentifier(apdu); break; case SET_FIRST_NAME: SetFirstName(apdu); break; case GET_FIRST_NAME: GetFirstName(apdu); break; case SET_LAST_NAME: SetLastName(apdu); break; case GET_LAST_NAME: GetLastName(apdu); break; case SET_BIRTH_DATE: SetBirthDate(apdu); break; case GET_BIRTH_DATE: GetBirthDate(apdu); break; case SET_COUNTRY: SetCountry(apdu); break; case GET_COUNTRY: GetCountry(apdu); break; case SET_PATIENT_PHONE: SetPatientPhone(apdu); break; case GET_PATIENT_PHONE: GetPatientPhone(apdu); break; case SET_CONTACT_PERSON: SetContactPerson(apdu); break; case GET_CONTACT_PERSON: GetContactPerson(apdu); break;
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 136 Fernando Mostardinha * Sandra Silva
case SET_CONTACT_ADDRESS: SetContactAddress(apdu); break; case GET_CONTACT_ADDRESS: GetContactAddress(apdu); break; default:
ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED); } } // Class methods private void SetPatientIdentifier(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte size = (byte)(apdu.setIncomingAndReceive()); byte index; // Store the length of the string and the string itself
Util.arrayFillNonAtomic(TheBuffer,(short)0,(short)TheBuffer.length,(byte)0x00); TheBuffer[0] = size; for (index = 0; index < size; index++) TheBuffer[(byte)(index + 1)] = buffer[(byte)(ISO7816.OFFSET_CDATA + index)]; return; } private void SetFirstName(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte size = (byte)(apdu.setIncomingAndReceive()); byte index; // Store the length of the string and the string itself
Util.arrayFillNonAtomic(TheBuffer1,(short)0,(short)TheBuffer1.length,(byte)0x00); TheBuffer1[0] = size; for (index = 0; index < size; index++) TheBuffer1[(byte)(index + 1)] = buffer[(byte)(ISO7816.OFFSET_CDATA + index)]; return; } private void SetLastName(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte size = (byte)(apdu.setIncomingAndReceive()); byte index; // Store the length of the string and the string itself
Util.arrayFillNonAtomic(TheBuffer2,(short)0,(short)TheBuffer2.length,(byte)0x00); TheBuffer2[0] = size; for (index = 0; index < size; index++) TheBuffer2[(byte)(index + 1)] = buffer[(byte)(ISO7816.OFFSET_CDATA + index)]; return; } private void SetBirthDate(APDU apdu) { byte buffer[] = apdu.getBuffer();
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 137 Fernando Mostardinha * Sandra Silva
byte size = (byte)(apdu.setIncomingAndReceive()); byte index; // Store the length of the string and the string itself
Util.arrayFillNonAtomic(TheBuffer3,(short)0,(short)TheBuffer3.length,(byte)0x00); TheBuffer3[0] = size; for (index = 0; index < size; index++) TheBuffer3[(byte)(index + 1)] = buffer[(byte)(ISO7816.OFFSET_CDATA + index)]; return; } private void SetCountry(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte size = (byte)(apdu.setIncomingAndReceive()); byte index; // Store the length of the string and the string itself
Util.arrayFillNonAtomic(TheBuffer4,(short)0,(short)TheBuffer4.length,(byte)0x00); TheBuffer4[0] = size; for (index = 0; index < size; index++) TheBuffer4[(byte)(index + 1)] = buffer[(byte)(ISO7816.OFFSET_CDATA + index)]; return; } private void SetPatientPhone(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte size = (byte)(apdu.setIncomingAndReceive()); byte index; // Store the length of the string and the string itself
Util.arrayFillNonAtomic(TheBuffer6,(short)0,(short)TheBuffer6.length,(byte)0x00); TheBuffer6[0] = size; for (index = 0; index < size; index++) TheBuffer6[(byte)(index + 1)] = buffer[(byte)(ISO7816.OFFSET_CDATA + index)]; return; } private void SetContactPerson(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte size = (byte)(apdu.setIncomingAndReceive()); byte index; // Store the length of the string and the string itself
Util.arrayFillNonAtomic(TheBuffer7,(short)0,(short)TheBuffer7.length,(byte)0x00); TheBuffer7[0] = size; for (index = 0; index < size; index++) TheBuffer7[(byte)(index + 1)] = buffer[(byte)(ISO7816.OFFSET_CDATA + index)]; return; }
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 138 Fernando Mostardinha * Sandra Silva
private void SetContactAddress(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte size = (byte)(apdu.setIncomingAndReceive()); byte index; // Store the length of the string and the string itself
Util.arrayFillNonAtomic(TheBuffer8,(short)0,(short)TheBuffer8.length,(byte)0x00); TheBuffer8[0] = size; for (index = 0; index < size; index++) TheBuffer8[(byte)(index + 1)] = buffer[(byte)(ISO7816.OFFSET_CDATA + index)]; return; } // GetString retrieves the string from the card. // This is actually the interesting function. When a client // asks for the string, it really has no way of knowing how // large the string would be. We handle this with the following steps: // // 1. Client sends a GetString APDU with a length of 0 // 2. Card responds with a Status Word of 0x62YY, where YY is the length // of the string (in hex). // 3. The client sends its GetString APDU again, but this time with the // correct length. // private void GetPatientIdentifier(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte numBytes = buffer[ISO7816.OFFSET_LC]; if (numBytes == (byte)0) { ISOException.throwIt((short)(0x6200 + TheBuffer[0])); } apdu.setOutgoing(); apdu.setOutgoingLength(numBytes); byte index; for (index = 0; index <= numBytes; index++) buffer[index] = TheBuffer[(byte)(index + 1)]; apdu.sendBytes((short)0,(short)numBytes); return; } private void GetFirstName(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte numBytes = buffer[ISO7816.OFFSET_LC]; if (numBytes == (byte)0) { ISOException.throwIt((short)(0x6200 + TheBuffer1[0])); } apdu.setOutgoing(); apdu.setOutgoingLength(numBytes); byte index; for (index = 0; index <= numBytes; index++) buffer[index] = TheBuffer1[(byte)(index + 1)]; apdu.sendBytes((short)0,(short)numBytes);
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 139 Fernando Mostardinha * Sandra Silva
return; } private void GetLastName(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte numBytes = buffer[ISO7816.OFFSET_LC]; if (numBytes == (byte)0) { ISOException.throwIt((short)(0x6200 + TheBuffer2[0])); } apdu.setOutgoing(); apdu.setOutgoingLength(numBytes); byte index; for (index = 0; index <= numBytes; index++) buffer[index] = TheBuffer2[(byte)(index + 1)]; apdu.sendBytes((short)0,(short)numBytes); return; } private void GetBirthDate(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte numBytes = buffer[ISO7816.OFFSET_LC]; if (numBytes == (byte)0) { ISOException.throwIt((short)(0x6200 + TheBuffer3[0])); } apdu.setOutgoing(); apdu.setOutgoingLength(numBytes); byte index; for (index = 0; index <= numBytes; index++) buffer[index] = TheBuffer3[(byte)(index + 1)]; apdu.sendBytes((short)0,(short)numBytes); return; } private void GetCountry(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte numBytes = buffer[ISO7816.OFFSET_LC]; if (numBytes == (byte)0) { ISOException.throwIt((short)(0x6200 + TheBuffer4[0])); } apdu.setOutgoing(); apdu.setOutgoingLength(numBytes); byte index; for (index = 0; index <= numBytes; index++) buffer[index] = TheBuffer4[(byte)(index + 1)]; apdu.sendBytes((short)0,(short)numBytes); return; } private void GetPatientPhone(APDU apdu) { byte buffer[] = apdu.getBuffer();
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 140 Fernando Mostardinha * Sandra Silva
byte numBytes = buffer[ISO7816.OFFSET_LC]; if (numBytes == (byte)0) { ISOException.throwIt((short)(0x6200 + TheBuffer6[0])); } apdu.setOutgoing(); apdu.setOutgoingLength(numBytes); byte index; for (index = 0; index <= numBytes; index++) buffer[index] = TheBuffer6[(byte)(index + 1)]; apdu.sendBytes((short)0,(short)numBytes); return; } private void GetContactPerson(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte numBytes = buffer[ISO7816.OFFSET_LC]; if (numBytes == (byte)0) { ISOException.throwIt((short)(0x6200 + TheBuffer7[0])); } apdu.setOutgoing(); apdu.setOutgoingLength(numBytes); byte index; for (index = 0; index <= numBytes; index++) buffer[index] = TheBuffer7[(byte)(index + 1)]; apdu.sendBytes((short)0,(short)numBytes); return; } private void GetContactAddress(APDU apdu) { byte buffer[] = apdu.getBuffer(); byte numBytes = buffer[ISO7816.OFFSET_LC]; if (numBytes == (byte)0) { ISOException.throwIt((short)(0x6200 + TheBuffer8[0])); } apdu.setOutgoing(); apdu.setOutgoingLength(numBytes); byte index; for (index = 0; index <= numBytes; index++) buffer[index] = TheBuffer8[(byte)(index + 1)]; apdu.sendBytes((short)0,(short)numBytes); return; } }
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 141 Fernando Mostardinha * Sandra Silva
Anexo 5 Código da aplicação gestora dos dados administrativos do paciente com interface gráfica, que corre do lado do host e interage com a aplicação do lado do cartão. /* * TODO To change the template for this generated file go to * Window - Preferences - Java - Code Style - Code Templates */ /** * @author Projecto * * TODO To change the template for this generated type comment go to * Window - Preferences - Java - Code Style - Code Templates */ package PatientData; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.util.Properties; import javax.swing.JLabel; import javax.swing.JPanel; import javax.swing.JTextField; import javax.swing.WindowConstants; import opencard.core.service.CardRequest; import opencard.core.service.SmartCard; import opencard.core.terminal.CommandAPDU; import opencard.core.terminal.ResponseAPDU; import opencard.opt.util.PassThruCardService; public class Modelo extends javax.swing.JFrame { private JPanel jPanel1; private JLabel jLabel4; private static JTextField jTextField7; private JLabel jLabel7; private JLabel jLabel8; private static JTextField jTextField5; private JLabel jLabel5; private static JTextField jTextField4; private static JTextField jTextField3; private JLabel jLabel3; private JLabel jLabel1; private static JTextField jTextField1; private static JTextField jTextField2; private static JTextField jTextField9; private static JTextField jTextField10; private JLabel jLabel9; private JLabel jLabel10; private static final int IFD_TIMEOUT = 10; // unit: seconds private static final int MAX_APDU_SIZE = 100; // unit: byte //command ISO7816 SELECT APPLICATION (select the application) // CLA || INS || P1 || P2 || Lc || INPUT DATA static final byte[] CMD_SELECT_APPLICATION = {(byte)0x00, (byte)0xA4, (byte)0x04, (byte)0x00, (byte)0x06, (byte)0x11, (byte)0x00, (byte)0x22, (byte)0x11, (byte)0x00, (byte)0x22}; //command ISO7816 GET PATIENT IDENTIFIER // CLA || INS || P1 || P2 || Le (= length of expected data) static final byte[] CMD_GET_PATIENT_IDENTIFIER ={(byte)0x83, (byte)0x11, (byte)0x00, (byte)0x00, (byte)0x0A}; //command ISO7816 GET PATIENT FIRST NAME // CLA || INS || P1 || P2 || Le (= length of expected data) static final byte[] CMD_GET_FIRST_NAME ={(byte)0x83, (byte)0x21, (byte)0x00, (byte)0x00, (byte)0x0A};
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 142 Fernando Mostardinha * Sandra Silva
//command ISO7816 GET PATIENT LAST NAME // CLA || INS || P1 || P2 || Le (= length of expected data) static final byte[] CMD_GET_LAST_NAME ={(byte)0x83, (byte)0x31, (byte)0x00, (byte)0x00, (byte)0x0A}; //command ISO7816 GET PATIENT BIRTH DATE // CLA || INS || P1 || P2 || Le (= length of expected data) static final byte[] CMD_GET_BIRTH_DATE ={(byte)0x83, (byte)0x41, (byte)0x00, (byte)0x00, (byte)0x0A}; //command ISO7816 GET PATIENT COUNTRY // CLA || INS || P1 || P2 || Le (= length of expected data) static final byte[] CMD_GET_COUNTRY ={(byte)0x83, (byte)0x51, (byte)0x00, (byte)0x00, (byte)0x0A}; //command ISO7816 GET PATIENT PHONE // CLA || INS || P1 || P2 || Le (= length of expected data) static final byte[] CMD_GET_PATIENT_PHONE ={(byte)0x83, (byte)0x71, (byte)0x00, (byte)0x00, (byte)0x0A}; //command ISO7816 GET CONTACT PERSON // CLA || INS || P1 || P2 || Le (= length of expected data) static final byte[] CMD_GET_CONTACT_PERSON ={(byte)0x83, (byte)0x81, (byte)0x00, (byte)0x00, (byte)0x0D}; //command ISO7816 GET CONTACT ADDRESS // CLA || INS || P1 || P2 || Le (= length of expected data) static final byte[] CMD_GET_CONTACT_ADDRESS ={(byte)0x83, (byte)0x91, (byte)0x00, (byte)0x00, (byte)0x1C}; static private int n; /** * Auto-generated main method to display this JFrame */ public static void main(String[] args) { Properties sysProps = System.getProperties(); // set system properties for OCF, PC/SC and PassThruCardServce sysProps.put ("OpenCard.terminals", "com.ibm.opencard.terminal.pcsc10.Pcsc10CardTerminalFactory"); sysProps.put ("OpenCard.services", "opencard.opt.util.PassThruCardServiceFactory"); Modelo inst = new Modelo(); inst.setVisible(true); } public void set(byte[] w){ try { System.out.println("activate Smart Card"); SmartCard.start(); // activate smart card CardRequest cr = new CardRequest(CardRequest.ANYCARD, null, PassThruCardService.class); cr.setTimeout(IFD_TIMEOUT); // set timeout for IFD // wait for a smart card inserted into the terminal System.out.println("wait for smart card - insert smart card in terminal\n"); SmartCard sc = SmartCard.waitForCard(cr); if (sc != null) { // no error occur and a smart card is in the terminal PassThruCardService ptcs = (PassThruCardService) sc.getCardService(PassThruCardService.class, true); String s = new String(); // set APDU buffer size CommandAPDU command = new CommandAPDU(MAX_APDU_SIZE); // create APDU buffer and set size //----- prepare command APDU - SELECT APPLICATION command.append(CMD_SELECT_APPLICATION); // send command and receive response ResponseAPDU response = ptcs.sendCommandAPDU(command); //----- prepare command APDU - SET'S command.setLength(0); command.append(w); // send command and receive response response = ptcs.sendCommandAPDU(command);
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 143 Fernando Mostardinha * Sandra Silva
System.out.println("\ndeactivate Smart Card"); SmartCard.shutdown(); }// if else System.out.println("could not create smart card object (e.g. no ICC in IFD)"); } // try catch (Exception e) { System.err.println("Caught exception '" + e.getClass() + "' - " + e.getMessage() ); } // catch } /** * */ private static void inicializacao() { try { System.out.println("activate Smart Card"); SmartCard.start(); // activate smart card CardRequest cr = new CardRequest(CardRequest.ANYCARD, null, PassThruCardService.class); cr.setTimeout(IFD_TIMEOUT); // set timeout for IFD // wait for a smart card inserted into the terminal System.out.println("wait for smart card - insert smart card in terminal\n"); SmartCard sc = SmartCard.waitForCard(cr); if (sc != null) { // no error occur and a smart card is in the terminal PassThruCardService ptcs = (PassThruCardService) sc.getCardService(PassThruCardService.class, true); String s = new String(); // set APDU buffer size CommandAPDU command = new CommandAPDU(MAX_APDU_SIZE); // create APDU buffer and set size //----- prepare command APDU - SELECT APPLICATION command.append(CMD_SELECT_APPLICATION); // send command and receive response ResponseAPDU response = ptcs.sendCommandAPDU(command); // prepare command APDU - GET PATIENT IDENTIFIER command.setLength(0); command.append(CMD_GET_PATIENT_IDENTIFIER); // send command and receive response response = ptcs.sendCommandAPDU(command); String nova=new String(""); for (n = 0; n < (response.getLength() - 2 ); n++) { s = Integer.toHexString(response.getByte(n)).toUpperCase(); int i=Integer.valueOf(s,16).intValue(); if(i!=0x00){ //converte hex para ascii String aChar=new Character((char)i).toString(); nova=nova+aChar; } } // for jTextField1.setText(nova); //----- prepare command APDU - GET FIRST NAME command.setLength(0); command.append(CMD_GET_FIRST_NAME); // send command and receive response response = ptcs.sendCommandAPDU(command); String nova1=new String(""); for (n = 0; n < (response.getLength() - 2 ); n++) { s = Integer.toHexString(response.getByte(n)).toUpperCase(); int i=Integer.valueOf(s,16).intValue(); if(i!=0x00){ //converte hex para ascii String aChar=new Character((char)i).toString();
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 144 Fernando Mostardinha * Sandra Silva
nova1=nova1+aChar; } } // for jTextField3.setText(nova1); //----- prepare command APDU - GET LAST NAME command.setLength(0); command.append(CMD_GET_LAST_NAME); // send command and receive response response = ptcs.sendCommandAPDU(command); String nova2=new String(""); for (n = 0; n < (response.getLength() - 2 ); n++) { s = Integer.toHexString(response.getByte(n)).toUpperCase(); int i=Integer.valueOf(s,16).intValue(); if(i!=0x00){ //converte hex para ascii String aChar=new Character((char)i).toString(); nova2=nova2+aChar; } } // for jTextField2.setText(nova2); //----- prepare command APDU - GET BIRTH DATE command.setLength(0); command.append(CMD_GET_BIRTH_DATE); // send command and receive response response = ptcs.sendCommandAPDU(command); String nova3=new String(""); for (n = 0; n < (response.getLength() - 2 ); n++) { s = Integer.toHexString(response.getByte(n)).toUpperCase(); int i=Integer.valueOf(s,16).intValue(); if(i!=0x00){ //converte hex para ascii String aChar=new Character((char)i).toString(); nova3=nova3+aChar; } } // for jTextField4.setText(nova3); //----- prepare command APDU - GET COUNTRY command.setLength(0); command.append(CMD_GET_COUNTRY); // send command and receive response response = ptcs.sendCommandAPDU(command); String nova4=new String(""); for (n = 0; n < (response.getLength() - 2 ); n++) { s = Integer.toHexString(response.getByte(n)).toUpperCase(); int i=Integer.valueOf(s,16).intValue(); if(i!=0x00){ //converte hex para ascii String aChar=new Character((char)i).toString(); nova4=nova4+aChar; } } // for jTextField5.setText(nova4); //----- prepare command APDU - GET PATIENT PHONE command.setLength(0); command.append(CMD_GET_PATIENT_PHONE); // send command and receive response response = ptcs.sendCommandAPDU(command); String nova6=new String(""); for (n = 0; n < (response.getLength() - 2 ); n++) { s = Integer.toHexString(response.getByte(n)).toUpperCase();
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 145 Fernando Mostardinha * Sandra Silva
int i=Integer.valueOf(s,16).intValue(); if(i!=0x00){ //converte hex para ascii String aChar=new Character((char)i).toString(); nova6=nova6+aChar; } } // for jTextField7.setText(nova6); //----- prepare command APDU - GET CONTACT PERSON command.setLength(0); command.append(CMD_GET_CONTACT_PERSON); // send command and receive response response = ptcs.sendCommandAPDU(command); String nova7=new String(""); for (n = 0; n < (response.getLength() - 2 ); n++) { s = Integer.toHexString(response.getByte(n)).toUpperCase(); int i=Integer.valueOf(s,16).intValue(); if(i!=0x00){ //converte hex para ascii String aChar=new Character((char)i).toString(); nova7=nova7+aChar; } } // for jTextField9.setText(nova7); //----- prepare command APDU - GET CONTACT ADDRESS command.setLength(0); command.append(CMD_GET_CONTACT_ADDRESS); // send command and receive response response = ptcs.sendCommandAPDU(command); String nova8=new String(""); for (n = 0; n < (response.getLength() - 2 ); n++) { s = Integer.toHexString(response.getByte(n)).toUpperCase(); int i=Integer.valueOf(s,16).intValue(); if(i!=0x00){ //converte hex para ascii String aChar=new Character((char)i).toString(); nova8=nova8+aChar; } } // for jTextField10.setText(nova8); System.out.println("\ndeactivate Smart Card"); SmartCard.shutdown(); }// if else System.out.println("could not create smart card object (e.g. no ICC in IFD)"); } // try catch (Exception e) { System.err.println("Caught exception '" + e.getClass() + "' - " + e.getMessage() ); } // catch } public Modelo() { super(); initGUI(); inicializacao(); } private void initGUI() {
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 146 Fernando Mostardinha * Sandra Silva
try { setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); this.getContentPane().setLayout(null); { jPanel1 = new JPanel(); this.getContentPane().add(jPanel1); jPanel1.setBounds(0, 0, 392, 10); } { jTextField1 = new JTextField(); this.getContentPane().add(jTextField1); jTextField1.setBounds(107, 19, 275, 30); jTextField1.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) { jTextField1ActionPerformed(evt); } }); } { jLabel1 = new JLabel(); this.getContentPane().add(jLabel1); jLabel1.setText("Patient Identifier"); jLabel1.setBounds(10, 19, 100, 28); } { jLabel3 = new JLabel(); this.getContentPane().add(jLabel3); jLabel3.setText("Patient Name"); jLabel3.setBounds(10, 53, 83, 30); } { jTextField3 = new JTextField(); this.getContentPane().add(jTextField3); jTextField3.setBounds(107, 54, 132, 30); jTextField3.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) { jTextField3ActionPerformed(evt); } }); } { jTextField2 = new JTextField(); this.getContentPane().add(jTextField2); jTextField2.setBounds(240, 54, 142, 30); jTextField2.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) { jTextField2ActionPerformed(evt); } }); } { jLabel4 = new JLabel(); this.getContentPane().add(jLabel4); jLabel4.setText("Birth Data"); jLabel4.setBounds(10, 91, 60, 28); } { jTextField4 = new JTextField(); this.getContentPane().add(jTextField4); jTextField4.setBounds(107, 90, 275, 30); jTextField4.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) { jTextField4ActionPerformed(evt); } }); } { jLabel5 = new JLabel(); this.getContentPane().add(jLabel5); jLabel5.setText("Country"); jLabel5.setBounds(10, 125, 83, 28); } {
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 147 Fernando Mostardinha * Sandra Silva
jTextField5 = new JTextField(); this.getContentPane().add(jTextField5); jTextField5.setBounds(107, 126, 275, 30); jTextField5.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) { jTextField5ActionPerformed(evt); } }); } { jLabel7 = new JLabel(); this.getContentPane().add(jLabel7); jLabel7.setText("Address Details"); jLabel7.setBounds(15, 237, 108, 30); } { jTextField7 = new JTextField(); this.getContentPane().add(jTextField7); jTextField7.setBounds(107, 271, 275, 30); jTextField7.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) { jTextField7ActionPerformed(evt); } }); } { jLabel8 = new JLabel(); this.getContentPane().add(jLabel8); jLabel8.setText("Phone"); jLabel8.setBounds(10, 271, 60, 28); } { jLabel9 = new JLabel(); this.getContentPane().add(jLabel9); jLabel9.setText("Contact Details"); jLabel9.setBounds(198, 317, 194, 30); } { jLabel10 = new JLabel(); this.getContentPane().add(jLabel10); jLabel10.setText("Contact Person"); jLabel10.setBounds(10, 365, 124, 28); } { jTextField9 = new JTextField(); this.getContentPane().add(jTextField9); jTextField9.setBounds(107, 366, 275, 30); jTextField9.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) { jTextField9ActionPerformed(evt); } }); } { jLabel11 = new JLabel(); this.getContentPane().add(jLabel11); jLabel11.setText("Address"); jLabel11.setBounds(10, 413, 60, 25); } { jTextField10 = new JTextField(); this.getContentPane().add(jTextField10); jTextField10.setBounds(107, 410, 275, 30); jTextField10.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent evt) { jTextField10ActionPerformed(evt); } }); } pack(); this.setTitle("Administrative Data"); this.setSize(480, 630); } catch (Exception e) { e.printStackTrace();
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 148 Fernando Mostardinha * Sandra Silva
} } /** * Auto-generated method for setting the popup menu for a component */ private void setComponentPopupMenu(final java.awt.Component parent, final javax.swing.JPopupMenu menu) { parent.addMouseListener(new java.awt.event.MouseAdapter() { public void mousePressed(java.awt.event.MouseEvent e) { if(e.isPopupTrigger()) menu.show(parent, e.getX(), e.getY()); } public void mouseReleased(java.awt.event.MouseEvent e) { if(e.isPopupTrigger()) menu.show(parent, e.getX(), e.getY()); } }); } private void jTextField1ActionPerformed(ActionEvent evt) { String input=evt.getActionCommand(); byte[] newBytes = input.getBytes(); byte comp=(byte)newBytes.length; byte[] CMD_SET_PATIENT_IDENTIFIER; CMD_SET_PATIENT_IDENTIFIER = new byte[comp + 5]; CMD_SET_PATIENT_IDENTIFIER[0]=(byte)0x83; CMD_SET_PATIENT_IDENTIFIER[1]=(byte)0x10; CMD_SET_PATIENT_IDENTIFIER[2]=(byte)0x00; CMD_SET_PATIENT_IDENTIFIER[3]=(byte)0x00; CMD_SET_PATIENT_IDENTIFIER[4]=comp; for(int i=0;i<newBytes.length;i++) CMD_SET_PATIENT_IDENTIFIER[5+i]=newBytes[i]; set(CMD_SET_PATIENT_IDENTIFIER); } private void jTextField2ActionPerformed(ActionEvent evt) { String input=evt.getActionCommand(); byte[] newBytes = input.getBytes(); byte comp=(byte)newBytes.length; byte[] CMD_SET_LAST_NAME; CMD_SET_LAST_NAME = new byte[comp + 5]; CMD_SET_LAST_NAME[0]=(byte)0x83; CMD_SET_LAST_NAME[1]=(byte)0x30; CMD_SET_LAST_NAME[2]=(byte)0x00; CMD_SET_LAST_NAME[3]=(byte)0x00; CMD_SET_LAST_NAME[4]=comp; for(int i=0;i<newBytes.length;i++) CMD_SET_LAST_NAME[5+i]=newBytes[i]; set(CMD_SET_LAST_NAME); } private void jTextField3ActionPerformed(ActionEvent evt) { String input=evt.getActionCommand(); byte[] newBytes = input.getBytes(); byte comp=(byte)newBytes.length; byte[] CMD_SET_FIRST_NAME; CMD_SET_FIRST_NAME = new byte[comp + 5];
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 149 Fernando Mostardinha * Sandra Silva
CMD_SET_FIRST_NAME[0]=(byte)0x83; CMD_SET_FIRST_NAME[1]=(byte)0x20; CMD_SET_FIRST_NAME[2]=(byte)0x00; CMD_SET_FIRST_NAME[3]=(byte)0x00; CMD_SET_FIRST_NAME[4]=comp; for(int i=0;i<newBytes.length;i++) CMD_SET_FIRST_NAME[5+i]=newBytes[i]; set(CMD_SET_FIRST_NAME); } private void jTextField4ActionPerformed(ActionEvent evt) { String input=evt.getActionCommand(); byte[] newBytes = input.getBytes(); byte comp=(byte)newBytes.length; byte[] CMD_SET_BIRTH_DATE; CMD_SET_BIRTH_DATE = new byte[comp + 5]; CMD_SET_BIRTH_DATE[0]=(byte)0x83; CMD_SET_BIRTH_DATE[1]=(byte)0x40; CMD_SET_BIRTH_DATE[2]=(byte)0x00; CMD_SET_BIRTH_DATE[3]=(byte)0x00; CMD_SET_BIRTH_DATE[4]=comp; for(int i=0;i<newBytes.length;i++) CMD_SET_BIRTH_DATE[5+i]=newBytes[i]; set(CMD_SET_BIRTH_DATE); } private void jTextField5ActionPerformed(ActionEvent evt) { String input=evt.getActionCommand(); byte[] newBytes = input.getBytes(); byte comp=(byte)newBytes.length; byte[] CMD_SET_COUNTRY; CMD_SET_COUNTRY = new byte[comp + 5]; CMD_SET_COUNTRY[0]=(byte)0x83; CMD_SET_COUNTRY[1]=(byte)0x50; CMD_SET_COUNTRY[2]=(byte)0x00; CMD_SET_COUNTRY[3]=(byte)0x00; CMD_SET_COUNTRY[4]=comp; for(int i=0;i<newBytes.length;i++) CMD_SET_COUNTRY[5+i]=newBytes[i]; set(CMD_SET_COUNTRY);
}
private void jTextField7ActionPerformed(ActionEvent evt) { String input=evt.getActionCommand(); byte[] newBytes = input.getBytes(); byte comp=(byte)newBytes.length; byte[] CMD_SET_PATIENT_PHONE; CMD_SET_PATIENT_PHONE = new byte[comp + 5]; CMD_SET_PATIENT_PHONE[0]=(byte)0x83; CMD_SET_PATIENT_PHONE[1]=(byte)0x70; CMD_SET_PATIENT_PHONE[2]=(byte)0x00; CMD_SET_PATIENT_PHONE[3]=(byte)0x00; CMD_SET_PATIENT_PHONE[4]=comp; for(int i=0;i<newBytes.length;i++)
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 150 Fernando Mostardinha * Sandra Silva
CMD_SET_PATIENT_PHONE[5+i]=newBytes[i]; set(CMD_SET_PATIENT_PHONE); } private void jTextField9ActionPerformed(ActionEvent evt) { String input=evt.getActionCommand(); byte[] newBytes = input.getBytes(); byte comp=(byte)newBytes.length; byte[] CMD_SET_CONTACT_PERSON; CMD_SET_CONTACT_PERSON = new byte[comp + 5]; CMD_SET_CONTACT_PERSON[0]=(byte)0x83; CMD_SET_CONTACT_PERSON[1]=(byte)0x80; CMD_SET_CONTACT_PERSON[2]=(byte)0x00; CMD_SET_CONTACT_PERSON[3]=(byte)0x00; CMD_SET_CONTACT_PERSON[4]=comp; for(int i=0;i<newBytes.length;i++) CMD_SET_CONTACT_PERSON[5+i]=newBytes[i]; set(CMD_SET_CONTACT_PERSON); } private void jTextField10ActionPerformed(ActionEvent evt) { String input=evt.getActionCommand(); byte[] newBytes = input.getBytes(); byte comp=(byte)newBytes.length; byte[] CMD_SET_CONTACT_ADDRESS; CMD_SET_CONTACT_ADDRESS = new byte[comp + 5]; CMD_SET_CONTACT_ADDRESS[0]=(byte)0x83; CMD_SET_CONTACT_ADDRESS[1]=(byte)0x90; CMD_SET_CONTACT_ADDRESS[2]=(byte)0x00; CMD_SET_CONTACT_ADDRESS[3]=(byte)0x00; CMD_SET_CONTACT_ADDRESS[4]=comp; for(int i=0;i<newBytes.length;i++) CMD_SET_CONTACT_ADDRESS[5+i]=newBytes[i]; set(CMD_SET_CONTACT_ADDRESS); } }
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 151 Fernando Mostardinha * Sandra Silva
Anexo 6 Código da aplicação gestora da informação clínica do paciente para o cartão. /** * @author Projecto * * TODO To change the template for this generated type comment go to * Window - Preferences - Java - Code Style - Code Templates */ package epr_links; import javacard.framework.*; //Class Definition public class Apontador extends javacard.framework.Applet { final static byte Link_CLA = (byte)0xC0; // Instruction set for Apontador final static byte GET_LINKS_ID = (byte)0x10; final static byte GET_LINK = (byte)0x20; final static byte GET_LINK_SIZE = (byte)0x30; final static byte LINK_ADD_REQUEST = (byte)0x40; final static byte ADD_LINK = (byte)0x50; final static byte SELECT = (byte) 0xA4; final static short SW_DATA_ERROR=(short)0x6A83; //erro ao copiar os dados // Códigos de erros para alguns métodos final static short NO_LINKS_ALOCATED=0; final static byte[] NO_MORE_LINKS_ALOCATED={(byte)0xFF}; final static short NO_SPACE_AVAILABLE=1; final static byte[] COPY_ERROR={}; final static short ERROR=0; final static short ERROR_WITH_TAG_A1=0xFF; // Variáveis globais static short size; //numero de bytes necessários para alocar na memória static short len_int; //tamanho intermédio da informação static short pos_arr; //posição do array temporário static short N_act_elem; //numero de elementos alocados na tabela static short index_free; //indice livre da memory static short aux1; // Constants final static short APDU_MAX_SIZE=256; final static short TAG_81=0x81; final static short TAG_82=0x82; final static short TAG_83=0x83; final static short TAG_A1=0xA1; final static short TAG_31=0x31; final static short SIZE_MEMORY= 2000; final static short N_TABLE_ELEMENTS=10; final static short TABLE_ELEMENT_SIZE=15; static byte[] arr = new byte[1000]; static byte[] memory = new byte[SIZE_MEMORY]; static byte[] table=new byte [TABLE_ELEMENT_SIZE*N_TABLE_ELEMENTS]; // The constructor. private Apontador (byte buffer[],short offset,byte length) { if (buffer[offset] == (byte)0) { register(); } }
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 152 Fernando Mostardinha * Sandra Silva
// Every applet running JavaCard 2.0 must implement the following // three functions. // You create the one instance of your applet here. public static void install(byte buffer[],short offset,byte length) { new Apontador(buffer, offset, length); } // This function is called when your applet is selected. public boolean select() { return true; } // The process method dispatches messages to your class methods // depending on the instruction type. public void process(APDU apdu) throws ISOException{ byte buffer[] = apdu.getBuffer(); // Implement a select handler if (selectingApplet()) { ISOException.throwIt(ISO7816.SW_NO_ERROR); } if (buffer[ISO7816.OFFSET_CLA] != Link_CLA) ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED); byte ins = buffer[ISO7816.OFFSET_INS]; switch (ins) { case ADD_LINK: AddLink(apdu); break; case LINK_ADD_REQUEST: LinkAddRequest(apdu); break; case GET_LINKS_ID: GetLinksId(apdu); break; case GET_LINK: GetLink(apdu); break; case GET_LINK_SIZE: GetLinkSize(apdu); break; default: ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED); } } private void LinkAddRequest(APDU apdu) { byte buffer[] = apdu.getBuffer(); pos_arr=0; //procura espaço livre na tabela if(N_act_elem==N_TABLE_ELEMENTS) ISOException.throwIt(ISO7816.SW_FILE_FULL); //procura espaço livre na memória index_free=GetMemToFreeSpace(); if(index_free==NO_SPACE_AVAILABLE) ISOException.throwIt(ISO7816.SW_FILE_FULL);
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 153 Fernando Mostardinha * Sandra Silva
//verifica se existe espaço suficiente short free_size=(short)(SIZE_MEMORY-index_free); size=(short)(buffer[ISO7816.OFFSET_CDATA]); //o que vai para a memória tem tamanho igual ao tamanho total do apontador-13 //onde 13 corresponde a 1 byte da tag da data,1 byte do campo length da data, 8 bytes //correspondentes ao campo value da data,1 byte da tag do factor de relevancia //mais 1 byte do campo length do factor de relevancia e finalmente 1 byte correspondente //ao campo value do factor de relevancia short size_mem=(short)(size-13); if(size_mem <= free_size) ISOException.throwIt(ISO7816.SW_NO_ERROR); else ISOException.throwIt(ISO7816.SW_CONDITIONS_NOT_SATISFIED); } private void AddLink(APDU apdu){ byte[] buffer=apdu.getBuffer(); //decrementa o numero total de bytes do campo LC size-=(short)buffer[ISO7816.OFFSET_LC]; //compara if(size==-1) ISOException.throwIt(ISO7816.SW_DATA_INVALID); //copia para o array temporário short off_novo=Util.arrayCopy(buffer,(short)(ISO7816.OFFSET_CDATA),arr,pos_arr,(short)buffer[ISO7816.OFFSET_LC]); pos_arr=off_novo; //verifica se o size igual a zero if(size>0) ISOException.throwIt(ISO7816.SW_NO_ERROR); else { short index_mem=index_free; //le o 1o e o 2o elementos do array temp para saber o comprimento e concatena-os num short short total_bytes=Util.getShort(arr,(short)1); //vai buscar o índice do link livre da tabela short ind_table=(short)(N_act_elem*15); //vai procurar link_date no array temp aux1=GetIdxTagLen(TAG_81,arr); if(aux1==ERROR) ISOException.throwIt(ISO7816.SW_WRONG_DATA); //copia-o para a tabela Util.arrayCopy(arr,(short)(aux1+2),table,(short)(ind_table+2),(short)8); //copia info do array temp para a memória, desde o índice zero até ao índice inferior //ao do tag do link date short id_mem=Util.arrayCopy(arr,(short)0,memory,index_mem,(short)(aux1-1)); //procura o relevancy factor aux1=GetIdxTagLen(TAG_82,arr); if(aux1==ERROR) ISOException.throwIt(ISO7816.SW_WRONG_DATA); //copia-o para a tabela Util.arrayCopy(arr,(short)(aux1+2),table,(short)(ind_table+10),(short)1); //procura índice da tag A1 correspondente aos Clinical Details short ind_A1=GetIdxTagLen(TAG_A1,arr);
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 154 Fernando Mostardinha * Sandra Silva
if(ind_A1==ERROR) ISOException.throwIt(ISO7816.SW_WRONG_DATA); //uma vez que o comprimento desta tag são 2 bytes, avança 3 casas e vai para a primeira tag //correspondente ao 1o clinical coded detail short ind_CD=(short)(ind_A1+3); //vai para o campo correspondente ao disease code short disease=(short)(ind_CD+4); //copia-o para a table Util.arrayCopy(arr,disease,table,(short)(ind_table+11),(short)4); //copia todo o resto da informação para a memória id_mem=Util.arrayCopy(arr,(short)(aux1+3),memory,id_mem,(short)(total_bytes-(aux1+3))); //copia o offset da memoria para a tabela table[ind_table]=(byte)(index_mem >> 8); table[(short)(ind_table+1)]=(byte)(index_mem & 0xFF); //actualiza o numero de elementos da table N_act_elem++; //apaga o array temp Util.arrayFillNonAtomic(arr,(short)0,(short)arr.length,(byte)0x00); ISOException.throwIt(ISO7816.SW_NO_ERROR); } } private void GetLinksId(APDU apdu) { byte buffer[] = apdu.getBuffer(); short links=GetAllLinksId(); short le=apdu.setOutgoing(); apdu.setOutgoingLength((byte)2); Util.setShort(buffer,(short)0,links); apdu.sendBytes((short)0,(short)2); return; } private void GetLink(APDU apdu){ byte[] buffer=apdu.getBuffer(); byte num=(byte)(buffer[ISO7816.OFFSET_P1]); arr=GetAllInfo(num); if(arr == COPY_ERROR) ISOException.throwIt(SW_DATA_ERROR); if(len_int>APDU_MAX_SIZE) { apdu.setOutgoing(); apdu.setOutgoingLength(APDU_MAX_SIZE); apdu.sendBytesLong(arr,(short)(pos_arr*APDU_MAX_SIZE),APDU_MAX_SIZE); pos_arr++; len_int=(short)(size-APDU_MAX_SIZE); } else { apdu.setOutgoing(); apdu.setOutgoingLength((short)len_int); apdu.sendBytesLong(arr,(short)(pos_arr*APDU_MAX_SIZE),(short)len_int);
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 155 Fernando Mostardinha * Sandra Silva
} } private void GetLinkSize(APDU apdu){ byte[] buffer=apdu.getBuffer(); byte num=(byte)(buffer[ISO7816.OFFSET_P1]); //procura offset do link na tabela short offset=Util.getShort(table,(short)((num-1)*15)); //vai à memória, ao elemento igual ao offset mais um (o elemento igual ao offset contém a tag) buscar o size //lê os 2 bytes e concatena-os num short size=Util.getShort(memory,(short)(offset+1)); len_int=size; pos_arr=0; //envia o size apdu.setOutgoing(); apdu.setOutgoingLength((byte)2); //move o size para o buffer buffer[0]=(byte)(size>>8); buffer[1]=(byte)(size & 0xFF); //envia os dados apdu.sendBytes((short)0,(short)2); } public short GetAllLinksId(){ if(N_act_elem == 0) return NO_LINKS_ALOCATED; else return N_act_elem; } public byte[] GetAllInfo(short n){ //short elem=n; short id_table=(short)((n-1)*15); //busca o offset da memória no índice n da tabela short off_mem=Util.getShort(table,id_table); //busca o offset da tag 83 correspondente ao electronic location //isto porque queremos enviar os dados direitos, ou seja, na ordem correcta //de forma a ser mais fácil manipulá-los no host aux1=GetIdxTagLen(TAG_83,memory); //copia desde o 1o elemento até ao (offset da tag 83 -1), para o array short off_arr=Util.arrayCopy(memory,off_mem,arr,(short)0,(short)(aux1-1)); //copia da tabela a data arr[off_arr]=81; arr[(short)(off_arr+1)]=(byte)8; off_arr=Util.arrayCopy(table,(short)(id_table+2),arr,(short)(off_arr+2),(short)8); //copia da tabela o factor de relevância arr[off_arr]=82; arr[(short)(off_arr+1)]=(byte)1; off_arr=Util.arrayCopy(table,(short)(id_table+10),arr,(short)(off_arr+2),(short)1); //copia toda a informação restante da memória até ao valor do dif off_arr=Util.arrayCopy(memory,aux1,arr,off_arr,(short)(size-aux1)); if(off_arr >= size) return COPY_ERROR; else
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 156 Fernando Mostardinha * Sandra Silva
return arr; } public short GetMemToFreeSpace(){ short len, index; index=0; while(true) { //le os dois bytes da memória e concatena-os num short len=Util.getShort(memory,index); if(len==0) return index; else { index=(short)(index+len+1); if(index<memory.length) index++; else return NO_SPACE_AVAILABLE; } } } public short GetIdxTagLen(short tag,byte[] data){ short xtag,len,index; index=3; while(true) { xtag=data[index]; if(xtag==tag) { aux1=index; return aux1; } else { len=data[(short)(index+1)]; index=(short)(index+len+1); if(index<data.length) index++; else return ERROR; } } } }
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 157 Fernando Mostardinha * Sandra Silva
Autores:
Fernando Mostardinha , etfam@ua.pt
Sandra Silva, slsilva@iol.pt
Orientador
Prof. Doutor Carlos Costa, ccosta@ieeta.pt
Colaborador:
Prof. Doutor José Luís Oliveira, jlo@det.ua.pt
Homepage:
url: sweet.ua.pt/~etfam/projecto.htm
Sistema de informação clínica e genética suportada num cartão inteligente (Java Card )
DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 158 Fernando Mostardinha * Sandra Silva