Forståelse af Java Card 2.0

Denne artikel begynder med en oversigt over chipkort og en kort gennemgang af ISO 7816, smartcard-standarden. Givet baggrunden for chipkort i tidligere Java-udvikler kolonner, begynder denne rate med et svar på spørgsmålet "Hvad er et Java-kort?" og en oversigt over Java Card-systemarkitekturen. Derefter fokuserer vi på de mange specifikke problemer for Java-kortet, herunder Java-kortets livscyklus; Java Card 2.0 sprogundersæt og API-biblioteksklasser; og Java Card-sikkerhed. Derefter diskuterer vi Java Card runtime-miljøet og viser, hvordan et Java Card kører. Vi lukker med et lysende eksempel: En elektronisk tegnebogsprogram, der er skrevet kun til Java-kortet.

Herfra henviser alle henvisninger til Java Card implicit til Java Card 2.0.

Hvad er et chipkort?

Identisk med størrelsen på et kreditkort lagrer og behandler et chipkort information gennem de elektroniske kredsløb, der er indlejret i silicium i plastsubstratet i dets krop. Der er to grundlæggende slags smartkort: An intelligent smart card indeholder en mikroprocessor og tilbyder læsning, skrivning og beregningskapacitet, som en lille mikrocomputer. EN hukommelseskortderimod har ikke en mikroprocessor og er kun beregnet til informationslagring. Et hukommelseskort bruger sikkerhedslogik til at kontrollere adgangen til hukommelsen.

Alle smartkort indeholder tre typer hukommelse: vedvarende, ikke-ændret hukommelse; vedvarende mutabel hukommelse; og ikke-vedvarende mutabel hukommelse. ROM, EEPROM og RAM er den mest anvendte hukommelse til de tre respektive typer i de nuværende smartkort. Vedvarende hukommelse kaldes også ikke-flygtig hukommelse. Vi bruger vilkårene vedholdende og ikke-flygtig omskifteligt i denne artikel.

ISO 7816 del 1-7, defineret af International Standard Organization, indeholder et sæt standarder, der dækker forskellige aspekter af smartkort. ISO 7816 består af:

• Fysiske egenskaber (del 1)

• Kontakternes dimensioner og placering (del 2)

• Elektroniske signaler og transmissionsprotokoller (del 3)

• Inter-industri kommandoer til udveksling (del 4)

• Applikationsidentifikatorer (del 5)

• Interindustrielle dataelementer (del 6)

• Interindustrielle kommandoer til SCQL (del 7)

Følgende diagram illustrerer de fysiske egenskaber ved et chipkort, der er defineret i ISO 7816, del 1.

For mere information om ISO 7816 og smartkort, se "Smart cards: A primer."

Normalt indeholder et chipkort ikke en strømforsyning, et display eller et tastatur. Det interagerer med omverdenen ved hjælp af den serielle kommunikationsgrænseflade via dets otte kontaktpunkter. Kontaktenes dimensioner og placering er dækket af del 2 i ISO 7816. Dette diagram viser kontakterne på et chipkort.

Et chipkort indsættes i en Card Acceptance Device (CAD), som muligvis opretter forbindelse til en anden computer. Andre udtryk, der bruges til Card Acceptance Device er terminal, læserog IFD (interface enhed). De leverer alle de samme grundlæggende funktioner, nemlig at forsyne kortet med strøm og etablere en databærende forbindelse.

Når to computere kommunikerer med hinanden, udveksler de datapakker, der er konstrueret efter et sæt protokoller. På samme måde taler smartkort til omverdenen ved hjælp af deres egne datapakker - kaldet APDU (Applikationsprotokol-dataenheder). APDU indeholder enten en kommando eller en svarmeddelelse. I kortverdenen bruges master-slave-modellen, hvor et smartkort altid spiller den passive rolle. Med andre ord venter et smartkort altid på en kommando APDU fra en terminal. Derefter udfører den den handling, der er specificeret i APDU'en og svarer til terminalen med et svar APDU. Kommando-APDU'er og svar-APDU'er udveksles alternativt mellem et kort og en terminal.

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

Overskriften koder den valgte kommando. Den består af fire felter: klasse (CLA), instruktion (INS) og parametre 1 og 2 (P1 og P2). Hvert felt indeholder 1 byte:

• CLA: Klasse-byte. I mange smartkort bruges denne byte til at identificere en applikation.

• INS: Instruktionsbyte. Denne byte angiver instruktionskoden.

• P1-P2: Parameterbyte. Disse giver yderligere kvalifikationer til APDU-kommandoen.

Lc angiver antallet af bytes i datafeltet for kommandoen APDU; Le angiver det maksimale antal byte, der forventes i datafeltet for det følgende svar APDU.

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

Hvad er et Java-kort?

Et Java-kort er et smartkort, der er i stand til at køre Java-programmer. Java Card 2.0-specifikationen blev offentliggjort på //www.javasoft.com/javacard. Den indeholder detaljeret information til opbygning af den virtuelle Java-kortmaskine og API til applikationsprogrammering på smartkort. Minimumskravet til systemet er 16 kilobyte skrivebeskyttet hukommelse (ROM), 8 kilobyte EEPROM og 256 byte tilfældig adgangshukommelse (RAM).

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

Som vist i figuren er Java Card VM bygget oven på et specifikt integreret kredsløb (IC) og implementering af det indbyggede operativsystem. JVM-laget skjuler producentens proprietære teknologi med et fælles sprog og systemgrænseflade. Java Card-rammen definerer et sæt API-klasser (Application Programming Interface) til udvikling af Java-kortapplikationer og til levering af systemtjenester til disse applikationer. En bestemt branche eller virksomhed kan levere tilføjelsesbiblioteker for at levere en service eller for at finjustere sikkerheds- og systemmodellen. Java-kortapplikationer kaldes applets. Flere applets kan findes på et kort. Hver applet identificeres entydigt ved hjælp af dens HJÆLPE (applikationsidentifikator), som defineret i ISO 7816, del 5.

Et vigtigt punkt at huske på er hvilke smartkort er ikke: De er ikke personlige computere. De har begrænsede hukommelsesressourcer og computerkraft. Brugere bør ikke tænke på Java Card 2.0 som blot en afskåret version af JDK.

Levetiden for et Java-kort

Java-kortets levetid starter, når det oprindelige OS, Java Card VM, API-klassebiblioteker og eventuelt applets brændes ind i ROM. Denne proces med at skrive de permanente komponenter i den ikke-mutable hukommelse på en chip til udførelse af indgående kommandoer kaldes maskering.

Inden det lander i din tegnebog, skal et Java-kort gennemgå initialisering og personalisering. Initialisering refererer til indlæsning af generelle data i et korts ikke-flygtige hukommelse. Disse data er identiske på tværs af et stort antal kort og er ikke specifikke for et individ. et eksempel kan være udstederens eller producentens navn.

Det næste trin, personalisering, indebærer at tildele et kort til en person. Det kan ske gennem fysisk personalisering eller gennem elektronisk personalisering. Fysisk personalisering henviser til prægning eller lasergravering af dit navn og kortnummer på plastikoverfladen på et kort. Elektronisk personalisering henviser til indlæsning af personlige data i et korts ikke-flygtige hukommelse, for eksempel din personlige nøgle, navn og pinkode.

Initialisering og personalisering varierer fra leverandør til sælger og udsteder til udsteder. I begge bruges EEPROM (en type ikke-flygtig hukommelse) ofte til lagring af data.

På dette tidspunkt er Java-kortet klar til brug. Du kan få et Java-kort fra en udsteder eller købe det fra en forhandler. Kort, der sælges af en forhandler, er generelle formål, i hvilket tilfælde personalisering ofte udelades.

Nu kan du indsætte dit Java-kort i en læser og sende APDU-kommandoer til de applets, der findes på kortet, eller downloade flere applets eller data på kortet.

Et Java-kort forbliver aktivt, indtil det er udløbet eller blokeret på grund af en uoprettelig fejl.

Levetid på en virtuel Java Card-maskine

I modsætning til den virtuelle Java-maskine (JVM) i en pc eller arbejdsstation kører den virtuelle Java-kortmaskine for evigt.

De fleste af de oplysninger, der er gemt på kortet, skal bevares, selv når strømmen fjernes - det vil sige når kortet fjernes fra læseren. Java Card VM opretter objekter i EEPROM til at indeholde de vedvarende oplysninger. Udførelsens levetid for Java Card VM er kortets levetid. Når strømmen ikke leveres, kører den virtuelle computer i en uendelig urcyklus.

Levetiden for Java-kort-applets og objekter

En applets levetid starter, når den er korrekt installeret og registreret i systemets registreringsdatabasetabel, og slutter, når den fjernes fra tabellen. Pladsen i en fjernet applet kan eller måske ikke genbruges, afhængigt af om affaldsindsamling er implementeret på kortet. En applet på et kort er i et inaktivt trin, indtil det udtrykkeligt vælges af terminalen.

Objekter oprettes i den vedvarende hukommelse (for eksempel EEPROM). De kan gå tabt eller indsamles skrald, hvis andre vedvarende genstande ikke refererer til dem. Det er dog tusind gange langsommere at skrive til EEPROM end til RAM.

Der er ofte adgang til nogle objekter, og indholdet af deres felter behøver ikke at være vedholdende. Java-kortet understøtter forbigående (midlertidige) objekter i RAM. Når et objekt er blevet erklæret forbigående, kan dets indhold ikke flyttes tilbage til den vedvarende hukommelse.

Java Card 2.0 sprogundersæt

Java Card-programmer er naturligvis skrevet i Java. De er kompileret ved hjælp af almindelige Java-kompilatorer. På grund af begrænsede hukommelsesressourcer og computerkraft understøttes ikke alle de sprogfunktioner, der er defineret i Java Language Specification, på Java-kortet. Specifikt understøtter Java-kortet ikke:

• Dynamisk klasseindlæsning

• Sikkerhedschef

• Tråde og synkronisering

• Objektkloning

• Afslutning

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

Det er ikke overraskende, at nøgleord, der understøtter disse funktioner, også udelades fra sproget. VM-implementatorer kan beslutte at understøtte 32-bit heltalstype eller native-metoder til applets efter udstedelse, hvis de arbejder på et mere avanceret chipkort med mere hukommelse. Post-udstedelses-applets er de applets, der er installeret på et Java-kort, efter at kortet er udstedt til en kortholder.

Java Card 2.0-rammen

Smartkort har været på markedet i 20 år, og de fleste af dem er generelt kompatible med ISO 7816 dele 1-7 og / eller EMV. Vi har allerede set på ISO 7816. Hvad er EMV? EMV-standarden, defineret af Europay, MasterCard og Visa, er baseret på ISO 7816-serien af ​​standarder med yderligere proprietære funktioner, der imødekommer de finansielle behovs specifikke behov. Java Card Framework er designet til nemt at understøtte smartcardsystemer og applikationer. Det skjuler detaljerne i chipkortinfrastrukturen og giver Java Card-applikationsudviklere en relativt let og ligetil programmeringsgrænseflade.

Java Card-rammen indeholder fire pakker:

I overensstemmelse med Java-navngivningskonventionen, Java Cardx pakker er udvidelser til Java Card-rammen. Det kræves ikke, at du støtter dem på kortet.

Java-kort sikkerhed

Java-applets er underlagt Java-sikkerhedsrestriktioner, men sikkerhedsmodellen for Java Card-systemer adskiller sig fra standard Java på mange måder.

Klassen Security Manager understøttes ikke på Java-kort. Sprogsikkerhedspolitikker implementeres af den virtuelle maskine.

Java-applets opretter objekter, der gemmer og manipulerer data. Et objekt ejes af den applet, der opretter det. Selvom en applet kan have henvisningen til et objekt, kan den ikke påberåbe sig objektets metoder, medmindre den ejer objektet, eller objektet deles eksplicit. En applet kan dele ethvert af sine objekter med en bestemt applet eller med alle applets.

En applet er en uafhængig enhed inden for et Java-kort. Dets valg, udførelse og funktionalitet påvirkes ikke af andre applets, der findes på det samme kort.

Hvordan ting fungerer sammen på et Java-kort

Inde i et Java-kort refererer JCRE (Java Card Runtime Environment) til den virtuelle Java-kortmaskine og klasserne i Java Card Framework. Hver applet inden for et Java-kort er knyttet til en unik AID tildelt af JCRE.

Når en applet er korrekt indlæst i kortets vedvarende hukommelse og forbundet med Java Card Framework og andre biblioteker på kortet, kalder JCRE applets installationsmetode som det sidste trin i appletinstallationsprocessen. En offentlig statisk metode, installere, skal implementeres af en appletklasse for at oprette en instans af appleten og registrere den hos JCRE. Da hukommelsen er begrænset, er det god programmeringspraksis på dette tidspunkt at oprette og initialisere de objekter, som appleten har brug for i løbet af sin levetid.