Programmering

Forstå Java Card 2.0

Denne artikkelen begynner med en oversikt over smartkort og en kort gjennomgang av ISO 7816, smartkortstandarden. Gitt bakgrunnen for smartkort i forrige Java Developer kolonnene, begynner denne delen med et svar på spørsmålet "Hva er et Java-kort?" og en oversikt over Java Card-systemarkitekturen. Deretter vil vi fokusere på de mange problemene som er spesifikke for Java-kortet, inkludert livssyklusen til Java-kort; Java Card 2.0 språkundersett og API-biblioteksklasser; og Java Card-sikkerhet. Deretter diskuterer vi Java Card runtime-miljøet og viser hvordan et Java Card kjører. Vi avslutter med et lysende eksempel: En elektronisk lommebokapplikasjon skrevet bare for Java-kortet.

Herfra refererer alle referanser til Java Card implisitt til Java Card 2.0.

Hva er et smartkort?

Identisk med størrelsen på et kredittkort, lagrer og behandler et smartkort informasjon gjennom de elektroniske kretsene som er innebygd i silisium i plastsubstratet i kroppen. Det er to grunnleggende typer smartkort: An intelligent smartkort inneholder en mikroprosessor og tilbyr lese-, skrive- og beregningsevne, som en liten mikrocomputer. EN minnekortderimot, har ikke mikroprosessor og er kun ment for informasjonslagring. Et minnekort bruker sikkerhetslogikk for å kontrollere tilgangen til minnet.

Alle smartkort inneholder tre typer minne: vedvarende ikke-muterbart minne; vedvarende foranderlig minne; og ikke-vedvarende foranderlig minne. ROM, EEPROM og RAM er det mest brukte minnet for de tre respektive typene i de nåværende smartkortene. Vedvarende minne kalles også ikke-flyktig minne. Vi vil bruke vilkårene vedvarende og ikke-flyktig om hverandre i denne artikkelen.

ISO 7816 del 1-7, definert av International Standard Organization, inneholder et sett med standarder som dekker ulike aspekter av smartkort. ISO 7816 består av:

  • Fysiske egenskaper (del 1)

  • Kontaktenes dimensjoner og plassering (del 2)

  • Elektroniske signaler og overføringsprotokoller (del 3)

  • Interindustrielle kommandoer for utveksling (del 4)

  • Søknadsidentifikatorer (del 5)

  • Dataelementer mellom bransjer (del 6)

  • Interindustrielle kommandoer for SCQL (del 7)

Følgende diagram illustrerer de fysiske egenskapene til et smartkort, som er definert i ISO 7816, del 1.

For mer informasjon om ISO 7816 og smartkort, se "Smartkort: En primer."

Normalt inneholder et smartkort ikke strømforsyning, skjerm eller tastatur. Den samhandler med omverdenen ved hjelp av det serielle kommunikasjonsgrensesnittet via de åtte kontaktpunktene. Kontaktenes dimensjoner og plassering er dekket i del 2 av ISO 7816. Dette diagrammet viser kontaktene på et smartkort.

Et smartkort settes inn i en Card Acceptance Device (CAD), som kan kobles til en annen datamaskin. Andre vilkår som brukes for kortakseptanordningen er terminal, leser, og IFD (grensesnitt enhet). De har alle de samme grunnleggende funksjonene, nemlig å forsyne kortet med strøm og å opprette en databærende forbindelse.

Når to datamaskiner kommuniserer med hverandre, utveksler de datapakker, som er konstruert etter et sett med protokoller. På samme måte snakker smartkort til omverdenen ved hjelp av sine egne datapakker - kalt APDU (Application Protocol Data Units). APDU inneholder enten en kommando eller en svarmelding. I kortverdenen brukes master-slave-modellen der et smartkort alltid spiller den passive rollen. Med andre ord venter et smartkort alltid på en kommando APDU fra en terminal. Den utfører deretter handlingen spesifisert i APDU og svarer til terminalen med et svar APDU. Kommando-APDU-er og svar-APDU-er byttes alternativt mellom et kort og en terminal.

Følgende tabeller illustrerer henholdsvis APDU-formater for kommando og respons. APDU-struktur er beskrevet i ISO 7816, del 4.

Kommando APDU
Obligatorisk topptekstBetinget kropp
CLAINSP1P2LcDatafeltLe

Overskriften koder den valgte kommandoen. Den består av fire felt: klasse (CLA), instruksjon (INS) og parametere 1 og 2 (P1 og P2). Hvert felt inneholder 1 byte:

  • CLA: Klassebyte. I mange smartkort brukes denne byten til å identifisere et program.

  • INS: Instruksjonsbyte. Denne byten angir instruksjonskoden.

  • P1-P2: Parameterbyte. Disse gir ytterligere kvalifisering til APDU-kommandoen.

Lc betegner antall byte i datafeltet til kommandoen APDU; Le betegner det maksimale antallet byte som forventes i datafeltet til følgende svar APDU.

Svar APDU
Betinget kroppObligatorisk trailer
DatafeltSW1SW2

Statusbyte SW1 og SW2 betegner behandlingsstatus for kommandoen APDU på et kort.

Hva er et Java-kort?

Et Java-kort er et smartkort som kan kjøre Java-programmer. Java Card 2.0-spesifikasjonen ble publisert på //www.javasoft.com/javacard. Den inneholder detaljert informasjon for å bygge Java Card virtuell maskin og applikasjonsprogrammeringsgrensesnitt (API) i smartkort. Minimumskravet til systemet er 16 kilobyte skrivebeskyttet minne (ROM), 8 kilobyte EEPROM og 256 byte random access memory (RAM).

Systemarkitekturen på Java-kortet er illustrert i følgende figur.

Som vist i figuren, er Java Card VM bygget på toppen av en spesifikk integrert krets (IC) og implementering av operativsystem. JVM-laget skjuler produsentens egenutviklede teknologi med et felles språk- og systemgrensesnitt. Java Card-rammeverket definerer et sett med API-klasser (Application Programming Interface) for utvikling av Java-kortapplikasjoner og for å tilby systemtjenester til disse applikasjonene. En bestemt bransje eller virksomhet kan levere tilleggsbiblioteker for å tilby en tjeneste eller for å foredle sikkerhets- og systemmodellen. Java-kortapplikasjoner kalles applets. Flere applikasjoner kan ligge på ett kort. Hver applet er identifisert unikt av sin BISTAND (applikasjonsidentifikator), som definert i ISO 7816, del 5.

Et viktig poeng å huske på er hvilke smartkort er ikke: De er ikke personlige datamaskiner. De har begrenset minneressurser og datakraft. Brukere skal ikke tenke på Java Card 2.0 som bare en avkledd versjon av JDK.

Levetiden til et Java-kort

Java-kortets levetid starter når det opprinnelige operativsystemet, Java-kort-VM, API-klassebiblioteker og eventuelt applets er brent inn i ROM. Denne prosessen med å skrive de permanente komponentene i det ikke-muterbare minnet til en chip for å utføre innkommende kommandoer kalles maskering.

Før det lander i lommeboken, må et Java-kort gjennomgå initialisering og personalisering. Initialisering refererer til innlasting av generelle data i et korts ikke-flyktige minne. Disse dataene er identiske på et stort antall kort og er ikke spesifikke for et individ. et eksempel kan være navnet på utstederen eller produsenten.

Det neste trinnet, personalisering, innebærer å tildele et kort til en person. Det kan skje gjennom fysisk personalisering eller gjennom elektronisk personalisering. Fysisk personalisering refererer til preging eller lasergravering av navn og kortnummer på plastoverflaten til et kort. Elektronisk personalisering refererer til å laste inn personlige data i et korts ikke-flyktige minne, for eksempel din personlige nøkkel, navn og pin-nummer.

Initialisering og personalisering varierer fra leverandør til leverandør og utsteder til utsteder. I begge brukes ofte EEPROM (en type ikke-flyktig minne) til lagring av data.

På dette tidspunktet er Java-kortet klart til bruk. Du kan få et Java-kort fra en utsteder eller kjøpe det fra en forhandler. Kort som selges av en forhandler er generelle formål, i så fall blir personalisering ofte utelatt.

Nå kan du sette inn Java-kortet ditt i en leser og sende APDU-kommandoer til appletsene som ligger på kortet eller laste ned flere applets eller data på kortet.

Et Java-kort forblir aktivt til det er utløpt eller blokkert på grunn av en uopprettelig feil.

Levetiden til en virtuell Java-kortmaskin

I motsetning til den virtuelle Java-maskinen (JVM) i en PC eller arbeidsstasjon, kjører den virtuelle Java-kortet for alltid.

Det meste av informasjonen som er lagret på kortet, må bevares selv når strømmen fjernes - det vil si når kortet fjernes fra leseren. Java-kort-VM oppretter objekter i EEPROM for å beholde den vedvarende informasjonen. Kjørelevetiden til Java Card VM er kortets levetid. Når strømmen ikke leveres, kjører VM i en uendelig klokkesyklus.

Levetiden til Java-kortprogrammer og -objekter

Levetiden til en applet begynner når den er riktig installert og registrert i systemets registertabell og slutter når den fjernes fra tabellen. Plassen til en fjernet applet kan eller ikke kan gjenbrukes, avhengig av om søppeloppsamling er implementert på kortet. En applet på et kort er i et inaktivt stadium til det eksplisitt er valgt av terminalen.

Objekter blir opprettet i det vedvarende minnet (for eksempel EEPROM). De kan gå tapt eller samle søppel hvis andre vedvarende gjenstander ikke refererer til dem. Imidlertid er det tusen ganger tregere å skrive til EEPROM enn til RAM.

Noen objekter er ofte tilgjengelige, og innholdet i feltene deres trenger ikke være vedvarende. Java-kortet støtter flyktig (midlertidige) objekter i RAM. Når et objekt er erklært som forbigående, kan ikke innholdet flyttes tilbake til det vedvarende minnet.

Delsett med Java Card 2.0-språk

Java Card-programmer er selvfølgelig skrevet på Java. De er samlet ved hjelp av vanlige Java-kompilatorer. På grunn av begrensede minnesressurser og datakraft støttes ikke alle språkfunksjonene som er definert i Java Language Specification på Java-kortet. Spesielt støtter ikke Java-kortet:

  • Dynamisk klasselasting

  • Sikkerhetssjef

  • Tråder og synkronisering

  • Objektkloning

  • Finalisering

  • Store primitive datatyper (float, double, long og char)

Det er ingen overraskelse at søkeord som støtter disse funksjonene, også er utelatt fra språket. VM-implementatorer kan bestemme seg for å støtte 32-biters heltallstype eller innfødte metoder for appletter etter utstedelse hvis de jobber med et mer avansert smartkort med mer minne. Etter utstedelse er de appletene som er installert på et Java-kort etter at kortet er utstedt til en kortholder.

Java Card 2.0-rammeverket

Smartkort har vært i markedet i 20 år, og de fleste av dem er generelt kompatible med ISO 7816 del 1-7 og / eller EMV. Vi har allerede sett på ISO 7816. Hva er EMV? EMV-standarden, definert av Europay, MasterCard og Visa, er basert på ISO 7816-serien med standarder med tilleggsbeskyttede funksjoner for å møte de spesifikke behovene i finansnæringen. Java Card Framework er designet for å enkelt støtte smartkortsystemer og applikasjoner. Det skjuler detaljene i smartkortinfrastrukturen og gir Java Card-applikasjonsutviklere et relativt enkelt og greit programmeringsgrensesnitt.

Java Card-rammeverket inneholder fire pakker:

Pakkens navnBeskrivelse
javacard.frameworkDette er kjernepakken på kortet. Den definerer klasser som og , som er de grunnleggende byggesteinene for Java Card-programmer og , og , som gir kjøretid og systemtjeneste til Java Card-programmer, for eksempel APDU-håndtering og objektdeling
javacardx.framework Denne pakken gir en objektorientert design for et ISO 7816-4-kompatibelt filsystem. Den støtter elementære filer (EF), dedikerte filer (DF) og filorienterte APDUer som spesifisert i ISO7816
javacardx.crypto og javacardx.cryptoEnc Disse to pakkene støtter kryptografisk funksjonalitet som kreves i smartkort

I samsvar med Java-navnekonvensjonen, Java Cardx pakker er utvidelser av Java Card-rammeverket. Det kreves ikke at du støtter dem på kortet.

Java-kortsikkerhet

Java-appletter er underlagt Java-sikkerhetsbegrensninger, men sikkerhetsmodellen til Java Card-systemer skiller seg ut fra standard Java på mange måter.

Security Manager-klassen støttes ikke på Java-kort. Retningslinjer for språksikkerhet implementeres av den virtuelle maskinen.

Java-appletter lager objekter som lagrer og manipulerer data. Et objekt eies av appleten som oppretter det. Selv om en applet kan ha referanse til et objekt, kan den ikke påberope seg objektets metoder, med mindre den eier objektet eller objektet er delt eksplisitt. En applet kan dele alle objektene med en bestemt applet eller med alle applets.

En applet er en uavhengig enhet innenfor et Java-kort. Valget, utførelsen og funksjonaliteten påvirkes ikke av andre applets som ligger på det samme kortet.

Hvordan ting fungerer sammen på et Java-kort

Inne på et Java-kort refererer JCRE (Java Card Runtime Environment) til den virtuelle Java-kortet og klassene i Java Card Framework. Hver applet på et Java-kort er tilknyttet unik AID tildelt av JCRE.

Etter at en applet er riktig lastet inn i kortets vedvarende minne og koblet til Java Card Framework og andre biblioteker på kortet, kaller JCRE appletens installasjonsmetode som det siste trinnet i installasjonen av appleten. En offentlig statisk metode, installere, må implementeres av en appletklasse for å opprette en forekomst av appleten og registrere den hos JCRE. Fordi minnet er begrenset, er det god programmeringspraksis, på dette tidspunktet, å lage og initialisere objektene appleten trenger i løpet av sin levetid.

$config[zx-auto] not found$config[zx-overlay] not found