-
Die Erfindung betrifft ein Verfahren zur Schlüsselermittlung für ein Authentisierungsverfahren nach dem Challenge-Response-Verfahren, bei einem System mit mehreren Aufträgen, wobei jedem Auftrag ein Auftragsschlüssel und mindestens ein Sicherheitsmodul zugeordnet ist, in dem ein vom Auftragsschlüssel ableitbarer individueller Schlüssel abgespeichert ist.
-
Das Verfahren ist insbesondere bei einem geschützten mikroprozessorgestützten Sicherheitsmodul vorteilhaft anwendbar.
-
Ein Sicherheitsmodul im Sinn der Erfindung ist wahlweise ein tragbarer Datenträger, beispielsweise eine Chipkarte, ein Chipkartenmodul zum Einbau in eine Chipkarte, oder ein volumiges Token mit den Funktionen eines Chipkartenmoduls oder einer Chipkarte und mit, im Unterschied zur Chipkarte, einem volumigen Körper. Alternativ ist als Sicherheitsmodul ein zum festen Einbau in ein Endgerät (Computer, PDA, Smart Phone, Mobiltelefon etc.) vorgesehenes, zumindest logisch gegenüber dem Endgerät abgegrenztes Sicherheitsmodul vorgesehen.
-
Der Stand der Technik wird am Beispiel der Chipkarte erläutert, kann aber für andere Arten von Sicherheitsmodulen ebenso zutreffend sein.
-
Die Kommunikation einer Chipkarte erfolgt stets gegenüber einem Host, beispielsweise einem Kartenleser, einem Endgerät, einem Chipkartenterminal wie z. B. einem Zahlungsverkehrsterminal, einem Hintergrundsystem (wie z. B. beim Mobilfunk), einem Testtool zum Testen von Chipkarten oder einer Produktionsanlage für die Produktion von Chipkarten, insbesondere einer Produktionsanlage zum Einspielen von Software wie Daten und/oder Programmcode in Chipkarten.
-
Bei einer Vielzahl von gesicherten Kommunikationsvorgängen ist es erforderlich, dass sich die Chipkarte gegenüber dem Host authentisiert oder umgekehrt der Host sich gegenüber der Chipkarte authentisiert, oder dass sich die Chipkarte und der Host gegenseitig authentisieren.
-
Die Authentisierung im Chipkartenbereich wird in der Regel nach dem Challenge-Response-Verfahren durchgeführt. Damit sich eine Chipkarte gegenüber einem Host authentisiert, sendet der Host zunächst an die Chipkarte den sogenannten Challenge mit einer zufällig erzeugten Frage, in der Regel einer (Pseudo-)Zufallszahl. Die Chipkarte berechnet mit einem Algorithmus ein Kryptogramm und sendet das Kryptogramm als Antwort, als sogenannten Response, an den Host. Der Host berechnet das Kryptogramm zudem selbst und vergleicht es mit dem im Response von der Chipkarte erhaltenen Kryptogramm. Stimmen die Kryptogramme überein, hat sich die Chipkarte gegenüber dem Host authentisiert. Die umgekehrte Authentisierung funktioniert analog.
-
Als Algorithmus wird ein Verschlüsselungsalgorithmus mit einem geheimen, für die Chipkarte individuellen Schlüssel verwendet, der das Geheimnis von Chipkarte und Host ist, und der in der Chipkarte abgespeichert ist. Durch die Anwendung des Verschlüsselungsalgorithmus auf den Challenge (die Zufallszahl), den individuellen Schlüssel und ggf. weitere Eingabedaten wird das Kryptogramm erzeugt. Insbesondere bei einer gegenseitigen Authentisierung erzeugen sowohl der Host als auch die Chipkarte jeweils eine Zufallszahl (Rost Challenge und Card Challenge), wobei in jedes Kryptogramm beide Zufallszahlen (Rost Challenge und Card Challenge) eingehen können. Der Response kann außer dem Kryptogramm noch weitere Daten enthalten, beispielsweise eine Seriennummer des Chips der Chipkarte.
-
In einigen Chipkarten ist ein Satz von mehreren zusammengehörigen Schlüsseln abgespeichert. In diesem Fall können an der Authentisierung zwischen Chipkarte und Host mehrere Schlüssel aus diesem Satz beteiligt sein, z. B. nacheinander. In einigen Chipkarten sind mehrere unabhängige Schlüssel bzw. Schlüsselsätze gespeichert. In diesem Fall wird zur Authentisierung zwischen Chipkarte und Host nur ein einzelner Schlüssel bzw. Schlüsselsatz verwendet.
-
Bei der Chipkartenproduktion kommt es vor, dass nacheinander unterschiedliche Schlüssel oder Schlüsselsätze in die Chipkarte gespeichert werden. Es ist möglich, zusätzliche Schlüssel oder Schlüsselsätze in die Chipkarte zu speichern, bereits in der Karte befindliche Schlüssel oder Schlüsselsätze durch neue Schlüssel oder Schlüsselsätze zu ersetzen, oder bereits in der Karte befindliche Schlüssel oder Schlüsselsätze zu löschen. Zu einem bestimmten Zeitpunkt während der Chipkartenproduktion können ein einziger Schlüssel oder Schlüsselsatz oder mehrere Schlüssel oder Schlüsselsätze in der Karte gespeichert sein. Im Fall mehrerer Schlüssel oder Schlüsselsätze kann die Authentisierung mit einem von diesen mehreren erfolgen. Im Lauf der Chipkartenproduktion kommt es vor, dass nacheinander mehrere Authentisierungen zwischen Chipkarte und Host mit unterschiedlichen Schlüsseln durchgeführt werden, beispielsweise jeweils nachdem ein Schlüssel oder Schlüsselsatz geändert worden ist, z. B. falls ein Schlüssel oder Schlüsselsatz zusätzlich in die Chipkarte gespeichert worden ist, ersetzt worden ist, oder gelöscht worden ist.
-
Bei der Chipkartenproduktion werden häufig mehrere separate Aufträge gleichzeitig in ein und derselben Produktionsanlage bearbeitet. Jeder Auftrag umfasst im Normalfall mindestens eine Chipkarte, und in aller Regel einen Satz von Chipkarten mit einer Mehrzahl von gleichartigen Chipkarten.
-
Die Chipkarten unterschiedlicher Aufträge sind dagegen in der Regel unterschiedlich. Bei den mehreren gleichartigen Chipkarten eines Auftrags gibt es in der Regel entweder einen für alle Chipkarten identischen Hauptschlüssel (Masterkey), aus dem sich die unterschiedlichen individuellen Schlüssel für die einzelnen Chipkarten des Auftrags ableiten lassen, oder alle Chipkarten des Auftrags enthalten den gleichen individuellen Schlüssel. Die Hauptschlüssel (Masterkeys) bzw. die in den Karten enthaltenen individuellen Schlüssel der unterschiedlichen Aufträge sind i. d. R. unterschiedlich, es kann aber auch vorkommen, dass die Aufträge zumindest teilweise zu Gruppen geordnet sind, und die Aufträge einer Gruppe haben alle denselben Schlüssel. Im Folgenden wird der Schlüssel zu einem Auftrag als Auftragsschlüssel bezeichnet. Als Auftragsschlüssel kann ein individueller Schlüssel vorgesehen sein, der in ein oder mehreren Karten abgespeichert ist, oder ein Hauptschlüssel, der nicht in einer Karte abgespeichert ist, aus dem sich aber individuelle Schlüssel, die in Karten abgespeichert sind, ableiten lassen.
-
Herkömmlicherweise wird der Produktionsanlage die Zuordnung, welcher Auftragsschlüssel zu welchem Auftrag gehört, explizit zur Verfügung gestellt, beispielsweise in Form einer Tabelle. Gerade wenn eine größere Anzahl von Aufträgen zu bearbeiten ist, ist der Verwaltungsaufwand zur sorgfältigen Verwaltung der Auftragsschlüssel der einzelnen Aufträge erheblich und die Schlüsselverwaltung fehleranfällig. Dabei kann es vorkommen, dass zwar die Gesamtmenge der Auftragsschlüssel für alle gerade in der Produktionsanlage befindlichen Aufträge der Produktionsanlage bekannt ist, jedoch die Zuordnung der Auftragsschlüssel zu den einzelnen Aufträgen nicht mehr mit Sicherheit nachvollziehbar ist. In diesem Fall muss der Auftragsschlüssel zu einem bestimmten Auftrag durch Ausprobieren ermittelt werden. Hierzu wird, gegenüber der einzigen Chipkarte bzw. einer beliebig herausgegriffenen Chipkarte des Auftrags, aus einem aus der Gesamtmenge der Auftragsschlüssel beliebig ausgewählten Auftragsschlüssel ein individueller Schlüssel abgeleitet und eine probeweise Authentisierung durchgeführt. Der individuelle Schlüssel wird entweder unter Verwendung einer von der Chipkarte zuvor erhaltenen eindeutigen Kennung der Chipkarte, z. B. der Seriennummer der Chipkarte, berechnet oder, falls der Auftragsschlüssel bereits ein individueller Schlüssel ist, durch direkte Zuweisung abgeleitet. Falls der herausgegriffene Auftragsschüssel der richtige zu dem Auftrag ist, wird die Authentisierung mit dem abgeleiteten individuellen Schlüssel erfolgreich beendet. Falls nicht, müssen solange erneute Authentisierungsversuche mit weiteren Auftragsschlüsseln durchgeführt werden, bis der richtige Auftragsschlüssel zu dem Auftrag ermittelt ist. Das Durchführen einer solchen Vielzahl von Authentisierungsversuchen kostet Produktionszeit und erhöht somit die Produktionskosten.
-
Viele der heutigen Chipkarten sind durch einen Fehlbedienungszähler abgesichert, der die Anzahl von möglichen fehlschlagenden Authentisierungen begrenzt und, falls die Anzahl erreicht wird, die Chipkarte gegen eine weitere Verwendung sperrt. Daher werden herkömmlicherweise bei Versuchen, den Auftragsschlüssel durch Ausprobieren herauszufinden, etliche Chipkarten gesperrt und im schlimmsten Fall sogar unbrauchbar. Zumindest führt das wieder Entsperren der gesperrten Chipkarten zu Zeitverlusten bei der Produktion und daher zu erhöhten Produktionskosten.
-
DE 43 39 460 C1 beschreibt ein Authentisierungsverfahren mit einem Fehlbedienungszähler (Fehlerzähler) bei einer Chipkarte mit einem Wertspeicher (z. B. Telefonkarte). Vor jedem Authentisierungsvorgang wird zunächst eine Sperre in der Chipkarte eingerichtet. Anschließend wird der Fehlbedienungszähler inkrementiert – sofern sein Zählerstand noch ein Inkrementieren erlaubt – und dadurch die Sperre aufgehoben. Nachfolgend wird eine Authentisierung zwischen der Chipkarte und einem Endgerät durchgeführt. Sofern die Authentisierung erfolgreich abgeschlossen wird, wird der Fehlbedienungszähler wieder dekrementiert. Wird die Authentisierung erfolglos abgeschlossen, bleibt der Fehlbedienungszähler auf seinem inkrementierten Zählerstand. Durch eine Höchstgrenze des Zählerstandes des Fehlbedienungszählers wird die Anzahl möglicher Authentisierungen nach oben begrenzt und ggf. die Chipkarte gesperrt.
-
Aus dem Dokument
WO 2007/067638 A1 aus dem Stand der Technik ist ein Verfahren zur Authentisierung eines Peripheriegeräts („accessory” 202) gegenüber einem Mobiltelefon entnehmbar. Gemäß
3, Block 308 wird bei dem Peripheriegerät mit einem Schlüssel ein erstes Kryptogramm berechnet (Hash2), und das erste Kryptogramm (Hash2) an das Mobiltelefon gesendet (Block 9). Beim Mobiltelefon wurde vorab mit einem Schlüssel ein zweites Kryptogramm berechnet (Hash1), und wird das zweite Kryptogramm (Hash1) mit dem ersten Kryptogramm (Hash2) auf Übereinstimmung geprüft (Block 312).
-
Aus dem Dokument
DE 199 19 909 C2 aus dem Stand der Technik ist ein Verfahren zum Versenden von signierten Nachrichten von unterschiedlichen Absendern an einen Empfänger entnehmbar. Dabei werden in einer Zentrale aus einem Hauptschlüssel eine Reihe von individuellen Signierschlüsseln für die unterschiedlichen Absender abgeleitet und in individuelle Chipkarten der Absender gespeichert (Spalte 3, Zeilen 31–35). Der Empfänger hat den Hauptschlüssel und kann damit mit individuellen Signierschlüsseln erzeugte Signaturen verifizieren (Spalte 3, Zeilen 60–67).
-
Der Erfindung liegt die Aufgabe zu Grunde, für ein Authentisierungsverfahren nach dem Challenge-Response-Verfahren ein einfaches, den Verwaltungsaufwand reduzierendes und Kosten sparendes Verfahren zur Ermittlung des Auftragsschlüssels eines vorbestimmten Auftrags von mehreren Aufträgen zu schaffen.
-
Die Aufgabe wird durch ein Verfahren nach dem unabhängigen Verfahrensanspruch 1 gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
-
Das erfindungsgemäße Verfahren ist zur Ermittlung des einem vorbestimmten Auftrag zugeordneten vorbestimmten Auftragsschlüssels bei einem System mit mehreren Aufträgen vorgesehen. Jedem Auftrag sind ein Auftragsschlüssel und mindestens ein Sicherheitsmodul zugeordnet. In dem bzw. in jedem Sicherheitsmodul eines Auftrags ist ein aus dem Auftragsschlüssel ableitbarer individueller Schlüssel abgespeichert. Der Auftragsschlüssel eines einzelnen Auftrags kann wahlweise sein: falls in allen Sicherheitsmodulen des Auftrags der gleiche Schlüssel abgespeichert ist, dieser sowohl beim Host als auch in allen Sicherheitsmodulen des Auftrags abgespeicherte gleiche individuelle Schlüssel; oder, falls in den einzelnen Sicherheitsmodulen des Auftrags unterschiedliche individuelle Schlüssel abgespeichert sind, ein beim Host abgespeicherter, für den Auftrag spezifischer Hauptschlüssel (Masterkey), der in den Sicherheitsmodulen nicht direkt abgespeichert ist, und aus dem sich beim Host die individuellen Schlüssel der einzelnen Sicherheitsmodule des Auftrags durch Berechnung ableiten lassen. Der Host kennt die Auftragsschlüssel der mehreren Aufträge, ohne die Zuordnung der Auftragsschlüssel zu den Aufträgen zu kennen. Das erfindungsgemäße Verfahren geht weiter aus von einem Authentisierungsverfahren nach dem Challenge-Response-Verfahren zur Authentisierung zwischen einem Host und einem der Sicherheitsmodule, d. h. zur Authentisierung eines der Sicherheitsmodule gegenüber dem Host oder zur gegenseitigen Authentisierung zwischen einem der Sicherheitsmodule und dem Host, wobei die Authentisierung des Sicherheitsmoduls gegenüber dem Host vor der Authentisierung des Hosts gegenüber dem Sicherheitsmodul stattfindet.
-
Gemäß der Erfindung wird der Auftragsschlüssel in einem einzigen zumindest teilweisen Authentisierungsversuch eines Sicherheitsmoduls gegenüber dem Host ermittelt.
-
Bei diesem Authentisierungsversuch wird ein vorbestimmtes Sicherheitsmodul ausgewählt. Dies kann jedes beliebige Sicherheitsmodul aus einem gewünschten Auftrag der mehreren Aufträge sein. Beim Sicherheitsmodul wird mit dem darin abgespeicherten individuellen Schlüssel ein erstes Kryptogramm berechnet und an den Host gesendet. Für das vorbestimmte Sicherheitsmodul wird beim Host aus dem Auftragsschlüssel mindestens eines der mehreren Aufträge, und höchstens für die Auftragsschlüssel jedes der Aufträge, mindestens ein individueller Schlüssel abgeleitet. Beim Host wird mit dem abgeleiteten individuellen Schlüssel ein zweites Kryptogramm berechnet. Das zweite Kryptogramm wird beim Host mit dem ersten Kryptogramm auf Übereinstimmung überprüft. An Hand desjenigen zweiten Kryptogramms, das mit dem ersten Kryptogramm übereinstimmt, wird der vorbestimmte Auftragsschlüssel des vorbestimmten Auftrags ermittelt.
-
Bei dem erfindungsgemäßen Verfahren ist es nicht erforderlich, dass der Host die Zuordnung zwischen den mehreren Aufträgen und den zugehörigen Auftragsschlüsseln kennt und verwaltet, sondern der Auftragsschlüssel wird durch Ausprobieren ermittelt. Daher spart das erfindungsgemäße Verfahren gegenüber dem Stand der Technik, bei dem eine Tabelle mit der Zuordnung zwischen Auftragsschlüsseln und Aufträgen verwendet wird, Verwaltungsaufwand. Dem erfindungsgemäßen Verfahren gemäß Anspruch 1 liegt weiter das besondere Prinzip zu Grunde, dass der Auftragsschlüssel in nur einem einzigen Authentisierungsversuch eines Sicherheitsmoduls gegenüber dem Host ermittelt wird, statt in mehreren Authentisierungsversuchen wie nach dem Stand der Technik. Das Berechnen der zweiten Kryptogramme und das Vergleichen mit dem ersten Kryptogramm erfolgt innerhalb des Hosts. Ein zeitraubender Datenverkehr zwischen Host und Sicherheitsmodul wie beim Durchführen mehrerer vollständiger Authentisierungsversuche gemäß dem Stand der Technik ist dabei nicht erforderlich. Bei der Authentisierung des Sicherheitsmoduls gegenüber dem Host ist lediglich ein einzelner Sendevorgang erforderlich, bei dem das vom Sicherheitsmodul berechnete erste Kryptogramm und ggf. weitere Daten vom Sicherheitsmodul an den Host gesandt werden. Folglich ist das erfindungsgemäße Verfahren einfach und spart gegenüber dem Stand der Technik den Aufwand für zusätzliche Authentisierungsversuche und damit Produktionskosten.
-
Wahlweise haben alle Aufträge unterschiedliche Auftragsschlüssel. Wahlweise haben zwei oder mehr Aufträge, aber dabei vorzugsweise nicht alle Aufträge, identische Auftragsschlüssel.
-
Wahlweise wird vom Host ein Challenge an das Sicherheitsmodul gesendet und das erste Kryptogramm in Reaktion auf den Challenge berechnet.
-
Wahlweise wird das vom Sicherheitsmodul berechnete erste Kryptogramm in einem Response auf den Challenge an den Host gesendet.
-
Der Auftragsschlüssel eines Auftrags ist wahlweise ein Hauptschlüssel, aus dem sich individuelle Schlüssel für alle Sicherheitsmodule eines Auftrags ableiten lassen. In diesem Fall wird der individuelle Schlüssel aus dem Auftragsschlüssel durch Berechnung abgeleitet, wahlweise unter Verwendung eines individuellen Datums des Sicherheitsmoduls, beispielsweise einer Seriennummer des Sicherheitsmoduls oder eines darin vorgesehenen Chips. Das individuelle Datum wird wahlweise vom Sicherheitsmodul zusammen mit dem ersten Kryptogramm an den Host gesendet. Alternativ ist der Auftragsschlüssel direkt der identische Schlüssel aller Sicherheitsmodule eines Auftrags, der in jedem Sicherheitsmodul des Auftrags abgespeichert ist. In diesem Fall erfolgt die Ableitung des individuellen Schlüssels aus dem Auftragsschlüssel durch einfache direkte Zuweisung. Wahlweise umfasst ein Auftrag mehrere Sicherheitsmodule oder nur ein einziges Sicherheitsmodul.
-
Das Sicherheitsmodul ist wahlweise eine Chipkarte (Smart Card) oder anderweitig gestaltet wie eingangs beschrieben.
-
Wahlweise wird beim Host zunächst nur für einen einzigen Auftragsschlüssel ein zweites Kryptogramm berechnet und anschließend das zweite Kryptogramm mit dem ersten Kryptogramm auf Übereinstimmung überprüft. Falls das zweite Kryptogramm mit dem ersten Kryptogramm übereinstimmt, wird der einzige Auftragsschlüssel als zu dem vorbestimmten Auftrag gehörig ermittelt. Falls die Kryptogramme nicht übereinstimmen, wird so lange ein weiteres zweites Kryptogramm mit einem weiteren einzelnen Auftragsschlüssel berechnet und anschließend mit dem im Sicherheitsmodul berechneten ersten Kryptogramm verglichen, bis der richtige Auftragsschlüssel ermittelt wird. Bei dieser Variante werden beim Host mindestens ein und höchstens so viele zweite Kryptogramme berechnet, wie Auftragsschlüssel sind und ggf. wie Aufträge vorhanden sind.
-
Alternativ werden beim Host auf jeden Fall die zweiten Kryptogramme zu allen Auftragsschlüsseln (bzw. ggf. Aufträgen) berechnet und anschließend die zweiten Kryptogramme mit dem ersten Kryptogramm auf Übereinstimmung verglichen.
-
Wahlweise wird zur Berechnung des jeweiligen Kryptogramms zuerst mit dem individuellen Schlüssel und der Zufallszahl mindestens ein Sitzungsschlüssel berechnet. Anschließend wird mit dem bzw. mindestens einem Sitzungsschlüssel das Kryptogramm berechnet. Wahlweise fließen in die Berechnung des Sitzungsschlüssels die vom Host erzeugte Zufallszahl und/oder eine vom Sicherheitsmodul erzeugte weitere Zufallszahl und/oder der Wert des im Sicherheitsmodul geführten Zählers ein. Bedarfsweise sendet das Sicherheitsmodul zusammen mit dem Kryptogramm zusätzlich die weitere Zufallszahl und/oder den Wert des Zählers an den Host. Wahlweise sendet das Sicherheitsmodul zusammen mit dem Kryptogramm individuelle Daten des Sicherheitsmoduls an den Host, z. B. die Seriennummer eines im Sicherheitsmodul vorgesehenen Chips. Wahlweise wird zur Berechnung des Kryptogramms ein Triple-DES-Algorithmus verwendet. Wahlweise werden drei Sitzungsschlüssel berechnet. Das Kryptogramm kann insbesondere berechnet werden wie in der Global Platform Card Specification Version 2.1.1, March 2003, beschrieben ist, insbesondere im Kapitel D. Secure Channel Protocol 01 oder im Kapitel E. Secure Channel Protocol 02.
-
Zufallszahlen für Kryptogramme nach der Global Platform Card Specification sind beispielsweise 8 Byte lang oder 6 Byte lang.
-
Wahlweise wird in einem weiteren Schritt eine Authentisierung des Hosts gegenüber dem Sicherheitsmodul mit dem ermittelten Auftragsschlüssel durchgeführt.
-
Gemäß einer Ausführungsform der Erfindung ist das Sicherheitsmodul mit einem Fehlbedienungszähler (FBZ) gesichert, durch den die Anzahl fehlgeschlagener Authentisierungen des Hosts gegenüber dem Sicherheitsmodul auf eine zulässige Höchstzahl begrenzt ist. Bei dieser Ausführungsform werden keine fehlgeschlagenen Authentisierungen durchgeführt, die deshalb fehlschlagen, weil der falsche Auftragsschlüssel verwendet worden ist. Folglich hat diese Ausführungsform des Verfahrens den zusätzlichen Vorteil, dass die Gefahr, dass Sicherheitsmodule bei der Schlüsselermittlung gesperrt werden, gegenüber dem Stand der Technik verringert ist.
-
Bei einer weiteren Ausführungsform des Verfahrens wird vor der Vollendung der Authentisierung des Hosts gegenüber dem Sicherheitsmodul ein Fehlbedienungszähler inkrementiert, d. h. in Richtung auf einen zulässigen Grenzzählerstand (z. B. einen betragsmäßigen Maximalwert oder Null), der eine Höchstzahl zulässiger fehlgeschlagener Authentisierungen widerspiegelt, verändert.
-
Wahlweise wird der Fehlbedienungszähler (FBZ) wieder dekrementiert, insbesondere auf einen Anfangswert zurückgesetzt, falls die Authentisierung des Hosts gegenüber dem Sicherheitsmodul erfolgreich abgeschlossen wird.
-
Wahlweise wird das erfindungsgemäße Verfahren mindestens zweimal oder mehrmals nacheinander mit unterschiedlichen individuellen Schlüsseln durchgeführt. Wahlweise wird das Verfahren erneut durchgeführt, falls in ein Sicherheitsmodul ein neuer individueller Schlüssel gespeichert worden ist, insbesondere falls der bisherige individuelle Schlüssel seine Gültigkeit im Sicherheitsmodul verliert oder überspeichert oder gelöscht wird und der neue individuelle Schlüssel gültig wird. Wahlweise wird das Verfahren erneut durchgeführt, falls im Sicherheitsmodul ein anderer, neuer individueller Schlüssel als der bisher gültige individuelle Schlüssel gültig wird, beispielsweise durch Aktivieren des neuen individuellen Schlüssels und Deaktivieren des bisher gültigen individuellen Schlüssels.
-
Wahlweise sind an der Authentisierung zwischen Host und Sicherheitsmodul mehrere in einem einzigen Sicherheitsmodul abgespeicherte Schlüssel beteiligt. Dies kann beispielsweise der Fall sein, falls in einem Sicherheitsmodul ein Satz von mehreren zusammengehörigen Schlüsseln abgespeichert ist. Falls in einem Sicherheitsmodul mehrere unabhängige individuelle Schlüssel abgespeichert sind, geht wahlweise einer von den mehreren individuellen Schlüssel in die Berechnung der Kryptogramme ein.
-
Die Authentisierung des ausgewählten vorbestimmten Sicherheitsmoduls gegenüber dem Host wird wahlweise auf die folgende Weise zumindest teilweise durchgeführt, genauer mit den folgenden Schritten. In einem ersten Schritt wird beim Host eine erste Zufallszahl erzeugt. In einem zweiten Schritt wird ein Challenge mit der Zufallszahl vom Host an das vorbestimmte Sicherheitsmodul gesendet. In einem dritten Schritt wird beim Sicherheitsmodul eine zweite Zufallszahl erzeugt. Optional wird im dritten Schritt oder an einer anderen Stelle der Authentisierung zwischen Host und Sicherheitsmodul ein interner Zähler des Sicherheitsmoduls erhöht. Wahlweise wird beim Sicherheitsmodul aus dem individuellen Schlüssel, der ersten und/oder der zweiten Zufallszahl und/oder dem Zählerstand des Zählers mindestens ein Sitzungsschlüssel berechnet. Mit der ersten und/oder der zweiten Zufallszahl und/oder dem Zählerstand des Zählers und entweder dem individuellen Schlüssel oder dem mindestens einen Sitzungsschlüssel berechnet das Sicherheitsmodul das erste Kryptogramm. Das Sicherheitsmodul sendet einen Response auf den Challenge an den Host. Der Response enthält das erste Kryptogramm, wahlweise individuelle Daten des Sicherheitsmoduls (z. B. Seriennummer eines Chips des Sicherheitsmoduls), wahlweise die zweite Zufallszahl, wahlweise den Zählerstand (Wert) des internen Zählers und wahlweise weitere Daten. Der Host leitet aus dem Auftragsschlüssel den individuellen Schlüssel ab, wahlweise unter Verwendung individueller Daten des Sicherheitsmoduls (z. B. einer Seriennummer des Chips des Sicherheitsmoduls), entweder durch Berechnung oder durch direkte Zuweisung. Der Host leitet ggf. den mindestens einen Sitzungsschlüssel ab. Der Host berechnet das zweite Kryptogramm, mit der ersten und/oder der zweiten Zufallszahl und/oder dem Zählerstand des Zählers und entweder dem individuellen Schlüssel oder dem mindestens einen Sitzungsschlüssel, nach dem analogen Verfahren wie das Sicherheitsmodul das erste Kryptogramm berechnet hat. Der Host vergleicht das erste und das zweite Kryptogramm auf Übereinstimmung.
-
Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigen:
-
1 eine Anordnung mit mehreren Aufträgen mit jeweils mehreren Chipkarten, in denen jeweils ein individueller Schlüssel abgespeichert ist, gemäß einer Ausführungsform der Erfindung;
-
2 ein schematisches Ablaufdiagramm der Ermittlung eines Auftragsschlüssels, gemäß einer Ausführungsform der Erfindung.
-
1 zeigt eine Anordnung mit mehreren Chipkarten, von denen jede einem von mehreren Aufträgen zugeordnet ist. Jedem Auftrag ist ein Auftragsschlüssel A1, A2, ... Aj, ... An zugeordnet. In jeder Chipkarte ist ein individueller Schlüssel KCi, i = 1...j...n abgespeichert, der in 1 für alle Chipkarten desselben Auftrags der gleiche ist. Im Beispiel aus 1 ist der Auftragsschlüssel eines Auftrags identisch mit den individuellen Schlüsseln der Chipkarten, die dem Auftrag zugeordnet sind, so dass der individuelle Schlüssel also durch direkte Zuweisung ableitbar ist.
-
2 zeigt ein schematisches Ablaufdiagramm der Ermittlung des Auftragsschlüssels Aj eines vorbestimmten Auftrags, beispielsweise des Auftragsschlüssels Aj aus 1, gemäß einer Ausführungsform der Erfindung. Das in 2 dargestellte Verfahren ist an den Verfahrensablauf gemäß Global Platform Card Specification Version 2.1.1, March 2003, Kapitel D.4 Secure Channel APDU Commands angelehnt, genauer Kapitel D.4.1, „SECURE CHANNEL PROTOCOL '01' (SCP01)”. Zunächst werden die Auftragsschlüssel A1, A2, Aj, ... An aller Aufträge an den Host zur Verfügung gestellt, ohne dass der Host die Zuordnung zwischen den Aufträgen und den Auftragsschlüsseln A1, A2, ... Aj, ... An kennt, und ein Auftrag j ausgewählt, dessen Auftragsschlüssel ermittelt werden soll. Zudem wird aus dem Auftrag j eine beliebige Chipkarte mit einem individuellen Schlüssel KCj ausgewählt, an der stellvertretend für den gesamten Auftrag der Auftragsschlüssel Aj ermittelt werden soll. In Schritt 1 wird im Host eine Zufallszahl RNDH erzeugt. In Schritt 2 wird mit einem Kommando zum Authentisieren der Chipkarte die Zufallszahl RNDH als Challenge an die ausgewählte Chipkarte gesendet. Das Kommando kann beispielsweise das Chipkarten-Kommando INITIALIZE UPDATE aus der Global Platform Card Specification Version 2.1.1, March 2003, Kapitel D.4 Secure Channel APDU Commands sein, genauer Kapitel D.4.1, falls für die Kommunikation zwischen Host und Chipkarte das „SECURE CHANNEL PROTOCOL '01' (SCP01)” verwendet wird. In Schritt 3 wird in der ausgewählten Chipkarte eine weitere Zufallszahl RNDC erzeugt und ein Fehlbedienungszähler inkrementiert. Das Inkrementieren des Fehlbedienungszählers erfolgt hier nach dem Erzeugen der weiteren Zufallszahl RNDC in der Chipkarte, kann aber wahlweise auch an einem anderen Punkt im Verfahrensablauf erfolgen, insbesondere vor dem Senden der Antwort in Schritt 6 (vgl. weiter unten), insbesondere an einem beliebigen Punkt während der Verarbeitung des Kommandos (z. B. INITIALIZE UPDATE). In Schritt 4 wird bei der Chipkarte aus dem individuellen Schlüssel KCj, der Zufallszahl RNDH und der weiteren Zufallszahl RNDC ein Sitzungsschlüssel KSj, beispielsweise der Sitzungsschlüssel KSenc gemäß SCP01, berechnet. In Schritt 5 wird bei der Chipkarte aus dem Sitzungsschlüssel KSj, der Zufallszahl RNDH und der weiteren Zufallszahl RNDC ein erstes Kryptogramm CRYPTC-Cj berechnet. In Schritt 6 wird als Response auf den Challenge eine Antwort mit der weiteren Zufallszahl RNDC, dem Kryptogramm CRYPTC-Cj und individuellen Daten der Chipkarte (z. B. der Seriennummer des Chips der Chipkarte) an den Host gesandt. Die Antwort ist wahlweise gemäß der Antwort auf INITIALIZE UPDATE in dem oben genannten Kapitel D.4.1 (SCP01) gestaltet, falls für die Kommunikation zwischen Host und Chipkarte das „SECURE CHANNEL PROTOCOL '01' (SCP01)” verwendet wird. In Schritt 7 wird beim Host für alle Auftragsschlüssel Ai der individuelle Schlüssel KCi, i = 1...j...n der Chipkarte abgeleitet, unter Verwendung der von der Chipkarte erhaltenen individuellen Daten (z. B. der Seriennummer des Chips der Chipkarte). In Schritt 8 wird beim Host aus dem jeweiligen individuellen Schlüssel KCi, der ersten Zufallszahl RNDH und der zweiten Zufallszahl RNDC ein Sitzungsschlüssel KSi berechnet und in Schritt 9 aus dem Sitzungsschlüssel KSi, RNDH und RNDC jeweils ein zweites Kryptogramm CRYPTC-Hi berechnet. In Schritt 10 wird das von der Chipkarte berechnete Kryptogramm CRYPTC-Cj mit den vom Host berechneten Kryptogrammen CRYPTC-Hi, i = 1...j...n verglichen. Dabei ergibt sich, dass das vom Host selbst berechnete Kryptogramm CRYPTC-Hi, i = j mit dem von der Chipkarte erhaltenen Kryptogramm CRYPTC-Cj übereinstimmt. Hierdurch erfährt der Host, dass Aj der Auftragsschlüssel zum Auftrag j ist.
-
Bei dem an Hand von 2 beschriebenen Verfahren kann alternativ das Chipkarten-Kommando INITIALIZE UPDATE gemäß F.5, genauer E.5.1, und die Antwort auf dieses Kommando verwendet werden, falls das „SECURE CHANNEL PROTOCOL '02' (SCP02)” verwendet wird. Für ein Verfahren in Anlehnung an das „SECURE CHANNEL PROTOCOL '02' (SCP02)” (Kapitel F.5.1) ist der Verfahrensablauf im Einzelnen teilweise abweichend von 2.
-
Wahlweise authentisiert sich nachfolgend der Host gegenüber der Chipkarte (Schritt 11), im Wesentlichen analog der Authentisierung der Chipkarte gegenüber dem Host, jedoch mit dem ermittelten Auftragsschlüssel Aj, oder genauer mit einem aus dem ermittelten Auftragsschlüssel Aj abgeleiteten individuellen Schlüssel. Wahlweise wird der Zählerstand des internen Zählers der Chipkarte im Verlauf der Authentisierung des Hosts gegenüber der Chipkarte erhöht. Die Authentisierung kann beispielsweise gemäß der Global Platform Card Specification Version 2.1.1, March 2003 erfolgen und durch das Kommando EXTERNAL AUTHENTICATE Kapitel D.4.2 (SCP01) oder F.5.2 (SCP02) veranlasst werden. Bei Chipkarten gemäß Global Platform 2.1.1 ist sowohl bei SCP01 als auch bei SCP02 die Authentisierung des Hosts gegenüber der Chipkarte zwingend. Erst nach einer erfolgreichen Authentisierung des Host gegenüber der Chipkarte wird der Fehlbedienungszähler FBZ wieder auf seinen Ausgangswert (d. h. Anfangswert) rückgesetzt.
-
Bei der Ausführungsform aus 2 werden zuerst Kryptogramme zu allen Auftragsschlüsseln berechnet und anschließend werden die Kryptogramme verglichen. Alternativ wird beim Host jeweils nur ein einziges Kryptogramm für einen einzigen Auftragsschlüssel berechnet und dieses mit dem von der Chipkarte berechneten Kryptogramm verglichen, bevor ein Kryptogramm für einen weiteren Auftragsschlüssel berechnet wird. Sobald der Auftragsschlüssel des gewünschten Auftrags ermittelt ist, wird beim Host das Berechnen von Kryptogrammen für Auftragsschlüssel abgebrochen. Bei dieser alternativen Ausführungsform werden beim Host mindestens ein und höchstens so viele Kryptogramme berechnet wie Auftragsschlüssel vorhanden sind.
