DE10218795B4 - Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls - Google Patents

Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls Download PDF

Info

Publication number
DE10218795B4
DE10218795B4 DE2002118795 DE10218795A DE10218795B4 DE 10218795 B4 DE10218795 B4 DE 10218795B4 DE 2002118795 DE2002118795 DE 2002118795 DE 10218795 A DE10218795 A DE 10218795A DE 10218795 B4 DE10218795 B4 DE 10218795B4
Authority
DE
Germany
Prior art keywords
chip
authentication feature
manufacturer
key
memory
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.)
Expired - Lifetime
Application number
DE2002118795
Other languages
English (en)
Other versions
DE10218795A1 (de
Inventor
Regina Dr. Tix
Hermann Püttmann
Guido Borneis
Hans Georg Richter
Hans Peter Kraus
Thomas Dr. Wolter
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.)
VOEB-ZVD BANK fur ZAHLUNGSVERKEHRSDIENSTLEISTUNGEN GmbH
BANK VERLAG GmbH
BANK-VERLAG GmbH
DEUTSCHER GENOSSENSCHAFTS VERL
DEUTSCHER GENOSSENSCHAFTS-VERLAG EG
DEUTSCHER SPARKASSEN VERLAG GM
DEUTSCHER SPARKASSEN VERLAG GmbH
Vob-Zvd Bank fur Zahlungsverkehrsdienstleistungen GmbH
VOEB ZVD BANK fur ZAHLUNGSVER
Original Assignee
VOEB-ZVD BANK fur ZAHLUNGSVERKEHRSDIENSTLEISTUNGEN GmbH
BANK VERLAG GmbH
BANK-VERLAG GmbH
DEUTSCHER GENOSSENSCHAFTS VERL
DEUTSCHER GENOSSENSCHAFTS-VERLAG EG
DEUTSCHER SPARKASSEN VERLAG GM
DEUTSCHER SPARKASSEN VERLAG GmbH
Vob-Zvd Bank fur Zahlungsverkehrsdienstleistungen GmbH
VOEB ZVD BANK fur ZAHLUNGSVER
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 VOEB-ZVD BANK fur ZAHLUNGSVERKEHRSDIENSTLEISTUNGEN GmbH, BANK VERLAG GmbH, BANK-VERLAG GmbH, DEUTSCHER GENOSSENSCHAFTS VERL, DEUTSCHER GENOSSENSCHAFTS-VERLAG EG, DEUTSCHER SPARKASSEN VERLAG GM, DEUTSCHER SPARKASSEN VERLAG GmbH, Vob-Zvd Bank fur Zahlungsverkehrsdienstleistungen GmbH, VOEB ZVD BANK fur ZAHLUNGSVER filed Critical VOEB-ZVD BANK fur ZAHLUNGSVERKEHRSDIENSTLEISTUNGEN GmbH
Priority to DE2002118795 priority Critical patent/DE10218795B4/de
Publication of DE10218795A1 publication Critical patent/DE10218795A1/de
Application granted granted Critical
Publication of DE10218795B4 publication Critical patent/DE10218795B4/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1458Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1466Key-lock mechanism
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/77Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in smart cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355Personalisation of cards for use
    • G06Q20/3558Preliminary personalisation for transfer to user
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409Device specific authentication in transaction processing
    • G06Q20/4097Device specific authentication in transaction processing using mutual authentication between devices and transaction partners

Abstract

Verfahren zum Produzieren von Sicherheitsmodulen, insbesondere Chipkarten mit folgenden Verfahrensschritten:
1.1 von dem Hersteller des Chips wird ein Authentikationsmerkmal, insbesondere ein geheimer Schlüssel, generiert;
1.2 das Authentikationsmerkmal wird in den nichtflüchtigen Speicher des Chips geschrieben;
1.3 der nichtflüchtige Speicher wird derart ausgebildet, dass das Authentikationsmerkmal nicht aus dem Speicher ausgelesen werden kann;
1.4 das Betriebssystem des Chips wird derart ausgebildet, dass nur unter Verwendung des Authentikationsmerkmals ein Zugriff auf den Speicher möglich ist;
1.5 dem Chipkartenhersteller wird das Authentikationsmerkmal zur Benutzung zur Verfügung gestellt;
1.6 in dem Chip erfolgt eine Überprüfung des zur Verfügung gestellten Authentikationsmerkmals mit dem in dem Chip abgespeicherten Authentikationsmerkmal;
1.7 bei erfolgreicher Überprüfung wird das Authentikationsmerkmal des Chipherstellers gegen einen Authentikationsmerkmal des Abnehmers der Chipkarte ausgetauscht;
1.8 nach dem Austausch erfolgt die Initialisierung der Chipkarte.

Description

  • Die Erfindung betrifft ein Verfahren zum Herstellen elektronischer Sicherheitsmodule und die nach diesem Verfahren hergestellten Sicherheitsmodule. Chipkarten, die beispielsweise als Zahlungsmittel oder als Signaturkarte verwendet werden können, müssen nach bestimmten vorgeschriebenen Verfahren so gestaltet werden, dass ein Missbrauch ausgeschlossen wird.
  • An der Fertigung einer solchen Chipkarte sind verschiedene Instanzen beteiligt. Zunächst gibt es den Chiphersteller, der also das Kernstück der Chipkarte produziert. Auf den Chip wird während der Produktion eine ROM-Maske aufgebracht, die von einem anderen Hersteller geliefert wird. Die ROM-Maske enthält unter anderem den Betriebssystemkern, der für den Betrieb der Chipkarte erforderlich ist.
  • Beim letzten Vorgang der Herstellung der Chipkarte muss diese zunächst initialisiert und anschließend personalisiert werden. Bei der Initialisierung werden die Voraussetzungen geschaffen, alle Personalisierungsdaten in den Speicherbe reich des Chips zu laden. Dabei werden alle global nötigen Daten übertragen und die nötigen Dateistrukturen angelegt.
  • Bei der anschließenden Personalisierung werden die individuellen Daten in die Chipkarte eingebracht. Die Karten werden dann von den Abnehmern, beispielsweise kreditwirtschaftlichen Verlagen, an Banken oder direkt an Endkunden geliefert.
  • Es muss bei der Personalisierung sichergestellt werden, dass die hierzu gehörenden Daten, nicht abgehört werden können. Daher werden die Initialisierung und Personalisierung als getrennte Prozessschritte behandelt und auch an unterschiedlichen Stellen durchgeführt.
  • Es ist bereits ein Verfahren zum Personalisieren von Smartcards bekannt, bei dem Personalisierungsdaten von dem Abnehmer der Smartcard bereitgestellt werden. Die geheimen Schlüssel werden in einem Sicherheitsmodul erzeugt ( US 6367011 ).
  • Ebenfalls bekannt ist der Aufbau eines gesicherten Speichers mit einer Fabrikationszone, die Informationen über den Hersteller des Speichers enthält. Diese Fabrikationszone ist nach der Herstellung nicht änderbar ( WO99/18504 A1 ).
  • Weiterhin bekannt ist ein System zur Ausstellung von gesicherten IC Karten, bei dem eine Überprüfung eines Ausstelleridentifizierungscodes außerhalb der IC Karte erfolgt ( DE 38 0 9 170 A1 ).
  • Der Erfindung liegt die Aufgabe zu Grunde, eine Möglichkeit zu schaffen, unerlaubte Zugriffe auf den Speicher der Chipkarte zu verhindern.
  • Zur Lösung dieser Aufgabe schlägt die Erfindung ein Verfahren mit den im Anspruch 1 genannten Merkmalen vor. Weiterbildungen der Erfindung sind Gegenstand von Unteransprüchen.
  • Erfindungsgemäß schreibt der Chiphersteller Prüfdaten, z. B. kryptographische Schlüssel, in den Chip. Vor oder bei dem Laden von Programmcode oder Daten in den Chip muß ein Authentizitätsmerkmal präsentiert werden, das anhand dieser eingebrachten Prüfdaten geprüft wird. Andernfalls wird das Laden zurückgewiesen.
  • Hierzu stellt der Chiphersteller dem Abnehmer ein Verfahren und/oder geheime Daten (z. B. kryptographische Schlüssel) zur Verfügung, die dem Abnehmer das Anbringen der Authentizitätsmerkmale (z. B. elektronische Signaturen, MACS) ermöglichen.
  • Der Hersteller des Betriebssystems (vorzugsweise im unveränderlichen Speicher/ROM-Maske realisiert) gestaltet dies so, dass die Authentizitätsprüfung stattfindet und nicht umgangen werden kann. Vorzugsweise braucht der Hersteller des Betriebssystems dazu die geheimen Daten und die Prüfdaten nicht zu kennen.
  • Erfindungsgemäß ist vorgesehen, dass das Betriebssystem derart ausgelegt wird, dass der Schlüssel nicht aus dem Speicher ausgegeben werden kann. Es soll auf diese Weise verhindert werden, dass der Schlüssel ausgelesen und kopiert werden kann. Der Schlüssel bleibt also geheim innerhalb des Chips.
  • Erfindungsgemäß kann in Weiterbildung vorgesehen sein, dass der Schlüssel auf gesichertem Weg von dem Chiphersteller zu dem Abnehmer der Chipkarte gebracht wird.
  • In Weiterbildung der Erfindung kann vorgesehen sein, dass der Schlüssel in einen speziellen Speicherbereich des EEPROMs des Chips, den Startbereich, eingeschrieben wird.
  • Um sicherzustellen, dass der Schlüssel nur in den Startbereich des Speichers eingeschrieben werden kann, kann erfindungsgemäß vorgesehen sein, dass das Betriebssystem bzw. die technische Umgebung des Chipherstellers derart ausgelegt ist, dass nur mit seiner Hilfe der Schlüssel eingeschrieben werden kann, und zwar nur in den speziell dafür vorgesehenen Startbereich.
  • Erfindungsgemäß kann das Vorsehen der Einbringung eines geheimen Schlüssel bei dem Chiphersteller dazu verwendet werden, für verschiedene Abnehmer verschiedene Schlüssel zu verwenden. Wenn beispielsweise ein Chiphersteller mehrere Abnehmer seines Chips für die gleiche Anwendung hat, so kann er in die für einen speziellen Abnehmer bestimmten Chips die diesem Abnehmer zugeordneten geheimen Schlüssel einschreiben.
  • Erfindungsgemäß kann in Weiterbildung vorgesehen sein, wenn Chipkarten an mehrere Abnehmer geliefert werden, für die mehreren Abnehmer unterschiedliche Schlüssel in jeder Karte unterzubringen. Diese können auf verschiedenen Speicherplätzen abgespeichert werden.
  • In nochmaliger Weiterbildung kann auch vorgesehen sein, dass bei dem Initialisieren der Chipkarte der in dieser Chipkarte beziehungsweise ihrem Chip enthaltene geheime Schlüssel des Chip-Herstellers durch einen weiteren Schlüssel ausgetauscht wird, der für einen bestimmten Abnehmer der Chipkarte maßgebend ist. Es könnte also bei der Initialisierung der Chipkarte an einer bestimmten Stelle eine Aufteilung der Chipkarten auf mehrere Abnehmer erfolgen. Jeder dieser Abnehmer hat einen eigenen geheimen Schlüssel, der mit Autorisierung durch den geheimen Schlüssel des Chip-Herstellers gegen diesen ausgetauscht werden kann. Dann kann bei der anschließenden Initialisierung dafür gesorgt werden, dass nur die diesem speziellen Abnehmer zugeordneten Daten, Programme usw. in die Chipkarte eingeschrieben werden können.
  • Es ist aber ebenfalls möglich und liegt im Rahmen der Erfindung, ein in den Kommandodaten übergebenes Passwort anhand eines Vergleichs mit einem im persistenten Speicher des Chips gespeicherten Chippasswort zu verifizieren. Erst bei einem erfolgreichen Vergleich können dann weitere Kommandos ausgeführt werden. Diese Möglichkeit, unter bestimmten Umständen den Zugriff auf den Speicher des Chips durch einen stationären Passwortvergleich zu ermöglichen, kann beispielsweise für Eingangstests oder dann verwendet werden, wenn beim ersten Initialisieren ein Fehler aufgetreten ist.
  • Es kann vorgesehen sein, dass beim Schlüselaustausch das schon vorher vorhandene statische Passwort gegen ein aus dem neuen einzubringenden Schlüssel abgeleitetes Passwort ausgetauscht wird.
  • Zur Durchführung der beiden Vorgänge, also sowohl des Austauschs eines geheimen Schlüssels durch einen zweiten geheimen Schlüssel als auch des Vergleichs zweier Passworte kann das gleiche Kommando verwendet werden.
  • Weitere Merkmale, Einzelheiten und Vorzüge der Erfindung ergeben sich aus der folgenden Beschreibung einer bevorzugten Ausführungsform der Erfindung sowie anhand der Zeichnung. Hierbei zeigen:
  • 1 schematisch den Aufbau des Chips einer Chipkarte;
  • 2 schematisch den Aufbau des Chips nach Einbringung des Initialisierungsimages;
  • 3 die Einbringung des abnehmerspezifischen geheimen Schlüssels;
  • 4 das Einbringen der Prüfdaten beim Chipkartenhersteller;
  • 5 den Zustand des Chips nach erfolgter Überprüfung.
  • Der Chip enthält eine ROM-Maske 1, die von dem ROM-Maskenhersteller produziert und von dem Chiphersteller in den Chip eingebracht wird. Die ROM-Maske enthält unter anderem das Betriebssystem, das für die weiteren Herstellungsschritte und den Betrieb des Chips erforderlich ist.
  • Weiterhin enthält der Chip ein EEPROM 2, das zur Aufnahme von Daten und Programmcode bestimmt ist. Das EEPROM 2 ist in drei Bereiche aufgeteilt, nämlich einen Startbereich 3, einen Prüfbereich 4 und einen Bereich 5 für Daten und Programmcode.
  • 1 zeigt den Zustand beim Chiphersteller, in dessen sicherer Umgebung 6 sein Schlüssel aus einem Speicherbereich 7 auf gesichertem Weg in einen Speicherbereich 8 des Startbereichs 3 des EEPROMs eingeschrieben wird.
  • Im Einzelnen gilt dabei folgendes:
    Key-Management des Chipherstellers und der Abnehmer des Chipherstellers, z. B. der Verlage:
    Der Chiphersteller bringt bei der Chipproduktion die ROM-Maske in die evaluierte Chip-Hardware ein. Die Produktionsumgebung des Chipherstellers ist nach den Vorgaben des Signaturgesetzes für die Produktion von SigG konformen Chips zu evaluieren. Der Chiphersteller bestätigt dem Verlag und dem Chipkartenhersteller, dass nur Chips mit evaluierter Hardware für die Produktion von Signaturkarten-Chips verwendet werden.
  • ROM-Maske des Chips:
    Der ROM-Maskenhersteller erstellt die Betriebssystem- und Anwendungssoftware für die Chipkarte in Form einer ROM-Maske.
  • Die ROM-Maske enthält für jeden Abnehmer, beispielsweise einen Verlag, zwei 20 Byte lange Hash-Werte über einen verlagsspezifischen öffentlichen Schlüssel PK-Verlag-Chip sowie die 2 Byte lange Byte-Längen des Modulus und die 3 Byte lange Schlüsselkennung Info-PK-Verlag zu dem jeweiligen PK-Verlag-Chip.
  • Jeder Verlag stellt dazu im Vorfeld dem ROM-Maskenhersteller diese Werte für Hash-Wert, Byte-Länge und Info-PK-Verlag zur Verfügung. Zusätzlich erhält der ROM-Maskenhersteller den Modulus zum Nachrechnen des Hash-Wertes.
  • Die 1 zeigt die Anordnung der Hashwerte in den Feldern 9 bis 12 der ROM-Maske des Chips, jeder Hash-Wert wird wie oben beschrieben in der ROM-Maske durch die jeweiligen Zusatzinformationen ergänzt. Die ROM-Maske wird anschließend vom Evaluator nach den gemäß Signaturgesetz vorgesehenen Sicherheitsanforderungen für die technische Komponente zur Erzeugung und Speicherung des Signaturschlüssels evaluiert und dem Chiphersteller zur Aufbringung auf dem evaluierten Chip übergeben.
  • Im Rahmen der Chipherstellung bringt der Chiphersteller den Triele-DES-Schlüssel K-Chip zusammen mit Nebeninformationen zum Schlüssel, das Chippasswort und weitere Daten gesichert in den Startbereich 3 des EEPROMs (Größe in der Regel 64 Bytes) der Chipkarte ein.
  • Das Betriebssystem des Chips muss durch geeignete Maßnahmen dafür Sorge tragen, dass der eingebrachte Schlüssel K-Chip und das Chippasswort nicht aus dem EEPROM auslesbar sind und der Startbereich nicht manipulierbar ist. Des Weiteren darf die Einbringung des Chippassworts und des Schlüssels K-Chip nur in den Startbereich des EEPROMS möglich sein.
  • Das Betriebssystem des Chips ist so zu gestalten, dass Unterprogrammaufrufe, die vom ROM-Code initiiert werden, um Code im EEPROM-Bereich ansprechen zu können, z. B. immer auf eine oder mehrere entsprechende Sprungadresse(n) 13 im Startbereich des EEPROMs weisen. Diese Sprungadressen 13 enthalten vom Zeitpunkt der Chip-Produktion beim Chiphersteller bis zu der erfolgreichen Ausführung des VERIFY_EEPROM-Kommandos immer eine „RETURN"-Anweisung, d. h. die übrigen EEPROM-Bereiche werden weder direkt noch indirekt zur Ausführung von Code adressiert.
  • Die Herstellung des Chips der Chipkarte beim Chiphersteller ist damit abgeschlossen. Die produzierten Chips werden nach der Modularisierung an den Chipkartenhersteller ausgeliefert. Der Chipkartenhersteller erhält Chips für die Chipkarte, die noch nicht abnehmerspezifisch sind, sondern erst bei der Initiali sierung einem der beispielsweise vier Abnehmer zugeordnet werden. Dies vereinfacht ggf. die Disposition der vorhandenen Chipmengen beim Chipkartenhersteller und reduziert durch die anfallenden größeren Einkaufsmengen beim Chiphersteller den Stückpreis des Chips.
  • Schlüsselaustausch mit den Verlagen für K-Chip
  • Jeder Chiphersteller bringt seinen K-Chip in das Sicherheitsmodul (S-Box) des Initialisierungstools ein, das dafür beim jeweiligen Abnehmer/Verlag aufgestellt wird. Diese S-Box besitzt u. a. folgende Funktionalität:
    Einbringung des chipherstellerspezifischen Schlüssels K-Chip;
    Einbringung des verlagsspezifischen Schlüssels K-Chip-Verlag;
    Verschlüsselung des eingebrachten K-Chip-Verlag mit dem Schlüssel K-Chip, Verschlüsselung der Schlüssel für den Prüfbereich des Chips mit K-Chip-Verlag;
    Berechnung der Signatur über die Prüfwerte und
    Erstellung der entsprechenden Chiffren für Testkarten.
  • Das Kryptogramm über K-Chip-Verlag wird später in die Initialisierungstabelle des Chips der Chipkarte übergeben. Durch den verlagsspezifischen K-Chip-Verlag wird eine klare Abgrenzung der Sicherheitskonzepte der einzelnen Verlage erreicht.
  • Den Verlagen darf es nicht möglich sein, durch etwaige Kenntnis eines mit K-Chip verschlüsselten Schlüssels K-Chip-Verlag eines anderen Verlags den Schlüssel K-Chip-Verlag eines anderen Verlags zu benutzen. Da K-Chip chipherstellerspezifisch ist, muss in der S-Box des Initialisierungstools die Funktion „Export des K-Chip" und „Entschlüsseln mit K-Chip" gesperrt sein. Es darf nur möglich sein, mit dieser S-Box den K-Chip-Verlag zu verschlüsseln. Die Funktionen der S-Box dürfen nur nach vorheriger Authentikation (z. B. PIN-Eingabe) des Benutzers gegen die S-Box ausführbar sein.
  • Initialisierung und Aufbau der Initialisierungstabelle:
    Die Initialisierungstabelle ist ein wesentliches Produktionsmittel für die Chipkarte. Sie kann bei der Herstellung der Chipkarte für die Einbringung identischer Speicherinhalte in alle Chipkarten einer ROM-Maske verwendet werden.
  • Der ROM-Maskenhersteller erstellt nach Fertigstellung der Programmierung von Code und Datenstrukturen ein Abbild eines speziellen Zustands des persistenten Speichers des Chips, das sogenannte Initialisierungsimage. Dieses soll in den persistenten Speicher der Chipkartenchips geladen werden, um diese zur Aufnahme von Personalisierungsdaten vorzubereiten. Zum Zweck einer geeigneten und sicheren Einbringung muss das Image für den Chip durch Hinzufügen von Kontroll-, Protokoll- und Prüfinformationen in das Format einer produktiven Initialisierungstabelle für die Initialisierungsanlage transformiert werden.
  • Die Initialisierungstabelle enthält nach dem Tabellenkopf Untertabellen mit Kommandofolgen, die der Initialisierer an die Chipkarte übergeben muss, sowie Kommandos und Informationen zur Kontrolle und Protokollierung des Initialisierungsprozesses.
  • Die Teile der Initialisierungstabelle, die die Kommandos und die dazugehörigen Kommandodaten enthalten, werden durch den Initialisierer satzweise in die Chipkarte geladen, indem der entsprechende Datensatz, bestehend aus einem Basis-Kommando und den zugehörigen Daten, an den Chip geschickt wird. Der Chip antwortet mit einem Returncode, der mit dem entsprechenden Returncode in der Kommandotabelle verglichen werden muss. Stimmen beide nicht miteinander überein, so ist der abweichende Returncode zu protokollieren und das Laden der Initialisierungstabelle abzubrechen.
  • Die 2 zeigt schematisch den Aufbau des EEPROMS der Chipkarte nach Einbringung des Initialisierungsimages. Der für den Programmcode und die Daten vorgesehene Bereich 5 des EPROMs enthält jetzt eine Sprungtabelle 15, von der aus eine Verzweigung auf mehrere Speicherbereiche 16 mit Pro grammcode erfolgen kann. Weiterhin enthält der Bereich 5 einen Bereich 17 für ein Filesystem mit konstanten Dateninhalten.
  • Einbringung des verlagsspezifischen K-Chip-Verlag beim Chipkartenhersteller:
    Als erste Aktion des Initialisierungsvorgangs beim Chipkartenhersteller wird der verlagsspezifische Schlüssel K-Chip-Verlag eingebracht. Das Kryptogramm des Schlüssels wurde dem Chipkartenhersteller zuvor vom Verlag als Teil der Initialisierungstabelle sicher zur Verfügung gestellt.
  • Die Initialisierungsanlage sendet ein Kommando VERIFY_CHIPPWD mit dem verschlüsselten K-Chip-Verlag an den Chip der Signaturkarte. Nach Empfang der Daten vergleicht der Chip die übergebenen Schlüssel-Informationen (VID, KID und KV) mit den im Startbereich gespeicherten Werten. Erkennt der Chip so, dass ihm ein neuer Schlüssel übergeben wurde, entschlüsselt der Chip mit Hilfe des Schlüssels K-Chip das Kryptogramm von K-Chip-Verlag. Im Startbereich des EEPROMS wird der Schlüssel K-Chip durch K-Chip-Verlag ersetzt. Die erfolgreiche Ausführung des Kommandos wird durch Änderung des Chipzustands protokolliert. In 3 ist die Einbringung des Schlüssels K-Chip-Verlag dargestellt. Ähnlich wie bei der Darstellung der 1 erfolgt ein Überspielen des geheimen Schlüssels des Abnehmers aus einem Speicherplatz 18 des Chipkartenherstellers in den Speicherbereich 8, in dem bislang der geheime Schlüssel des Chipherstellers untergebracht war.
  • Beschreibung des Kommandos „VERIFY_CHIPPWD":
  • Das Kommando VERIFY_CHIPPWD ermöglicht es, entweder den Schlüssel KChip durch den verlagsspezifischen Schlüssel KChip_Verlag zu ersetzen (falls LC = '1E' ist) oder das in den Kommandodaten übergebene Passwort anhand eines Vergleichs mit dem im persistenten Speicher gespeicherten Chippasswort zu verifizieren (falls LC = '08' oder LC = '1E' ist). In jedem Fall autorisiert eine erfolgreiche Kommandoausführung die externe Welt zur Ausführung weiterer Kommandos.
  • Der Fehlbedienungszähler (FBZ) für das Chippasswort und der Fehlbedienungszähler für den KChip_Verlag müssen persistent im Startbereich des EEPROM gespeichert werden, damit sie bei einer Stromunterbrechung nicht gelöscht werden. Hat bei der Verwendung des Chippassworts oder des KChip_Verlag durch das Kommando der jeweilige FBZ den Wert '00', so bricht das Kommando mit Fehlermeldung ab.
  • Beim Aufruf des Kommandos wird zunächst die Integrität des Startbereichs mit einer proprietär zu realisierenden Routine geprüft.
  • Für den Modus „Chippasswort vergleichen" (LC = '08') wird folgendermaßen verfahren:
    Ist der Wert des Fehlbedienungszählers für das Chippasswort '00', so wird das Kommando mit dem Returncode '69 83' abgebrochen. Ist dieser FBZ nicht '00', dann verifiziert der Chip das in den Kommandodaten übergebene 8 Byte lange Chippasswort CHIPPWD anhand eines Vergleichs mit dem im Startbereich des EEPROM stehenden Chippasswort. Bei einem falschen Wert des Chippasswortes wird der FBZ des Chippasswortes um eins dekrementiert und das Kommando wird mit dem Returncode '63 Cx' abgebrochen. Dabei gibt 'x' den Wert dieses FBZ und somit die Anzahl der weiteren Versuche an, also 'x' = '2', '1' oder '0'.
  • Ist der Vergleich erfolgreich, so wird der Fehlbedienungszähler des Chippasswortes auf den Initialwert '03' zurückgesetzt, im flüchtigen Speicher wird ein Flag gesetzt, das die erfolgreiche Verifikation des Chippasswortes signalisiert und das Kommando wird mit der Ausgabe des Returncodes '90 00' beendet.
  • Der Kommandoaufruf im Modus LC = '08' wird z. B. verwendet als Authentikation beim Einbringen der Protokolldaten der Modulherstellung, bei der Personalisierung und – im Fall einer zweigeteilten Initialisierungstabelle – zu Beginn des zweiten Teils der Initialisierungstabelle. Am Anfang der Initialisierungstabelle wird es im Modus LC = '1E' abgesetzt, da dort ein Schlüsselwechsel vorgesehen ist.
  • Im Folgenden werden diese Bezeichnungen verwendet:
    VDaten: VID2 ∥ KID2 ∥ KV2 ∥ KChip_Verlag ∥ '00 00 00 00 00'
    MAC(VDaten): Retail-CFB-MAC über VDaten berechnet mit KChip_Verlag und ICV = '00 ... 00'
    CHIPPWD: ein vom ROM-Maskenhersteller vergebenes und vom Chiphersteller eingebrachtes 8 Byte langes Passwort oder MAC(VDaten), falls bereits ein Schlüsselwechsel zu KChip_Verlag stattgefunden hat
    [KChip_Verlag]: KChip_Verlag mit dem KChip im CBC-Mode mit ICV = '00 ... 00' Triple-DES verschlüsselt
    VID1: ZKA-Herstellerkennung des Chipherstellers für den im Chip enthaltenen KChip
    VID2: ZKA-Herstellerkennung des Verlags für den in den Chip einzubringenden KChip_Verlag
    KID1, KID2: Schlüsselnummer/-ID des entsprechenden Schlüssels
    KV1, KV2: Schlüsselversion des entsprechenden Schlüssels
  • Für den Modus „eventuell Schlüssel wechseln" (LC = '1E') wird folgendermaßen verfahren:
    Der Chip prüft, ob das Tripel (VID1, KID1, KV1) verschieden ist vom Tripel (VID2, KID2, KV2) und ob das im Startbereich befindliche und zu KChip gehörige Tripel (VID, KID, KV) entweder gleich (VID1, KID1, KV1) oder gleich (VID2, KID2, KV2) ist. Ist dies nicht der Fall, wird das Kommando mit dem Returncode '64 00' abgebrochen.
  • LC = '1E' mit Schlüsselwechsel:
  • Falls das Tripel (VID, KID, KV) identisch ist mit (VID1, KID1, KV1), wird der Wert des Fehlbedienungszählers für den Schlüssel KChip geprüft. Ist er '00', so wird das Kommando mit dem Returncode '69 83' abgebrochen. Ist dieser FBZ nicht '00', dann prüft der Chip die Kommandodaten. Das Kryptogramm [KChip_Verlag] wird mit KChip entschlüsselt. Mit dem so erhaltenen KChip_Verlag wird anschließend der Wert MAC(VDaten) berechnet und mit dem entsprechenden Wert aus den Kommandodaten verglichen. Stimmen die beiden MAC-Werte nicht überein, wird der FBZ des KChip um eins dekrementiert und das Kommando mit dem Returncode '63 Cx' abgebrochen. Dabei gibt 'x' den Wert dieses Fehlbedienungszählers und somit die Anzahl der weiteren Versuche an, also 'x' = 'F' ... '0'.
  • Stimmt der MAC aus den Kommandodaten mit dem berechneten MAC(VDaten) überein, ersetzt der Chip im Startbereich VID, KID und KV des Schlüssels KChip durch VID2, KID2 und KV2 und KChip durch KChip_Verlag und setzt den zugehörigen FBZ auf '10'. Anschließend wird das 8 Byte lange Chippasswort im Startbereich durch den Wert MAC(VDaten) (= CHIPPWD) ersetzt und der FBZ des Chippasswortes auf '03' gesetzt. Der Chipzustand wird auf 2 gesetzt. Dann wird ein Flag im flüchtigen Speicher gesetzt, das die erfolgreiche Verifikation des Chippassworts signalisiert und das Kommando mit Returncode '90 00' beendet.
  • LC = '1E' ohne Schlüsselwechsel:
  • Falls das Tripel (VID, KID, KV) identisch ist mit (VID2, KID2, KV2), wird CHIPPWD im Startbereich mit dem in den Kommandodaten übergebenen Wert MAC(VDaten) verglichen. Diese Prüfung verläuft mit Ausnahme der Änderung des Chipzustands wie im Modus LC = '08':
    Ist der Wert des Fehlbedienungszählers des Chippasswortes '00', so wird das Kommando mit dem Returncode '69 83' abgebrochen. Stimmen die beiden Werte für CHIPPWD nicht überein, wird der FBZ des Chippasswortes um eins dekrementiert und das Kommando wird mit dem Returncode '63 Cx' abgebrochen. Dabei gibt 'x' den Wert dieses FBZ und somit die Anzahl der weiteren Versuche an, also 'x' = '2', '1' oder '0'. Ist der Vergleich erfolgreich, so wird der FBZ des Chippasswortes auf den Initialwert '03' zurückgesetzt und im flüchtigen Speicher wird ein Flag gesetzt, das die erfolgreiche Verifikation des Chippass- Wortes signalisiert. Der Chipzustand wird auf 2 gesetzt und das Kommando wird mit der Ausgabe des Returncodes '90 00' beendet.
  • Außer dem Wechsel von KChip zu KChip_Verlag ist es mit diesem Kommando im Modus LC = '1E' ebenfalls möglich, von einem Verlagsschlüssel KChip_Verlag auf einen anderen Verlagsschlüssel KChip Verlag zu wechseln. Dabei wird im Chip der alte KChip_Verlag behandelt wie oben beschrieben der KChip. Hierzu bedarf es der entsprechenden Kommandodaten mit der Chiffre des neuen unter dem alten KChip_Verlag und dem neuen Chippasswort.
    • Funktion des Kommandos:
    • Überprüfung und Verarbeitung des Chippasswortes, ggf. Schlüsseltausch
    • Eingabelänge: LC '1E' oder '08'
    • Kommandodaten:
    • falls LC = '1E': VID1 KID1 ∥ KV1 VID2 ∥ KID2 ∥ KV2 ∥ [KChip_Verlag] ∥
    • MAC(VDaten)
    • falls LC = '08': 8 Byte langes Chippasswort CHIPPWD
    • Returncodes:
    • '90 00' erfolgreich ausgeführt
    • '6E 00' ungültiger CLA-Wert
    • '6D 00' ungültiger INS-Wert
    • '6A 86' ungültiger Wert in P1 oder P2
    • '67 00' falsche Länge
    • '6F 00' allgemeiner Fehler – technisches Problem
    • '63 Cx' Authentikation gescheitert, 'x' weitere Versuche möglich
    • '69 83' Authentikation blockiert (Fehlbedienungszähler = '00')
    • '64 00' Execution Error, State of non-volatile memory unchanged (wird ausgegeben, wenn beim Lesen von Daten inhaltliche Fehler oder Inkonsistenzen festgestellt werden)
  • Der weitere Initialisierungsvorgang für den Chip der Signaturkarte erfolgt durch Laden der Initialisierungstabelle in den Chip. Um den höheren Sicherheitsan forderungen einer Signaturkarte zu genügen, ist das Initialisierungsimage gegen Manipulation geschützt.
  • Laden des Initialisierungsimages in den Chip:
  • In der Initialisierungsumgebung des Chipkartenherstellers werden nach Einbringung des verlagsspezifischen Schlüssels K-Chip-Verlag in den Speicherplatz 21 zunächst die Bereichsgrenzen BTAB für das Initialisierungsimage übergeben. Dazu enthält der Teil CTRL_TAB der Initialisierungstabelle das INITIALIZE-Kommando mit dem Parameter BTAB. Der Chip akzeptiert die in BTAB vorgegebenen Werte für die Bereichsgrenzen nur, wenn so der Bereich gegenüber den Vorgaben von BChip im Startbereich des Chips eingeschränkt wird oder gleich bleibt. Der Chipzustand ändert sich anschließend auf „Image laden". Ein späteres Überschreiben von BTAB wird durch den Chip bis zum erfolgreichen Abschluss des VERIFY_EEPROM-Kommandos oder bis zu einer Reinitialisierung ausgeschlossen. Keinesfalls darf es möglich sein, als zu initialisierenden Adressbereich Teile des Start-Bereichs des EEPROMs oder andere Speicherbereiche außerhalb des Code-Daten-Bereichs anzugeben und zu manipulieren.
  • Im nächsten Schritt wird der Code-/Daten-Bereich des EEPROMs von der Initialisierungsanlage des Chipkartenherstellers anhand der Initialisierungstabelle wie in 2 dargestellt initialisiert, wobei hier die zu initialisierenden Adressbereiche des EEPROMs vom Betriebssystem auf ihre Lage innerhalb der durch BTAB vorgegebenen Bereichsgrenzen überprüft werden:
    Anschließend werden die Daten in den Prüfbereich eingebracht, siehe 4. Neben dem erwähnten Speicherplatz 21 für den verlagsspezifischen Schlüssel K-Chip-Verlag gibt es weitere Speicherplätze 20 und 22 bis 24, die bei der Initialisierung mit Prüfdaten besetzt werden.
  • Die Prüfdaten enthalten (auf der Schnittstelle zwischen Initialisierungsmaschine und Chipkarte):
    den mit K-Chip-Verlag verschlüsselten Triple-DES-Schlüssel KINITAB_MAC,
    den mit K-Chip-Verlag verschlüsselten Triple-DES-Personalisierungs-Schlüssel KPers,
    den mit K-Chip-Verlag verschlüsselten Triple-DES-Personalisierungs-Schlüssel KTransfer,
    die Zuordnung Z mit der Halbleiter/ROM-Masken-Kombination, die bei VERIFY_EEPROM gegen eine vorhandene Eintragung im Startbereich des Chip-EEPROMs geprüft wird,
    den MAC über den Code-/Daten-Bereich,
    die Zusatzinformation Info-PK-Verlag zum PK-Verlag-Chip,
    den öffentlichen Schlüssel PK-Verlag-Chip,
    die verlagsspezifische Kennzeichnung der Initialisierung und
    die Signatur über den Hash-Wert von KINITAB_MAC ∥ KPers ∥ KTransfer ∥ Z ∥ BTAB ∥ MAC (Image) ∥ Info_PK_Verlag ∥ verlagsspezifische Kennzeichnung der Initialisierung.
  • Danach erfolgt eine Überprüfung, ob die Inhalte des Code/Datenbereichs 5 des EEPROMS 2 der Chipkarte authentisch sind. Dazu wird ein entsprechendes Kommando an den Chip geschickt. Dies führt zu folgenden Vorgängen:
    Das Betriebssystem des Chips bildet zunächst den Hash-Wert über den im Prüf-Bereich des Speichers gespeicherten öffentlichen Schlüssels PK-Verlag-Chip und vergleicht diesen mit dem über Info-PK-Verlag referenzierten, in der ROM-Maske hinterlegten Hash-Wert. Stimmt der berechnete Hash-Wert mit dem zugehörigen, in der ROM-Maske vorhandenen Hash-Wert überein, ist der im Prüf-Bereich gespeicherte PK-Verlag-Chip authentisch.
  • Dann prüft der Chip mit dem Schlüssel PK-Verlag-Chip die Signatur über die Prüfdaten P = (KINITAB_MAC ∥ KPers ∥ KTransfer ∥ Z ∥ BTAB ∥ MAC über das Initialisierungsimage ∥ Info_PK_Verlag ∥ verlagsspezifische Kennzeichnung der Initialisierung). Dazu wird zunächst der Hash-Wert (SHA-1) über P gebildet und anschließend mit dem Hash-Wert, der sich durch RSA-Public-Key- Verschlüsselung der Signatur über P mit Hilfe des PK-Verlag-Chip ergibt, verglichen. Stimmen die beiden Hash-Werte überein, sind insbesondere der eingebrachte KINITAB_MAC und der MAC über den EEPROM-Inhalt des Code-/Daten-Bereichs authentisch. Die Prüfdaten werden nur akzeptiert, wenn Z mit dem entsprechenden Kennzeichen der Chipherstellerdaten im Startbereich übereinstimmt.
  • Anschließend berechnet der Chip mit dem Schlüssel KINITAB_MAC unter Verwendung der Bereichsgrenzen BTAB den MAC über den Code-/Daten-Bereich des EEPROMs (inkl. der Protokolldaten für die Chipherstellung (Byte 1–3, 8–9 und 14), für die Initialisierung (ohne die ersten 16 Byte) und für die Personalisierung) und vergleicht diesen mit dem im Prüfbereich gespeicherten MAC. Stimmen beide MACs überein, ist nachgewiesen, dass das EEPROM korrekt initialisiert wurde und das eingebrachte Initialisierungsimage authentisch ist. Nach erfolgreicher Überprüfung ändert der Chip seinen Zustand in OK. Nun kann von dem Betriebssystem die in der Sprungadresse 13 gespeicherte RETURN – Anweisung durch die Adresse der Sprungtabelle 15 im Code/Datenbereich 5 des EEPROMS 2 ersetzt werden. Damit werden die Unterprogrammaufrufe des ROM Codes nicht mehr gesperrt, sondern über die Sprungtabelle oder einen anderen Mechanismus an den entsprechenden Programmcode im entsprechenden Bereich 5 des EEPROMs 2 adressiert. Der Programmcode in diesem Bereich ist damit für das Betriebssystem verfügbar und ausführbar. Dies ist schematisch in 5 dargestellt.
  • Anschließend kann dann die Personalisierung durchgeführt werden. Die bisherige strikte organisatorische Trennung von Initialisierungs- und Personalisierungsumgebung muss für die Produktion der Chipkarte nicht beibehalten werden, da die Schlüssel verschlüsselt in die Chipkarte eingebracht werden.

Claims (8)

  1. Verfahren zum Produzieren von Sicherheitsmodulen, insbesondere Chipkarten mit folgenden Verfahrensschritten: 1.1 von dem Hersteller des Chips wird ein Authentikationsmerkmal, insbesondere ein geheimer Schlüssel, generiert; 1.2 das Authentikationsmerkmal wird in den nichtflüchtigen Speicher des Chips geschrieben; 1.3 der nichtflüchtige Speicher wird derart ausgebildet, dass das Authentikationsmerkmal nicht aus dem Speicher ausgelesen werden kann; 1.4 das Betriebssystem des Chips wird derart ausgebildet, dass nur unter Verwendung des Authentikationsmerkmals ein Zugriff auf den Speicher möglich ist; 1.5 dem Chipkartenhersteller wird das Authentikationsmerkmal zur Benutzung zur Verfügung gestellt; 1.6 in dem Chip erfolgt eine Überprüfung des zur Verfügung gestellten Authentikationsmerkmals mit dem in dem Chip abgespeicherten Authentikationsmerkmal; 1.7 bei erfolgreicher Überprüfung wird das Authentikationsmerkmal des Chipherstellers gegen einen Authentikationsmerkmal des Abnehmers der Chipkarte ausgetauscht; 1.8 nach dem Austausch erfolgt die Initialisierung der Chipkarte.
  2. Verfahren nach Anspruch 1, bei dem die Vertraulichkeit der Daten zur Erzeugung des Authentikationsmerkmals so gesichert wird, dass sie nur dem Chiphersteller bekannt werden und von dem Chipkartenhersteller und dem Abnehmer nur verwendet werden können.
  3. Verfahren nach Anspruch 1 oder 2, bei dem das Authentikationsmerkmal in einen speziellen Startbereich des nichtflüchtigen Speichers des Chips geschrieben wird.
  4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Betriebssystem derart ausgebildet wird, dass das Authentikationsmerkmal nur in den Startbereich (3) des nichtflüchtigen Speichers eingeschrieben werden kann.
  5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die technische Umgebung des Chipherstellers derart ausgebildet wird, dass das Authentikationsmerkmal nur in den Startbereich (3) des nichtflüchtigen Speichers eingeschrieben werden kann.
  6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Zugriff auf den Speicher des Chips durch einen statischen Passwortvergleich ermöglicht wird.
  7. Verfahren nach einem der vorhergehenden Ansprüche, bei dem beim Austausch der Authentikationsmerkmale auch ein vorher schon vorhandenes statisches Passwort gegen ein aus dem neuen Authentikationsmerkmal abgeleitetes Passwort ausgetauscht wird.
  8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem bei mehreren Abnehmern des Sicherheitsmoduls für jeden Abnehmer ein eigener geheimer Schlüssel in jedem Sicherheitsmodul gespeichert wird.
DE2002118795 2002-04-22 2002-04-22 Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls Expired - Lifetime DE10218795B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE2002118795 DE10218795B4 (de) 2002-04-22 2002-04-22 Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE2002118795 DE10218795B4 (de) 2002-04-22 2002-04-22 Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls

Publications (2)

Publication Number Publication Date
DE10218795A1 DE10218795A1 (de) 2003-11-06
DE10218795B4 true DE10218795B4 (de) 2009-03-19

Family

ID=28798832

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2002118795 Expired - Lifetime DE10218795B4 (de) 2002-04-22 2002-04-22 Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls

Country Status (1)

Country Link
DE (1) DE10218795B4 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004058020A1 (de) * 2004-12-01 2006-06-08 Siemens Ag Verfahren zur Personalisierung von Chipkarten
WO2006124357A2 (en) 2005-05-11 2006-11-23 Bigfoot Networks, Inc. Distributed processing system and method
US9455844B2 (en) 2005-09-30 2016-09-27 Qualcomm Incorporated Distributed processing system and method
US8683045B2 (en) 2006-07-17 2014-03-25 Qualcomm Incorporated Intermediate network device for host-client communication
US8874780B2 (en) 2006-07-17 2014-10-28 Qualcomm Incorporated Data buffering and notification system and methods thereof
US7908364B2 (en) 2007-01-26 2011-03-15 Bigfoot Networks, Inc. Method storing socket state information in application space for improving communication efficiency of an application program
WO2008118522A1 (en) 2007-03-23 2008-10-02 Bigfoot Networks, Inc. Distributed processing system and method
EP2143000A4 (de) 2007-03-26 2011-04-27 Bigfoot Networks Inc Verfahren und system zur kommunikation zwischen knoten
KR101540129B1 (ko) 2007-07-20 2015-07-28 퀄컴 인코포레이티드 원격 액세스 진단 디바이스 및 이의 방법들
WO2009014971A1 (en) 2007-07-20 2009-01-29 Bigfoot Networks, Inc. Client authentication device and methods thereof
KR101561716B1 (ko) 2007-11-29 2015-10-19 퀄컴 인코포레이티드 원격 메시지 라우팅 디바이스 및 이의 방법들

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3809170A1 (de) * 1987-03-24 1988-10-13 Mitsubishi Electric Corp System zur ausstellung von gesicherten ic-karten
WO1999018504A1 (en) * 1997-10-03 1999-04-15 Atmel Corporation Secure memory having multiple security levels
US6367011B1 (en) * 1997-10-14 2002-04-02 Visa International Service Association Personalization of smart cards

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3809170A1 (de) * 1987-03-24 1988-10-13 Mitsubishi Electric Corp System zur ausstellung von gesicherten ic-karten
WO1999018504A1 (en) * 1997-10-03 1999-04-15 Atmel Corporation Secure memory having multiple security levels
US6367011B1 (en) * 1997-10-14 2002-04-02 Visa International Service Association Personalization of smart cards

Also Published As

Publication number Publication date
DE10218795A1 (de) 2003-11-06

Similar Documents

Publication Publication Date Title
DE3700663C2 (de)
DE69823649T2 (de) Multi-anwendungs ic-kartensystem
DE10218795B4 (de) Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls
DE10108487A1 (de) Verfahren und System zur verteilten Erstellung eines Programms für einen programmierbaren, tragbaren Datenträger
EP3204850A1 (de) Verfahren zum laden von ausführbaren programminstruktionen in eine chipkarte im wirkbetrieb
EP1196902B1 (de) Verfahren zum betreiben eines zur ausführung von nachladbaren funktionsprogrammen ausgebildeten datenträgers
EP1532510A2 (de) VERFAHREN ZUM SCHUTZ VOR MANIPULATIONEN AN EINEM STEUERGERÄT FÜR MINDESTENS EINE Kfz-KOMPONENTE UND STEUERGERÄT
DE19925389A1 (de) Verfahren und Vorrichtung zur Übertragung von Daten auf SmartCards
EP0280035B1 (de) Verfahren zum Sichern von Programmen und zur Integritätskontrolle gesicherter Programme
DE10218835B4 (de) Verfahren zum Herstellen einer Chipkarte und Chipkarte
EP1784756B1 (de) Verfahren und sicherheitssystem zur sicheren und eindeutigen kodierung eines sicherheitsmoduls
DE102011010627A1 (de) Verfahren zur Programmierung eines Mobilendgeräte-Chips
DE102007041370B4 (de) Chipkarte, elektronisches Gerät, Verfahren zur Herstellung einer Chipkarte und Verfahren zur Inbenutzungnahme einer Chipkarte
DE10340861A1 (de) Prozessorschaltung und Verfahren zum Zuordnen eines Logikchips zu einem Speicherchip
DE19716015A1 (de) Einbringen von Information auf einer Chipkarte
EP0847031B1 (de) Verfahren zum gesicherten nachträglichen Programmieren einer Mikroprozessorkarte für eine zusätzliche Anwendung
EP1722336A2 (de) Vorrichtung und Verfahren zur Erzeugung von Daten für eine Initialisierung von Sicherheitsdatenträgern
EP2850553B1 (de) Elektronisches zugangsschutzsystem, verfahren zum betrieb eines computersystems, chipkarte und firmwarekomponente
DE10218796A1 (de) Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls
DE60216106T2 (de) Geschützte lesung von rechnerbefehlen in einem datenverarbeitungssystem
DE69738548T2 (de) Dynamisches dateninterpretationsverfahren für eine chipkarte
EP0977160B1 (de) Verfahren und Datenverarbeitungsanordnung zum gesicherten Ausführen von Befehlen
DE102009021011A1 (de) Elektronischer Schlüssel zur Authentifizierung
DE102021000603A1 (de) Chip-Initialisierung mit Betriebssystemladen
DE10235381A1 (de) Verfahren zum Überspielen wenigstens eines Datensatzes aus einer externen Datenquelle in eine Recheneinheit, sowie Recheneinheit

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
8364 No opposition during term of opposition
R071 Expiry of right