DE102018115758A1

DE102018115758A1 - Sicherheit von Java-Card-Schlüsselobjekten

Info

Publication number: DE102018115758A1
Application number: DE102018115758.4A
Authority: DE
Inventors: Kalaiselvam Suruddaiyan
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2018-06-29
Filing date: 2018-06-29
Publication date: 2020-01-02

Abstract

Es wird ein Verfahren zum Betrieb einer Java-Card-Umgebung bereitgestellt, umfassend: Erzeugen eines Schlüsselobjekts, wobei eine derartige Erzeugung mindestens einen zusätzlichen Sicherheitsparameter umfasst. Auch wird eine entsprechende Sicherheitsvorrichtung vorgeschlagen.

Description

Ausführungsformen der vorliegenden Erfindung betreffen Schlüsselobjekte in einer Java-Card-Umgebung.
Java-Card bezieht sich auf eine Softwaretechnologie, die es Java-basierten Anwendungen (Applets) gestattet, auf Smart Cards und ähnlichen Vorrichtungen geringer Speicherkapazität sicher ausgeführt zu werden. Java Card ist eine sehr kleine Java-Plattform, die für eingebettete Vorrichtungen bestimmt ist. Java Card verleiht dem Benutzer die Fähigkeit, die Vorrichtungen zu programmieren und sie anwendungsspezifisch zu machen. Es ist in SIM-Karten (in GSM-Mobiltelefonen genutzt), ID-Karten, Bankkarten oder dergleichen weit verbreitet. Für weitere Einzelheiten wird auf https://en.wikipedia.org/wiki/Java_Card verwiesen.
Java-Card-Systeme sind bekannt und werden in verschiedenen Anwendungen immer öfter genutzt, z.B. Anwendungsfälle, bei denen mehr als eine einzelne Anwendung von einer Chipkarte (auch als „Smart Card“ bezeichnet) unterstützt wird. In derartigen Szenarios wird Sicherheit ein immer wichtigeres Thema. Dies gilt insbesondere für Schlüssel, die von einer Anwendung genutzt werden, die auf der Chipkarte ausgeführt wird.
Bestehende Java-Card-Applets (d.h. Programme) nutzen die Java-Card-API (Application Programming Interface, Anwendungsprogrammierschnittstelle) um Schlüssel zu erstellen und Schlüsselreferenzen für weitere Nutzung zu halten. Wenn von einem bösartigen Programm (Applet) auf die Schlüsselreferenz zugegriffen werden kann, kann dieses bösartige Programm imstande sein, den Schlüssel abzurufen, z.B. durch eine get-Key-Methode des Schlüsselobjekts, z.B. „keyObj.getKey(...)“.
Ein Firewall-Mechanismus des Java-Card-Betriebssystems (Java-Card-Plattform) sollte jeglichen unzulässigen Zugriff auf die Schlüsselobjekte verhindern. Bestehende Mechanismen gestatten jedoch den Zugriff auf die Schlüssel objekte über gemeinsam nutzbare Schnittstellen. Daher sind bestehende Firewall-Lösungen nicht stark genug, um Schlüsselobjekte vor ungewolltem Zugriff, z.B. durch nicht authentifizierte Applets, zu schützen.
Es ist daher eine Aufgabe, die Sicherheit von Java-Card-Schlüsselobjekten zu verbessern.
Dies wird durch die Merkmale der unabhängigen Ansprüche erreicht. Weitere Ausführungsformen gehen aus den abhängigen Ansprüchen hervor.
Um die oben genannte Aufgabe zu erfüllen, wird ein Verfahren zum Betrieb einer Java-Card-Umgebung bereitgestellt, das Folgendes umfasst:

- Erzeugen eines Schlüsselobjekts, wobei eine derartige Erzeugung mindestens einen zusätzlichen Sicherheitsparameter umfasst.

Es sei angemerkt, dass das Schlüsselobjekt mindestens einen Schlüssel umfassen kann, der für Signatur- und Chiffrierzwecke genutzt werden kann. Der erzeugte Schlüssel kann ein nicht initialisierter kryptographischer Schlüssel sein.
Jeder der Sicherheitsparameter kann ein sein, der als Boolean-Typ realisiert ist, z.B. ein Flag mit zwei möglichen Zuständen. In einem ersten Zustand kann das Flag gesetzt sein, oder der Boolean-Parameter kann TRUE sein, und in einem zweiten Zustand kann das Flag zurückgesetzt sein, oder der Boolean-Parameter kann FALSE sein.
Es sei angemerkt, dass der zusätzliche Sicherheitsparameter mindestens ein Parameter zusätzlich zu bereits bestehenden Parametern der Java-Card-Umgebung sein kann, insbesondere der buildKey-Methode der Klasse KeyBuilder.
Gemäß einer Ausführungsform wird das Schlüsselobjekt durch die buildKey-Methode der Klasse KeyBuilder erzeugt.
Gemäß einer Ausführungsform umfasst der zusätzliche Sicherheitsparameter einen Nur-Schreiben-Parameter, der

- wenn er gesetzt ist, angibt, dass ein Schlüssel des Schlüsselobjekts nicht gelesen werden kann;
- wenn er nicht gesetzt ist, angibt, dass der Schlüssel des Schlüssel objekts gelesen werden kann.

Somit kann sichergestellt werden, dass der/die Schlüssel von keinem Benutzer (d.h. keiner Anwendung) von der Java-Card-Plattform gelesen werden kann/können, sei es der Inhaber oder ein beliebiges anderes Applet (selbst ein Java-Card-Applet, das böswillig versucht, den/die Schlüssel auszulesen).
Gemäß einer Ausführungsform umfasst der zusätzliche Sicherheitsparameter einen Nur-Schreiben-durch-Inhaber-Parameter, der

- wenn er gesetzt ist, angibt, dass es nur einem Inhaber des Schlüsselobjekts gestattet ist, das Schlüsselobjekt zu verändern;
- wenn er nicht gesetzt ist, angibt, dass es auch einer anderen Anwendung als dem Inhaber des Schlüsselobjekts gestattet ist, das Schlüsselobjekt zu verändern.

Die Veränderung des Schlüsselobjekts kann Ändern eines Schlüssels des Schlüssel objekts enthalten.
Auch wird eine Sicherheitsvorrichtung bereitgestellt, welche eine Java-Card-Umgebung nutzt, wobei die Sicherheitsvorrichtung eine Verarbeitungseinheit umfasst, die eingerichtet ist zum

Die Verarbeitungseinheit kann eine beliebige Verarbeitungsfähigkeit sein, die auf der Sicherheitsvorrichtung und/oder einer Java-Card-Umgebung eingerichtet ist. Die Verarbeitungseinheit kann eine Java-Card-API nutzen.
Gemäß einer Ausführungsform umfasst der zusätzliche Sicherheitsparameter einen Nur-Schreiben-Parameter, der

Gemäß einer Ausführungsform umfasst der zusätzliche Sicherheitsparameter einen Nur-Schreiben-durch-Inhaber-Parameter, der

Gemäß einer Ausführungsform ist die Sicherheitsvorrichtung eine Smart Card.
Ferner wird eine Vorrichtung zum Betrieb einer Java-Card-Umgebung vorgeschlagen, die Folgendes umfasst:

- Mittel zum Erzeugen eines Schlüsselobjekts, wobei diese Erzeugung mindestens einen zusätzlichen Sicherheitsparameter umfasst.

Es wird ein Computerprogrammprodukt vorgeschlagen, das direkt in einen Speicher einer digitalen Verarbeitungsvorrichtung ladbar ist, umfassend Softwarecodeabschnitte zur Durchführung der Schritte des hierin beschriebenen Verfahrens.
Es wird ein computerlesbarer Datenträger bereitgestellt, der computerausführbare Anweisungen umfasst, die dafür geeignet sind, zu bewirken, dass ein Computersystem die Schritte des hierin beschriebenen Verfahrens durchführt.
Ausführungsformen werden unter Bezugnahme auf die Zeichnung(en) gezeigt und dargestellt. Die Zeichnung(en) dienen dazu, das Grundprinzip darzustellen, so dass nur Aspekte dargestellt werden, die zum Verständnis des Grundprinzips notwendig sind.

1 zeigt ein schematisches Diagramm, das eine Kommunikation zwischen einer Benutzereinheit und eine Java-Card-Plattform veranschaulicht.

In Java Card umfasst die Klasse KeyBuilder die Methode buildKey wie folgt:

      public static Key buildKey(byte algorithmicKeyType,
              byte keyMemoryType,
              short keyLength,
              boolean keyEncryption)

Die Methode buildKey erzeugt nicht initialisierte kryptographische Schlüssel für Signatur- und Chiffrieralgorithmen. Die Parameter der buildKey-Methode sind wie folgt:

- algorithmicKeyType gibt den zu erzeugenden Typ von Schlüssel und Algorithmus an.
- keyMemoryType gibt den Speichertyp zur Speicherung von Schlüsseldaten an.
- keyLength gibt die Schlüsselgröße in Bits an.
- keyEncryption: Wenn dieser Boolean wahr ist, fordert er eine Schlüsselimplementierung an, welche die javacardx.crypto.KeyEncryption-Schnittstelle implementiert; die zurückgegebene Schlüsselimplementierung kann die javacardx.crypto.KeyEncryption-Schnittstelle selbst dann implementieren, wenn dieser Parameter falsch ist.

Hiermit bereitgestellte Beispiele legen insbesondere nahe, dass Java-Card-Schlüsselobjekte im Sinne von Vertraulichkeit und Authentizität sicherer gemacht werden.

Dies kann dadurch erreicht werden, dass der buildKey-Methode mindestens ein Sicherheitsparameter hinzugefügt wird:

- isWriteOnly,
- isWriteOnlyByOwner.

Diese beiden Sicherheitsparameter können Boolean-Parameter sein, d.h. entweder TRUE oder FALSE. Sie können auch als Flags bezeichnet werden, wobei ein Flag gesetzt oder nicht gesetzt sein kann.

Auf Grundlage des mindestens einen Sicherheitsparameters können die Schlüsselobjekte so eingerichtet werden, dass vom Standpunkt eines Applets auf sie nur geschrieben werden kann. Ferner können beliebige Schlüssel dann nicht mehr mithilfe z.B. der getKey-Methode der Klasse AESKey ausgelesen werden.

Der Sicherheitsparameter isWriteOnly und/oder isWriteOnlyByOwner, die der buildKey-Methode hinzugefügt werden, können die folgende Funktionalität bereitstellen:

Wenn der Parameter isWriteOnly-Parameter auf TRUE gesetzt ist, kann der Schlüssel nicht gelesen werden. Das Java-Card-Betriebssystem kann den Schlüssel intern für kryptographische Operationen nutzen. Wenn der Parameter isWriteOnly auf FALSE gesetzt ist, kann der Schlüssel gelesen werden.

Wenn der Parameter isWriteOnlyByOwner auf TRUE gesetzt ist, wenn der Schlüssel mit einer anderen Anwendung über eine gemeinsam nutzbare Schnittstelle gemeinsam genutzt wird, kann der Client das Schlüsselobjekt nicht verändern.

Wenn der Parameter isWriteOnlyByOwner auf FALSE gesetzt ist, wenn der Schlüssel mit einer anderen Anwendung über eine gemeinsam nutzbare Schnittstelle gemeinsam genutzt wird, kann der Client das Schlüsselobjekt verändern.

Der Schlüssel kann einen beliebigen symmetrischen oder asymmetrischen Schlüssel umfassen.

Es kann ein Mechanismus zur Speicherung vertraulicher Schlüssel von dem Java-Card-Betriebssystem bereitgestellt werden.

1 zeigt ein schematisches Diagramm, das eine Kommunikation zwischen einer Benutzereinheit 101 (auch als „Nutzer des Schlüsselobjekts“ bezeichnet) und einer Java-Card-Plattform 102 (welches das Java-Card-Betriebssystem, das auch die Schlüssel implementiert, sein oder umfassen kann) veranschaulicht.

Die Benutzereinheit 101 kann eins von Folgendem sein:

- ein Java-Card-Applet außerhalb der Karte, d.h. eins, das nicht auf der Chipkarte implementiert ist;
- ein Java-Card-Applet auf der Chipkarte;
- ein bösartiges Applet.

Die Java-Card-Plattform 102 kann mindestens eins von Folgendem umfassen:

- eine Java Card Virtual Machine (JCVM),
- eine Java-Card-Anwendungsprogrammierschnittstelle (Java Card Application Programming Interface, JCAPI),
- eine Java-Card-Laufzeitumgebung (Java Card Runtime Environment, JCRE),
- Kryptographische Fähigkeiten,
- eine Hardware-Abstraktionsschicht (Hardware Abstraction Layer, HAL).

Die Benutzereinheit 101 sendet den erweiterten buildKey-Befehl an die Java-Card-Plattform 102, einschließlich der Parameter isWriteOnly und isWriteOnlyByOwner, die beispielhaft beide auf TRUE gesetzt sind.

Die Java-Card-Plattform 102 (insbesondere die Klasse KeyBuilder) gibt eine Schlüsselreferenz zurück, d.h. ein Objekt keyRef.

Für dieses keyRef-Objekt kann eine setKey-Anforderung genutzt werden, um den Schlüssel zu setzen. Wenn der Parameter isWriteOnlyByOwner auf TRUE gesetzt ist, wird diese Anforderung durch die Java-Card-Plattform 102 nur dann ausgeführt, wenn der Inhaber des keyRef-Objekts die Anforderung gesendet hat; andernfalls wird eine SecurityException ausgelöst.

Für dieses keyRef-Objekt kann eine getKey-Anforderung genutzt werden, um den Schlüssel zu erhalten. Wenn der Parameter isWriteOnly auf TRUE gesetzt ist, ist es nicht gestattet, dass der Schlüssel gelesen wird. Somit wird der getKey-Anforderung zufolge eine SecurityException ausgelöst.

Somit verbessert die hierin vorgestellte Lösung die Sicherheit von Schlüsseln in Java-Card-Systemen. Die Schlüsselobjekte in der Java-Card-Umgebung werden daher im Sinne von Vertraulichkeit und Authentizität verbessert. Die erhöhte Sicherheit kann mit bestehenden Java-Card-Firewall-Mechanismen kombiniert werden. Auch erhöht der Ansatz die Flexibilität der Java-Card-API, die es Benutzern dieser API gestattet, ihr System und/oder ihre Anwendung(en) abzusichern.

Es ist ebenso ein Vorteil, dass die Sicherheit im Kern des Java-Card-Systems verarbeitet werden kann. Somit ist keine zusätzliche (entfernte) Verarbeitungsfähigkeit erforderlich.

Die Lösung kann auf der Java-Card-API oder einer Erweiterung davon beruhen.

Wenngleich verschiedene beispielhafte Ausführungsformen der Erfindung offenbart wurden, ist es für den Fachmann offensichtlich, dass verschiedene Änderungen und Modifikationen vorgenommen werden können, die einige der Vorteile der Erfindung erzielen, ohne vom Geist und Umfang der Erfindung abzuweichen. Für den Durchschnittsfachmann ist es offensichtlich, dass andere Komponenten, welche die gleichen Funktionen ausführen, in geeigneter Weise ersetzt werden können. Es sollte erwähnt werden, dass Merkmale, die unter Bezugnahme auf eine bestimmte Figur erläutert werden, mit Merkmalen anderer Figuren kombiniert werden können, selbst in den Fällen, in denen dies nicht ausdrücklich erwähnt wurde. Ferner können die Verfahren der Erfindung entweder in allen Softwareimplementierungen mithilfe der entsprechenden Prozessoranweisungen oder in Hybridimplementierungen, die eine Kombination aus Hardwarelogik und Softwarelogik nutzen, erreicht werden, um dieselben Ergebnisse zu erzielen. Es ist beabsichtigt, dass derartige Modifikationen des erfinderischen Konzepts durch die beigefügten Ansprüche abgedeckt sind.

Claims

Verfahren zum Betrieb einer Java-Card-Umgebung, umfassend: - Erzeugen eines Schlüsselobjekts, wobei eine derartige Erzeugung mindestens einen zusätzlichen Sicherheitsparameter umfasst.
Verfahren nach Anspruch 1, bei dem das Schlüsselobjekt durch die buildKey-Methode der Klasse KeyBuilder erzeugt wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei der der zusätzliche Sicherheitsparameter einen Nur-Schreiben-Parameter umfasst, der - wenn er gesetzt ist, angibt, dass ein Schlüssel des Schlüsselobjekts nicht gelesen werden kann; - wenn er nicht gesetzt ist, angibt, dass der Schlüssel des Schlüssel objekts gelesen werden kann.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem der zusätzliche Sicherheitsparameter einen Nur-Schreiben-durch-Inhaber-Parameter umfasst, der - wenn er gesetzt ist, angibt, dass es nur einem Inhaber des Schlüsselobjekts gestattet ist, das Schlüsselobjekt zu verändern; - wenn er nicht gesetzt ist, angibt, dass es auch einer anderen Anwendung als dem Inhaber des Schlüsselobjekts gestattet ist, das Schlüsselobjekt zu verändern.
Sicherheitsvorrichtung, die eine Java-Card-Umgebung nutzt, umfassend eine Verarbeitungseinheit, die eingerichtet ist zum - Erzeugen eines Schlüsselobjekts, wobei eine derartige Erzeugung mindestens einen zusätzlichen Sicherheitsparameter umfasst.
Sicherheitsvorrichtung nach Anspruch 5, bei der der zusätzliche Sicherheitsparameter einen Nur-Schreiben-Parameter umfasst, der - wenn er gesetzt ist, angibt, dass ein Schlüssel des Schlüsselobjekts nicht gelesen werden kann; - wenn er nicht gesetzt ist, angibt, dass der Schlüssel des Schlüsselobjekts gelesen werden kann.
Sicherheitsvorrichtung nach einem der Ansprüche 5 oder 6, bei der der zusätzliche Sicherheitsparameter einen Nur-Schreiben-durch-Inhaber-Parameter umfasst, der - wenn er gesetzt ist, angibt, dass es nur einem Inhaber des Schlüsselobjekts gestattet ist, das Schlüsselobjekt zu verändern; - wenn er nicht gesetzt ist, angibt, dass es auch einer anderen Anwendung als dem Inhaber des Schlüsselobjekts gestattet ist, das Schlüsselobjekt zu verändern.
Sicherheitsvorrichtung nach einem der Ansprüche 5 bis 7, bei der die Sicherheitsvorrichtung eine Smart Card ist.
Vorrichtung zum Betrieb einer Java-Card-Umgebung, umfassend: - Mittel zum Erzeugen eines Schlüsselobjekts, wobei diese Erzeugung mindestens einen zusätzlichen Sicherheitsparameter umfasst.
Computerprogrammprodukt, das direkt in einen Speicher einer digitalen Verarbeitungsvorrichtung ladbar ist, umfassend Softwarecodeabschnitte zur Durchführung der Schritte des Verfahrens nach einem der Ansprüche 1 bis 4.
Computerlesbarer Datenträger mit computerausführbaren Anweisungen, die dafür geeignet sind, zu bewirken, dass ein Computersystem die Schritte des Verfahrens nach einem der Ansprüche 1 bis 4 durchführt.