Sistema de informação clínica e genética suportada num cartão inteligente (JavaCard)

Transcrição

1 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, Sandra Silva, Orientador: Prof. Doutor Carlos Costa Colaborador: Prof. Doutor José Luís Oliveira Universidade de Aveiro, 15 de Julho de 2005

2 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 ii

3 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 iii

4 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 iv

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

6 Í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 Introdução Objectivos: 2 Capítulo Ferramentas Tecnológicas: ECLIPSE O Eclipse Eclipse, o código aberto, open source Consórcio Eclipse Aspectos Técnicos da Plataforma Eclipse Componentes Plataforma Runtime Workspace Suporte de equipa Editor de texto Fácil depuração com sugestões Quick Fix suggestions Consola Criação de uma classe no Eclipse Jigloo GUI Builder Cyberflex Access SDK OpenCard Framework 29 Capítulo SmartCard Introdução História do SmartCard Pontos de contacto de um Smart Card Sistema operativo do Smart Card Sistemas Operativos do Smart Card no mercado 36 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 vi

7 3.5 Tipos de Smart Card Segurança num Smart Card Princípios em segurança Privacidade Criptografia Simétrica Criptografia Assimétrica Integridade Autentificação do código da mensagem Não repúdio (Non-Repudiation) Assinatura Digital Autenticação Certificados Verificação Códigos de Identificação Pessoal (PIN) Biometria Leitores / Terminais para Smart Card Desenvolvimento de ferramentas para Smart Card Gestão do Smart Card Alguns exemplos de aplicações para projectos Smart Card Futuro dos Smart Cards PC/SC Interface de Migração PC/SC Comunicação Smart Card Modelo de Comunicação Smart Card Protocolo APDU Comando APDU 59 U Resposta APDU Processando APDUs Limitações da linguagem Java Card 63 Capítulo JavaCard Arquitectura de um Javacard Características de segurança de um Java Card Máquina Virtual Javacard (JCVM) Ficheiros CAP e ficheiros de Exportação Conversor Javacard Descodificador/leitor Javacard Instalador JavaCard e programa interface do instalador do cartão Java Card Runtime Environment Características do Java Card Runtime (JCRE) Java Card API Java Card Applets Convenção de nomes para pacotes e aplicações Processo de desenvolvimento de uma applet Limitações e problemas 81 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 vii

8 4.12 Rivais e futuro do JavaCard Conclusões 84 Capítulo Protótipo desenvolvido Introdução Início da aplicação, dos conceitos aprendidos e estudo do software disponível 86 o GET BALANCE APDU 88 o DEBIT APDU Estudo da plataforma Open Card Framework (OCF) Desenvolvimento da aplicação gestora dos dados administrativos do paciente Desenvolvimento da aplicação do cartão Desenvolvimento da interface gráfica Desenvolvimento da interligação entre a aplicação do cartão e interface gráfica Desenvolvimento da aplicação gestora da informação clínica do paciente Desenvolvimento da aplicação do cartão Desenvolvimento da interface gráfica Conclusões 116 Capítulo Conclusões 118 Referências 120 Anexos 122 Anexo Anexo Anexo Anexo Anexo Anexo DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 viii

9 Í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 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 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 ix

10 Figura 3.14: Comunicação através de APDU U 58 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 Figura 3.19: Valores ISO 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 x

11 Í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 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 xi

12 Lista de acrónimos AID ANSI APDU Application IDentifier American National Standards Institute Application Programming Data Unit API Aplication Programmer s InterfaceCAD Card Acceptance Device ATM CAD CAP CHIP CLA CLK Asynchronous Transfer Mode Card Acceptance Device Converted APplet file Abreviatura de microchip CLAsse Clock CPL Common Public License v1.0 DES EEPROM FIPS GNU GSM GUI IDE Data Encryption Standard Electrically Erasable Programmable Read-Only Memory Federam Information Processing Standard General Public License Global System for Mobile communications Graphical User Interface Integrated Development Environment DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 xii

13 IFD INS ISO JAR JCRE JCVM JVM Lc Le MAC MFC MS-PDC OCF InterFace Device Instruction International Organization for Standardization Java ARchive Java Card Runtime Environment Java Card Virtual Machine Java Virtual Machine Comprimento dos dados a enviar Comprimento dos dados a receber Message Authentication Code Multi Function Card Multi Service Patient Data Card Open Card Framework P1, P2 Parâmetros PC/SC PDC PIN PIX PMB PUK RAM Personal Computer / Smart Card Patient Data Card Personal Identification Number Property Identifier extension Porta Moedas multibanco Personal Unblocking code Random Access Memory DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 xiii

14 RID ROM RS232 RSA SO SSL SWT TCP/IP UA UV URL Resource IDentifier Read Only Memory Recommended Standard 232 (computer serial interface, IEEE) Rivest Shamir Adleman, algoritmo de Criptografia assimétrica Sistema Operativo Secure Sockets Layer Standard Widget Toolkit Transmission Control Protocol / Internet Protocol Universidade de Aveiro Ultra Violeta Unique Resource Locator DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 xiv

15 Capítulo 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 1

16 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 2

17 Capítulo 2 2 Ferramentas Tecnológicas: 2.1 ECLIPSE 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 3

18 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 4

19 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 5

20 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 6

21 Figura 2.1: Componentes principais e APIs da plataforma Eclipse 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 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 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, DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 7

22 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.) 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 8

23 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 9

24 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 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). DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 10

25 Figura 2.6: Criação de uma classe no Eclipse 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 11

26 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. Podese 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] DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 12

27 Figura 2.7: Jigloo, plugin gráfico do Eclipse DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 13

28 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 14

29 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 15

30 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 16

31 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). DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 17

32 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 18

33 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 19

34 Figura 2.19: Criação do load file Figura 2.20: Informação de que o programa foi carregado com sucesso DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 20

35 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 21

36 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). DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 22

37 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). DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 23

38 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 C 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 24

39 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 25

40 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 C 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 Finalmente, através da figura 2.34 verifica-se que o saldo do cartão foi decrementado, passando agora a ser de nove viagens. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 26

41 Figura 2.32: Envio do comando Debit Figura 2.33: Resposta do comando DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 27

42 Figura 2.34: Nova consulta do saldo do cartão DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 28

43 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 29

44 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 30

45 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 31

46 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 32

47 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... DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 33

48 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 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: DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 34

49 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 35

50 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 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 36

51 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 37

52 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 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 38

53 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 39

54 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] 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 40

55 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 41

56 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 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 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 42

57 integridade e da origem das trocas de dados na transacção. É a prevenção da falsificação Assinatura Digital Figura 3.9: Atribuição da Assinatura Digital e Verificação 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 43

58 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 44

59 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 45

60 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 46

61 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 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 47

62 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 48

63 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 ( mas este esforço é ainda embrionário, uma vez que esta entidade foi estabelecida em Abril de 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 49

64 "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) DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 50

65 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 51

66 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 52

67 - 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) DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 53

68 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? DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 54

69 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 55

70 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 PC/SC 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 56

71 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 57

72 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 58

73 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 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 : 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 59

74 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 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 60

75 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 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: DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 61

76 Figura 3.21: Códigos de Resposta Status Figura 3.22: Quatro possíveis estruturas do Comando APDU [9] 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 62

77 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 63

78 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 multiaplicacional que incorpora muitas vantagens da linguagem Java. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 64

79 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 65

80 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 66

81 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 67

82 4.2 Características de segurança de um Java Card e protegido. 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 68

83 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 69

84 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 70

85 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 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 71

86 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 72

87 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 73

88 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 74

89 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 75

90 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 76

91 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 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 77

92 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 78

93 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 79

94 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 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 80

95 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 81

96 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] DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 82

97 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 83

98 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 multifacetada plataforma de aplicações e parece ser uma óptima escolha para aplicações com o cartão inteligente. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 84

99 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] DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 85

100 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, eramnos 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 86

101 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 87

102 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 0x 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 88

103 O Data Field corresponde ao campo de dados e como referido no ponto acima, não toma nenhum valor. O campo Le corresponde ao comprimento dos dados esperados pelo response, e neste comando tem o comprimento de 1 byte. Response APDU Data Status words Significado das Status Words Número de viagens 0x9000 Operação bem sucedida Tabela 5.2: Response APDU definido O campo Data da response APDU contém o balanço das viagens. o DEBIT APDU Comando APDU CLA INS P1 P2 Lc Data Field Le 0xC0 0x20 0x0 0x0 1 Viagem - Tabela 5.3: Comando APDU definido para o comando DEBIT O campo CLA identifica a estrutura do comando, tal como no comando GET BALANCE O campo INS identifica a instrução a realizar, neste caso, a operação de Debit. P1 e P2 não são usados neste caso e por isso têm os dois o valor zero. O campo Lc identifica o comprimento de dados a enviar para o cartão, nesta aplicação, corresponde a 1 byte. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 89

104 O Data Field contém a viagem a descontar, ou seja, o número de viagens a descontar, visto que existe a possibilidade de poder descontar mais do que uma. O campo Le corresponde ao comprimento dos dados esperados pelo response e neste comando não tem qualquer valor, dado que não são esperados dados, apenas status words a identificarem se a operação foi ou não bem sucedida. Response APDU Data Status Words Significado das Status Words - 0x9000 Operação bem sucedida - 0x6A83 Débito Inválido Tabela 5.4: Response APDU definido para o comando DEBIT O campo Data da response APDU não contém dados. Depois da fase de projecção, passamos ao desenvolvimento do código, que pode ser consultado em Anexo 1. A sua compilação foi realizada no Eclipse. Depois de compilado, testamo-lo no Cyberflex Access Toolkit 4.3, programa este explicado num capítulo anterior (ver ponto 2.2). 5.3 Estudo da plataforma Open Card Framework (OCF) Como foi referido anteriormente no capítulo 3, a plataforma OpenCard Framework favorece a interacção entre o reader dos cartões e a aplicação no cartão. A sua arquitectura baseia-se na tecnologia Java, e resultou no aumento da portabilidade e da interoperabilidade, pois permite a interacção entre utilizador e cartão sem recurso ao software Cyberflex, ainda que este seja necessário para carregar inicialmente a aplicação no cartão. Deste modo, é possível executar os comandos APDU com maior facilidade. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 90

105 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 ){ DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 91

106 System.out.println(" \nStart SimpleOCF\n"); SimpleOCF OCF = new SimpleOCF(); OCF.run(); // main //class Antes de podermos trabalhar com o OCF (OpenCard Framework), é necessário inicializá-lo, e no final desligá-lo, de forma a libertar os recursos do sistema. Uma vez que podem ocorrer erros (por exemplo, no caso do utilizador remover o cartão enquanto este está a ser acedido), torna-se também necessário implementar tratamento de erros. Um exemplo, pode ser visto no código abaixo: try { System.out.println("activate Smart Card"); SmartCard.start(); // activate smart card //... // try System.out.println("\ndeactivate Smart Card"); SmartCard.shutdown(); 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 92

107 Depois de lidarmos com o código envolvente e necessário para a inicialização do OCF, segue-se a execução de um CardRequest, de forma a que um cartão inserido no reader possa ser lido: CardRequest cr = new CardRequest(CardRequest.ANYCARD, null, PassThruCardService.class); cr.settimeout(ifd_timeout); // set timeout for IFD // wait for a smart card inserted into the terminal System.out.println("wait for smart card - insert smart card in terminal\n"); SmartCard sc = SmartCard.waitForCard(cr); O método waitforcard irá retornar um objecto SmartCard que será usado pela aplicação para se referir ao cartão quando este for inserido no reader. Os comandos APDU serão agora definidos como constantes dentro da classe. Um exemplo: public class SimpleOCF { // command ISO7816 SELECT APPLICATION (select the application) // CLA INS P1 P2 Lc INPUT DATA final byte[ ] CMD_SELECT_APPLICATION = {(byte)0x00, (byte)0xa4, (byte)0x04, (byte)0x00, (byte)0x07, (byte)0x11, (byte)0x22, (byte)0x33, (byte)0x44, (byte)0x55, (byte)0x66, (byte)0x77 ; // command ISO7816 VERIFY PIN (verify the pin inserted) // CLA INS P1 P2 Lc INPUT DATA final byte[] CMD_VERIFY_PIN ={(byte)0x80, (byte)0x40, (byte)0x00, (byte)0x00, (byte)0x04, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00 ; // command ISO7816 DEPOSIT (add value to the card balance) // CLA INS P1 P2 Lc INPUT DATA DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 93

108 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 A 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); DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 94

109 // 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). DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 95

110 5.4.1 Desenvolvimento da aplicação do cartão A função principal da aplicação reside em ler e escrever os dados pessoais do paciente. Em termos técnicos, faz os get s e set s dos dados pretendidos. É possível observar abaixo as duas definições de get e set que são idênticas para todos os get s e set s. o GET APDU Comando APDU CLA INS P1 P2 Lc Data Field Le 0x83 * 0x0 0x0 - - ** Tabela 5.5: Comando do APDU definido para o comando GET O campo CLA identifica a estrutura do comando, definida por nós, tais como todos os outros campos do comando. O campo INS identifica a instrução a realizar. Nesta aplicação, os get s realizados são (*): PATIENT IDENTIFIER = 0x11 FIRST NAME = 0x21 LAST NAME = 0x31 BIRTH DATE = 0x41 COUNTRY = 0x51 PATIENT PHONE = 0x71 CONTACT PERSON = 0x81 CONTACT ADDRESS = 0x91 P1 e P2 não são usados neste caso e por isso têm os dois o valor zero. O campo Lc, neste comando não tem nenhum valor pois nenhuma informação vai ser enviada para o cartão, mas sim recebida deste. O Data Field não toma nenhum valor. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 96

111 O campo Le (**) corresponde ao comprimento dos dados esperados pelo response e terá comprimentos diferentes consoante o get a realizar. Response APDU Data Status words Significado das Status Words Informação pretendida 0x9000 Operação bem sucedida Tabela 5.6: Response APDU definido para o comando GET O campo Dados da response APDU contém a informação relativa ao get efectuado. o SET APDU Comando APDU CLA INS P1 P2 Lc Data Field Le 0x83 * 0x0 0x0 ** Tabela 5.7: Comando APDU definido para o comando SET Informação a guardar no cartão 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. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 97

112 O campo Lc (**) identifica o comprimento de dados a enviar para o cartão e conforme o set a realizar terá comprimentos diferentes. O Data Field contém a informação a guardar no cartão. O campo Le corresponde ao comprimento dos dados esperados pelo response e neste comando não tem qualquer valor, dado que não são esperados nenhuns dados, apenas status words a identificarem se a operação foi ou não bem sucedida. Response APDU Data Status Words Significado das Status Words - 0x9000 Operação bem sucedida Tabela 5.8: Response APDU definido para o comando SET O campo Data da response APDU não contém dados. O código respeitante a esta fase encontra-se no Anexo 4. DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 98

113 5.4.2 Desenvolvimento da interface gráfica Figura 5.1: Dados administrativos 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. 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 DET/UA * Lic. Eng. Electrónica e Telecomunicações * Relatório Final Projecto * 15/Jul/05 99