YETKİNİK BEKLENTİSİNİN BİLGİLENDİRİCİ KAYNAKLAR

Nesta sec¸˜ao, abordamos os aspectos espec´ıficos da traduc¸˜ao para a implementac¸˜ao Java

Carddos servic¸os oferecidos pelo cart˜ao com o modo de comunicac¸˜ao mais comum, que con- vencionamos denominar nesta dissertac¸˜ao de applet APDU (cap´ıtulo 2). Como vimos, este tipo de applet trata, em um mesmo m´odulo (a classe applet), tanto dos aspectos de controle de execuc¸˜ao e comunicac¸˜ao, quanto da l´ogica de neg´ocio da aplicac¸˜ao cart˜ao. Por tratar explici- tamente a comunicac¸˜ao por meio do protocolo APDU e por n˜ao depender necessariamente de outras classes externas, o applet APDU tende a ser mais eficiente do que o applet RMI.

M´etodo process

O m´etodo process, como apresentado na sec¸˜ao 2.5, ´e respons´avel pela decodificac¸˜ao do campo de instruc¸˜ao (INS) do comando APDU e pela chamada dos servic¸os correspondentes oferecidos pelo cart˜ao. A decodificac¸˜ao ´e feita baseada no conjunto OPNAMES e seus valo- res definidos na m´aquina <specification name>Conversions, que d´a origem a uma classe de mesmo nome (OPNAMES), como apresentado na sec¸˜ao 4.1.3.

public void process(APDU apdu) throws ISOException { byte buffer = apdu.getBuffer();

...

switch (buffer[ISO7816.OFFSET_INS]) {

case OPNAMES.addcredit: addCredit(apdu); break; case OPNAMES.debit: debit(apdu); break; case OPNAMES.getBalance: getBalance(apdu); break;

default: ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED); }

Gerac¸˜ao dos m´etodos da classe applet

Os m´etodos que encapsulam a funcionalidade do applet s˜ao gerados a partir das operac¸˜oes do m´odulo de implementac¸˜ao B. Como vimos no cap´ıtulo 2, os m´etodos do applet Java Card

APDUtˆem todos o tipo de retorno void e recebem ou enviam informac¸˜oes por meio do protocolo

APDU. Dessa forma, o m´etodo a ser gerado n˜ao ´e idˆentico `a operac¸˜ao que serve como modelo para a sua criac¸˜ao, sendo necess´arias algumas modificac¸˜oes na assinatura e na implementac¸˜ao interna obtidas do modelo para que o m´etodo seja corretamente gerado na sua forma Java Card

APDU. Observe-se que essas modificac¸˜oes alteram a estrutura do m´etodo com relac¸˜ao `a sua operac¸˜ao modelo, mas n˜ao alteraram a sua funcionalidade.

Uma outra observac¸˜ao tamb´em deve ser feita quanto `a recepc¸˜ao do objeto APDU em cada m´etodo. O objeto APDU pode ser visto como um ponto de entrada tempor´ario para o JCRE que pode ser acessado por qualquer applet no cart˜ao. Al´em disso, o JCRE trata o buffer APDU como um array global que pode ser utilizado livremente pelos applets no cart˜ao. Dessa forma, tanto a referˆencia para o objeto APDU quanto o buffer s´o podem ser referenciados em escopo local, ou seja, em um parˆametro ou em uma vari´avel declarada dentro de um m´etodo. Optou-se aqui por fornecer a referˆencia `a vari´avel APDU como parˆametro em cada m´etodo. Poder´ıamos ter optado por fornecer apenas o buffer APDU no parˆametro. No entanto, isto impossibilitaria acesso aos outros servic¸os da classe APDU no corpo do m´etodo gerado.

A seguir, apresentamos as abordagem adotadas para a recepc¸˜ao de parˆametros e para o envio de dados em um m´etodo Java Card APDU.

Recepc¸˜ao de parˆametros Apesar da mudanc¸a na assinatura dos m´etodos que ser˜ao gerados com base nas operac¸˜oes da implementac¸˜ao B, as referˆencias aos parˆametros de cada operac¸˜ao ´e mantida. Dessa forma, ´e poss´ıvel declarar cada parˆametro no corpo da operac¸˜ao e inicializ´a-lo atrav´es do buffer APDU que ser´a recebido. A abordagem para a recepc¸˜ao do valor do parˆametro por meio do buffer APDU depende da quantidade e do tipo dos parˆametros recebidos.

Quando h´a at´e dois parˆametros do tipo byte, estes s˜ao recebidos nos campos P1 e P2 do

buffer, como pode-se ver pelo exemplo a seguir.

test (p1, p2) b= public void test (APDU apdu) { PRE byte[] buffer = apdu.getBuffer();

p1 ∈ BYTE ∧

p2 ∈ BYTE byte p1 = (byte) buffer[ISO7816.OFFSET_P1]; THEN byte p2 = (byte) buffer[ISO7816.OFFSET_P2];

... ...

END }

Para o caso de haver at´e trˆes parˆametros do tipo byte ou dois byte e um short, os dois primeiros s˜ao recebidos em P1 e P2, e o terceiro no campo DATA.

test (p1, p2, p3) b= public void test (APDU apdu) { PRE byte[] buffer = apdu.getBuffer();

p1 ∈ BYTE ∧ byte p1 = (byte) buffer[ISO7816.OFFSET_P1] p2 ∈ BYTE ∧ byte p2 = (byte) buffer[ISO7816.OFFSET_P2] P3 ∈ SHORT byte bytesRead = (byte)

THEN apdu.setIncomingAndReceive();

... short p3 = (short) buffer[ISO7816.OFFSET_CDATA]

END }

Quando h´a mais de um dado para ser recebido no campo data, como no caso de haver dois parˆametros short ou no caso de um dos parˆametros ser um array, vem sendo desenvolvido um algoritmo que percorre o campo data do buffer APDU e recupera o valor de cada parˆametro. At´e o presente momento, este algoritmo ainda encontra-se em desenvolvimento.

Envio de dados para o cliente O envio de dados para a aplicac¸˜ao cliente tamb´em necessita de um tratamento diferenciado, de acordo com o tipo e a quantidade de parˆametros a serem enviados na resposta APDU.

Como vimos anteriormente, em B, pode-se retornar mais de um resultado em uma operac¸˜ao. No entanto, em Java Card, na vers˜ao APDU, os tipos de retorno das func¸˜oes s˜ao todos void. Dessa forma, na traduc¸˜ao de B para Java, o m´etodo correspondente `a operac¸˜ao tem sua as- sinatura modificada para void, mas as vari´aveis de retorno presentes em seu modelo B s˜ao declaradas e inicializadas com os seus valores de retorno dentro do corpo do m´etodo gerado. De posse desses valores, ´e poss´ıvel envi´a-los ao cliente no estilo Java Card APDU, copiando-os para o buffer APDU e fazendo-se as chamadas aos m´etodos setOutgoing, setOutgoingLength e

sendBytes. Resalte-se que n˜ao h´a restric¸˜ao quanto ao n´umero de parˆametros a serem enviados, deve-se apenas ter o cuidado de especificar, em setOutgoingLength, a quantidade correta de

bytesque ser˜ao retornados na resposta.

Abaixo vemos o exemplo do envio de duas vari´aveis, uma do tipo short (var1) e outra do tipo byte (var2). Observe-se que, na operac¸˜ao B, a vari´avel de retorno res recebe o valor de var1 e a vari´avel res2 o valor de var2. Sendo assim, no m´etodo correspondente, elas s˜ao declaradas

com sendo do tipo das vari´aveis cujo valor recebem e, em seguida, s˜ao inicializadas com estas mesmas vari´aveis, assim como em seu modelo B. Posteriormente, s˜ao inseridas as informac¸˜oes necess´arias para o envio, como o n´umero de bytes que ser˜ao enviados em setOutgoingLength; ´e feita a c´opia das vari´aveis para o buffer de forma seq¨uencial e, por fim, elas s˜ao enviadas por meio da chamada ao m´etodo sendBytes. At´e o momento, foi tratado apenas o envio dos tipos

bytee short, ficando os arrays e tipos inteiros maiores para trabalhos futuros.

res, res2 <-- op b= public void op (APDU apdu) {

BEGIN short res = 0;

res := var1; byte res2 = 0; res2 := var2 res = var1;

END res2 = var2;

byte[] buffer = apdu.getBuffer(); short le = apdu.setOutgoing();

apdu.setOutgoingLength(3);

setShort(buffer, (short) 0, (short) res); buffer[2] = (byte) res2;

apdu.sendBytes((short) 0, (short) 3); }