DE60318407T2 - Verfahren und vorrichtung zur automatischen bewertung eines computerprogramms mit kryptografiefunktionen - Google Patents

Verfahren und vorrichtung zur automatischen bewertung eines computerprogramms mit kryptografiefunktionen Download PDF

Info

Publication number
DE60318407T2
DE60318407T2 DE60318407T DE60318407T DE60318407T2 DE 60318407 T2 DE60318407 T2 DE 60318407T2 DE 60318407 T DE60318407 T DE 60318407T DE 60318407 T DE60318407 T DE 60318407T DE 60318407 T2 DE60318407 T2 DE 60318407T2
Authority
DE
Germany
Prior art keywords
memory
function
program
data processing
data
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
DE60318407T
Other languages
English (en)
Other versions
DE60318407D1 (de
Inventor
Vincent Finkelstein
Fabrice Elisabeth
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.)
Idemia France SAS
Original Assignee
Oberthur Card Systems SA France
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 Oberthur Card Systems SA France filed Critical Oberthur Card Systems SA France
Publication of DE60318407D1 publication Critical patent/DE60318407D1/de
Application granted granted Critical
Publication of DE60318407T2 publication Critical patent/DE60318407T2/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
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577Assessing vulnerabilities and evaluating computer system security
    • 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
    • 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/0806Details of the card
    • G07F7/0813Specific details related to card security
    • G07F7/082Features insuring the integrity of the data on or in the card

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computing Systems (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)
  • Information Transfer Between Computers (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Description

  • Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum automatischen Validieren eines Datenverarbeitungsprogramms.
  • Genauer zielt die vorliegende Erfindung auf ein Verfahren zum automatischen Validieren eines Datenverarbeitungsprogramms ab, das auf einen gesicherten Speicher und auf einen nicht gesicherten Speicher zugreifen kann, wobei das Programm wenigstens eine Chiffrierungsfunktion und wenigstens eine Dechiffrierungsfunktion verwendet.
  • Die Erfindung findet vorteilhaft, jedoch nicht einschränkend, Anwendung bei der Personalisierung von Mikroschaltungskarten.
  • Bekanntermaßen umfasst die Personalisierung von Mikroschaltungskarten Verarbeitungsschritte an sensiblen Daten, d. h. geheimen Daten, die man vor jeder betrügerischen Manipulation schützen möchte.
  • Zum Beispiel kann eine solche Verarbeitung aus den folgenden aufeinanderfolgenden Operationen bestehen:
    • – Empfang von chiffrierten Eingangsdaten;
    • – Dechiffrieren dieser chiffrierten Daten mit einem geheimen Schlüssel, wobei das Ergebnis dieser Dechiffrierungsoperation erste sensible Daten sind;
    • – logische Operation, beispielsweise Verschiebung, an diesen ersten sensiblen Daten und Erhalt von zweiten sensiblen Daten; und
    • – Chiffrieren der zweiten sensiblen Daten unter Verwendung eines zweiten geheimen Schlüssels.
  • Auf dem Gebiet der Personalisierung von Mikroschaltungskarten sind verschiedene Lösungen bekannt, um derartige Verarbeitungen vorzunehmen und zudem die während der Verarbeitung erhaltenen sensiblen Daten vor jeder betrügerischen Manipulation zu schützen.
  • Eine erste bekannte Lösung besteht darin, eine Karte mit einer spezifischen Mikroschaltung herzustellen, "Root-Karte" genannt, welche die verschiedenen vorerwähnten Operationen ausführt.
  • Die Verwendung einer so definierten Root-Karte ermöglicht tatsächlich, eine absolute Sicherheit zu erzielen, da die Daten für ihre Manipulation zeitweilig in einem internen, gesicherten Speicher der Mikroschaltungskarte archiviert werden.
  • Leider ermöglicht eine Root-Karte nur, die Verarbeitungen auszuführen, für die sie entwickelt worden ist.
  • Dies bedeutet, dass es für die Anwendung einer neuen Verarbeitung erforderlich ist, eine spezifische Kartenmaske zu entwickeln, die an diese Verarbeitung angepasst ist, was nicht zu vernachlässigende Entwicklungskosten und Entwicklungszeit erfordert.
  • Um diesem Nachteil abzuhelfen, verwendet der Fachmann für die Personalisierung der Mikroschaltungskarte mitunter in bekannter Weise gesicherte Plattformen, die dafür ausgelegt sind, verschiedenartige Verarbeitungen an sensiblen Daten auszuführen.
  • Derartige Plattformen können aus gesicherten Datenverarbeitungssystemen oder spezifischen elektronischen Karten gebildet sein.
  • In diesem Kontext umfasst die Verwirklichung einer besonderen Verarbeitung eine erste Phase der Spezifizierung und der Entwicklung einer Software, um die verschiedenen Operationen dieser Verarbeitung auszuführen und die Eigenschaften zu berücksichtigen, die diesen gesicherten Plattformen eigen sind.
  • Während einer zweiten Phase wird die so entwickelte Software manuell durch Fachleute für diese Plattformen überprüft, die während dieser besonderen Bearbeitung verifizieren, dass Dritte, die eine betrügerische Absicht hegen, nicht auf sensible Daten zugreifen können.
  • Obwohl diese zweite Lösung flexibler als die Root-Karte anwendbar ist, erfordert sie gleichermaßen relativ lange Entwicklungszeiten, insbesondere wegen der Phase der manuellen Verifizierung des Programms durch eine spezialisierte Firma.
  • Die vorliegende Erfindung ermöglicht, die vorerwähnten Probleme zu lösen.
  • Genauer hat die vorliegende Erfindung ein Verfahren zum automatischen Validieren eines Datenverarbeitungsprogramms zur Aufgabe, das auf einen gesicherten Speicher und auf einen nicht gesicherten Speicher zugreifen kann, wobei das Programm wenigstens eine Chiffrierungsfunktion und wenigstens eine Dechiffrierungsfunktion verwendet; wobei dieses Validierungsverfahren einen Verifizierungsschritt enthält, in dessen Verlauf verifiziert wird:
    • – dass jede Funktion, die ausgelegt ist, um Daten aus dem gesicherten Speicher zu lesen und Daten in dem nicht gesicherten Speicher zu erzeugen, eine Chiffrierungsfunktion ist; und
    • – dass alle Daten, die durch die Dechiffrierungsfunktion erzeugt werden, in dem gesicherten Speicher gespeichert werden.
  • In der Folge wird in diesem Dokument zwischen einem "gesicherten Speicher", d. h. einen Speicher, auf den nur mittels eines verifizierenden Programms, das dieses Validierungsverfahren ausführt, zugegriffen werden kann, und einem "nicht gesicherten Speicher", auf den insbesondere von einem Anwender dieses verifizierenden Programms oder mittels anderer Datenverarbeitungsprogramme zugegriffen werden kann, unterschieden.
  • In einer ersten Ausführungsform sind der gesicherte Speicher und der nicht gesicherte Speicher unterschiedliche physische Speicher, die verschiedenen Hardware-Komponenten entsprechen.
  • In einer bevorzugten Ausführungsform sind der gesicherte Speicher und der nicht gesicherte Speicher unterschiedliche Registerbereiche ein und derselben Hardware-Komponente, wobei das Management und die Kontrolle des Zugriffs auf diese Speicher auf eine dem Fachmann bekannte Art softwaremäßig erfolgt, beispielsweise durch Speichermanagementfunktionen auf niedriger Ebene, die durch ein gesichertes Betriebssystem geliefert werden.
  • Dieses Validierungsverfahren ist besonders vorteilhaft, denn im Gegensatz zu der Root-Karte oder zu der gesicherten Plattform des Standes der Technik ermöglicht es, jedes Datenverarbeitungsprogramm zu validieren, das Kryptographiefunktionen verwendet.
  • Es verifiziert insbesondere, dass jede Funktion, die ausgelegt ist, um Daten aus dem gesicherten Speicher zu lesen und Daten in dem nicht gesicherten Speicher zu erzeugen, eine Chiffrierungsfunktion ist, wodurch sichergestellt werden kann, dass durch den Anwender dieses Verifizierungsprogramms oder durch andere Datenverarbeitungsprogramme nur auf chiffrierte Daten zugegriffen werden kann.
  • Das Validierungsverfahren gemäß der Erfindung verifiziert auch, dass alle Daten, die durch die Dechiffrierungsfunktion erzeugt sind, insbesondere alle sensiblen Daten, in dem gesicherten Speicher gespeichert sind.
  • Gemäß einem ersten Merkmal verwendet das Datenverarbeitungsprogramm außerdem wenigstens eine nicht kryptographische Funktion, die aus einer logischen Funktion, einer Funktion zum Erzeugen einer Zufallszahl oder einer Integritätskontrollfunktion ausgewählt ist.
  • Das Validierungsverfahren ermöglicht daher, jeden Programmtyp zu validieren, der Chiffrierungs-, Dechiffrierungs- und auch nicht kryptographische Funktionen verwendet.
  • Gemäß einem bevorzugten Merkmal der Erfindung umfasst dann, wenn das Datenverarbeitungsprogramm im Quellcode vorliegt, das Verfahren vor dem Verifizierungsschritt einen Schritt zum Kompilieren des Quellcodes in Binärskript, wobei der Verifizierungsschritt an dem somit erzeugten Binärskript ausgeführt wird.
  • Diese bevorzugte Ausführungsform ermöglicht, eine zusätzliche Sicherheitsebene zu erreichen, denn sie verwehrt jede betrügerische Modifikation, die nach dem Verifizierungsschritt an dem Quellcode vorgenommen werden könnte.
  • Das Datenverarbeitungsprogramm ist beispielsweise ein Programm zum Erzeugen sensibler Daten.
  • In einer bevorzugten Ausführungsform ist das Datenverarbeitungsprogramm ein Programm zum Transformieren sensibler Daten. Es nimmt beispielsweise als Eingabe erste sensible Daten entgegen, beispielsweise gesicherte Schlüssel, führt Dechiffrierungsoperationen und logische Operationen an diesen ersten sensiblen Daten aus und liefert, nach einem Chiffrieren, andere sensible Daten, beispielsweise einen geheimen Code.
  • Gemäß einem weiteren besonders vorteilhaften Merkmal ist jede Funktion, die von dem Datenverarbeitungsprogramm verwendet wird, wenigstens einer Betriebsart zugeordnet, die wenigstens eine Regel für den Zugriff auf den gesicherten Speicher und den nicht gesicherten Speicher definiert, wobei die Betriebsart in einer Verifizierungstabelle gespeichert ist, die während des Verifizierungsschrittes verwendet wird.
  • Diese Betriebsarten werden von den Programmierern während des Schrittes der Spezifizierung und Entwicklung einer speziellen Verarbeitung verwendet.
  • Gemäß der Erfindung zwingen diese Regeln insbesondere jede Dechiffrierungsfunktion, die erzeugten Daten in einem gesicherten Speicher zu speichern.
  • In einer bevorzugten Ausführungsform umfasst das Validierungsverfahren u. a.:
    • – einen Schritt zum Zuweisen des gesicherten Speichers und des nicht gesicherten Speichers;
    • – einen Schritt des Ladens eines Programms zum Verifizieren des Binärskripts in einen Arbeitsspeicher, wobei das Verifizierungsprogramm ausgelegt ist, um den Verifizierungsschritt auszuführen; und
    • – einen Schritt zum Laden des Binärskripts in den Arbeitsspeicher.
  • Diese verschiedenen Schritte werden durch ein Hauptprogramm ausgeführt, das daher die Speicherumgebung definiert, die von dem Verifizierungsprogramm zum Verifizieren des Binärskripts genutzt wird.
  • Es findet folglich auf dem Gebiet der Personalisierung von Mikroschaltungskarten, aber auch auf verschiedenen Gebieten, wie beispielsweise den elektronischen Transaktionen in Telekommunikationsservern, Anwendung.
  • Die Erfindung zielt auch auf einen Kompilierer ab, der ein Validierungsverfahren wie nachstehend mit wenigen Worten beschrieben anwendet.
  • Ein solcher Kompilierer kann vorteilhaft in einer Logikkette zur Personalisierung von Mikroschaltungskarten verwendet werden.
  • Außerdem zielt die Erfindung auf ein Verfahren zum Ausführen eines Datenverarbeitungsprogramms ab, das auf einen gesicherten Speicher und auf einen nicht gesicherten Speicher zugreifen kann, wobei das Programm wenigstens eine Chiffrierungsfunktion und wenigstens eine Dechiffrierungsfunktion verwendet.
  • Vor der Ausführung jeder Funktion verwirklicht das Ausführungsverfahren gemäß der Erfindung einen Verifizierungsschritt, wie er oben kurz beschrieben wurde.
  • Gemäß diesem Ausführungsverfahren wird vor der Ausführung jeder Funktion des Programms verifiziert, gemäß dem oben mit wenigen Worten beschriebenen Verifizierungsschritt, dass diese Funktion die Sicherheit sensibler Daten bewahrt.
  • Ein solches Ausführungsverfahren ist besonders zuverlässig, denn es verwehrt jede Manipulation des Binärskripts zwischen dem Verifizieren und dem Ausführen einer Funktion.
  • Es kann selbstverständlich für die Personalisierung von Mikroschaltungskarten verwendet werden.
  • Allgemeiner kann es für die Transformation oder die Erzeugung sensibler Daten eingesetzt werden, beispielsweise auf dem Gebiet der Telekommunikation für die Erzeugung von Schlüsseln in einem Telekommunikationsserver.
  • Gemäß einem weiteren Aspekt betrifft die Erfindung eine integrierte elektronische Schaltung, die ausgelegt ist, um ein Validierungsverfahren oder ein Ausführungsverfahren wie oben mit wenigen Worten beschrieben auszuführen.
  • Eine solche integrierte Schaltung kann beispielsweise mit Hilfe der dem Fachmann bekannten Sprache VHDL modelliert werden.
  • Sie kann auch in Form eines programmierbaren elektronischen Bauelements verwirklicht werden.
  • Die Erfindung zielt auch auf eine Mikroschaltungskarte und ein Datenverarbeitungssystem, das eine integrierte elektronische Schaltung wie oben mit wenigen Worten beschrieben enthält, ab.
  • Gemäß einem weiteren Aspekt zielt die Erfindung auf ein gesichertes Betriebssystems ab, das ein Validierungsverfahren wie oben kurz beschrieben ausführt.
  • Ein solches Betriebssystem kann sehr vorteilhaft in der Mikroschaltungskartenindustrie verwendet werden, denn es ermöglicht, die Sicherheitsfunktionen auf der niedrigsten Software-Ebene dieser Mikroschaltungskarten anzusiedeln, wodurch quasi jede Art von betrügerischen Operationen verwehrt wird.
  • Auf dem Gebiet der Mikroschaltungskarten ermöglicht ein solches Betriebssystem auch, die Ausführung der Anwendung, die anschließend geladen wird, einschließlich jener, die nach dem Inbetriebsetzen dieser Karten (engl. "post-insuance") geladen wird, zu sichern.
  • Die Erfindung zielt auch auf eine Mikroschaltungskarte und ein Datenverarbeitungssystem, das ein solches Betriebssystem enthält, ab.
  • Entsprechend zielt die Erfindung auf eine Vorrichtung zum Validieren eines Datenverarbeitungsprogramms ab, das auf einen gesicherten Speicher und auf einen nicht gesicherten Speicher zugreifen kann, wobei das Programm wenigstens eine Chiffrierungsfunktion und wenigstens eine Dechiffrierungsfunktion verwendet.
  • Die Validierungsvorrichtung enthält ein Verifizierungsprogramm, das ausgelegt ist, um zu verifizieren:
    • – dass jede Funktion, die ausgelegt ist, um die Daten aus dem gesicherten Speicher zu lesen und um in dem nicht gesicherten Speicher Daten zu erzeugen, eine Chiffrierungsfunktion ist; und
    • – dass alle Daten, die durch die Dechiffrierungsfunktion erzeugt werden, in dem gesicherten Speicher gespeichert werden.
  • Die Erfindung zielt auch auf ein gesichertes Betriebssystem ab, das Folgendes umfasst:
    • – Mittel zum Kompilieren eines Datenverarbeitungsprogramms in Binärskript;
    • – Mittel zum Laden des Binärskripts (EXE) in einen Arbeitsspeicher;
    • – Mittel zum Zuweisen eines gesicherten Speichers und eines nicht gesicherten Speichers;
    • – eine Validierungsvorrichtung wie oben kurz beschrieben.
  • Da die besonderen Vorteile und Eigenschaften, die für den Kompilierer, das Ausführungsverfahren, das gesicherte Betriebssystem, die Mikroschaltungskarte, die Validierungsvorrichtung und das Datenverarbeitungssystem charakteristisch sind, jenen gleich sind, die oben bezüglich des Validierungsverfahrens gemäß der Erfindung dargelegt wurden, werden sie hier nicht noch einmal in Erinnerung gebracht.
  • Weitere Aspekte und Vorteile der vorliegenden Erfindung werden deutlicher beim Lesen der folgenden Beschreibung besonderer Ausführungsformen, wobei diese Beschreibung nur beispielhaft und nicht einschränkend gegeben ist und sich auf die beigefügte Zeichnung bezieht, worin
  • 1 eine Syntaxtabelle gemäß der vorliegenden Erfindung darstellt;
  • 2 eine Verifizierungstabelle gemäß der vorliegenden Erfindung darstellt;
  • 3 ein Ablaufplan ist, der die wichtigsten Schritte eines Hauptprogramms gemäß der vorliegenden Erfindung darstellt;
  • 4 ein Ablaufplan ist, der die wichtigsten Schritte einer Verifizierungsprozedur gemäß der vorliegenden Erfindung darstellt; und
  • 5 ein Datenverarbeitungssystem darstellt, das eine Validierungsvorrichtung gemäß der vorliegenden Erfindung enthält.
  • Außerdem gehören zu der Beschreibung die folgenden Anhänge:
    • – Anhang A: Beispiel für ein Datenverarbeitungsprogramm, das durch ein Validierungsverfahren gemäß der vorliegenden Erfindung validiert und durch ein Ausführungsverfahren gemäß der vorliegenden Erfindung ausgeführt werden kann;
    • – Anhang B: Binärcode, der nach dem Kompilieren des Datenverarbeitungsprogramms des Anhangs A erhalten wurde.
  • Ein Beispiel für ein Datenverarbeitungsprogramm P im Quellcode, das durch ein automatisches Validierungsverfahren gemäß der vorliegenden Erfindung validiert und durch ein Ausführungsverfahren gemäß der vorliegenden Erfindung ausgeführt werden kann, ist im Anhang A gegeben.
  • Dieses Datenverarbeitungsprogramm P umfasst eine Folge von Operationen, wobei jede Operation eine Dechiffrierungsfunktion; eine Chiffrierungsfunktion oder eine nicht kryptographische Funktion anwendet.
  • Bei der Entwicklung eines solchen Datenverarbeitungsprogramms muss der Entwickler für jede Operation eine Syntax einhalten, die in einer Syntaxtabelle TS gespeichert ist, wofür in 1 ein Beispiel gegeben ist.
  • Genauer umfasst jede Operation:
    • – einen Bezeichner der Funktion;
    • – eine Argumentenliste; und
    • – ein Zeichen, das für das Ende der Operation repräsentativ ist, beispielsweise das Zeichen ";".
  • So ist die erste Operation, die in der Zeile a1 angegeben ist, eine Dechiffrierungsoperation unter Verwendung einer Dechiffrierungsfunktion DES-1, durch den Bezeichner DES-1 bezeichnet, wobei diese Funktion drei Argumente verwendet:
    • – INPUT: 8-Byte-Adressbereich, der die zu dechiffrierenden Daten enthält;
    • – KEY: Zeiger auf einen kryptographischen Schlüssel, wobei dieser Zeiger in Form einer Kette von L Zeichen gespeichert ist; und
    • – OUTPUT: 8-Byte-Adressbereich, in dem das Ergebnis der Dechiffrierungsfunktion gespeichert werden soll.
  • Vorteilhafterweise kennt der Programmierer in der oben beschriebenen Ausführungsform nicht den kryptographischen Schlüssel, sondern nur seinen Zeiger KEY in Zeichenkettenform. Diese Ausführungsform ermöglicht, jedem Betrug seitens des Programmierers vorzubeugen.
  • Genauso ist die zweite Operation, die in der Zeile a2 angegeben ist, eine Integritätskontrolloperation, die eine Integritätskontrollfunktion verwendet, CHECK-SUM_XOR, durch den Bezeichner CHECKSUM_XOR bezeichnet, wobei diese Funktion zwei Argumente verwendet:
    • – INPUT: 8-Byte-Adressbereich, der die Eingangsdaten der logischen Funktion enthält, die wirksam werden soll; und
    • – OUTPUT: 8-Byte-Adressbereich, in dem das Ergebnis der logischen Funktion gespeichert werden soll.
  • Schließlich ist die dritte Operation, die in der Zeile a3 angegeben ist, eine Chiffrierungsoperation unter Verwendung einer Chiffrierungsfunktion DES, durch den Bezeichner DES bezeichnet, wobei diese Funktion drei Argumente verwendet:
    • – INPUT: 8-Byte-Adressbereich, der die zu chiffrierenden Daten enthält;
    • – KEY: Zeiger auf einen kryptographischen Schlüssel, wobei dieser Zeiger in Form einer Kette von L Zeichen gespeichert ist; und
    • – OUTPUT: 8-Byte-Adressbereich, in dem das Ergebnis der Chiffrierungsfunktion gespeichert werden soll.
  • Jede Funktion ist außerdem einer Betriebsart zugeordnet, die wenigstens eine Speicherzugriffsregel definiert, wobei die Betriebsarten in einer Verifizierungstabelle wie in 2 gezeigt gespeichert sind.
  • 2 stellt eine Verifizierungstabelle gemäß der vorliegenden Erfindung dar.
  • Für jede Chiffrierungsfunktion, Dechiffrierungsfunktion und jede logische Funktion enthält die Verifizierungstabelle TV genau so viele Zeilen, wie es Betriebsarten für jede Funktion gibt, wobei jede Betriebsart Regeln für den Zugriff auf den gesicherten Speicher MS und den nicht gesicherten Speicher MNS definiert.
  • Beispielsweise umfasst die Chiffrierungsfunktion DES vier Betriebsarten, denn in der hier beschriebenen Ausführungsform ist es jeder Chiffrierungsfunktion gestattet, in dem gesicherten Speicher und dem nicht gesicherten Speicher zu lesen und zu schreiben, und zwar ohne besondere Einschränkung.
  • Hingegen ist aus den letzten zwei Zeilen der Verifizierungstabelle TV offensichtlich, dass die Dechiffrierungsfunktion DES-1 nur zwei Betriebsarten umfasst, wobei es jeder Dechiffrierungsfunktion gemäß der vorliegenden Erfindung nur gestattet ist, Daten in einem gesicherten Speicher MS zu erzeugen.
  • Im Folgenden wird mit Bezug auf 3 ein Hauptprogramm beschrieben, das ein Verfahren zum automatischen Validieren und ein Verfahren zum Ausführen eines Datenverarbeitungsprogramms P gemäß der vorliegenden Erfindung ausführt.
  • Das Validierungsverfahren umfasst einen vorhergehenden Schritt E300 des Kompilierens des Datenverarbeitungsprogramms P des Anhangs A, wobei dieser Kompilierungsschritt ein Binärskript EXE erzeugt.
  • Das Binärskript EXE, welches das Ergebnis dieses Kompilierungsschrittes ist, wird nun mit Bezug auf den Anhang B beschrieben.
  • Um die Beschreibung zu vereinfachen, sind die Bytes des Binärskripts EXE mittels Zeilen b1 bis b20 gruppiert.
  • Die ersten zwei Bytes des Skripts EXE (Zeile b1) entsprechen dem Umfang des Binärskripts, d. h. 6C in Hexadezimalschreibweise.
  • Das folgende Byte (Zeile b2) entspricht der Anzahl der Operationen des Datenverarbeitungsprogramms P, d. h. 3.
  • Die in den Zeilen b3 bis b8 gruppierten Bytes sind die durch das Kompilieren der ersten Operation (Zeile a1, Anhang A) erzeugten Bytes.
  • Genauso sind die in den Zeilen b9 bis b13 gruppierten Bytes die durch das Kompilieren der zweiten Operation (Zeile a2, Anhang A) erzeugten Bytes.
  • Schließlich sind die in den Zeilen b14 bis b19 gruppierten Bytes die durch das Kompilieren der dritten und letzten Operation (Zeile a3, Anhang A) erzeugten Bytes.
  • In jeder dieser Gruppen
    • – ist die erste Zeile (Zeilen b3, b16 und b14) aus einem Byte gebildet, das die Anzahl der Bytes, in Hexadezimalschreibweise, repräsentiert, die durch das Kompilieren der entsprechenden Operation, nämlich 24, 16 bzw. 24 für die Funktionen DES-1, CHECKSUM_XOR und DES erzeugt ist;
    • – ist die zweite Zeile (Zeilen b4, b10 und b15) aus einem Byte gebildet, das durch das Kompilieren des Bezeichners der entsprechenden Funktion, nämlich 22, 53 bzw. 21, für die Funktionen DES-1, CHECKSUM_XOR und DES gebildet ist;
    • – ist die dritte Zeile aus einem Byte gebildet (Zeilen b5, b11 und b16), das gleich der Anzahl der Argumente der entsprechenden Funktion ist, nämlich 3, 2 bzw. 3 bei den Funktionen DES-1, CHECKSUM_XOR und DES;
    • – ist die vierte Zeile (Zeilen b6, b12 und b17) aus den Bytes gebildet, die durch das Kompilieren des ersten Arguments der entsprechenden Funktion erzeugt sind;
    • – ist die fünfte Zeile (Zeilen b7, b13 und b18) aus den Bytes gebildet, die durch das Kompilieren des zweiten Arguments der entsprechenden Funktion erzeugt sind; und
    • – ist die sechste Zeile (Zeilen b8 und b19) gegebenenfalls aus den Bytes gebildet, die durch das Kompilieren des dritten Arguments der entsprechenden Funktion erzeugt sind.
  • In der hier beschriebenen Ausführungsform erzeugt das Kompilieren eines Arguments zuallererst ein erstes Byte, das für die Speicherzone repräsentativ ist, in der die Lese- oder Schreiboperation an diesem Argument ausgeführt werden soll.
  • In dem hier beschriebenen Beispiel werden vier Speicherzonen verwendet:
    • – eine nicht gesicherte Eingangszone, IN_BUF, repräsentiert durch das Byte 01 (Zeile b6);
    • – eine nicht gesicherte Ausgangszone, OUT_BUF, repräsentiert durch das Byte 02 (Zeile b19);
    • – eine gesicherte Rechenzone, PRIVATE, repräsentiert durch das Byte 04 (Zeile b8; b12 und b13); und
    • – eine gesicherte Speicherzone für Schlüssel, repräsentiert durch das Byte 05 (Zeilen b7 und b18).
  • Das Kompilieren eines Arguments erzeugt dann ein zweites Byte, das für den Umfang des Arguments repräsentativ ist. In dem hier gegebenen Beispiel beträgt dieser Umfang entweder 8 Bytes, wenn das Argument eine Adresse ist, oder aber 12 Bytes (0C in Hexadezimalschreibweise), wenn das Argument der aus 12 Zeichen gebildete Schlüssel KEY "CIPHER.TEST1" ist.
  • Das Kompilieren eines Arguments erzeugt schließlich eine Gruppe von Bytes, die für den Wert des betrachteten Arguments repräsentativ ist.
  • In der hier beschriebenen Ausführungsform wird ein Adressbereich in dem Programm P unter Verwendung der Schreibweise ZONE/VERSCHIEBUNG/LÄNGE repräsentiert, wobei
    • – ZONE den Typ der Speicherzone, die diesen Adressbereich enthält, repräsentiert, wobei dieser Typ aus der nicht gesicherten Eingangszone IN_BUF, der nicht gesicherten Ausgangszone OUT_BUF, der gesicherten Rechenzone PRIVATE und der gesicherten Schlüsselspeicherzone gewählt ist;
    • – VERSCHIEBUNG die Verschiebung (engl. "offset") des Beginns dieses Adressbereichs in Bezug auf den Beginn der Zone repräsentiert; und
    • – LÄNGE den Umfang des Adressbereichs repräsentiert.
  • Gemäß dieser Schreibweise bedeutet das zweite Argument (OUT-PUT = [PRIVATE/08/01]) der logischen Operation CHECKSUM_XOR (Zeile a2, Anhang A), dass das Ergebnis dieser logischen Operation in der gesicherten Rechenzone PRIVATE, in einem Bereich, der sich über ein Byte erstreckt, ab dem achten Byte dieser Zone gespeichert werden soll.
  • Bei der hier beschriebenen Ausführungsform endet das Binärskript mit einer Bytefolge (Zeile b20), die einer kryptographischen Signatur entspricht, die aus wenigstens einem Teil der dieses Skript bildenden Bytes erhalten wurde.
  • Auf den Schritt E300 des Kompilierens folgt ein Schritt E305, in dessen Verlauf das Hauptprogramm Folgendes empfängt:
    • – einerseits Eingangsdaten des Datenverarbeitungsprogramm P, wobei diese Eingangsdaten gesicherte Schlüssel umfassen können; und
    • – andererseits das während des Kompilierungsschrittes E300 erzeugte Binärskript EXE.
  • Bei der hier beschriebenen Ausführungsform werden die gesicherten Schlüssel in der gesicherten Schlüsselspeicherzone gespeichert.
  • Auf den Empfangsschritt E305 folgt ein Schritt E310, in dessen Verlauf das Hauptprogramm einen gesicherten Speicher MS und einen nicht gesicherten Speicher MNS dynamisch zuweist.
  • Dieser Zuweisungsschritt ist dem Fachmann bekannt und kann beispielsweise mit Hilfe der Systemfunktion malloc() verwirklicht werden.
  • Wie dem auch sei, dieser Zuweisungsschritt E310 ermöglicht, einen ersten Adresszeiger BUFF_MNS zu erhalten, wobei dieser Zeiger BUFF_MNS auf den nicht gesicherten Speicher zeigt, und einen zweiten Adresszeiger BUFF_MS, der auf den gesicherten Speicher zeigt.
  • Bei der hier beschriebenen Ausführungsform ist der auf diese Weise zugewiesene, nicht gesicherte Speicher MNS in zwei Zonen unterteilt:
    • – die nicht gesicherte Eingangszone IN_BUF; und
    • – die nicht gesicherte Ausgangszone OUT_BUF.
  • Der gesicherte Speicher MS ist ebenfalls in zwei Zonen unterteilt:
    • – die gesicherte Rechenzone PRIVATE; und
    • – die gesicherte Schlüsselspeicherzone.
  • Bei einer bevorzugten Ausführungsform wird im Verlauf desselben Schrittes E310 außerdem ein Arbeitsspeicher MT zugewiesen, der über den Zeiger BUFF_EXE aufgefunden wird, wobei dieser Arbeitsspeicher das während des Schrittes E305 empfangene Binärskript EXE enthält.
  • Auf den Speicherzuweisungsschritt E310 folgt ein Schritt E315 zum Verifizieren der Integrität des Binärskripts.
  • Dieser Schritt E315 kann beispielsweise ausgeführt werden, indem die kryptographische Signatur des Binärskripts EXE, wie zuvor mit Bezug auf die Zeile b20 des Anhangs B beschrieben, verifiziert wird.
  • Dieser wahlweise Schritt E315 des Verifizierens der Integrität des Skripts ermöglicht, die Sicherheit des Validierungsverfahrens zu verbessern.
  • Auf den wahlweisen Schritt E315 des Verifizierens der Integrität des Skripts folgt ein Schritt E320, in dessen Verlauf die Operationsanzahl N des Datenverarbeitungsprogramms P erhalten wird, wobei diese Anzahl N in einem Register gleichen Namens in dem Arbeitsspeicher MT gespeichert wird.
  • Bei der hier beschriebenen Ausführungsform ist die Operationsanzahl N das dritte Byte (Zeile b2) des Binärskripts EXE.
  • Wenn der wahlweise Schritt E315 zum Verifizieren der Integrität des Skripts nicht vorgesehen ist, folgt der Schritt E320 des Erhalts der Operationsanzahl auf den vorher beschriebenen Schritt E310 der Zuweisung der Speicher.
  • Auf den Schritt E320 des Erhalts der Operationsanzahl N folgt ein Test E325, in dessen Verlauf verifiziert wird, ob der Inhalt des Registers N des Arbeitsspeichers MT gleich 0 ist.
  • Wenn das nicht der Fall ist, ist das Ergebnis des Tests E325 negativ.
  • Auf diesen Test folgt dann ein Schritt E330, in dessen Verlauf aus dem Binärskript der Bezeichner der Funktion erhalten wird, die bei der ersten Operation des Datenverarbeitungsprogramms P verwendet wird.
  • In dem Beispiel des Anhangs B ist der auf diese Weise erhaltene Bezeichner 22 und damit repräsentativ für die Funktion DES-1 (Zeile b4).
  • Auf diesen Schritt E330 folgt ein Schritt E335, in dessen Verlauf aus dem Binärskript die Argumente dieser Funktion erhalten werden.
  • In der Praxis umfasst der Schritt E335 des Erhaltens der Argumente:
    • – einen ersten Teilschritt, in dessen Verlauf in der Syntaxtabelle TS von 1 die Liste und der Umfang jedes der Argumente der Funktion gesucht wird; und
    • – einen zweiten Teilschritt, in dessen Verlauf die entsprechende Anzahl Bytes in dem Binärskript gelesen wird.
  • Auf den Schritt E335 des Erhaltens der Argumente der Funktion folgt ein Schritt E340 des Aufrufs einer Prozedur zum Verifizieren der während der Schritte E330 und E335 bezeichneten Funktion.
  • Die Hauptschritte E400 bis E440 der Verifizierungsprozedur werden nun mit Bezug auf 4 beschrieben.
  • Im Verlauf des ersten Schrittes E400 der Verifizierungsprozedur werden aus der Verifizierungstabelle von 2 die Regeln für den Zugriff auf den gesicherten Speicher und den nicht gesicherten Speicher erhalten, wobei diese Regeln in der Betriebsart der im Schritt E330 bezeichneten Funktion definiert sind.
  • Auf den Schritt E400 des Erhalts der Regeln folgt ein Test E410, in dessen Verlauf verifiziert wird, ob diese Zugriffsregeln eingehalten werden.
  • In der Praxis wird dieser Verifizierungsschritt ausgeführt, indem verifiziert wird:
    • – dass alle Lese- und Schreiboperationen, die gemäß diesen Regeln in einem gesicherten Speicher ausgeführt werden sollen, in dem Adressbereich ausgeführt werden, auf den der Zeiger BUFF_MS zeigt; und
    • – dass alle Schreib- und Leseoperationen, die in dem nicht gesicherten Speicher ausgeführt werden sollen, in dem Adressbereich ausgeführt werden, auf den der Zeiger BUFF_MNS zeigt.
  • Beispielsweise erkennt man beim Durchgehen der Zeilen b14 bis b19 des Anhangs B, dass die Funktion DES (Zeile b15) Folgendes ausführt:
    • – eine Operation des Lesens des Bereichs, der aus den ersten 9 Bytes der gesicherten Rechenzone PRIVATE (Byte 04, Zeile b17) gebildet ist; und
    • – eine Operation des Schreibens in den Bereich, der aus den ersten 10 Bytes der nicht gesicherten Ausgangszone OUT_BUF (Byte 02, Zeile b19) gebildet ist, wobei diese Speicherzugriffe entsprechend der Verifizierungstabelle TV mit einer zweiten Betriebsart der Funktion DES übereinstimmend sind.
  • Wenn alle Speicherzugriffsregeln eingehalten worden sind, ist das Ergebnis des Tests E410 positiv.
  • Auf diesen Test folgt dann der Schritt E420, in dessen Verlauf die in Verarbeitung befindliche Operation ausgeführt wird.
  • Dagegen ist das Ergebnis des Tests E410 negativ, wenn wenigstens eine der Zugriffsregeln nicht eingehalten worden ist.
  • Auf diesen Test folgt dann ein Schritt E430, in dessen Verlauf der Speicher der nicht gesicherten Ausgangszone OUT_BUF gelöscht wird.
  • Auf den Schritt E430 des Löschens des Ausgangsspeichers folgt ein Schritt E440, um dem Programmierer des Datenverarbeitungsprogramms P einen Fehler zu melden.
  • Wie dem auch sei, die Schritte E420 und E440 beenden die Verifizierungsprozedur gemäß der Erfindung.
  • Auf diese Schritte folgt der Validierungstest E345, der nun wieder anhand 3 beschrieben wird.
  • Im Verlauf dieses Validierungstests E345 wird verifiziert, ob die vorher mit Bezug auf 4 beschriebene Verifizierungsprozedur mit einer Ausführung der Operation (Schritt E420) oder mit einem Fehlermeldungsschritt (Schritt E440) beendet worden ist.
  • Wenn die Verifizierungsprozedur normal beendet wird, d. h. durch den Schritt E420 der Operationsausführung, ist das Ergebnis des Tests E345 positiv.
  • Auf diesen Test folgt dann ein Schritt E350, in dessen Verlauf der Inhalt des Registers N um eine Einheit dekrementiert wird.
  • Auf den Schritt E350 folgt der schon beschriebene Test E325, in dessen Verlauf geprüft wird, ob das Register N den Wert 0 enthält.
  • Wenn das Ergebnis dieses Tests negativ ist, wird der schon beschriebene Schritt E330 ausgeführt, in dessen Verlauf aus dem Binärskript EXE der Bezeichner der Funktion gelesen wird, welche die zweite Operation des Datenverarbeitungsprogramms P darstellt.
  • Die Schritte E325 bis E350 bilden folglich eine Schleife, in deren Verlauf alle Operationen des Datenverarbeitungsprogramms P validiert und ausgeführt werden, wenn dieses Programm die Gesamtheit der Speicherzugangsregeln einhält.
  • Dagegen ist dann, wenn die Verifizierungsprozedur durch eine Fehlermeldung beendet wird, das Ergebnis des Tests E345 negativ.
  • Auf diesen Test folgt dann der nachstehend beschriebene Schritt E355.
  • Wenn alle Operationen des Datenverarbeitungsprogramms P durch die Schleife, bestehend aus den Schritten E325 bis E350, validiert worden sind, ist das Ergebnis des Tests E325 positiv.
  • In diesem Fall folgt auf den Test E325 ein Schritt E355, in dessen Verlauf der Inhalt der Ausgangszone OUT_BUF entweder an den Anwender des Hauptprogramms oder aber an ein anderes Datenverarbeitungsprogramm zur Verarbeitung der Ausgangsdaten übermittelt wird.
  • Auf den Schritt E355 folgt ein Schritt E360 der Freigabe und des Löschens der im Schritt E310 zugewiesenen Speicher.
  • Dieser Schritt E310 beendet das Hauptprogramm gemäß der vorliegenden Erfindung.
  • 5 stellt ein Datenverarbeitungssystem, das eine Validierungsvorrichtung gemäß der vorliegenden Erfindung enthält, schematisch dar.
  • Dieses Datenverarbeitungssystem umfasst zuallererst einen Kompilierer, der ermöglicht, ausgehend von einem Datenverarbeitungsprogramm P im Quellcode ein Binärskript EXE wie vorher definiert zu erzeugen.
  • Das Datenverarbeitungssystem umfasst außerdem ein gesichertes Betriebssystem (engl. Operating System). Dieses gesicherte Betriebssystem umfasst Mittel zum Zuweisen eines gesicherten Speichers MS und eines nicht gesicherten Speichers MNS.
  • Diese Zuweisungsmittel sind in der Praxis, in einer bevorzugten Ausführungsform, dem Fachmann bekannte Software-Funktionen, beispielsweise die Funktion malloc(). Diese Zuweisungsfunktion gibt auf bekannte Weise einen Adresszeiger zurück, der den Beginn der Adressbereiche des gesicherten Speichers MS und des nicht gesicherten Speichers MNS eingrenzt.
  • In dem Beispiel von 5 sind die Adresszeiger des gesicherten Speichers MS und des nicht gesicherten Speichers MNS BUFF_MS bzw. BUFF_MNS.
  • In einer bevorzugten Ausführungsform ist das Binärskript EXE in einem Arbeitsspeicher MT enthalten, der durch die vorerwähnten Zuweisungsmittel zugewiesen und mittels des Adresszeigers BUFF_EXE aufgefunden wird.
  • In der hier beschriebenen Ausführungsform wird praktisch das Binärskript EXE durch Lademittel des Datenverarbeitungssystems, beispielsweise einen PCI-Bus, in den Arbeitsspeicher geladen.
  • In einer weiteren Ausführungsform wird das Binärskript EXE in einem nichtflüchtigen Speicher gespeichert und zum Zeitpunkt seiner Validierung geladen.
  • Das Datenverarbeitungssystem umfasst daher eine Validierungsvorrichtung, die ein Verifizierungsprogramm enthält, das dafür ausgelegt ist, die Gültigkeit des Binärskripts EXE zu verifizieren.
  • Im Allgemeinen ist das Verifizierungsprogramm des Datenverarbeitungssystems dafür ausgelegt, das Validierungsverfahren und das Ausführungsverfahren, die vorher mit Bezug auf 3 und 4 beschrieben wurden, auszuführen.
  • Genauer ist das Verifizierungsprogramm dafür ausgelegt zu verifizieren, dass jede Funktion, die dafür ausgelegt ist, Daten aus dem gesicherten Speicher MS zu lesen und Daten in dem nicht gesicherten Speicher MNS zu erzeugen, eine Chiffrierungsfunktion ist.
  • Außerdem ist es dafür ausgelegt zu verifizieren, dass alle Daten, die durch eine Dechiffrierungsfunktion erzeugt werden, in dem gesicherten Speicher MS gespeichert werden.
  • Das Verifizierungsprogramm ist insbesondere dafür ausgelegt, nach dem Kompilieren den im Arbeitsspeicher MT gespeicherten Binärskript durchzugehen, um die Anweisungen zu ermitteln, die Bezeichnern und Argumenten von Chiffrierungs-, Dechiffrierungs- und logischen Funktionen entsprechen.
  • Dieser Ermittlungsschritt wird ausgeführt, indem die hexadezimalen Daten des Binärskripts EXE mit den Informationen verglichen werden, die in der vorher mit Bezug auf 1 beschriebenen Syntaxtabelle TS enthalten sind.
  • Das Verifizierungsprogramm des Datenverarbeitungssystems ist dafür ausgelegt, dann, wenn diese Funktionsbezeichner und -argumente erst einmal ermittelt sind, zu verifizieren, dass die Zugriffsregeln, die in der mit Bezug auf 2 beschriebenen Verifizierungstabelle TV gespeichert sind, eingehalten werden.
  • Dafür und für jede Lese- oder Schreiboperation in einem Speicher ermittelt es in dem Binärskript EXE die Speicheradresse, an der diese Operation ausgeführt werden soll.
  • Dann bestimmt es, ob diese Operation dafür vorgesehen ist, in dem gesicherten Speicher MS oder in dem nicht gesicherten Speicher MNS stattzufinden, und zwar indem es die für die Operation vorgesehene Adresse mit den Werten der Adresszeiger BUFF_MS und BUFF_MNS vergleicht.
  • Sobald der Typ dieser Speicher erkannt ist, verifiziert das Verifizierungsprogramm des Datenverarbeitungssystems, dass die Schreib- oder Leseoperation gemäß den Zugriffsregeln für den in Verarbeitung befindlichen Funktionstyp ist.
  • In einer weiteren Ausführungsform ist das Validierungsverfahren auf der Ebene des gesicherten Betriebssystems angesiedelt. Ein solches Betriebssystem kann vorteilhaft in einer Mikroschaltungskarte verwendet werden.
  • ANHÄNGE
  • Anhang A:
    • /*a1*/ DES-1(INPUT = [IN_BUF/00/08], KEY = "CIPHER.TEST1", OUTPUT = [PRIVATE/00/08]);
    • /*a2*/ CHECKSUM_XOR(INPUT = [PRIVATE/00/08], OUTPUT = [PRIVATE/08/01]);
    • /*a3*/ DES(INPUT = [PRIVATE/00/09], KEY = "CIPHER.TEST1", OUTPUT = [OUT_BUF/00/10]);
  • Anhang B:
    /*b1*/ 006C /* Umfang des Skripts*/
    /*b2*/ 03 /* Anzahl der Operationen*/
    /*b3*/ 24 /* Umfang von DES-1 */
    /*b4*/ 22 /* Bezeichner für DES-1 */
    /*b5*/ 03 /* Anzahl der Argumente */
    /*b6*/ 01 08 0000000000000008 /* INPUT */
    /*b7*/ 05 0C 4349504845522E5445535431 /* KEY */
    /*b8*/ 04 08 0000000000000008 /* OUTPUT */
    /*b9*/ 16 /* Umfang von CHECKSUM_XOR */
    /*b10*/ 53 /* Bezeichner für CHECKSUM_XOR */
    /*b11*/ 02 /* Anzahl der Argumente */
    /*b12*/ 04 08 0000000000000008 /* INPUT */
    /*b13* 04 08 0000000800000001 /* OUTPUT */
    /*b14*/ 24 /* Umfang von DES*/
    /*b15*/ 21 /* Bezeichner für DES */
    /*b16*/ 03 /* Anzahl der Argumente */
    /*b17*/ 04 08 0000000000000009 /* INPUT */
    /*b18*/ 05 0C 4349504845522E5445535431 /* KEY */
    /*b19*/ 02 08 0000000000000010 /* OUTPUT */
    /*b20*/ 1425283678895422 /* kryptographische Signatur*/

Claims (21)

  1. Verfahren zum automatischen Validieren eines Datenverarbeitungsprogramms, das auf einen gesicherten Speicher (MS) und auf einen nicht gesicherten Speicher (MNS) zugreifen kann, wobei das Programm wenigstens eine Chiffrierungsfunktion (DES) und wenigstens eine Dechiffrierungsfunktion (DES-1) verwendet, dadurch gekennzeichnet, dass es einen Verifizierungsschritt (E340) enthält, in dessen Verlauf verifiziert wird: – dass jede Funktion, die ausgelegt ist, um Daten aus dem gesicherten Speicher (MS) zu lesen und Daten in dem nicht gesicherten Speicher (MNS) zu erzeugen, eine Chiffrierungsfunktion ist; und – dass alle Daten, die durch die Dechiffrierungsfunktion erzeugt werden, in dem gesicherten Speicher (MS) gespeichert werden.
  2. Validierungsverfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Programm außerdem wenigstens eine nicht kryptographische Funktion verwendet, wobei die nicht kryptographische Funktion aus einer logischen Funktion, einer Funktion zum Erzeugen einer Zufallszahl oder einer Integritätskontrollfunktion ausgewählt ist.
  3. Validierungsverfahren nach Anspruch 2, dadurch gekennzeichnet, dass alle Daten, die durch die nicht kryptographische Funktion aus Daten erzeugt werden, die in dem gesicherten Speicher (MS) gelesen werden, in den gesicherten Speicher (MS) gespeichert werden.
  4. Validierungsverfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass dann, wenn das Datenverarbeitungsprogramm im Quellcode vorliegt, das Verfahren vor dem Verifizierungsschritt (E340) einen Schritt (E300) zum Kompilieren des Quellcodes in Binärskript (EXE) umfasst, wobei der Verifizierungsschritt (E340) an dem somit erzeugten Binärskript (EXE) ausgeführt wird.
  5. Validierungsverfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das Datenverarbeitungsprogramm ein Programm zum Erzeugen sensibler Daten ist.
  6. Validierungsverfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Datenverarbeitungsprogramm ein Programm zum Transformieren sensibler Daten ist.
  7. Validierungsverfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass jede Funktion, die von dem Datenverarbeitungsprogramm verwendet wird, wenigstens einer Betriebsart zugeordnet ist, die wenigstens eine Regel für den Zugriff auf die Speicher definiert, wobei die Betriebsart in einer Verifizierungstabelle (TV) gespeichert ist, die während des Verifizierungsschrittes (E340) verwendet wird.
  8. Validierungsverfahren nach Anspruch 7, dadurch gekennzeichnet, dass es außerdem umfasst: – einen Schritt (E310) zum Zuweisen des gesicherten Speichers (MS) und des nicht gesicherten Speichers (MNS); – einen Schritt des Ladens eines Programms zum Verifizieren des Binärskripts (EXE) in einen Arbeitsspeicher, wobei das Verifizierungsprogramm ausgelegt ist, um den Verifizierungsschritt (E340) auszuführen; und – einen Schritt (E305) zum Laden des Binärskripts (EXE) in den Arbeitsspeicher.
  9. Kompilierer, dadurch gekennzeichnet, dass er ausgelegt ist, um ein Validierungsverfahren nach einem der Ansprüche 1 bis 7 auszuführen.
  10. Verfahren zum Ausführen eines Datenverarbeitungsprogramms, das auf einen gesicherten Speicher (MS) und auf einen nicht gesicherten Speicher (MNS) zugreifen kann, wobei das Programm wenigstens eine Chiffrierungsfunktion (DES) und wenigstens eine Dechiffrierungsfunktion (DES-1) verwendet, dadurch gekennzeichnet, dass vor der Ausführung (E420) jeder Funktion des Programms ein Verifizierungsschritt (E340) nach einem der Ansprüche 1 bis 8 ausgeführt wird.
  11. Verwendung des Ausführungsverfahrens nach Anspruch 10 für die Transformation oder die Erzeugung sensibler Daten.
  12. Verwendung des Ausführungsprogramms nach Anspruch 10 für die Personalisierung von Mikroschaltungskarten.
  13. Integrierte elektronische Schaltung, dadurch gekennzeichnet, dass sie aus gelegt ist, um ein Validierungsverfahren nach einem der Ansprüche 1 bis 8 oder ein Ausführungsverfahren nach Anspruch 10 auszuführen.
  14. Mikroschaltungskarte, dadurch gekennzeichnet, dass sie eine integrierte elektronische Schaltung nach Anspruch 13 enthält.
  15. Datenverarbeitungssystem, dadurch gekennzeichnet, dass es eine integrierte elektronische Schaltung nach Anspruch 13 enthält.
  16. Gesichertes Betriebssystem, das ausgelegt ist, um ein Validierungsverfahren nach einem der Ansprüche 1 bis 8 auszuführen.
  17. Mikroschaltungskarte, dadurch gekennzeichnet, dass sie ein Betriebssystem nach Anspruch 16 enthält.
  18. Datenverarbeitungssystem, dadurch gekennzeichnet, dass es ein Betriebssystem nach Anspruch 16 enthält.
  19. Vorrichtung zum Validieren eines Datenverarbeitungsprogramms, das auf einen gesicherten Speicher (MS) und auf einen nicht gesicherten Speicher (MNS) zugreifen kann, wobei das Programm wenigstens eine Chiffrierungsfunktion (DES) und wenigstens eine Dechiffrierungsfunktion (DES-1) verwendet, dadurch gekennzeichnet, dass es ein Verifizierungsprogramm enthält, das ausgelegt ist, um zu verifizieren: – dass jede Funktion, die ausgelegt ist, um die Daten aus dem gesicherten Speicher (MS) zu lesen und um in dem nicht gesicherten Speicher (MNS) Daten zu erzeugen, eine Chiffrierungsfunktion ist; und – dass alle Daten, die durch die Dechiffrierungsfunktion erzeugt werden, in dem gesicherten Speicher (MS) gespeichert werden.
  20. Validierungsvorrichtung nach Anspruch 19, dadurch gekennzeichnet, dass das Verifizierungsprogramm ausgelegt ist, um die Verifizierungen ausgehend von einem Binärskript (EXE) auszuführen, das durch Kompilierung des Datenverarbeitungsprogramms erhalten wird.
  21. Datenverarbeitungssystem, das ein gesichertes Betriebssystem enthält, dadurch gekennzeichnet, dass es umfasst: – Mittel zum Kompilieren eines Datenverarbeitungsprogramms in Binärskript (EXE); – Mittel zum Laden des Binärskripts (EXE) in einen Arbeitsspeicher; – Mittel zum Zuweisen eines gesicherten Speichers (MS) und eines nicht gesicherten Speichers (MNS); – eine Validierungsvorrichtung nach Anspruch 19.
DE60318407T 2002-03-26 2003-03-18 Verfahren und vorrichtung zur automatischen bewertung eines computerprogramms mit kryptografiefunktionen Expired - Lifetime DE60318407T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0203743A FR2837944B1 (fr) 2002-03-26 2002-03-26 Procede et dispositif de validation automatique d'un programme informatique utilisant des fonctions de cryptographie
FR0203743 2002-03-26
PCT/FR2003/000858 WO2003081546A1 (fr) 2002-03-26 2003-03-18 Procede et dispositif de validation automatique d'un programme informatique utilisant des fonctions de cryptographie

Publications (2)

Publication Number Publication Date
DE60318407D1 DE60318407D1 (de) 2008-02-14
DE60318407T2 true DE60318407T2 (de) 2008-12-24

Family

ID=27839187

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60318407T Expired - Lifetime DE60318407T2 (de) 2002-03-26 2003-03-18 Verfahren und vorrichtung zur automatischen bewertung eines computerprogramms mit kryptografiefunktionen

Country Status (9)

Country Link
US (1) US7627768B2 (de)
EP (1) EP1488386B1 (de)
CN (1) CN100338588C (de)
AT (1) ATE382921T1 (de)
AU (1) AU2003227844A1 (de)
DE (1) DE60318407T2 (de)
ES (1) ES2298516T3 (de)
FR (1) FR2837944B1 (de)
WO (1) WO2003081546A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5081668B2 (ja) * 2008-02-28 2012-11-28 株式会社リコー 画像処理装置、情報処理方法及び情報処理プログラム
US10666443B2 (en) * 2016-10-18 2020-05-26 Red Hat, Inc. Continued verification and monitoring of application code in containerized execution environment
US10872161B2 (en) * 2016-11-23 2020-12-22 Entrust Corporation Printer identity and security

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5134700A (en) * 1987-09-18 1992-07-28 General Instrument Corporation Microcomputer with internal ram security during external program mode
US5224166A (en) * 1992-08-11 1993-06-29 International Business Machines Corporation System for seamless processing of encrypted and non-encrypted data and instructions
US7124302B2 (en) * 1995-02-13 2006-10-17 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US8548166B2 (en) * 1995-04-03 2013-10-01 Anthony J. Wasilewski Method for partially encrypting program data
US5892826A (en) * 1996-01-30 1999-04-06 Motorola, Inc. Data processor with flexible data encryption
US6438666B2 (en) * 1997-09-26 2002-08-20 Hughes Electronics Corporation Method and apparatus for controlling access to confidential data by analyzing property inherent in data
US6385727B1 (en) * 1998-09-25 2002-05-07 Hughes Electronics Corporation Apparatus for providing a secure processing environment
FR2796175B1 (fr) * 1999-07-09 2001-08-31 Sagem Procede de preservation de l'integrite de donnees logiciel de mise en oeuvre de donnees sensibles confidentielles et carte support de ces donnees
US7330970B1 (en) * 1999-07-13 2008-02-12 Microsoft Corporation Methods and systems for protecting information in paging operating systems
US7124170B1 (en) * 1999-08-20 2006-10-17 Intertrust Technologies Corp. Secure processing unit systems and methods
US20070288765A1 (en) * 1999-12-22 2007-12-13 Kean Thomas A Method and Apparatus for Secure Configuration of a Field Programmable Gate Array
ATE249664T1 (de) * 2000-01-18 2003-09-15 Infineon Technologies Ag Mikroprozessoranordnung mit verschlüsselung
US6901385B2 (en) * 2000-02-17 2005-05-31 Matsushita Electric Industrial Co., Ltd. Semiconductor memory card that records contents for trial and purchase, recording apparatus, reproducing apparatus, and sales method
US7082615B1 (en) * 2000-03-31 2006-07-25 Intel Corporation Protecting software environment in isolated execution
FI115257B (fi) * 2001-08-07 2005-03-31 Nokia Corp Menetelmä informaation käsittelemiseksi elektroniikkalaitteessa, järjestelmä, elektroniikkalaite ja suoritinlohko
DE10200288A1 (de) * 2002-01-07 2003-07-17 Scm Microsystems Gmbh Eine Vorrichtung zur Ausführung von Anwendungen, die sichere Transaktionen und/oder Zugangskontrolle zu werthaltigen Inhalten und/oder Dienstleistungen umfassen, und Verfahren zum Schutz einer solchen Vorrichtung
JP4447977B2 (ja) * 2004-06-30 2010-04-07 富士通マイクロエレクトロニクス株式会社 セキュアプロセッサ、およびセキュアプロセッサ用プログラム。
EP1785878B2 (de) * 2004-08-20 2016-08-10 Mitsubishi Electric Corporation Speicherkarte, datenaustauschsystem und datenaustauschverfahren
US7657756B2 (en) * 2004-10-08 2010-02-02 International Business Machines Corporaiton Secure memory caching structures for data, integrity and version values
US20070006294A1 (en) * 2005-06-30 2007-01-04 Hunter G K Secure flow control for a data flow in a computer and data flow in a computer network
US7934049B2 (en) * 2005-09-14 2011-04-26 Sandisk Corporation Methods used in a secure yet flexible system architecture for secure devices with flash mass storage memory
US7886162B2 (en) * 2007-05-29 2011-02-08 International Business Machines Corporation Cryptographic secure program overlays
US8332635B2 (en) * 2007-05-29 2012-12-11 International Business Machines Corporation Updateable secure kernel extensions
US8433927B2 (en) * 2007-05-29 2013-04-30 International Business Machines Corporation Cryptographically-enabled privileged mode execution
US8422674B2 (en) * 2007-05-29 2013-04-16 International Business Machines Corporation Application-specific secret generation

Also Published As

Publication number Publication date
WO2003081546A1 (fr) 2003-10-02
FR2837944B1 (fr) 2004-07-09
FR2837944A1 (fr) 2003-10-03
CN1643550A (zh) 2005-07-20
US20050207572A1 (en) 2005-09-22
US7627768B2 (en) 2009-12-01
EP1488386B1 (de) 2008-01-02
ES2298516T3 (es) 2008-05-16
DE60318407D1 (de) 2008-02-14
ATE382921T1 (de) 2008-01-15
AU2003227844A1 (en) 2003-10-08
CN100338588C (zh) 2007-09-19
EP1488386A1 (de) 2004-12-22

Similar Documents

Publication Publication Date Title
DE3689569T2 (de) Verfahren zur Systemdateiensicherung und Datenverarbeitungseinheit zu dessen Durchführung.
DE112005001666B4 (de) Verfahren zum Bereitstellen von privaten Direktbeweis-Schlüsseln in signierten Gruppen für Vorrichtungen mit Hilfe einer Verteilungs-CD
DE69714752C5 (de) Verwendung einer hohen programmiersprache in einem mikrokontroller
DE102015209116A1 (de) Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
EP3891642B1 (de) Verfahren zur sicherung der vertrauenswürdigkeit von quellcodes
WO2023011756A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
DE60103515T2 (de) Kryptografisches verfahren zum schutz gegen betrug
DE60318407T2 (de) Verfahren und vorrichtung zur automatischen bewertung eines computerprogramms mit kryptografiefunktionen
DE102018112742A1 (de) Computerimplementiertes Verfahren zum Übergeben eines Datenstrings von einer Anwendung an eine Datenschutzeinrichtung
EP1614012A1 (de) Verfahren zur überprüfung der datenintegrität von software in steuergeräten
EP3234843A1 (de) Verfahren zum bereitstellen einer sicherheitskritischen softwareapplikation auf einer computereinheit
EP0117907A2 (de) Verfahren zur Überprüfung elektronischer Daten sowie Modul für das Verfahren
DE10218835B4 (de) Verfahren zum Herstellen einer Chipkarte und Chipkarte
DE602004007368T2 (de) Verfahren zum verwalten eines in einem umprogrammierbaren onboard-system heruntergeladenen ausführbaren codes
EP1722336A2 (de) Vorrichtung und Verfahren zur Erzeugung von Daten für eine Initialisierung von Sicherheitsdatenträgern
EP3745287B1 (de) Schützen einer softwareapplikation
EP3798873B1 (de) Verfahren zum schützen einer computer-implementierten anwendung vor manipulation
DE69900566T2 (de) Verfahren zur Personalisierung einer IC-Karte
DE102020206039A1 (de) Erstellen einer Container-Instanz
DE10127194A1 (de) Verfahren und Vorrichtung zum Ausblenden von nicht funktionstüchtigen Speicherzellen
DE60216106T2 (de) Geschützte lesung von rechnerbefehlen in einem datenverarbeitungssystem
DE102018006313A1 (de) Verfahren mit Safe-Error-Abwehrmaßnahme
DE10324507A1 (de) Verfahren zum Laden von Daten in eine Speichereinrichtung
DE102018009143A1 (de) Verfahren zur Authentifizierung eines Geräts durch ein Hostsystem
DE102018129354A1 (de) Verfahren zum Bearbeiten von Anwendungsprogrammen auf einem verteilten Automatisierungssystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: MEISSNER, BOLTE & PARTNER GBR, 80538 MUENCHEN