Hvordan skrive en Java-kort-applet: En utviklerveiledning

Denne artikkelen veileder deg gjennom prosessen med å lage en enkel elektronisk lommebok-applet og gir veiledning for å bygge en applet og konstruere koden. Hvis du trenger en oppdatering av det grunnleggende om Java Card-teknologi, kan du se i mars 1998 Java Developer kolonne, "Forstå Java Card 2.0", som gir en oversikt over smartkort og beskriver systemarkitekturen, API-ene og kjøretidsmiljøet til Java Card-teknologien. For konsistens bruker denne artikkelen samme lommebok-appleteksempel som ble brukt i mars 1998-kolonnen. Imidlertid har lommebokappleten vi bruker i denne artikkelen blitt oppdatert for å gjenspeile endringer i API-ene i Java Card 2.1. I tillegg, mens den forrige artikkelen fungerte som en generell introduksjon til Java Card-teknologien, fokuserer denne artikkelen på å skrive applets for Java Card 2.1.

Arkitekt appleten

Som med all programvareutvikling, bør du først gå gjennom en før du setter deg ned og skriver en Java Card-applet designfase. I denne fasen definerer du arkitekturen til appleten.

Fire trinn omfatter applet-designfasen:

1. Spesifiser funksjonene til appleten
2. Be om og tildel hjelpemidler til både appleten og pakken som inneholder appletklassen
3. Design klassestrukturen til appletprogrammene
4. Definer grensesnittet mellom appleten og terminalapplikasjonen

I de neste avsnittene bruker vi eksemplet på en lommebokapplet for å se detaljert på hvert av trinnene i appletdesignprosessen.

Spesifisere funksjonene til appleten

Eksempel på lommebok-applet vil lagre elektroniske penger og støtte kreditt-, debet- og sjekkbalansefunksjoner.

For å forhindre uautorisert bruk av kortet inneholder det en sikkerhetsalgoritme. Denne algoritmen krever at brukeren oppgir en PIN-kode, en streng på maksimalt åtte sifre. Kortbrukeren skriver PIN-koden sin på et tastatur som er koblet til CAD-en. Sikkerhetsalgoritmen får kortet til å låse seg etter tre mislykkede forsøk på å angi PIN-koden. PIN-koden initialiseres i henhold til installasjonsparametrene når appleten installeres og opprettes.

PIN-koden må verifiseres før en kreditt- eller debettransaksjon kan utføres.

La oss si at kortets maksimale saldo er 2 767, og at ingen kreditt- eller belastningstransaksjoner kan overstige 27. Dermed Java-variabler av typen kort og byte kan representere henholdsvis lommeboksaldoen og beløpet på hver transaksjon.

* En lommebok-applet fra den virkelige verden vil kreve en mye mer sofistikert sikkerhetsmekanisme for å forhindre uautorisert tilgang til lommeboken.

Spesifisering av hjelpemidler

De fleste applikasjoner som du er kjent med er navngitt og identifisert med et strengnavn. I Java Card-teknologi blir imidlertid hver applet identifisert og valgt av en AID. Hver Java-pakke tildeles også en AID. Dette er fordi en pakke, når den er lastet på et kort, er koblet til andre pakker, som allerede har blitt plassert på kortet via deres AID. Denne navnekonvensjonen er i samsvar med smartkort-spesifikasjonen som definert i ISO 7816.

En AID er en sekvens med byte mellom 5 og 16 byte. Dens format er avbildet i tabell 1.

ISO kontrollerer tildelingen av RID til selskaper, hvor hvert selskap får sin egen unike RID fra ISO. Bedrifter administrerer tildeling av PIX for AID.

Java-klassene til lommebokappleten er definert i en Java-pakke. De fiktive hjelpemidlene for lommebokappleten og appletpakken er definert som illustrert i tabell 2.

Pakken AID og applet AID har samme RID-verdi; deres PIX-verdier er forskjellige fra siste bit.

Definere klassestrukturen og metodefunksjonene til appleten

En Java-kort-appletklasse må strekke seg fra javacard.framework.Applet klasse. Denne klassen er superklassen for alle applets som er bosatt på et Java-kort. Den definerer de vanlige metodene en applet må støtte for å kunne samhandle med JCRE i løpet av sin levetid.

Tabell 3 viser de offentlige og beskyttede metodene som er definert i klassen javacard.framework.Applet:

Klassen javacard.framework.Applet gir et rammeverk for kjøring av applet. Metoder definert i denne klassen kalles av JCRE når JCRE mottar APDU-kommandoer fra CAD.

Etter at appletkoden er riktig lastet på et Java-kort og koblet til andre pakker på kortet, begynner en applets levetid når en appletforekomst blir opprettet og registrert i JCREs registertabell. En applet må implementere den statiske metoden installere() for å opprette en appletforekomst og registrere forekomsten med JCRE ved å påkalle en av de to registrere() metoder. De installere()metoden tar en byte-array som parameter. Denne matrisen inneholder installasjonsparametrene for å initialisere eller tilpasse appletforekomsten.

En applet på et Java-kort er i et inaktivt stadium til det eksplisitt er valgt. Når JCRE mottar en Å VELGE APDU-kommando, den søker i den interne tabellen etter appleten hvis AID samsvarer med den som er spesifisert i kommandoen. Hvis en samsvar blir funnet, forbereder JCRE den nye appleten som skal velges. Denne forberedelsesprosessen består av to trinn: For det første, hvis en nåværende valgt applet er til stede, fjerner JCRE den fra ved å påkalle fravelge () metode. Appleten utfører opprydnings- eller bokføringsarbeid i fravelge () metoden før den går inn i det inaktive stadiet. Deretter påkaller JCRE å velge() metode for å informere den nye appleten om at den er valgt. Den nye appleten utfører enhver initialisering som er nødvendig før den faktisk blir valgt. Appleten returnerer ekte til å velge() metode hvis den nå er klar til å bli aktiv og for å behandle påfølgende APDU-kommandoer. Ellers returnerer appleten falsk for å avvise deltakelsen, og i så fall blir ingen applet valgt. De javacard.framework.Applet klasse gir en standard implementering for både å velge() og fravelge () metoder. En underklasse av Applet klasse kan overstyre disse to metodene for å definere appletens oppførsel under valg og fravalg.

Når en applet er valgt, videresender JCRE alle påfølgende APDU-kommandoer (inkludert Å VELGE kommandoen) til appleten prosess() metode. I prosess() metode, tolker appleten hver APDU-kommando og utfører oppgaven spesifisert av kommandoen. For hver kommando APDU svarer appleten på CAD ved å sende tilbake et svar APDU, som informerer CAD om resultatet av behandlingen av kommandoen APDU. De prosess() metode i klassen javacard.framework.Applet er en abstrakt metode: en underklasse av Applet klasse må overstyre denne metoden for å implementere funksjonene til en applet.

Denne kommando-og-svar-dialogen fortsetter til en ny applet er valgt eller kortet er fjernet fra CAD. Når det ikke er valgt, blir en applet inaktiv til neste gang den velges.

De getShareableInterfaceObject metoden er ment for interapplet-kommunikasjon. Det påkalles av en klient-applet for å be om et delbart grensesnittobjekt fra server-appleten. Standardimplementeringen av denne metoden returnerer null. Dessverre vil en detaljert diskusjon av objektdeling og interapplet-kommunikasjon være utenfor omfanget av denne artikkelen.

Siden Å VELGE APDU-kommandoen blir også videresendt til prosess() metoden, den velger applet () metoden brukes av appleten prosess() metode for å skille mellom Å VELGE APDU-kommando som velger denne appleten fra alle andre Å VELGE APDU-kommandoer som kan relateres til valg av fil eller intern applettilstand.

Definere grensesnittet mellom en applet og terminalapplikasjonen

En applet som kjører på et smartkort kommuniserer med terminalapplikasjonen i CAD ved hjelp av applikasjonsprotokolldataenheter. I hovedsak er grensesnittet mellom en applet og terminalapplikasjonen et sett med APDU-kommandoer som er avtalt og støttet av både appleten og terminalapplikasjonen.

En APDU-grunning

Denne delen gir et sammendrag av APDU-kommandoer for å komme i gang med å definere APDU-kommandoer for lommebokappleten. (Detaljene i APDU-protokollen er spesifisert i ISO 7816.)

APDU-kommandoer er alltid sett med par. Hvert par inneholder en kommando APDU, som spesifiserer en kommando, og en svar APDU, som sender tilbake kjøringsresultatet av kommandoen. I kortverdenen er smartkort det reaktiv kommunikatorer - det vil si at de aldri initierer kommunikasjon, de svarer bare på APDUer fra omverdenen. Terminalapplikasjonen sender en kommando APDU gjennom CAD. JCRE mottar kommandoen, og velger enten en ny applet eller sender kommandoen til den valgte appleten. Den valgte appleten behandler kommandoen og returnerer et svar APDU til terminalapplikasjonen. Kommando-APDU-er og svar-APDU-er byttes vekselvis mellom et kort og en CAD.

Tabell 4 beskriver APDU-formater for kommando og respons.

Definere APDU-kommandoer

En Java-kort-applet skal støtte et sett med APDU-kommandoer, omfattende en Å VELGE APDU-kommando og en eller flere prosess APDU-kommandoer.

• De Å VELGE kommandoen instruerer JCRE om å velge appleten på kortet.
• Prosesskommandosettene definerer kommandoene appleten støtter. Disse er definert i samsvar med funksjonene til appleten.

Java Card-teknologi spesifiserer kodingen av Å VELGE APDU-kommando. Appletutviklere kan fritt definere kodingen av prosesskommandoene sine. Prosesskommandoer må imidlertid være i samsvar med strukturen som er beskrevet ovenfor.

Strukturelt sett er Å VELGE kommando- og prosesskommandoer er par kommandoer og svar-APDUer.

For hver kommando APDU skal appleten først dekode verdien av hvert felt i kommandoen. Hvis de valgfrie datafeltene er inkludert, bør appleten også bestemme formatet og strukturen. Ved hjelp av disse definisjonene vet appleten hvordan man skal tolke hver kommando og lese dataene. Deretter kan den utføre oppgaven spesifisert av kommandoen.