DE202006020631U1 - Computertechnisches Gerät - Google Patents

Computertechnisches Gerät Download PDF

Info

Publication number
DE202006020631U1
DE202006020631U1 DE202006020631U DE202006020631U DE202006020631U1 DE 202006020631 U1 DE202006020631 U1 DE 202006020631U1 DE 202006020631 U DE202006020631 U DE 202006020631U DE 202006020631 U DE202006020631 U DE 202006020631U DE 202006020631 U1 DE202006020631 U1 DE 202006020631U1
Authority
DE
Germany
Prior art keywords
memory
program
processor
data
verification
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
DE202006020631U
Other languages
English (en)
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.)
Ingenico Group SA
Original Assignee
Compagnie Industrielle et Financiere dIngenierie Ingenico SA
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 Compagnie Industrielle et Financiere dIngenierie Ingenico SA filed Critical Compagnie Industrielle et Financiere dIngenierie Ingenico SA
Publication of DE202006020631U1 publication Critical patent/DE202006020631U1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Computertechnisches Gerät, mit
einem Prozessor (4) zum Ausführen von Programmen, einem Speicher (6), den der Prozessor lesen und beschreiben kann, und einer Ein-/Ausgabevorrichtung (8), die eine Kommunikation zwischen dem Prozessor (4) des Geräts und der Außenwelt ermöglicht,
wobei das Gerät (2) dazu ausgestaltet ist, eine Anforderung des Ladens eines Verifizierungsprogramms (P) in den Speicher (6) und des Ausführens dieses Programms durch den Prozessor zu empfangen, wobei das Verifizierungsprogramm Daten in den Speicher (6) des Geräts schreiben und Daten aus dem Speicher (6) lesen kann, um sie zur Ein-/Ausgabevorrichtung (8) zu senden;
wobei das Gerät dazu ausgestaltet ist, eine Anforderung des Ausführens des Programms (P), um den verfügbaren, nicht mit dem Programm (P) belegten Speicher (6) zu sättigen, zu empfangen,
wobei Nachrichten mit dem Gerät ausgetauscht werden, das das Programm (P) ausführt, und
wobei die Übereinstimmung des logischen Inhalts des Geräts in Abhängigkeit von den mit...

Description

  • Die vorliegende Erfindung betrifft computertechnische Geräte und insbesondere die Verifizierung der Übereinstimmung des logischen Inhalts eines computertechnischen Geräts mit einem Referenzinhalt.
  • Ein Informationsverarbeitungsgerät, das einen Prozessor, der mit einem Speicher verbunden ist, sowie Ein-/Ausgabevorrichtungen umfasst, wird ein computertechnisches Gerät genannt. Der Prozessor, der Speicher sowie die Ein-/Ausgabevorrichtungen können mittels verschiedener Hardwarelösungen implementiert werden. So kann der Speicher beispielsweise einen EEPROM-, EPPROM- oder Flash-Speicher umfassen. Das Gerät kann ein Programm oder eine Software in den Prozessor laden, das bzw. die im Speicher enthalten ist, und das Programm oder die Software ausführen. Das Gerät kann über den Umweg von Ein-/Ausgabevorrichtungen mit der Außenwelt kommunizieren, um von der Außenwelt stammende Informationen zu empfangen oder Informationen an die Außenwelt zu übertragen. Diese Definition computertechnischen Geräten beinhaltet Chipkarten, Cash-Systeme, Minicomputer (PDA), Pay-TV-Geräte und Computer. Diese Geräte unterscheiden sich in Bezug auf den Prozessortyp, den Speichertyp, den Typ der Ein-/Ausgabevorrichtungen sowie ihren Zweck.
  • Bei einem solchen Gerät wird der Inhalt des Speichers logischer Inhalt oder logischer Zustand genannt – dabei handelt es sich um ausführbaren Code, Parameter oder auch passive Daten.
  • Ein Problem, das bei den computertechnischen Geräten angetroffen wird, besteht in der Übereinstimmung des logischen Inhalts des Geräts mit einem Referenzinhalt. Dieses Problem stellt sich, wenn ein Gerät aufgestellt wird, dessen Hardwarespezifikationen bekannt sind, insbesondere der Umfang des Speichers und der Prozessortyp. Das Problem besteht darin zu wissen, ob das angeordnete Gerät sich in einem Referenzzustand befindet. Der Referenzzustand kann einem gegebenen logischen Inhalt – eine bestimmte Information, die in dem Speicher dargestellt ist – oder auch einem Fehlen von Informationen in dem Speicher entsprechen.
  • Dieses Problem stellt sich insbesondere bei Chipkarten und Cash-Systemen; tatsächlich erfolgt das Beschreiben der Speicher dieser Informationsgeräte unter Vertraulichkeit.
  • Die Personalisierung von Chipkarten (für Telefonieanwendungen mit dem GSM-Standard, Bezahlungs- oder Identitätsanwendungen) und Cash-Systemen umfasst eine Phase des Einfügens von ausführbaren Codes in diese Geräte. In der Regel ermöglichen Chipkarten mit offenen Betriebssystemen (wie die im Vertrieb erhältlichen Systeme, die dem „Javacard"-Standard entsprechen) das Hinzufügen von Programmen oder ausführbaren Erweiterungen in den nichtflüchtigen Speicher der Karte (in der Regel EEPROM, EPROM oder Flash).
  • Ebenso umfasst die Initialisierung von Cash-Systemen, wie die von dem Unternehmen INGENICO unter der Bezeichnung 5100 vertriebenen Systeme, eine Phase, in der der nichtflüchtige Speicher des Systems (in der Regel EEPROM, EPROM, Flash oder RAM mit Batteriesicherung) mit einer Anwendung geladen wird, die für den Bankier (Erwerber) spezifisch ist, für den das System bestimmt ist. Der Ausdruck „Anwendung" bezeichnet den ausführbaren Code, passive Parameter und Schlüssel.
  • Das Einfügen des ausführbaren Codes, von passiven Parametern und von Schlüsseln in den Speicher erfolgt in einer Personalisierungsstation, die das Gerät aufnimmt. Wenn das Gerät mit der Personalisierungsstation verbunden wird, wird angenommen, dass es sich in einem Referenzzustand befindet, das heißt in einem gegebenen logischen Zustand.
  • Wenn die Vertraulichkeit von Informationen bewahrt werden soll, die von der Personalisierungsstation in das Gerät eingefügt wurden, ist es unabdingbar, sicherzustellen, dass das zu personalisierende Gerät frei jeglicher bösartiger Anwendungen ist. Eine bösartige Anwendung ist für die Zwecke der vorliegenden Patentanmeldung als jeglicher ausführbarer Code und/oder jegliche unterschiedliche passive Daten im Referenzzustand, in dem sich das Gerät mutmaßlich befindet, definiert.
  • Wir geben hier einige Beispiele von bösartigen Anwendungen in verschiedenen Bereichen an:
    • – Ein leeres Cash-System wird von einem Angestellten mit bösartigen Absichten manipuliert, der eine Anwendung darauf lädt, die das Verhalten eines leeren Systems simuliert. Diese Anwendung hinterlässt eine Kopie der geheimen Schlüssel in einem lesbaren Bereich des nichtflüchtigen Speichers. Sobald die Schlüssel eingefügt wurden, ergreift der Angestellte mit bösartigen Absichten dank der in einem lesbaren Bereich des Speichers vorgenommenen Kopie von den eingefügten Schlüsseln Besitz. Anschließend löscht der Angestellte mit bösartigen Absichten die Anwendung, die das Verhalten eines leeren Systems simuliert, und programmiert die gestohlenen Schlüssel auf ordnungsgemäße Weise in einem leeren System um, das er in die Handelskette eingliedert; die Kontrolle einer Anzahl von Systemen ermöglicht nicht, die Manipulation zu entdecken. Somit erhält der Erwerber ein System, in dem er die geschützten Schlüssel glaubt, während diese Schlüssel dem Angestellten mit bösartigen Absichten bekannt sind;
    • – eine Ausweiskarte wird in einem Land A für ein Konto in einem Land B hergestellt. Das Land B stellt die Personalisierung dieser Karten mittels Einfügung von geheimen Schlüsseln in einem von außen nicht lesbaren Bereich des Speichers der Karten sicher. Die an B gelieferte Karte kann einen bösartigen Code umfassen, der von den Behörden des Lands A vor der Lieferung leerer Karten an Land B eingefügt wurde. Dieser Code kann gegenüber der Personalisierungsstation ein perfektes Softwareverhalten einer leeren Karte simulieren, jedoch in einer verborgenen Datei, die in dem lesbaren Speicher gespeichert ist, Kopien von geheimen Schlüsseln, die von B in das Ausweisdokument eingefügt wurden, schützen. Somit kann das Land A bei einer Kontrolle des Ausweisdokuments durch das Land A, bei der der bösartige Code aktiviert werden kann, auf diese Weise die Schlüssel erlangen, die vom Land B auf die Karte geladen wurden, und das Ausweisdokument vervielfältigen; der Vorgang der Aktivierung des bösartigen Codes kann sehr charakteristisch sein, beispielsweise im Schreiben einer Datei mit einer spezifischen Angabe resultieren, die das „Aufwecken" des bösartigen Codes bewirkt;
    • – eine Bankkarte, auf die ein Javacard-Applet geschrieben werden soll, das Schlüssel umfasst, kann bereits einen bösartigen Code enthalten, der von einem betrü gerischen Bediener vor der Personalisierung der Karte hochgeladen wurde. Somit kann der Bediener die Karte zum Ende der Personalisierung zurückerlangen, seine Schlüssel erneut lesen, den bösartigen Code löschen, den rechtmäßigen Code auf die Karte (sowie die Schlüssel, über die er Kenntnis haben wollte) hochladen und die Karte in den industriellen Prozess eingliedern, damit sie nicht bei der letzten Registrierung fehlt;
    • – ebenso kann es, nachdem eine Festplatte formatiert und diese in einem Betriebssystem der Marke Windows XP installiert wurde, von Nutzen sein, sicherzustellen, dass die Festplatte sehr wohl das Bild des Inhalts der offiziellen Windows-XP-CD enthält, die von dem Unternehmen Microsoft im Handel vertrieben wird.
  • Das gleiche Szenario kann bei der Initialisierung jedes Geräts, das gegebenenfalls Geheimnisse umfasst (Personalcomputer, Minicomputer oder PDA, Mobiltelefon, Spielekonsolen, Cash-Systeme, Pay-TV-Decoder usw.), oder beim Einfügen von Informationen – Programmen, Schlüsseln, Daten jeglicher Art – in ein solches Gerät auftreten.
  • Es versteht sich, dass es bei all diesen Beispielen von Nutzen ist, wenn man verifizieren kann, dass der Zustand des Geräts mit einem Referenzzustand übereinstimmt. Diese Verifizierung kann eine Verifizierung vor dem Einfügen von Informationen in das Gerät sein; in den Beispielen der Personalisierung einer Chipkarte oder eines Cash-Systems hat die Verifizierung zum Ziel, vor der Personalisierung die Übereinstimmung des Geräts mit einem Referenzzustand, insbesondere das Fehlen einer bösartigen Anwendung festzustellen. Diese Verifizierung kann eine Verifizierung nach dem Einfügen von Informationen in das Gerät sein: Die Verifizierung hat dann zum Ziel, festzustellen, dass das Gerät Träger eines Inhalts (ausführbarer Code, Parameter, passive Daten) ist, die strengstens mit einem gegebenen Modell übereinstimmen.
  • Der Stand der Technik schlägt drei Arten von Lösungen vor, die ermöglichen, zu gewährleisten, dass ein computertechnisches Gerät Träger eines logischen Inhalts ist, der mit einem gegebenen Modell übereinstimmt. Diese Lösungen können Software-, Hardware- oder invasive Lösungen sein.
  • Die Softwarelösungen setzen voraus, dass das Gerät derart entworfen wurde, dass eine an dem Gerät vorgenommene bestimmte physische Aktion in einem garantierten Verhalten des Geräts resultiert. Im Beispiel eines Personalcomputers (PC) besteht die physische Aktion darin, die Tasten Strg-Alt-Entf zu drücken, wobei vorher eine Diskette in das Lesegerät eingelegt und der Rechner hochgefahren wird, was im Start des Betriebssystems resultiert. Wenn das BIOS (Abkürzung für den englischen Ausdruck „Basic Input/Output System", d. h. allgemeines Ein-/Ausgabesystem) eines PC beim Hochfahren das Vorliegen einer Diskette im Diskettenlesegerät erkennt, übergibt es die Kontrolle an das auf der Diskette vorliegende Programm und zwingt dieses Programm, sich selbst auszuführen. Somit ist es möglich, ein Gerät neu zu formatieren, das ausgefallen ist oder einen bösartigen Code (wie einen „Virus" oder ein „Rootkit") enthält; diese Neuformatierung setzt das Gerät in einen gegebenen Referenzzustand zurück – einen Initialisierungszustand, in dem das Gerät frei von logischem Inhalt ist.
  • Eine solche Hardwarelösung setzt voraus, dass das Gerät mittels einer solchen physischen Aktion einen privilegierten Eingriff gestattet.
  • Im Fall des Verifizierens, dass das Gerät einen gegebenen logischen Inhalt aufweist, setzt eine solche Lösung voraus, dass der Prüfer das Gerät wieder mit dem gewünschten logischen Inhalt beschreiben kann. Das ist nicht immer der Fall. So gibt es heutzutage Geräte, deren Speicher nicht aus einem ROM (Totspeicher), sondern einem nichtflüchtigen, wiederbeschreibbaren Speicher (wie einem Flash- oder EEPROM-Speicher) besteht. Zum Beispiel bieten zahlreiche Komponentenhersteller leere Flash-Chips an, auf die der Kartenhersteller ein Betriebssystem seiner Wahl hochladen kann; Beispiele solcher Chips sind die von dem Unternehmen SST unter der Bezeichnung Emosyn, von dem Unternehmen Atmel unter der Bezeichnung AT90SC3232, von dem Unternehmen Infineon unter der Bezeichnung SLE88CFX4000P oder auch von dem Unternehmen Electronic Marin unter der Bezeichnung EMTCG vertriebenen Chips. Bei diesen derartigen Geräten hat der Benutzer die Möglichkeit, ein neues Betriebssystem auf den Chip der Karte zu laden, und kann das Gerät zwingen, nur mit einem externen Datenträger zu starten, so dass diese Chips folglich dem Benutzer nicht gestatten zu wissen, ob das sich auf dem Chip der Karte befindende Betriebssystem mit einem gegebenen Protokoll übereinstimmt oder nicht.
  • Die invasiven Lösungen setzen voraus, dass das zu verifizierende Gerät auseinandergebaut wurde und dass das Bauteil, das den Code oder die Daten enthält – das physische Bauteil, das die Speicherfunktion gewährleistet –, mithilfe eines externen Testgeräts untersucht wird. Das externe Testgerät ermöglicht, den Inhalt des Speichers des zu verifizierenden Geräts zu lesen, unabhängig von dem Prozessor des zu verifizierenden Geräts, und folglich unabhängig davon die Ausführung jeder bösartigen Anwendung, die eine erwartete Funktion simuliert. Sobald Gewissheit über die Übereinstimmung des in dem ausgebauten Bauteil enthaltenen Codes mit dem Modell erlangt wurde, wird das Bauteil wieder in den Rechner eingebaut. Als Beispiel ermöglicht die Software, die von dem Unternehmen Guidance Software unter der Bezeichnung EnCase im Handel erhältlich ist, den Inhalt einer Festplatte außerhalb eines Rechners nachzuprüfen.
  • Eine solche invasive Lösung liegt für den durchschnittlichen Benutzer oftmals nicht im Rahmen seiner Möglichkeiten oder sie ist einfach technisch unmöglich; daher wird eine Chipkarte oder ein Cash-System aus Gründen der Sicherheit derart entworfen, dass es unmöglich ist, das kleinste Bauteil herauszunehmen, ohne die Selbstzerstörung des Geräts zu verursachen.
  • Die Softwarelösungen bestehen in der Kommunikation mit dem zu verifizierenden Gerät. Derzeit werden mehrere Ansätze angewendet, keine gibt jedoch absolute Gewissheit in Bezug auf das verifizierte Gerät. In allen Softwareansätzen wird vorausgesetzt, dass der Angreifer das Recht hat, den Softwarezustand (logischen Zustand) des Zielrechners zu ändern, jedoch auf keinen Fall nur das Recht hat, die physische Struktur zu ändern (beispielsweise Ergänzen des Speichers, Abschalten eines Peripheriegeräts, Austauschen der Festplatte usw.).
  • Eine erste Softwarelösung besteht darin, von dem untersuchten Gerät anzufordern, den gesamten oder einen Teil seines Speichers mit einem Hash-Code zu codieren. Ein solcher Ansatz ist unzureichend, da man sich perfekt vorstellen kann, dass der bösartige Code in dem Betriebssystem komprimiert ist (jeglicher ausführbarer Code ist höchst redundant und eignet sich folglich zur Komprimierung), den es nach und nach dekomprimiert und Hash-codiert, um auf Hash-Codierungsanforderungen des Prüfers zu antworten. Eine solche Lösung wird beispielsweise in dem Artikel „Oblivious Hashing: A Stealthy Software Integrity Verification Primitive" von Yuqun Chen, Ramarathnahm Venkatesan, Matthew Cary, Ruoming Pang, Saurabh Sinha und Mariusz H. Jakubowski, Proceedings of 5th International Workshop an Information Hiding, Noordwijkerhout, Niederlande, Oktober 2002, Lecture Notes in Computer Science, Nr. 2578, Springer-Verlag, 2003, beschrieben.
  • Eine zweite Lösung besteht darin, den anfangs im zu verifizierenden Gerät vorliegenden Code mit einem digitalen Signaturalgorithmus zu unterzeichnen. Dieser Ansatz setzt voraus, dass der bereits im Gerät vorliegende Code vertrauenswürdig ist. Diese Lösung wird beispielsweise von Konsortium Trusted Computing Group empfohlen, dessen Website https://www.trustedcomputinggroup.org/home ist.
  • Die Erfindung stellt eine Lösung für das Problem der Verifizierung der Übereinstimmung eines computertechnischen Geräts mit einem logischen Inhalt oder Referenzzustand. Die Erfindung setzt nur die Kenntnis von Hardwarespezifikationen des verifizierten Geräts voraus.
  • In bestimmten Ausführungsformen ermöglicht die Erfindung, zu gewährleisten, dass ein gegebener Code präzise auf ein Gerät geladen wird, dessen Hardwarespezifikationen bekannt sind. Diese Ausführungsformen setzen weder voraus, dass das zu verifizierende Gerät spezifische Geheimnisse enthält, noch einen Code, der bereits als sicher angenommen wird; sie setzen weiterhin nicht das Vorhandensein eines Hardwaremechanismus voraus, der ermöglicht, einen privilegierten Eingriff auf das Gerät zu gewährleisten.
  • In einer Ausführungsform stellt die Erfindung ein computertechnisches Gerät bereit, welches einen Prozessor, einen Speicher, den der Prozessor lesen und beschreiben kann, und eine Ein-/Ausgabevorrichtung, die eine Kommunikation zwischen dem Prozessor des Geräts und der Außenwelt ermöglicht, aufweist.
  • Eine Anforderung des Ladens eines Verifizierungsprogramms P in den Speicher und des Ausführens dieses Programms wird an das Gerät gesendet, wobei das Verifizierungsprogramm Daten in den Speicher des Geräts schreiben und Daten aus dem Speicher lesen kann, um sie zur Ein-/Ausgabevorrichtung zu senden. Eine Anforderung des Ausführens des Programms P wird an das Gerät gesendet, um den verfügbaren, nicht mit dem Programm belegten Speicher zu sättigen. Nachrichten werden mit dem Gerät ausgetauscht, das das Programm ausführt, und die Übereinstimmung des logischen Inhalts des Geräts wird in Abhängigkeit von den mit dem Gerät ausgetauschten Nachrichten verifiziert.
  • In anderen Ausführungsformen kann das Gerät eines oder mehrere der folgenden Merkmale aufweisen:
    • – die Verifizierung der Übereinstimmung erfolgt in Abhängigkeit von dem Inhalt der mit dem Gerät ausgetauschten Nachrichten;
    • – die Verifizierung der Übereinstimmung erfolgt in Abhängigkeit von der Messung der zeitlichen Abstimmung der mit dem Gerät ausgetauschten Nachrichten;
    • – das Verifizierungsprogramm P umfasst zusätzliche Lesebefehle, die in der Ein-/Ausgabevorrichtung eine gesteigerte Aktivität bewirken;
    • – die Verifizierung der Übereinstimmung wird mittels einer Rückwärtsschritttechnik nachgewiesen, die auf die von dem Prozessor ausführbare Befehlsliste angewendet wird;
    • – der Schritt des Nachweisens der Übereinstimmung mittels einer Rückwärtsschritttechnik umfasst die Bewertung unterschiedlicher Kandidatenbefehle auf konkrete Weise;
    • – der Schritt des Nachweisens der Übereinstimmung mittels einer Rückwärtsschritttechnik umfasst die Bewertung unterschiedlicher Kandidatenbefehle auf abstrakte Weise;
    • – die Verifizierung der Übereinstimmung wird mittels einer umfassenden Untersuchung möglicher Programme nachgewiesen, die auf die von dem Prozessor ausführbare Befehlsliste angewendet wird;
    • – die Anforderung des Ladens in den Speicher umfasst eine Anforderung des Ladens des Verifizierungsprogramms P in den Speicher von der Ein-/Ausgabevorrichtung aus;
    • – die Anforderung des Ladens in den Speicher umfasst eine Anforderung des Aktivierens eines Verifizierungsprogramms P, das im Gerät enthalten ist;
    • – das Ausführen des Programms P zum Sättigen des verfügbaren Speichers umfasst das Lesen von Fülldaten von der Ein-/Ausgabevorrichtung und das Schreiben von Fülldaten in den Speicher;
    • – das Ausführen des Programms P zum Sättigen des verfügbaren Speichers umfasst das Lesen eines Problems von der Ein-/Ausgabevorrichtung und die Lösung des Problems mit dem Verifizierungsprogramm P, indem der verfügbare Speicher eingesetzt wird;
    • – das Ausführen des Programms P zum Sättigen des verfügbaren Speichers umfasst das Lesen eines Kerns von der Ein-/Ausgabevorrichtung und die Erweiterung des Kerns, indem der verfügbare Speicher eingesetzt wird;
    • – das Austauschen von Nachrichten Folgendes umfasst: das Senden einer Anforderung des Lesens von Daten des Speichers an das Gerät und den Empfang von in dem Speicher gelesenen Daten, die den Code des Verifizierungsprogramms umfassen, durch das Gerät;
    • – das Verifizierungsprogramm kann eine Funktion auf die Daten des Speichers ausführen und das Austauschen von Nachrichten Folgendes umfasst: das Senden einer Anforderung des Ausführens der Funktion und des Lesens von Daten des Speichers an das Gerät und den Empfang des Resultats der Funktion und des in dem Speicher gelesenen Codes des Verifizierungsprogramms durch das Gerät;
    • – die auf die Daten ausgeführte Funktion umfasst die Berechnung des Hash-Codierens von Daten des Speichers, bei denen es sich nicht um den Code des Verifizierungsprogramms handelt;
    • – das Ausführen des Programms P zum Sättigen des verfügbaren Speichers umfasst das Lesen eines Problems von der Ein-/Ausgabevorrichtung und die Lösung des Problems, indem der verfügbare Speicher eingesetzt wird, wobei das Austauschen von Nachrichten Folgendes umfasst: das Senden eines Problems an das Gerät und den Empfang des Resultats des Problems und des in dem Speicher gelesenen Codes des Verifizierungsprogramms durch das Gerät;
    • – der Code des Verifizierungsprogramms umfasst Befehle zum erneuten Lesen des Codes gegenüber der Ein-/Ausgabevorrichtung;
    • – das Ausführen des Verifizierungsprogramms bewirkt das Löschen des Speichers, mit Ausnahme des Codes des Verifizierungsprogramms.
  • In einer anderen Ausführungsform betrifft die Erfindung eine Wiederherstellung eines computertechnischen Geräts, das einen Prozessor, einen Speicher, den der Prozessor lesen und beschreiben kann, und eine Ein-/Ausgabevorrichtung, die eine Kommunikation zwischen dem Prozessor des Geräts und der Außenwelt ermöglicht, aufweist:
    • – in dem Speicher enthaltene Daten werden vor der Außenwelt geschützt;
    • – die Übereinstimmung des logischen Inhalts des computertechnischen Geräts mit einem Referenzinhalt wird verifiziert;
    • – geschützte Daten werden analysiert und ggf. bearbeitet und
    • – analysierte Daten werden in den Speicher des Geräts übertragen.
  • In noch einer anderen Ausführungsform stellt die Erfindung ein computertechnisches Gerät bereit, das einen Prozessor, einen Speicher, den der Prozessor lesen und beschreiben kann, eine Ein-/Ausgabevorrichtung, die eine Kommunikation zwischen dem Prozessor des Geräts und der Außenwelt ermöglicht, und ein in dem Gerät gespeichertes Verifizierungsprogramm umfasst, wobei das Verifizierungsprogramm Befehle umfasst, die darauf eingerichtet sind, Folgendes zu bewirken, wenn es von dem Prozessor ausgeführt wird:
    • – das Schreiben von Daten in den Speicher des Geräts und
    • – das Lesen von Daten in dem Speicher, die den Codes des Verifizierungsprogramms umfassen, um diese zur Ein-/Ausgabevorrichtung zu senden.
  • In einer letzten Ausführungsform stellt die Erfindung eine computertechnische Vorrichtung bereit, die Folgendes umfasst:
    • – eine erste Untereinheit, die einen Prozessor, einen Speicher, den der Prozessor lesen und beschreiben kann, und eine Ein-/Ausgabevorrichtung umfasst;
    • – eine zweite Untereinheit, wobei die zweite Untereinheit darauf eingerichtet ist, über die Ein-/Ausgabevorrichtung mit dem Prozessor der ersten Untereinheit zu kommunizieren und die Übereinstimmung des logischen Zustands der ersten Untereinheit gemäß dem oben erwähnten Verfahren zu verifizieren.
  • Weitere Merkmale und Vorteile der Erfindung zeigen sich bei Lektüre der folgenden ausführlichen Beschreibung von Ausführungsformen der Erfindung, die nur beispielhaft gegeben sind, und unter Bezugnahme auf die Zeichnungen, in denen:
  • 1 eine schematische Darstellung eines Geräts zeigt, von dem gewünscht wird, den logischen Zustand zu verifizieren;
  • 2 ein Flussdiagramm eines ersten Ausführungsbeispiels des Verfahrens der Erfindung zeigt;
  • 3 ein Flussdiagramm eines zweiten Ausführungsbeispiels des Verfahrens der Erfindung zeigt;
  • 4 ein Flussdiagramm eines Verfahrens zur Wiederherstellung des Zustands eines computertechnischen Geräts zeigt;
  • 5 ein Funktionsschema einer Vorrichtung zeigt, in deren Inneren das Verfahren der 2 oder 3 ausgeführt wird.
  • 1 zeigt eine schematische Ansicht eines computertechnischen Geräts. Wie oben erläutert, weist das Gerät 2 einen Prozessor 4, einen Speicher 6 und eine Ein-/Ausgabevorrichtung 8 auf. Der Prozessor 4 kann den Speicher 6 beschreiben und aus diesem Speicher lesen. Der Prozessor 4 kann auch ausführbaren Code, der in dem Speicher 6 gespeichert ist, ausführen. Der Prozessor 4 kann außerdem Informationen von der Ein-/Ausgabevorrichtung empfangen und Informationen über die Ein-/Ausgabevorrichtung an die Außenwelt senden. In 1 sind nur die Funktionselemente dargestellt, die zur Durchführung der Erfindung erforderlich sind; insbesondere kann das Gerät einen spezifischen Speicher aufweisen, der das Betriebssystem enthält, wie die oben beispielhaft erwähnten Flash-Chips; der Speicher 6 ist somit der Speicher, der dem Benutzer des Geräts zum Laden von Daten, Parametern oder vom Prozessor ausführbaren Codes angeboten wird.
  • Die verschiedenen Elemente des Geräts der 1 sind Funktionselemente und verschiedene Hardwarelösungen können verwendet werden, um diese zu implementieren. In Bezug auf den Prozessor können handelsübliche Prozessoren, wie 68HCO5 oder 80C51, oder auch die oben erwähnten Flash-Chips verwendet werden. In Bezug auf den Speicher kann der Flash-Speicher, ein Magnetspeicher oder ein EEPPROM-Speicher in einer beliebigen Form verwendet werden. Die besondere Form, die die Ein-/Ausgabevorrichtung aufweist, ist gleichgültig. Im Beispiel einer Chipkarte kann die Ein-/Ausgabevorrichtung Signale lesen, die auf den seriellen Anschluss angewendet werden; im Beispiel einer berührungslosen Chipkarte umfasst die Ein-/Ausgabevorrichtung eine Antenne und Schaltkreise, die zum Decodieren der Signale eingerichtet sind, die auf der Antenne empfangen wurden. Im Beispiel eines Cash-Systems bestehen die verschiedenen Funktionselemente der 1 in der Regel aus einem 32-Bit-Mikroprozessor, einem seriellen Anschluss und einem Flash-Speicher.
  • Wie oben angegeben, kann das Gerät außer einer Chipkarte oder einem Cash-System ein Personalcomputer oder ein anderer Computer, ein Minicomputer, ein Pay-TV-Gerät oder ein beliebiges anderes Gerät sein, das die schematische Struktur der 1 aufweist.
  • Das Verifizierungsverfahren der Erfindung setzt voraus, dass die Hardwarespezifikationen des Geräts 2 bekannt sind. Im Beispiel der 2 reicht es aus, die Kapazität des Speichers 6 des Geräts zu kennen. Im Beispiel der 3 erfordert das Verfahren zudem, die Zeitcharakteristika des Prozessors des Geräts zu kenne, in der Regel die Anzahl der Taktzyklen, die zur Ausführung jedes Befehls erforderlich ist.
  • 2 ist ein Flussdiagramm eines ersten Ausführungsbeispiels des Verfahrens der Erfindung. In dieser Ausführungsform nutzt die Erfindung die Tatsache, dass die Ausführung eines bösartigen Programms, das die „normale" Funktionsweise des Geräts 2 simuliert, voraussetzt, dass Speicherressourcen verfügbar sind. Die Erfindung schlägt daher vor, von dem Gerät zu fordern, ein Verifizierungsprogramm auszuführen, das mit der Außenwelt kommunizieren und den Speicher des Geräts vor der Kommunikation sättigen kann. Bei Abwesenheit eines bösartigen Programms erfolgt die Kommunikation mit der Außenwelt auf abwartende Weise; wenn ein bösartiges Programm vorhanden ist und versucht, die Ausführung des Verifizierungsprogramms zu simulieren, führt das Fehlen von Speicherressourcen dazu, dass die Kommunikation mit der Außenwelt nicht auf abwartende Weise erfolgt.
  • In Schritt 10 wird von dem Gerät 2 gefordert, ein Verifizierungsprogramm, im Folgenden P genannt, in den Speicher 6 zu laden und auszuführen. Das Laden kann über den Umweg der Ein-/Ausgabevorrichtung erfolgen, indem das Programm in den Speicher 6 geschrieben wird. Es kann auch ein ruhendes Verifizierungsprogramm P vorgesehen werden – auch in der verifizierten Vorrichtung gespeichert; in diesem Fall ist es nicht erforderlich, es über die Ein-/Ausgabevorrichtung zu laden, und es reicht aus, es im Speicher 6 einzurichten. Der Ausdruck „Laden" soll folglich ein Schreiben des Programms über die Ein-/Ausgabevorrichtung 8 im Speicher 6, jedoch auch ein Schreiben eines bereits im Gerät 2 enthaltenen Programms in den Speicher 6 beinhalten, ist jedoch nicht darauf beschränkt.
  • Das Verifizierungsprogramm P, wenn es ausgeführt wird, ermöglicht, Daten in den Speicher 6 zu schreiben; in der unter Bezugnahme auf 2 beschriebenen Ausführungsform besteht das Schreiben von Daten im Schreiben von in der Ein-/Ausgabevorrichtung 8 empfangenen Daten in den Speicher 6. Es gibt weitere Modi zum Schreiben von Daten in den Speicher.
  • Das Programm P ermöglicht außerdem, wenn es ausgeführt wird, den Inhalt des Speichers zu lesen, um ihn zur Ein-/Ausgabevorrichtung zu senden.
  • Zum Ende des Schritts 10 gibt es auch keine Gewissheit, dass das Gerät korrekt beladen und das Programm P ausgeführt hat. Wenn dies der Fall ist, verhält sich das Gerät bei Fehlen jeglichen bösartigen Programms „normal". Das Gerät kann ein bösartiges Programm umfassen, das versucht, die „normale" Funktionsweise zu simulieren: Das Gerät kann aufgrund dieses bösartigen Programms probieren, sich so zu verhalten, als ob das Programm P geladen, jedoch nicht korrekt geladen oder nur ein Teil geladen oder auch unterlassen wurde, es auszuführen.
  • In den Schritten 12 bis 18 wird das Programm P verwendet, um ein Verifizierungsprotokoll mit dem Gerät einzuleiten. Dieses Protokoll hat zum Ziel, die Funktionsweise des Geräts zu testen, um zu ermöglichen, mit Gewissheit zu folgern, dass das Gerät „sauber" ist, das heißt, dass es kein bösartiges Programm umfasst, oder mit Gewissheit zu folgern, dass das Gerät infiziert ist, das heißt, dass es einen bösartigen Code umfasst.
  • In Schritt 12 wird das Programm P verwendet, um den Speicher 6 des Geräts mit einem Block zufallsbedingter oder nicht zufallsbedingter Daten, R genannt, zu sättigen. Die Sättigung besteht im Füllen des Speichers 6 mit Ausnahme des Teils des Speichers 6, in dem das Programm P gespeichert ist. Im Beispiel der 2 erfolgt diese Sättigung einfach, indem zufallsbedingte Daten, im Folgenden R genannt, auf die Ein-/Ausgabe des Geräts 2 angewendet werden; die Daten R werden aufgrund der Ausführung des Programms P in den Speicher 6 geschrieben. Alternativ dazu wird nicht ausgeschlossen, dass R aus feststehenden und/oder nicht zufallsbedingten Daten, die bereits im verifizierten Gerät vorhanden sind, oder von der Außenwelt stammenden Daten bestehen.
  • In den Schritten 14 bis 16 werden Nachrichten mit dem zu verifizierenden Gerät ausgetauscht. Schritt 14 ist die Anwendung einer Anforderung, an das Gerät, des Ausführens des Programms P, um den Inhalt des Speichers 6 zu lesen. In Schritt 16 wird von dem Gerät der Inhalt des Speichers 6 oder eine Angabe, deren Wert mit dem Inhalt des Speichers verknüpft ist, empfangen. Wir verstehen folglich unter „Inhalt des Speichers" jede Angabe, deren Wert mit dem Inhalt des Speichers verknüpft ist und/oder diesem entspricht.
  • In Schritt 18 wird der vom Gerät 2 empfangene Inhalt des Speichers 6 mit den erwarteten zufallsbedingten Daten R und mit dem Code des Programms P und allgemeiner mit jeglicher Spur einer normalen Ausführung, die aus der Ausführung von P resultierte, als die Bedingungen normal waren, verglichen. Wenn der von dem Gerät empfangene Inhalt des Speichers 6 den Daten R und dem Code des Programms P entspricht, wird in Schritt 20 gefolgert, dass das Gerät „sauber" ist und kein bösartiges Programm umfasst. Im Gegensatz dazu, wenn dies nicht der Fall ist, wird in Schritt 22 gefolgert, dass das Gerät sich nicht in einem Zustand befindet, der dem Referenzzustand entspricht.
  • Der Vergleich des Schritts 18 beruht auf der Tatsache, dass P das einzige Programm ist, das zugleich
    • – sich nach dem Laden der Daten R in dem restlichen Platz in dem Speicher halten kann und
    • – zu einem Verhalten fähig ist, das darin besteht, die Daten R und den Code von P zum externen Verifizieren zurückzusenden.
  • Dies ergibt sich einerseits aus der Sättigung des Speichers 6; ein bösartiges Programm, das sich auf dem Gerät befinden kann, um dessen normale Funktionsweise zu simulieren, muss einen Teil des Speichers 6 nutzen; es muss folglich das Laden der Daten R in den Speicher simulieren, um sie anschließend zurückzubekommen. Dies ist um so schwerer, wenn die Daten R zufallsbedingt, wie oben erwähnt, oder pseudozufallsbedingt sind. In dem Fall, in dem die Daten R nicht zufallsbedingt sind, muss der Prüfer sicherstellen (selbst nachweisen) oder die Hypothese aufstellen, dass ein potentielles bösartiges Programm nicht dazu in der Lage ist, die korrekte Wiedergabe dieser nicht zufallsbedingten Daten zu simulieren.
  • Dies ergibt sich dann aus dem Umfang des Programms P. Es ist vorteilhaft, wenn das Programm P einen möglichst geringen Umfang aufweist, um das Schreiben eines Programms, das dessen Funktionsweise simuliert, in der Praxis unmöglich zu machen. Im weiter vorgeschlagenen Beispiel weist das Programm P einen Umfang von 23 Byte auf. Ein Umfang von weniger als 50 Byte macht in der Praxis einen geringen Umfang aus, der das Schreiben eines Programms mit der gleichen Funktionsweise extrem schwer, sogar unmöglich macht.
  • Schließlich ergibt sich dies aus der Tatsache, dass das Austauschen von Nachrichten mit dem Gerät auch das Lesen des Codes des Programms P umfasst.
  • Somit kann ein bösartiges Programm aufgrund der Sättigung des verfügbaren Speichers nicht über erforderliche Speicherressourcen verfügen, um die „normale" Funktionsweise des Geräts in den verschiedenen Schritten des Verfahrens der 2 zu simulieren.
  • Ein erstes Beispiel von Programm P ist unten angegeben. Dieses Programm wird 68HCO5-Assembler geschrieben. Beispiel1.asm
    Figure 00140001
    Figure 00150001
  • Solange der angewendete Befehl Null ist, führt das Programm das Lesen des Speichers durch – dies umfasst das Lesen seines sauberen Codes. Wenn der Befehl nicht Null ist, beschreibt das Programm den gesamten verfügbaren Speicher, außerhalb der Stelle, die es belegt. Das Verfahren der Erfindung wird somit durchgeführt:
    • – indem von dem Gerät gefordert wird, das Laden des obigen Programms Beispiel1.asm in seinen Speicher zu laden und dann auszuführen;
    • – indem ein Befehl, der nicht Null ist, und Fülldaten in ausreichender Menge, um den verfügbaren Speicher zu füllen, angewendet werden (der Prüfer kann ein solches Laden ab dem Zeitpunkt verhindern, ab dem er verifiziert, dass die bereits in dem Speicher vorhandenen Daten R keinem bösartigen Programm ermöglichen, ein korrektes Verhalten zu simulieren – bereits in dem Speicher vorhandenen Daten R können vorbehaltlich eines solchen Nachweisens oder einer solchen Hypothese verwendet werden); hier ist zu beachten, dass vorausgesetzt wird, dass die Hardwarespezifikationen des Gerät, insbesondere der Speicherumfang bekannt sind;
    • – indem ein Befehl, der Null ist, angewendet wird, um das Lesen der Gesamtheit der in dem Speicher enthaltenen Daten bewirkt wird.
  • Bei der Ausführung erzeugt dieses Programm Beispiel1.asm die Folge 00FF3F81 BE802706 B680E780 20F43381 E680B780 5C26F920 E9 {zufallsbedingter Block R}.
  • Das oben vorgeschlagene Beispiel zeigt, dass es möglich ist, Codes zu generieren, die die erforderliche Funktion aufweisen und beim Lesen die erwarteten Informationen zurücksenden.
  • Das unter Bezugnahme auf 2 beschriebene Verfahren weist den Vorteil auf, nur die Kenntnis der Kapazität des Speichers 6 des Geräts 2 zu implizieren, so dass eine Sättigung des Speichers sichergestellt wird. Wenn zudem die Zeitcharakteristika des Prozessors 4 des Geräts bekannt sind, kann auch die Zeit – als Anzahl der Taktzyklen des Prozessors – gemessen werden, die erforderlich ist, um die Daten R sowie den Code des Programms P zurückzusenden.
  • Somit kann der Prüfer die Zeit der Anzahl der Taktzyklen nehmen, die das Rücksenden der verschiedenen Byte trennen, die die zurückgesendete Angabe „R und der Code von P" darstellen, und folgern, dass das Gerät M nur „sauber" ist, wenn die Byte der Angabe „R und der Code von P" in einem vorhersehbaren Rhythmus zurückgesendet werden, sie Daten der Spezifikationen des Prozessors des Geräts M sind.
  • 3 zeigt das entsprechende Verfahren; 3 ist mit 2 identisch, mit Ausnahme des Schritts 19, der Verifizierung der zeitlichen Abstimmung von mit dem Gerät ausgetauschten Nachrichten. Wenn die Abstimmung der Nachrichten nicht die erwartete ist, folgert der Prüfer in Schritt 26, dass der logische Inhalt des Geräts nicht mit dem erwarteten Inhalt übereinstimmt. Andernfalls befindet sich das Gerät in einem logischen Zustand, der mit dem Referenzzustand übereinstimmt (Schritt 28). In der Darstellung der 3 folgt Schritt 19 der Verifizierung der Abstimmung von mit dem Gerät ausgetauschten Nachrichten auf Schritt 18. Es handelt sich nur um eine schematische Darstellung, die Reihenfolge der Verifizierungen hat keine Auswirkung.
  • Diese Verifizierung der Abstimmung von Nachrichten gestaltet die Simulierung des Verhaltens des Programms P durch ein bösartiges Programm auch schwieriger.
  • Außerdem ist es möglich, es auf formelle Art und Weise nachzuweisen, indem eine Backtracking (oder im Deutschen Rückwärtsschritt) genannte Technik angewendet wird, bei der ein gegebener Code der einzige ist, der dem Prüfer R und seinen sauberen Code innerhalb einer Frist und/oder eines präzisen Rhythmus wiedergeben kann. Diese Backtracking-Technik ist dem Fachmann an sich bekannt und wird beispielsweise in: http://www.cis.upenn.edu/~matuszek/cit594-2002/Pages/backtrackinq/html beschrieben; sie wird daher nicht ausführlich beschrieben. Während die Gewissheit der Übereinstimmung im Verfahren der 2 empirisch ist, ermöglicht das Verfahren der 3 einen formellen Beweis der Unmöglichkeit, ein bösartiges Programm hervorzubringen, das die Funktionsweise des Verifizierungsprogramms P simuliert.
  • Um dieses Nachweisen zu vereinfachen, ist es vorteilhaft, die Schleife eines erneuten Lesens von Befehlsbyte zusätzlich zum Rücksenden der Byte einzubringen, was zum Ziel hat, jegliches bösartiges Programm noch mehr zu etwas zu zwingen, wie im folgenden Beispiel dargestellt ist:
    Figure 00170001
  • Das vorherige Codefragment sendet ein Byte mit jeweils 14 Rechnerzyklen zurück. Der im Verfahren der 3 einsetzbare formelle Beweis besteht darin, nachzuweisen, dass keine Befehlsequenz von höchstens 14 Zyklen die erwartete Sequenz zeitgemäß und rechtzeitig generieren kann.
  • Um die Durchführung eines bösartigen Programms noch schwieriger zu machen – oder den formellen Beweis zu vereinfachen, kann außerdem die Schleife eines erneuten Lesens mit Operationen des Rücksendens von Informationen eingebracht werden, um diese Dauer von 14 Zyklen, die das Senden von aufeinander folgenden Charakteren der Sequenz „R und Code von P" soweit wie möglich zu verkürzen. Zum Beispiel:
    Figure 00170002
  • In diesem Beispiel ist zu bemerken, dass das bösartige Programm nur noch 8, 7 oder 8 Zyklen einrichtet, um jedes der Byte der Sequenz „R und Code von P" zu generieren. Dies ermöglicht, die Codes, die das Generieren von Sequenzen ermöglichen, automatisch zu untersuchen und diese Codes nacheinander über den Umweg eines Backtracking genannten Verfahrens auszusortieren, sofern gewünscht wird, eine formelle Verifizierung der Unmöglichkeit des Erstellens eines bösartigen Codes einzurichten.
  • Es ist anzumerken, dass es sich nicht um eine umfassende Untersuchung aller möglichen Codes handelt, denn sobald ein Code C von den auferlegten zeitlichen Einschränkungen abweicht, alle längeren Codes mit C als Fragment oder Präfix eliminiert werden.
  • Zur Verifizierung mittels Backtracking können die unterschiedlichen Kandidatenbefehle auf konkrete oder abstrakte (symbolische) Weise bewertet werden. Die Vorteile einer konkreten Bewertung sind eine größere Einfachheit der Programmierung. Die Vorteile einer symbolischen Verifizierung sind eine höhere Effizienz trotz einer größeren Komplexität der Programmierung.
  • Anhang 1 der vorliegenden Beschreibung stellt den Quellcode eines Verfahrens zum Nachweisen des Codes dar, der ein Backtracking-Verfahren ermöglicht, das speziell auf die vorliegende Erfindung eingestellt ist.
  • Anhang 2 der vorliegenden Beschreibung gibt für das Beispiel des Programms Beispiel1.asm, das zusätzliche Lesebefehle einbringt, das vom Gerät erwartete Verhalfen an.
  • Das Nachweisen der Verifizierung der Übereinstimmung kann eine umfassende Untersuchung einsetzen, die auf die von der verifizierten Plattform ausführbare Befehlsliste angewendet wird; dann wird die Gesamtheit der möglichen Codes bestimmt, die den erforderlichen Umfang aufweisen, und es wird der Test dieser Codes durchgeführt, um nachzuweisen, dass sie nicht darauf eingerichtet sind, Nachrichten zu liefern, die mit dem Gerät ausgetauscht werden; dieses Nachweisen gilt für das Verfahren der 2, in der die Verifizierung in Abhängigkeit von dem Inhalt der mit dem Gerät ausgetauschten Nachrichten erfolgt; diese Technik gilt auch für das Verfahren der 3, in der die Verifizierung außerdem in Abhängigkeit von dem Ausmaß der zeitlichen Abstimmung der mit dem Gerät ausgetauschten Nachrichten erfolgt.
  • Anhänge 3 und 4 zeigen die Codierungen unterschiedlicher Befehle mit 7 Zyklen und 8 Zyklen, die für eine Befehlsliste möglich sind, die dem 68HCO5-Assembler entspricht. Diese unterschiedlichen Befehle mit 7 und 8 Zyklen können für ein Nachweisen der Verifizierung der Übereinstimmung mittels umfassender Untersuchung verwendet werden, wenn in das Programm Befehle eines erneuten Lesens eingebracht sind, die zu 7 oder 8 Zyklen führen, die für das bösartige Programm verfügbar sind, wie im oben vorgeschlagenen Beispiel.
  • Anhang 5 zeigt ein anderes Beispiel des Codes des Verifizierungsprogramms P; der Anhang zeigt nur den Teil des Programms, der das erneute Lesen von Werten ermöglicht, der Teil des Platzierens des Werts in dem verifizierten Speicher wurde zwecks mehr Deutlichkeit entfernt.
  • Die unter Bezugnahme auf die 2 und 3 vorgeschlagenen Verfahren ermöglichen eine Verifizierung der Übereinstimmung des logischen Inhalts des Geräts. Diese Verfahren implizieren allerdings eine Sättigung des Speichers mittels Anwendung von Sätti gungsdaten R auf die Ein-/Ausgabevorrichtung. Eine solche Lösung bringt kein besonderes Problem mit sich, wenn die Kapazität des Speichers 6 im Verhältnis zur Ausgabeleistung der Ein-/Ausgabevorrichtung ausreichend gering ist. Die Verfahren der 2 und 3 sind somit leicht bei Geräten wie Chipkarten anwendbar. Wenn die Kapazität des Speichers sehr groß ist – beispielsweise ein Megabyte- oder Gigabyte-Speicher in einem Computer –, kann vorteilhafterweise eine der folgenden Lösungen für den Schritt der Sättigung des Speichers eingesetzt werden.
  • Eine erste Lösung besteht darin, anstelle von Sättigungsdaten dem Gerät die Spezifikation eines zu lösenden Problems zu liefern, wobei die Lösung des Problems zur Sättigung des Speichers führt. Als Beispiel für solche Probleme können die SPACE COMPLETE genannten Probleme genannt werden. Zum Beispiel werden solche Probleme im Artikel „Moderately Hard, Memory-bound Functions" von Martin Abadi, Mike Burrows, Mark Manasse und Ted Wobber oder auch im Artikel „On Memory-Sound Functions for Fighting Spam" von Cynthia Dwork, Andrew Goldberg und Moni Naor beschrieben.
  • Das in dem zweiten Artikel genutzte Problem impliziert die Berechnung von Überschneidungen und somit der Belegung einer Speicherkapazität, deren Umfang in Abhängigkeit von einem Parameter festgelegt sein kann. Was die Spezifikation des Problems angeht, so miss sie nur einige wenige Byte. Es versteht sich, dass die Spezifikation des Problems in Bezug auf den Umfang des Speichers 6 „kurz" ist.
  • Eine zweite Lösung besteht darin, einen kurzen Kern einer Angabe anzuwenden, der vom Programm P zu erweitern ist, wobei die erweiterte Angabe das Sättigen des Speichers ermöglicht. Der Erweiterungsvorgang ist vorzugsweise derart, dass er kein Mittel aufweist, dass die Angabe anderweitig erweitert, indem die Vollständigkeit des verfügbaren Speichers belegt wird.
  • Die oben und unter Bezugnahme auf 2 vorgeschlagenen unterschiedlichen Lösungen können auch gemischt werden.
  • Eine dritte Lösung besteht darin, den Speicher nicht zu sättigen und mit den bereits auf der verifizierten Plattform vorhandenen Daten zu arbeiten (diese Daten können je nach dem Fall aus bereits auf der Plattform vorhandenem ausführbarem Code (Code von rechtmäßigen Anwendungen) und/oder rechtmäßigen passiven Daten bestehen). In diesem Fall kann der Prüfer vorzugsweise zunächst nachweisen oder voraussetzen, dass die Wiedergabe dieser bereits auf der verifizierten Plattform vorhandenen Daten durch das Programm P in der Verifizierungsphase nicht von einem bösartigen Programm simu liert werden kann (mit oder ohne Einschränkungen der zeitlichen Abstimmung). Ein solches Nachweisen kann stets mit einer Backtracking-Technik erzielt werden.
  • Diese Lösungen ermöglichen, die Dauer des Schritts der Sättigung des Speichers durch das Programm P zu begrenzen oder das Laden von bereits im Speicher enthaltenen Daten zu verhindern. In den Fallen, in denen die Sättigungsdaten zumindest zu Beginn von der Außenwelt stammen (Lieferung des Problems, Lieferung des Kerns), bleibt es für ein bösartiges Programm unmöglich, im Voraus die Lösung vorauszusehen und somit die Sättigung des Speichers zu verhindern. Diese Lösungen setzen allerdings voraus, dass das Programm P komplexer als das oben vorgeschlagene Programm Beispiel1.asm ist.
  • Wir merken schließlich an, dass es anstelle der zufallsbedingten Angabe auch möglich ist, anstelle von R eine festgelegte und nicht vertrauliche Angabe zu verwenden und in diesem Fall nachzuweisen, dass das Verhalten der Plattform unzweideutig charakterisierbar ist.
  • Die Verfahren der 2 und 3 implizieren auch einen Schritt 16 des Lesens des Inhalts des Speichers. Wie bei dem Beschreiben des Speichers bringt diese Lösung kein besonderes Problem mit sich, wenn die Kapazität des Speichers 6 im Verhältnis zur Ausgabeleistung der Ein-/Ausgabevorrichtung ausreichend gering ist. Es kann dennoch eine der folgenden Lösungen verwendet werden, um den Austausch zwischen dem Gerät und der Außenwelt schneller zu machen.
  • Eine erste Lösung besteht darin, anstelle des Lesens von zufallsbedingten oder pseudozufallsbedingten Sättigungsdaten eine Berechnung des Hash-Codierens oder eine Berechnung der zyklischen Blockprüfung an diesen Daten durchzuführen. Sofern die Daten zufallsbedingt oder pseudozufallsbedingt sind, ist die in der Beschreibung der Softwarelösung des Standes der Technik erwähnte Komprimierung unmöglich oder sehr schwierig.
  • Es kann auch die folgende Lösung vorgeschlagen werden: n zufallsbedingte oder pseudozufallsbedingte Füllblocks werden von der Außenwelt empfangen; diese Daten werden von dem Programm P in dem Speicher 6 platziert. Auf diesen Schritt 12 der Sättigung des Speichers folgt eine Anzeige einer Konvertierung von n Elementen durch die Außenwelt und das Rücksenden des Hash-Codes von konvertierten Daten an die Außenwelt durch das Programm P. Auch wenn das bösartige Programm die Art der anzuwendenden Hash-Codierung kennt, ist es ihm somit unmöglich, den Hash-Code bei Empfang der Füllblocks zu berechnen.
  • Diese Lösungen ermöglichen, die Dauer des Schritts des Lesens von dem Speicher durch das Programm P zu begrenzen. Sofern die Berechnung der zyklischen Blockprüfung, des Hash-Codes oder die Berechnung des Resultats das Einrichten von Sättigungsdaten in ihrer Gesamtheit impliziert, bleibt es für ein bösartiges Programm unmöglich, im Voraus die Lösung vorauszusehen und somit die Sättigung des Speichers zu verhindern. Das Zurücksenden von Informationen zur Außenwelt ist allerdings schneller, weil es ausreicht, {das Resultat der an den Daten R + dem Code von P vorgenommenen Berechnung} zu übertragen, anstatt {die Daten R + den Code von P} zu überfragen.
  • Die oben und unter Bezugnahme auf 2 vorgeschlagenen unterschiedlichen Lösungen können auch gemischt werden. Es versteht sich zudem, dass die Lösungen, die die Dauer des Beschreibens des Speichers begrenzen, und die Lösungen, die die Dauer des Lesens von Daten von dem Speicher begrenzen, gemischt werden können.
  • Weder die Abfolge des Verifizierungsverfahrens noch seine Anwendungen werden hier beschrieben. Im Beispiel von zu personalisierenden Geräten folgt auf die Personalisierung eine Verifizierung der Übereinstimmung des Geräts, während ein Gerät, das nicht als übereinstimmend erweist, abgelehnt wird. Sobald das Gerät verifiziert wurde, kann die Kapazität des in den Speicher 6 des Geräts zu schreibenden Programms P zur Personalisierung des Geräts verwendet werden.
  • Das Verfahren der 2 und 3 gilt insbesondere, wenn der Speicher mutmaßlich keinen Code enthält oder wenn der Speicher, der einen bekannten Code enthält, problemlos zum Ende des Verifizierungsverfahrens wiederhergestellt werden kann.
  • Es kann auch vorgesehen werden, dass das Programm P damit beginnen, alle vorhandenen Daten aus dem Speicher zu löschen, mit Ausnahme seines sauberen Codes, dann den Empfang von Daten von der Außenwelt einzuleiten.
  • Es kann auch vorgesehen werden, dass das Programm P die vorhandenen Daten an Ort und Stelle belässt, die letzteren jedoch an den Prüfer übermittelt, der das Nachweisen vornehmen wird, dass es möglich ist, die Prüfung unzweideutig mit diesen Daten anstelle zufallsbedingter Daten durchzuführen.
  • Es kann auch vor dem Schritt der Sättigung des Speichers ein Schutz von in dem Speicher enthaltenen Daten – oder eines Teils dieser vorgesehen werden, indem diese Daten vorläufig an die Außenwelt übertragen werden. Die Übereinstimmung von geschlitzten Daten kann außerhalb des Geräts analysiert werden; die geschützten Daten kennen anschließend, wenn sie übereinstimmen, im verifizierten Gerät wiederhergestellt werden; wiederum kann das Programm P zur Wiederherstellung von Daten nach der Verifizierung der Übereinstimmung verwendet werden. Die Erfindung ermöglicht somit eine Wiederherstellung eines computertechnischen Geräts. 4 zeigt ein solches Verfahren, das auf ein Gerät der Art der 1 angewendet wird: der erste Schritt 30 ist ein Schritt des Schutzes des Inhalts des Speichers vor der Außenwelt; auf ihn folgt ein Schritt 32 der Verifizierung der Übereinstimmung gemäß dem oben beschriebenen Verfahren; in Schritt 34 werden die exportierten Daten analysiert und sie werden gegebenenfalls bearbeitet, beispielsweise wenn sie ein bösartiges Programm enthalten. Wenn das Gerät sich in einem Zustand befindet, der mit dem Referenzzustand übereinstimmt (Schritt 36), werden die bearbeiteten Daten wieder dort eingegeben (Schritt 38). Wenn das verifizierte Gerät sich nicht in einem Zustand befindet, der mit dem Referenzzustand übereinstimmt, wird ein Fehler signalisiert (Schritt 40); dann können erforderliche Korrekturmaßnahmen (Neuinitialisierung oder andere) vorgenommen werden.
  • Es ist ebenfalls möglich, das in der vorliegenden Erfindung beschriebene Verfahren auf die folgenden Arten abzuändern oder zu generalisieren:
    • – Eine erste Generalisierung besteht darin, anstelle des Schreibens der Daten R in einer Handlung und des erneuten Lesens dieser in einer Handlung die Schreibvorgänge und die Lesevorgänge wiederholt abzuwechseln. Auf diese Weise wird ein erster Datenblock R[1] geschrieben, ein erster Block R'[1] wird erneut gelesen, dann wird ein zweiter Datenblock R[2] geschrieben, ein zweiter Block R'[2] wird erneut gelesen und so weiter. Hier steht R'[i] entweder für einen Wert, der R[i] entsprechen muss, oder einen Wert, der von R[i] abhängt.
    • – Eine zweite Variante kann das Verifizierungsprotokoll mit dem Rechner mehrere Male wiederholen und den Rechner im Fall eines Gelingens aller Sitzungen des Protokolls als sauber akzeptieren. Eine solche Wiederholung hat zum Ziel, die Wahrscheinlichkeit, dass eine bösartige Anwendung das Protokoll durch reinen Zufall besteht, exponentiell zu verringern.
    • – Eine dritte Variante ersetzt das Nachweisen mittels Backtracking durch jegliche andere Nachweisform, beispielsweise die umfassende Untersuchung (oder die Erzeugung) des kleineren Codes (wir nennen den Umfang dieses Codes m), der eine Angabe R mit dem Umfang von mindestens m Byte wiedergeben kann.
  • Es wurde unter Bezugnahme auf die 2 und 3 eine Verifizierung eines Geräts von der Außenwelt aus beschrieben, unter Bezugnahme auf einen „Prüfer", der kein Teil des Geräts ausmacht. Das Verfahren der Erfindung gilt auch für das Innenleben dieser Vor richtung, zwischen zwei Schaltkreisen, zwischen zwei Untersystemen oder zwei Bauteilen, die einen Teil der Vorrichtung ausmachen; in diesem Fall verhält sich einer der zwei Schaltkreise, eines der zwei Untersysteme oder eines der zwei Bauteile gegenüber dem anderen Schaltkreis, Untersystem oder Bauteil als die „Außenwelt" oder als der „Prüfer". Dieser andere Schaltkreis, dieses andere Untersystem oder dieses andere Bauteil verhält sich dann als das oben beschriebene zu verifizierende Gerät: es muss daher einen Prozessor, einen Speicher sowie eine Ein-/Ausgabevorrichtung, die eine Kommunikation mit der anderen Untereinheit ermöglicht, umfassen. 5 zeigt eine solche Vorrichtung 50. Die Elemente der ersten Untereinheit sind mit den Bezugsziffern der 1, die um 50 erhöht wurden, gekennzeichnet. Die zweite Untereinheit ist mit 60 bezeichnet; sie wird nicht ausführlicher beschrieben.
  • Anders ausgedrückt, das oben erwähnte Verfahren wird intern in der Vorrichtung ausgeführt. Es kann zwischen zwei Untereinheiten der Vorrichtung oder zwischen mehr als zwei Untereinheiten, je nach den gewünschten Konvertierungen vorgenommen werden; das Verfahren kann auf unsichtbare Weise vom Benutzer der Vorrichtung, periodisch oder in besonderen Umständen ausgeführt werden. Im Fall einer Nichtübereinstimmung können dann eine oder mehrere Aktionen bewirkt werden, wie beispielsweise ein Stoppen der Funktionen der Vorrichtung oder auch eine Nachricht an den Benutzer oder an die Außenwelt.
  • Als Beispiel kann das Verfahren der Erfindung in einem Rechner mit mehreren Prozessoren eingesetzt werden, wie einem PC, einem Cash-System, einem Pay-TV-Decoder, einem elektronischen Element, das sich in einer Waffe oder einem Militärfahrzeug befindet, wobei jeder der Prozessoren zur Verifizierung des anderen Prozessors die „Außenwelt" darstellt.
  • ANHANG 1
  • In der Sprache Mathematica geschriebener Backtracking-Algorithmus
  • Der Algorithmus untersucht die Codes mit einem Umfang MSZ = 21 Byte (als Beispiel) und setzt eine 68HCO5-Befehlsliste voraus, die durch die Befehle INCH, IDA, STA und BNE beschränkt ist, Eingabeanschluss bei 0x00, Ausgabeanschluss bei 0x01

    q:=Function[x,Mod[x,256]];
    MSZ=21;
    s:=Function[x,Mod[x,MSZ]];
    (*diese Funktion initialisiert den Zustand des Speichers auf –1 (–1 bedeutet üblicherweise unbestimmter Wert), außer das der Anschluss sich bei Adresse 0 findet, die auf 0 initialisiert wird*) M=Prepend[Table[–1,{n,1,MSZ–1}],0];
    (*Werte von 4 Opcodes*) BNE=16^^26; LDA=16^^66; INC=16^^4C;
    STA=16^^B7;
    (*Funktion, die den Inhalt eines Speicherplatzes zurücksendet*)
    RM:=Function[x,M[[s[x]+1]]];
    (*Funktion, die einem Speicherplatz einen Wert zuordnet*)
    SM:=Function[{x,v},M[[s[x]+1]]=v];
    (*Funktion, die die Kompatibilität des Inhalts der Maschine mit einer Code-Hypothese verifiziert, die vom Backtracking-Algorithmus aufgestellt wurde*)
    NC:=Function[{pt,Ist},Sum[If[Ist[[d+1]]≠ RM[s[pt+d]]&& RM[s[pt+d]]≠ 1,1,0],{d,0,Length[Ist]–1}]≠0];
    (*Funktion, die dem Speicher eine Reihe von Werten zuordnet*)
    SetM:=Function[{pt,v1},For[b=1,b≤Length[v1],SM[s[pt+b–1],vl [[s[b]]]];b++]];
    (*Funktion, die den Registern des Mikroprozessors Werte zuordnet*)
    SetRegs:=Function[{va,pt},A=q[va];Z=If[A☐0,1,0];PC=s[pt];SM[1,A]];
    (*Funktion zur Decodierung relativer Adressen für Sprungbefehl*)
    dec:=Function[j,2+j–If[j≤16^^7F,0,256]];
    (*Funktion, die testet, ob der Zustand des Speichers mit der Hypothese des Befehlsfragments der Form INCH STA 1 kompatibel ist*) INCT:=Function[U, q[Ex–1]≠ A∥NC[PC,{INC,STA,1}]]
    (*Modellierung des Effekts eines Befehlsfragments der Art INCH STA 1*)
    INCS:=Function[U,SetM[PC,{INC,STA,1}];A=Ex;Z=If[A☐0,1,0];PC–s[PC+3]; SM[1,A];]
    (*die gleiche Vorgehensweise wie zuvor bei einem Fragment der Art IDA m STA 1*) LDAT:=Function[U, NC[PC,{LDA,U,STA,1}]∥
    If[MemberQ[{PC,s[PC+1],s[PC+2],s[PC+3]},s[U]], Ex≠
    Pick[{LDA,U,STA,1},{PC,s[PC+1],s[PC+2],s[PC+3]},s[U]][[1]], RM[U]≠Ex && RM[U]≠1]];
    LDAS:=Function[U,
    SetM[PC, {LDA,U,STA,1}];
    If[Not[MemberQ[{PC,s[PC+1],s[PC+2],s[PC+3]},s[U]],SM[U,Ex]];
    A=RM[U];Z=If[A☐0,1,0];PC=s[PC+4]; SM[1,A];]
    (*Modellierung des Effekts eines Befehlsfragments der Art BNE Lable STA 1*)
    BRAT:=Function[L,(Ex≠A∥NC[PC,{BNE,L}])∥ If [Z==1,NC[s[PC+2],{STA,1}],
    NC[s[PC+dec[L]],{STA,1}]∥ 16^^FE≤L≤16^^FF]];
    GRAS:=Function[L,
    SetM[PC,{BNE,L}];
    SetM[If[Z☐1,s[PC+2],s[PC+dec[L]]], {STA,1}];
    Z=If[A☐0,1,0];A=Ex;SM[1‚A];PCs[PC=If[Z☐1,4,dec[L]+2]]];
    (*Modellierung des Effekts eines Befehlsfragments der Art STA m STA 1*)
    STAT:=Function[U,
    NC[PC,{STA,U,STA,1}∥ A≠Ex ∥ s[U]=1 ∥ (s[U]☐s[PC+2] && A≠STA) ∥
    (s[U]☐s[PC+1]&& A≠1)];
    STAS:=Function[U,
    SetM[PC, {STA,U,STA,1}];
    SM[U,Ex]; Z=If[A☐0,1,0];A=Ex;PC=s[PC+4];SM[1,Ex];];
    (*Lesen der Datei, die die erwarteten Werte einer rechtmäßigen Plattform und deren zeitliche Abstimmung enthält, Datei weiter unten angegeben*)
    ExList=Drop[Drop[<<file.m,1],1];
    (*Lesen der Dateien, die alle Fragmente enthalten, deren Ausführung 7 oder 8 Zyklen einnehmen können, Dateien weiter unten angegeben*)
    Try[7]=<<try7.txt;Try[8]=<<try8.txt;S[8]=Length[Try[8]];S[7]=Length[Try[7]];
    (*Isolierung von erwarteten Werten in einer Tabelle, EV = Expected Values, und von Werten der zeitlichen Abstimmung, TM = Timing*)
    TM=Table[Ex,List[[h,2]],{h,1,Length[ExList]}];
    EV=Table[Ex,List[[h,1]],{h,1,Length[ExList]}];
    (*Initialisierung einer GS-Liste, die den Zustand der untersuchten Hypothese enthält*)
    For[h=1,h ≤Length[ExList],GS[h]1;PL[h]=0;h++];
    (*diese Funktion generiert den Zustand, der einer gegebenen GS-Liste entspricht*)
    ReRun:=Function[idd, PC=PCx;A=Ax;Z=Zx;M=Prepend[Table[–1,{n,1,MSZ–1}],0];
    For[c=1,c≤idd, Ex=EV[[cc]]; ExecInst[Try[TM[[c]]][[GS[c]]]]; c++]];
    (*Funktion, die einen Befehl in eine Testfunktion umwandelt*)
    TestInst:=Function[hy, Pick[{INCT,LDAT,BRAT,STAT},{"INC","LDA","BRA","STA"},hy[[1]]][[1]][hy[[2]]]]
    (*Funktion, die einen Befehl in eine Ausführungsfunktion umwandelt*)
    ExecInst:=Function[hy,Pick[{INCS,LDAS,BRAS,STAS},{"INC","LDA","BRA","STA"},hy[[1]]][[1]][hy[[2]]]]
    (*Funktion des Durchgangs des Übertrags auf die Codefragmentindizes*)
    Uniformize:=Function[,For[h=Length[ExList],h≠1
    If[GS[h]☐S[TM[h]]]+1,GS[h–1]++;GS[h]=1]; h––]];
    (*Backtracking-Schleife*)
    For[Zx=1, Zx≤2,For[Ax=0,Ax≤255,For[PCx=8,PCx≤MSZ–1,
    (****************)
    PC=PCx; A=Ax; Z=Zx;
    ID=1; Label[yyy]; Ex=EV[[ID]];CY=TM[[ID]]; HY=Try[CY][[GS[ID]]];
    If[Not[TestInst[HY]], ExecInst[HY]; ID++;Goto[yyy],
    If[GS[ID]<S[CY],GS[ID]++; Goto[yyy]]];
    PL[ID–1]++; GS[ID]=1; GS[ID–1]++;ID––; Uniformize[]; ReRun[ID–1];
    Goto[yyy]; Label[zzz];
    (****************)
    PCx++];Ax++];Zx++]; ANHANG 2 Codierung des erwarteten Verhaltens durch die Plattform (Datei file.m)
    Figure 00260001
  • Figure 00270001
  • ANHANG 3
  • Codierung unterschiedlicher Befehle mit 7 Zyklen (Datei try7.txt)
    • {{LDA,0},{LDA,1},{LDA,2},... (hier Elemente der Form {LDA,i} einfügen) ...,{LDA,251},{LDA,252},{LDA,253},{LDA,254},{LDA,255},{BRA,0},{BRA,1},{BRA,2},... (hier Elemente der Form {BRA,i} einfügen) ...,{BRA,253},{BRA,254},{BRA,255},{INC,0}}
  • ANHANG 4
  • Codierung unterschiedlicher Befehle mit 8 Zyklen (Datei try78.txt)
    • {{STA,1},{STA,2},... (hier Elemente der Form {STA,i} einfügen) ...,{STA252},{STA,253},{STA,254},{STA,255},{STA,0}}
  • ANHANG 5
    portR equ $00; read port location
    PortS equ PortR+1; send port location
    org portR;
    dw $0000;
    start: sta portS;
    addr1 lda portR;
    sta portS;
    lda addrl+1;
    sta portS;
    inca ;
    sta portS;
    sta addrl+1;
    sta portS;
    bne send;
    org $1ffE;
    dw start;
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • - „Oblivious Hashing: A Stealthy Software Integrity Verification Primitive" von Yuqun Chen, Ramarathnahm Venkatesan, Matthew Cary, Ruoming Pang, Saurabh Sinha und Mariusz H. Jakubowski, Proceedings of 5th International Workshop an Information Hiding, Noordwijkerhout, Niederlande, Oktober 2002, Lecture Notes in Computer Science, Nr. 2578, Springer-Verlag, 2003 [0020]
    • - https://www.trustedcomputinggroup.org/home [0021]
    • - http://www.cis.upenn.edu/~matuszek/cit594-2002/Pages/backtrackinq/html [0062]
    • - „Moderately Hard, Memory-bound Functions" von Martin Abadi, Mike Burrows, Mark Manasse und Ted Wobber [0075]
    • - „On Memory-Sound Functions for Fighting Spam" von Cynthia Dwork, Andrew Goldberg und Moni Naor [0075]

Claims (22)

  1. Computertechnisches Gerät, mit einem Prozessor (4) zum Ausführen von Programmen, einem Speicher (6), den der Prozessor lesen und beschreiben kann, und einer Ein-/Ausgabevorrichtung (8), die eine Kommunikation zwischen dem Prozessor (4) des Geräts und der Außenwelt ermöglicht, wobei das Gerät (2) dazu ausgestaltet ist, eine Anforderung des Ladens eines Verifizierungsprogramms (P) in den Speicher (6) und des Ausführens dieses Programms durch den Prozessor zu empfangen, wobei das Verifizierungsprogramm Daten in den Speicher (6) des Geräts schreiben und Daten aus dem Speicher (6) lesen kann, um sie zur Ein-/Ausgabevorrichtung (8) zu senden; wobei das Gerät dazu ausgestaltet ist, eine Anforderung des Ausführens des Programms (P), um den verfügbaren, nicht mit dem Programm (P) belegten Speicher (6) zu sättigen, zu empfangen, wobei Nachrichten mit dem Gerät ausgetauscht werden, das das Programm (P) ausführt, und wobei die Übereinstimmung des logischen Inhalts des Geräts in Abhängigkeit von den mit dem Gerät ausgetauschten Nachrichten verifiziert wird.
  2. Gerät nach Anspruch 1, wobei die Verifizierung der Übereinstimmung in Abhängigkeit von dem Inhalt der mit dem Gerät ausgetauschten Nachrichten erfolgt.
  3. Gerät nach Anspruch 1 oder 2, wobei die Verifizierung der Übereinstimmung in Abhängigkeit von der Messung der zeitlichen Abstimmung der mit dem Gerät ausgetauschten Nachrichten erfolgt.
  4. Gerät nach Anspruch 3, wobei das Verifizierungsprogramm (P) zusätzliche Lesebefehle umfasst, die in der Ein-/Ausgabevorrichtung (8) eine gesteigerte Aktivität bewirken.
  5. Gerät nach einem der Ansprüche 1 bis 4, wobei die Verifizierung der Übereinstimmung mittels einer Rückwärtsschritttechnik nachgewiesen wird, die auf die von dem Prozessor (4) ausführbare Befehlsliste angewendet wird.
  6. Gerät nach Anspruch 5, wobei beim Nachweisen der Übereinstimmung mittels einer Rückwärtsschritttechnik die Bewertung unterschiedlicher Kandidatenbefehle auf konkrete Weise erfolgt.
  7. Gerät nach Anspruch 5, wobei beim Nachweisen der Übereinstimmung mittels einer Rückwärtsschritttechnik die Bewertung unterschiedlicher Kandidatenbefehle auf abstrakte Weise erfolgt.
  8. Gerät nach einem der Ansprüche 1 bis 4, wobei die Verifizierung der Übereinstimmung mittels einer umfassenden Untersuchung möglicher Programme nachgewiesen wird, die auf die von dem Prozessor (4) ausführbare Befehlsliste angewendet wird.
  9. Gerät nach einem der Ansprüche 1 bis 8, wobei die Anforderung des Ladens in den Speicher eine Anforderung des Ladens des Verifizierungsprogramms (P) in den Speicher (6) von der Ein-/Ausgabevorrichtung (8) aus umfasst.
  10. Gerät nach einem der Ansprüche 1 bis 8, wobei die Anforderung des Ladens in den Speicher eine Anforderung des Aktivierens eines Verifizierungsprogramms (P) umfasst, das im Gerät enthalten ist.
  11. Gerät nach einem der Ansprüche 1 bis 10, wobei das Ausführen des Programms (P) zum Sättigen des verfügbaren Speichers das Lesen von Fülldaten von der Ein-/Ausgabevorrichtung und das Schreiben von Fülldaten in den Speicher umfasst.
  12. Gerät nach einem der Ansprüche 1 bis 11, wobei das Ausführen des Programms (P) zum Sättigen des verfügbaren Speichers das Lesen eines Problems von der Ein-/Ausgabevorrichtung und die Lösung des Problems mit dem Verifizierungsprogramm (P) umfasst, indem der verfügbare Speicher eingesetzt wird.
  13. Gerät nach einem der Ansprüche 1 bis 12, wobei das Ausführen des Programms (P) zum Sättigen des verfügbaren Speichers das Lesen eines Kerns von der Ein-/Ausgabevorrichtung und die Erweiterung des Kerns umfasst, indem der verfügbare Speicher eingesetzt wird.
  14. Gerät nach einem der Ansprüche 1 bis 13, wobei das Austauschen von Nachrichten ein Senden (14) einer Anforderung des Lesens von Daten des Speichers (3) an das Gerät und einen Empfang von in dem Speicher (6) gelesenen Daten, die den Code des Verifizierungsprogramms umfasst.
  15. Gerät nach einem der Ansprüche 1 bis 13, wobei das Verifizierungsprogramm eine Funktion auf die Daten des Speichers ausführen kann und in dem das Austauschen von Nachrichten Folgendes umfasst: – das Senden (14) einer Anforderung des Ausführens der Funktion und des Lesens von Daten des Speichers (6) an das Gerät und – den Empfang (16) des Resultats der Funktion und des in dem Speicher gelesenen Codes des Verifizierungsprogramms durch das Gerät.
  16. Gerät nach Anspruch 15, wobei die Funktion die Berechnung des Hash-Codierens von Daten des Speichers umfasst, bei denen es sich nicht um den Code des Verifizierungsprogramms handelt.
  17. Gerät nach einem der Ansprüche 1 bis 13, wobei das Ausführen des Programms (P) zum Sättigen des verfügbaren Speichers das Lesen eines Problems von der Ein-/Ausgabevorrichtung und die Lösung des Problems umfasst, indem der verfügbare Speicher eingesetzt wird, und in dem das Austauschen von Nachrichten Folgendes umfasst: – das Senden (14) eines Problems an das Gerät und – den Empfang (16) des Resultats des Problems und des in dem Speicher gelesenen Codes des Verifizierungsprogramms durch das Gerät.
  18. Gerät nach einem der Ansprüche 1 bis 17, wobei der Code des Verifizierungsprogramms Befehle zum erneuten Lesen des Codes gegenüber der Ein-/Ausgabevorrichtung umfasst.
  19. Gerät nach einem der Ansprüche 1 bis 18, wobei das Ausführen des Verifizierungsprogramms das Löschen des Speichers, mit Ausnahme des Codes des Verifizierungsprogramms bewirkt.
  20. Computertechnisches Gerät, mit einem Prozessor (4), einem Speicher (6), den der Prozessor lesen und beschreiben kann, und einer Ein-/Ausgabevorrichtung (8), die eine Kommunikation zwischen dem Prozessor (4) des Geräts und der Außenwelt ermöglicht, wobei in dem Speicher (6) enthaltene Daten vor der Außenwelt geschützt werden, wobei die Übereinstimmung des logischen Inhalts des computertechnischen Geräts (2) mit einem Referenzinhalt in einem computertechnischen Gerät gemäß einem der Ansprüche 1 bis 19 verifiziert wird; geschützte Daten werden analysiert (34) und ggf. bearbeitet, analysierte Daten werden in den Speicher des Geräts übertragen.
  21. Computertechnisches Gerät, das einen Prozessor (4), einen Speicher (6), den der Prozessor lesen und beschreiben kann, eine Ein-/Ausgabevorrichtung (8), die eine Kommunikation zwischen dem Prozessor (4) des Geräts und der Außenwelt ermöglicht, und ein in dem Gerät gespeichertes Verifizierungsprogramm umfasst, wobei das Verifizierungsprogramm Befehle umfasst, die darauf eingerichtet sind, Folgendes zu bewirken, wenn es von dem Prozessor ausgeführt wird: – das Schreiben von Daten in den Speicher (6) des Geräts und – das Lesen von Daten in dem Speicher (6), die den Code des Verifizierungsprogramms umfassen, um diese zur Ein-/Ausgabevorrichtung (8) zu senden.
  22. Computertechnische Vorrichtung, die Folgendes umfasst: – eine erste Untereinheit, die einen Prozessor, einen Speicher, den der Prozessor lesen und beschreiben kann, und eine Ein-/Ausgabevorrichtung umfasst; – eine zweite Untereinheit, wobei die zweite Untereinheit darauf eingerichtet ist, über die Ein-/Ausgabevorrichtung mit dem Prozessor der ersten Untereinheit zu kommunizieren und die Übereinstimmung des logischen Zustands der ersten Untereinheit gemäß dem Gerät nach einem der Ansprüche 1 bis 19 zu verifizieren.
DE202006020631U 2006-03-01 2006-08-25 Computertechnisches Gerät Expired - Lifetime DE202006020631U1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP06290345A EP1830295A1 (de) 2006-03-01 2006-03-01 Verfahren zur Verifizierung der Übereinstimmung von logischem Inhalt eines computertechnischen Geräts mit einem Referenzinhalt
EP06290345 2006-03-01
EP06017741A EP1830293A1 (de) 2006-03-01 2006-08-25 Verfahren zur Verifizierung der Übereinstimmung von logischem Inhalt eines computertechnischen Geräts mit einem Referenzinhalt

Publications (1)

Publication Number Publication Date
DE202006020631U1 true DE202006020631U1 (de) 2009-04-16

Family

ID=36950413

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202006020631U Expired - Lifetime DE202006020631U1 (de) 2006-03-01 2006-08-25 Computertechnisches Gerät

Country Status (3)

Country Link
US (1) US20090260084A1 (de)
EP (2) EP1830295A1 (de)
DE (1) DE202006020631U1 (de)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9294499B2 (en) * 2008-03-31 2016-03-22 Orange Defense communication mode for an apparatus able to communicate by means of various communication services
US8732296B1 (en) * 2009-05-06 2014-05-20 Mcafee, Inc. System, method, and computer program product for redirecting IRC traffic identified utilizing a port-independent algorithm and controlling IRC based malware
US8959638B2 (en) 2011-03-29 2015-02-17 Mcafee, Inc. System and method for below-operating system trapping and securing of interdriver communication
US9032525B2 (en) 2011-03-29 2015-05-12 Mcafee, Inc. System and method for below-operating system trapping of driver filter attachment
US9087199B2 (en) 2011-03-31 2015-07-21 Mcafee, Inc. System and method for providing a secured operating system execution environment
US8925089B2 (en) 2011-03-29 2014-12-30 Mcafee, Inc. System and method for below-operating system modification of malicious code on an electronic device
US8966624B2 (en) 2011-03-31 2015-02-24 Mcafee, Inc. System and method for securing an input/output path of an application against malware with a below-operating system security agent
US8650642B2 (en) * 2011-03-31 2014-02-11 Mcafee, Inc. System and method for below-operating system protection of an operating system kernel
US8813227B2 (en) 2011-03-29 2014-08-19 Mcafee, Inc. System and method for below-operating system regulation and control of self-modifying code
US8863283B2 (en) 2011-03-31 2014-10-14 Mcafee, Inc. System and method for securing access to system calls
US9038176B2 (en) 2011-03-31 2015-05-19 Mcafee, Inc. System and method for below-operating system trapping and securing loading of code into memory
US9262246B2 (en) 2011-03-31 2016-02-16 Mcafee, Inc. System and method for securing memory and storage of an electronic device with a below-operating system security agent
US8966629B2 (en) 2011-03-31 2015-02-24 Mcafee, Inc. System and method for below-operating system trapping of driver loading and unloading
US9317690B2 (en) 2011-03-28 2016-04-19 Mcafee, Inc. System and method for firmware based anti-malware security
US8674858B2 (en) * 2011-04-11 2014-03-18 Marvell World Trade Ltd. Method for compression and real-time decompression of executable code
US8806647B1 (en) * 2011-04-25 2014-08-12 Twitter, Inc. Behavioral scanning of mobile applications
CN108490368A (zh) * 2018-07-02 2018-09-04 桂林电子科技大学 一种锂电池充放电测试装置及方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7062650B2 (en) * 2001-09-28 2006-06-13 Intel Corporation System and method for verifying integrity of system with multiple components
US8887287B2 (en) * 2004-10-27 2014-11-11 Alcatel Lucent Method and apparatus for software integrity protection using timed executable agents

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Moderately Hard, Memory-bound Functions" von Martin Abadi, Mike Burrows, Mark Manasse und Ted Wobber
"Oblivious Hashing: A Stealthy Software Integrity Verification Primitive" von Yuqun Chen, Ramarathnahm Venkatesan, Matthew Cary, Ruoming Pang, Saurabh Sinha und Mariusz H. Jakubowski, Proceedings of 5th International Workshop an Information Hiding, Noordwijkerhout, Niederlande, Oktober 2002, Lecture Notes in Computer Science, Nr. 2578, Springer-Verlag, 2003
"On Memory-Sound Functions for Fighting Spam" von Cynthia Dwork, Andrew Goldberg und Moni Naor
http://www.cis.upenn.edu/~matuszek/cit594-2002/Pages/backtrackinq/html
https://www.trustedcomputinggroup.org/home

Also Published As

Publication number Publication date
EP1830293A1 (de) 2007-09-05
US20090260084A1 (en) 2009-10-15
EP1830295A1 (de) 2007-09-05

Similar Documents

Publication Publication Date Title
DE202006020631U1 (de) Computertechnisches Gerät
EP1099197B1 (de) Vorrichtung zum liefern von ausgangsdaten als reaktion auf eingangsdaten und verfahren zum überprüfen der authentizität und verfahren zum verschlüsselten übertragen von informationen
EP2515499B1 (de) Verfahren zum Erzeugen eines kryptographischen Schlüssels für ein geschütztes digitales Datenobjekt auf Basis von aktuellen Komponenten eines Rechners
DE3700663C2 (de)
EP3388994A1 (de) Verfahren und vorrichtung zum rechnergestützten testen einer blockkette
DE102020122712A1 (de) Integritätsmanifest-zertifikat
DE112011100182T5 (de) Transaktionsprüfung für Datensicherheitsvorrichtungen
EP1410128A1 (de) Datenverarbeitungsvorrichtung
DE60224590T2 (de) Software-integritätstest bei einem mobiltelefon
EP2673731B1 (de) Verfahren zur programmierung eines mobilendgeräte-chips
EP3337085B1 (de) Nachladen kryptographischer programminstruktionen
EP3667597A1 (de) Verfahren zum bestimmen einer identität eines produkts durch erfassung eines optisch sichtbaren und eines nicht sichtbaren merkmals, sowie identifizierungssystem
EP2885907B1 (de) Verfahren zur installation von sicherheitsrelevanten anwendungen in einem sicherheitselement eines endgerät
DE102014210282A1 (de) Erzeugen eines kryptographischen Schlüssels
DE102007034527B4 (de) Verfahren und System zur Kennzeichnung einer Ware als Originalware eines Warenherstellers
EP3175577B1 (de) Verfahren zur erzeugung einer digitalen signatur
EP3373545A1 (de) Sicherheitseinheit insbesondere ein für iot-gerät und verfahren zur ausführung einer oder mehrerer applikationen zum gesicherten datenaustausch mit einem oder mehrere web-dienste bereitstellenden servern
DE102005020313A1 (de) Vorrichtung und Verfahren zur Erzeugung von Daten für eine Initialisierung von Sicherheitsdatenträgern
EP2229646B1 (de) Softwareidentifikation
DE102013006621A1 (de) Verfahren zum Bereitstellen einer Applikation auf einem Sicherheitsmodul sowie ein solches Sicherheitsmodul
DE102013108073B4 (de) Datenverarbeitungsanordnung und verfahren zur datenverarbeitung
EP1927870B1 (de) Tragbarer Datenträger
DE102018009143A1 (de) Verfahren zur Authentifizierung eines Geräts durch ein Hostsystem
EP1365363B1 (de) Verfahren zur Ausführung einer Datentransaktion mittels einer aus einer Haupt- und einer trennbaren Hilfskomponente bestehenden Transaktionsvorrichtung
DE202022106894U1 (de) System zur Verbesserung der Cybersicherheit durch Erkennung und Überwachung von Datenverfälschungen mittels Künstlicher Intelligenz

Legal Events

Date Code Title Description
R207 Utility model specification

Effective date: 20090520

R150 Utility model maintained after payment of first maintenance fee after three years

Effective date: 20090923

R151 Utility model maintained after payment of second maintenance fee after six years

Effective date: 20120913

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0021000000

Ipc: G06F0021120000

Effective date: 20130304

R152 Utility model maintained after payment of third maintenance fee after eight years
R152 Utility model maintained after payment of third maintenance fee after eight years

Effective date: 20140912

R071 Expiry of right