DE69836633T2 - Datentransportschlüsselsatz für chipkarten - Google Patents

Datentransportschlüsselsatz für chipkarten Download PDF

Info

Publication number
DE69836633T2
DE69836633T2 DE69836633T DE69836633T DE69836633T2 DE 69836633 T2 DE69836633 T2 DE 69836633T2 DE 69836633 T DE69836633 T DE 69836633T DE 69836633 T DE69836633 T DE 69836633T DE 69836633 T2 DE69836633 T2 DE 69836633T2
Authority
DE
Germany
Prior art keywords
card
data
key
public
application
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
DE69836633T
Other languages
English (en)
Other versions
DE69836633D1 (de
Inventor
Philip Timothy Radlett RICHARDS
Barrington David Brighton EVERETT
Charles John VINER
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.)
STEPNEXUS HOLDINGS, GEORGETOWN, GRAND CAYMAN, KY
Original Assignee
BAMBOO HOLDINGS GEORGETOWN
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 BAMBOO HOLDINGS GEORGETOWN filed Critical BAMBOO HOLDINGS GEORGETOWN
Publication of DE69836633D1 publication Critical patent/DE69836633D1/de
Application granted granted Critical
Publication of DE69836633T2 publication Critical patent/DE69836633T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms 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/10—Mechanisms 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/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/0719—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips at least one of the integrated circuit chips comprising an arrangement for application selection, e.g. an acceleration sensor or a set of radio buttons
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment 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/355—Personalisation of cards for use
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment 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/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment 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/357—Cards having a plurality of specified features
    • G06Q20/3576—Multiple memory zones on card
    • G06Q20/35765—Access rights to memory zones
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms 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/10—Mechanisms 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/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system

Description

  • HINTERGRUND DER ERFINDUNG
  • IC-(Integrated Circuit)-Karten werden in zunehmendem Maße für viele verschiedene Zwecke in der heutigen Welt eingesetzt. Eine IC-Karte (auch Smartcard genannt) hat gewöhnlich die Größe einer herkömmlichen Kreditkarte, die einen Computerchip enthält, der einen Mikroprozessor, einen Festwertspeicher (ROM), einen elektrisch löschbaren programmierbaren Festwertspeicher (EEPROM), einen Ein-/Ausgabe-(E/A)-Mechanismus sowie andere Schaltungen zum Unterstützen des Mikroprozessors bei seinen Operationen aufweist. Eine IC-Karte kann in ihrem Speicher eine einzelne Anwendung oder mehrere unabhängige Anwendungen haben. MDLTOSTM ist ein Mehranwendungsbetriebssystem, das unter anderen Plattformen auf IC-Karten läuft und die Ausführung mehrerer Anwendungen auf der Karte selbst zulässt. So kann ein Kartenbenutzer viele in der Karte gespeicherte Programme (z.B. Kredit/Debit, elektronische(s) Bargeld/Geldbörse und/oder Loyalitätsanwendungen) unabhängig vom Terminaltyp (d.h. ATM, Telefon und/oder POS) laufen lassen, in den die Karte für den Gebrauch eingeführt wurde.
  • Auf eine konventionelle IC-Karte für eine Anwendung, wie z.B. eine Telefonkarte oder eine Elektronisches-Bargeld-Karte, wird bei der Herstellung und vor der Ausgabe an einen Kartenbenutzer eine einzelne Anwendung geladen. Diese Anwendung kann jedoch nach der Ausgabe der Karte nicht mehr modifiziert oder geändert werden, sogar wenn die Modifikation vom Kartenbenutzer oder Kartenausgeber gewünscht wird. Ferner müsste der Kartenbenutzer, wenn er die Ausführung einer Reihe verschiedener Anwendungsfunktionen durch von ihm ausgegebene IC-Karten wünscht, wie z.B. Elektronische Geldbörse und eine Kredit/Debit-Funktion, mehrere physische Karten bei sich führen, was recht aufwändig und unpraktisch wäre. Wenn ein Anwendungsentwickler oder Kartenbenutzer wünscht, dass zwei unterschiedliche Anwendungen interagieren oder Daten miteinander austauschen, wie z.B. bei einer Geldbörsenanwendung, die mit einer Vielflieger-Loyalitätsanwendung interagiert, dann müsste der Kartenbenutzer mehrere Karten abwechselnd in den Kartenaufnahmeterminal einführen und herausnehmen, was die Transaktion erschwert und sie langwierig und unpraktisch macht.
  • Es ist daher von Nutzen, mehrere Anwendungen auf derselben IC-Karte zu speichern. So kann ein Kartenbenutzer beispielsweise sowohl eine Geldbörsenanwendung als auch eine Kredit/Debit-Anwendung auf derselben Karte haben, so dass er wählen kann, welchen Zahlungstyp (elektronisches Bargeld oder Kreditkarte) er für einen Kauf benutzen möchte. Mehrere Anwendungen könnten auf einer IC-Karte dann vorgesehen werden, wenn genügend Speicherkapazität vorliegt und ein Betriebssystem, das mehrere Anwendungen unterstützen kann, auf der Karte vorhanden ist. Es könnten zwar mehrere Anwendungen vorgewählt und bei der Produktion im Speicher der Karte platziert werden, aber es wäre auch nützlich, die Möglichkeit zu haben, Anwendungen nach der Produktion der Karte nach Bedarf laden und löschen zu können.
  • Die erhöhte Flexibilität und Leistung des Speicherns mehrerer Anwendungen auf einer einzelnen Karte erfordert die Überwindung neuer technischer Herausforderungen in Bezug auf die Intaktheit und Sicherheit der Informationen (einschließlich Anwendungscode und assoziierter Daten), die zwischen der individuellen Karte und dem Anwendungsanbieter sowie innerhalb des gesamten Systems beim Laden und Löschen von Anwendungen ausgetauscht werden. Es wäre nützlich, die Möglichkeit zu haben, dass das IC-Kartensystem Daten zwischen Karten, Kartenausgebern, Systembetreibern und Anwendungsanbietern sicher austauscht und Anwendungen auf sichere Weise jederzeit von einem lokalen Terminal oder ortsfern über eine Telefonleitung, eine Internet- oder Intranet-Verbindung oder eine andere Datenleitung lädt und löscht. Da diese Datenübertragungsleitungen typischerweise keine sicheren Leitungen sind, müssen mehrere Sicherheits- und Entitätsauthentifizierungstechniken ausgeführt werden, um sicherzustellen, dass nicht unbefugt in über die Übertragungsleitungen gesendete Anwendungen eingegriffen werden kann und nur auf die gewünschten Karten geladen wird.
  • Wie erwähnt, ist es wichtig, besonders dann, wenn immer mehr neue Anwendungen für den Kartenhalter verfügbar werden, dass das System es zulässt, dass Anwendungen nach der Ausgabe auf die IC-Karte geladen werden. Dies ist notwendig, um die Langlebigkeit der IC-Karten zu schützen, da die Karte sonst nutzlos würde, wenn eine Anwendung überaltert. Es wäre nützlich, wenn Anwendungen von einem fernen Ort wie auch über eine Direktverbindung auf den Terminal eines Anwendungsanbieters addiert werden könnten. So wäre es beispielsweise nützlich, wenn ein Kartenbenutzer seine IC-Karte einfach in einen Heimcomputer einstecken und eine Anwendung über das Internet herunterladen könnte. Diese Art von Fernladung von Anwendungen ist mit einer Reihe von Sicherheitsrisiken verbunden, wenn der Anwendungscode und zugehörige Daten über eine unsichere Kommunikationsleitung wie z.B. das Internet übertragen werden.
  • Eine Entität, die eine Anwendung oder Daten auf eine IC-Karte überträgt, verlangt, dass nur die beabsichtigte IC-Karte die übertragenen Daten empfängt. Dritte dürfen die Daten nicht abfangen und betrachten können. Zudem erfordert eine Übertragungsentität eine Verifizierung, dass die IC-Karte, die Informationen angefordert hat, tatsächlich Teil des gesamten IC-Kartensystems ist und sich nicht einfach als Teil des Systems ausgibt. Diese Besorgnisse gelten sowohl für das Fernladen von Anwendungen als auch für das lokale Laden von Anwendungen über ein Terminal.
  • Es ist demgemäß eine Aufgabe von Ausgestaltungen der vorliegenden Erfindung, eine Übertragungstechnik mit verbesserter Sicherheit und speziell zum Bereitstellen eines IC-Kartensystems bereitzustellen, das die Übertragung von Daten mit verbesserter Sicherheit einschließlich Smartcard-Anwendungen zulässt, die auf IC-Karten geladen werden können.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Diese und andere Ziele werden mit einer Ausgestaltung der vorliegenden Erfindung erreicht, die ein(e) IC-Kartenverfahren und Vorrichtung zum sicheren Übertragen von Daten einschließlich einer Anwendung auf eine IC-Karte gemäß Definition in den Ansprüchen 1 und 8 bereitstellt.
  • In einer bevorzugten Ausgestaltung verschlüsselt (oder signiert digital) eine Certification Authority („CA") oder die Entität, die die Gesamtsicherheit des IC-Kartensystems verwaltet, eine Kopie des Public-Key der IC-Karte und die signierte Kopie wird ebenfalls auf der IC-Karte gespeichert. Die die Daten auf die IC-Karte übertragende Entität kann prüfen, ob die CA die Karte zugelassen hat, indem sie den signierten Public-Key unter Verwendung des signierten Public-Key der IC-Karte herunterlädt und ihn mit dem Public-Key der CA verifiziert. Wenn die Verifikation erfolgreich ist, dann hat die Entität festgestellt, dass die CA die IC-Karte zugelassen hat.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Weitere Aufgaben, Merkmale und Vorteile von Ausgestaltungen der Erfindung gehen aus der nachfolgenden ausführlichen Beschreibung hervor, die beispielhaft in Verbindung mit den Begleitzeichnungen zu sehen ist, die illustrative Ausgestaltungen der Erfindung zeigen. Dabei zeigt:
  • 1A ein Blockdiagramm des sicheren Datenübertragungssystems, das auf sichere Weise Daten von einer Übertragungsentität auf eine IC-Karte überträgt;
  • 1B ein Blockdiagramm des Anwendungsladesystems, das eine Anwendung von einem Anwendungsanbieter auf eine IC-Karte lädt;
  • 2 eine grafische Darstellung des Inhalts einer Anwendungsladeeinheit;
  • 3 eine grafische Darstellung einer Anwendungseinheit;
  • 4 ein Ablaufschema der Schritte zum Bereitstellen eines individuellen Key-Set für eine IC-Karte;
  • 5 eine grafische Darstellung einer Key-Transformationseinheit;
  • 6 eine grafische Darstellung eines Klartexts einer Key-Transformationseinheit;
  • 7 eine grafische Darstellung des Anwendungsladezertifikats;
  • 8 eine grafische Darstellung der entschlüsselten Anwendungseinheit;
  • 9 ein Ablaufschema, das die Schritte beim Bearbeiten der Anwendungsladeeinheit illustriert;
  • 10 ein Ablaufschema, das die beim Bearbeiten der KTU ausgeführten Schritte illustriert; und
  • 11 ein Blockdiagramm, das die Komponenten einer IC-Karte zeigt, die die Anwendungsladeeinheit empfangen und verarbeiten kann.
  • In den Figuren werden, wenn nicht anders angegeben, dieselben Bezugsziffern und Zeichen zum Kennzeichnen gleichartiger Merkmale, Elemente, Komponenten oder Teile der illustrierten Ausgestaltung verwendet. Ferner wird der Erfindungsgegenstand zwar jetzt ausführlich mit Bezug auf die Figuren beschrieben, aber dies erfolgt in Verbindung mit den illustrierten Ausgestaltungen.
  • AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
  • Es ist nützlich, jederzeit während der Lebensdauer von IC-Karten, die Mehranwendungsbetriebssysteme enthalten, Anwendungen darauf laden zu können. Diese Flexibilität gestattet es dem Benutzer einer Karte, der IC-Karte periodisch neue Anwendungen hinzuzufügen, und lässt es auch zu, ältere Anwendungen mit neu herausgekommenen Versionen der Anwendung zu aktualisieren. So beginnt ein Kartenbenutzer möglicherweise z.B. mit einer IC-Karte, die eine auf seiner IC-Karte gespeicherte Geldbörsen- oder Elektronisches-Bargeld-Anwendung (z.B. MONDEXTM) enthält. Einige Zeit nach dem Erwerb der Karte möchte der Benutzer möglicherweise eine zusätzliche Anwendung wie z.B. eine Kredit/Debit-Anwendung auf die Karte laden. Einige Zeit nach dem Laden der Kredit/Debit-Anwendung auf die Karte wird möglicherweise eine neue Version der Kredit/Debit-Anwendung verfügbar und der Kartenbenutzer sollte die alte Anwendung auf seiner IC-Karte löschen und durch die neue Version der Kredit/Debit-Anwendung ersetzen können, die zusätzliche Merkmale enthalten kann. Ferner muss eine IC-Karte Daten in Bezug auf persönliche Informationen wie z.B. neue Kreditkartenkontonummern oder aktualisierte Informationen empfangen.
  • Die Flexibilität zum Laden von Anwendungen und zum Übertragen von Daten zu verschiedenen Zeiten während der Lebensdauer der IC-Karte wirft Sicherheitsfragen in Bezug auf den Vorgang des Ladens von Anwendungen auf die Karte auf. In einer Umgebung mit einem Mehranwendungsbetriebssystem ist es nützlich, Anwendungen und Daten sowohl an Terminals wie z.B. einer ATM-Maschine einer Bank als auch über Fernkommunikationsverbindungen wie Telefonleitungen, Kabelleitungen, das Internet, Satellit oder mit anderen Kommunikationsmitteln laden zu können. Beim Laden von Anwendungen und Daten auf eine IC-Karte muss der Anwendungsanbieter Sicherheit in Bezug auf die zu ladenden Anwendungen bereitstellen. Zunächst muss der Anwendungsanbieter sicherstellen, dass die Anwendung nur zum richtigen Kartenbenutzer gesendet wird, der die Anwendung erhalten soll. Zweitens, die Anwendung und assoziierte Daten können private oder geheime Geschäftsinformationen beinhalten, die verschlüsselt werden müssen, damit keine anderen Entitäten als die IC-Karte den Inhalt des/der verschlüsselten Anwendungscodes und Daten einsehen können. Ein Teil des Anwendungscodes und der Daten ist möglicherweise geheim, während es andere Teile nicht sind. Diese Belange der Authentifizierung und des Schutzes des Inhalts eines Teils oder der gesamten Anwendung und der assoziierten Daten, die auf eine Karte geladen werden, werden hierin angegangen.
  • Es wird hierin eine Reihe von Ver-/Entschlüsselungstechniken beschrieben. Es gibt zwei Grundtypen der Verschlüsselung, nämlich symmetrische Verschlüsselung und asymmetrische Verschlüsselung. Symmetrische Verschlüsselung arbeitet mit einem Secret-Key als Teil einer mathematischen Formel, die Daten durch Umwandeln mittels der Formel und des Key verschlüsselt.
  • Nach dem Verschlüsseln der Daten kann eine andere Partei die verschlüsselten Daten unter Verwendung desselben Secret-Key mit einem Entschlüsselungsalgorithmus entschlüsseln. So wird derselbe Key zum Ver- und Entschlüsseln benutzt, daher ist die Technik symmetrisch. Ein konventionelles Beispiel für einen symmetrischen Algorithmus ist DES.
  • Asymmetrische Verschlüsselungstechniken arbeiten mit zwei unterschiedlichen Keys eines Paares zum Ver- und Entschlüsseln von Informationen. Die beiden Keys werden gewöhnlich als Private- oder Secret-Key und als Public-Key bezeichnet. Wenn Daten mit einem Key des Paares verschlüsselt werden, dann wird der andere Key zum Entschlüsseln der Daten verwendet. Wenn ein Sender von Daten diese mit seinem Secret-Key signiert, dann kann jeder mit dem Public-Key die Meldung verifizieren. Da Public-Keys der Öffentlichkeit typischerweise bekannt sind, kann der Inhalt von mit einem Secret-Key signierten Daten nicht geschützt werden, aber der Ursprung der Daten kann dadurch verifiziert werden, dass ermittelt wird, ob die Daten mit einem bestimmten Secret-Key signiert wurden. Dieser Authentifizierungsprozess wird als digitale Signatur bezeichnet. Wenn Person A eine Meldung authentifizieren möchte, die sie zu Person B sendet, dann würde Person A das Dokument mit ihrem Secret-Key signieren. Wenn Person B die Meldung empfangen hat, dann würde sie den Public-Key von Person A zum Verifizieren der Meldung benutzen. Wenn die Meldung mit dem Public-Key verifiziert wurde, dann wüsste Person B, dass das Dokument mit dem Secret-Key von Person A signiert wurde. So wurde der Ursprung der Meldung authentifiziert.
  • Der asymmetrische Key-Satz kann ebenfalls zum Schützen des Inhalts einer Meldung verwendet werden. Wenn Person A eine verschlüsselte Meldung zu Person B senden möchte, die sonst niemand lesen kann, dann würde sie die Daten oder die Meldung mit dem Public-Key von Person B verschlüsseln und zu Person B senden. Jetzt könnte nur der Inhaber des Secret-Key von B die Daten entschlüsseln. Wenn eine Kombination von Keys verwendet wird, dann könnte eine Person die Meldung sowohl authentifizieren als auch verschlüsseln. Das asymmetrische Key-Paar hat einige leistungsstarke Anwendungen in Bezug auf Kartensicherheit. Asymmetrische Verschlüsselung ist jedoch relativ prozessoraufwändig (Prozessorkosten sind mit Rechenzeit assoziiert) im Vergleich zu symmetrischer Verschlüsselung. Ein Beispiel für eine asymmetrische Verschlüsselungsmethode ist RSA®.
  • Eine hybride symmetrische Verschlüsselung, die die Verschlüsselungsmethode leistungsstärker macht, besteht darin, Daten mit zwei symmetrischen Keys zu verschlüsseln. Diese Technik wird Dreifach-DES genannt und codiert Daten mit Key 1, decodiert sie mit Key 2 (der in der Tat die Daten weiter codiert) und codiert die Daten dann wiederum weiter mit Key 1. Nach dem Eingang der Daten an ihrem Ziel werden sie mit Key 1 decodiert, Key 2 wird zum Codieren der Daten und Key 1 zum Decodieren der Daten verwendet. Diese zusätzlichen Schritte des Codierens und Decodierens machen die Technik leistungstärker und es wird schwieriger, die Nachricht ohne beide Keys richtig zu entziffern.
  • 1A zeigt ein Blockdiagramm der beim Übertragen von Daten auf sichere Weise in einem IC-Kartensystem verwendeten Entitäten. Die übertragende Entität I kann ein Kartenausgeber, eine Bank, eine IC-Karte oder sonstige Entität sein, die Daten zu einer IC-Karte 3 übertragen möchte. Die übertragende Entität 1 leitet vorzugsweise den Datenübertragungsprozess ein. Alternativ kann die IC-Karte 3 den Datenübertragungsprozess einleiten, wenn die Karte Daten von der übertragenden Entität 1 benötigt.
  • Die übertragende Entität 1 ist mit einem Schnittstellengerät 5 (z.B. einem Terminal, der mit einer IC-Karte kommuniziert) verbunden. Die Datenleitung 7 kann eine Telefonleitung, ein Intranet, das Internet, eine Satellitenverbindung oder jeder beliebige andere Typ von Kommunikationsverbindung sein. In diesem Beispiel möchte die übertragende Entität 1, die sich fern von der IC-Karte 3 befindet, Daten auf sichere Weise zur IC-Karte senden. Da jedoch die Datenverbindung eine „offene" Verbindung ist (d.h. keine private Verbindung) und Dritte übertragene Daten evtl. abfangen oder ersetzen können, werden Sicherheitsmaßnahmen benötigt, um zu garantieren, dass nur die beabsichtigte IC-Karte die übertragenen Daten empfängt.
  • Die Certificate Authority 9 kann ebenfalls zum Authentifizieren verwendet werden, dass die IC-Karte als Teil des IC-Kartensystems validiert wurde.
  • In 1A wird ein Private- (oder Secret-) Key 19 und ein entsprechender Public-Key 15 für die IC-Karte 3 erzeugt. Die Keys werden vorzugsweise mittels eines asymmetrischen Verschlüsselungsalgorithmus wie RSA® erzeugt. Die Keys können bei der CA 9 oder an jedem anderen Ort erzeugt werden, weil sie nur für die IC-Karte 3 spezifisch sind und keine anderen Kopien geführt zu werden brauchen. Ein drittes Datenelement, das Public-Key-Zertifikat 17, wird ebenfalls erzeugt und auf der IC-Karte gespeichert.
  • Das Public-Key-Zertifikat 17 wird durch Signieren des Public-Key 15 mit dem Private-Key der CA 9 erzeugt. So kann eine Person mit dem Public-Key der CA 9 prüfen, ob die CA den Public-Key der IC-Karte digital signiert hat, um den individuellen Key-Satz der IC-Karte zu zertifizieren. Das Public-Key-Zertifikat kann von der CA beim Erzeugen des Private/Public-Key-Satzes der IC-Karte oder zu einem späteren Zeitpunkt erzeugt werden.
  • Wenn eine Datenübertragung von der übertragenden Entität 1 eingeleitet wird, dann wird die IC-Karte 3 durch das Schnittstellengerät 5 kontaktiert und die IC-Karte 3 sendet ihren Public-Key 15 und ihr Public-Key-Zertifikat 17 zur übertragenden Entität 1. Die übertragende Entität verifiziert dann das Public-Key-Zertifikat mit dem Public-Key der CA 13 (die öffentlich von der CA 9 erhältlich ist und in der übertragenden Entität 1 gespeichert werden kann), so dass ermittelt wird, ob die CA 9 den Public-Key digital signiert hat, und so dass geprüft wird, ob die IC-Karte eine gültige Karte ist.
  • Die übertragende Entität 1 verschlüsselt dann die zu übertragenden Daten mit dem Public-Key der IC-Karte. Die übertragende Entität 1 überträgt dann die verschlüsselten Daten 11 zum Schnittstellengerät 5 und zur IC-Karte 3. Die IC-Karte 3 entschlüsselt die verschlüsselten Daten mit ihrem entsprechenden Private- (auch Secret-Key genannt) Key 19. Die Daten können dann von der IC-Karte 3 verarbeitet werden. Nur die IC-Karte 3 hat eine Kopie ihres Private-Key, so dass nur die beabsichtigte IC-Karte Zugang zu den verschlüsselten Daten hat. So wird sichergestellt, dass Dritte nicht auf die verschlüsselten Daten zugreifen können und dass entsprechend nur die beabsichtigte IC-Karte die Daten lesen und verarbeiten kann.
  • 1B zeigt eine sichere Methode zum Laden von Anwendungen auf eine IC-Karte. 1B zeigt ein
  • Blockdiagramm der bei einem sicheren Anwendungsfernladeprozess verwendeten Entitäten. Der Anwendungsanbieter 101 kann ein Kartenausgeber, eine Bank oder eine andere Entität sein, die Anwendungsladedienste anbietet. Der Anwendungsanbieter 101 leitet einen Anwendungsladevorgang auf die IC-Karte 103 ein. Die IC-Karte 103 ist mit der Datenleitung 107 verbunden, die mit dem Schnittstellengerät 105 verbunden ist (z.B. ein Terminal, das mit einer IC-Karte kommuniziert). Die Datenleitung 107 kann eine Telefonleitung, ein Intranet, das Internet, eine Satellitenverbindung oder ein beliebiger anderer Typ von Kommunikationsverbindung sein. Der Anwendungsanbieter 101, der sich fern von der IC-Karte 103 befindet, möchte eine Anwendung zur IC-Karte senden und darauf laden. Da jedoch die Datenverbindung eine offene Verbindung ist und Dritte die übertragenen Anwendungen evtl. abfangen oder ersetzen können, werden Sicherheitsmaßnahmen benötigt, um die Anwendung selbst, den Anwendungsanbieter und die IC-Karte zu authentifizieren, um die Intaktheit des Systems zu gewährleisten. Die CA 109 kann ebenfalls verwendet werden, um dabei zu helfen zu authentifizieren, dass übertragene Daten Teile eines identifizierten Systems sind.
  • In 1B sendet der Anwendungsanbieter eine Anwendungsladeeinheit 111 zum Schnittstellengerät 105 und schließlich zur IC-Karte 103. Die ALU beinhaltet die Anwendung selbst sowie Sicherheitsdaten, die zum Authentifizieren und Schützen des Verwendungscodes und der assoziierten Daten nötig sind. Die ALU wird speziell in 2 und in Verbindung mit den anderen Figuren hierin erörtert. Die ALU 111 enthält vorzugsweise auch ALC-(Application Load Certificate)-Daten 113, die von der Certification Authority (CA) 109 zum Anwendungsanbieter 101 gesendet werden. Die Certification Authority verwaltet die gesamte Sicherheit des Systems durch Bereitstellen eines Application Load Certificate für jede Anwendung, die auf eine IC-Karte geladen werden soll. Der Anwendungsanbieter 101 und die IC-Karte 103 haben beide individuelle Public/Secret-Key-Sätze. Es werden jetzt die Authentifizierungs- und Sicherheitsvorgänge beschrieben.
  • 2 zeigt ein Diagramm, das die Komponenten einer Anwendungsladeeinheit illustriert, die während des Anwendungsladevorgangs vom Anwendungslader auf die IC-Karte gesendet wird. Die Anwendungsladeeinheit (ALU) 201 enthält eine Anwendungseinheit (AU) 203, eine Anwendungseinheitssignatur (AUS) 205, eine Key-Transformationseinheit (KTU) 207 und ein Anwendungsladezertifikat (ALC) 209. Die ALU 201 wird in ein bei der Datenübertragung verwendetes herkömmliches Format formatiert. Die AU 203 enthält den Anwendungscode und Daten, die auf der IC-Karte gespeichert werden sollen, von denen einige oder alle zum Schützen eines/von geheimen Teils/Teilen des Codes und/oder der Daten verschlüsselt werden. Die AU 203 wird ausführlicher in Verbindung mit 3 beschrieben.
  • Die AUS 205 ist der Anwendungscode und die Daten, die die AU 203 mit dem Secret-Key des Anwendungsanbieters digital signiert hat. Der Public-Key des Anwendungsanbieters wird als Teil des ALC 209 gesendet und dient zum Authentifizieren des Anwendungsanbieters als Urheber der Anwendung. Das ALC 209 besteht aus Kartenidentifikationsinformationen sowie dem Public-Key des Anwendungsanbieters und ist mit dem Secret-Key der Certification Authority signiert. Alle diese Elemente werden nachfolgend ausführlicher beschrieben.
  • Die KTU 207 enthält Informationen über die Verschlüsselung der AU 203 (Code und Daten der Anwendung), die ein Entschlüsseln der designierten Teile der IC-Karte zulässt, so dass die IC-Karte auf die Anwendung und die Daten zugreifen kann, schützt die Daten aber bei der Übertragung zwischen dem Anwendungsanbieter und der IC-Karte. Die KTU 207 wird mit dem Public-Key der IC-Karte verschlüsselt, für die die Anwendung gedacht ist, wodurch gewährleistet wird, dass nur die beabsichtigte IC-Karte den Anwendungscode und die Daten mit den KTU-Informationen entschlüsseln kann. Dieses Element wird in Verbindung mit 5 beschrieben.
  • 3 zeigt eine grafische Darstellung der Anwendungseinheit 203, die Teil der Anwendungsladeeinheit ist. Die AU 203 enthält sowohl den Programmcode als auch assoziierte Daten, die auf die IC-Karte des Kartenbenutzers geladen werden sollen. Der Programmcode besteht aus einer Reihe von Programmbefehlen, die vom Mikroprozessor auf der IC-Karte ausgeführt werden. Die Programmbefehle können in jeder Programmiersprache geschrieben werden, die das auf der IC-Karte gespeicherte Betriebssystem interpretieren kann.
  • So kann das Programm beispielsweise im MULTOS-System in MELTM (MULTOS Executable Language) geschrieben werden. Die meisten Anwendungen haben assoziierte Daten, die auf die Karte geladen werden müssen. So können beispielsweise Daten, die den Kartenbenutzer identifizieren, wie z.B. Name und Kontonummer einer Person, mit der Kredit/Debit-Anwendung auf sichere Weise geladen werden. Ein Anwendungsanbieter kann bei der Installation einer Elektronische-Geldbörse-Anwendung durch Daten repräsentiertes elektronisches Bargeld als Promotion bereitstellen. Einige oder alle dieser Daten sollen gegenüber Dritten geheim gehalten werden. Ferner kann der Anwendungscode selbst als proprietär angesehen werden und Teile sollen möglicherweise vor anderen geheim gehalten werden. Die Verwendung einer Key-Transformationseinheit (KTU) erlaubt es einem Anwendungsanbieter, gewählte Teile seiner Anwendung als vertraulich zu designieren und zu verschlüsseln und sie vor Dritten zu schützen.
  • Der Anwendungseinheitsteil 305 zeigt den Programmcode, der vom Anwendungsanbieter zur IC-Karte übertragen werden soll. Der Anwendungseinheitsteil 307 zeigt die assoziierten Daten, die als Teil der auf die IC-Karte zu ladenden Anwendung übertragen werden sollen. In diesem Beispiel sind drei diskrete Bereiche der Anwendungseinheit als mit einem Einfach- oder Dreifach-DES zu verschlüsseln dargestellt. Es kann mittels der hierin beschriebenen Techniken eine beliebige Zahl von Variationen in Bezug auf die verschlüsselten Teile und den Verschlüsselungstyp angewendet werden.
  • In diesem Beispiel zeigt der verschlüsselte Ort 309 den ersten Teil der Anwendungseinheit 203, der mit einer Dreifach-DES-Technik verschlüsselt wurde. Der oben beschriebene Verschlüsselungsvorgang beinhaltet die Verwendung eines symmetrischen Key und des konventionell bekannten Algorithmus auf DES-Basis zum Transformieren der Daten. Die Daten können später durch Anwenden des Key auf einen konventionell bekannten Entschlüsselungsalgorithmus auf DES-Basis wiederhergestellt werden. Der verschlüsselte Ort 311 zeigt einen zweiten Teil der Anwendungseinheit 203, der mit Dreifach-DES verschlüsselt wurde. Der verschlüsselte Ort 313 zeigt einen dritten Teil, der mit Einfach-DES verschlüsselt wurde. Einfach-DES erfordert weniger Rechenaufwand zum Entschlüsseln und nimmt im Rahmen der nachfolgend beschriebenen KTU weniger Raum ein. Wenn die Anwendungseinheit von Dritten abgefangen würde, während sie vom Anwendungslader auf die IC-Karte übertragen wird, dann könnten die verschlüsselten Teile nur dann gelesen werden, wenn die dritte Partei die richtigen Keys und den richtigen Entschlüsselungsalgorithmus hätte. Daher werden diese Informationen in der KTU geschützt.
  • Die KTU soll es zulassen, dass die IC-Karte, für die die Anwendung und die assoziierten Daten gedacht sind, die verschlüsselten Teile der Anwendungseinheit zu entschlüsseln, indem sie beschreibt, welche Teile der Anwendungseinheit verschlüsselt sind, welcher Verschlüsselungsalgorithmus benutzt wurde, sowie den/die Key(s), der/die zum Entziffern des Textes zu verwenden ist/sind. Diese Informationen sind zwischen dem Anwendungsanbieter und der beabsichtigten IC-Karte äußerst vertraulich und werden daher auf für die beabsichtigte Karte individuelle Weise geschützt. Zum Verschlüsseln der KTU, die Teil der gesamten übertragenen ALU ist, wird ein individueller Key-Satz für die jeweilige beabsichtigte IC-Karte verwendet. Der Key-Satz und seine Erzeugung werden nachfolgend beschrieben.
  • Gemäß einer Ausgestaltung der vorliegenden Erfindung besteht eine der an der CA ausgeführten Sicherheitsoperationen darin, für jede IC-Karte einen individualisierten Key-Satz zu erzeugen, der darauf gespeichert wird. Die Keys werden für eine kartenexterne Verifizierung (d.h. um zu verifizieren, dass die Karte authentisch ist) und für eine sichere Datenübertragung verwendet. Der Key-Erzeugungsvorgang ist allgemein in 4 dargestellt. Der Key-Satz besteht aus drei unterschiedlichen Key-Datenelementen: dem Secret-Key der Karte, der nur der Karte bekannt ist, dem Public-Key der Karte, der auf der Karte gespeichert ist, und dem Public-Key-Zertifikat der Karte, das der vom Secret-Key der CA signierte Public-Key der Karte ist. Die einzelnen Keys des Key-Satzes werden nachfolgend ausführlicher beschrieben.
  • In Schritt 401 wird ein kartenspezifischer Transport-Secret-Key für die individuelle IC-Karte im Speicher der Karte gespeichert. Dieser Secret-Key wird von der CA mit einer standardmäßigen asymmetrischen Verschlüsselungtechnik wie RSA® erzeugt und über ein Kartenannahmegerät auf die Karte geladen. Nach dem Speichern auf der Karte löscht die CA eventuelle Daten in Bezug auf den Secret-Key aus ihrem eigenen Speicher. So kennt nur die Karte selbst ihren Secret-Key. Das die Secret-Key-Informationen in der Karte enthaltende Datenelement wird als „mkd_sk" bezeichnet, was MULTOS Key Data Secret Key bedeutet.
  • In Schritt 403 wird ein kartenspezifischer Transport-Public-Key für die individuelle IC-Karte im Speicher der Karte gespeichert. Dieser Public-Key wird vorzugsweise von der CA mit der zum Erzeugen des Secret-Key in Schritt 401 benutzten asymmetrischen Verschlüsselungstechnik erzeugt. Wie beim Secret-Key, nach dem Speichern des Public-Key auf der Karte löscht die CA (oder ein anderer Key-Provider) die Public-Key-Daten von ihren Systemen, so dass sich die einzige Kopie des Public-Key auf der Karte befindet. Das die Public-Key-Informationen der Karte enthaltende Datenelement wird mit „mkd_pk" bezeichnet, was MULTOS Key Data Public Key bedeutet.
  • In Schritt 405 wird ein kartenspezifisches Transport-Public-Key-Zertifikat für die individuelle IC-Karte im Speicher der Karte gespeichert. Das die Public-Key-Zertifikatsinformationen der Karte enthaltende Datenelement wird mit „mkd_pk_c" bezeichnet, was MULTOS Key Data Public Key Certificate bedeuetet. Dieses Public-Key-Zertifikat wird vorzugsweise durch Signieren des Transport-Public-Key mkd_pk mit dem Secret-Key der CA wie folgt erzeugt: mkd_pk_c = [mkd_pk]CA_sk was bedeutet, dass das Public-Key-Zertifikat der individuellen Karte durch Anwenden des Secret-Key der CA auf den Public-Key der individuellen Karte gebildet wird. Der Vorgang wird bei der CA durchgeführt. Das Public-Key-Zertifikat wird von der CA behalten, so dass sie den Public-Key nach Bedarf regenerieren kann.
  • Ein Terminal kann das Public-Key-Zertifikat von den IC-Karten lesen, um zu prüfen, ob die CA die individuelle IC-Karte signiert und somit zugelassen hat. Dies erfolgt durch Verifizieren des Public-Key-Zertifikats mit der Public-Komponente des zum Signieren der mkd_pk verwendeten CA-Key-Satzes.
  • 5 ist eine grafische Darstellung des Inhalts der KTU 207, der den Kopfteil 501 und den KTU-Ciphertext-Teil 503 enthält. Wie in 5 gezeigt, beinhalten die Kopfinformationen 501´z.B. eine Kennung oder Zulassungsinformationen 505 wie z.B. die application_id_no (Anwendungsidentifikationsnummer), mcd_no (IC-Kartennummer) und/oder das msm_control_data_date (das Ausgabedatum der IC-Karte). Es könnten auch zusätzliche Kennungen einbezogen werden. Diese Kennungen gestatten es dem System zu prüfen, ob die IC-Karte, die die ALU empfängt, die beabsichtigte IC-Karte ist. Die Zulassungsdaten sind in der oben referenzierten bezogenen Anwendung ausführlich erörtert.
  • Der KTU-Ciphertext 503 entspricht dem KTU Plaintext (nicht verschlüsselt), der mit dem Public-Key mkd_pk der beabsichtigten IC-Karte wie in Box 507 gezeigt verschlüsselt wird. Der KTU Plaintext ist in 6 näher beschrieben. Den Public-Key mkd_pk holt der Anwendungsanbieter von der beabsichtigten IC-Karte ein. Der Public-Key einer IC-Karte ist für jedermann frei erhältlich und kann direkt von der Karte oder von der CA erhalten werden. Durch Verschlüsseln des KTU Plaintext mit dem Public-Key der IC-Karte kann nur die beabsichtigte IC-Karte ihren Secret-Key des Public/Secret-Key-Paares zum Entschlüsseln des KTU Ciphertext benutzen. Dies bedeutet, dass nur die beabsichtigte IC-Karte den Inhalt des KTU-Klartextes ermitteln, die verschlüsselten Teile der geladenen Anwendung identifizieren und die Keys zum Enschlüsseln und Wiederherstellen der gesamten Anwendung und zugehörigen Daten verwenden kann. Da keine andere Entität den Secret-Key der IC-Karte hat, werden Sicherheit und Intaktheit des/der übertragenen Programmcode und Daten gewährleistet.
  • 6 ist eine grafische Darstellung des KTU Plaintext 601. KTU Plaintext 601 beinhaltet vorzugsweise ein Kennungsfeld 603, ein no_area_descriptors Feld 605, ein alg_id Feld 607, ein area_start Feld 609, ein area_length Feld 611, ein key_length Feld 613, ein key_data Feld 615 sowie zusätzliche Bereichs- und Key-Felder je nach der
  • Anzahl der verschlüsselten Bereiche in der Anwendungseinheit. Kennungen 603 enthalten Identifikationsinformationen der Anwendungseinheit, zu der die KTU gehört.
  • Das no_area_descriptors Feld 605 zeigt an, wie viele verschiedene Teile der AU verschlüsselt wurden. In dem Beispiel von 3 wäre die Zahl der Bereichsdeskriptoren drei. Feld 607 enthält die Algorithmuskennung für den ersten Bereich, der verschlüsselt wurde. Der Algorithmus könnte z.B. DES oder Dreifach-DES sein. Feld 609 zeigt den Anfang des ersten verschlüsselten Bereichs an. Diese Anzeige könnte ein Versatz vom Anfang der AU sein. So könnte der Versatz z.B. 100 sein, was bedeutet, dass der erste Bereich am 100. Byte der Anwendungseinheit beginnt. Feld 611 zeigt die Bereichslänge für die ersten verschlüsselten Teile an. Dieses Feld ermöglicht es, dass der Mikroprozessor auf der IC-Karte weiß, ein wie großer Bereich verschlüsselt wurde, und mit dem Anfang des Bereichs gekoppelt kann der Mikroprozessor der IC-Karte den richtigen Teil der Anwendungseinheit entschlüsseln. Feld 613 zeigt die Key-Länge für den jeweiligen verschlüsselten Teil der Anwendungseinheit an. Die Länge des Key unterscheidet sich für unterschiedliche Verschlüsselungstechniken. Durch das Key-Length-Feld kennt die IC-Karte die Länge der Key-Daten. Feld 615 zeigt die Key-Daten für den jeweiligen verschlüsselten Teil an. Die Key-Daten werden mit der Algorithmusidentität und dem Ort des codierten Teils zum Decodieren des verschlüsselten Teils benutzt. Wenn mehr als ein verschlüsselter Bereich angezeigt wird, dann sind zusätzliche Daten, die sich auf Algorithmus, Anfangsort, Länge, Key-Länge und Key-Daten beziehen, im KTU Plaintext vorhanden. Es wurde zwar eine Reihe von Feldern beschrieben, aber nicht alle Felder sind für die Erfindung notwendig. Das wichtigste Feld ist jedoch das Key-Daten-Feld selbst.
  • 7 ist eine grafische Darstellung des Anwendungsladezertifikats (ALC) 209. Das ALC 209 beinhaltet einen Kopf 701 und einen Anwendungsanbieter-Public-Key 703. Kopf 701 und Anwendungsanbieter-Public-Key 703 werden dann mit dem CA-Secret-Key signiert (verschlüsselt). So muss die CA das ALC 209 für jede geladene Anwendung zum Anwendungsanbieter senden, weil nur die CA den CA-Private-Key kennt. Der Kopf 701 enthält Informationen über den Anwendungsanbieter und die IC-Karte, für die die Anwendung beabsichtigt ist. Das ALC 209 wird vom Anwendungsanbieter, der die Identifikationsinformation benutzen kann, in die richtige ALU gesetzt. Der Anwendungsanbieter-Public-Key 703 wird zusammen mit den Identifikationsdaten zur CA gesendet. Die CA signiert dann diese Information nach dem Verifizieren ihrer Authentizität und sendet das signierte ALC zum Anwendungsanbieter zurück. Die IC-Karte prüft das ALC 209 nach dem Erhalt des ALC 209 als Teil der ALU 201 mit dem Public-Key der CA. Dadurch wird gewährleistet, dass die CA das Anwendungsladezertifikat signiert hat und dass es echt ist. Nach dem Verifizieren der Informationen werden die Kopfidentifikationsinformationen 701 geprüft und der Public-Key des Anwendungsanbieters wird wiederhergestellt. Mit diesem Public-Key wird geprüft, ob Anwendung und Code, die auf die IC-Karte geladen werden sollen, vom richtigen Anwendungsanbieter stammen.
  • 8 ist eine grafische Darstellung der Verwendung des Public-Key des Anwendungsanbieters zum Prüfen der Signatur der AU 205, um zu prüfen, ob die AU 203 vom Anwendungsanbieter signiert wurde. Die AU-Signatur 205 wird mit dem Public-Key 801 des Anwendungsanbieters verifiziert und mit der AU 203 verglichen. Wenn die Datenblöcke übereinstimmen, dann hat die IC-Karte verifiziert, dass der Anwendungsanbieter die Anwendungseinheit signiert (verschlüsselt) hat und die Anwendung echt ist. Diese Authentifizierung ist deshalb gültig, weil nur der Anwendungsanbieter seinen eigenen Secret-Key hat. Die IC-Karte kann diese Informationen effizient verarbeiten, weil ihr der Public-Key des Anwendungsanbieters als Teil des Anwendungsladezertifikats 209 gegeben wurde, das von der CA signiert wurde. Sie braucht daher den Public-Key nicht von einem externen Ort abzurufen, um die Anwendung zu authentifizieren.
  • 9 zeigt ein Ablaufschema der Schritte zum Verarbeiten der Anwendungsladeeinheit, wenn sie von der IC-Karte empfangen wurde. Vor dem Empfangen der ALU können bei Bedarf Identitätschecks in Bezug auf die Identität der IC-Karte durchgeführt werden. Die ALU-Verarbeitungstechniken bieten eine Reihe weiterer Verifizierungen einschließlich der Verifizierung, dass die geladene Anwendung (1) vom richtigen Anwendungsanbieter kommt, (2) auf die beabsichtigte Karte geladen wird und (3) von der CA zertifiziert wurde. Die ALU-Verarbeitungstechniken erlauben auch die Übertragung von Transportentschlüsselungs-Keys, die es der IC-Karte ermöglichen, Teile des Programmcodes und der assoziierten Daten auf sichere Weise zu entschlüsseln. In Schritt 901 empfängt die IC-Karte die ALU vom Anwendungsanbieter. Die ALU kann über eine Terminalverbindung, eine kontaktlose Verbindung, ein Telefon, per Computer, Intranet, Internet oder mit einem beliebigen anderen Kommunikationsmittel übertragen werden. Die ALU wird in einen E/A-Puffer der IC-Karte zusammen mit Kopfinformationen gesetzt, die die Startadressen von AU 203, AU signiert 205, KTU 207 und ALC 209 anzeigen. Alternativ könnte die IC-Karte die relativen Adressorte dieser vier Einheiten bestimmen.
  • In Schritt 903 wird das ALC 209 mit dem Public-Key der CA verifiziert. Jede IC-Karte speichert vorzugsweise in ihrem Speicher eine Kopie des Public-Key der CA, weil er in vielen Transaktionen verwendet wird. Die IC-Karte könnte den Public-Key aber auch von einem bekannten Speicherort holen. Wenn der Public-Key der CA das ALC 209 verifizieren kann, dann hat die IC-Karte geprüft, dass die CA das ALC 209 mit ihrem Secret-Key signiert hat und das Anwendungsladezertifikat somit in Ordnung ist. Wenn die IC-Karte das ALC nicht verifizieren kann, dann wurde das ALC nicht von der CA signiert und das Zertifikat ist nicht in Ordnung. Der Anwendungsladeprozess würde dann enden.
  • In Schritt 905 wird dann die Identität der IC-Karte anhand der im Anwendungsladezertifikat gesendeten Identifikationsinformationen geprüft, um sicherzustellen, dass die Karte für den Empfang der Anwendung beabsichtigt ist. Diese Zulassungsüberprüfung ist in der oben identifizierten verwandten Patentanmeldung beschrieben. Wenn es keine Übereinstimmung von Identifikationsdaten gibt, dann endet der Anwendungsladeprozess. Wenn die Identifikationsdaten übereinstimmen, dann wird der Vorgang fortgesetzt.
  • In Schritt 907 wird der Public-Key von Anwendungsanbietern verwendet, der vom verifizierten ALC zum Verifizieren der AU-Signatur 205 abgerufen wurde. Wenn die ALU vom Anwendungsanbieter erzeugt wurde, dann wurde die Anwendungseinheit 203 mit dem Secret-Key des Anwendungsanbieters signiert, um zu authentifizieren, dass die Anwendung vom richtigen Anwendungsanbieter kommt. Der Anwendungsanbieter sendet dann seinen Public-Key durch das ALC zur IC-Karte. Die IC-Karte verifiziert dann die AU-Signatur 205. Wenn die beiden Datenblöcke übereinstimmen, dann ist die ALU als vom Anwendungsanbieter erzeugt verifiziert. Da der Public-Key des Anwendungsanbieters Teil des ALC ist, das von der CA signiert wurde, kann die CA gewährleisten, dass der richtige Public-Key zur IC-Karte gesendet wurde. Diese eindeutige Key-Interaktion zwischen Anwendungsanbieter, CA und beabsichtigter IC-Karte stellt sicher, dass keine Fälschungen oder unzugelassenen Anwendungen oder Daten auf eine IC-Karte geladen werden, die Teil des sicheren Systems ist.
  • In Schritt 911 wird dann ein KTU-Authentifizierungscheck verarbeitet, bei dem weiter verifiziert wird, dass nur die beabsichtigte Karte die Anwendung empfangen hat. Der KTU-Authentifizierungscheck stellt sicher, dass, wenn Dritte die ALU auf irgendeine Weise abfangen, diese dritte Partei die verschlüsselten Teile der AU nicht lesen und die Keys nicht zum Entschlüsseln der AU abrufen können. Dieser Schritt ist in 10 näher erläutert.
  • 10 zeigt die Schritte des KTU-Authentifizierungsvorgangs. In Schritt 1001, der in gestrichelten Linien dargestellt ist, weil er vorzugsweise fakultativ ist, wird die Identifikation der IC-Karte ein zweites Mal geprüft. Die Identifikationsinformationen können als Teil der KTU-Daten gesendet werden. Dieser Check ist jedoch fakultativ, da er bereits einmal in Schritt 905 ausgeführt wurde.
  • In Schritt 1003 wird dann der KTU-Ciphertext 503 mit dem Secret-Key (mkd_sk) der IC-Karte entschlüsselt. Der KTU-Plaintext wurde zuvor mit dem Public-Key (mkd_pk) der beabsichtigten Karte verschlüsselt. Dies bedeutet, dass nur der Inhaber des Secret-Key der beabsichtigten Karte die verschlüsselte Meldung entschlüsseln könnte. Der Anwendungsanbieter holt den Public-Key der beabsichtigten IC-Karte entweder von der IC-Karte selbst (Erörterung des mkd-Key-Satzes siehe 4 und zugehörigen Text) oder von einer die Public-Keys enthaltenden Datenbank ab. Wenn die IC-Karte den KTU Ciphertext nicht richtig entschlüsseln kann, dann ist die KTU für diese Karte nicht gedacht und der Anwendungsladevorgang wird gestoppt. Wenn die IC-Karte den KTU Ciphertext ordnungsgemäß entziffert, dann wird der Vorgang fortgesetzt.
  • In Schritt 1005 wird ein verschlüsselter Bereich der Anwendungseinheit (AU) identifiziert. In dem Beispiel des in Verbindung mit 6 beschriebenen KTU Plaintext verwendet die IC-Karte eine relative Startadresse und ein Bereichslängenfeld zum Ermitteln des verschlüsselten Teils. In Schritt 1005 wird auch identifiziert, welche Verschlüsselungstechnik zum Verschlüsseln des identifizierten Teils benutzt wurde, so dass die richtige Entschlüsselungstechnik angewendet werden kann. So könnte die Technik beispielsweise Einfach- oder Dreifach-DES sein. Alternativ könnte die Technik eine Standardtechnik sein, die in dem System benutzt wird und nicht identifiziert zu werden braucht.
  • In Schritt 1007 wird dann der Key vom KTU Plaintext abgerufen und der identifizierte Teil wird mit der identifizierten Entschlüsselungstechnik entschlüsselt. So kann die IC-Karte den entschlüsselten Teil der AU haben und ihn in ihrem EEPROM speichern, wenn alle verschlüsselten Teile entschlüsselt sind.
  • In Schritt 1009 wird geprüft, ob es noch weitere zusätzliche verschlüsselte Bereiche gibt. In dem in 3 beschriebenen Beispiel gibt es drei verschlüsselte Bereiche. Die Zahl der verschlüsselten Bereiche war in dem Beispiel von 6 ein Feld. Die Zahl der Teile kann jedoch mit anderen konventionellen Mitteln ermittelt werden. Wenn es zusätzliche verschlüsselte Teile gibt, dann springt der Vorgang zu Schritt 1005. Wenn es keine zusätzlichen verschlüsselten Teile gibt, dann wird der Vorgang mit Schritt 1011 fortgesetzt.
  • In Schritt 1011 wird die entschlüsselte AU dann in den Speicher der IC-Karte geladen. Die ALU hat sämtliche Authentifizierungs- und Entschlüsselungschecks erfolgreich durchlaufen und die Anwendung kann sich jetzt ordnungsgemäß auf der IC-Karte befinden und kann vom Kartenbenutzer abgearbeitet und benutzt werden. Die unterschiedlichen Checks wurden zwar in den 9 und 10 in einer bestimmten Reihenfolge dargelegt, aber die Checks können in jeder beliebigen Reihenfolge ausgeführt werden. Während alle in Verbindung mit der ALU angewendeten beschriebenen Techniken die beste Sicherheit ergeben, könnten eine oder mehrere der individuellen Techniken auch für ihre individuellen Zwecke benutzt oder mit anderen konventionellen Sicherheitstechniken kombinert werden.
  • 11 zeigt ein Beispiel für ein Blockdiagramm eines IC-Kartenchips, auf den eine ALU geladen und verarbeitet werden kann. Eine integrierte Schaltung befindet sich für den Gebrauch auf einer IC-Karte. Die IC-Karte beinhaltet vorzugsweise eine Zentraleinheit 1101, einen RAM 1103, einen EEPROM 1105, einen ROM 1107, einen Timer 1109, Steuerlogik 1111, einen E/A-Port 1113 und einen Sicherheitsschaltkomplex 1115, die mit einem herkömmlichen Datenbus miteinander verbunden sind.
  • Steuerlogik 1111 in Speicherkarten bietet ausreichend Sequenzierung und Umschaltung zum Handhaben von Lese-Schreib-Zugriffen auf den Speicher der Karte durch die Ein-/Ausgangsports. Die CPU 1101 mit ihrer Steuerlogik kann Berechnungen ausführen, auf Speicherpositionen zugreifen, Speicherinhalt modifizieren und Ein-/Ausgangsports verwalten. Einige Karten haben einen Coprozessor für die Handhabung von komplexen Berechnungen wie kryptografische Operationen. Ein-/Ausgangsports 1113 werden unter der Steuerung einer CPU und Steuerlogik für Kommunikationen zwischen der Karte und einem Kartenschnittstellengerät verwendet. Der Timer 1109 (der einen Taktimpuls erzeugt oder bereitstellt) steuert die Steuerlogik 1111 und die CPU 1101 durch die Folge von Schritten zum Ausführen von Speicherzugriff, Lesen von oder Schreiben auf Speicher, Verarbeitung und Datenkommunikation an. Mit einer Zeituhr können Anwendungsmerkmale wie Rufdauer bereitgestellt werden. Ein Sicherheitsschaltkomplex 1115 beinhaltet schmelzbare Verbindungen, die die Ein-/Ausgangsleitungen mit einem internen Schaltkomplex nach Bedarf zum Testen bei der Herstellung verbinden, die aber nach dem Vollzug der Tests zerstört werden („durchbrennen"), um spätere Zugriffe zu verhüten. Die AU-Daten hinter der ALU wurden authentifiziert und verifiziert und im EEPROM 1105 gespeichert. Der Private-Key der IC-Karte wird an einer sicheren Speicherposition gespeichert. Der Public-Key der IC-Karte und das Public-Key-Zertifikat werden vorzugsweise im EEPROM 1105 gespeichert. Der hierin beschriebene Authentifizierungsvorgang wird von der CPU 1101 durchgeführt.
  • 11 zeigt auch eine mögliche Konfiguration für den Anwendungsanbieter, die übertragende Entität und für die CA. Die CPU 1101 im Anwendungsanbieter verschlüsselt die notwendigen Informationen mit hierin beschriebenen Verschlüsselungstechniken und führt die notwendigen Datenoperationen durch. Die CPU 1101 in der Certification Authority dient zum Signieren des Anwendungsladezertifikats und des Public-Key-Zertifikats wie hierin beschrieben.
  • Das oben Gesagte illustriert lediglich die Grundsätze der Erfindung. Man wird somit verstehen, dass die Fachperson in der Lage sein wird, zahlreiche Systeme und Methoden zu entwickeln, die zwar hier nicht explizit gezeigt und beschrieben sind, die aber die Grundsätze der Erfindung ausgestalten und somit in Wesen und Umfang der Erfindung fallen.
  • So wird hierin beispielsweise das Laden einer Anwendung erörtert, aber dieselben sicheren Ladevorgänge können auch auf die Übertragung anderer Datentypen wie z.B. Datenblöcke, Datenbankdateien, Textverarbeitungsdokumente oder jeden anderen Datentyp angewendet werden, der auf sichere Weise übertragen werden soll.

Claims (14)

  1. Verfahren zum Transportieren von Daten (11) auf eine IC-Karte (3) unter Verwendung eines individualisierten Key-Satzes (15, 19) für die Karte, das die folgenden Schritte beinhaltet: Speichern eines für die IC-Karte eindeutigen Private-Key- und Public-Key-Paares (15, 19) in einem Speicher, der sich auf der IC-Karte befindet; Abrufen des genannten gespeicherten Public-Key (15) von der genannten IC-Karte; Verschlüsseln von Teilen der auf die Karte zu transportierenden Daten mit dem genannten abgerufenen Public-Key; Verschlüsseln von Daten, die die verschlüsselten Teile der genannten zu der genannten IC-Karte zu transportierenden Daten (KTU) identifizieren; Verschlüsseln der genannten KTU-Daten mit dem genannten Public-Key der IC-Karte; Übertragen der verschlüsselten Daten einschließlich der verschlüsselten KTU-Daten zu der IC-Karte; Entschlüsseln der KTU-Daten; und Entschlüsseln der durch die KTU-Daten identifizierten Daten als mit dem Private-Key der IC-Karte verschlüsselt; wobei die KTU-Daten ferner identifizieren, welche Verschlüsselungstechnik zum Verschlüsseln jedes Bereiches der zu transportierenden Daten benutzt wurde.
  2. Verfahren nach Anspruch 1, das ferner den Schritt des Speicherns der genannten entschlüsselten Daten auf der genannten IC-Karte beinhaltet.
  3. Verfahren nach Anspruch 1 oder Anspruch 2, wobei eine Certification Authority den Public-Key der IC-Karte digital signiert, um ein Public-Key-Zertifikat zu erzeugen, das für die genannte Karte eindeutig und darauf gespeichert ist, und wobei das genannte Public-Key-Zertifikat vor dem genannten Übertragungsschritt verifiziert wird.
  4. Verfahren nach Anspruch 3, wobei das genannte Public-Key-Zertifikat mit dem genannten gespeicherten Public-Key der Certification Authority vor den genannten Übertragungsschritten verifiziert wird.
  5. Verfahren nach Anspruch 3 oder 4, wobei der genannte Schritt des Abrufens des genannten gespeicherten Public-Key das Entschlüsseln des genannten Public-Key-Zertifikats und das Vergleichen des genannten entschlüsselten Public-Key-Zertifikats mit dem genannten gespeicherten Public-Key beinhaltet.
  6. Verfahren nach einem der vorherigen Ansprüche, wobei die genannten Public- und Private-Keys der IC-Karte mit einer asymmetrischen Technik bereitgestellt werden.
  7. Verfahren nach Anspruch 6, wobei die genannte asymmetrische Technik RSA ist.
  8. System zum Transportieren von Daten auf eine IC-Karte (3) unter Verwendung eines individualisierten Key-Satzes (15, 19) für die Karte, das Folgendes umfasst: Mittel zum Speichern eines für die IC-Karte eindeutigen Private-Key- und Public-Key-Paares (15, 19) in einem Speicher, der sich auf der IC-Karte befindet; Mittel zum Abrufen eines gespeicherten Public-Key (15) von der IC-Karte; Mittel zum Verschlüsseln von Teilen der auf die Karte zu transportierenden Daten; Mittel zum Verschlüsseln von Daten (KTU), die die verschlüsselten Teile der genannten zu der genannten IC-Karte zu transportierenden Daten mit dem genannten Public-Key der IC-Karte identifizieren; Mittel zum Übertragen der verschlüsselten Daten einschließlich der verschlüsselten KTU-Daten auf die IC-Karte; Mittel zum Entschlüsseln der KTU-Daten; Mittel zum Entschlüsseln der Teile von Daten, die von den KTU-Daten als verschlüsselt identifiziert werden; wobei die KTU-Daten ferner die zum Verschlüsseln jedes Verschlüsselungsbereiches benutzte Verschlüsselungstechnik identifizieren, so dass eine Entschlüsselungstechnik benutzt werden kann.
  9. System nach Anspruch 8, ferner mit Mitteln zum Speichern der genannten entschlüsselten Daten auf der genannten IC-Karte.
  10. System nach Anspruch 8 oder Anspruch 9, ferner mit einem Public-Key-Zertifikat, das den von einer Certification Authority digital signierten Public-Key der IC-Karte umfasst, wobei das genannte Public-Key-Zertifikat für die genannte Karte eindeutig ist und darauf gespeichert ist; und ferner mit Mitteln zum Verifizieren des genannten Public-Key-Zertifikats.
  11. System nach Anspruch 10, wobei das genannte Mittel zum Verifizieren Mittel zum Verifizieren des genannten Public-Key-Zertifikats mit dem gespeicherten Public-Key der genannten Certification Authority beinhaltet.
  12. System nach Anspruch 10 oder Anspruch 11, wobei das genannte Mittel zum Abrufen des genannten Public-Key Mittel zum Entschlüsseln des genannten Public-Key-Zertifikats beinhaltet; und ferner mit Mitteln zum Vergleichen des genannten entschlüsselten Public-Key-Zertifikats mit dem genannten gespeicherten Public-Key.
  13. System nach einem der vorherigen Ansprüche, wobei die genannten Public- und Private-Keys der IC-Karte mit einer beliebigen asymmetrischen Technik bereitgestellt werden.
  14. System nach Anspruch 13, wobei die genannte asymmetrische Technik RSA ist.
DE69836633T 1997-05-15 1998-05-14 Datentransportschlüsselsatz für chipkarten Expired - Lifetime DE69836633T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US4651497P 1997-05-15 1997-05-15
US46514P 1997-05-15
US09/075,973 US6230267B1 (en) 1997-05-15 1998-05-11 IC card transportation key set
US75973 1998-05-11
PCT/GB1998/001405 WO1998052163A2 (en) 1997-05-15 1998-05-14 Ic card transportation key set

Publications (2)

Publication Number Publication Date
DE69836633D1 DE69836633D1 (de) 2007-01-25
DE69836633T2 true DE69836633T2 (de) 2007-11-15

Family

ID=26724016

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69836633T Expired - Lifetime DE69836633T2 (de) 1997-05-15 1998-05-14 Datentransportschlüsselsatz für chipkarten

Country Status (7)

Country Link
US (1) US6230267B1 (de)
EP (1) EP0985204B1 (de)
JP (1) JP4127862B2 (de)
AU (1) AU7777398A (de)
DE (1) DE69836633T2 (de)
HK (1) HK1023635A1 (de)
WO (1) WO1998052163A2 (de)

Families Citing this family (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6419161B1 (en) * 1996-01-22 2002-07-16 Welcome Real-Time Apparatus and method for processing coded information stored on an integrated circuit card
US6385723B1 (en) * 1997-05-15 2002-05-07 Mondex International Limited Key transformation unit for an IC card
DE19734507C2 (de) * 1997-08-08 2000-04-27 Siemens Ag Verfahren zur Echtheitsprüfung eines Datenträgers
EP1056015A4 (de) * 1998-01-21 2005-01-05 Tokyo Electron Ltd Speichervorrichtung, ver- und entschlüsselungsvorrichtung und zugriffsverfahren auf nichtflüchtige speicher
JP3969467B2 (ja) * 1998-06-17 2007-09-05 富士通株式会社 ネットワークシステム、送受信方法、送信装置、受信装置、および、記録媒体
JP2000049770A (ja) * 1998-07-31 2000-02-18 Hitachi Ltd 暗号化通信方法、暗号アルゴリズム共有管理方法、暗号アルゴリズム変換方法、ネットワーク通信システム
ATE343169T1 (de) * 1998-08-31 2006-11-15 Irdeto Access Bv System um verschlüsselte daten zu liefern, system um verschlüsselte daten zu entschlüsseln und verfahren um eine kommunikationsschnittstelle in einem solchen system zur verfügung zu stellen
EP1125182B1 (de) * 1998-10-07 2003-01-02 Adobe Systems Incorporated Zuteilung des zugriffs auf einen datensatz
DE19860203A1 (de) 1998-12-24 2000-06-29 Deutsche Telekom Ag Verfahren für die sichere Handhabung von Geld- oder Werteeinheiten mit vorausbezahlten Datenträgern
JP3483124B2 (ja) * 1999-01-21 2004-01-06 船井電機株式会社 端末装置
US6449720B1 (en) * 1999-05-17 2002-09-10 Wave Systems Corp. Public cryptographic control unit and system therefor
GB9925227D0 (en) 1999-10-25 1999-12-22 Internet Limited Data storage retrieval and access system
GB9928737D0 (en) 1999-12-03 2000-02-02 Ncr Int Inc Self-service terminal
JP4524829B2 (ja) * 2000-01-25 2010-08-18 ソニー株式会社 データ処理システム、記録デバイス、およびデータ処理方法、並びにプログラム提供媒体
US7603721B2 (en) * 2000-05-09 2009-10-13 Microsoft Corporation Restricted software and hardware usage on a computer
GB2363867A (en) * 2000-06-19 2002-01-09 Martyn Gilbert Access control method
AUPQ854300A0 (en) * 2000-07-03 2000-07-27 Funge Merger Corporation Payment systems improvements
CN1193321C (zh) * 2000-07-11 2005-03-16 卡巴闭锁系统公开股份有限公司 初始化移动数据载体的方法和设备
US6948061B1 (en) 2000-09-20 2005-09-20 Certicom Corp. Method and device for performing secure transactions
US6996547B1 (en) * 2000-09-27 2006-02-07 Motorola, Inc. Method for purchasing items over a non-secure communication channel
WO2002035464A2 (fr) * 2000-10-23 2002-05-02 Omega Electronics S.A. Systeme d'identification electronique sans contact
US20020087662A1 (en) * 2000-12-29 2002-07-04 Stephane Bouet System and method for selective updating of media files
FR2820231B1 (fr) * 2001-01-26 2005-01-21 Gemplus Card Int Carte a circuit(s) integre(s) ou carte a puce(s) integrant une couche de securisation et dispositif de communication cooperant avec une telle carte
JP2002245427A (ja) * 2001-02-20 2002-08-30 Toshiba Corp Ｉｃカード、ｉｃカード端末装置およびｉｃカード複製方法
KR100641824B1 (ko) * 2001-04-25 2006-11-06 주식회사 하렉스인포텍 대칭키 보안 알고리즘을 이용한 금융정보 입력방법 및 그이동통신용 상거래 시스템
DE10142351A1 (de) * 2001-08-30 2003-03-20 Giesecke & Devrient Gmbh Initialisieren einer Chipkarte
JP2003078518A (ja) * 2001-09-03 2003-03-14 Fuji Xerox Co Ltd 暗号化・復号システム、暗号化装置、復号装置およびそれらの方法
US6973191B2 (en) * 2001-11-02 2005-12-06 Activcard System and method for generating symmetric keys within a personal security device having minimal trust relationships
EP1391853A1 (de) 2001-11-30 2004-02-25 STMicroelectronics S.A. Diversifikation der Kennzahl einer integrierten Schaltung
FR2833119A1 (fr) 2001-11-30 2003-06-06 St Microelectronics Sa Generation de quantites secretes d'identification d'un circuit integre
EP1359550A1 (de) * 2001-11-30 2003-11-05 STMicroelectronics S.A. Wiederherstellung einer Geheimzahl mittels der Kennzahl einer integrierten Schaltung
US7085386B2 (en) * 2001-12-07 2006-08-01 Activcard System and method for secure replacement of high level cryptographic keys in a personal security device
US20050086506A1 (en) * 2001-12-17 2005-04-21 Legic Identsystems Ag Method for initialising an application terminals
US7165718B2 (en) * 2002-01-16 2007-01-23 Pathway Enterprises, Inc. Identification of an individual using a multiple purpose card
GB0210692D0 (en) 2002-05-10 2002-06-19 Assendon Ltd Smart card token for remote authentication
WO2003107193A1 (ja) * 2002-06-14 2003-12-24 松下電器産業株式会社 半導体集積回路装置、データ記憶検証装置およびデータ記憶検証方法
US20040093507A1 (en) * 2002-06-26 2004-05-13 Stephan Courcambeck Verification of the integrity of a software code executed by an integrated processor
JP3933003B2 (ja) * 2002-07-30 2007-06-20 株式会社日立製作所 Ｉｃカードおよび決済端末
JP4461351B2 (ja) * 2002-08-15 2010-05-12 ソニー株式会社 非接触式ｉｃカード
JP4501349B2 (ja) * 2003-03-13 2010-07-14 ソニー株式会社 システムモジュール実行装置
US7278165B2 (en) * 2003-03-18 2007-10-02 Sony Corporation Method and system for implementing digital rights management
JP4557969B2 (ja) * 2003-03-31 2010-10-06 エヌエックスピー ビー ヴィ スマートカードに関する変更権を付与する方法
US7552376B2 (en) * 2005-10-28 2009-06-23 International Business Machines Corporation Modeling error correction capability with estimation of defect parameters
EP2016535A4 (de) * 2006-04-19 2010-06-23 Stepnexus Holdings Verfahren und systeme zum laden einer ic-card-anwendung
US20070265977A1 (en) * 2006-05-12 2007-11-15 Chris Read Method and system for improved digital rights management
US8108940B2 (en) * 2006-12-19 2012-01-31 International Business Machines Corporation Method for protecting data from unauthorised access
US8296240B2 (en) * 2007-03-22 2012-10-23 Sony Corporation Digital rights management dongle
US8908870B2 (en) * 2007-11-01 2014-12-09 Infineon Technologies Ag Method and system for transferring information to a device
US8627079B2 (en) 2007-11-01 2014-01-07 Infineon Technologies Ag Method and system for controlling a device
US7962737B2 (en) * 2007-11-21 2011-06-14 Dell Products L.P. Methods, media and apparatus for booting diskless systems
US8250375B2 (en) * 2008-04-25 2012-08-21 Microsoft Corporation Generating unique data from electronic devices
US9230259B1 (en) 2009-03-20 2016-01-05 Jpmorgan Chase Bank, N.A. Systems and methods for mobile ordering and payment
JP5293388B2 (ja) * 2009-05-01 2013-09-18 大日本印刷株式会社 Ｉｃチップ及びデータ読み出し方法等
US9525548B2 (en) 2010-10-21 2016-12-20 Microsoft Technology Licensing, Llc Provisioning techniques
US20120143769A1 (en) * 2010-12-02 2012-06-07 Microsoft Corporation Commerce card
US8807440B1 (en) 2010-12-17 2014-08-19 Google Inc. Routing secure element payment requests to an alternate application
US8352749B2 (en) 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
US8335921B2 (en) 2010-12-17 2012-12-18 Google, Inc. Writing application data to a secure element
US8171525B1 (en) 2011-09-15 2012-05-01 Google Inc. Enabling users to select between secure service providers using a central trusted service manager
US8255687B1 (en) 2011-09-15 2012-08-28 Google Inc. Enabling users to select between secure service providers using a key escrow service
US8313036B1 (en) 2011-09-16 2012-11-20 Google Inc. Secure application directory
US8385553B1 (en) 2012-02-28 2013-02-26 Google Inc. Portable secure element
US8429409B1 (en) 2012-04-06 2013-04-23 Google Inc. Secure reset of personal and service provider information on mobile devices
US20140074704A1 (en) 2012-09-11 2014-03-13 Cashstar, Inc. Systems, methods and devices for conducting transactions with electronic passbooks
US10475024B1 (en) 2012-10-15 2019-11-12 Square, Inc. Secure smart card transactions
US9830588B2 (en) * 2013-02-26 2017-11-28 Digimarc Corporation Methods and arrangements for smartphone payments
US9311640B2 (en) 2014-02-11 2016-04-12 Digimarc Corporation Methods and arrangements for smartphone payments and transactions
SG2013071964A (en) * 2013-09-24 2015-04-29 Mastercard Asia Pacific Pte Ltd A method for electrically personalizing a payment chip and a payment chip
US9760740B1 (en) 2014-06-23 2017-09-12 Square, Inc. Terminal case with integrated dual reader stack
US10108947B2 (en) * 2014-07-31 2018-10-23 Square, Inc. Smart card reader with public key index on host device
US10753982B2 (en) 2014-12-09 2020-08-25 Square, Inc. Monitoring battery health of a battery used in a device
US10594478B2 (en) 2016-11-18 2020-03-17 International Business Machines Corporation Authenticated copying of encryption keys between secure zones
WO2019217931A1 (en) * 2018-05-11 2019-11-14 Lattice Semiconductor Corporation Asset management systems and methods for programmable logic devices
US11610188B2 (en) 2020-04-15 2023-03-21 Capital One Services, Llc Systems and methods for ATM integrated card fabricator

Family Cites Families (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2536928B1 (fr) 1982-11-30 1989-10-06 France Etat Systeme pour chiffrer et dechiffrer des informations, du type utilisant un systeme de dechiffrement a cle publique
JPS60160491A (ja) 1984-01-31 1985-08-22 Toshiba Corp Ｉｃカードとｉｃカード発行装置
JPS60207957A (ja) 1984-03-31 1985-10-19 Toshiba Corp デ−タ保護方式
JPS61177585A (ja) 1985-02-04 1986-08-09 Toshiba Corp 携帯用電子装置密封体
DE3682476D1 (de) 1985-10-07 1991-12-19 Toshiba Kawasaki Kk Tragbares elektronisches geraet.
US4816654A (en) 1986-05-16 1989-03-28 American Telephone And Telegraph Company Improved security system for a portable data carrier
US4816653A (en) 1986-05-16 1989-03-28 American Telephone And Telegraph Company Security file system for a portable data carrier
JP2537199B2 (ja) 1986-06-20 1996-09-25 株式会社東芝 Ｉｃカ―ド
JPS6373388A (ja) 1986-09-16 1988-04-02 Fujitsu Ltd 複数サ−ビス用ｉｃカ−ドの領域獲得方式
JPS63182795A (ja) 1987-01-20 1988-07-28 インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン ポータブル・カードとその製造方法
US5162989A (en) 1987-02-20 1992-11-10 Oki Electric Industry Co., Ltd. Information rental system including processor equipped IC card having data erasing means
US4949257A (en) 1987-04-28 1990-08-14 Zvi Orbach Automated merchandising system for computer software
US4868376A (en) 1987-05-15 1989-09-19 Smartcard International Inc. Intelligent portable interactive personal data system
GB2204973A (en) 1987-05-19 1988-11-23 Gen Electric Co Plc Data processing system
JP2592856B2 (ja) 1987-09-24 1997-03-19 株式会社東芝 Ｉｃカード発行システム
FR2626095B1 (fr) 1988-01-20 1991-08-30 Sgs Thomson Microelectronics Systeme de securite pour proteger des zones de programmation d'une carte a puce
JP2623332B2 (ja) 1988-02-03 1997-06-25 日立マクセル株式会社 Ｉｃカード及びその動作プログラム書込み方法
DE68927361T4 (de) 1988-08-12 1999-11-04 Hitachi Maxell Chipkarte und Verfahren zum Wiedereinschreiben ihres Programmes
GB8827288D0 (en) 1988-11-22 1988-12-29 Byron R S Articles to be worn
AU5964290A (en) 1989-07-20 1991-02-22 Cash Card Systems Limited Improvements in and relating to non-cash payment means
JPH03240127A (ja) 1990-02-17 1991-10-25 Hitachi Maxell Ltd プログラム制御システム
GB9008362D0 (en) * 1990-04-12 1990-06-13 Hackremco No 574 Limited Banking computer system
ES2047774T3 (es) 1990-07-20 1994-03-01 Siemens Nixdorf Inf Syst Procedimiento para impedir desviaciones inadmisibles del protocolo de desarrollo de una aplicacion en un sistema de intercambio de datos.
FR2666671B1 (fr) 1990-09-12 1994-08-05 Gemplus Card Int Procede de gestion d'un programme d'application charge dans un support a microcircuit.
FR2673476B1 (fr) 1991-01-18 1996-04-12 Gemplus Card Int Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur.
DE69231118T2 (de) 1991-10-18 2000-12-14 Fujitsu Ltd Nachrichtenverteilungssystem mit schnurlosen nachrichtenübertragenden Unterstationen und nachrichtenempfängende Terminalendgeräte
FR2683357A1 (fr) 1991-10-30 1993-05-07 Philips Composants Microcircuit pour carte a puce a memoire programmable protegee.
GB9126779D0 (en) 1991-12-17 1992-02-12 Int Computers Ltd Security mechanism for a computer system
FR2687816B1 (fr) 1992-02-24 1994-04-08 Gemplus Card International Procede de personnalisation d'une carte a puce.
JPH05250523A (ja) 1992-03-06 1993-09-28 Toshiba Corp 処理方式
US5745571A (en) 1992-03-30 1998-04-28 Telstra Corporation Limited Cryptographic communications method and system
GB9207840D0 (en) 1992-04-09 1992-05-27 Entertainment Express Limited Data reproducing apparatus
US5396558A (en) 1992-09-18 1995-03-07 Nippon Telegraph And Telephone Corporation Method and apparatus for settlement of accounts by IC cards
FR2697357B1 (fr) 1992-10-23 1994-12-23 Gemplus Card Int Procédé d'acquisition de logiciels et système informatique pour mettre en Óoeuvre le procédé.
EP0706692B1 (de) 1992-10-26 2003-04-16 Intellect Australia Pty. Ltd. Host-benutzer-transaktionssystem
JP3421378B2 (ja) 1993-03-23 2003-06-30 株式会社東芝 伝送制御方式
JPH0744672A (ja) 1993-07-28 1995-02-14 Oki Electric Ind Co Ltd Ｉｃカード及びｉｃカードシステム
GB9320982D0 (en) 1993-10-12 1993-12-01 Ibm A data processing system
GB2284689B (en) 1993-12-07 1998-02-18 Inventec Corp Ic card back-up generating and programming device
EP0666550B1 (de) 1994-02-08 1997-05-02 Belle Gate Investment B.V. Datenauswechselsystem mit tragbaren Datenverarbeitungseinheiten
SE502424C2 (sv) 1994-02-17 1995-10-16 Telia Ab Metod och anordning vid certifikathanteringssystem
FR2720848B1 (fr) 1994-06-03 1996-07-26 Gemplus Card Int Procédé de conduite d'une transaction entre une carte à puce et un système d'information.
FR2725537B1 (fr) 1994-10-11 1996-11-22 Bull Cp8 Procede de chargement d'une zone memoire protegee d'un dispositif de traitement de l'information et dispositif associe
US5636357A (en) 1994-12-21 1997-06-03 Eurotronics Company Memory card and method for operation in a plurality of systems having incompatible object code format requirements
DE19508724C1 (de) 1995-03-10 1996-10-31 Siemens Ag Chipkarte mit geschütztem Betriebssystem
FR2734934B1 (fr) 1995-05-30 1997-07-04 Syseca Carte a puce intelligente securisee
US5799314A (en) 1995-06-30 1998-08-25 Sun Microsystems, Inc. System and method of controlling mapping of data buffers for heterogenous programs in digital computer system
US5889941A (en) * 1996-04-15 1999-03-30 Ubiq Inc. System and apparatus for smart card personalization
CA2288824A1 (en) 1997-03-24 1998-10-01 Marc B. Kekicheff A system and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US6012636A (en) * 1997-04-22 2000-01-11 Smith; Frank E. Multiple card data system having first and second memory elements including magnetic strip and fingerprints scanning means
US6003014A (en) * 1997-08-22 1999-12-14 Visa International Service Association Method and apparatus for acquiring access using a smart card
US6128391A (en) 1997-09-22 2000-10-03 Visa International Service Association Method and apparatus for asymetric key management in a cryptographic system

Also Published As

Publication number Publication date
HK1023635A1 (en) 2000-09-15
WO1998052163A2 (en) 1998-11-19
US6230267B1 (en) 2001-05-08
DE69836633D1 (de) 2007-01-25
WO1998052163A3 (en) 1999-06-17
EP0985204A1 (de) 2000-03-15
JP2001527675A (ja) 2001-12-25
EP0985204B1 (de) 2006-12-13
JP4127862B2 (ja) 2008-07-30
AU7777398A (en) 1998-12-08

Similar Documents

Publication Publication Date Title
DE69836633T2 (de) Datentransportschlüsselsatz für chipkarten
DE69834180T2 (de) Schlüsseltransformationseinheit für eine chipkarte
EP0981807B1 (de) Chipkarte mit anwendungsinhaltsverzeichnis
DE60023705T2 (de) Sichere verteilung und schutz einer schlüsselinformation
DE69823649T2 (de) Multi-anwendungs ic-kartensystem
EP0992025B1 (de) Transaktionsverfahren mit einem tragbaren Identifizierungselement
EP1360644B1 (de) Sicherheitsmodul mit flüchtigem speicher zur speicherung eines algorithmuscodes
DE60200081T2 (de) Sichere Benutzer- und Datenauthenifizierung über ein Kommunikationsnetzwerk
US7730312B2 (en) Tamper resistant module certification authority
DE102011100144B4 (de) Sicheres drahtloses Zahlungssystem und Verfahren zu dessen Anwendung
DE19947986A1 (de) System und Verfahren zum Herunterladen von Anwendungsteilen auf eine Chipkarte
DE10212619A1 (de) Sichere Benutzerauthentisierung über ein Kommunikationsnetzwerk
DE60214539T2 (de) Elektronisches bezahlungsendgerät, an ein solches endgerät angepasste chipkarte und verfahren zum laden eines geheimschlüssels in einem solchen endgerät
DE3319919A1 (de) Schutzsystem fuer intelligenz-karten
DE19710249C2 (de) Netzwerkunterstütztes Chipkarten-Transaktionsverfahren und Anordnung zur Abwicklung von Transaktionen
DE60203041T2 (de) Verfahren und vorrichtung zum beglaubigen einer transaktion
DE69911174T2 (de) System und verfahren zur kontrolle des zugangs zu dem computercode in einer chipkarte
DE102006037879A1 (de) Lesegerät für ein Dokument, Verfahren zum Lesen eines Datenobjekts und Computerprogrammprodukt
DE60123380T2 (de) Verfahren zum beglaubigen eines tragbaren gegenstandes, dazugehöriger tragbarer gegenstand, und vorrichtung zum durchführen des verfahrens
EP0847031B1 (de) Verfahren zum gesicherten nachträglichen Programmieren einer Mikroprozessorkarte für eine zusätzliche Anwendung
WO2016146726A1 (de) Verfahren zur erzeugung eines zertifikats für einen sicherheitstoken
DE19841862A1 (de) Inegration von Chipkartenfunktionen in ein mobiles Kommunikationsgerät
EP1047028A1 (de) Kommunikationssytem und Verfahren zur effizienten Durchführung von elektronischen Transaktionen in mobilen Kommunikationsnetzen
EP2916252A1 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102009048239A1 (de) Personalisieren eines Telekommunikationsmoduls

Legal Events

Date Code Title Description
8327 Change in the person/name/address of the patent owner

Owner name: BAMBOO HOLDINGS, GEORGETOWN, GRAND CAYMAN, KY

8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: STEPNEXUS HOLDINGS, GEORGETOWN, GRAND CAYMAN, KY