DE112012002277B4

DE112012002277B4 - Verknüpfen von Schlüssel-Steuerdaten bei Diensten allgemeiner kryptografischer Architektur

Info

Publication number: DE112012002277B4
Application number: DE112012002277.7T
Authority: DE
Inventors: Richard Victor Kisley; Todd Weston Arnold; Carsten Dahl Frehr
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-06-01
Filing date: 2012-05-29
Publication date: 2021-09-23
Anticipated expiration: 2032-05-30
Also published as: CN103563290B; US8953792B2; US20120308000A1; GB2505609A; GB201322085D0; DE112012002277T5; GB2505609B; US8953789B2; CN103563290A; WO2012164487A1; US20130044875A1

Abstract

Verfahren zum Erzeugen eines Schlüssel-Token, wobei das Verfahren aufweist:Empfangen eines ersten Schlüssel-Token, eines zweiten Schlüssel-Token und einer Anforderung zum Verknüpfen des ersten Schlüssel-Token mit dem zweiten Schlüssel-Token;Ermitteln, ob der erste Schlüssel-Token und der zweite Schlüssel-Token gültige Tokens allgemeiner kryptografischer Architektur (CCA) für einen bestimmten Verschlüsselungsalgorithmus sind;Ermitteln, ob der erste Schlüssel-Token und der zweite Schlüssel-Token die Schlüssel des bestimmten Verschlüsselungsalgorithmus enthalten, die eine gewünschte Anzahl von Bytes aufweisen; undFeststellen eines ersten Schlüsseltyps des ersten Schlüssel-Token und eines Schlüsseltyps des zweiten Schlüssel-Token, in Reaktion auf einem Feststellen, dass es sich bei dem ersten Schlüssel-Token und dem zweiten Schlüssel-Token um gültige CCA-Tokens für den bestimmten Verschlüsselungsalgorithmus handelt und dass der erste Schlüssel-Token und der zweite Schlüssel-Token die Schlüssel des bestimmten Verschlüsselungsalgorithmus mit der gewünschten Anzahl von Bytes enthalten;Ermitteln, ob der Schlüsseltyp des ersten Schlüssel-Token mit dem Schlüsseltyp des zweiten Schlüssel-Token verknüpft werden kann;Verknüpfen des ersten Schlüssel-Token mit dem zweiten Schlüssel-Token, um einen dritten Schlüssel-Token zu erzeugen in Reaktion auf ein Feststellen, dass der Schlüsseltyp des ersten Schlüssel-Token mit dem Schlüsseltyp des zweiten Schlüssel-Token verknüpft werden kann; undAusgeben des dritten Schlüssel-Token.

Description

HINTERGRUND
Die vorliegende Erfindung bezieht sich auf kryptografische Schlüssel und insbesondere auf kryptografische Schlüssel bei Diensten allgemeiner kryptografischer Architektur (common cryptographic architecture, CCA).
Die CCA wird häufig bei Finanzdiensten wie z.B. Zahlungskartendiensten verwendet, um Finanzdaten wie z.B. Kontodaten und Prüfcodes eines Benutzers zu schützen. Die CCA spezifiziert eine Byte-Anordnung aus Schlüssel-Steuerdaten, die als Steuervektor (CV) bezeichnet wird, der an einen kryptografischen Schlüssel wie etwa ein Schlüssel des Datenverschlüsselungs-Standards (DES) gebunden ist, der unter Verwendung eines physisch sicheren Hardware-Sicherheitsmoduls (HSM) gesichert ist. Der CV wird sowohl beim Management des Schlüssels als auch zum Steuern der Schlüsselnutzung verwendet.
Bits in dem CV repräsentieren z.B. einen Schlüsseltyp, der umfangreiche Fähigkeiten des Schlüssels identifiziert, z.B. ob der Schlüssel in der Lage ist, Daten zu verschlüsseln und/oder zu entschlüsseln, Schlüssel einzuhüllen oder zu enthüllen (wrap oder unwrap), Nachrichtenechtheit-Überprüfungscodes (message authentication codes - MACs) zu berechnen oder zu überprüfen, Daten einer persönlichen Kennzahl (PIN-Daten) zu verschlüsseln oder zu entschlüsseln und PIN-Daten zu erzeugen oder zu überprüfen. Die CV-Bits können außerdem einen Schlüssel-Untertyp darstellen, der eine Einschränkung von Schlüsselfähigkeiten bei Aktionen darstellt, die durch den Schlüsseltyp unterstützt werden wie etwa eine Einschränkung, dass der Schlüssel entweder zum Verschlüsseln oder zum Entschlüsseln, jedoch nicht für beides verwendet werden kann. Die CV-Bits können Schlüsselmanagement-Angaben enthalten, die steuern, ob der Schlüssel verteilt werden kann, und wenn das der Fall ist, ob der Schlüssel exportiert werden kann, wenn er in einem Schlüsselblock eingehüllt (wrapped) ist. Die Schlüsselnutzung kann außerdem in den CV-Bits dargestellt werden. Die Schlüsselnutzung steuert, wie der Schlüssel über die Begrenzungen hinaus verwendet werden kann, die durch den Schlüsseltyp und den Schlüssel-Untertyp eingeführt werden wie z.B. Einschränkungen hinsichtlich des Typs von Daten, die von dem Schlüssel verarbeitet werden können sind, oder die Typen von Schlüsseln, die mit dem Schlüssel eingehüllt werden können.
Der CV hat gewöhnlich eine Länge von 8 Byte oder 16 Byte, die mit der Länge eines DES-Schlüssels übereinstimmt, an den er gebunden ist. Der CV ist gewöhnlich in einer CCA-Datenstruktur enthalten, die als Schlüssel-Token bezeichnet wird, der außerdem eine eingehüllte Version des Schlüssels enthält. Der Einhüllungsvorgang (Wrapping Process) bindet den CV kryptografisch an den Schlüssel, so dass eine Veränderung des CV den resultierenden Wert des Schlüssels im enthüllten Zustand ändert, wodurch der Schlüssel nutzlos wird.
In diesem Zusammenhang wurden bereits einige Dokument veröffentlicht. Beispielsweise beschriebt das Dokument US 2010 / 0 031 021 A1 ein Verfahren für eine Implementierung einer Datenstruktur, die für Instruktionen einen kryptographische Schutz gegen Veränderungen oder Missbrauch aufweisen. Dazu wird ein Trusted-Block verwendet, der spezifische Schlüssel-Management-Regeln aufweist. Andererseits beschreibt das Dokument US 2010 / 0 158 247 A1 ein Verfahren für eine Implementierung von 3DES und anderen kryptographischen Algorithmen. Auch hier wird ein Sicherheitsblock genutzt, der Steuerungs-, Schüssel- und Hash-Felder aufweist.
Als Aufgaben des vorgestellten Verfahrens wird eine Überwindung des oben angerissenen Problems von separaten 8- oder 16-Bit-Schlüsseln angesehen. Dadurch sollen kryptographische Schlüssel - insb. bei Zahlungskartendiensten - zuverlässiger einsetzbar sein.
ZUSAMMENFASSUNG
Diese Aufgabe wird durch die unabhängigen Ansprüche gelöst. Weitere Ausgestaltungen ergeben sich aus den jeweiligen Ansprüchen.
Zusätzliche Merkmale und Vorteile werden durch die beschriebene Technik der vorliegenden Erfindung realisiert. Weitere Ausführungsformen und Aspekte der Erfindung werden hier genau beschrieben und als ein Teil der beanspruchten Erfindung betrachtet. Für ein besseres Verständnis der Erfindung mit den Vorteilen und Merkmalen ist auf die Beschreibung und die Zeichnungen Bezug zu nehmen.
Figurenliste
Der Gegenstand, der als die Erfindung betrachtet wird, wird in den Ansprüchen am Ende der Beschreibung besonders hervorgehoben und deutlich beansprucht. Das Vorhergehende und weitere Merkmale und Vorteile der Erfindung werden aus der folgenden genauen Beschreibung deutlich, die in Verbindung mit den beigefügten Zeichnungen erfolgt, worin:

1 eine beispielhafte Ausführungsform eines Systems veranschaulicht;
die 2A bis 2B einen Ablaufplan eines beispielhaften Verfahrens veranschaulichen, das durch das System von 1 ausgeführt werden kann;
3 eine Tabelle veranschaulicht, die durch das System von 1 verwendet werden kann; und
4 ein Blockschaubild eines beispielhaften Verfahrens zum Erzeugen eines Schlüssel-Token veranschaulicht, das durch das System von 1 ausgeführt werden kann.

GENAUE BESCHREIBUNG
Ein Beispiel eines Dienstes allgemeiner kryptografischer Architektur (CCA-Dienst) wird als Kartenprüfwert-Erzeugung (CW-Erzeugen) bezeichnet, bei der zwei 8-Byte-CCA-Schlüssel verwendet werden, um Zahlungskarten-Prüfwerte zu erzeugen. Ein weiterer CCA-Dienst wird CW-Prüfen bezeichnet, bei dem entweder der ursprüngliche Satz von Schlüsseln oder in einigen Fällen ein zweiter Satz von Schlüsseln verwendet wird, der einen Steuervektor (CV) auf der Grundlage von Einschränkungen enthält, die lediglich bei dem Dienst CVV-Prüfen verwendet werden können, um CVVs zu prüfen.
Jeder Dienst verwendet zwei separate 8-Byte-Schlüssel-Tokens, die als key_a und key_b bezeichnet werden. Die kryptografischen Schlüssel, die in den Tokens eingehüllt sind, werden in den Diensten CW-Erzeugen und CW-Prüfen für unterschiedliche Zwecke verwendet. Der CCA-Dienst unterstützt drei Typen von Schlüsseln, die für key_a und key_b verwendet werden können. Zu den drei Typen von Schlüsseln gehören prozessspezifische Schlüssel, die für Dienste CVV-Prüfen und CW-Erzeugen verwendet werden, wobei die prozessspezifischen Schlüssel mit CVV-KEYA und CW-KEYB bezeichnet werden. Schlüssel, die Nachrichtenechtheit-Überprüfungscodes (MACs) sowie CWs berechnen können, werden als ANY-MAC-Schlüssel bezeichnet. Schlüssel, die MACs berechnen können sowie Daten verschlüsseln und entschlüsseln können sowie CWs berechnen können, werden als DATA-Schlüssel bezeichnet.
Gemäß früheren CCA-Spezifikationen wurden für key_a und key_b separate 8-Byte-Schlüssel verwendet. Gemäß bestimmten CCA-Spezifikationen kann ein einziger 16-Byte-Schlüssel für die Prozesse verwendet werden, wobei der 16-Byte-Schlüssel zwei Hälften enthält, wobei jede Hälfte unter Verwendung eines Einhüllungsvorgangs, der in einem Hardware-Sicherheitsmodul (HSM) umgesetzt wird, kryptografisch an den Schlüssel-Token gebunden ist.
Die Verfahren und Systeme, die nachfolgend beschrieben werden, ermöglichen Benutzern von Schemen, die die separaten 8-Byte-Schlüssel verwenden, die separaten 8-Byte-Schlüssel in einen einzigen 16-Byte-Schlüssel umzusetzen, während Steuerdaten und die Sicherheit der Schlüssel aufrechterhalten werden. Für veranschaulichende beispielhafte Zwecke enthalten die Beispiel-Schlüssel zwei 8-Byte-Schlüssel, die zu einem einzigen 16-Byte-Schlüssel verknüpft werden, wobei die beispielhaften Ausführungsformen jedoch nicht auf bestimmte Schlüssellängen beschränkt sind. Daher kann jede Anordnung aus einer beliebigen Anzahl von kürzeren Schlüsseln, die jede Schlüssellänge aufweisen können, zu einem einzigen größeren Schlüssel unter Verwendung von Verfahren und Systemen verknüpft werden, die den Verfahren und Systemen ähnlich sind, die nachfolgend beschrieben werden.
In diesem Zusammenhang veranschaulicht 1 eine beispielhafte Ausführungsform eines Systems 100. Das System 100 enthält einen Prozessor 102, der zum Datenaustausch mit einer Anzeigeeinheit 104, Eingabeeinheiten 106, einem Speicher 108, einer Vernetzungseinheit 110 und einem HSM 112 verbunden ist. Die Vernetzungseinheit 110 kann zum Datenaustausch mit Datenübertragungsnetzwerken 118 verbunden sein, die zum Datenaustausch mit weiteren Prozessoren (nicht gezeigt) verbunden sein können. Das HSM 112 enthält einen HSM-Prozessor 116, der zum Datenaustausch mit einem HSM-Speicher 114 verbunden ist.
Im Betrieb kann der Prozessor 102 z.B. Anwendungsprogrammierschnittstellen (APIs) ansteuern, die Verarbeitungsaufgaben ausführen und Datenpakete mit Rufparametern erzeugen und zu dem HSM 112 senden. Der HSM-Prozessor 116 empfängt und verarbeitet die Datenpakete und erzeugt ein Antwortpaket, das zu der anfordernden API gesendet wird. Ein Datenpaket kann z.B. einen Satz von Parametern enthalten, die als Zeiger auf Objekte definiert sind. Zu den Parametern gehören z.B. key_a_identifier_length, wobei es sich um einen Zeiger auf eine Ganzzahl handelt, die die Länge des Parameters key_a_identifier in Byte spezifiziert. Bei key_a_identifier handelt es sich um einen Zeiger auf eine Folgevariable, die den CCA-Schlüssel-Token enthält, der den Schlüssel enthält. Die Parameter key_b_identifier_length und key_b_identifier sind ähnlich zu den key_a-Parametern, die oben beschrieben wurden, sind jedoch dem key_b zugehörig. Bei output_key_identifier_length handelt es sich um einen Zeiger zu einer Ganzzahl, die die Länge des Parameters output_key_identifier in Byte spezifiziert. Bei dem Parameter output_key_identifier handelt es sich um einen Zeiger zu einer Folgevariable, die den Ausgabe-Schlüssel-Token empfängt, der die 16-Byte-Version des 8-Byte-Eingabeschlüssel key_a und des 8-Byte-Eingabeschlüssel key_b und den CV befördert.
Die 2A und 2B veranschaulichen einen Ablaufplan eines beispielhaften Verfahrens, das durch das System 100 (1) ausgeführt werden kann. In 2A empfängt das HSM 112 im Block 202 einen Schlüssel, der als key_a bezeichnet wird, und einen Schlüssel, der als key_b bezeichnet wird. Die Schlüssel können z.B. vom Speicher 108 über den Prozessor 102 empfangen werden. Im Block 204 ermittelt das HSM 112, ob es sich bei den beiden empfangenen Schlüsseln um gültige CCA-Schlüssel-Tokens für den symmetrischen Verschlüsselungsalgorithmus handelt, der bei dem Schema wie z.B. dem Datenverschlüsselungs-Standard (DES) verwendet wird. In diesem Zusammenhang prüft das HSM 112 z.B. die Unversehrtheit der CCA-Schlüssel-Tokens, um sicherzustellen, dass die CCA-Schlüssel-Tokens nicht verfälscht wurden, prüft, dass alle Felder gültige Werte enthalten, prüft, dass die Token-Typ-Kennung für einen akzeptablen DES-Token gilt, und führt weitere Gültigkeitsprüfungen aus. Wenn es sich bei beiden Schlüsseln nicht um gültige CCA-Schlüssel-Tokens für DES handelt, kann im Block 206 eine Fehlernachricht an den Benutzer ausgegeben werden. Wenn beide Schlüssel gültige CCA -Tokens für DES sind, ermittelt das HSM 112 im Block 206, ob beide Schlüssel 8-Byte-DES-Schlüssel enthalten. Wenn das nicht der Fall ist, kann im Block 206 eine Fehlernachricht ausgegeben werden. Im Block 210 werden die vorgesehenen Schlüssel key_a und key_b durch eine CVV-Erzeugen-Schlüsselprüfungs-Unterroutine geleitet. Die CW-Erzeugen-Schlüsselprüfungs-Unterroutine ermittelt im Block 212, ob die beiden CVs für die vorgesehenen Schlüssel key_a und key_b für einen Dienst CVV-Erzeugen gültig sind. Wenn die beiden CVs für den Dienst CW-Erzeugen nicht gültig sind, werden die vorgesehenen Schlüssel key_a und key_b im Block 214 (von 2B) durch eine CW-Prüfen-Schlüsselprüfungs-Unterroutine geleitet. Die CVV-Prüfen-Schlüsselprüfungs-Unterroutine ermittelt im Block 216, ob die beiden CVs für die vorgesehenen Schlüssel key_a und key_b für einen Dienst CVV-Prüfen gültig sind. Wenn die beiden CVs für CVV-Prüfen nicht gültig sind, kann im Block 206 (von 2A) eine Fehlernachricht ausgegeben werden. Wenn die beiden CVs für die Dienste CVV-Erzeugen und/oder CW-Prüfen gültig sind, ermittelt das HSM 112 im Block, ob der Verknüpfungsprozess für die Verknüpfung der bestimmten Typen von Schlüsseln, die als key_a und key_b bezeichnet werden, zulässig ist. Obwohl die dargestellten Ausführungsformen die Verwendung von DES enthalten, kann jeder andere spezielle Algorithmus oder jedes andere spezielle Schema einer symmetrischen Verschlüsselung auch in alternativen Ausführungsformen verwendet werden.
In diesem Zusammenhang stellt 3 eine Tabelle 300 dar, die von dem HSM 112 verwendet wird, um logisch zu ermitteln, ob der Verknüpfungsprozess zulässig ist auf der Grundlage der bestimmten Typen von Schlüsseln, die als key_a und key_b bezeichnet werden. In 3 ermittelt das HSM 112, welcher Schlüsseltyp als key_a bezeichnet wird und welcher Schlüsseltyp als key_b bezeichnet wird, und wendet die Tabelle 300 an, um zu ermitteln, ob der Verknüpfungsprozess zulässig ist. Wenn z.B. der 8-Byte-Eingabeschlüssel, der als key_a bezeichnet wird, ein Schlüssel des Typs CWKEY-A ist, und der 8-Byte-Eingabeschlüssel, der als key_b bezeichnet wird, ein Schlüssel des Typs CWKEY-B ist, ist der Verknüpfungsprozess zum Verknüpfen der Schlüssel zu einem 16-Byte-Schlüssel zulässig. Wenn der 8-Byte-Eingabeschlüssel, der als key_a bezeichnet wird, ein Schlüssel des Typs DATA ist, und der 8-Byte-Eingabeschlüssel, der als key_b bezeichnet wird, ein Schlüssel des Typs DATA ist, ist der Verknüpfungsprozess zum Verknüpfen der Schlüssel zu einem 16-Byte-Schlüssel zulässig. Wenn in ähnlicher Weise der 8-Byte-Eingabeschlüssel, der als key_a bezeichnet wird, ein Schlüssel des Typs ANY-MAC ist, und der 8-Byte-Eingabeschlüssel, der als key_b bezeichnet wird, ein Schlüssel des Typs ANY-MAC ist, ist der Verknüpfungsprozess zum Verknüpfen der Schlüssel zu einem 16-Byte-Schlüssel zulässig. Wenn dagegen der 8-Byte-Eingabeschlüssel, der als key_a bezeichnet wird, ein Schlüssel des Typs CWKEY-B ist, ist der Verknüpfungsprozess nicht zulässig, unabhängig von dem Typ des Schlüssels, der als key_b bezeichnet wird, und wenn der 8-Byte-Eingabeschlüssel, der als key_b bezeichnet wird, ein Schlüssel des Typs CWKEY-A ist, ist der Verknüpfungsprozess nicht zulässig, unabhängig von dem Typ des Schlüssels, der als key_a bezeichnet wird.
Wenn in 2B der Verknüpfungsprozess für die Verknüpfung der bestimmten Typen von Schlüsseln, die als key_a und key_b bezeichnet werden, nicht zulässig ist, kann im Block 220 eine Zurückweisungsnachricht ausgegeben werden. Das HSM 112 ermittelt im Block 222, ob der Benutzer die erforderlichen Genehmigungen aufweist, um das System 100 anzuweisen, den Verknüpfungsprozess auszuführen. Für die Verknüpfungen von Schlüsseln, die in der Tabelle 300 (von 3) als zulässig angegeben sind, kann den meisten oder allen Benutzer gestattet sein, das System 100 anzuweisen, den Verknüpfungsprozess auszuführen. Weitere Verknüpfungen von Schlüsseltypen können zulässig sein, wenn der Benutzer die erforderlichen Sicherheitsgenehmigungen aufweist, das System 100 anzuweisen, die Verknüpfung der bestimmten Schlüsseltypen auszuführen. Die Sicherheitsgenehmigungen des Benutzers können ermittelt werden, indem z.B. eine Benutzer-Anmeldeprozedur verwendet wird, die den Benutzer identifiziert und eine Sicherheitsstufe für den Benutzer angibt. Wenn z.B. in 3 der 8-Byte-Eingabeschlüssel, der als key_a bezeichnet wird, ein Schlüssel des Typs CWKEY-A ist und der Eingabeschlüssel, der als key_b bezeichnet wird, entweder ein Schlüssel des Typs DATA oder ein Schlüssel des Typs ANY-MAC ist, ist der Verknüpfungsprozess zum Verknüpfen der Schlüssel zu einem 16-Byte-Schlüssel bedingt zulässig, solange der Benutzer, der den Verknüpfungsprozess anfordert, berechtigt ist oder die erforderlichen Genehmigungen aufweist, das System 100 anzuweisen, einen derartigen Verknüpfungsprozess auszuführen. Wenn in 2B der Benutzer nicht die erforderlichen Genehmigungen aufweist, das System 100 anzuweisen, den Verknüpfungsprozess für die bestimmten Schlüssel (wie in der Tabelle 300 angegeben) auszuführen, kann im Block 220 eine Zurückweisungsnachricht ausgegeben werden. Wenn der Benutzer die erforderlichen Genehmigungen aufweist, den Verknüpfungsprozess für die bestimmten Schlüssel (wie in der Tabelle 300 angegeben) auszuführen, erzeugt das HSM 112 einen 16-Byte-Schlüssel-Token unter Verwendung der empfangen 8-Byte-Schlüssel-Tokens und gibt den erzeugten 16-Byte-Schlüssel-Token an den Benutzer aus, der z.B. über die Anzeigeeinheit 104 (von 1) ausgegeben oder im Speicher 108 für einen späteren Abruf durch einen Benutzer aufbewahrt werden kann.
4 veranschaulicht ein Blockschaubild eines beispielhaften Verfahrens zum Erzeugen eines 16-Byte-Schlüssel-Token. Im Block 402 wird ein Standard-CV CWKEY-A mit einer Länge für einen 16-Byte-Schlüssel erzeugt. In diesem Zusammenhang handelt es sich bei CWKEY-A um eine Schlüssel-Token-Struktur, die Standardwerte für einen Token enthält, der einen 16-Byte-CW-Schlüssel halten wird. Der CWKEY-A weist Raum auf, der für die Schlüssel reserviert ist, enthält den CV und weitere Steuerinformationen wie z.B. einen Token-Kennungsmerker, eine Token-Versionsnummer, Merker-Bytes und einen Token-Validierungswert. Im Block 404 wird der unverschlüsselte 8-Byte-Schlüssel, der als key_a bezeichnet wird, in den Anfang eines 16-Byte-Puffers kopiert, und der unverschlüsselte Schlüssel, der als key_b bezeichnet wird, wird in das Ende des 16-Byte-Puffers kopiert. Im Block 406 wird der resultierende 16-Byte-Schlüssel in dem Puffer unter Verwendung eines Schlüssel-Einhüllungsverfahrens eine Schlüssel-Einhüllung ausgeführt, die das Schlüsselmaterial verschlüsselt und den CV CVVKEY-A an das verschlüsselte Schlüsselmaterial bindet. Jedes geeignete Einhüllungsverfahren kann für den bestimmten Token-Typ verwendet werden. Der Einhüllungsvorgang stellt sicher, dass der CV nicht geändert werden kann, ohne dass das Schlüsselmaterial unbrauchbar gemacht wird. Der eingehüllte Schlüssel und der 16-Byte-CV CWKEY-A werden in einen Ausgabe-Schlüssel-Token im Block 408 einfügt. Im Block 410 wird der Ausgabe-Schlüssel-Token an den Benutzer ausgegeben.
Ein beispielhafter Schlüssel-Einhüllungsvorgang wird nachfolgend beschrieben; jeder geeignete alternative Schlüssel-Einhüllungsvorgang kann jedoch in alternativen Ausführungsformen verwendet werden. In diesem Zusammenhang wird für einen 16-Byte-DES-Schlüssel (K), bei dem die linken 8 Byte KL lauten und die rechten 8 Byte KR lauten, ein DES-Schlüssel, der einen Schlüssel KEK verschlüsselt, mit doppelter Länge, der zwei Hälften KEKL und KEKR aufweist, verwendet, um den Schlüssel K gemeinsam mit einem Steuervektor CV, der zwei Hälften CVL und CVR aufweist, einzuhüllen. Der Prozess enthält ein Berechnen von KEKL‘ = KEKL XOR CVL (wobei es sich bei XOR um eine logische Exclusiv-ODER-Operation handelt) und von KEKR‘ = KEKR XOR CVR. Die Werte KEKL‘ und KEKR‘ werden gemeinsam als ein DES-Schlüssel KEK‘ mit doppelter Länge verwendet. Der Schlüssel KL wird mit KEK‘ unter Verwendung eines Triple DES Verschlüsselung Electronic Code Book (ECB) verschlüsselt, um die linke Hälfte des eingehüllten Schlüssels zu definieren, und KR wird mit KEK‘ unter Verwendung einer Triple-DES-ECB-Verschlüsselung verschlüsselt, um die rechte Hälfte des eingehüllten Schlüssels zu definieren. Die oben beschriebene Schlüssel-Token-Struktur empfängt den CV, die linke und die rechte Hälfte des eingehüllten Schlüssels und weitere Elemente, die Teil der Token-Struktur sind.
Die technischen Wirkungen und Vorteile der oben beschriebenen Ausführungsformen ermöglichen, dass ein Satz von kurzen Schlüsseln zu einem längeren Schlüssel verknüpft werden kann, der an einen Benutzer ausgegeben werden kann, ohne die Sicherheit der Schlüssel oder des Systems zu gefährden.
Einem Fachmann ist klar, dass Aspekte der vorliegenden Erfindung als System, Verfahren oder Computerprogrammprodukt ausgeführt werden können. Dementsprechend können Aspekte der vorliegenden Erfindung die Form einer reinen Hardware-Ausführungsform, einer reinen Software-Ausführungsform (darunter Firmware, residente Software, Mikrocode usw.) oder einer Ausführungsform annehmen, die Software- und Hardware-Aspekte kombiniert, die hier alle als „Schaltung“, „Modul“ oder „System“ bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien ausgeführt wird, die computerlesbaren Programmcode aufweisen, der darin ausgeführt wird. Jede Kombination aus einem oder mehreren computerlesbaren Medien kann verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann z.B. ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, -vorrichtung oder -einheit oder jede geeignete Kombination des Vorhergehenden sein, ist jedoch nicht auf diese beschränkt. Zu spezifischeren Beispielen (eine nicht erschöpfende Liste) des computerlesbaren Speichermediums würden folgende gehören: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffspeicher (RAM), ein Festwertspeicher (ROM), ein löschbarer programmierbarer Festwertspeicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer Compactdisk-Festwertspeicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder jede geeignete Kombination des Vorhergehenden. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes materielle Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Befehlsausführung enthalten oder speichern kann.
Ein computerlesbares Signalmedium kann ein verbreitetes Datensignal mit einem computerlesbaren Programmcode, der darin z.B. im Basisband oder als Teil einer Trägerwelle verkörpert wird, enthalten. Ein derartiges verbreitetes Signal kann jede von einer Vielzahl von Formen annehmen, zu denen elektromagnetische, optische Formen oder jede geeignete Kombination hiervon gehören, jedoch nicht darauf beschränkt sind. Ein computerlesbares Signalmedium kann jedes computerlesbare Medium sein, das kein computerlesbares Speichermedium ist und ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Befehlsausführung übertragen, verbreiten oder transportieren kann.
Programmcode, der auf einem computerlesbaren Medium verkörpert ist, kann unter Verwendung jedes geeigneten Mediums übertragen werden, darunter drahtlose, leitungsgestützte, Lichtwellenleiterkabel-, HF-Medien oder jede geeignete Kombination aus dem Vorhergehenden, ohne darauf beschränkt zu sein.
Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorliegenden Erfindung kann in jeder Kombination aus einer oder mehreren Programmiersprachen geschrieben sein, darunter eine objektorientierte Programmiersprache wie Java, Smalltalk, C++ oder dergleichen und herkömmliche prozedurale Programmiersprachen wie etwa die Programmiersprache „C“ oder ähnliche Programmiersprachen. Der Programmcode kann nur auf dem Computer eines Benutzers, teilweise auf dem Computer eines Benutzers, als ein selbständiges Software-Paket, teilweise auf dem Computer eines Benutzers und teilweise auf einem fernen Computer oder nur auf dem fernen Computer oder Server ausgeführt werden. In dem zuletzt genannten Szenario kann der ferne Computer mit dem Computer des Benutzers durch jeden Netzwerktyp verbunden sein, einschließlich eines lokalen Netzwerks (LAN) oder eines Weitverkehrsnetzes (WAN), oder die Verbindung kann zu einem externen Computer (z.B. über das Internet unter Verwendung eines Internet-Dienstanbieters) hergestellt werden.
Aspekte der vorliegenden Erfindung werden hier unter Bezugnahme auf Ablaufplan-Darstellungen und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es ist klar, dass jeder Block der Ablaufplan-Darstellungen und/oder Blockschaubilder und Kombinationen von Blöcken in den Ablaufplan-Darstellungen und/oder Blockschaubildern durch Computerprogrammbefehle umgesetzt werden können. Diese Computerprogrammbefehle können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu bilden, so dass die Befehle, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Umsetzen der Funktionen/Wirkungen, die in dem Block oder den Blöcken des Ablaufplans und/oder Blockschaubilds spezifiziert sind, erzeugen. Diese Computerprogrammbefehle können außerdem in einem computerlesbaren Medium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anweisen kann, in einer bestimmten Weise zu funktionieren, so dass die in dem computerlesbaren Medium gespeicherten Befehle einen Herstellungsgegenstand produzieren, wozu Befehle gehören, die die Funktion/Wirkung umsetzen, die in dem Block/den Blöcken des Ablaufplans und/oder Blockschaubilds spezifiziert sind. Die Computerprogrammbefehle können außerdem in einen Computer, andere programmierbare Datenverarbeitungsvorrichtungen oder andere Einheiten geladen werden, um eine Reihe von Operationsschritten zu bewirken, die auf dem Computer, der anderen programmierbaren Datenverarbeitungsvorrichtung oder anderen Einheiten ausgeführt werden sollen, um einen durch einen Computer umgesetzten Prozess zu erzeugen, so dass die Befehle, die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführt werden, Prozesse zum Umsetzen der Funktionen/Wirkungen, die in dem Block oder Blöcken des Ablaufplans und/oder Blockschaubilds spezifiziert sind, bereitzustellen. Der Ablaufplan und die Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und Operation von möglichen Umsetzungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in dem Ablaufplan oder Blockschaubildern ein Modul, Segment oder Abschnitt von Code repräsentieren, der einen oder mehrere ausführbare Befehle zum Umsetzen der spezifizierten logischen Funktion(en) umfasst. Es sollte außerdem angemerkt werden, dass in einigen alternativen Umsetzungen die in dem Block angegebenen Funktionen nicht in der in den Figuren angegebenen Reihenfolge auftreten. Zum Beispiel können zwei Blöcke, die nacheinander gezeigt sind, tatsächlich im Wesentlichen gleichzeitig ausgeführt werden oder die Blöcke können gelegentlich in Abhängigkeit von der beteiligten Funktionalität in der umgekehrten Reihenfolge ausgeführt werden. Es wird außerdem angemerkt, dass jeder Block in den Blockschaubildern und/oder Ablaufplan-Darstellungen und Kombinationen von Blöcken in den Blockschaubildern und/oder Ablaufplan-Darstellung durch Systeme, die auf spezieller Hardware beruhen, die die spezifizierten Funktionen oder Wirkungen ausführen, oder Kombinationen aus spezieller Hardware und Computerbefehlen umgesetzt werden können.
Die hier verwendete Terminologie dient lediglich dem Zweck der Beschreibung bestimmter Ausführungsformen und ist nicht vorgesehen, die Erfindung einzuschränken. Es ist vorgesehen, dass die hier verwendeten Singularformen „ein“ und „der/die/das“ ebenso die Pluralformen einschließen, falls im Kontext nicht anders deutlich angegeben. Es ist ferner klar, dass die Ausdrücke „weist auf“ und/oder „aufweisen“, wenn sie in dieser Beschreibung verwendet werden, das Vorhandensein von angegebenen Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen und/oder Komponenten spezifizieren, jedoch nicht das Vorhandensein oder die Hinzufügung von einem oder mehreren anderen Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen hiervon ausschließen.
Es ist vorgesehen, dass die entsprechenden Strukturen, Materialien, Wirkungen und Ersetzungen aller Mittel oder Schritte plus Funktionselementen in den nachfolgenden Ansprüchen jede Struktur, jedes Material oder jede Wirkung zum Ausführen der Funktion in Kombination mit anderen beanspruchten Elementen in der speziell beanspruchten Weise enthalten. Die Beschreibung der vorliegenden Erfindung wurde für Zwecke der Erläuterung und Beschreibung dargestellt, es ist jedoch nicht vorgesehen, dass sie in der beschriebenen Form für die Erfindung erschöpfend oder einschränkend ist. Viele Modifikationen und Variationen sind für einen Fachmann vorstellbar, ohne vom Umfang und Erfindungsgedanken der Erfindung abzuweichen. Die Ausführungsform wurde ausgewählt und beschrieben, um die Grundgedanken der Erfindung und die praktische Anwendung am besten zu erläutern und um andere Fachleute zu befähigen, die Erfindung für verschiedene Ausführungsformen mit zahlreichen Modifikationen zu verstehen, wie sie für die vorgesehene bestimmte Verwendung geeignet sind.

Claims

Verfahren zum Erzeugen eines Schlüssel-Token, wobei das Verfahren aufweist: Empfangen eines ersten Schlüssel-Token, eines zweiten Schlüssel-Token und einer Anforderung zum Verknüpfen des ersten Schlüssel-Token mit dem zweiten Schlüssel-Token; Ermitteln, ob der erste Schlüssel-Token und der zweite Schlüssel-Token gültige Tokens allgemeiner kryptografischer Architektur (CCA) für einen bestimmten Verschlüsselungsalgorithmus sind; Ermitteln, ob der erste Schlüssel-Token und der zweite Schlüssel-Token die Schlüssel des bestimmten Verschlüsselungsalgorithmus enthalten, die eine gewünschte Anzahl von Bytes aufweisen; und Feststellen eines ersten Schlüsseltyps des ersten Schlüssel-Token und eines Schlüsseltyps des zweiten Schlüssel-Token, in Reaktion auf einem Feststellen, dass es sich bei dem ersten Schlüssel-Token und dem zweiten Schlüssel-Token um gültige CCA-Tokens für den bestimmten Verschlüsselungsalgorithmus handelt und dass der erste Schlüssel-Token und der zweite Schlüssel-Token die Schlüssel des bestimmten Verschlüsselungsalgorithmus mit der gewünschten Anzahl von Bytes enthalten; Ermitteln, ob der Schlüsseltyp des ersten Schlüssel-Token mit dem Schlüsseltyp des zweiten Schlüssel-Token verknüpft werden kann; Verknüpfen des ersten Schlüssel-Token mit dem zweiten Schlüssel-Token, um einen dritten Schlüssel-Token zu erzeugen in Reaktion auf ein Feststellen, dass der Schlüsseltyp des ersten Schlüssel-Token mit dem Schlüsseltyp des zweiten Schlüssel-Token verknüpft werden kann; und Ausgeben des dritten Schlüssel-Token.
Verfahren nach Anspruch 1, wobei das Verfahren vor dem Verknüpfen des ersten Schlüssel-Token mit dem zweiten Schlüssel-Token zum Erzeugen des dritten Schlüssel-Token ferner aufweist: Ermitteln, ob ein Benutzer, der fordert, den ersten Schlüssel-Token mit dem zweiten Schlüssel-Token zu verknüpfen, berechtigt ist, die Verknüpfung auf der Grundlage des Schlüsseltyps des ersten Schlüssel-Token und des Schlüsseltyps des zweiten Schlüssel-Token zu fordern; und Verweigern der Forderung zum Verknüpfen des ersten Schlüssel-Token mit dem zweiten Schlüssel-Token in Reaktion auf ein Feststellen, dass der Benutzer nicht berechtigt ist, die Verknüpfung zu fordern auf der Grundlage des Schlüsseltyps des ersten Schlüssel-Token und des Schlüsseltyps des zweiten Schlüssel-Token.
Verfahren nach Anspruch 1, wobei das Verfahren vor dem Feststellen eines Schlüsseltyps des ersten Schlüssel-Token und eines Schlüsseltyps des zweiten Schlüssel-Token ferner aufweist: Ermitteln, ob ein erster Steuervektor (CV), der dem ersten Schlüssel-Token zugehörig ist, und ein zweiter CV, der dem zweiten Schlüssel-Token zugehörig ist, jeweils gültig sind für einen Dienst Kartenprüfwert-(CW)-Erzeugen und in Reaktion auf ein Feststellen, dass der erste CV und der zweite CV für den Dienst Kartenprüfwert-(CW)-Erzeugen nicht gültig sind, Ermitteln, ob der erste CV und der zweite CV für einen Dienst Kartenprüfwert-(CW)-Prüfen gültig sind; und Ausgeben einer Fehlernachricht in Reaktion auf das Feststellen, dass der erste CV und der zweite CV für den Dienst Kartenprüfwert-(CW)-Prüfen nicht gültig sind.
Verfahren nach Anspruch 1, wobei das Verknüpfen des ersten Schlüssel-Token mit dem zweiten Schlüssel-Token zum Erzeugen des dritten Schlüssel-Token aufweist: Erzeugen eines CV; Kopieren eines Schlüssels des ersten Schlüssel-Token in einen ersten Abschnitt eines Puffers; Kopieren eines Schlüssels des zweiten Schlüssel-Token in einen zweiten Abschnitt des Puffers; Einfügen der Schlüssel in den Puffer und des CV in einen Ausgabe-Schlüssel-Token, um den dritten Schlüssel-Token zu definieren; und Einhüllen der Schlüssel in dem dritten Schlüssel-Token, um den CV an die Schlüssel zu binden.
Verfahren nach Anspruch 1, wobei der erste Schlüssel-Token ein 8-Byte-Token ist, der zweite Schlüssel-Token ein 8-Byte-Token ist und der dritte Schlüssel-Token ein 16-Byte-Token ist.
System, das aufweist: einen Prozessor, der so eingerichtet ist, dass er ein Verfahren zum Erzeugen eines Schlüssel-Token gemäß einem der Ansprüche 1 bis 5 ausführt.
Computerprogrammprodukt, das aufweist: ein nichtflüchtiges computerlesbares Speichermedium, das durch einen Computer ausführbare Befehle enthält, die beim Ausführen in einem Prozessor den Prozessor anweisen, ein Verfahren zum Erzeugen eines Schlüssel-Token gemäß einem der Ansprüche 1 bis 5 auszuführen.