Sådan skriver du en Java Card-applet: En udviklervejledning

Denne artikel leder dig gennem processen med at oprette en simpel elektronisk tegnebog-applet og giver anvisninger til at bygge en applet og konstruere dens kode. Se marts 1998, hvis du har brug for en opdatering af det grundlæggende i Java Card-teknologi Java-udvikler kolonne "Forståelse af Java Card 2.0", som giver en oversigt over smartkort og beskriver systemarkitekturen, API'erne og runtime-miljøet i Java Card-teknologien. For konsistens bruger denne artikel det samme eksempel på tegnebogen, som det blev brugt i kolonnen marts 1998. Den tegnebog-applet, vi bruger i denne artikel, er dog opdateret for at afspejle ændringer i API'erne i Java Card 2.1. Derudover fokuserer denne artikel på at skrive applets til Java Card 2.1, mens den forrige artikel fungerede som en samlet introduktion til Java Card-teknologien.

Arkitekt applet

Som med enhver softwareudvikling skal du først gå igennem en, før du sætter dig ned og skriver en Java-kort-applet designfase. I denne fase definerer du appletens arkitektur.

Fire trin omfatter applet-designfasen:

1. Angiv funktionerne i appleten
2. Anmod om og tildel AID'er til både appleten og pakken, der indeholder appletklassen
3. Design klassestrukturen for appletprogrammerne
4. Definer grænsefladen mellem appleten og terminalapplikationen

I de følgende sektioner bruger vi eksemplet på en tegnebog-applet til at se nærmere på hvert trin i applet-designprocessen.

Specificering af appletens funktioner

Vores eksempel på tegnebog-applet gemmer elektroniske penge og understøtter kredit-, debet- og check-balance-funktioner.

For at forhindre uautoriseret brug af kortet indeholder det en sikkerhedsalgoritme. Denne algoritme kræver, at brugeren indtaster en pinkode, højst en streng på otte cifre. Kortbrugeren skriver sin PIN-kode på et tastatur, der er tilsluttet CAD. Sikkerhedsalgoritmen får kortet til at låse efter tre mislykkede forsøg på at indtaste PIN-koden. PIN-koden initialiseres i henhold til installationsparametrene, når appleten installeres og oprettes.

PIN-koden skal verificeres, før en kredit- eller debiteringstransaktion kan udføres.

Lad os sige, at kortets maksimale saldo er 2.677, og at ingen kredit- eller betalingstransaktion kan overstige 27. Java-variabler af typen kort og byte kan repræsentere henholdsvis tegnebogssaldoen og størrelsen på hver transaktion.

* En ægte verdens tegnebog-applet ville kræve en meget mere sofistikeret sikkerhedsmekanisme for at forhindre uautoriseret adgang til tegnebogen.

Angivelse af AID'er

De fleste applikationer, som du er fortrolig med, navngives og identificeres med et strengnavn. I Java Card-teknologi identificeres og vælges hver applet dog med en AID. Hver Java-pakke tildeles også en AID. Dette skyldes, at en pakke, når den er indlæst på et kort, er forbundet med andre pakker, som allerede er placeret på kortet via deres AID'er. Denne navngivningskonvention er i overensstemmelse med chipkortspecifikationen som defineret i ISO 7816.

En AID er en sekvens af bytes mellem 5 og 16 bytes i længden. Dens format er afbildet i tabel 1.

ISO kontrollerer tildelingen af ​​RID'er til virksomheder, hvor hvert firma får sin egen unikke RID fra ISO. Virksomheder administrerer tildeling af PIX'er til AID'er.

Java-klasser i tegnebog-appleten er defineret i en Java-pakke. De fiktive AID'er til tegnebogen-appleten og appletpakken er defineret som illustreret i tabel 2.

Pakke-AID og applet-AID har samme RID-værdi; deres PIX-værdier adskiller sig ved den sidste bit.

Definition af klassestruktur og metodefunktioner for appleten

En Java-kort-appletklasse skal strække sig fra javacard.framework.Applet klasse. Denne klasse er superklassen for alle applets, der findes på et Java-kort. Den definerer de almindelige metoder, som en applet skal understøtte for at interagere med JCRE i løbet af dens levetid.

Tabel 3 viser de offentlige og beskyttede metoder defineret i klassen javacard.framework.Applet:

Klassen javacard.framework.Applet giver en ramme for applet-udførelse. Metoder defineret i denne klasse kaldes af JCRE, når JCRE modtager APDU-kommandoer fra CAD.

Efter at appletkoden er indlæst korrekt på et Java-kort og forbundet med andre pakker på kortet, starter en applets levetid, når en appletforekomst oprettes og registreres i JCRE's registertabel. En applet skal implementere den statiske metode installere() for at oprette en appletforekomst og registrere forekomsten med JCRE ved at påkalde en af ​​de to Tilmeld() metoder. Det installere()metoden tager et byte-array som parameter. Denne matrix indeholder installationsparametrene til initialisering eller personalisering af appletforekomsten.

En applet på et Java-kort er i en inaktiv fase, indtil den eksplicit er valgt. Når JCRE modtager en VÆLG APDU-kommando, den søger i den interne tabel efter den applet, hvis AID svarer til den, der er angivet i kommandoen. Hvis der findes et match, forbereder JCRE den nye applet, der skal vælges. Denne forberedelsesproces består af to trin: For det første, hvis en aktuelt valgt applet er til stede, fravælger JCRE den ved at påkalde fravælge () metode. Appleten udfører ethvert oprydnings- eller bogføringsarbejde i fravælge () metode, inden den går ind i den inaktive fase. Derefter påberåber JCRE sig Vælg() metode til at informere den nye applet om, at den er valgt. Den nye applet udfører enhver nødvendig initialisering, før den faktisk bliver valgt. Applet'en vender tilbage rigtigt til Vælg() metode, hvis den nu er klar til at blive aktiv og til at behandle efterfølgende APDU-kommandoer. Ellers vender applet tilbage falsk at afvise sin deltagelse, og hvis ja, vælges ingen applet. Det javacard.framework.Applet klasse giver en standardimplementering for begge Vælg() og fravælge () metoder. En underklasse af Applet klasse kan tilsidesætte disse to metoder til at definere applets adfærd under markering og fravælgelse.

Når en applet er valgt, videresender JCRE alle efterfølgende APDU-kommandoer (inklusive VÆLG kommando) til appletens behandle() metode. I behandle() metode fortolker applet hver APDU-kommando og udfører den opgave, der er angivet af kommandoen. For hver kommando APDU reagerer applet på CAD ved at sende et svar APDU tilbage, som informerer CAD om resultatet af behandlingen af ​​kommandoen APDU. Det behandle() metode i klassen javacard.framework.Applet er en abstrakt metode: en underklasse af Applet klasse skal tilsidesætte denne metode for at implementere en applets funktioner.

Denne kommando-og-svar-dialog fortsætter, indtil en ny applet er valgt, eller kortet fjernes fra CAD. Når den ikke er valgt, bliver en applet inaktiv indtil næste gang den vælges.

Det getShareableInterfaceObject metoden er beregnet til interapplet kommunikation. Det påkræves af en klient-applet for at anmode om et delbart interface-objekt fra server-appleten. Standardimplementeringen af ​​denne metode returnerer null. Desværre vil en detaljeret diskussion af objektdeling og interapplet-kommunikation være uden for denne artikels anvendelsesområde.

Siden VÆLG APDU kommando videresendes også til behandle() metode, den vælger applet () metode bruges af appletens behandle() metode til at skelne mellem VÆLG APDU-kommando, der vælger denne applet fra alle andre VÆLG APDU-kommandoer, der kan relateres til valg af fil- eller intern appletilstand.

Definere grænsefladen mellem en applet og dens terminalapplikation

En applet, der kører på et smartcard, kommunikerer med terminalapplikationen ved CAD ved hjælp af applikationsprotokol-dataenheder. I det væsentlige er grænsefladen mellem en applet og dens terminalapplikation et sæt APDU-kommandoer, der er aftalt og understøttet af både appleten og terminalapplikationen.

En APDU-primer

Dette afsnit giver en oversigt over APDU-kommandoer for at komme i gang med at definere APDU-kommandoer til tegnebogen. (Detaljerne i APDU-protokollen er specificeret i ISO 7816.)

APDU-kommandoer er altid parpar. Hvert par indeholder en kommando APDU, der specificerer en kommando, og en svar APDU, der sender eksekveringsresultatet af kommandoen tilbage. I kortverdenen er smartkort det reaktiv kommunikatorer - det vil sige, de initierer aldrig kommunikation, de svarer kun på APDU'er fra omverdenen. Terminalapplikationen sender en kommando APDU gennem CAD. JCRE modtager kommandoen og vælger enten en ny applet eller sender kommandoen til den aktuelt valgte applet. Den aktuelt valgte applet behandler kommandoen og returnerer et svar APDU til terminalapplikationen. Kommando-APDU'er og svar-APDU'er udveksles skiftevis mellem et kort og en CAD.

Tabel 4 beskriver APDU-formater for kommando og respons.

Definition af APDU-kommandoer

En Java Card-applet skal understøtte et sæt APDU-kommandoer, der omfatter en VÆLG APDU-kommando og en eller flere proces APDU-kommandoer.

• Det VÆLG kommando instruerer JCRE om at vælge appleten på kortet.
• Sættet med proceskommandoer definerer de kommandoer, som miniprogrammet understøtter. Disse defineres i overensstemmelse med funktionerne i appleten.

Java Card-teknologi specificerer kodningen af VÆLG APDU-kommando. Appletudviklere kan frit definere kodningen af ​​deres proceskommandoer. Proceskommandoer skal dog være i overensstemmelse med strukturen beskrevet ovenfor.

Strukturelt set VÆLG kommando- og proceskommandoer er par af APDU'er til kommando og svar.

For hver kommando APDU skal appleten først afkode værdien for hvert felt i kommandoen. Hvis de valgfri datafelter er inkluderet, skal appleten også bestemme deres format og struktur. Ved hjælp af disse definitioner ved appleten, hvordan man fortolker hver kommando og læser dataene. Derefter kan den udføre den opgave, der er angivet af kommandoen.