UNIVERSIDADE ANHEMBI MORUMBI DAVI PEREIRA DO CARMO JULIANO ASSUNÇÃO MEDEIROS DE SOUZA RODRIGO LOVAGLIO BEZERRA TIAGO GODOI

Transcrição

1 UNIVERSIDADE ANHEMBI MORUMBI DAVI PEREIRA DO CARMO JULIANO ASSUNÇÃO MEDEIROS DE SOUZA RODRIGO LOVAGLIO BEZERRA TIAGO GODOI IMPLEMENTANDO APLICAÇÕES SMART CARDS NA PLATAFORMA JAVA CARD São Paulo 2009

2 DAVI PEREIRA DO CARMO JULIANO ASSUNÇÃO MEDEIROS DE SOUZA RODRIGO LOVAGLIO BEZERRA TIAGO GODOI IMPLEMENTANDO APLICAÇÕES SMART CARDS NA PLATAFORMA JAVA CARD Orientador: MSc Augusto Mendes Gomes Júnior Trabalho de Conclusão de Curso apresentado como exigência parcial para a obtenção de título de bacharel em Ciência da Computação da Universidade Anhembi Morumbi. São Paulo 2009

3 I31 Implementando aplicações Smart Cards na Plataforma Java Card / Davi Pereira do Carmo, [et.al.] f.: il.; 30 cm. Orientador: Augusto Mendes Gomes Junior. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Universidade Anhembi Morumbi, São Paulo, Bibliografia: f Ciência da Computação. 2. Smart Card. 3. Java Card. I. Título. CDD 004

4 DAVI PEREIRA DO CARMO JULIANO ASSUNÇÃO MEDEIROS DE SOUZA RODRIGO LOVAGLIO BEZERRA TIAGO GODOI IMPLEMENTANDO APLICAÇÕES SMART CARDS NA PLATAFORMA JAVA CARD Orientador: MSc Augusto Mendes Gomes Júnior Trabalho de conclusão de curso apresentado como exigência parcial para a obtenção de título de bacharel em Ciência da Computação da Universidade Anhembi Morumbi. Aprovado em Professor Universidade Anhembi-Morumbi Professor Universidade Anhembi-Morumbi Professor Universidade Anhembi-Morumbi

5 Dedico este trabalho a Deus, que nos deu tudo, o Dom da Vida. Aos nossos pais, nossa família, por nos ensinarem a retidão do caminho.

6 AGRADECIMENTOS Inicialmente, gostaríamos de agradecer ao Igor Medeiros pelo incentivo e apoio. Um muito obrigado ao Professor Luis Fernando Aires pela oportunidade concedida de apresentarmos o nosso projeto e sempre que possível nos ajudou. Um agradecimento especial ao Professor Augusto Gomes nosso orientador, professor e amigo, pela dedicação, esforço e paciência em ajudar por esses anos de trabalho. Aos nossos pais, irmãos, por serem nossos amigos, companheiros e acima de tudo, nossa família. Vocês são tudo em nossas vidas! Um muito e sincero obrigado a todos vocês!

7 É incansável buscar conhecimento! Interminável é sua procura! Aos mestres, que nos abreviam esta procura! O Reconhecimento sempre! (Jose Andre, 2008)

8 RESUMO A utilização de Smart Cards pode facilmente ser observada nas mais diversas áreas: financeira, telecomunicações, governamentais entre tantas outras. E o motivo é a segurança que um Smart Card prove. Java Card é um Smart Card que utiliza a plataforma Java tanto para execução das aplicações contidas no card quanto para o desenvolvimento dessas aplicações. O presente trabalho tem como objetivo a apresentação da tecnologia Java Card para desenvolvimento de software para Smart Cards em um ambiente Open Source. Apresenta também aspectos relativos do hardware e principalmente da plataforma de desenvolvimento de software para Java Card. O processo de desenvolvimento consistiu do levantamento de requisitos modelados utilizando diagramas de UML, sendo estes, Casos de Uso e Diagrama de Classes. Com a modelagem foi iniciado o desenvolvimento da aplicação Bilhete Metropolitano. Para o desenvolvimento foram utilizadas as ferramentas Eclipse acoplado com o plugin JCOP e Netbeans. Ao final deste trabalho é apresentada uma aplicação Wallet para pagamento de tarifa em um ambiente de transporte metropolitano. Palavras- Chave: Smart Card, Java Card, Wallet, Biometria

9 ABSTRACT The use of smart cards can easily be observed in several areas: financial, telecommunications, government, among many others. And the reason is the security that provides a Smart Card. Java Card is a Smart Card that uses the Java platform to run both the applications contained in the card and for the development of these applications. This paper aims to show the Java Card technology for software development for Smart Cards in an Open Source environment. It also presents aspects of the hardware and especially the platform software development for Java Card. The development process consisted of gathering requirements modeled using UML diagrams, and these, Use Cases and Class Diagram. With the modeling was initiated application development Metropolitan Card. For the development tools were used coupled with the Eclipse plugin JCOP and Netbeans. At the end of this paper presents a Wallet application for payment of fare in an environment of metropolitan transport. Key-words: Smart Card, Java Card, Wallet, Biometria

10 FIGURAS FIGURA 2-1 CARTÃO COM CARACTERES GRAVADOS EM ALTO RELEVO, EMBOSSED CARD FIGURA 2-2 COMPOSIÇÃO DA TARJA MAGNÉTICA E ESPECIFICAÇÕES FÍSICAS FIGURA 2-3 CLASSIFICAÇÃO DE UM SMART CARD FIGURA 2-4 PONTOS DE CONTATOS DO SMART CARD FIGURA 2-5 DIAGRAMA EM BLOCOS DE UM LEITOR RFID FIGURA 2-6 DIAGRAMA DE BLOCOS BÁSICO SMART CARD SEM FIO FIGURA 2-7 CARTÃO FABRICADO PELA SHARP COM 1 MB DE MEMÓRIA FLASH FIGURA 2-8 MODELO DE COMUNICAÇÃO FIGURA 2-9 ELEMENTOS DE UMA APLICAÇÃO JAVA CARD FIGURA 3-1 JAVA CARD VIRTUAL MACHINE FIGURA 3-2 SISTEMA DE PARTIÇÕES DAS APPLETS NA PLATAFORMA JAVA CARD FIGURA 4-2 DIAGRAMA DE CASO DE USO DO BILHETE METROPOLITANO FIGURA 4-1 CASOS DE USO DO SISTEMA FIGURA 4-3 DIAGRAMA DE CASO DE USO BILHETE DE TRANSPORTE METROPOLITANO FIGURA 4-4 DIAGRAMA DE CLASSE DO BILHETE METROPOLITANO FIGURA 4-5 DIAGRAMA DE SEQUENCIA DO BILHETE METROPOLITANO FIGURA 5-2 ORGANIZAÇÃO DOS PROJETOS FIGURA 5-1 APLICAÇÃO BILHETE METROPOLITANO DISTRIBUÍDA ENTRE O CARD E O HOST FIGURA 5-3 DEFININDO UM AID PARA O PACOTE DA APPLET FIGURA 5-4 PAINÉIS CAP FILE PROPERTIES E JCOP EXPLORER PODEM SER USADOS PARA SABER QUAIS OS AID USADOS FIGURA 5-5 INTERFACE GRÁFICA PARA OPERAÇÃO DO CARTÃO FIGURA 5-6 APPLET BILHETEONCARD FIGURA 7-1 CASOS DE USO DO COMPONENTE DE AUTENTICAÇÃO FIGURA 7-2 DIAGRAMA DE CASO DE USO DO COMPONENTE DE AUTENTICAÇÃO

11 ÍNDICE DE TABELAS TABELA 1 COMANDO APDU TABELA 2 RESPOSTA APDU TABELA 3 CARACTERÍSTICAS SUPORTADAS E NÃO SUPORTADAS TABELA 4 CREDITAR TABELA 5 VERIFICAR SALDO TABELA 6 DEBITAR PASSAGEM TABELA 7 MÉTODOS NA CLASSE JAVACARD.FRAMEWORK.APPLET TABELA 8 MÉTODOS NA APPLET TABELA 9 CÓDIGO DO COMANDO APDU PARA A ESCOLHA DA CLASSE TABELA 10 CÓDIGO DE COMANDO APDU PARA DETERMINAR QUAL MÉTODO PROCESSARÁ OS DADOS TABELA 11 AUTENTICAR TABELA 12 CHECAR ASSINATURA BIOMÉTRICA TABELA 13 VALIDAR ID

12 LISTA DE ABREVIATURAS E SIGLAS AFIS AID APDU API CAD CAP CLA CLK CPU EEPROM GND ID IDE INS I/O ISO JCDK JCOP JCRE JCVM JDK JME Lc Le NPU PC PIN PIX RAM RF RFID RFU Automated Fingerprint Identification Systems Application Identifier Application Protocol Data Units Application Programming Interface Card Acceptance Device Converted Applet Class of instruction Clock Central Processing Unit Electrically-Erasable Programmable Read-Only Memory Ground Identificador Integrated Development Environment. Instruction Code Input/Output International Organization for Standardization Java Card Development Kit Java Card OpenPlatform Java Card Runtime Environment Java Card Virtual Machine Java Development Kit Java Micro Edition Length of incomming command data Length of outgoing response data Numerical Processing Unit Personal Computer Personal Identification Number Proprietary Identifier Extension Rondon Access Memory Radio-Frequency Radio-Frequency Identification Reserved for future use

13 RID RISC ROM RST SIM Card SO UC UML Vcc Vpp Resource Identifier Reduced Instruction Set Computer Read Only Memory Sigla para RESET Subscriber Identity Module Sistema Operacional Use Case Unified Modeling Language Sigla para nível de tensão de referencia em circuitos elétricos medido em Volts Sigla para nível de tensão em circuitos elétricos medido em Volts

14 SUMÁRIO 1. INTRODUÇÃO OBJETIVO JUSTIFICATIVA ABRANGÊNCIA ESTRUTURA DO TRABALHO SMART CARDS DEFINIÇÃO TIPOS DE CARTÕES Embossed Cards Magnetic Stripe Cards Smart Cards Visão geral Cartões de memória Cartões com Microprocessador Smart Cards Contact Smart Cards Contactless ARQUITETURA DO SMART CARD ROM (Read-Only Memory) EEPROM (Electrically-Erasable Programmable Read-Only Memory) RAM (Randon Access Memory) Flash Memory CPU COMUNICAÇÃO NO SMART CARD Modelo de Comunicação Application Protocol Data Units APDU Classe APDU Processamento das APDUs SISTEMAS OPERACIONAIS SISTEMA SMART CARD JAVA CARD JAVA CARD VIRTUAL MACHINE (JCVM)... 23

15 3.2 JAVA CARD RUNTIME ENVIRONMENT (JCRE) JAVA CARD API (APPLICATION PROGRAMMING INTERFACE) CARACTERÍSTICAS APPLET FIREWALL TRANSAÇÕES ATÔMICAS APPLICATION IDENTIFIER (AID) TRABALHOS RELACIONADOS MODELAGEM BILHETE METROPOLITANO Casos de uso Diagrama de Caso de Uso Descrição de Caso de Uso Diagrama de Classes Diagrama de Sequência DESENVOLVIMENTO AMBIENTE DE DESENVOLVIMENTO Projeto da classe BilheteOnCard Projeto da classe BilheteHost Projeto da classe BilheteHostSwingMain IMPLEMENTANDO A APPLET BILHETEONCARD Definição dos Comandos APDU ANALISES E RESULTADOS SOBRE A APLICAÇÃO DE AUTENTICAÇÃO SOBRE A APLICAÇÃO DE BILHETE METROPOLITANO DIFICULDADES ENCONTRADAS CONCLUSÃO TRABALHOS FUTUROS Aplicação de autenticação Casos de Uso Diagrama de Casos de Uso Descrição de Casos de Uso... 49

16 REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A NORMAS DA ISO ISO ISO ISO ISO ISO ISO ISO ISO ISO ISO ISO APÊNDICE B CONFIGURAÇÃO DO AMBIENTE DE DESENVOLVIMENTO JAVA DEVELOPMENT KIT JAVA CARD DEVELOPMENT KIT ECLIPSE...58 INSTALANDO O PLUGIN JCOP VALIDANDO O PLUGIN JCOP APENDICE C CÓDIGO-FONTE DA APLICAÇÃO BILHETE METROPOLITANO... 70

17 7 1. INTRODUÇÃO As novas tendências do mercado mundial de comercio eletrônico e comunicação digital têm mudado rapidamente a forma com que as pessoas se comunicam e fazem transações. O mundo tornou-se mais interligado onde as transações comerciais estão evoluindo cada vez mais do tradicional face-a-face. Sistemas baseados na tecnologia de Smart Cards estão em uso todos os dias em diversas aplicações como: sistema de saúde, transações bancarias, entretenimento, transporte, telefonia, armazenamento de certificações digitais e muitas outras aplicações (GUILLOU, 2001). Todas estas aplicações são beneficiadas pelos recursos que as plataformas de Smart Cards propiciam (segurança, portabilidade, mobilidade entre outras). Recursos como segurança e portabilidade proporcionam uma forma segura, confiável, conveniente e eficaz para garantir o comércio eletrônico bem como para permitir uma ampla gama de novas aplicações. Existe uma grande carência de soluções computacionais, principalmente em aplicações nas quais a segurança é um ponto crucial, fazendo crescer o interesse das organizações, comunidade acadêmica e desenvolvedora em criar soluções baseadas em Smart Cards, com sua variada tecnologia de programação dentre elas o Java Card (SUN MICROSYSTEMS, 2005-a), devido as suas facilidades e características únicas até o momento. A plataforma Java Card oferece todas as facilidades encontradas nas outras plataformas Java. Java Card torna o desenvolvimento de aplicações para sistemas computacionais com recurso extremamente limitado mais fácil e simplificado ao contrário de seus principais concorrentes. 1.1 OBJETIVO O objetivo deste trabalho é demonstrar o desenvolvimento de aplicações para Smart Cards na plataforma Java Card. Este material de Java Card apresenta o desenvolvimento de aplicações tanto do lado embarcado quanto do lado host. Para isso, foi desenvolvida uma aplicação de Wallet, que é de grande demanda no mercado para mostrar a capacidade desta plataforma.

18 8 1.2 JUSTIFICATIVA Sendo uma das plataformas existentes de Java, o Java Card é pouco difundido no Brasil ao contrário, por exemplo, de Java Micro Edition (SUN MICROSYSTEMS, 2009-b) que também é específica para ambientes embarcados com poucos recursos computacionais. Este trabalho vem contribuir para a disseminação de conhecimento sobre Java Card, oferecendo um material rico para iniciantes nesta tecnologia. A Sun Microsystems trouxe para a indústria de Smart Cards as características que fizeram da tecnologia Java um sucesso. Java Card oferece programação Orientada a Objetos, tornando o ciclo de desenvolvimento mais produtivo, ágil e rápido. A UML (OMG, 2009) pode ser usada para modelar um sistema Java Card. Com isso, componentes de software reutilizáveis passam a ser construídos para as mais diversas aplicações de Smart Cards. Segurança sempre foi um dos grandes apelos da tecnologia Java e não é diferente com a tecnologia Java Card. Java Card disponibiliza um firewall que impede a execução de códigos maliciosos assim como impede também que applets invadam a memória uma das outras. Java Card conta também com ambientes IDE comumente conhecido do desenvolvedor Java como Eclipse e Netbeans para o desenvolvimento de aplicações. Além disso, estas IDE são livres para uso, ou seja, sem custo, ao contrário dos ambientes integrados de outras plataformas de desenvolvimento que são comerciais. A linguagem Java possui uma grande base de desenvolvedores que podem começar a construir aplicações para Java Card imediatamente, sem uma curva de aprendizagem e/ou adaptação grande. Java Card é uma plataforma de desenvolvimento de alto nível, que não requer do desenvolvedor conhecimento intrínseco do hardware dos cartões. Ao criar uma applet, não há necessidade de recompilá-la para cada cartão recém lançado ao contrário das aplicações nativas escritas em Assembly ou C. 1.3 ABRANGÊNCIA O objeto de estudo deste trabalho é a tecnologia Java Card para Smart Cards. Outras tecnologias para Smart Cards como, por exemplo, MULTOS (MULTOS, 2009) não são estudadas. Um conhecimento básico sobre Smart Cards é abordado. Porém, aprofundar conceitualmente a tecnologia de Smart Cards não faz parte do escopo deste trabalho. A aplicação de comércio eletrônico não foi desenvolvida visando um produto comercial. Serviu para mostrar os recursos da tecnologia Java Card e apresentar seu ciclo de desenvolvimento.

19 9 Portanto, não é dada profundidade sobre comércio eletrônico visto que este assunto tem gama suficiente para outro trabalho. O processo de criação de um sistema Java Card é apresentado com: Diagrama UML de Casos de Usos; Diagrama UML de Classes; Configuração do ambiente de desenvolvimento da IDE Eclipse; Configuração do plugin JCOP no ambiente Eclipse; Para a demonstração da execução da aplicação, é feita uma rastreabilidade com o código e itens conceituais da tecnologia Java Card. A demonstração é feita com um ambiente real: utilizando um Smart Card Java Card versão conectado a um computador IBM-PC, rodando Microsoft Windows XP. Por fim, os testes validam os requisitos, casos de uso e segurança. 1.4 ESTRUTURA DO TRABALHO No capítulo 1 é apresentada uma introdução deste trabalho. O capítulo 2, apresenta uma definição de Smart Card, tipos de cartões, sua arquitetura de hardware, seu modelo de comunicação. No capítulo 3, é apresentada uma definição dos componentes básicos utilizados na tecnologia Java Card. No capítulo 4, é apresentada a metodologia do trabalho. No capítulo 5 é apresentado o ambiente de desenvolvimento Java Card. No capítulo 6 estão os resultados dos testes. O capítulo 7 tem a conclusão deste trabalho. Ao final dos capítulos há as referências bibliográficas e apêndices.

20 10 2. SMART CARDS A idéia de introduzir um circuito integrado em um cartão de plástico foi realizada pela primeira vez por dois inventores alemães, Jurgen Dethloff e Helmult Grotrupp, em 1968 (CHEN, 2000). No entanto, o primeiro uso em massa se deu na França no ano de 1983 na utilização de cartões telefônicos, porém a explosão do uso se deu em meados dos anos 90, com a introdução da utilização de Smart Card baseados em SIM CARD utilizados em equipamentos móveis na Europa. 2.1 DEFINIÇÃO Smart Card é a mais nova geração de cartão. Conta com um microchip embutido no cartão com possibilidade de armazenamento, processamento e transmissão dos dados, através de contato ou até mesmo sem fio (RANKL; EFFING, 2003). Os Smart Card oferecem inúmeras vantagens em relação às tecnologias anteriores tanto na capacidade de armazenamento, bem como nas possibilidades de aplicação devido a sua grande flexibilidade e segurança. A mais significativa vantagem dos Smart Cards em relação as outras tecnologias é a capacidade de gravação e proteção das informações contra a manipulação e acesso não autorizado. Dispõem de uma infinidade de mecanismos de segurança para proteção do cartão, como algoritmos de criptografia (CHUCK, 2001). 2.2 TIPOS DE CARTÕES Quando a Diners Club lançou seu primeiro cartão para operações de pagamentos, ele era um simples cartão de papel. Ele logo mudou para um cartão de plástico, mas ainda assim não dispunha de nenhum meio tecnológico para armazenamento de dados de seu portador. A inteligência do uso do cartão estava nas informações estampadas em alto-relevo em sua superfície que eram copiadas através de um simples dispositivo mecânico, sendo transferidas para um papel tornando-se um recibo. Desde então, os esforços para aumentar a eficiência das transações e reduzir as fraudes envolvendo os cartões, tem sido um processo contínuo ao longo dos anos. Os tópicos seguintes apresentam a evolução dos cartões em mais de meio século de existência.

21 Embossed Cards Os Embossed Cards fazem parte da primeira geração de cartões em transações comerciais que tiveram inicio em A tecnologia apesar de parecer muito primitiva foi muito difundida pela sua simplicidade e versatilidade como cartões de crédito. Não utilizava nenhuma fonte de energia elétrica ou conexão a alguma rede de dados para realização de transações (RANKL; EFFING, 2003). A figura 2-1 apresenta um dos cartões de alto relevo da MasterCard. Figura 2-1 Cartão com caracteres gravados em alto relevo, embossed Card. Fonte: HOLOPHILE (2006, p.20) Magnetic Stripe Cards Os Magnetic Stripe Cards (Cartões com tarja magnética) surgiram em meados de 1960 como uma nova geração de cartões e uma grande evolução em relação aos Embossed Cards. Com essa tecnologia as informações dos cartões passaram a ser lidas e armazenadas eletronicamente. Eliminou-se a necessidade de recibos em papéis, além do aumento significativo no quesito segurança, pela dificuldade de cópia (HALLIDAY, 2006). As tarjas magnéticas, assim como os Smart Cards obedecem a especificações. O padrão ISO/IEC 7811 (ISO, 2009b) especifica que: 1. A faixa um tenha 210 bits por polegada (bpi), e armazene 79 seis-bits, mais bit de paridade de caracteres apenas de leitura; 2. A faixa dois tenha 75 bpi, e armazene 40 quatro-bits, mais caracteres de bit de paridade; 3. A faixa três tenha 210 bpi, e armazene 107 quatro-bits, mais caracteres de bit de parida. Seu cartão de crédito normalmente só usa as faixas um e dois. A terceira é uma faixa de leitura/escrita (que inclui um PIN codificado, código de país, unidades monetárias, valor

22 12 autorizado), mas sua utilização não é padronizada entre os bancos. A figura 2-2 exibe as faixas em um cartão de tarja magnéticas. Figura 2-2 Composição da tarja magnética e especificações físicas. Fonte: RANKL; EFFING (2003 p.17) Smart Cards Visão geral Os Smart Cards são freqüentemente chamados cartões com microchip. As dimensões do cartão bem como suas características eletrônicas seguem a norma ISO7816 (ISO, 2009b). ISO 7816 é a norma que estabelece o padrão para a indústria de Smart Cards. Eles podem ser divididos em cartões de memória e cartões com microprocessador e também podem ser categorizados como cartões contact ou contact less no processo de leitura do cartão. A figura 2-3 mostra a composição dos tipos de cartões. Figura 2-3 Classificação de um Smart Card. Fonte: O autor (2009).

23 Cartões de memória Cartões de memória são estáticos. Sua lógica não pode ser reprogramada. Tampouco podem ser utilizados para situações diversas. Devido ao baixo custo de produção, eles são construídos para atenderem necessidades únicas e imutáveis. Ou seja, para novos negócios, novos cartões de memória devem ser construídos tornando os anteriores obsoletos. Esses cartões não possuem processador acoplado não é possível desenvolver soluções em software para atender constantes mudanças. Este tipo de Smart Card é muito utilizado por companhias telefônicas que os fornecem como cartão pré-pago a seus clientes. A vantagem dos cartões de memória está no baixo custo da tecnologia empregada. No entanto cartões de memória podem ser adulterados de forma relativamente simples. Por exemplo, cartões de telefone pré-pago possuem um mecanismo lógico que impede o incremento de seus créditos. Porém existem meios técnicos de burlar essa lógica e alterar o valor dos créditos. As operadoras aprenderam a lidar com essa técnica de fraude colocando validações também nos aparelhos de telefones onde os cartões de memória são inseridos Cartões com Microprocessador Cartões com microprocessadores oferecem um grande aumento de segurança e também eleva a capacidade funcional do cartão. Este tipo de cartão é análogo ao IBM-PC: além de seu microprocessador, possui memória dinâmica e volátil, memória para armazenamento de dados, dispositivos de I/O, sistema operacional e sistema de arquivos. Alguns tipos de cartões permitem alocar múltiplos software. O sistema operacional impede o acesso livre aos dados. Aplicações para este tipo de cartão podem usufruir de criptografia. A segurança ainda é incrementada pela existência de um firewall nestes cartões. Muitos dos atuais modelos dos cartões com microprocessador possuem recursos de criptografia incorporados as suas funcionalidades que são limitadas apenas por sua pouca capacidade de processamento e de suas memórias. Os cartões são amplamente utilizados para controle de acesso, aplicações bancárias, aplicações comerciais, telecomunicações e em outras aplicações sempre que a segurança dos dados e a privacidade são as principais preocupações.

24 Smart Cards Contact O cartão de contato deve ser inserido em uma leitora para fazer a comunicação com o mundo externo. A interface de comunicação do cartão é feita através de uma serial com oito pontos de contato como mostra a figura 2-4. Figura 2-4 Pontos de contatos do Smart Card. Fonte: O autor (2009). As dimensões e localizações dos contatos são descritos na ISO (ISO, 2009a). O contato Vcc fornece energia para o microchip. Este contato opera com 3 v ou 5 v, com um desvio de 10 por cento. O contato RST é utilizado para enviar um sinal de reinicialização do microprocessador chamado de reset direct. Um reset indirect ocorre no ato de retirar e inserir o cartão na leitora. Há cartões com processadores que não possuem clock interno. O ponto CLK fornece um sinal de clock externo a partir da qual o clock interno é derivado. O GND é usado como um ponto de referência de tensão e seu valor é considerado como zero. O ponto Vpp é opcional e só é utilizado nos cartões antigos. Quando utilizado fornece dois níveis de tensão. O menor nível de tensão é chamado de estado inativo, que deve ser mantido pelo CAD no processo de leitura da EEPROM. O maior nível de tensão (estado ativo) atua quando é necessário alterar a programação da memória EEPROM. O ponto I/O ponto é usado para transferir dados e comandos entre o Smart Card e o mundo externo, em modo half-duplex. Os pontos RFU são reservados para uso futuro.

25 Smart Cards Contactless Os contactless Smart Cards possuem internamente a mesma estrutura lógica de funcionamento de um Smart Card microprocessado ou de um Smart Card de memória. Fisicamente conta com uma interface, adicional em sua estrutura física, encarregada de prover a comunicação através de rádio freqüência (RF). Nos cartões sem fio tanto a energia como os dados são transferidos sem a necessidade de qualquer contato físico entre o cartão e a leitora (RANKL; EFFING, 2003). Os dois tipos de Smart Cards (memória e microprocessador) podem utilizar essa funcionalidade, mas com algumas particularidades. Smart Cards com microprocessador sem fio possuem um circuito mais complexo o qual demanda mais energia para seu funcionamento, sendo que a intensidade do sinal necessário para seu funcionamento tende a ser de maior intensidade do que os cartões de contato. Já os Smart Cards com memória, somente operam a uma distância da ordem de alguns metros, devido à menor complexidade do circuito e a baixa da intensidade do sinal necessária para sua operação. Entretanto aplicações que acessam o Smart Card a uma longa distância podem causar problemas, como o acesso indevido, que devem ser previstos e prevenidos. Smart Cards sem fio são particularmente empregados para aplicações nas quais existe a necessidade de identificação de forma rápida, segura e simples. Como exemplo controle de acesso, ticket de transporte público, ticket de companhias aéreas, identificação de bagagem, identificação de pessoas e outras aplicações. Com o avanço da tecnologia sem fio hoje é possível obter cartões e leitoras que usam esta tecnologia a um baixo custo similar aos cartões e leitoras que utilizam contatos elétricos. A figura 2-5 ilustra em diagrama de blocos como são constituídos os módulos de comunicação de um cartão e uma leitora com tecnologia RFID. Figura 2-5 Diagrama em blocos de um leitor RFID. Fonte: (REVISTA SABER).

26 ARQUITETURA DO SMART CARD Um Smart Card é formado por um cartão de plástico integrado com um microchip e um ou mais software. Existem padrões de construção para cartões inteligentes, onde normas definem desde suas medidas físicas como altura, largura e espessura até as especificações de hardware e metodologias para a construção do software. O hardware essencial do Smart Card é composto por uma EEPROM, ROM, RAM, CPU, dispositivos de I/O e atualmente memória flash. Cartões contactless possuem ainda uma antena e uma pequena bateria necessárias para comunicação RFID. Nos cartões contact é necessário que exista contato físico entre os periféricos de I/O da leitora e do cartão. A figura 2-6 apresenta um diagrama básico de um Smart Card sem fio. (2003, p.23). Figura 2-6 Diagrama de blocos básico Smart Card sem fio. Fonte: RANKL; EFFING ROM (Read-Only Memory) A ROM é usada para armazenamento de aplicações fixas. Na ROM é onde está o sistema operacional do Smart Card. Como o próprio nome indica, não é possível regravar nessa memória.

27 EEPROM (Electrically-Erasable Programmable Read-Only Memory) A EEPROM funciona de maneira semelhante a ROM. Ela mantém os dados persistentes mesmo quando essa memória está sem energia. A diferença da EEPROM para a ROM é que a memória EEPROM permite atualizar o seu conteúdo, inserindo ou removendo dados. Na EEPROM existem importantes parâmetros a serem ressaltados tais como: número de escrita, período de retenção de dados, acesso e tempo. O número de ciclos de escrita e de pelo menos vezes e pode conservar os dados por 10 anos. A leitura da EEPROM é tão rápida quanto a da RAM, mas a escrita é 1000 vezes mais lenta RAM (Randon Access Memory) A memória RAM é a memória de trabalho do usuário. Ela é usada para armazenar e alterar os dados temporariamente. Sua capacidade chega a 8 KB. A memória RAM é muito escassa no Smart Card porque sua célula de memória tende a ser de aproximadamente quatro vezes maior que a célula da EEPROM Flash Memory A memória flash tem ganhado espaço em diversos produtos que necessitam de persistência de dados. Seu custo em relação a RAM tem impulsionado sua adoção em produtos como módulos de armazenamento tais como pendrive, SD Card, e atualmente netbooks. Com o Smart Card não é diferente. A memória flash tem ganhado espaço nos cartões inteligentes. Atualmente, é possível encontrar cartões com capacidade de armazenamento de 1 MB. A figura 2-7 exibe um cartão de 1 MB.

28 18 Figura 2-7 Cartão fabricado pela Sharp com 1 MB de memória flash. Fonte: (USA SMART CARD, 2009). A memória flash é mais eficiente no espaço físico e no poder de escrita e leitura da EEPROM, pode ser lida por partes, mas somente pode ser atualizada como um todo. Assim a memória flash é normalmente usada para armazenar programas adicionais ou grandes blocos de dados que são atualizados conforme um todo CPU Atualmente, os novos CPU s são microcontroladores de 16-bit e 32-bit com um conjunto reduzido de instruções RISC. Há uma gama de fornecedores como Motorola com o 6805, Intel com 8051, ARM com SecurCore SC300. Alguns processadores de Smart Cards possuem até 24 MHZ. Alguns Smart Cards possuem também um co-processador (NPU). Os microship dos Smart Cards que são projetados para uso em aplicativos de segurança utilizam geralmente um co-processador. O co-processador é um circuito integrado especial para acelerar cálculos matemáticos, que são exigidos em operações de criptografia, tais como o algoritmo RSA. A inclusão de um co-processador geralmente afeta o custo do microchip. 2.4 COMUNICAÇÃO NO SMART CARD Um Smart Card é inserido em um CAD. Um CAD pode ser classificado em duas categorias: leitores e terminais. Existe uma ligeira diferença entre os leitores e os terminais. Os leitores geralmente usados para descrever uma unidade que faz interface com um PC para a maioria dos seus

29 19 requisitos de transformação. Leitores não são construídos para processar dados, porém são dotados com recursos de detecção e correção de erros impedindo assim que dados não compatíveis com o protocolo de transporte sejam transmitidos. Os terminais por outro lado integram um leitor de cartões como um dos seus componentes. Além de ter a funcionalidade de um leitor, um terminal tem a capacidade de processar os dados que foram trocados pela comunicação com um Smart Card. Como por exemplo, nos terminais de caixa eletrônico e nas transações de cartão de crédito Modelo de Comunicação A comunicação entre o cartão e o leitor é half-duplex, isto é, os dados podem ser enviados a partir do CAD para o cartão ou do cartão para o CAD somente num sentido não podendo ser ao mesmo tempo. Os computadores se comunicam através de um protocolo como o TCP/IP. Com Smart Card não é diferente, ele tem seu próprio protocolo chamado APDU (Application Protocol Data Unit). Na APDU a comunicação é feita por comando e resposta. No modelo mestre-escravo o cartão desempenha o papel de escravo para o host. Comando APDU s e respostas APDU s são trocados entre o cartão e computador (ou terminal) como mostrado na figura 2-8. O protocolo APDU está especificado na ISO , confira o Apêndice A para maiores informações. Figura 2-8 Modelo de Comunicação. Fonte: O autor (2009) Application Protocol Data Units APDU De maneira similar à troca de mensagens entre dois computadores em rede, através do protocolo TCP/IP, os Smart Cards conversam com computadores usando pacotes de dados específicos chamados de APDUs (aplication protocol data units). Um APDU contém duas

30 20 estruturas, um Comando APDU e outra para Resposta APDU. A tabela 1 mostra os campos do comando APDU. Tabela 1 Comando APDU. COMANDO APDU CABEÇALHO (OBRIGATÓRIO) CORPO (OPCIONAL) CLA INS P1 P2 Lc Data field Le Os campos de cabeçalho são de preenchimento obrigatório. Cada um dos quatro primeiros campos tem o tamanho fixo de 1 Byte. O campo CLA define a categoria do comando. O Byte do campo INS define o código de instrução. Os campos P1 e P2 fornecem qualificação adicional para a instrução. No corpo do comando APDU existem os campos Lc, Data field e Le. O campo Lc define o tamanho (em Bytes) do campo Data field. Já o campo Le informa ao Card o tamanho esperado (em Bytes) da resposta. O protocolo APDU funciona com o par comando/resposta. A resposta que o Smart Card envia ao host também segue um modelo. A tabela 2 mostra como é organizada uma resposta APDU. Tabela 2 Resposta APDU. RESPOSTA APDU CORPO (OPCIONAL) CORPO (OBRIGATÓRIO) Data field SW1 SW2 O campo Data Field contém o dado de resposta e seu tamanho é definido no comando APDU no campo Le. Este campo é opcional. Já os campos SW1 e SW2 são campos de preenchimento obrigatório. Eles contêm palavras de status que são enviadas ao host informando se a operação ocorreu bem Classe APDU A Classe APDU na API do Java Card prove uma poderosa e flexível interface no manuseio de APDU s cuja estrutura de comandos e respostas está em conformidade com a especificação da ISO A classe APDU também prove um meio orientado a objetos de manusear APDUs. As applets recebem e enviam APDUs pela invocação de métodos

31 21 definidos na classe APDU. Portanto, desenvolvedores de applets podem concentrar seus esforços no processamento do conteúdo de mensagens APDU em vez dos detalhes de como APDUs são construídos e transmitidos. A Tecnologia Java Card provê a classe javacard.framework.apdu, que define uma poderosa porém simples interface para ajudar applets a manusear APDU s facilmente. A figura 2-9 apresenta a estrutura de uma aplicação Java Card. Figura 2-9 Elementos de uma aplicação Java Card. Fonte: (ARIZA, 2005) Processamento das APDUs Sempre que é enviado um APDU ao cartão, o JCRE invoca o método process da applet selecionado. O método process deve ser implementado previamente antes de poder trabalhar com as applets, a applet tem que estar instalada no cartão. Todas as applets são extensões da classe Applet base. A instalação das applets é feita mediante o método install que deve ser implementado. Uma vez que a applet esta instalada, o JCRE invoca o método install. 2.5 SISTEMAS OPERACIONAIS Os sistemas operacionais nos Smart Cards suportam um conjunto de instruções para construir aplicações. A ISO padroniza um vasto escopo de instruções no formato de

32 22 APDUs. Um sistema operacional de Smart Card pode suportar todas ou algumas destas APDUs. A maioria dos sistemas operacionais de Smart Card tem um apoio no sistema de arquivos baseado na ISO , por exemplo, seleção de arquivo e arquivo de comandos de acesso. 2.6 SISTEMA SMART CARD Um sistema Smart Card é distribuído em duas partes: o sistema receptor no computador ligado a uma leitora ou em um terminal e o outro sistema dentro do cartão. A maior parte do software é do lado do receptor, o sistema reconhece o software especifico do Smart Card e processa a comunicação entre a aplicação e o cartão. Software receptor geralmente é escrito em linguagens de programação de alto nível, tais como Java e C++. O sistema do cartão normalmente é utilizado para gerenciar a memória, manipular os dispositivos de I/O na comunicação com o receptor, garantir a integridade dos dados e a sua segurança. Para garantir a padronização a indústria criou o OpenCard Framework (OPENCARD, 2009), uma plataforma aberta que oferece um ambiente integrado para o desenvolvimento de aplicações para Smart Cards, permitindo assim que componentes de software de diferentes fornecedores trabalhem de forma integrada. O Java Card oferece uma plataforma aberta na qual aplicações podem ser escritas em Java e podem ser executadas em qualquer cartão Smart Card que suporta o Java Card Runtime Environment.

33 23 3. JAVA CARD A tecnologia Java Card surgiu como uma solução para a indústria de Smart Card para o complexo e vagaroso processo de desenvolvimento de aplicações para Smart Card. Ao contrário do que se possa imaginar essa tecnologia não nasceu nos laboratórios de engenharia da Sun Microsystems. Em 1996, um grupo de engenheiros da Schlumberger s Product Center em Austim, Texas enxergaram na linguagem de programação Java a solução para aplicações seguras nos Smart Cards e decidiram portá-la para esses dispositivos (CHEN, 2000). Java também trazia todo o principal ambiente de desenvolvimento das aplicações desktop e web para a plataforma dos Smart Cards. Esse grupo propôs o primeiro draft para a API do Java Card. Em pouco tempo, empresas como Gemplus e Bull aderiram a Schlumberger s e fundou o Java Card Forum, um consórcio para identificar e resolver questões da tecnologia Java Card para a indústria, promovendo assim sua expansão e aceitação. A Java Card 1.0 consistia apenas das especificações da API. Isso chamou a atenção da Sun Microsystems que logo tornou o Java Card uma das plataformas Java. Em 1991, a Sun Microsystems anunciou a versão 2.0 da Java Card. Em 1997, foi lançada uma versão significativa: Java Card 2.1. Essa plataforma de Java Card consistia da Java Card API Specification 2.1, a Java Card Runtime Environment Specification 2.1 e Java Card Virtual Machine Specification. Desde então a tecnologia Java Card vem abraçando a indústria de Smart Card. Atualmente, a plataforma Java Card encontra-se na versão 3. A plataforma Java Card dividi-se em 3 tecnologias: Java Card Virtual Machine, Java Card Runtime Environment, e Java Card API. 3.1 JAVA CARD VIRTUAL MACHINE (JCVM) Define as características, serviços e comportamentos que uma aplicação Java Card deve suportar. Inclui o conjunto de instruções de um Java Card Virtual Machine e suporta apenas um subconjunto da linguagem Java, os formatos de arquivos usados para a instalação de applets e bibliotecas dentro dos cartões inteligentes e outros dispositivos que hospedam a tecnologia Java Card. A principal diferença entre a máquina virtual Java Card (JCVM) e a máquina virtual Java (JVM) é que a JCVM é implementada em duas partes distintas, como demonstradas na figura 3-1.

34 24 Figura 3-1 Java Card Virtual Machine. Fonte: (CHEN, 2001) A parte on-card da JCVM é o Interpretador que é executado dentro do Smart Card. Já a outra parte que compõe a JCVM é o Converter que é executado off-card. Juntas, essas partes implementam todas as funções da máquina virtual. O conversor carrega e pré processa os arquivos Java de classe gerando um arquivo CAP (Converted Applet). O arquivo CAP é então carregado em um Smart Card Java Card e é executado pelo interpretador. Além de criar um arquivo CAP, o conversor gera um arquivo de exportação que representa as APIs públicas do pacote a ser convertido. Correspondentemente, a máquina virtual Java Card suporta apenas os recursos que são exigidos por este subconjunto. Qualquer característica da linguagem não suportado usado em uma Applet é detectada pelo conversor. Portanto, para escrever uma aplicação funcional na plataforma Java Card, é necessário escrever a classe da applet que ficará no cartão e escrever a classe Java que estará fora do cartão. Existe um relacionamento de dependência entre a classe on-card e a classe off-card. Essa dependência é causada porque ambas as classes trocam array de bytes, ora representando um comando do protocolo APDU, ora representando uma resposta do protocolo APDU.

35 JAVA CARD RUNTIME ENVIRONMENT (JCRE) Define o comportamento necessário para o ambiente de execução em qualquer aplicação da tecnologia Java Card, que deve incluir as implementações da JCVM, as classes da API Java Card, a execução de serviços o gerenciamento de memória, gerenciamento de applet, e outras características em tempo de execução. 3.3 JAVA CARD API (APPLICATION PROGRAMMING INTERFACE) Especificação descreve o conjunto e a extensão de pacotes Java e as classes para a programação de aplicações dos cartões inteligentes. Essa API é um subconjunto da API de Java Standard Edition. Isto se deve ao fato de certos recursos exigem um poder de processamento do qual o hardware de um Java Card não dispõe. A tabela 3 fornece uma descrição detalhada dos recursos suportados e não suportados pela API do Java Card. Tabela 3 Características suportadas e não suportadas. Características Java Suportadas Tipo de dados primitivos pequenos: boolean, byte, short. Arrays One-dimensionais. Pacotes Java, classes, interfaces e exceções Característica de Orientação a Objetos: herança, métodos virtuais, sobrecarga, criação de objetos dinâmicos, escopo de acesso e regras obrigatórias. O int key palavra reservada 32-bit integer tipo de dado suportado opcional Características Java não Suportadas Tipo de dados primitivos grandes: long, double, float Caracteres e strings Arrays Multidimensionais Carregamento dinâmico de classe Gerenciamento de segurança Coletor de lixo e finalização Threads Serialização de Objetos Clonagem de Objetos 3.4 CARACTERÍSTICAS Apesar dos Smart Cards serem padronizados no tamanho, forma e protocolo de comunicação, o trabalho no interior difere amplamente de um fabricante para outro. Muitas ferramentas de desenvolvimento para Smart Card são feitas pelos fabricantes de Smart Cards usando uma linguagem assembly genérica e emuladora de hardware dedicados obtidos dos

36 26 fornecedores do microchip. Portanto, é praticamente impossível para terceiros desenvolver aplicações e vende-los aos emitentes de cartões. Desenvolver aplicações para Smart Card tem sido uma tarefa restrita a um grupo altamente qualificado e especializado com um profundo conhecimento do hardware e software do Smart Card. Java Card traz para o ambiente embarcado dos Smart Cards todas as vantagens da linguagem de programação Java. Java Card permite trabalhar com Orientação a Objetos permitindo assim criar componentes de software reutilizáveis, robustos e seguros. O processo de desenvolvimento passa a ser mais rápido uma vez que pode empregar metodologias, padrões de projeto, um design moderno e também conta com tratamento de exceções. Java Card traz de antemão um grande número de desenvolvedores. Por ser a linguagem Java amplamente difundida, um programador Java não necessita de uma curva de aprendizagem grande para começar a construir aplicações para Smart Card. Java Card oferece os seguintes benefícios: 1. Facilidade no desenvolvimento de aplicações - Existem inúmeras IDE s para a linguagem Java: Eclipse, Netbeans, JBuilder entre outros. Estes ambientes integrados são usados largamente por diversas organizações de desenvolvimento de software. 2. Segurança - Java embutiu recursos poderosos de segurança. Java não permite manipulações de ponteiro e dessa forma códigos maliciosos não comprometem um sistema feito em Java. Com Java Card não é diferente. Java Card dispõe da Applet Firewall que impede aplicações mal-intencionadas de danificarem o sistema. 3. Independência de Hardware - Um dos grandes sucessos de Java foi sua total independência de hardware. Uma aplicação Java Card pode ser instalada em qualquer Smart Card que contenha uma Java Card Virtual Machine e/ou Java Card Runtime Environment. 4. Capacidade para armazenar e gerenciar aplicações - Java Card pode armazenar múltiplas applets para as mais variadas finalidades. O firewall garante que essas applets não acessem umas as outras explicitamente. 5. Compatível com as normas existentes - A API Java Card é compatível com as normas internacionais de cartões inteligentes, tais como ISO7816 (ISO, 2009), ou EMV (EMV, 2009). E é ainda compatível com padrões específicos da indústria como Global Platform (GLOBAL PLATFORM, 2009) e ETSI (ETSI, 2009).

37 APPLET FIREWALL Uma applet freqüentemente armazena informações extremamente importantes tais como dinheiro eletrônico, impressões digitais, chaves criptográficas, e outros. A applet firewall limita uma applet para a sua própria área designada. Uma applet é impedida de acessar aos conteúdos ou métodos dos objetos possuídos pelas outras applets. A applet do firewall e os mecanismos de compartilhamento afeta a forma de escrita das applets. A applet do firewall fornece proteção contra as preocupações mais freqüentes de seguranças: erros de desenvolvedores e negligências que possa permitir que os dados importantes sejam copiados por outra applet e também fornece proteção contra a pirataria. Uma applet pode ser capaz de obter um objeto de referência a partir de um local acessível, mas se o objeto é propriedade de outro aplicativo em outro pacote, o firewall impede o acesso ao objeto. Assim, uma applet ou até mesmo uma aplicação do lado do host (Terminal ou Leitora) não pode afetar o funcionamento de outras applets ou do JCRE. Figura 3-2 Sistema de partições das applets na plataforma Java Card. Fonte: (CHEN, 2000). O funcionamento do firewall no Java Card está nas partições do sistema que são separadas em objetos chamados contexto. O firewall é a fronteira entre um ou mais desses objetos. Quando uma applet é criada o JCRE atribui-lhe um grupo. Todas as instâncias de uma applet compartilham o mesmo grupo de contexto. Acesso de objetos entre applets no

38 28 mesmo grupo é permitido. No entanto, o acesso a um objeto em um grupo diferente é negada pelo firewall. Além disso, o JCRE mantém seu próprio contexto. O contexto do JCRE é dedicado em um contexto de sistema que tem privilégios especiais, como o acesso do contexto da applet do JCRE para qualquer contexto em outra applet, mas o inverso é proibido pelo firewall. 3.6 TRANSAÇÕES ATÔMICAS Java Card trabalha com suporte um modelo transacional permitindo as applets efetuarem transações seguras. Neste modelo, a atomicidade é empregada. Ela garante que as transações entre o Smart Card e o host sejam total e completamente concluídas ou abortadas em caso de falha. No caso de uma atualização de um determinado valor, se o cartão for retirado da leitora durante a operação, a atual operação é abortada e o valor original é restaurado. Esse conceito de atomicidade é empregado para conteúdo persistente no cartão. Essa atomicidade não pode ser aplicada para arrays transientes. 3.7 APPLICATION IDENTIFIER (AID) Na plataforma Java Card ao contrário da plataforma Java cada applet instanciada é unicamente identifica por um application identifier. Packages em Java Card também possuem um AID uma vez que quando são carregados para dentro do cartão eles são linkados com outros pacotes através de seu AID. A ISO cuida da especificação do AID. Ela define o AID como um array de bytes que pode ser interpretado como duas partes distintas. A primeira parte contém os 5 primeiros bytes desse array é conhecido como resource identifier (RID). Já a segunda parte desse array é de tamanho variável e é conhecido como Proprietary Identifier Extension (PIX).Um PIX pode ter de 0 a 11 bytes de tamanho. Já o AID tem um total mínimo de 5 até um máximo de 16 bytes. A ISO controla a assinatura do RID para empresas. Cada empresa tem um RID único. Em Java Card um AID para pacotes é construído com a concatenação do RID da companhia e um PIX para o package. Um AID de applet é assinado pelo provedor da applet mais um PIX para a applet. O AID da applet não deve ser o mesmo do AID do pacote. O arquivo CAP contém a especificação de cada AID de pacote de applet.

39 TRABALHOS RELACIONADOS O TCC Smart Card Java Card de autoria de Álvaro Fernandes Lorenzoni apresenta um estudo da tecnologia dos Smart Card, abordando características relativas ao hardware e software. O autor fornece um histórico de evolução dos cartões, demonstra à composição da arquitetura do Smart Card, cita exemplos de sistemas operacionais de cartões inteligentes, no entanto, o trabalho recebe um maior enfoque quando se trata de desenvolvimento de aplicações em Smart Cards utilizando a tecnologia Java Card, mas nem por isso o autor deixa de mencionar outras plataformas de desenvolvimento como: Multos, Basic Card, Windows Smart Cards e Linux. O trabalho demonstra uma série de comparações entre Smart Cards de diferentes tecnologias existentes no mercado, também ressalta uma das maiores preocupações existente no mercado quando o assunto trata-se de Smart Cards, ou seja, segurança. O autor aborda de maneira simples e intuitiva três fatores chave para uma maior confiabilidade, evidenciando a união de três fatores: O que você tem? O que você sabe? O que você é? Onde respectivamente as respostas para as questões seriam: Smart Cards. PIN (Número de Identificação Pessoal) Biometria. (impressão digital, reconhecimento de íris, reconhecimento de face, ou seja, características físicas humanas). O autor afirma que a união de Smart Cards com informações pessoais dos indivíduos tanto físicas como memorizadas, atingem um alto grau de índice de confiabilidade. Além disso, o autor sugere o desenvolvimento de duas aplicações para um mesmo Smart Cards a primeira proposta é a criação de uma aplicação (wallet), em outras palavras, uma aplicação de dinheiro eletrônico, como por exemplo, red shop ou cartão de crédito e a segunda aplicação baseado na identificação e autenticação de alunos, ambas usando um alto grau de segurança através do emprego da tecnologia Java Card. O autor enaltece que o Smart Cards juntamente com a tecnologia Java formam uma poderosa combinação que vai proporcionar a abertura para novas aplicações das quais dentro

40 30 de alguns anos estarão fortemente evidenciados através da utilização em massa dessas tecnologias seguras e funcionais.

41 31 4. MODELAGEM Neste capítulo apresentamos a modelagem da aplicação Bilhete Metropolitano. Essa aplicação é uma wallet. Wallet é uma aplicação comum no universo do Smart Card o que torna o aprendizado de Java Card mais empolgante porque o desenvolvedor iniciante pode rapidamente criar um tipo de aplicação Java Card amplamente utilizada no mercado. 4.1 BILHETE METROPOLITANO Para exemplo de uma aplicação wallet, foi criada uma aplicação clone do sistema de Bilhete Único utilizado pelo departamento de transporte da cidade de São Paulo. A cidade de São Paulo dispõe de um sistema onde os cidadãos que utilizam o transporte público compram um Smart Card que interage nesse sistema. A aquisição do cartão é feito em postos credenciados. No ato da compra do cartão o usuário pode inserir créditos nele no próprio posto autorizado ou nos terminais de ônibus da cidade. Uma vez creditado o cartão o usuário pode utilizá-lo para efetuar o pagamento da passagem de ônibus. A aplicação desenvolvida pode inserir créditos, verificar saldo e debitar o valor de uma passagem de categoria normal. Esta aplicação é referida a partir daqui como Bilhete Metropolitano. Este capítulo apresenta a modelagem do Bilhete Metropolitano. Os requisitos desse sistema foram modelados com Casos de Uso e os mesmos foram validados através do Diagrama de Casos de Uso e da Descrição de Casos de Uso. Por se tratar de um Sistema com componentes de software embarcado o sistema possui poucas classes principalmente por ser o Smart Card uma plataforma computacional de baixo poder e de nicho de mercado específico. O componente de software on-card do Bilhete Metropolitano é constituído de uma única applet o que torna a modelagem mais simples. As próximas seções apresentam essa modelagem Casos de uso Foram levantados três requisitos funcionais todos de alta prioridade para a modelagem do Bilhete Metropolitano. A figura 4-1 apresenta os casos de usos.

42 32 Debitar Passagem Creditar Verificar Saldo Figura 4-1 Casos de Uso do sistema. Fonte: O autor (2009) Diagrama de Caso de Uso O Diagrama de Caso de Uso exibe as interações entre os casos de uso e os atores do sistema. Esse diagrama pode ser visto na figura 4-2. Figura 4-2 Diagrama de Caso de Uso do Bilhete Metropolitano. Fonte: O autor (2009).

43 Descrição de Caso de Uso Esta seção descreve com mais detalhes os Casos de Uso levantados na seção informando desde sua descrição até seu fluxo de execução. Tabela 4 Creditar. Use Case Descrição Atores Pré-condições Pós-condições Fluxo Principal Fluxo Alternativo Creditar Este Use Case é responsável pela ação de transferir credito ao cartão. Passageiro, Operador Administrativo Aplicação do cartão inicializada Saldo incrementado e atualizado. 1. O passageiro insere o cartão na leitora. 2. Efetua o pagamento. 3. Operador Administrativo autoriza a inserção do crédito. Tabela 5 Verificar Saldo. Use Case Descrição Atores Pré-condições Pós-condições Fluxo Principal Fluxo Alternativo Verificar Saldo Este UC é responsável por consultar o saldo disponível. Passageiro Cartão habilitado. Não aplicável 1. Se cartão não inserido na leitora a. Passageiro insere o cartão na leitora. 2. Leitora exibe o saldo.

44 34 Tabela 6 Debitar Passagem Use Case Descrição Atores Pré-condições Pós-condições Fluxo Principal Fluxo Alternativo Debitar Passagem Este UC débito no valor de uma passagem.. Passageiro Saldo maior ou igual ao valor da passagem.. Saldo decrementado e autorização para utilização de mais 4 passagens gratuitas durante 4 horas. 1. Passageiro insere cartão na leitora. 2. <<Include UC Verificar Saldo >> 3. Catraca liberada. autor (2009). Figura 4-3 Diagrama de Caso de Uso Bilhete de Transporte Metropolitano. Fonte: O Diagrama de Classes A figura 4-4 apresenta o Diagrama de Classes do sistema. Apenas três classes são necessárias para criar uma aplicação de carteira para o sistema de pagamento de passagem para transporte público. Figura 4-4 Diagrama de Classe do Bilhete Metropolitano. Fonte: O autor (2009).

45 Diagrama de Sequência O diagrama de sequencia da figura 4-5 aprsenta a interação do operador e usário com os componentes do sistema. Figura 4-5 Diagrama de Sequência do Bilhete Metropolitano. Fonte: O autor (2009).

46 36 5. DESENVOLVIMENTO A aplicação desenvolvida neste trabalho foi uma wallet (carteira eletrônica). Wallet é uma solução de ponta que permite administrar contas pré-pagas, registrar os débitos gerados pelo uso de diferentes serviços e recarregar as contas através de diferentes canais: cartões prépagos, cartões de crédito, transferências bancárias, entre outros (ATS, 2009). Desenvolver aplicações para Smart Card significa trabalhar com aplicações distribuídas em ambientes heterogêneos. Um dos lados desse ambiente é sem dúvida o próprio Smart Card e em particular o Javacard. No Javacard são instalados arquivos CAP que são gerados a partir das applets. O segundo lado do desenvolvimento são as aplicações host. Essas aplicações podem estar em ambiente de hardware distinto, ou seja, em um PowerPC, x86 entre outros, bem como em sistemas operacionais distintos; Windows, Unix e Linux. A criação de uma applet exige criar uma classe que estenda a classe applet do pacote javacard.framework.applet. A JCRE por padrão invoca os métodos install, select, process ou deselect. A tabela 7 exibe os métodos necessários para implementar uma applet. Tabela 7 Métodos na classe javacard.framework.applet public static void install(byte[] barray, short boffset, byte blength) A JCRE chama este método para criar uma instância da applet. protected final void register() Este método é usado pela applet para registrar a instância da applet com a JCRE e assinar o valor padrão do AID no arquivo CAP da applet instanciada. protected final void register(byte[] barray, short boffset, byte blength) Este método é usado pela applet para registrar a instância da applet com a JCRE e assinar o do AID especificado no array barray public boolean select() A JCRE chama este método para informar a applet que ela foi selecionada. public abstract void process(apdu apdu) A JCRE chama este método para instruir a applet para processar uma entrada de comando APDU. public void deselect()

47 37 A JCRE chama este método para informar a applet atualmente selecionada que outra (ou a mesma) applet será selecionada. A applet Bilhete Metropolitano implementou a maior parte desses métodos. Como o sistema dispõe de apenas uma applet no cartão não foi preciso implementar o método deselect. 5.1 AMBIENTE DE DESENVOLVIMENTO Para desenvolver essa aplicação utilizamos o ambiente IDE Eclipse. Além do Eclipse também utilizamos um plugin comumente utilizado no desenvolvimento de sistemas Java Card chamado JCOP. Este plugin agrega velocidade, praticidade e organização no desenvolvimento das applets efetuando automaticamente o deployment das applets em arquivos CAP (Converted Applet) bem como outros demais arquivos necessários para a construção do arquivo CAP. O JCOP dispensa a árdua tarefa de utilizar as ferramentas do JCDK por meio de linha de comando. As operações de instalar, atualizar e/ou apagar applets e packages no cartão podem ser feitas com simples cliques. Esse plugin também oferece um shell permitindo utilizar seus comandos em um prompt. JCOP conecta-se diretamente com cartões de desenvolvimento através de uma leitora transferindo applets. Caso não haja um cartão físico o JCOP dispõe de um emulador de Java Card. Consulte o Apêndice C sobre a configuração do Eclipse e JCOP. Após a instalação e configuração do Eclipse e do JCOP o passo seguinte foi organizar a construção da aplicação Bilhete Metropolitano. Essa aplicação foi construída com três classes. Duas dessas classes formam um subsistema distribuído (CHEN, 2000): uma classe dentro do Smart Card e a outra em um PC. A figura 5-1 exemplifica essa idéia.

48 38 autor (2009). Figura 5-1 Aplicação Bilhete Metropolitano distribuída entre o card e o host. Fonte: O Cada classe está contida em projetos distintos. A figura 5-2 exibe a organização dos projetos no Eclipse no painel Package Explorer e no painel JCOP Explorer sendo que este último apresenta somente projetos com applets. O terceiro projeto comporta a classe BilheteHostSwingMain. Esta classe faz um input de dados de modo mais elegante e prático através de seus componentes Swing. Essa mesma classe agrega a classe BilheteHost e utilizando os métodos desta, obtém comunicação com o Java Card. Figura 5-2 Organização dos projetos. Fonte: O autor (2009).

49 Projeto da classe BilheteOnCard BilheteOnCard é a applet instalada no cartão. Seu objetivo é pegar comandos externos ao cartão e processá-los. Essa applet é uma aplicação de carteira, portanto suas operações se resumem há: inserir crédito, consultar sado e debitar. O projeto da applet foi criado usando o assistente do próprio JCOP. No menu File- >New->Java Card Project encontra-se uma maneira fácil e prática para iniciar um projeto. Após definir o nome do projeto bastou avançar para os próximos passos utilizando as opções já recomendadas pelo JCOP. A criação de um package é extremamente importante, pois este pacote também faz parte do arquivo CAP. Tanto o package quanto a applet devem ter um AID que é usado pela JCRE para selecionar a applet correta. Um AID de package é definido acessando as propriedades do pacote em questão. Na propriedade Java Card Settings há o campo Package AID. Uma forma mais eficiente e rápida de definir um AID é escrevê-lo como uma String. Para isso é necessário que o primeiro caractere nesse campo seja o pipe. Para a applet o mesmo processo de definição de AID foi seguido. A figura 5-3 exibe um exemplo. Figura 5-3 Definindo um AID para o pacote da Applet. Fonte: O Autor (2009).