Java-kort - Java Card

Java platform udgaver
Duke (Java maskot) waving.svg

Java-kort refererer til en softwareteknologi, der gør det muligt at køre Java- baserede applikationer ( applets ) sikkert på smartkort og lignende enheder med lille hukommelsesfodaftryk. Java-kort er den mindste af Java-platforme, der er målrettet mod integrerede enheder. Java Card giver brugeren mulighed for at programmere enhederne og gøre dem applikationsspecifikke. Det er meget brugt i ATM- kort. Det første Java Card blev introduceret i 1996 af Schlumbergers kortafdeling, som senere fusionerede med Gemplus og dannede Gemalto . Java Card-produkter er baseret på Java Card Platform-specifikationerne udviklet af Sun Microsystems (senere endatterselskab af Oracle Corporation ). Mange Java-kortprodukter er også afhængige af GlobalPlatform-specifikationerne til sikker styring af applikationer på kortet (download, installation, personalisering, sletning).

De vigtigste designmål for Java Card-teknologien er bærbarhed og sikkerhed.

Bærbarhed

Java Card sigter mod at definere et standardmiljø for computerkortcomputering, der tillader den samme Java Card-applet at køre på forskellige chipkort, ligesom en Java-applet kører på forskellige computere. Som i Java opnås dette ved hjælp af kombinationen af ​​en virtuel maskine (Java Card Virtual Machine) og et veldefineret runtime-bibliotek, som i vid udstrækning abstraherer appleten fra forskelle mellem smartkort. Bærbarhed mindskes fortsat af problemer med hukommelsesstørrelse, ydeevne og runtime-support (f.eks. Til kommunikationsprotokoller eller kryptografiske algoritmer).

Sikkerhed

Java-kortteknologi blev oprindeligt udviklet med det formål at sikre følsom information gemt på smartkort . Sikkerhed bestemmes af forskellige aspekter af denne teknologi:

Datakapsling
Data gemmes i applikationen, og Java Card-applikationer udføres i et isoleret miljø (Java Card VM), adskilt fra det underliggende operativsystem og hardware.
Applet-firewall
I modsætning til andre Java-VM'er styrer en Java-kort-VM normalt flere applikationer, som hver især kontrollerer følsomme data. Forskellige applikationer adskilles derfor fra hinanden ved hjælp af en applet-firewall, som begrænser og kontrollerer adgangen til dataelementerne i en applet til en anden.
Kryptografi
Almindeligt anvendte symmetriske nøgealgoritmer som DES , Triple DES , AES og asymmetriske nøgealgoritmer som RSA , elliptisk kurve-kryptografi understøttes såvel som andre kryptografiske tjenester som signering, nøglegenerering og nøgleudveksling.
Applet
Appleten er en tilstandsmaskine, der kun behandler indgående kommandoanmodninger og reagerer ved at sende data eller svarstatusord tilbage til interfaceenheden.

Design

På sprogniveau er Java-kort en præcis delmængde af Java: alle sprogkonstruktioner af Java-kort findes i Java og opfører sig identisk. Dette går til det punkt, at et Java Card-program som en del af en standard build-cyklus kompileres til en Java-klassefil af en Java-compiler; klassefilen efterbehandles af værktøjer, der er specifikke for Java Card-platformen.

Imidlertid understøttes mange Java-sprogfunktioner ikke af Java-kort (især typer char, dobbelt, float og long; transientkvalifikatoren; enums; arrays med mere end en dimension; finalisering; objektkloning; tråde). Desuden leveres nogle almindelige træk ved Java ikke ved kørsel af mange faktiske smartkort (især type int, som er standardtypen for et Java-udtryk og affaldssamling af objekter).

Bytecode

Java Card bytecode kørt af Java Card Virtual Machine er en funktionel delmængde af Java 2 bytecode, der køres af en standard Java Virtual Machine, men med en anden kodning for at optimere til størrelse. En Java-kort-applet bruger således typisk mindre bytecode end den hypotetiske Java-applet, der opnås ved at kompilere den samme Java-kildekode. Dette sparer hukommelse, en nødvendighed i ressourcebegrænsede enheder som smartkort. Som designkompromis er der ingen understøttelse af nogle Java-sprogfunktioner (som nævnt ovenfor) og størrelsesbegrænsninger. Der findes teknikker til at overvinde størrelsesbegrænsningerne, såsom at opdele applikationens kode i pakker under 64  KiB- grænsen.

Bibliotek og runtime

Standard Java Card-klassebibliotek og understøttelse af runtime adskiller sig meget fra det i Java, og den fælles delmængde er minimal. F.eks. Understøttes klassen Java Security Manager ikke i Java Card, hvor sikkerhedspolitikker implementeres af Java Card Virtual Machine; og transienter (ikke-vedvarende, hurtige RAM-variabler, der kan være klassemedlemmer) understøttes via et Java Card-klassebibliotek, mens de har understøttet modersmål i Java.

Specifikke funktioner

Java-kortets runtime og den virtuelle maskine understøtter også funktioner, der er specifikke for Java Card-platformen:

Udholdenhed
Med Java-kort er objekter som standard gemt i vedvarende hukommelse (RAM er meget knappe på smartkort, og det bruges kun til midlertidige eller sikkerhedsfølsomme objekter). Runtime-miljøet såvel som bytecoden er derfor blevet tilpasset til at styre vedvarende objekter.
Atomicitet
Da smartkort er eksternt drevet og er afhængige af vedvarende hukommelse, skal vedvarende opdateringer være atomare. De individuelle skriveoperationer, der udføres af individuelle bytekodeinstruktioner og API-metoder, er derfor garanteret atomare, og Java Card Runtime inkluderer en begrænset transaktionsmekanisme.
Appletisolering
Java Card-firewall er en mekanisme, der isolerer de forskellige applets, der findes på et kort, fra hinanden. Det inkluderer også en delingsmekanisme, der giver en applet mulighed for eksplicit at gøre et objekt tilgængeligt for andre applets.

Udvikling

Kodningsteknikker, der anvendes i et praktisk Java Card-program, adskiller sig markant fra dem, der bruges i et Java-program. At Java-kort bruger en præcis delmængde af Java-sproget, fremskynder stadig indlæringskurven og gør det muligt at bruge et Java-miljø til at udvikle og debugge et Java Card-program (advarsel: selvom fejlretning sker med Java-bytecode, skal du sørge for, at klassefilen passer til begrænsningen af ​​Java Card-sprog ved at konvertere det til Java Card bytecode; og test i et ægte Java Card-smartcard tidligt for at få en idé om ydeevnen); endvidere kan man køre og fejle både Java-kortkoden for, at applikationen skal indlejres i et chipkort, og en Java-applikation, der vil være i værten ved hjælp af chipkortet, og alle arbejder sammen i samme miljø.

Versioner

Oracle har frigivet flere Java Card-platformspecifikationer og leverer SDK-værktøjer til applikationsudvikling. Normalt implementerer chipkortleverandører kun et undersæt af algoritmer, der er specificeret i Java Card-platformmålet, og den eneste måde at finde ud af, hvilken undersæt af specifikation der er implementeret, er at teste kortet.

  • Version 3.1 (17.12.2018)
    • Tilføjet konfigurerbar support til generering af nøglepar, understøttelse af elliptiske kurver, nye algoritmer og understøttelse af operationer, yderligere AES-tilstande og kinesiske algoritmer.
  • Version 3.0.5 (03.06.2015)
    • Oracle SDK: Java Card Classic Development Kit 3.0.5u1 (03.06.2015)
    • Tilføjet understøttelse af Diffie-Hellman modulær eksponentiering, Domain Data Conservation for Diffie-Hellman, Elliptic Curve og DSA nøgler, RSA-3072, SHA3, almindelig ECDSA, AES CMAC, AES CTR.
  • Version 3.0.4 (06.08.2011)
    • Oracle SDK: Java Card Classic Development Kit 3.0.4 (06.11.2011)
    • Tilføjet support til DES MAC8 ISO9797.
  • Version 3.0.1 (15.06.2009)
    • Oracle SDK: Java Card Development Kit 3.0.3 RR (11.11.2010)
    • Tilføjet understøttelse af SHA-224, SHA-2 for alle signaturalgoritmer.
  • Version 2.2.2 (03.2006)
    • Oracle SDK: Java Card Development Kit 2.2.2 (03.2006)
    • Tilføjet understøttelse af SHA-256, SHA-384, SHA-512, ISO9796-2, HMAC, Korean SEED MAC NOPAD, Korean SEED NOPAD.
  • Version 2.2.1 (10.2003)
    • Oracle SDK: Java Card Development Kit 2.2.1 (10.2003)
  • Version 2.2 (11.2002)
    • Tilføjet understøttelse af AES-kryptografi-nøgleindkapsling, CRC-algoritmer, Elliptic Curve Cryptography-nøgleindkapsling, Diffie-Hellman-nøgleudveksling ved hjælp af ECC, ECC-nøgler til binære polynomialkurver og til primært heltalskurver, AES, ECC og RSA med variable nøgellængder.
  • Version 2.1.1 (18.05.2000)
    • Oracle SDK: Java Card Development Kit 2.1.2 (05.04.2001)
    • Tilføjet support til RSA uden polstring.
  • Version 2.1 (07.06.1999)

Java-kort 3.0

Version 3.0 af Java Card-specifikationen (udkast udgivet i marts 2008) er adskilt i to udgaver: Classic Edition og Connected Edition .

  • Den klassiske udgave (pt versionen 3.0.5 udgivet i juni 2015) er en videreudvikling af Java Card Platform version 2 (som sidste version 2.2.2 blev udgivet i marts 2006), som understøtter de traditionelle kort applets på ressource-begrænset enheder sådanne som Smart Cards. Ældre applets er generelt kompatible med nyere Classic Edition-enheder, og applets til disse nyere enheder kan være kompatible med ældre enheder, hvis de ikke henviser til nye biblioteksfunktioner. Smart Cards, der implementerer Java Card Classic Edition, er sikkerhedscertificeret af flere leverandører og er kommercielt tilgængelige.
  • Den tilsluttede Edition (i øjeblikket ved versionen 3.0.2 frigivet i december 2009) har til formål at give en ny virtuel maskine og en forbedret udførelse miljø med netværksorienterede funktioner. Applikationer kan udvikles som klassiske kortapplets, der anmodes om af APDU- kommandoer eller som servlets, der bruger HTTP til at understøtte webbaserede kommunikationsplaner ( HTML , REST , SOAP ...) med kortet. Runtime bruger et undersæt af Java (1.) 6 bytecode uden flydende punkt; det understøtter flygtige objekter ( affaldsindsamling ), multithreading , kommunikationsfaciliteter mellem applikationer, vedholdenhed , transaktioner , kortadministrationsfaciliteter ... Fra og med 2017 har der været lidt anvendelse i kommercielt tilgængelige Smart Cards, så meget at henvisning til Java-kort (inklusive i den nuværende Wikipedia-side) ekskluderer ofte implicit Connected Edition .

Se også

Referencer

eksterne links