O GLOBAL PLATFORM

O Global Platform é uma das especificações mais importantes de todo processo de desenvolvimento e utilização Java Card, para aqueles que almejam ser especialistas no desenvolvimento de aplicativos Java Card comerciais é primordial o seu conhecimento.

Curiosamente é uma das especificações menos divulgadas e documentadas até em livros do gênero. 

A especificação é extensa, complexa e meio pesada de se ler e compreender, e posso dizer sem dúvidas de longe é uma das partes mais intimidadoras de todo processo de desenvolvimento. 

Porém não se preocupe com um pouco de insistência essa barreira será vencida.

História.

O Mercado Francês é um dos pioneiros na implantação de cartões com chip para operações de débito e crédito, essa ação diminuiu em 98% a quantidade de fraudes com cartões.

Em 1993 a Europay, MasterCard e Visa, grandes operadoras de cartões, criaram em conjunto um padrão conhecido como EMV.

O padrão EMV define várias regras de operações com cartões com chip, como características físicas e elétricas, estrutura de segurança, interoperabilidade dos cartões nos terminais a nível global e regras de interação entre cartão e terminal baseadas no padrão ISO 7816.

O EMV define quatro regras básicas nas aplicações:

• Autenticação off-line, ou seja o terminal precisa se autenticar no cartão sem estar conectado a meios externos.
• Gestão de Riscos, o cartão grava todas as transações e dispara um alarme caso certas condições de risco ocorram.
• Autenticação por PIN (Personal Identification Number) off-line, o PIN nada mais é que a senha numérica do cartão, essa regra define que esse PIN deve ser armazenada de maneira sigilosa e o mesmo deve ser "match on card"(autenticada dentro do cartão) sem o terminal estar conectado a meios externos.
• Autenticação on-line, de modo exporádico o cartão pode ser verificado junto a uma base de dados on-line.

Porém o padrão EMV deixa em aberto para implementação diversos parâmetros de segurança, o que obviamente levou cada operadora desenvolver seus próprios sistemas, a Visa com o VSDC (Visa Smart Debit Card), a Master Card com o M/Chip, JCB com o J/Chip.

A Visa por sua vez desenvolveu um dos sistemas mais notáveis e seguros chamado de Visa Open Platform que especificam diversas regras como autenticação mútua, instalador de applets, gerenciamento do ciclo de vida do cartão, etc.

Em 1999 é fundada a organização Global Platform, trata-se de uma organização sem fins lucrativos, concentrada na padronização da infraestrura de desenvolvimento, distribuição e gerenciamento de smart cards. Essa organização se divide em 3 comites : the Card Committe, Device Committe e System Committe.

Para nós desenvolvedores apenas o Card Committe importa, pois as especificações dela está presente em mais de 90% dos cartões no mercado. Muito provavelmente no seu cartão de Débito e Crédito com chip na sua carteira, seu SIM Card no Celular, seu Cartão com Certificado Digital, etc.

Assim como a especificação Java Card o Global Platform possui diversas versões e cabe ao desenvolvedor utilizar a correta pois pode variar de versão de Chip para Chip.

A mais comum é a Global Platform 2.1.1.

Global Platform.

Arquitetura Global Platform

A Figura acima demonstra a arquitetura Global Platform, que tem como premissa o Esquema Dinâmico de Multi-aplicações para Cartões. O Global Platform é a evolução natural do Visa Open Platform e foi adotada pela maioria dos fabricantes de Chip para Smart Cards.

Global Platform é neutro, ou seja independe do ambiente que está executando, no caso do Java Card ele se encontra na camada do JCRE (Java Card Runtime Environment).

Card Manager.

O Card Manager é Motor do GP (Global Platform) e todos os cartões que implementam a especificação GP tem um, o card manager implementa o Security Domain, que tem a função básica de gerenciar a autenticação entre Host e Cartão através de uma conexão segura ou mutual authentication, o ciclo de vida do cartão e aplicativos, carga/instalação/exclusão de aplicativos (Applets no caso do JC), gerenciamento de chaves do algoritmo criptografico usado para operações em ambiente seguro (DES/TripleDES/AES).

O Card Manager pode ser acessado utilizando-se o comando select (ISO 7816-4) mais o AID (Application Identifier), gravem bem esse conceito pois será muito utilizado lá na frente.

AID - Application Identifier.

Todos os Aplicativos para Smart Card tem um, seus Applets terão, o Card Manager do seu cartão de Crédito/Débito com Chip, seu SIM Card GSM no Celular, etc.

Basicamente ele é utilizado para se selecionar a aplicação dentro do cartão análogamente podemos comparar o AID com o nome de um Arquivo no HD do seu PC.

Ele segue os Padrões ISO 7816 e tem o seguinte formato [RID + PIX].

RID (Registered Provider Identifier), consiste de obrigatoriamente 5 bytes e identifica o fabricante/desenvolvedor da aplicação e é publicada por uma autoridade ISO 7816-5.

PIX (Proprietary Application Identifier Extension), consiste no identificador de Aplicativo e é definido pelo fabricante/desenvolvedor do aplicativo.

Por exemplo o AID do Card Manager do cartão Visa Electron  é [A0 00 00 00 03 20 10] onde RID = [A0 00 00 00 03] PIX = [20 10].

Life Cicle Models.
O Modelo do Ciclo de Vida de um cartão consiste em :

• OP_READY
• INITIALIZED
• SECURED
• CARD_LOCKED
• TERMINATED 

OP_READY e INITIALIZED é utilizado na fase de pré-personalização do cartão.

SECURED, CARD_LOCKED, TERMINATED, utilizado ao longo da vida do cartão.

O Ciclo de Vida, por exemplo como sendo uma fabricante do cartão você é responsável pela personalização do cartão que definem centenas de configurações do cartão como Protocolo de Comunicação T=0 ou T=1, configuração da Velocidade de Comunicação se é ou não negociavel, Cold ATR e Warm ATR, diversas configurações sobre como deve se comportar o GP, como deve se comportar o JCRE, etc. 

Após todo o processo o cartão é colocado no modo OP_READY nesse modo diversas configurações são desativadas. Poucas pessoas conhecem esse procedimento. ( Sou um dos poucos privilegiados. =D ).

Uma vez em OP_READY o cartão é vendido para os integradores de cartões, que por sua vez configuram a chave do criptografador utilizado no Mutual Authentication, instalam suas aplicações com configurações em modo padrão e por fim colocam o cartão em modo INITIALIZED.

Esse cartão agora é passado por exemplo para um banco que por sua vez pode iniciar os dados contidos na aplicação com os dados do cliente, ou mesmo atualiza-la com uma versão mais nova de aplicativo e por fim o cartão é colocado em modo SECURED.

Uma vez em modo SECURED o cartão ainda pode ter seus aplicativos atualizados e seu Card Manager acessado, porém indica que já foi totalmente personalizado e que pode ser entregue ao cliente.

O Cliente tem seu cartão roubado e avisa a operadora, a operadora adiciona esse cartão na black list.

Primeira hipótese o ladrão tenta passar esse cartão numa conhecida lojas de convêniencia, o cartão é passado para CARD_LOCKED pelo terminal que detecta a infração, todos os aplicativos do cartão são travados sobrando apenas o Card Manager e a resposta ATR.

Segunda hipótese o ladrão tenta violar o cartão utilizando um programa malicioso, após algumas tentativas o cartão detecta a tentativa de fraude, nesse momento dados são destruídos e o cartão passa para o modo TERMINATED, nesse ponto todas funcionalidades são bloqueadas, todos os APDU's são direcionados para o Card Manager porém agora o Security Domain apenas responderá ao comando GET DATA.

Esse foi um exemplo do ciclo de vida de um cartão, todas as passagens de estado são irreverssiveis, por exemplo quando se passa de OP_READY para INITIALIZED não se pode reverter para o modo OP_READY e assim sucessivamente.

O Modelo do ciclo de vida de um aplicativo consiste em :

• INSTALLED
• SELECTABLE
• LOCKED

Após a carga da aplicação no cartão ele precisa ser instalado, uma vez instalado o aplicativo entra para a lista de Aplicações disponíveis no cartão em modo INSTALLED, porém ainda não é selecionável, ou seja acessível pelo comando select da ISO 7816-4.

Uma vez instalado o Aplicativo pode ser passado para o modo SELECTABLE, no caso de um applet Java Card nesse momento o JCRE chama o método que deve ser ser sobreescrito na sua aplicação Java Card "public static void install (byte bArray[], short bOffset, byte bLength)", nesse método todos os recursos devem ser iniciados e o Applet Instanciado, feito isso o aplicativo estará pronto para uso e pode ser selecionado pelo comando select.

O Aplicativo pode ser passado para LOCKED, com isso ele não pode mais ser acessado, porém esse modo é reversível através do Card Manager.

Comandos Global Platform.

A Globlal Platform especifica um pequeno grupo de comandos APDU's seguindo a norma ISO 7816-4, são elas :

DELETE.

Esse comando é utilizado para exclusão de objetos executáveis do cartão, Applets no caso do Java Card através do seu AID.

GET DATA.

Esse comando retorna um objeto de dados, que dependendo do parametro passado pode variar entre o Número de Identificação do Fabricante, Identificador do Cartão, detalhes pertinentes a Chave do motor criptografico para operações em ambientes seguros, etc.

GET STATUS.

Esse comando retorna um objeto de dados, que dependendo do parametro passado pode variar entre Security Domain, Aplicativos Executaveis, Módulos Executáveis e Life Cicles dos Aplicativos e do Card Manager.

INSTALL.

Esse comando é responsável por realizar vários passos requeridos para tornar uma aplicação instalada e selecionavel, ou seja torna a Aplicação INSTALLED, SELECTABLE, etc.

LOAD.

Esse comando é responsável pela carga de um arquivo para o cartão, caso o pacote LOAD ultrapasse 256 bytes, ele deve ser dividido e enviado sequencialmente em diversos pacotes LOAD's, no caso do Java Card é esse comando que faz a carga dos Applets no cartão.

MANAGE CHANNEL.

Esse comando gerencia diversos canais lógicos abertos no cartão. O canal lógico de número Zero nunca pode ser fechado.

PUT KEY.

Esse comando altera uma das chaves do motor criptografico utilizado para proteção do canal de comunicação seguro e dados internos.

SELECT.

Esse comando é exatamente o mesmo definido pela norma ISO 7816-4.

SET STATUS.

Esse comando altera o Life Cicle do cartão do OP_READY para INITIALIZED, do INITIALIZED para SECURED e assim sucessivamente.

STORE DATA.

Esse comando é responsável pela carga de dados para uma determinada Aplicação ou para o Security Domain, assim como no caso do comando LOAD, se o pacote STORE DATA ultrapassar 256 bytes, ele deve ser dividido e enviado sequencialmente. 

O SCP ou Secure Channel Protocol 1 / 2.

Sem dúvidas nenhuma é a parte mais desafiadora do Global Platform, essa parte é conhecida também como Mutual Authentication, ela é responsável por autenticar um Host no cartão.

O processo utiliza derivação de uma chave TripleDES(GP2.1.1) ou AES(GP2.2), essa derivação mais um numero gerado aleatoriamente pelo cartão e pelo host formam dois criptogramas que ao serem autenticados definem a chave do criptografador a ser utilizado durante toda comunicação entre Host e Cartão.
Não entrarei em muitos detalhes sobre esse tópico pois tornará o artigo mais gigantesco do que já está, em Tutoriais Futuros espero demonstrar o uso desse processo de autenticação utilizando o Visa Open Platform API.

Fluxo do Mutual Autentication (Global Platform 2.1.1)

Seguindo o Fluxo da figura acima, inicialmente selecionamos o Card Manager ou Security Domain do Cartão usando o comando [select + AID], em resposta o cartão deve enviar um pacote de dados que fornece informações sobre o cartão no formato DER (Distinguished Encodin Rules) que é definida pela ASN.1 (Abstract Syntax Notation One)(link).

Dependendo esse Pacote pode conter diversas informações sobre como está configurarado o Secure Channel Protocol e o Security Domain.

INITIALIZE UPDATE.

É o comando APDU utilizado para se iniciar a autenticação mutua entre host e cartão.

EXTERNAL AUTHENTICATE.

O Cartão envia um pacote de dados em resposta ao INITIALIZE UPDATE, com posse desses dados a Chave secreta é derivada e uma série de calculos criptograficos são realizados, como resultado disso ao final termos a chave de Sessão e uma espécie de assinatura digital garantindo que a chave que está no cartão é a mesma que o Host possui, com isso um pacote de comando chamado EXTERNAL AUTHENTICATE é criado e enviado para o cartão que por sua vez executará uma série de cálculos e validará à autenticação.

Somente após esses complexos procedimentos é possível utilizar os diversos comandos definidos pela GP como instalação/exclusão de um Applet, PUT KEY, etc.

O GPShell.

O GPShell é um aplicativo de linha de comando que utiliza uma API Open Source que pode ser usado nas sua aplicações para auxilia-lo com esses detalhes do Global Platform.

No futuro quando estiver postando Tutoriais que utilizam Java Cards físicos ensinarei como usar essa ferramenta para carga/instalação/exclusão dos Applets no cartão.