Grundlegendes zu Java Card 2.0

Dieser Artikel beginnt mit einem Überblick über Smartcards und einem kurzen Überblick über ISO 7816, den Smartcard-Standard. Angesichts des Hintergrunds zu Smartcards in früheren Java Developer- Spalten beginnt diese Ausgabe mit einer Antwort auf die Frage "Was ist eine Java-Karte?". und eine Übersicht über die Java Card-Systemarchitektur. Als Nächstes konzentrieren wir uns auf die vielen spezifischen Probleme der Java-Karte, einschließlich des Lebenszyklus der Java-Karte. die Java Card 2.0-Sprachuntermenge und die API-Bibliotheksklassen; und Java Card Sicherheit. Anschließend werden wir die Java Card-Laufzeitumgebung erläutern und zeigen, wie eine Java Card ausgeführt wird. Wir schließen mit einem anschaulichen Beispiel: Eine elektronische Brieftaschenanwendung, die nur für die Java-Karte geschrieben wurde.

Ab hier beziehen sich alle Verweise auf Java Card implizit auf Java Card 2.0.

Was ist eine Smartcard?

Identisch mit der Größe einer Kreditkarte speichert und verarbeitet eine Smartcard Informationen über die elektronischen Schaltkreise, die in Silizium im Kunststoffsubstrat ihres Körpers eingebettet sind. Es gibt zwei grundlegende Arten von Smartcards: Eine intelligente Smartcard enthält einen Mikroprozessor und bietet Lese-, Schreib- und Berechnungsfunktionen wie ein kleiner Mikrocomputer. Eine Speicherkarte hingegen hat keinen Mikroprozessor und ist nur zur Informationsspeicherung gedacht. Eine Speicherkarte verwendet eine Sicherheitslogik, um den Zugriff auf den Speicher zu steuern.

Alle Smartcards enthalten drei Arten von Speicher: dauerhafter nicht veränderbarer Speicher; beständiges veränderliches Gedächtnis; und nicht persistenter veränderlicher Speicher. ROM, EEPROM und RAM sind die am häufigsten verwendeten Speicher für die drei jeweiligen Typen in den aktuellen Smartcards. Permanenter Speicher wird auch als nichtflüchtiger Speicher bezeichnet. In diesem Artikel werden die Begriffe persistent und nichtflüchtig austauschbar verwendet.

ISO 7816 Teil 1-7, definiert von der International Standard Organization, enthält eine Reihe von Standards, die verschiedene Aspekte von Smartcards abdecken. ISO 7816 besteht aus:

  • Physikalische Eigenschaften (Teil 1)

  • Abmessungen und Position der Kontakte (Teil 2)

  • Elektronische Signale und Übertragungsprotokolle (Teil 3)

  • Branchenübergreifende Befehle für den Austausch (Teil 4)

  • Anwendungskennungen (Teil 5)

  • Branchenübergreifende Datenelemente (Teil 6)

  • Branchenübergreifende Befehle für SCQL (Teil 7)

Das folgende Diagramm zeigt die physikalischen Eigenschaften einer Smartcard, die in ISO 7816, Teil 1 definiert sind.

Weitere Informationen zu ISO 7816 und Smartcards finden Sie unter "Smartcards: Eine Grundierung".

Normalerweise enthält eine Smartcard kein Netzteil, kein Display oder keine Tastatur. Es interagiert mit der Außenwelt über die serielle Kommunikationsschnittstelle über seine acht Kontaktpunkte. Die Abmessungen und die Position der Kontakte werden in Teil 2 von ISO 7816 behandelt. Dieses Diagramm zeigt die Kontakte auf einer Smartcard.

Eine Smartcard wird in ein Kartenakzeptanzgerät (CAD) eingesetzt, das möglicherweise eine Verbindung zu einem anderen Computer herstellt. Andere Begriffe, die für das Kartenakzeptanzgerät verwendet werden , sind Terminal , Lesegerät und IFD (Schnittstellengerät). Sie alle bieten die gleichen Grundfunktionen, nämlich die Stromversorgung der Karte und den Aufbau einer datenführenden Verbindung.

Wenn zwei Computer miteinander kommunizieren, tauschen sie Datenpakete aus, die nach einer Reihe von Protokollen erstellt werden. In ähnlicher Weise sprechen Smartcards mit ihren eigenen Datenpaketen - APDU (Application Protocol Data Units) genannt - mit der Außenwelt . APDU enthält entweder einen Befehl oder eine Antwortnachricht. In der Kartenwelt wird das Master-Slave-Modell verwendet, bei dem eine Smartcard immer die passive Rolle spielt. Mit anderen Worten, eine Smartcard wartet immer auf eine Befehls-APDU von einem Terminal. Anschließend führt es die in der APDU angegebene Aktion aus und antwortet dem Terminal mit einer Antwort-APDU. Befehls-APDUs und Antwort-APDUs werden alternativ zwischen einer Karte und einem Terminal ausgetauscht.

Die folgenden Tabellen veranschaulichen die Befehls- und Antwort-APDU-Formate. Die APDU-Struktur ist in ISO 7816, Teil 4 beschrieben.

Befehl APDU
Obligatorischer Header Bedingter Körper
CLA INS P1 P2 Lc Datenfeld Le

Der Header codiert den ausgewählten Befehl. Es besteht aus vier Feldern: Klasse (CLA), Anweisung (INS) und Parameter 1 und 2 (P1 und P2). Jedes Feld enthält 1 Byte:

  • CLA: Klassenbyte. In vielen Smartcards wird dieses Byte verwendet, um eine Anwendung zu identifizieren.

  • INS: Anweisungsbyte. Dieses Byte gibt den Befehlscode an.

  • P1-P2: Parameterbytes. Diese bieten eine weitere Qualifizierung für den APDU-Befehl.

Lc bezeichnet die Anzahl der Bytes im Datenfeld des Befehls APDU; Le bezeichnet die maximale Anzahl von Bytes, die im Datenfeld der folgenden Antwort-APDU erwartet werden.

Antwort APDU
Bedingter Körper Obligatorischer Trailer
Datenfeld SW1 SW2

Die Statusbytes SW1 und SW2 bezeichnen den Verarbeitungsstatus des Befehls APDU in einer Karte.

Was ist eine Java-Karte?

Eine Java-Karte ist eine Smartcard, mit der Java-Programme ausgeführt werden können. Die Java Card 2.0-Spezifikation wurde unter //www.javasoft.com/javacard veröffentlicht. Es enthält detaillierte Informationen zum Erstellen der virtuellen Java Card-Maschine und der API (Application Programming Interface) in Smartcards. Die minimale Systemanforderung beträgt 16 Kilobyte Nur-Lese-Speicher (ROM), 8 Kilobyte EEPROM und 256 Byte Direktzugriffsspeicher (RAM).

Die Systemarchitektur auf der Java-Karte ist in der folgenden Abbildung dargestellt.

Wie in der Abbildung gezeigt, basiert die Java Card VM auf einer bestimmten Implementierung einer integrierten Schaltung (IC) und eines nativen Betriebssystems. Die JVM-Schicht verbirgt die proprietäre Technologie des Herstellers mit einer gemeinsamen Sprache und Systemschnittstelle. Das Java Card-Framework definiert eine Reihe von API-Klassen (Application Programming Interface) zum Entwickeln von Java Card-Anwendungen und zum Bereitstellen von Systemdiensten für diese Anwendungen. Eine bestimmte Branche oder ein bestimmtes Unternehmen kann Zusatzbibliotheken bereitstellen, um einen Dienst bereitzustellen oder das Sicherheits- und Systemmodell zu verfeinern. Java Card-Anwendungen werden als Applets bezeichnet . Auf einer Karte können sich mehrere Applets befinden. Jedes Applet wird eindeutig durch seine AID (Application Identifier) ​​identifiziert, wie in ISO 7816, Teil 5 definiert.

Ein wichtiger Punkt, den Sie beachten sollten, ist, was Smartcards nicht sind : Sie sind keine PCs. Sie haben begrenzte Speicherressourcen und Rechenleistung. Benutzer sollten sich Java Card 2.0 nicht einfach als abgespeckte Version des JDK vorstellen.

Die Lebensdauer einer Java-Karte

Die Lebensdauer der Java-Karte beginnt, wenn das native Betriebssystem, die Java-Karten-VM, API-Klassenbibliotheken und optional Applets in das ROM gebrannt werden. Dieser Vorgang des Schreibens der permanenten Komponenten in den nicht veränderlichen Speicher eines Chips zum Ausführen eingehender Befehle wird als Maskierung bezeichnet .

Bevor eine Java-Karte in Ihrer Brieftasche landet, muss sie initialisiert und personalisiert werden. Die Initialisierung bezieht sich auf das Laden allgemeiner Daten in den nichtflüchtigen Speicher einer Karte. Diese Daten sind über eine große Anzahl von Karten hinweg identisch und nicht individuell. Ein Beispiel könnte der Name des Emittenten oder des Herstellers sein.

Der nächste Schritt, die Personalisierung, besteht darin, einer Person eine Karte zuzuweisen. Dies kann durch physische Personalisierung oder durch elektronische Personalisierung geschehen. Physische Personalisierung bezieht sich auf das Prägen oder Lasergravieren Ihres Namens und Ihrer Kartennummer auf die Kunststoffoberfläche einer Karte. Unter elektronischer Personalisierung versteht man das Laden persönlicher Daten in den nichtflüchtigen Speicher einer Karte, z. B. Ihren persönlichen Schlüssel, Namen und Ihre PIN-Nummer.

Initialisierung und Personalisierung variieren von Anbieter zu Anbieter und von Emittent zu Emittent. In beiden Fällen wird häufig das EEPROM (eine Art nichtflüchtiger Speicher) zum Speichern von Daten verwendet.

Zu diesem Zeitpunkt ist die Java-Karte einsatzbereit. Sie können eine Java-Karte von einem Aussteller erhalten oder bei einem Einzelhändler kaufen. Von einem Einzelhändler verkaufte Karten sind universell einsetzbar. In diesem Fall wird die Personalisierung häufig weggelassen.

Jetzt können Sie Ihre Java-Karte in ein Lesegerät einlegen und APDU-Befehle an die auf der Karte befindlichen Applets senden oder weitere Applets oder Daten auf die Karte herunterladen.

Eine Java-Karte bleibt aktiv, bis sie aufgrund eines nicht behebbaren Fehlers abgelaufen oder blockiert ist.

Lebensdauer einer virtuellen Java Card-Maschine

Im Gegensatz zur Java Virtual Machine (JVM) auf einem PC oder einer Workstation wird die Java Card Virtual Machine für immer ausgeführt.

Die meisten auf der Karte gespeicherten Informationen müssen auch dann erhalten bleiben, wenn die Stromversorgung unterbrochen wird, dh wenn die Karte aus dem Lesegerät entfernt wird. Die Java Card VM erstellt Objekte im EEPROM, um die persistenten Informationen zu speichern. Die Ausführungslebensdauer der Java Card VM entspricht der Lebensdauer der Karte. Wenn die Stromversorgung nicht bereitgestellt wird, wird die VM in einem unendlichen Taktzyklus ausgeführt.

Die Lebensdauer von Java Card-Applets und -Objekten

Die Lebensdauer eines Applets beginnt, wenn es ordnungsgemäß installiert und in der Registrierungstabelle des Systems registriert ist, und endet, wenn es aus der Tabelle entfernt wird. Der Speicherplatz eines entfernten Applets kann jedoch wiederverwendet werden oder nicht, je nachdem, ob die Speicherbereinigung auf der Karte implementiert ist. Ein Applet auf einer Karte befindet sich in einem inaktiven Stadium, bis es vom Terminal explizit ausgewählt wird.

Objekte werden im persistenten Speicher erstellt (z. B. EEPROM). Sie können verloren gehen oder Müll sammeln, wenn andere persistente Objekte nicht auf sie verweisen. Das Schreiben in das EEPROM ist jedoch tausendmal langsamer als in das RAM.

Auf einige Objekte wird häufig zugegriffen, und der Inhalt ihrer Felder muss nicht dauerhaft sein. Die Java-Karte unterstützt vorübergehende (temporäre) Objekte im RAM. Sobald ein Objekt als vorübergehend deklariert wurde, kann sein Inhalt nicht mehr in den persistenten Speicher verschoben werden.

Teilmenge der Java Card 2.0-Sprache

Java Card-Programme sind natürlich in Java geschrieben. Sie werden mit gängigen Java-Compilern kompiliert. Aufgrund begrenzter Speicherressourcen und Rechenleistung werden nicht alle in der Java-Sprachspezifikation definierten Sprachfunktionen auf der Java-Karte unterstützt. Insbesondere unterstützt die Java-Karte nicht:

  • Dynamisches Laden von Klassen

  • Sicherheitsmanager

  • Threads und Synchronisation

  • Klonen von Objekten

  • Finalisierung

  • Große primitive Datentypen (float, double, long und char)

Es ist keine Überraschung, dass Schlüsselwörter, die diese Funktionen unterstützen, auch in der Sprache weggelassen werden. VM-Implementierer unterstützen möglicherweise 32-Bit-Integer-Typ oder native Methoden für Applets nach der Ausgabe, wenn sie an einer fortschrittlicheren Smartcard mit mehr Speicher arbeiten. Applets nach der Ausstellung sind Applets, die auf einer Java-Karte installiert werden, nachdem die Karte an einen Karteninhaber ausgegeben wurde.

Das Java Card 2.0-Framework

Smartcards sind seit 20 Jahren auf dem Markt und die meisten von ihnen sind im Allgemeinen mit ISO 7816 Parts 1-7 und / oder EMV kompatibel. Wir haben uns bereits mit ISO 7816 befasst. Was ist EMV? Der von Europay, MasterCard und Visa definierte EMV-Standard basiert auf der Normreihe ISO 7816 mit zusätzlichen proprietären Funktionen, um den spezifischen Anforderungen der Finanzbranche gerecht zu werden. Das Java Card Framework unterstützt Smartcard-Systeme und -Anwendungen auf einfache Weise. Es verbirgt die Details der Smartcard-Infrastruktur und bietet Entwicklern von Java Card-Anwendungen eine relativ einfache und unkomplizierte Programmierschnittstelle.

Das Java Card Framework enthält vier Pakete:

Paketnamen Beschreibung
javacard.framework Dies ist das Kernpaket auf der Karte. Es definiert Klassen wie und , die die Grundbausteine ​​für Java Card-Programme darstellen , und , die Java Card-Programmen Laufzeit- und Systemdienste bieten, wie z. B. APDU-Behandlung und Objektfreigabe
javacardx.framework Dieses Paket bietet ein objektorientiertes Design für ein ISO 7816-4-kompatibles Dateisystem. Es unterstützt Elementardateien (EF), dedizierte Dateien (DF) und dateiorientierte APDUs gemäß ISO7816
javacardx.crypto und javacardx.cryptoEnc Diese beiden Pakete unterstützen kryptografische Funktionen, die für Smartcards erforderlich sind

Java Cardx- Pakete sind gemäß der Java-Namenskonvention Erweiterungen des Java Card-Frameworks. Es ist nicht erforderlich, dass Sie sie auf der Karte unterstützen.

Java-Kartensicherheit

Java-Applets unterliegen Java-Sicherheitsbeschränkungen. Das Sicherheitsmodell von Java-Kartensystemen unterscheidet sich jedoch in vielerlei Hinsicht von Standard-Java.

Die Security Manager-Klasse wird auf Java Card nicht unterstützt. Sprachsicherheitsrichtlinien werden von der virtuellen Maschine implementiert.

Java-Applets erstellen Objekte, die Daten speichern und bearbeiten. Ein Objekt gehört dem Applet, das es erstellt. Obwohl ein Applet möglicherweise auf ein Objekt verweist, kann es die Methoden des Objekts nicht aufrufen, es sei denn, es besitzt das Objekt oder das Objekt wird explizit freigegeben. Ein Applet kann jedes seiner Objekte für ein bestimmtes Applet oder für alle Applets freigeben.

Ein Applet ist eine unabhängige Entität innerhalb einer Java-Karte. Auswahl, Ausführung und Funktionalität werden von anderen Applets auf derselben Karte nicht beeinflusst.

Wie die Dinge in einer Java-Karte zusammenarbeiten

Innerhalb einer Java Card bezieht sich JCRE (Java Card Runtime Environment) auf die virtuelle Java Card-Maschine und die Klassen im Java Card Framework. Jedes Applet innerhalb einer Java-Karte ist einer von JCRE zugewiesenen eindeutigen AID zugeordnet.

Nachdem ein Applet korrekt in den dauerhaften Speicher der Karte geladen und mit dem Java Card Framework und anderen Bibliotheken auf der Karte verknüpft wurde, ruft JCRE die Installationsmethode des Applets als letzten Schritt im Applet-Installationsprozess auf. Eine öffentliche statische Methode installmuss von einer Applet-Klasse implementiert werden, um eine Instanz des Applets zu erstellen und bei JCRE zu registrieren. Da der Speicher begrenzt ist, empfiehlt es sich an dieser Stelle, die Objekte zu erstellen und zu initialisieren, die das Applet während seiner Lebensdauer benötigt.