Java-kort

JCRE er ansvarlig for styring av kortressurser, nettverkskommunikasjon, utførelse og sikkerhet for appletter. Den er implementert på smartkortet og brukes hovedsakelig til operativsystemet som er tilstede på kortet. JCRE består av JCVM, API-er, bransjespesifikke utvidelser. og klassesystemer.

JCRE skiller applets fra de tekniske egenskapene til smartkortet. Det gir standardsystemet og API-ene for applets. Disse er derfor lettere å skrive og er derfor lett bærbare på forskjellige smartkortarkitekturer.

Det nedre laget av JCRE inneholder JCVM og native metoder. De gir støtte for JCVM og klassesystemet for neste lag. Klassesystemet rammer driften av JCRE, og dens rolle ligner på et operativsystem. Han er ansvarlig:

Klassesystemet påkaller innfødte metoder. De inneholder et sett med funksjoner på lavt nivå som tillater JCRE å administrere de fysiske ressursene på kortet, for eksempel I / O, minneadministrasjon eller den kryptografiske prosessoren. Disse metodene er samlet i kjørbar kode dedikert til prosessoren på kortet.

API-klassestrukturen definerer applikasjonsprogrammeringsgrensesnitt, APIer . Den største fordelen er at det gjør det lettere å lage applets . Applet utviklere kan fokusere sine programmering innsats mot begrensningene i smartkort system infrastruktur med de tilgjengelige API utvidelser. Applets har tilgang til JCRE-tjenester gjennom API-klasser.

Den bransjespesifikke utvidelsesstrukturen gir komplementære biblioteker med tilleggstjenester eller system- og sikkerhetsmodeller (f.eks. Finansnæringer).

Installatøren muliggjør sikker nedlasting av programvare og applets til kortet etter at kortet er produsert og levert til brukeren. Den interne installatøren samarbeider med den eksterne installatøren à la carte. Sammen utfører de oppgaven med å laste inn det binære innholdet i CAP-filen eller klasse (r) -filen. Imidlertid er installasjonsprogrammet en valgfri JCRE-komponent, men uten det må all kortprogramvare, inkludert appletter , skrives til kortminnet under produksjonsprosessen.

Det tilgjengelige applikasjonsprogrammeringsgrensesnittet API brukes til å utvikle applikasjoner og tilby tjenester til disse applikasjonene: Disse klassene definerer konvensjonene som en Java Card-applet har tilgang til JCRE og native funksjoner, inkludert systemfunksjonen. / O operasjoner. APIene som brukes av kortet er:

1. Implementeringer av forskjellige krypteringsnøkler av KeyBuilder-klassen;
2. Hashing av data av MessageDigest-klassen;
3. Tilfeldig datagenerering etter RandomData-klassen;
4. Signatur av Signatur-klassen;
5. Sesjonsnøkkel utveksling ved KeyAgreement klassen.

Java Card 3 "Connected" versjon

Versjon 3 “Connected” av Java Card-plattformspesifikasjonene har store forskjeller med de andre eksisterende versjonene.

For det første, mens tidligere versjoner bare kunne laste spesifikke binære filer (CAP-filer), blir "Connected" Java Card 3-applikasjoner distribuert som konvensjonelt kompilerte java-filer (filer .class) gruppert i enkeltfiler .jar. Det er da ikke lenger nødvendig å bruke kodekonverteringsverktøy.

I tillegg favoriserer Java Card 3 “Connected” internettkommunikasjonsmodus: Internett-protokoller via ISO 7816-4 IP-standarden for grensesnitt “med kontakter”. ISO 14443 brukes til “kontaktløse” grensesnitt. De "Connected" Java Card 3-applikasjonene er faktisk Servlets , det vil si ekte Webtjenester , som som sådan respekterer HTTP- protokollen .

Java Card 3 virtuelle maskin er basert på CLDC mye brukt i verden av mobiltelefoni. Denne plattformen gir tilgang til de rikeste funksjonene i JAVA-språket. CLDC-plattformen har blitt redusert i størrelse, protokoller og sikkerhetssystemer for smartkort er integrert.

Utvikling av enheter som støtter Java Card-teknologi

Forbedring medført av den tilkoblede versjonen 3 .

• Skriv applikasjoner servlets .
• Multithreading ledelse.
• Verifisering med intern byte-kode (Verifisering av.klasse med intern virtuell maskin).
• Søppeloppsamler inkludert i den virtuelle maskinen.
• Lagt til Char, Long og String typer.
• Flerdimensjonalt utvalg.
• Klasse som representerer de primitive typene (boolsk, heltall, ...)
• Klasse for håndtering av karakterstrenger (StringBuilder ...).
• Klasse for I / O-ledelse (Reader, Writer og Stream).
• Klasse for nettverksadministrasjon.
• Klasse for administrasjon av samlinger (Vector, hashtable ...).
• Klasse for datostyring.
• Klasse for lokalisering og internasjonalisering.
• Programmeringsspråket er forbedret med spesifikke funksjoner fra Java SE:

Begrensning av Java-kort V3 servletmotor

Liste over hovedfunksjonene i Java Serlet 2.4-spesifikasjonene som ikke støttes av Java Card V3-plattformen.

• APIer støttes ikke (java.io.File, java.net.URL, java.util.Map, java.util.Set, java.security.cert.X509Certificate ...). For eksempel kan du ikke slette en fil med slettemetoden til klassen java.io.File, kan ikke bruke hashmap-strukturen, kan ikke bruke X509-sertifikatadministrasjon ( RFC  2459).
• Flytende nummer (flyte). Det er ikke mulig å utføre operasjoner på desimaltall.
• Serialisering og kloning av objekter (java.io.Serializable, java.lang.Cloneable). Det er ikke mulig å konvertere objekter til binær strøm for å håndtere utholdenhet. Det er ikke mulig å opprette nye forekomster fra en objektreferanse (klone).
• Støtte for Java Server Pages V2.0. JSP-koder gjenkjennes ikke, derfor er forpliktelse til å skrive servlets i Java.
• Java Naming and Directory Interface . Ingen tilgang til kataloghåndteringsklasser.

Java Card Application Security

Sikkerhetsadministrasjonen utviklet for smartkort er implementert av JCVM som gir følgende sikkerhetsregler:

• Hver JCVM inneholder en verifiseringsfunksjon hvis rolle er å verifisere de kompilerte Java-filene (.class) utstedt av en Java-kompilator. På Java Card versjon 3-plattformen er det imidlertid mulig å laste klassefiler direkte uten å gå gjennom verifisereren og omformeren.
• JCREs sikkerhetsfunksjon tvinger brannmurer til å isolere hver applet eller servlet, og forhindrer uautorisert tilgang til objekter opprettet av en annen applet.
• All tilgang til metoder og variabler i en klassefil er av accessors. Disse aksessorer definerer en primitiv type konsistensjekk for hver metode. Det er mulig å erklære en metode "offentlig", "beskyttet" (tilgjengelig med metoder i samme underklasse eller "pakke") eller "privat" (ingen tilgang fra andre klasser). Hvis det ikke gis noen erklæring, kan metoden nås av hvilken som helst klasse i samme pakke.

Utover objektkodeverifiseringen implementert av JCVM, implementerer Java Card 3-plattformen sikkerhetsmekanismer som gir applikasjonsnivå og sikkerhet for kommunikasjon.

Java Card-plattformen støtter en kodeisoleringsmekanisme. Kodeisolering sørger for at den lastede koden til et program ikke kolliderer med koden til andre applikasjoner.

Java Card-plattformen støtter kontekst- og applikasjonsisolering. Kontekstisolering sikrer at objektene som er opprettet, og som derfor er i besittelse av applikasjoner som opererer i samme kontekst, ikke får tilgang til applikasjoner fra en annen kontekst med mindre disse applikasjonene som har disse objektene eksplisitt gir grensesnitt for tilgang. Slike grensesnitt kalles vanlige grensesnitt og objekter som implementerer disse grensesnittene, kalt vanlige grensesnittobjekter , utgjør lovlige inngangspunkter for disse applikasjonene.

Rollebasert sikkerhet tillater applikasjonens sikkerhetspolicy å begrense tilgangen til programmets beskyttede ressurser. Restriksjonene er basert på egenskapene til applikasjonen som ber om tilgang, for eksempel dens identitet og identiteten til brukeren som tilgangsforsvaret blir bedt om.

Brukerautentisering er prosessen der en bruker beviser sin identitet à la carte. Denne autentiserte identiteten brukes deretter av plattformen til å utføre autorisasjonsbeslutninger, for eksempel de som kreves av rollebasert sikkerhet, for å få tilgang til beskyttede ressurser.

Autentisering av klientapplikasjon er prosessen der en klientapplikasjon beviser sin identitet til en serverapplikasjon. Denne autentiserte identiteten brukes deretter av serverapplikasjonen til å utføre autorisasjonsbeslutninger for å få tilgang til beskyttede ressurser.

Med Java Card-plattformen kan applikasjoner samhandle med eksterne applikasjoner gjennom sikker nettverkskommunikasjon (TLS, SSL).

En webapplikasjonsutvikler kan erklære integritet og konfidensialitet forutsetninger når du distribuerer en webapplikasjon. Applikasjonsutvikleren eller leverandøren kan også kreve at applikasjonen vert på en dedikert sikker port med åpne HTTPS-tilkoblinger.

Java Card-plattformen støtter en kryptografisk struktur. En applikasjonsutvikler eller leverandør kan velge kryptografialgoritmen som best oppfyller behovene til applikasjonen deres.

Programmeringskonsept

Prinsipp for programmering av en applet

En Java Card-applet er i samsvar med ISO 7816-standarden, med andre ord, den svarer på forespørsler på samme måte som den mottar dem i form av byte-kodekommandoer. Dette forenkler utviklingen av en applikasjon betraktelig, siden det ikke lenger er behov for koding på lavt nivå for sending og mottak av kommandoer. Denne delen er faktisk innkapslet i et Java-rammeverk.

Byte-kodekommandoer kalles APDUer (Application Protocol Data Unit). Disse er kodet forskjellig avhengig av sending og mottak.

En APDU-kommando som sendes fra leseren til Java-kortet er en serie på fem byte, eventuelt etterfulgt av et varierende antall byte, formatert som følger:

Et APDU-svar som sendes fra Java-kortet til leseren, er en serie byte, returnert som svar på en kommando og formatert som følger:

Når kommandoen på appletnivå kjøres normalt, er den returnerte statusverdien 90 00 .

Hvis en INS-instruksjon sørger for både sending og mottak av data, standardiserer Java Card et tofaset APDU-system. Først sendes APDU med for <Ln> et antall byte å sende, deretter når kortet svarer 0x91 <Le> (indikerer at <Le> byte er klare til å bli returnert av kortet, som svar når du bestiller) a Get Svar APDU sendes for å utløse mottak av disse utgående <Le> -byte.

Oppsummert er datafeltet (e) valgfritt i begge tilfeller, kontroll APDU og respons APDU. Derfor er det fire mulige tilfeller av kommunikasjon mellom klienten og Java Card Platform, versjon 2.2.2 (eller versjon 3.0.1 klassisk utgave):

Før du kan overføre en kommando til en applet distribuert i et Java-kort, er det nødvendig å velge den ved å sende en spesifikk APDU-kommando som angir identifikatoren til AID- applikasjonen . Søknadsidentifikatoren består av to deler. Den første på 5 byte, RID , er tildelt av ISO-standarden. Dette tilsvarer identifikatoren som er spesifikk for selskapet. Den andre, PIX, er sammensatt mellom 0 og 11 byte. Oppdraget av dette forblir ansvaret for selskapet som utvikler Java Card-applikasjonen.

For å programmere et Java-kort er det fem viktige trinn:

• Skrive av Java-kildekoden;
• Kodesammensetning;
• Konverter filer .classtil .cap ;
• Filbekreftelse .cap(valgfritt);
• Installasjon av filen .cappå Java-kortet.

Det sterke punktet med Java Card-utvikling er at de to første trinnene kan gjøres med et klassisk JAVA-utviklingsmiljø.

Her er et eksempel på kode som ganske enkelt returnerer tegnstrengen 'Hello World' på forespørselen som er koblet til 0x10- instruksjonen . I dette eksemplet består AID av verdiene RID = DA8EF6DD26 og PIX = 86E899.

Eksempel på Hello World-appleten .