Sistema de informação clínica e genética suportada num ...sweet.ua.pt/a16669/docs/RelFinal_14285_16669.pdf · suportada num cartão inteligente (JavaCard) Autores: -Fernando Mostardinha,

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

http://www.ua.pt/

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


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


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


DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 v Fernando Mostardinha * Sandra Silva


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


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


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


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


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


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


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


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


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


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.



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;


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

http://www.eclipse.org/



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.



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



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.



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,




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.




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




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).




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.




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]

http://eclipse-plugins.2y.net/eclipse/plugin_details.jsp?id=472



Figura 2.7: Jigloo, plugin gráfico do Eclipse




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.




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




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




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).




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.




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




Figura 2.19: Criação do load file

Figura 2.20: Informação de que o programa foi carregado com sucesso




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




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).




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).




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




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




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.




Figura 2.32: Envio do comando Debit

Figura 2.33: Resposta do comando




Figura 2.34: Nova consulta do saldo do cartão




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.


http://www.opencard.org/



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.



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.

http://www.opencard.org/



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




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...




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:



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



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.



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.



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.



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”.


http://www.ansi.org/



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.




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.


http://ftp.rsa.com/pub/pkcs/doc/



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



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




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.



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.



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




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.

http://www.temporeal2000.com/paginas/biometria.htm




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.




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



"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)




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



• 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



- 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)



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?



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.



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.



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.



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




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




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




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:




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.




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



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.


http://wwwtcs.inf.tu-dresden.de/~ohme/dud/smartcard.pdf



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



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.




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.




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




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.



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.




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.




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.




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




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.



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




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



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.




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.



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.




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




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.



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]



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


http://www.multos.com/default.cfm/loaddoc.433



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.

http://www.eecg.toronto.edu/%7Eali/ferro/tutorial.html



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]

http://www.multos.com/



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.



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.



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.



• 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


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


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.



• 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.


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.



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 ){



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 {


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.



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:


// 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)


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)




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);



// 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).



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


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 Data Field não toma nenhum valor.



• 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


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.



• 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.


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.



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




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.




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.



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


Informação

do 2º apontador da tabela

Informação

do 3º apontador da tabela

.

.

.

.

.

.

Tabela 5.9: Estrutura de dados dos apontadores



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




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




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.



Figura 5.6: Fluxograma do comando LINK ADD REQUEST O comando definiu-se da forma seguinte:

Comando APDU


0xC0 0x40 0x0 0x0 * Tamanho dos

dados a enviar

-

Tabela 5.11: Comando APDU definido para o comando LINK ADD REQUEST




• 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.



Figura 5.7: Fluxograma do comando ADD LINK



O comando foi definido como:

Comando APDU


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


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.


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



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 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.



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:


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.




• 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.



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.



Figura 5.10: Fluxograma do comando GET LINK



A definição do comando é realizada da seguinte forma:


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.





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




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




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.



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



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.



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

http://wwwtcs.inf.tu-dresden.de/%7Eohme/dud/smartcard.pdf

http://developers.sun.com/techtopics/mobility/javacard/articles/javacard1/


http://www-106.ibm.com/developerworks/java/library/os-ecov/?t=egrL262&p=starteclipseplat#N10049

http://www-106.ibm.com/developerworks/java/library/os-ecov/?t=egrL262&p=starteclipseplat#N10049

http://www.ansi.org/

http://developers.sun.com/techtopics/mobility/javacard/articles/javacard1/

http://eclipse-plugins.2y.net/eclipse/plugin_details.jsp?id=472



[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



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() {



//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 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){


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



Anexo 2 Código do programa SimpleOCF

/*



*/

/**

* @author Projecto

*

* TODO To change the template for this generated type comment go to


*/

import java.util.*;





private static final int IFD_TIMEOUT = 10; // unit: seconds

private static final int MAX_APDU_SIZE = 100; // unit: byte



final byte[] CMD_SELECT_APPLICATION = {(byte)0x00, (byte)0xA4, (byte)0x04, (byte)0x00, (byte)0x07,

(byte)0x11, (byte)0x22, (byte)0x33, (byte)0x44,


// command ISO7816 VERIFY PIN (verify the pin inserted)


final byte[] CMD_VERIFY_PIN ={(byte)0x80, (byte)0x40, (byte)0x00, (byte)0x00, (byte)0x04, (byte)0x00,


// command ISO7816 DEPOSIT (add value to the card balance)


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)


final byte[] CMD_VIEW_BALANCE ={(byte)0x80, (byte)0x30, (byte)0x00, (byte)0x00, (byte)0x01};

private int n, x;

private byte[] i;



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 {



CardRequest cr = new CardRequest(CardRequest.ANYCARD, null, PassThruCardService.class);





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;


} // for



CommandAPDU command = new CommandAPDU(MAX_APDU_SIZE); // create APDU buffer and set size

//----- prepare command APDU - SELECT APPLICATION








if (s.length() == 1) s = "0" + s;


} // for








if (s.length() == 1) s = "0" + s;


} // for


//----- prepare command APDU - VERIFY PIN

command.setLength(0);

command.append(CMD_VERIFY_PIN);


response = ptcs.sendCommandAPDU(command);



for (n = 0; n < command.getLength(); n++) {


if (s.length() == 1) s = "0" + s;


} // for


// show int response apdu


for (n=0; n<response.getLength(); n++) {


if (s.length() == 1) s = "0" + s;


} // for


//----- prepare command APDU - VIEW BALANCE


command.append(CMD_VIEW_BALANCE);







if (s.length() == 1) s = "0" + s;


} // for






if (s.length() == 1) s = "0" + s;


}//for


//----- prepare command APDU - DEPOSIT




command.append(CMD_DEPOSIT);







if (s.length() == 1) s = "0" + s;


} // for






if (s.length() == 1) s = "0" + s;


} // for


//----- prepare command APDU - VIEW BALANCE


command.append(CMD_VIEW_BALANCE);







if (s.length() == 1) s = "0" + s;


} // for






if (s.length() == 1) s = "0" + s;


}//for

System.out.print("\n");



} // if

else System.out.println("could not create smart card object (e.g. no ICC in IFD)");

} // try


System.err.println("Caught exception '" + e.getClass() + "' - " + e.getMessage() );

} // catch



finally {

System.exit(0);

} // finally

} // run


System.out.println("---------------\nStart SimpleOCF\n");

SimpleOCF OCF = new SimpleOCF();

OCF.run();

} // main

} //class



Anexo 3 Código do programa StringOCF

/*



*/

/**

* @author Projecto

*

* TODO To change the template for this generated type comment go to


*/

import java.util.*;




public class StringOCF {

private static final int IFD_TIMEOUT = 10; // unit: seconds

private static final int MAX_APDU_SIZE = 100; // unit: byte



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


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


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



public void run() {

try {



CardRequest cr = new CardRequest(CardRequest.ANYCARD, null, PassThruCardService.class);





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;


} // for



CommandAPDU command = new CommandAPDU(MAX_APDU_SIZE); // create APDU buffer and set size

//----- prepare command APDU - SELECT APPLICATION








if (s.length() == 1) s = "0" + s;


} // for






if (s.length() == 1) s = "0" + s;


} // for


//----- prepare command APDU - GET STRING




command.append(CMD_GET_STRING);







if (s.length() == 1) s = "0" + s;


} // for






if (s.length() == 1) s = "0" + s;


} // for


//----- prepare command APDU - SEND STRING


command.append(CMD_SEND_STRING);







if (s.length() == 1) s = "0" + s;


} // for






if (s.length() == 1) s = "0" + s;


}//for


//----- prepare command APDU - GET STRING


command.append(CMD_GET_STRING);









if (s.length() == 1) s = "0" + s;


} // for






if (s.length() == 1) s = "0" + s;


} // for




} // if

else System.out.println("could not create smart card object (e.g. no ICC in IFD)");

} // try


System.err.println("Caught exception '" + e.getClass() + "' - " + e.getMessage() );

} // catch

finally {

System.exit(0);

} // finally

} // run


System.out.println("---------------\nStart StringOCF\n");

StringOCF OCF = new StringOCF();

OCF.run();

} // main

}



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.



// 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;



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();



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; }



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);



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();



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; } }



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};



//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);



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();



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();



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() {



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); } {



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();



} } /** * 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];



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++)



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); } }



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(); } }



// 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);



//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);



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);



} } 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



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; } } } }



Autores:

Fernando Mostardinha , [email protected]

Sandra Silva, [email protected]

Orientador

Prof. Doutor Carlos Costa, [email protected]

Colaborador:

Prof. Doutor José Luís Oliveira, [email protected]

Homepage:

url: sweet.ua.pt/~etfam/projecto.htm

mailto:[email protected]






Documents

Sistema de informação clínica e genética suportada num ...sweet.ua.pt/a16669/docs/RelFinal_14285_16669.pdf · suportada num cartão inteligente (JavaCard) Autores: -Fernando Mostardinha,