Java-Karte - Java Card

Java Card bezeichnet eine Softwaretechnologie, mit der Java- basierte Anwendungen ( Applets ) sicher auf Smartcards und ähnlichen Geräten mit geringem Speicherbedarf ausgeführt werden können. Java Card ist die kleinste Java-Plattform für eingebettete Geräte. Java Card gibt dem Benutzer die Möglichkeit, die Geräte zu programmieren und anwendungsspezifisch zu gestalten. Es wird häufig in Geldautomatenkarten verwendet. Die erste Java Card wurde 1996 von der Kartenabteilung von Schlumberger eingeführt , die später mit Gemplus zu Gemalto fusionierte . Java Card-Produkte basieren auf den Spezifikationen der Java Card Platform, die von Sun Microsystems (später aTochtergesellschaft der Oracle Corporation ). Viele Java-Kartenprodukte setzen auch auf die GlobalPlatform-Spezifikationen für die sichere Verwaltung von Anwendungen auf der Karte (Download, Installation, Personalisierung, Löschung).

Die wichtigsten Designziele der Java Card-Technologie sind Portabilität und Sicherheit.

Portabilität

Java Card zielt darauf ab, eine Standard- Smartcard- Computerumgebung zu definieren , die es ermöglicht, dass dasselbe Java Card-Applet auf verschiedenen Smartcards ausgeführt wird, ähnlich wie ein Java-Applet auf verschiedenen Computern läuft. Wie in Java wird dies durch die Kombination einer virtuellen Maschine (der Java Card Virtual Machine) und einer wohldefinierten Laufzeitbibliothek erreicht, die das Applet weitgehend von Unterschieden zwischen Smartcards abstrahiert. Die Portabilität bleibt durch Probleme der Speichergröße, Leistung und Laufzeitunterstützung (zB für Kommunikationsprotokolle oder kryptografische Algorithmen) gemindert.

Sicherheit

Die Java Card-Technologie wurde ursprünglich entwickelt, um sensible Informationen, die auf Smartcards gespeichert sind, zu sichern . Die Sicherheit wird durch verschiedene Aspekte dieser Technologie bestimmt:

Datenverkapselung
Daten werden innerhalb der Anwendung gespeichert, und Java Card-Anwendungen werden in einer isolierten Umgebung (der Java Card VM) ausgeführt, die vom zugrunde liegenden Betriebssystem und der zugrunde liegenden Hardware getrennt ist.
Applet-Firewall
Im Gegensatz zu anderen Java VMs verwaltet eine Java Card VM normalerweise mehrere Anwendungen, von denen jede sensible Daten kontrolliert. Verschiedene Anwendungen werden daher durch eine Applet-Firewall voneinander getrennt, die den Zugriff von Datenelementen eines Applets auf ein anderes einschränkt und überprüft.
Kryptographie
Häufig verwendete symmetrische Schlüsselalgorithmen wie DES , Triple DES , AES und asymmetrische Schlüsselalgorithmen wie RSA , elliptische Kurvenkryptographie werden ebenso unterstützt wie andere kryptographische Dienste wie Signieren, Schlüsselgenerierung und Schlüsselaustausch.
Applet
Das Applet ist eine Zustandsmaschine, die nur eingehende Befehlsanforderungen verarbeitet und antwortet, indem sie Daten oder Antwortstatuswörter zurück an das Schnittstellengerät sendet.

Design

Auf Sprachebene ist Java Card eine genaue Untermenge von Java: Alle Sprachkonstrukte von Java Card existieren in Java und verhalten sich identisch. Dies geht so weit, dass als Teil eines Standard-Build-Zyklus ein Java Card-Programm von einem Java-Compiler in eine Java-Klassendatei kompiliert wird; die Klassendatei wird durch spezielle Tools für die Java Card-Plattform nachbearbeitet.

Viele Java-Sprachfeatures werden jedoch von Java Card nicht unterstützt (insbesondere die Typen char, double, float und long; der transientQualifizierer; Aufzählungen; Arrays mit mehr als einer Dimension; Finalisierung; Objektklonen; Threads). Darüber hinaus werden einige allgemeine Java-Features von vielen tatsächlichen Smartcards zur Laufzeit nicht bereitgestellt (insbesondere type int, der Standardtyp eines Java-Ausdrucks; und Garbage Collection von Objekten).

Bytecode

Der von der Java Card Virtual Machine ausgeführte Java Card-Bytecode ist eine funktionale Teilmenge des Java 2-Bytecodes , der von einer standardmäßigen Java Virtual Machine ausgeführt wird, jedoch mit einer anderen Codierung, um die Größe zu optimieren. Ein Java-Card-Applet verwendet somit typischerweise weniger Bytecode als das hypothetische Java-Applet, das durch Kompilieren desselben Java-Quellcodes erhalten wird. Dies spart Speicher, eine Notwendigkeit bei ressourcenbeschränkten Geräten wie Smartcards. Als Kompromiss beim Design gibt es keine Unterstützung für einige Java-Sprachfeatures (wie oben erwähnt) und Größenbeschränkungen. Es gibt Techniken zum Überwinden der Größenbeschränkungen, wie z. B. das Aufteilen des Codes der Anwendung in Pakete unterhalb der Grenze von 64  KiB .

Bibliothek und Laufzeit

Die standardmäßige Java Card-Klassenbibliothek und die Laufzeitunterstützung unterscheiden sich stark von der in Java, und die gemeinsame Teilmenge ist minimal. Beispielsweise wird die Java Security Manager-Klasse in Java Card nicht unterstützt, wo Sicherheitsrichtlinien von der Java Card Virtual Machine implementiert werden; und Transienten (nicht persistente, schnelle RAM-Variablen, die Klassenmitglieder sein können) werden über eine Java Card-Klassenbibliothek unterstützt, während sie in Java native Sprachunterstützung bieten.

Spezielle Features

Die Java Card-Laufzeit und die virtuelle Maschine unterstützen auch Funktionen, die für die Java Card-Plattform spezifisch sind:

Beharrlichkeit
Bei Java Card werden Objekte standardmäßig im persistenten Speicher gespeichert (RAM ist auf Smartcards sehr knapp und wird nur für temporäre oder sicherheitskritische Objekte verwendet). Die Laufzeitumgebung sowie der Bytecode wurden daher angepasst, um persistente Objekte zu verwalten.
Atomarität
Da Smartcards extern mit Strom versorgt werden und auf persistentem Speicher angewiesen sind, müssen persistente Updates atomar sein. Die einzelnen Schreiboperationen, die von einzelnen Bytecode-Befehlen und API-Methoden ausgeführt werden, sind daher garantiert atomar, und die Java Card Runtime enthält einen eingeschränkten Transaktionsmechanismus.
Applet-Isolierung
Die Java Card Firewall ist ein Mechanismus, der die verschiedenen Applets, die auf einer Karte vorhanden sind, voneinander isoliert. Es enthält auch einen Freigabemechanismus, der es einem Applet ermöglicht, ein Objekt explizit anderen Applets zur Verfügung zu stellen.

Entwicklung

Die in einem praktischen Java Card-Programm verwendeten Codierungstechniken unterscheiden sich erheblich von denen, die in einem Java-Programm verwendet werden. Dass Java Card jedoch eine genaue Teilmenge der Java-Sprache verwendet, beschleunigt die Lernkurve und ermöglicht die Verwendung einer Java-Umgebung zum Entwickeln und Debuggen eines Java Card-Programms (Vorsicht: Auch wenn das Debuggen mit Java-Bytecode erfolgt, stellen Sie sicher, dass die Klassendatei passt die Einschränkungen der Java Card-Sprache an, indem sie in Java Card-Bytecode konvertiert wird und testen Sie frühzeitig in einer echten Java Card-Smartcard, um eine Vorstellung von der Leistung zu erhalten); ferner kann man sowohl den Java Card-Code für die in eine Smartcard einzubettende Anwendung als auch eine Java-Anwendung, die sich im Host befindet und die Smartcard verwendet, ausführen und debuggen, die alle gemeinsam in derselben Umgebung arbeiten.

Versionen

Oracle hat mehrere Java Card-Plattformspezifikationen veröffentlicht und stellt SDK-Tools für die Anwendungsentwicklung bereit. Normalerweise implementieren Smartcard-Anbieter nur eine Teilmenge von Algorithmen, die im Ziel der Java Card-Plattform angegeben sind, und die einzige Möglichkeit, herauszufinden, welche Teilmenge der Spezifikation implementiert ist, besteht darin, die Karte zu testen.

  • Version 3.1 (17.12.2018)
    • Konfigurierbare Unterstützung für die Generierung von Schlüsselpaaren, Unterstützung für benannte elliptische Kurven, Unterstützung neuer Algorithmen und Operationen, zusätzliche AES-Modi und chinesische Algorithmen hinzugefügt.
  • Version 3.0.5 (03.06.2015)
    • Oracle SDK: Java Card Classic Development Kit 3.0.5u1 (03.06.2015)
    • Unterstützung für modulare Diffie-Hellman-Exponentiation, Domain Data Conservation for Diffie-Hellman, Elliptic Curve und DSA-Schlüssel, RSA-3072, SHA3, Plain ECDSA, AES CMAC, AES CTR hinzugefügt.
  • Version 3.0.4 (06.08.2011)
    • Oracle SDK: Java Card Classic Development Kit 3.0.4 (06.11.2011)
    • Unterstützung für DES MAC8 ISO9797 hinzugefügt.
  • Version 3.0.1 (15.06.2009)
    • Oracle SDK: Java Card Development Kit 3.0.3 RR (11.11.2010)
    • Unterstützung für SHA-224, SHA-2 für alle Signaturalgorithmen hinzugefügt.
  • Version 2.2.2 (03.2006)
    • Oracle SDK: Java Card Development Kit 2.2.2 (03.2006)
    • Unterstützung für SHA-256, SHA-384, SHA-512, ISO9796-2, HMAC, Korean SEED MAC NOPAD, Korean SEED NOPAD hinzugefügt.
  • Version 2.2.1 (10.2003)
    • Oracle SDK: Java Card Development Kit 2.2.1 (10.2003)
  • Version 2.2 (11.2002)
    • Unterstützung für AES-Kryptografie-Schlüsselkapselung, CRC-Algorithmen, Elliptic Curve-Kryptografie-Schlüsselkapselung, Diffie-Hellman-Schlüsselaustausch mit ECC, ECC-Schlüssel für binäre Polynomkurven und für Primzahlkurven, AES, ECC und RSA mit variablen Schlüssellängen hinzugefügt.
  • Version 2.1.1 (18.05.2000)
    • Oracle SDK: Java Card Development Kit 2.1.2 (05.04.2001)
    • Unterstützung für RSA ohne Padding hinzugefügt.
  • Version 2.1 (07.06.1999)

Java-Karte 3.0

Die Version 3.0 der Java Card-Spezifikation (Entwurf März 2008) ist in zwei Editionen unterteilt: die Classic Edition und die Connected Edition .

  • Die Classic Edition (derzeit in der im Juni 2015 veröffentlichten Version 3.0.5) ist eine Weiterentwicklung der Java Card Platform Version 2 (die letzte Version 2.2.2 wurde im März 2006 veröffentlicht), die traditionelle Karten-Applets auf ressourcenbeschränkten Geräten wie z als Smartcards. Ältere Applets sind im Allgemeinen mit neueren Classic Edition-Geräten kompatibel, und Applets für diese neueren Geräte können mit älteren Geräten kompatibel sein, wenn sie sich nicht auf neue Bibliotheksfunktionen beziehen. Smart Cards, die Java Card Classic Edition implementieren, wurden von mehreren Anbietern sicherheitszertifiziert und sind im Handel erhältlich.
  • Die Connected Edition (derzeit in der im Dezember 2009 veröffentlichten Version 3.0.2) zielt darauf ab, eine neue virtuelle Maschine und eine verbesserte Ausführungsumgebung mit netzwerkorientierten Funktionen bereitzustellen. Anwendungen können als klassische Karten-Applets entwickelt werden, die von APDU- Befehlen angefordert werden , oder als Servlets, die HTTP verwenden , um webbasierte Kommunikationsschemata ( HTML , REST , SOAP ...) mit der Karte zu unterstützen. Die Laufzeit verwendet eine Teilmenge des Java (1.)6-Bytecodes, ohne Gleitkomma; Es unterstützt flüchtige Objekte ( Garbage Collection ), Multithreading , Kommunikationsmöglichkeiten zwischen Anwendungen, Persistenz , Transaktionen , Kartenverwaltungsfunktionen ... in der vorliegenden Wikipedia-Seite) schließt die Connected Edition oft implizit aus .

Siehe auch

Verweise

Externe Links