DE102010012496A1 - Datenträgerinterne Schlüsselerzeugung - Google Patents

Datenträgerinterne Schlüsselerzeugung Download PDF

Info

Publication number
DE102010012496A1
DE102010012496A1 DE201010012496 DE102010012496A DE102010012496A1 DE 102010012496 A1 DE102010012496 A1 DE 102010012496A1 DE 201010012496 DE201010012496 DE 201010012496 DE 102010012496 A DE102010012496 A DE 102010012496A DE 102010012496 A1 DE102010012496 A1 DE 102010012496A1
Authority
DE
Germany
Prior art keywords
key
application
request
data carrier
generating
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE201010012496
Other languages
English (en)
Inventor
Claus Jarnik
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE
Original Assignee
Giesecke and Devrient GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Priority to DE201010012496 priority Critical patent/DE102010012496A1/de
Publication of DE102010012496A1 publication Critical patent/DE102010012496A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Ein Verfahren zum Erzeugen von kryptographischen Schlüsseln in einem portablen Datenträger (10) umfasst den Schritt des Zuweisens (S1) einer Anforderungsberechtigung an eine in dem Datenträger (10) installierte Applikation (54) durch eine Berechtigungszuweisungseinrichtung (53). Die Anforderungsberechtigung berechtigt dabei zum Anfordern (S2) zumindest eines kryptographischen Schlüssels bei einer Schlüsselerzeugungseinrichtung (55) des Datenträgers (10). Weiterhin umfasst das Verfahren den Schritt des Anfordere (S2) des zumindest einen Schlüssels durch die Applikation (54) bei der Schlüsselerzeugungseinrichtung (55) gemäß einer Anforderungsspezifikation sowie den Schritt des Erzeugen (S4) des zumindest einen Schlüssels durch die Schlüsselerzeugungseinrichtung (55) gemäß der Anforderungsspezifikation der Applikation (54).

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Erzeugen von kryptographischen Schlüsseln in einem portablen Datenträger sowie einen entsprechend eingerichteten Datenträger.
  • Portable Datenträger, die zumindest einen Speicher und einen Prozessor zum Ausführen von in dem Speicher gespeicherten Applikationen besitzen, sind vorwiegend derart eingerichtet, dass auf dem Datenträger Applikationen mehrerer Dienstanbieter installiert werden können. Um die jeweiligen Applikationen und die von diesen Applikationen bearbeiteten Daten vor unbefugtem Zugriff zu schützen, sind spezielle, privilegierte Applikationen, so genannte „Security Domains”, vorgesehen, die für die herkömmlichen, nicht privilegierten Applikationen eines Dienstanbieters eine Art Sicherheitsumgebung bereitstellen. Die privilegierten Applikationen können untereinander nochmals nach dem Grad ihrer Privilegierung unterschieden werden, wobei die Security Domain des Kartenausgebers in der Regel die höchsten Privilegien aufweist.
  • Eine solche privilegierte Applikation umfasst eine eigene Schlüsselinfrastruktur und unterstützt die Datenkommunikation der in der Security Domain installierten nicht privilegierten Applikation mit Dritten über gesicherte Datenkommunikationskanäle. Nicht privilegierte Applikationen sind in der Regel herkömmliche Anwendungen, beispielsweise zum Abwickeln eines Bezahlvorgangs oder dergleichen, und verfügen für gewöhnlich nicht über eigene kryptographische Schlüssel. Die Schlüssel dienen der privilegierten Applikation unter anderem dazu, den der Applikation zugewiesenen weiteren Applikationen eine Sicherheitsinfrastruktur bereitzustellen, um beispielsweise gesichert Daten zu übertragen oder zu empfangen sowie gespeicherte Daten gesichert abzulegen. Eine Datenträgerinfrastruktur der skizzierten Art ist beispielsweise in der „GlobalPlatform Card Specification, Version 2.2” detailliert beschrieben.
  • Das Ausstatten einer privilegierten Applikation mit kryptographischen Schlüsseln erfolgt in der Regel während der Installation oder Konfiguration der Applikation. Gemäß der oben angegebenen Spezifikation und einer Aktualisierung derselben („Amendment A”, Version 1.0) sind zwei Verfahren bekannt, um kryptographische Schlüssel bereitzustellen. Gemäß einer ersten Variante werden die entsprechenden Schlüssel außerhalb des Datenträgers erzeugt und jeder Schlüssel wird mittels eines geeigneten Kommandos, in der Regel verschlüsselt, in den Datenträger eingebracht, dort entschlüsselt und gespeichert. Diese Lösung hat den Nachteil, dass ein sehr großer Zeit- und Datenübertragungsaufwand erforderlich ist. Eine zweite Variante beschreibt ein Verfahren zur datenträgerinternen Erzeugung von kryptographischen Schlüsseln. Dieses erfordert allerdings – neben einer Einrichtung zum Erzeugen der Schlüssel – eine eigens dafür in dem Datenträger installierte Kontrollinstanz, welche ihrerseits einen zusätzlichen Ressourcen- und Konfigurationsaufwand erfordert. Der Zeitaufwand zum Erzeugen der Schlüssel im Datenträger kann dabei im Vergleich zur externen Erzeugung kaum verringert werden.
  • Aufgabe der vorliegenden Erfindung ist es demnach, ein einfaches und flexibles Verfahren vorzuschlagen, mittels dessen kryptographische Schlüssel mit geringem Aufwand in einem portablen Datenträger bereitgestellt werden können.
  • Diese Aufgabe wird durch ein Verfahren und einen Datenträger mit den Merkmalen der unabhängigen Ansprüche gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den abhängigen Ansprüchen angegeben.
  • Ein erfindungsgemäßes Verfahren zum Erzeugen von kryptographischen Schlüsseln in einem portablen Datenträger umfasst den Schritt des Zuweisens einer Anforderungsberechtigung an eine in dem Datenträger installierte Applikation durch eine Berechtigungszuweisungseinrichtung. Die Anforderungsberechtigung berechtigt dabei zum Anfordern zumindest eines kryptographischen Schlüssels bei einer Schlüsselerzeugungseinrichtung des Datenträgers. Weiterhin umfasst das Verfahren den Schritt des Anforderns des zumindest einen Schlüssels durch die Applikation bei der Schlüsselerzeugungseinrichtung gemäß einer Anforderungsspezifikation sowie den Schritt des Erzeugen des zumindest einen Schlüssels durch die Schlüsselerzeugungseinrichtung gemäß der Anforderungsspezifikation der Applikation.
  • Demnach umfasst ein erfindungsgemäßer portabler Datenträger einen Prozessor, einen Speicher sowie eine in dem Speicher gespeicherte Applikation. Erfindungsgemäß umfasst der Datenträger eine Schlüsselerzeugungseinrichtung sowie eine Berechtigungszuweisungseinrichtung. Die Berechtigungszuweisungseinrichtung ist eingerichtet, der Applikation eine Anforderungsberechtigung zum Anfordern zumindest eines kryptographischen Schlüssels bei der Schlüsselerzeugungseinrichtung zuzuweisen. Die Schlüsselerzeugungseinrichtung ist eingerichtet, zumindest einen kryptographischen Schlüssel gemäß einer Anforderungsspezifikation der Applikation zu erzeugen.
  • Das Verfahren ermöglicht somit eine flexible Schlüsselerzeugung in dem Datenträger. Durch Zuweisung einer Anforderungsberechtigung an eine beliebige, auf dem Datenträger gespeicherte Applikation kann diese Applikation mit der Berechtigung oder dem Privileg ausgestattet werden, bei der Schlüsselerzeugungseinrichtung zumindest einen kryptographischen Schlüssel anzufordern. Über eine fehlende Zuweisung können somit auch Applikationen von der Berechtigung zur Schlüsselanforderung ausgeschlossen werden. Auf diese Weise kann die den Datenträger ausgebende Stelle detailliert festlegen, welchen der auf dem Datenträger installierten Applikationen durch die Berechtigungszuweisungseinrichtung eine Berechtigung zur Anforderung eines oder mehrerer Schlüssel zugewiesen werden soll. Weiter kann die Art der angeforderten Schlüssel von der berechtigten Applikation über die Anforderungsspezifikation vorgegeben werden. Das Verfahren ermöglicht jeder berechtigten Applikation die Anforderung zumindest eines Schlüssels zu jedem Zeitpunkt während des Lebenszyklus der Applikation bzw. des Datenträgers. Der Zeitpunkt, zu dem eine Applikation mit einer Anforderungsberechtigung ausgestattet wird, ist ebenfalls frei wählbar. Somit kann eine datenträgerinterne Schlüsselerzeugung flexibel festgelegt und gehandhabt werden. Das Verfahren geht weiterhin sparsam mit den Ressourcen des Datenträgers um. Solange die Applikation keine Schlüssel angefordert hat, werden entsprechende Ressourcen des Datenträgers, beispielsweise zum Verwalten der Schlüssel notwendige Speicherbereiche, nicht benötigt.
  • Vorzugsweise wird einer Applikation die Anforderungsberechtigung während oder direkt nach ihrer Installation oder während ihrer Konfiguration, d. h. als ein Konfigurationsschritt, durch die Berechtigungszuweisungseinrichtung zugewiesen. Die Konfiguration einer Applikation schließt sich in der Regel an deren Installation an und dient dazu, die Applikation für den bestimmungsgemäßen Gebrauch auf den Datenträger einzurichten. Das Anfordern kryptographischer Schlüssel durch die Applikation bei der Schlüsselerzeugungseinrichtung des Datenträgers kann insofern als weiterer Konfigurationsschritt bezüglich dieser Applikation angesehen werden. Die Applikation erweitert mit dem Empfang der Schlüssel von der Schlüsselerzeugungseinrichtung ihre eigene Funktionalität, indem sie dadurch beispielsweise mit einer eigenen Schlüsselinfrastruktur zur gesicherten Kommunikation ausgestattet wird.
  • Es ist auch möglich, dass die Applikation, obwohl ihr eine Anforderungsberechtigung zugewiesen worden ist, kryptographische Schlüssel bei der Schlüsselerzeugungsrichtung erst dann anfordert, wenn die Applikation nachträglich um eine Funktionalität erweitert worden ist, z. B. im Rahmen eines Updates, welche nun entsprechende kryptographische Schlüssel erfordert.
  • Der Applikation kann die Anforderungsberechtigung durch die Berechtigungszuweisungseinrichtung aber auch zu einem späteren Zeitpunkt zugewiesen werden, nachdem die Applikation in dem Datenträger bereits verwendet worden ist, d. h. insbesondere nachdem sie installiert und konfiguriert worden ist. Auch auf diese Weise kann der Funktionsumfang einer Applikation nachträglich, auch nach Ausgabe des Datenträgers an den Nutzer, erweitert werden.
  • Das erfindungsgemäße Verfahren erlaubt es, verschiedenen Applikationen eine Anforderungsberechtigung zum Anfordern kryptographischer Schlüssel zuzuweisen. Zum einen können privilegierte Applikationen, insbesondere Security Domains, mit einer Anforderungsberechtigung ausgestattet werden. Dabei ist es möglich, ausgewählten, auf dem Datenträger installierten Security Domains diese Berechtigung vorzuenthalten, indem diesen keine Anforderungsberechtigung durch die Berechtigungszuweisungseinrichtung zugewiesen wird. Auf der anderen Seite kann auch einer untergeordneten Applikation, welche beispielsweise innerhalb einer Security Domain installiert ist, eine Anforderungsberechtigung zugewiesen werden. Dadurch wird diese Applikation in die Lage versetzt, eigenständig bei der Schlüsselerzeugungseinrichtung kryptographische Schlüssel anzufordern. Insbesondere kann also Applikationen verschiedener Hierarchiestufen des Datenträgers und unabhängig von ihrer Position in der Hierarchie eine Anforderungsberechtigung zugewiesen oder eben nicht zugewiesen werden.
  • Vorzugsweise wird als Schlüsselerzeugungseinrichtung auf dem Datenträger eine zentrale Schlüsselerzeugungseinrichtung bereitgestellt. Diese ist eingerichtet, Anforderungen zur Erzeugung zumindest eines kryptographischen Schlüssels von unterschiedlichen, auf dem Datenträger installierten Applikationen entgegenzunehmen und Schlüssel gemäß den jeweiligen Anforderungsspezifikationen zu erzeugen. Die zentrale Schlüsselerzeugungseinrichtung gibt somit eine einheitliche Schnittstelle (API, „Application Programming Interface) für alle auf den Datenträger installierten Applikationen vor. Vorzugsweise ist diese Schlüsselerzeugungseinrichtung eingerichtet, verschiedenste Schlüssel gemäß beliebiger Vorgaben in den Anforderungsspezifikationen der anfordernden Applikationen zu erzeugen. Auf diese Weise werden Ressourcen des Datenträgers geschont, da es vermieden werden kann, unterschiedliche Applikationen des Datenträgers mit einer Funktionalität zur Schlüsselerzeugung auszustatten. Weiterhin steht jede Anpassung, beispielsweise jede Erweiterung der Funktionalität, der zentralen Schlüsselerzeugungseinrichtung direkt jeder anforderungsberechtigten Applikation bereit, ohne dass diese selbst angepasst werden müsste.
  • Es ist aber auch möglich, eine Mehrzahl von Schlüsselerzeugungseinrichtungen auf dem Datenträger bereitzustellen, beispielsweise jeweils zur Erzeugung verschiedener Klassen kryptographischer Schlüssel. Weiterhin ist es möglich, dass Applikationen auf verschiedenen Hierarchiestufen des Datenträgers ihre jeweiligen Schlüsselanforderungen an jeweils unterschiedliche Schlüsselerzeugungseinrichtungen senden, welche den entsprechenden Hierarchiestufen zugeordnet sind.
  • Vorzugsweise prüft die Schlüsselerzeugungseinrichtung die Anforderungsberechtigung einer Applikation, welche bei ihr einen kryptographischen Schlüssel angefordert hat, und erzeugt den Schlüssel nur dann, wenn die Applikation zum Anfordern des Schlüssels berechtigt ist. Die von der Schlüsselerzeugungseinrichtung bereitgestellte API gewährleistet weiterhin eine gesicherte Datenkommunikation zwischen der Schlüsselerzeugungseinrichtung und der aufrufenden, berechtigten Applikation. Damit wird wirkungsvoll verhindert, dass unberechtigte Applikationen die Dienste der Schlüsselerzeugungsapplikation in Anspruch nehmen. Eine solche nicht anforderungsberechtigte Applikation muss in der Regel auf die Schlüsselarchitektur einer ihr übergeordneten Applikation, beispielsweise einer Security Domain, innerhalb derer die Applikation selbst installiert ist, zurückgreifen.
  • Die Berechtigungszuweisungseinrichtung kann eingerichtet sein, Anforderungsberechtigungen verschiedener Art zuzuweisen. Jede dieser zugewiesenen Anforderungsberechtigungen berechtigt die entsprechende Applikation zwar prinzipiell zum Anfordern eines Schlüssels bei einer Schlüsselerzeugungseinrichtung. Allerdings ist es möglich, dass eine erste Anforderungsberechtigung lediglich zum Anfordern einer eingeschränkten Klasse von Schlüsseln berechtigt oder die Anzahl anforderbarer Schlüssel begrenzt, während eine zweite, von der ersten Anforderungsberechtigung abweichende Anforderungsberechtigung beispielsweise das Anfordern beliebiger Schlüssel in beliebiger Anzahl erlaubt. D. h. die Art der Anforderungsberechtigung kann Beschränkungen hinsichtlich anforderbarer Schlüssel umfassen.
  • Es ist alternativ oder zusätzlich möglich, dass eine Anforderungsberechtigung in dem Fall, in dem mehrere Schlüsselerzeugungseinrichtungen in dem Datenträger vorgesehen sind, die Teilmenge der Schlüsselerzeugungseinrichtungen vorgibt, die von der Applikation, welcher die entsprechende Anforderungsberechtigung zugewiesen worden ist, in Anspruch genommen werden kann. Auf diese Weise kann noch detaillierter festgelegt werden, welche Applikation mittels welcher Schlüsselerzeugungseinrichtung welche Schlüssel anzufordern berechtigt ist.
  • Entsprechend prüft die Schlüsselerzeugungseinrichtung, an die eine Anforderung zur Erzeugung eines Schlüssels von einer Applikation gesendet worden ist, bei Anforderungsberechtigung der Applikation nicht nur, ob die Applikation zur Schlüsselanforderung generell berechtigt ist, sondern beispielsweise auch, ob die betreffende Applikation berechtigt ist, genau diese Schlüsselerzeugungseinrichtung in Anspruch zu nehmen und Schlüssel gemäß der empfangenen Anforderungsspezifikation, insbesondere hinsichtlich Anzahl und Art der Schlüssel, anzufordern.
  • Schließlich ist es möglich vorzusehen, dass die Berechtigungszuweisungseinrichtung einer Applikation die Anforderungsberechtigung wieder entzieht. Ein solches Merkmal würde die Flexibilität des Verfahrens weiter erhöhen. Abgelaufene Schlüssel, beispielsweise, könnten dann durch eine Applikation, welcher die Anforderungsberechtigung entzogen worden ist, nicht mehr erneuert werden.
  • Eine Applikation, die bei der Schlüsselerzeugungseinrichtung zumindest einen kryptographischen Schlüssel anfordert, spezifiziert den zu erzeugenden Schlüssel mittels der Anforderungsspezifikation. Diese gibt – unter anderem – eine Anzahl zu erzeugender Schlüssel vor, d. h. eine Applikation kann innerhalb einer Anforderung an die Schlüsselerzeugungseinrichtung eine Mehrzahl auch verschiedener kryptographischer Schlüssel anfordern. Weiterhin spezifiziert die Applikation mittels der Anforderungsspezifikation weitere Parameter, welche den zumindest einen zu erzeugenden Schlüssel definieren, beispielsweise den Typ, die Länge, die Version oder die Kennung des Schlüssels.
  • Nachdem die Schlüsselerzeugungseinrichtung den zumindest einen kryptographischen Schlüssel gemäß der Anforderungsspezifikation erzeugt hat, übergibt sie den zumindest einen Schüssel an die anfordernde Applikation. Diese verwaltet den oder die erzeugten, übergebenden Schlüssel im Folgenden. Insbesondere speichert die Applikation den zumindest einen Schlüssel sicher innerhalb eines vor ihr kontrollierten Zugriffsbereichs eines Speichers des Datenträgers. Ein Verwalten des zumindest einen Schlüssels umfasst auch dessen bestimmungsgemäße Verwendung durch die Applikation, beispielsweise zur Herstellung eines gesicherten Kommunikationskanals oder dergleichen.
  • In bestimmten Anwendungszusammenhängen ist es erforderlich, dass datenträgerintern erzeugte Schlüssel, nachdem sie von der Applikation gespeichert worden sind, nach außerhalb des Datenträgers exportiert werden müssen. Dies ist beispielsweise dann der Fall, wenn der entsprechende Schlüssel erst dann sinnvoll eingesetzt werden kann, wenn er nicht nur der Applikation in dem Datenträger, sondern weiterhin einer externen Instanz außerhalb des Datenträgers bekannt ist. Ein Schlüssel beispielsweise, welcher zum Verschlüsseln von Daten gemäß einem symmetrischen Verschlüsselungsverfahren verwendet werden soll, muss beiden Kommunikationspartnern, also der verschlüsselnden als auch der entschlüsselnden Partei, vorliegen. Ebenso sollte ein in einem asymmetrischen Verschlüsselungsverfahren verwendeter öffentlicher Schlüssel allen potentiellen Kommunikationspartnern bekannt sein.
  • Befindet sich der Datenträger zum Zeitpunkt des Exportieren des Schlüssels in einer gesicherten Umgebung, beispielsweise während der Herstellung des Datenträgers, kann darauf verzichtet werden, dass ein Schlüssel, bevor er nach außerhalb des Datenträgers exportiert wird, kryptographisch gesichert wird.
  • Wird das Exportieren eines durch die Schlüsselerzeugungseinrichtung erzeugten Schlüssels allerdings in einem ungesicherten Umfeld, beispielsweise unter Zuhilfenahme eines nicht gesicherten oder nicht vertrauenswürdigen Netzwerks, durchgeführt, so wird der Schlüssel vor dem Exportieren nach außerhalb des Datenträgers kryptographisch gesichert. Auf diese Weise wird verhindert, dass der Schlüssel ausgespäht oder gar unbemerkt verändert werden kann. Eine entsprechende kryptographische Sicherung kann beispielsweise mittels Verschlüsseln und/oder digitalem Signieren durchgeführt werden. Auf diese Weise kann ein Exportieren auch dann gesichert erfolgen, wenn der Datenträger bereits an einen Nutzer ausgegeben worden ist.
  • Vorzugsweise werden die Mittel zum kryptographischen Sichern eines zu exportierenden Schlüssels von einer solchen Applikation bereitgestellt, welche zu der Applikation, die den Schlüssel bei der Schlüsselerzeugungseinrichtung angefordert hat, assoziiert ist, insbesondere dieser gemäß einer gegebenen Hierarchie übergeordnet ist. Bei einer hierarchischen Anordnung der Applikationen auf dem Datenträger kann eine Applikation einer tieferen Hierarchiestufe Funktionalitäten einer ihr bezüglich der Hierarchie übergeordneten, assoziierten Applikation in Anspruch nehmen. Voraussetzung ist dabei natürlich, dass diese übergeordnete, assoziierte Applikation bereits über eine geeignete Schlüsselarchitektur oder dergleichen verfügt. In der Regel ist zumindest eine zu Beginn der Herstellung des Datenträgers auf dem Datenträger installierte Applikation, welche der den Datenträger ausgebenden Stelle zugeordnet ist, beispielsweise die so genannte Issuer Security Domain, entsprechend eingereichtet.
  • Einer im weiteren Verlauf der Herstellung des Datenträgers auf diesem installierten Security Domain kann also die übergeordnete Issuer Security Domain die entsprechenden Mittel zum kryptographischen Sichern eines zu exportierenden Schlüssels bereitstellen. Wird nachfolgend beispielsweise innerhalb dieser gewöhnlichen Security Domain, die ihrerseits einem gewöhnlichen Dienstanbieter zugeordnet sein kann, eine nicht privilegierte Applikation installiert und mit einer Anforderungsberechtigung ausgestattet, so können die Schlüssel, deren Erzeugung diese nicht privilegierte Applikation bei der Schlüsselerzeugungseinrichtung angefordert hat, auf verschiedene Weise zum Exportieren kryptographisch gesichert werden. Zum einen können dazu Schlüssel der gewöhnlichen Security Domain verwendet werden, die nun vorliegen. Zum anderen kann auch auf die Issuer Security Domain zurückgegriffen werden.
  • Zueinander assoziierte Applikationen können bezüglich der genannten Hierarchie auch auf derselben Stufe stehen, beispielsweise unterschiedliche, innerhalb einer Security Domain installierte, nicht privilegierte Applikationen. Schließlich ist es möglich, dass verschiedene Applikationen des Datenträgers in einer Weise zueinander assoziiert sind, welche sich in keiner hierarchischen Anordnung widerspiegelt. Wesentlich ist im beschriebenen Zusammenhang lediglich, dass die eine Applikation eine Sicherheitsinfrastruktur der anderen, zu ihr assoziierten Applikation in einer Weise verwenden kann, dass die damit gesichert exportierten Daten gegen unberechtigten Zugriff geschützt sind.
  • Auf die beschriebene Weise ist es insbesondere möglich, Schlüssel, welche eine beliebige berechtigte Applikation bei der Schlüsselerzeugungseinrichtung angefordert hat, in gesicherter Weise nach außerhalb des Datenträgers zu exportieren. Dazu ist es insbesondere nicht erforderlich, dass die anfordernde Applikation bereits in irgendeiner Weise personalisiert ist, beispielsweise mit einem minimalen Schlüsselsatz. Ausreichend ist, wenn die Applikation zum kryptographischen Sichern der zu exportierenden Schlüssel auf Mittel einer aus ihrer Sicht vertrauenswürdigen assoziierten Applikation zurückgreifen kann.
  • Die Applikation, welche bei der Schlüsselerzeugungseinrichtung zumindest einen kryptographischen Schlüssel anfordert, kann dazu auf verschiedene Weise aufgefordert worden sein. Gemäß einer ersten Variante kann dies mittels eines proprietären Schlüsselerzeugungskommandos, beispielsweise in Form einer speziellen APDU, geschehen. Dieses Schlüsselerzeugungskommando wird über eine geeignete Datenkommunikationsschnittstelle des Datenträgers an die Applikation gesendet und von dieser verarbeitet. Die Anforderungsspezifikation, mit welcher der zumindest eine zu erzeugende Schlüssel spezifiziert wird, ist dabei vorzugsweise ebenfalls Teil des Schlüsselerzeugungskommandos. Als Teil eines gegebenenfalls vorgesehenen Antwortkommandos auf das Schlüsselerzeugungskommando kann die Applikation den zumindest einen, von ihr bei der Schlüsselerzeugungseinrichtung angeforderten und von dieser erzeugten Schlüssel in der vorstehend beschriebenen Weise nach außerhalb des Datenträgers exportieren. Das Zuweisen einer Anforderungsberechtigung an die betreffende Applikation, womit diese zum Anfordern des zumindest einen Schlüssels berechtigt worden ist, ist in der Regel unabhängig von dem Schlüsselerzeugungskommando und vor dem Empfangen und Verarbeiten desselben erfolgt, beispielsweise während einer Installation oder früheren Konfiguration der Applikation oder bereits beim ersten Laden der Applikation auf den Datenträger.
  • Eine zweite Variante sieht vor, dass die Applikation durch eine oder mehrere Anweisungen, welche Teil eines erweiterten Installationskommandos sind, zum Anfordern des zumindest einen kryptographischen Schlüssels aufgefordert wird. Ein entsprechendes erweitertes Installationskommando ist in der DE 10 2009 041 924 detailliert beschrieben worden. Das dort beschriebene Verfahren sieht vor, mit lediglich einem Aufruf eines entsprechenden erweiterten Installationskommandos eine Applikation gleichzeitig zu installieren und zu konfigurieren. Es ist auch möglich, mittels des erweiterten Installationskommandos eine Mehrzahl von Applikationen zu installieren und/oder zu konfigurieren. Dadurch verringert sich der Datenübertragungsaufwand während der Installation und Konfiguration des Datenträgers beträchtlich. Eine oder mehrere Anweisungen zur Anforderung zumindest eines kryptographischen Schlüssels bei der Schlüsselerzeugungseinrichtung des Datenträgers können problemlos in das erweiterte Installationskommando integriert werden. Damit ist beispielsweise ein erweitertes Installationskommando denkbar, welches das Installieren und Konfigurieren einer Applikation bewirkt, wobei als ein Konfigurationsschritt ein Schlüssel bei der Schlüsselerzeugungseinrichtung angefordert wird und in einem weiteren Konfigurationsschritt nach außerhalb des Datenträgers exportiert wird. Das Zuweisen einer Anforderungsberechtigung an die betreffende Applikation kann gleichfalls mittels des Installationskommandos bewirkt werden. Alternativ kann die Applikation vor ihrer Installation mit der Anforderungsberechtigung ausgestattet werden, beispielsweise wenn die Applikation erstmalig auf den Datenträger geladen wird.
  • Eine Integration des Verfahrens der vorliegenden Erfindung zum datenträgerinternen Erzeugen kryptographischer Schlüssel in den Zusammenhang des vorstehend skizzierten Konzepts eines erweiterten Installationskommandos erscheint besonders vorteilhaft, da sich die Vorteile beider Lösungen im Wesentlichen addieren, ohne dass das eine Verfahren das jeweils andere beeinträchtigt oder einschränkt. D. h. eine flexible und applikationsspezifisch festlegbare Berechtigung zur Anforderung kryptographischer Schlüssel bei einer vorzugsweise zentralen Schlüsselerzeugungseinrichtung kann auf äußerst effektive Weise Ressourcen schonend umgesetzt werden.
  • Wie schon in der DE 10 2009 041 924 mit Bezug auf das erweiterte Installationskommando beschrieben, werden alle Anweisungen eines erfindungsgemäß neu definierten Schlüsselerzeugungskommandos innerhalb einer Betriebssystemtransaktion durchgeführt. Dasselbe gilt für die Schritte des erfindungsgemäßen Verfahrens, wenn diese als Bestandteil eines erweiterten Installationskommandos verwendet werden. D. h. die Schritte des Anforderns des zumindest einen kryptographischen Schlüssels bei der Schlüsselerzeugungseinrichtung, des Erzeugen des oder der angeforderten Schlüssel sowie das Exportieren des- oder derselben nach außerhalb des Datenträgers werden stets innerhalb einer Betriebssystemtransaktion durchgeführt. Im Falle eines Fehlers beim Abarbeiten eines dieser Schritte im Datenträger wird der Datenträger in den Zustand versetzt, den er vor dem Anfordern des zumindest einen Schlüssels, d. h. vor dem Empfangen des Schlüsselerzeugungskommandos bzw. des erweiterten Installationskommandos, eingenommen hatte. Auf diese Weise ist es möglich, stets einen definierten Zustand des Datenträgers garantieren zu können. Entweder sind alle Schritte des Verfahrens erfolgreich durchgeführt worden oder sämtliche Veränderungen am Zustand des Datenträgers, welche auf der Ausführung eines Teils der Verfahrensschritte beruhen, werden betriebssystemseitig in ihrer Gesamtheit rückgängig gemacht. Ein aufwändiges, manuelles Rollback, d. h. Rückabwickeln, einzelner, nicht korrekt durchgeführter Kommandos mit dem Ziel, zu einem definierten Zustand des Datenträgers zurückzukehren, kann unterbleiben. Auf diese Weise kann die Herstellung des Datenträgers beträchtlich vereinfacht werden, da auftretende Fehler während der Produktion schneller und mit wesentlich weniger Aufwand hinsichtlich Zeit und notwendiger Datenübertragung behoben werden können.
  • Die vorliegende Erfindung wird im Folgenden mit Bezug auf die beiliegenden Zeichnungen beispielhaft beschrieben. Darin zeigen:
  • 1 eine bevorzugte Ausführungsform eines erfindungsgemäßen Datenträgers und
  • 2A, 2B Schritte einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens.
  • Ein portabler Datenträger 10, der mit Bezug auf 1 als Chipkarte dargestellt ist, umfasst eine Datenkommunikationsschnittstelle 20, einen Prozessor (CPU) 30 und verschiedene Speicher 40, 50 und 60. Die Bauform des Datenträgers 10 kann variieren, beispielsweise kann er auch als (U)SIM-Mobilfunkkarte, als Speicherkarte, als USB-Token oder dergleichen ausgebildet sein.
  • Die Datenkommunikationsschnittstelle 20 ist als Kontaktfeld ausgebildet. Darüber kann der Datenträger 10 über ein entsprechendes Lesegerät kontaktiert werden. Alternativ oder zusätzlich kann eine Datenkommunikationsschnittstelle zur kontaktlosen Datenkommunikation, beispielsweise in Form einer Antennenspule (nicht gezeigt), vorgesehen sein.
  • Ein nicht wiederbeschreibbarer, nicht flüchtiger ROM-Speicher 40 speichert ein den Datenträger 10 steuerndes Betriebssystem (OS) 42. Der Speicher 40 kann weiter eine oder mehrere Applikationen speichern (nicht gezeigt), die auf dem Prozessor 30 des Datenträgers 10 ausführbar sind.
  • In dem wiederbeschreibbaren, nicht flüchtigen Speicher 50 ist eine Steuereinrichtung 52 gespeichert. Diese umfasst eine mit Bezug auf 2A beschriebene Berechtigungszuweisungseinrichtung 53. Die Berechtigungszuweisungseinrichtung 53 kann auch separat von der Steuereinrichtung 52 gespeichert sein und eingerichtet sein, mit dieser zu interagieren. Weiterhin ist in dem Speicher 50 eine Schlüsselerzeugungseinrichtung 55 gespeichert, welche ebenfalls mit Bezug auf 2A näher beschrieben wird. Schließlich umfasst der Speicher 50 eine Applikation 54, welche nach geeigneter Installation und Konfiguration auf dem Prozessor 30 ausführbar ist.
  • Die Steuereinrichtung 52, welche auch in dem ROM-Speicher 40 gespeichert sein könnte, ist eingerichtet, von dem Datenträger 10 über die Datenkommunikationsschnittstelle 20 empfangene Installationskommandos zum Installieren und Konfigurieren der Applikationen 54 sowie weiterer, über die Datenkommunikationsschnittstelle 20 nachladbarer Applikationen auszuführen. Die Berechtigungszuweisungseinrichtung 53 ist eingerichtet, auf dem Datenträger gespeicherten Applikationen, z. B. die Applikation 54, eine Anforderungsberechtigung zuzuweisen. Eine solche Anforderungsberechtigung berechtigt, wenn zugewiesen, die entsprechende Applikation 54 zum Anfordern zumindest eines kryptographischen Schlüssels bei der Schlüsselerzeugungseinrichtung 55. Diese ist ihrerseits eingerichtet, auf Anforderung einer berechtigten Applikation 54 und gemäß einer im Rahmen der Anforderung empfangenen Anforderungsspezifikation kryptographische Schlüssel zu erzeugen und an die anfordernde Applikation 54 zu übergeben.
  • Der wiederbeschreibbare, flüchtige RAM-Speicher 60 dient dem Datenträger 10 als Arbeitsspeicher.
  • Auf dem Datenträger 10 ausführbare Applikationen, wie beispielsweise die Applikation 54, können verschiedenen Klassen zugeordnet werden. Eine erste Klasse bilden so genannte „Security Domains”. Dies sind privilegierte Applikationen, welche derart eingerichtet werden können, dass sie für andere, nicht privilegierte, herkömmliche Applikationen, welche die zweite Klasse bilden, eine Sicherheitsumgebung bereitstellen. Mit Hilfe dieser Sicherheitsumgebung können die nicht privilegierten Applikationen, welche in der entsprechenden Umgebung installiert oder dieser nach einer Installation zugewiesen werden, über sichere Kanäle Daten austauschen und erzeugte oder empfangene Daten gesichert speichern. Zu diesem Zweck umfasst eine privilegierte Applikation eine eigene Schlüsselinfrastruktur, d. h. kryptographische Schlüssel und Funktionalitäten zum Durchführen von symmetrischen oder asymmetrischen Verschlüsselungsverfahren. Die Schlüssel können beispielsweise zum Verschlüsseln und/oder Entschlüsseln von Daten, zum Überprüfen von digitalen Signaturen und zum Berechnen von digitalen Signaturen verwendet werden. Wie erwähnt, wird auf diese Weise eine gesicherte Datenkommunikation, beispielsweise zwischen dem Datenträger und einer Anwendung auf einer externen, mit dem Datenträger verbundenen Datenverarbeitungseinrichtung ermöglicht. Ein Verfahren zur datenträgerinternen Erzeugung entsprechender Schlüssel wird nachstehend mit Bezug auf die 2A und 2B beschrieben. Datenträgerintern erzeugte Schlüssel können denselben Zwecken dienen wie nach dem Stand der Technik von außerhalb des Datenträgers in den Datenträger, beispielsweise mittels eines PUT KEY Kommandos, eingebrachte Schlüssel.
  • In der Regel ist eine privilegierte Applikation je einem Dienstanbieter zugeordnet, so dass herkömmliche, nicht privilegierte Applikationen des Dienstanbieters geschützt durch die privilegierte Applikation und abgeschirmt von Applikationen und Diensten anderer Anbieter auf demselben Datenträger 10 agieren können. Privilegierte Applikationen können verschiedene Privilegien besitzen. Die privilegierte Applikation des Kartenausgebers, die so genannte „Issuer Security Domain”, ISD, besitzt in der Regel die höchsten Prioritäten und wird als erste Applikation auf dem Datenträger 10 installiert. Weitere privilegierte Applikationen können nachfolgend auf dem Datenträger 10 eingerichtet, d. h. installiert und konfiguriert, werden.
  • Die privilegierten Applikationen können eine Hierarchie bilden, indem eine privilegierte Applikation einer anderen privilegierten Applikation zugewiesen (extradiert) und damit untergeordnet wird. Die zugewiesene Applikation kann dann Dienste der privilegierten Applikation, der sie zugeordnet worden ist, nutzen, beispielsweise wenn die zugewiesene Applikation nicht selbst entsprechende Privilegien besitzt. Die privilegierte Applikation ist somit assoziiert zu der nicht privilegierten Applikation.
  • Eine nicht privilegierte Applikation muss innerhalb einer privilegierten Applikation installiert werden. Verfügt die entsprechende privilegierte Applikation dazu nicht über genügend Privilegien, so kann die nicht privilegierte Applikation in einer höher privilegierten Applikation installiert und danach der nieder privilegierten Applikation mittels Extradition zugewiesen werden. Auf diese Weise sind sowohl die höher privilegierte als auch die nieder privilegierte Applikation zu der nicht privilegierten Applikation assoziiert.
  • Bei einer Installation einer Applikation 54 auf dem Datenträger 10 durch die Steuereinrichtung 52 wird die Applikation zuerst authentisiert, d. h. es wird geprüft, ob eine Installation auf dem Datenträger 10 an der entsprechenden Stelle vorgesehen ist. Danach wird durch die Steuereinrichtung 52, welche eine Laufzeitumgebung des Datenträgers 10 umfasst, der Applikation 54 zugeordneter Speicherplatz reserviert und die Applikation 54 identifizierende Daten werden in ein Register des Datenträgers 10 eingetragen. Erst nach einer solchen Installation ist eine Applikation 54, welche zuvor bereits als ausführbarer Code in Form eines so genannten „executable load files” in einem Speicher 50 des Datenträger 10 gespeichert war oder über die Datenkommunikationsschnittstelle 20 nachgeladen worden ist, auf dem Prozessor 30 des Datenträgers 10 ausführbar.
  • Es kann erforderlich sein, dass eine Applikation 54, bevor sie ausführbar ist, zusätzlich noch konfiguriert werden muss. Eine privilegierte Applikation 54 beispielsweise muss notwendigerweise vorgegebene kryptographische Schlüssel umfassen, bevor sie ausgeführt werden kann. Diese Schlüssel müssen in einem oder mehreren Konfigurationsschritten der Applikation 54 zugeordnet werden. Erst danach kann diese Applikation 54 als personalisiert („PERSONALIZED”) und damit vollständig einsetzbar angesehen werden. Ein Verfahren zur datenträgerinternen Erzeugung solcher Schlüssel für eine Applikation 54 wird nachstehend mit Bezug auf die 2A und 2B beschrieben.
  • Weitere Konfigurationsschritte sind beispielsweise das Extradieren, also das Zuweisen einer Applikation 54 zu einer privilegierten Applikation 54. Eine Applikation 54 kann auch dadurch konfiguriert werden, dass der Applikation Personalisierungsdaten zugeordnet werden, welche die Applikation für einen späteren Nutzer personalisieren.
  • Mit Bezug auf die 2A und 2B wird nun ein Verfahren zum Erzeugen von kryptographischen Schlüsseln in dem Datenträger 10 beschrieben.
  • In einem ersten Schritt S1 wird der Applikation 54 durch die Berechtigungszuweisungseinrichtung 53 eine Anforderungsberechtigung zugewiesen. Diese Anforderungsberechtigung berechtigt die Applikation 54 (vgl. Schritt S2), zumindest einen kryptographischen Schlüssel bei der Schlüsselerzeugungseinrichtung 55 anzufordern. Das Zuweisen der Anforderungsberechtigung durch die Berechtigungszuweisungseinrichtung 53 kann während der Installation oder Konfiguration der Applikation 54, welche beispielsweise mittels eines erweiterten Installationskommandos durchgeführt wird, erfolgen. D. h. das Installationskommando, das von der Steuerapplikation 52 verarbeitet wird, umfasst eine Anweisung, welche die Berechtigungszuweisungseinrichtung 53 anweist, der Applikation 54 eine Anforderungsberechtigung zuzuweisen.
  • Alternativ kann es vorgesehen sein, dass die Applikation 54 bereits in einem noch uninstallierten Zustand oder mittels eines separaten Installationskommandos durch die Berechtigungszuweisungseinrichtung 53 mit einer Anforderungsberechtigung ausgestattet wird. D. h. der Schritt S1 des Zuweisen einer Anforderungsberechtigung sowie der nachfolgend beschriebene Schritt des Anforderns eines Schlüssels bei der Schlüsselerzeugungseinrichtung 55 können sowohl Anweisungen eines einzigen erweiterten Installationskommandos sein, aber auch separat voneinander und angestoßen durch unterschiedliche Kommandos durchgeführt werden.
  • Die Anforderungsberechtigung kann in beliebiger, geeigneter Weise implementiert werden. Beispielsweise kann eine berechtigte Applikation 54 durch die Berechtigungszuweisungseinrichtung 53 mit einem entsprechenden Attribut versehen werden. Gemäß der erwähnten „GlobalPlatform Card Specification” ist beispielsweise innerhalb des „INSTALL (for INSTALL)”-Kommandos ein so genanntes „Privileges”-Feld vorgesehen, mittels dessen eine Applikation mit bestimmten Rechten (z. B. Security-Domain-Rechte, Authorized Management, u. ä.) ausgestattet werden kann. Ein solches Feld, oder eine analoge Ergänzung oder proprietäre Erweiterung des Feldes, könnte somit verwendet werden, um eine Anforderungsberechtigung einzurichten.
  • Eine andere Möglichkeit besteht im Verwalten einer Liste der berechtigten Applikationen 54 durch die Berechtigungszuweisungseinrichtung 53.
  • Schließlich besteht die Möglichkeit, die Anforderungsberechtigung (gemäß der genannten Spezifikation) mittels dafür neu definierter Kommandos oder innerhalb der so genannten „Application Specific Parameters” zu setzen. Diese Parameter sind vorgesehen, um einer Applikation bestimmte Konfigurationsdaten zu übergeben.
  • In Schritt S2 fordert die Applikation 54 – in Schritt S1 mit einer Anforderungsberechtigung ausgestattet – kryptographische Schlüssel bei der Schlüsselerzeugungseinrichtung 55 an. Die Applikation 54 kann sowohl von einem proprietären Schlüsselerzeugungskommando als auch mittels einer Anweisung eines vorstehend beschriebenen erweiterten Installationskommandos zum Anfordern dieser Schlüssel aufgefordert werden. Mittels eines Schlüsselerzeugungskommandos kann ein Dienstanbieter beispielsweise eine ihm auf dem Datenträger 10 zugeordnete Applikation 54 mit neuen oder zusätzlichen kryptographischen Schlüsseln ausstatten. Dieser Schritt ist zu jedem Zeitpunkt im Lebenszyklus des Datenträgers 10 durchführbar, insbesondere auch, wenn der Datenträger 10 bereits an einen Nutzer ausgegeben worden ist.
  • Bevor die Schlüsselerzeugungseinrichtung 55 der Anforderung der Applikation 54 folgt und die angeforderten Schlüssel erzeugt, prüft sie in Schritt S3 die Berechtigung der Applikation 54. Lediglich wenn diese Berechtigung vorliegt, wird das Verfahren mit Schritt S4 fortgesetzt, andernfalls wird es abgebrochen. Dies wäre beispielsweise dann der Fall, wenn eine Applikation, welcher keine Anforderungsberechtigung zugewiesen worden ist, eine Schlüsselerzeugungsanforderung an die Schlüsselerzeugungsapplikation 55 senden würde.
  • In Schritt S4 erzeugt die Schlüsselerzeugungseinrichtung nun, vorzugsweise nacheinander, die von der Applikation 54 angeforderten Schlüssel. Diese sind in einer Anforderungsspezifikation spezifiziert, welche der Schlüsselerzeugungseinrichtung 55 von der Applikation im Rahmen der Anforderung der Schlüssel übergeben wird. Die Applikation 54 ihrerseits hat die Anforderungsspezifikation mittels des Schlüsselerzeugungskommandos oder des erweiterten Installationskommandos empfangen. Eine solche Anforderungsspezifikation kodiert in geeigneter Weise sämtliche, die zu erzeugenden Schlüssel definierenden Parameter, d. h. insbesondere die Anzahl zu erzeugender Schlüssel sowie für jeden zu erzeugenden Schlüssel den Typ, die Länge, die Version und die Kennung. Vorzugsweise erfolgt eine solche Kodierung TLV-basiert. TLV steht für „Tag, Length, Value”. Ein „Tag”, beispielsweise 0xDF, steht für die durchzuführende Operation, hier also das Erzeugen von Schlüsseln. Eine „Length”, beispielsweise 0x10, steht für die Länge des nachfolgenden „Values”, hier also 16 Hexadezimalstellen. Mit dem Value-Parameter werden nun sämtliche zu erzeugenden Schlüssel, in diesem Beispiel vier, definiert. Jede Schlüsseldefinition benötigt vier (Hexadezimal-)Stellen, jeweils eine für Typ, Länge, Version und ID. Eine entsprechende Anforderungsspezifikation lautet beispielsweise
    „DF 10 80 08 01 01 80 10 01 02 88 18 02 01 88 20 02 02”,
    wobei z. B. der den zweiten der Schlüssel definierende Anteil „80 10 01 02” einen Schlüssel vom Typ „80” der Länge „10”, der Version „01” mit der ID „02” definiert. Die Kodierungen gängiger Schlüsseltypen – „80” steht beispielsweise für DES (data encryption scheme), „88” für AES (advanced encryption scheme) – sind der Schlüsselerzeugungseinrichtung 55 bekannt. Folgt die von der Schlüsselerzeugungseinrichtung 55 empfangene Anforderungsspezifikation nicht dem geforderten Schema, wird das Verfahren ebenfalls abgebrochen.
  • Zu jedem erzeugten Schlüssel bereitet die Schlüsselerzeugungseinrichtung 55 in Schritt S5 entsprechende Antwortdaten vor, mit denen ein erzeugter Schlüssel an die anfordernde Applikation 54 übergeben werden. Diese Antwortdaten können neben den eigentlichen Schlüsseldaten weitere, beispielsweise die Applikation 54 betreffende Daten, z. B. einen so genannten „application identifier” (AID), umfassen.
  • In Schritt S6 prüft die Schlüsselerzeugungseinrichtung 55, ob gemäß der Anforderung der Applikation 54 noch weitere Schlüssel zu erzeugen sind und wiederholt gegebenenfalls die Schritte S4 und S5 zur Erzeugung weiterer Schlüssel. Eine einzige Schlüsselanforderung ist, wie beschrieben, geeignet, eine Mehrzahl auch verschiedener Schlüssel bei der Schlüsselerzeugungseinrichtung 55 anzufordern.
  • Hat die Schlüsselerzeugungseinrichtung 55 schließlich alle von der Applikation 54 angeforderten Schlüssel erzeugt, so werden diese Schlüssel an die Applikation 54 übergeben, welche die Schlüssel in Schritt S7 innerhalb der Applikation 54 speichert. Im Folgenden werden die Schlüssel, wie in Schritt S7 ebenfalls angedeutet, durch die Applikation 54 verwaltet. Dies beinhaltet eine Benutzung der Schlüssel durch die Applikation 54 selbst, beispielsweise zum Aufbau eines gesicherten Kommunikationskanals, oder eine Bereitstellung einer Sicherheitsdienstleistung unter Verwendung einzelner Schlüssel an eine der Applikation 54 untergeordnete oder assoziierte Applikation.
  • Bevor die erzeugten und in der Applikation 54 gespeicherten Schlüssel nach außerhalb des Datenträgers exportiert werden, vorzugsweise mittels eines Antwortkommandos auf das Schlüsselerzeugungskommando oder das erweiterte Installationskommando, welche die Erzeugung der Schlüssel initiiert haben, wird in Schritt S8 geprüft, ob sich der Datenträger 10 in einer sicheren Umgebung befindet. Dies ist beispielsweise während der Produktion des Datenträgers 10 der Fall, wenn der Empfänger des Antwortkommandos die entsprechende Produktionsmaschine ist und die verwendeten Übertragungswege sämtlich vor unberechtigtem Zugriff geschützt sind. In diesem Fall kann von einer kryptographischen Sicherung, beispielsweise einem Verschlüsseln (vgl. Schritt S9) der zu exportierenden Schlüssel abgesehen werden.
  • Falls allerdings keine gesicherte Umgebung vorliegt, wenn der Datenträger 10 beispielsweise bereits an einen Nutzer ausgegeben worden ist und eine Datenkommunikation mit dem Datenträger 10 über ein nicht vertrauenswürdiges Netzwerk stattfindet, müssen die erzeugten Schlüssel vor dem Exportieren in Schritt S9 kryptographisch gesichert, beispielsweise verschlüsselt, werden. Die zum Sichern erforderlichen Mittel werden der Applikation 54, welche ja in der Regel nicht personalisiert ist und keine entsprechenden Mittel umfasst, von einer mit der Applikation 54 assoziierten Applikation, beispielsweise einer übergeordneten Security Domain, bereitgestellt.
  • Anschließend werden die – gegebenenfalls gesicherten – Schlüssel in Schritt S10 an die Anwendung außerhalb des Datenträgers 10 exportiert, welche die Schlüsselerzeugung mittels des Schlüsselerzeugungskommandos oder des erweiterten Installationskommandos initiiert hat.
  • Es ergeben sich somit zahlreiche Vorteile. Das beschriebene Verfahren kann flexibel eingesetzt werden, z. B. auch dann, wenn der Datenträger 10 bereits an einen Nutzer ausgegeben worden ist. Entsprechende Schlüssel können von einer berechtigten Applikation 54 bei der Schlüsselerzeugungseinrichtung 55 jederzeit angefordert werden. Eine Applikation 54 kann mehrfach zum Anfordern von Schlüsseln aufgefordert werden. Es ist bezüglich einer Schlüsselerzeugung keine Vorkonfiguration oder Personalisierung notwendig, insbesondere müssen keine Ressourcen des Datenträgers 10 vorab reserviert werden noch muss die anfordernde Applikation 54 einen initialen Schlüsselsatz umfassen. Dadurch ergibt sich für den Hersteller des Datenträgers 10 die Möglichkeit, die Herstellungszeit des Datenträgers 10 dadurch weiter zu verkürzen, dass zumindest ein Teil der zu erzeugenden Schlüssel erst nach Auslieferung des Datenträgers 10 an den Nutzer wie beschrieben datenträgerintern und auf Anforderung des Nutzers erzeugt werden. Wird die Schlüsselerzeugung dagegen beim Hersteller durchgeführt, so kann dies vorteilhaft mittels eines erweiterten Installationskommandos erfolgen, welches als eine oder mehrere Anweisungen ein Anfordern kryptographischer Schlüssel bei der Schlüsselerzeugungseinrichtung umfasst.
  • Auch das Zuweisen einer Anforderungsberechtigung durch die Zuweisungseinrichtung 53 kann noch nach Ausgabe des Datenträgers 10, beispielsweise im Rahmen eines Updates, erfolgen. Dadurch wird die Flexibilität des Verfahrens weiter erhöht. Im Rahmen der „GlobalPlatform Card Specification” stehen das „STORE DATA”- oder das „INSTALL (for REGISTRY UPDATE)”-Kommando zur nachträglichen Rechteaktivierung prinzipiell zur Verfügung.
  • Es ist leicht möglich, das beschriebene Verfahren in herkömmliche Datenträger zu integrieren, ohne dass die Notwendigkeit besteht, derzeit gültige Spezifikationen, beispielsweise die genannte „GlobalPlatform Card Specification”, zu ändern. Die neu entwickelten Applikationen und Einrichtungen lassen sich ohne großen technischen Aufwand und ohne Kompatibilitätsprobleme in aktuelle Datenträger integrieren. Es fällt kein erhöhter Verwaltungs- und Konfigurationsaufwand an.
  • Datenträgerintern können, wie erwähnt, beliebige Schlüssel in beliebiger Anzahl erzeugt werden. Das gesamte Verfahren ist transaktionsgesichert, d. h. läuft stets innerhalb einer Betriebssystemtransaktion ab. Damit ist eine Korrektur während des Verfahrens eventuell auftretender Fehler einfach und ohne großen Aufwand möglich. Auch dadurch werden Produktionszeit und -kosten eingespart.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 102009041924 [0031, 0033]

Claims (15)

  1. Verfahren zum Erzeugen von kryptographischen Schlüsseln in einem portablen Datenträger (10), gekennzeichnet durch die Schritte: – Zuweisen (S1) einer Anforderungsberechtigung zum Anfordern zumindest eines kryptographischen Schlüssels bei einer Schlüsselerzeugungseinrichtung (55) des Datenträgers (10) an eine in dem Datenträger installierte Applikation (54) durch eine Berechtigungszuweisungseinrichtung (53); – Anfordern (S2) des zumindest einen Schlüssels durch die Applikation (54) bei der Schlüsselerzeugungseinrichtung (55) gemäß einer Anforderungsspezifikation; – Erzeugen (S4) des zumindest einen Schlüssels durch die Schlüsselerzeugungseinrichtung (55) gemäß der Anforderungsspezifikation der Applikation (54).
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Applikation (54) während ihrer Installation oder Konfiguration auf dem Datenträger (10) die Anforderungsberechtigung zugewiesen wird.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass einer privilegierten Applikation (54), insbesondere einer Security Domain, eine Anforderungsberechtigung zugewiesen wird.
  4. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass einer nicht privilegierten Applikation (54), insbesondere einer einer Security Domain untergeordneten Applikation, eine Anforderungsberechtigung zugewiesen wird.
  5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass als Schlüsselerzeugungseinrichtung (55) auf dem Datenträger (10) eine zentrale Schlüsselerzeugungseinrichtung bereitgestellt wird, welche eingerichtet ist, Anforderungen zur Erzeugung zumindest eines kryptographischen Schlüssels von unterschiedlichen auf dem Datenträger (10) installierten Applikationen (54) entgegenzunehmen und Schlüssel gemäß der jeweiligen Anforderungsspezifikation zu erzeugen.
  6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Schlüsselerzeugungseinrichtung (55) die Anforderungsberechtigung der Applikation (54) vor dem Erzeugen des zumindest einen Schlüssels prüft (S3) und den zumindest einen Schlüssel nur dann erzeugt, wenn die Applikation (54) zum Anfordern des zumindest einen Schlüssels berechtigt ist.
  7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Applikation (54) den zumindest einen angeforderten Schlüssel mittels der Anforderungsspezifikation derart spezifiziert, dass die Anforderungsspezifikation eine Anzahl zu erzeugender Schlüssel und/oder einen Typ eines zu erzeugenden Schlüssels und/oder eine Länge eines zu erzeugenden Schlüssels und/oder eine Version eines zu erzeugenden Schlüssels und/oder eine Kennung eines zu erzeugenden Schlüssels vorgibt.
  8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Schlüsselerzeugungseinrichtung (55) den zumindest einen erzeugten Schlüssel an die anfordernde Applikation (54) übergibt und die Applikation (54) den zumindest einen erzeugten, übergebenen Schlüssel verwaltet (S7).
  9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass der zumindest eine erzeugte Schlüssel nach außerhalb des Datenträgers exportiert (S10) wird.
  10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass der zumindest eine Schlüssel vor dem Exportieren (S10) kryptographisch gesichert wird (S9).
  11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Mittel zum kryptographischen Sichern des zumindest einen Schlüssels von einer der Applikation (54) assoziierten privilegierten Applikation bereitgestellt werden.
  12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Applikation (54) mittels eines proprietären Schlüsselerzeugungskommandos oder mittels eines Bestandteils eines erweiterten Installationskommandos zum Anfordern des zumindest einen Schlüssels bei der Schlüsselerzeugungseinrichtung (55) aufgefordert wird.
  13. Verfahren nach einem der Ansprüche 9 bis 12, dadurch gekennzeichnet, dass das Anfordern, Erzeugen und Exportieren des zumindest einen Schlüssels in dem Datenträger (10) innerhalb einer Betriebssystemtransaktion durchgeführt wird und der Datenträger (10) im Fall des Auftretens eines Fehlers während eines dieser Schritte in den Zustand versetzt wird, den der Datenträger (10) vor dem Anfordern des zumindest einen Schlüssels eingenommen hatte.
  14. Portabler Datenträger (10), umfassend einen Prozessor (30), einen Speicher (40; 50; 60) sowie eine in dem Speicher (50) gespeicherte Applikation (54), gekennzeichnet durch eine Schlüsselerzeugungseinrichtung (55) sowie eine Berechtigungszuweisungseinrichtung (53), wobei die Berechtigungszuweisungseinrichtung (53) eingerichtet ist, der Applikation (54) eine Anforderungsberechtigung zum Anfordern zumindest eines kryptographischen Schlüssels bei der Schlüsselerzeugungseinrichtung (55) zuzuweisen, und die Schlüsselerzeugungseinrichtung (55) eingerichtet ist, zumindest einen kryptographischen Schlüssel gemäß einer Anforderungsspezifikation der Applikation (54) zu erzeugen.
  15. Datenträger (10) nach Anspruch 14, dadurch gekennzeichnet, dass der Datenträger (10) zum Durchführen eines Verfahrens nach einem der Ansprüche 1 bis 13 eingerichtet ist.
DE201010012496 2010-03-24 2010-03-24 Datenträgerinterne Schlüsselerzeugung Pending DE102010012496A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE201010012496 DE102010012496A1 (de) 2010-03-24 2010-03-24 Datenträgerinterne Schlüsselerzeugung

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE201010012496 DE102010012496A1 (de) 2010-03-24 2010-03-24 Datenträgerinterne Schlüsselerzeugung

Publications (1)

Publication Number Publication Date
DE102010012496A1 true DE102010012496A1 (de) 2011-09-29

Family

ID=44585880

Family Applications (1)

Application Number Title Priority Date Filing Date
DE201010012496 Pending DE102010012496A1 (de) 2010-03-24 2010-03-24 Datenträgerinterne Schlüsselerzeugung

Country Status (1)

Country Link
DE (1) DE102010012496A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009041924A1 (de) 2009-09-17 2011-04-07 Giesecke & Devrient Gmbh Verfahren zum Installieren und Konfigurieren von Applikationen auf einem portablen Datenträger

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009041924A1 (de) 2009-09-17 2011-04-07 Giesecke & Devrient Gmbh Verfahren zum Installieren und Konfigurieren von Applikationen auf einem portablen Datenträger

Similar Documents

Publication Publication Date Title
DE69730712T2 (de) Kommunikationssystem mit gesicherter, unabhängiger verwaltung mehrerer anwendungen pro gebraucherkarte, gebraucherkarte und verwaltungsverfahren dafür
EP2318921B1 (de) Laden und aktualisieren einer personalisierungsbedürftigen applikation
EP2910039B1 (de) Verfahren zum einbringen von teilnehmeridentitätsdaten in ein teilnehmeridentitätsmodul
EP1361514B1 (de) System und Verfahren zum Verwalten von Ressourcen von tragbaren Ressourcenmodulen
DE102012110499A1 (de) Sicherheitszugangsverfahren für elektronische Automobil-Steuergeräte
WO2014044348A1 (de) Teilnehmeridentitätsmodul zum authentisieren eines teilnehmers an einem kommunikationsnetzwerk
EP3649625B1 (de) Verfahren zur delegation von zugriffsrechten
WO2012130461A2 (de) Aktualisierung einer datenträgerapplikation
EP1164456B1 (de) Software-Schutzmechanismus
EP1196902B1 (de) Verfahren zum betreiben eines zur ausführung von nachladbaren funktionsprogrammen ausgebildeten datenträgers
EP1638246B1 (de) Verfahren zum Austausch von Kryptographiedaten
EP2524333B1 (de) Verfahren zum bereitstellen eines sicheren zählers auf einem endgerät
DE102010012496A1 (de) Datenträgerinterne Schlüsselerzeugung
WO2011033030A1 (de) Verfahren zum installieren und konfigurieren von applikationen auf einem portablen datenträger
EP3407242A1 (de) Personalisieren eines halbleiterelements
DE102015101523A1 (de) Verfahren zur Berechtigungsverwaltung in einer Anordnung mit mehreren Rechensystemen
WO2017032452A1 (de) Transaktionssystem
DE102016000324B4 (de) Verfahren zur Verwaltung von Identifikationsdaten mehrerer Anwendungen
EP3329415B1 (de) Chipkarte mit hauptapplikation und persistenzapplikation erlaubt hauptapplikationupdate ohne die benutzerdaten im persistenzapplikation zu ändern
EP2486551B1 (de) Personalisieren eines telekommunikationsmoduls
DE19839266A1 (de) Verfahren zur Freigabe eines Softwaremoduls, sowie ein Softwaremodul, ein Freischaltemodul, ein PC und ein Diensterechner hierfür
EP3831110A1 (de) Sicherheitselement, verfahren zum betreiben eines sicherheitselements und verfahren zum installieren eines allgemeinen anwendungsprogramms
EP1855252B1 (de) Anordnung und Verfahren zum Erstellen eines Frankierabdrucks
EP3215957B1 (de) Chipkarte, chipkartensystem und verfahren zum zugriff auf eine chipkarte
WO2023051950A1 (de) Universal integrated chip card, uicc, zum verwalten von profilen, sowie verfahren

Legal Events

Date Code Title Description
R163 Identified publications notified
R163 Identified publications notified

Effective date: 20140211

R012 Request for examination validly filed
R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GMBH, DE

Free format text: FORMER OWNER: GIESECKE & DEVRIENT GMBH, 81677 MUENCHEN, DE

R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT EPAYMENTS GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT MOBILE SECURITY GMBH, 81677 MUENCHEN, DE

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT MOBILE SECURITY GMBH, 81677 MUENCHEN, DE

R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT EPAYMENTS GMBH, 81677 MUENCHEN, DE