DE102007057900B4 - Authentifikation von verdächtigen Daten unter Verwendung von Schlüsseltabellen - Google Patents

Authentifikation von verdächtigen Daten unter Verwendung von Schlüsseltabellen Download PDF

Info

Publication number
DE102007057900B4
DE102007057900B4 DE102007057900.6A DE102007057900A DE102007057900B4 DE 102007057900 B4 DE102007057900 B4 DE 102007057900B4 DE 102007057900 A DE102007057900 A DE 102007057900A DE 102007057900 B4 DE102007057900 B4 DE 102007057900B4
Authority
DE
Germany
Prior art keywords
trusted
component
code
trusted platform
key
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.)
Active
Application number
DE102007057900.6A
Other languages
English (en)
Other versions
DE102007057900A1 (de
Inventor
David Caroll Challener
John H. Nicholson
Joseph Michael Pennisi
Rod D. Waltermann
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.)
Lenovo PC International Ltd
Original Assignee
Lenovo Singapore Pte Ltd
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 Lenovo Singapore Pte Ltd filed Critical Lenovo Singapore Pte Ltd
Publication of DE102007057900A1 publication Critical patent/DE102007057900A1/de
Application granted granted Critical
Publication of DE102007057900B4 publication Critical patent/DE102007057900B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/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
    • 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/51Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

Anordnung zur Validierung von Code, wobei die Anordnung Nachfolgendes umfasst: einen Prozessor, der einen Ausführungsraum umfasst; eine Bauteilkomponente einer vertrauenswürdigen Plattform, die Komponentenregister einer vertrauenswürdigen Plattform umfasst; ein Schlüsselpaar zur Bestätigung der Vertrauenswürdigkeit für jede Instanz von Komponenten der vertrauenswürdigen Plattform, wobei besagtes Schlüsselpaar zur Bestätigung der Vertrauenswürdigkeit jedes einen privaten Schlüssel zur Bestätigung der Vertrauenswürdigkeit und einen öffentlichen Schlüssel zur Bestätigung der Vertrauenswürdigkeit umfasst; öffentliche Schlüssel zur Validierung und verschlüsselte Hashwerte für jede Instanz von Komponenten der vertrauenswürdigen Plattform; für jede Instanz von Komponenten der vertrauenswürdigen Plattform einen Hashalgorithmus zum Erzeugen eines ersten Hashwerts zum Vergleich mit einem zweiten Hashwert, der aus verschlüsselten Hashwerten mittels des öffentlichen Schlüssels zur Validierung der jeweiligen Instanz von Komponenten der vertrauenswürdigen Plattform erzeugt wird; und einen gesicherten Speicherbereich, der mindestens eine Tabelle zum Abspeichern von Validierungssoftware umfasst.

Description

  • Die offenbarte Erfindung bezieht sich im Allgemeinen auf das Gebiet der Datensicherheit, und bezieht sich im Besonderen auf das Gebiet der Verbesserung der Sicherheitsmerkmale von Komponenten einer vertrauenswürdigen Plattform.
  • E-Commerce, e-Government und e-Business wachsen alle im Gleichschritt mit einer Zunahme der Internetkriminalität. Viele hochtechnologische Sicherheitstechnologien sind eingerichtet worden, um der wachsenden Bedrohung durch Internetkriminalität zu begegnen, aber es entwickelt sich ein Kompromiss bei der Verwendung von Sicherheitstechnologien zum Schutz von Daten und zur Authentifikation von Identitäten und Transaktionen. IT Eigentümer von Verfahren, die diese Identitäten und Transaktionen umfassen, wünschen sich, eine bestimmte Authentifikation und Verschlüsselungsalgorithmen zu verwenden, die auf ihre Risikoprofile zugeschnitten sind. Verbunden mit diesen Algorithmen wollen sie spezifische Implementierungen von Komponenten einer vertrauenswürdigen Plattform (Trusted Platform Modules – TPMs) mit festgelegten Merkmalen verwenden, um den erforderlichen Sicherheitsgrad ihrer durchgehenden Anordnungen und operativen Komponenten zu unterstützen. TPMs sind Mikrochips, ausgestaltet, um bestimmte grundlegende sicherheitsbedingte Funktionen an die Software zur Verfügung zu stellen, die vom TPM Gebrauch macht. Als eine auf Hardware basierende Sicherheitsanordnung ist ein TPM viel sicherer als ein softwarebasiertes Sicherheitsmerkmal, aber diese erhöhte Sicherheit kommt zu einem hohen Preis und normalerweise mit mehr Verwaltungsaufwand. 1 zeigt ein vereinfachtes Blockdiagramm eines grundlegenden TPM 100. Die Hardwarekomponenten des TPM 100 umfassen: eine Hardwareengine 120, eine Hashengine 140, einen Zufallszahlgenerator 160 und einen internen hardwaregeschützten Speicher 180. Gegenwärtig erfordern TPMs bestimmte kryptographische Algorithmen, wie zum Beispiel RSA SHA-1 und HMAC (Hash function based Message Authentication Code). RSA wurde von R. L. Rivest, A. Shamir und L. M. Adleman entwickelt. SHA-1 ist ein Standard für einen sicheren Hashalgorithmus.
  • Trusted Computing GroupTM „Trusted Platform Modules Strengthen User and Platform Authenticity” (Januar 2005) offenbart TPMs als Special-Purpose Integrierte Schaltungen, die in einer Vielzahl von Plattformen eingesetzt werden können, um Benutzer- und Maschinenauthentifizierung zu stärken, was wesentlich ist, um unerlaubten Zugriff auf vertrauliche Informationen, auch durch kompromittierte Netzwerke, zu unterbinden. Durch TPMs können Schlüssel, die für kryptographische Algorithmen benötigt werden, in hardwaregeschützten Speicherbereichen gespeichert werden, im Gegensatz zu ansonsten lediglich durch softwarebasierte Verschlüsselung geschützten Speicherbereichen.
  • In 2 wird dort ein TPM Softwarestack gezeigt. Auf der untersten Ebene befindet sich das TPM Hardwarebauelement 210, das ein Chip ist, der sich normalerweise auf einem Motherboard befindet. Auf das TPM wird über eine TPM Bauelementtreiberbibliothek 220 zugegriffen. Anwendungen verwenden das TPM durch Standardschnittstellen oder durch direktes Durchführen der Kommunikation mit dem ISS 230. Das ISS 230 ist der TCPA (Trusted Computing Platform Alliance) Software Stack, der die unterstützende Funktionalität für das TPM zur Verfügung stellt. Die nächst höhere Ebene ist der Kryptographiedienstanbieter 240, wie zum Beispiel das CAPI von Microsoft®. Auf der höchsten Ebene befinden sich die Anwendungen 250, die das TPM 210 verwenden.
  • Die Druckschrift US 2006/0005015 A1 offenbart ein Verfahren zur Aufrechterhaltung der Vertrauenswürdigkeit bzw. Integrität von sensibler Kommunikation von einem Ursprungsprogramm zu seinem Zielprogramm innerhalb einer Plattform, zwischen Plattformen, oder dem gleichen Programm das von Zeit zu Zeit aufgerufen wird. Dazu wird ein Mechanismus offenbart um das der Verschlüsselung zu Grunde liegende Datenmaterial in einem versteckten Prozessormodus zu sichern. Dabei werden Ring 0 Programme verwendet um die Kommunikation mit den Plattformkomponenten zu sichern und Authentifizierungsprozesse fälschungssicher zu machen. Außerdem kann durch den offenbarten Mechanismus der innere Zustand eines Programms zu jeder Aufrufzeit verifiziert werden.
  • Die Druckschrift US 2005/0138393 A1 offenbart ein Verfahren bei dem gesicherte Hardware benutzt wird, um den Zugriff auf kryptographische Schlüssel zu kontrollieren. Zugriff zu den kryptographischen Schlüsseln wird nur gewährt, wenn ein entsprechender Wert in einem Special Purpose Register der Hardware gefunden wird. Das Special Purpose Register ist in Verbindung mit der Hardware fähig den Systemstatus zu verifizieren. Der Wert, der in dem Register gespeichert wird, ist eine Funktion einer Benutzeridentifikationsmetrik, wie in etwa einem Passwort, biometrischen Daten, oder andere Sicherheitsmerkmale, die zur Verifikation der Benutzeridentität benutzt werden können. Die Benutzeridentifikationsmetrik kann dabei genutzt werden, um eine Tabelle zu indizieren, die speziellen Werten der Metrik einen Sicherheitswert zuweist, der benutzt werden kann um den Inhalt des Registers zu beeinflussen. Zugang zu den kryptographischen Schlüsseln wird nur gewährt, wenn das Special Purpose Register einen entsprechenden Wert trägt.
  • Der typische Ansatz, verschiedene Algorithmen und TPMs zu implementieren, wie er in allein stehenden oder integrierten Hardwarebauelementen ausgeliefert wird, lässt die Sicherheitskosten ansteigen. Was erforderlich ist, ist ein flexibler, dennoch sicherer Ansatz, der einen sicher programmierbaren Mikrocontroller verwendet, um verschiedene auswählbare Authentifikations- und Verschlüsselungsalgorithmen zu unterstützen, und diese auch mit der Emulation von unterschiedlichen Instanzen der TPM Hardware zu verwenden. Wenn Ausführungscode in einen programmierbaren Mikrocontroller für verschiedene Operationen aus einem Cachespeicher geladen und entladen wird, kann die Integrität einer bestimmten Sicherheitsoperation nicht jedes Mal validiert werden, wenn diese verwendet wird. Massenverschlüsselung (oder Blockverschlüsselung) ist eine Lösung für dieses Problem, aber sie wird als zu langsam erachtet.
  • Deshalb gibt es einen Bedarf an einer Sicherheitsanordnung, die die Mängel nach dem Stand der Technik überwindet.
  • Kurz gesagt umfasst ein Verfahren zur Authentifikation von verdächtigem Code entsprechend einer Ausführungsform der Erfindung die Schritte oder Aktionen: Empfangen des verdächtigen Codes für eine erste Instanz einer Komponente einer vertrauenswürdigen Plattform; Laden des verdächtigen Codes in eine funktionsfähig mit einem Prozessor verknüpfte Bauteilkomponente einer vertrauenswürdigen Plattform, wobei der verdächtige Code außerhalb eines geschützten Speicherbereichs innerhalb der Bauteilkomponente der vertrauenswürdigen Plattform geladen wird; Abrufen eines öffentlichen Schlüssels zur Validierung aus einer ersten Tabelle und Speichern von diesem in einem indizierten Register in der Bauteilkomponente der vertrauenswürdigen Plattform, wobei der öffentliche Schlüssel zur Validierung durch den verdächtigen Code indiziert wird; und Abrufen eines Hashalgorithmus aus einer Tabelle, wobei der Hashalgorithmus durch den verdächtigen Code indiziert wird. Das Verfahren fährt weiterhin fort durch: Ausführen des mit dem verdächtigen Code verknüpften Hashalgorithmus, um einen ersten Hashwert abzuleiten; Entschlüsseln, unter Verwendung des öffentlichen Schlüssels zur Validierung, eines zweiten in der Tabelle gespeicherten verschlüsselten Hashwerts, um einen zweiten Hashwert abzuleiten, wobei der zweite Hashwert durch den verdächtigen Code indiziert wird; Vergleichen des zweiten entschlüsselten Hashwerts mit dem ersten Hashwert, um zu bestimmen, ob sie gleich sind; und beim Feststellen, dass die ersten und zweiten Hashwerte gleich sind, Laden des verdächtigen Codes in den geschützten Bereich des Prozessors zur Ausführung durch den Prozessor.
  • Das Verfahren umfasst weiterhin die Schritte oder Aktionen: Abrufen eines privaten Schlüssels zur Bestätigung der Vertrauenswürdigkeit; Speichern des privaten Schlüssels zur Bestätigung der Vertrauenswürdigkeit in einem Register innerhalb der Bauteilkomponente der vertrauenswürdigen Plattform; und das Ausführen des verdächtigen Codes aus dem Ausführungsraum.
  • Eine Anordnung zur Validierung des Codes entsprechend einer Ausführungsform der vorliegenden Erfindung umfasst die folgenden Bauelemente für das Ausführen der obigen Verfahrensschritte: einen Prozessor einschließlich eines Ausführungsraums; eine Bauteilkomponente einer vertrauenswürdigen Plattform, die Komponentenregister einer vertrauenswürdigen Plattform umfasst; ein Schlüsselpaar zur Bestätigung der Vertrauenswürdigkeit für jede Instanz von Komponenten einer vertrauenswürdigen Plattform, wobei der Schlüssel zur Bestätigung der Vertrauenswürdigkeit einen privaten Schlüssel zur Bestätigung der Vertrauenswürdigkeit und einen öffentlichen Schlüssels zur Bestätigung der Vertrauenswürdigkeit umfasst; öffentliche Schlüssel zur Validierung und verschlüsselte Hashwerte für jede Instanz der Komponenten einer vertrauenswürdigen Plattform; einen gesicherten Speicherbereich einschließlich mindestens einer Tabelle zur Abspeicherung von Validierungssoftware. Die Anordnung umfasst weiterhin: eine Eingabe-/Ausgabe-Schnittstelle, einen Datenspeicher der Anordnung und ein Massenspeichergerät.
  • Entsprechend einer weiteren Ausführungsform der vorliegenden Erfindung umfasst ein computerlesbares Medium Software zum Ausführen der obigen Verfahrensschritte.
  • Um die vorhergehenden und anderen beispielhaften Zwecke, Aspekte und Vorteile zu beschreiben, verwenden wir die folgende detaillierte Beschreibung einer beispielhaften Ausführungsform der Erfindung mit Bezug auf die Figuren, in denen:
  • 1 ein vereinfachtes Blockdiagramm einer typischen Komponente einer vertrauenswürdigen Plattform entsprechend dem Stand der Technik ist.
  • 2 ein vereinfachtes Blockdiagramm eines Softwarestacks einer Komponente einer vertrauenswürdigen Plattform entsprechend dem Stand der Technik ist.
  • 3 ein Blockdiagramm eines Informationsverarbeitungssystems auf höchster Ebene ist, das gestaltet ist, um entsprechend einer Ausführungsform der Erfindung zu arbeiten.
  • 4 ein Ablaufdiagramm eines Verfahrens entsprechend einer Ausführungsform der Erfindung ist.
  • 5 ein vereinfachtes Diagramm einer Tabelle von Schlüsseln entsprechend einer Ausführungsform der vorliegenden Erfindung ist.
  • 6 ein vereinfachtes Diagramm einer weiteren Tabelle von Schlüsseln entsprechend einer Ausführungsform der vorliegenden Erfindung ist.
  • 7 ein vereinfachtes Blockdiagramm einer weiteren Konfiguration des Informationsverarbeitungssystems gemäß 3 entsprechend einer weiteren Ausführungsform der vorliegenden Erfindung ist.
  • 8 ein vereinfachtes Blockdiagramm einer Tabelle von Schlüsseln ist, die sowohl die Schlüssel zur Bestätigung der Vertrauenswürdigkeit als auch den öffentlichen Schlüssel zur Validierung entsprechend einer weiteren Ausführungsform der vorliegenden Erfindung in einer Tabelle zeigt.
  • 9 ein vereinfachtes Blockdiagramm einer noch weiteren Konfiguration des Informationsverarbeitungssystems gemäß 3 entsprechend einer weiteren Ausführungsform der vorliegenden Erfindung ist.
  • 10 ein vereinfachtes Diagramm einer Tabelle von Schlüsseln mit dem Emulationscode entsprechend einer weiteren Ausführungsform der vorliegenden Erfindung ist, wobei sich der öffentlichen Schlüssel zur Validierung und die Schlüssel zur Bestätigung der Vertrauenswürdigkeit zusammen in einer Tabelle befinden.
  • Während die Erfindung, so wie sie beansprucht wird, in alternative Ausführungsformen abgeändert werden kann, werden bestimmte Ausführungsformen von dieser auf dem Weg des Beispiels in den Figuren gezeigt und werden hierin im Detail beschrieben. Es sollte jedoch verstanden werden, dass die Figuren und die detaillierte Beschreibung zu diesen nicht beabsichtigt sind, um die Erfindung auf die bestimmte offenbarte Form zu beschränken, sondern im Gegenteil dazu es die Absicht ist, alle Abänderungen, Äquivalente und Alternativen abzudecken, die innerhalb des Schutzumfangs der vorliegenden Erfindung fallen.
  • Wir beschreiben ein flexibles, aber sicheres Verfahren dafür, einen programmierbaren Mikrocontroller zu verwenden, um verschiedene auswählbare Authentifikations- und Verschlüsselungsalgorithmen zu unterstützen und diese auch mit der Emulation von unterschiedlichen Instanzen der TPM Hardware zu verwenden. Dies wird durch die neuartige Verwendung von Tabellen aus Schlüsseln erreicht, die durch den Emulationscode indiziert werden.
  • Was folgt ist ein Glossar von Bezeichnungen (aus ”TCG Glossary of Technical Terms”) das auf jede Beschreibung bezüglich TPMs anwendbar ist:
    Schlüssel zur Bestätigung der Vertrauenswürdigkeit (Endorsement Key) – EK; ein RSA Schlüsselpaar bestehend aus einem öffentlicher (EKpu) und einem privaten (EKpr) Schlüssel (Public Key und Private Key). Der EK wird verwendet, um ein authentisches TPM zu erkennen. Der EK wird verwendet, um eine in den Privacy CA und den DAA Protokollen an das TPM geschickte Information zu entschlüsseln, und während der Installation eines Eigentümers im TPM.
  • Endorsement Key Credential – ein Berechtigungsnachweis, der das EKpu enthält, das bestätigt, dass der Halter des EKprs ein TPM entsprechend der TCG Spezifikation ist. Die meisten TPMs sind in Hardware ausgeführt, dies ist aber nicht obligatorisch.
  • Nichtflüchtig (Shielded Location) – ein geschützter Speicherplatz (Shielded Location), für dessen Inhalt garantiert wird, dass dieser zwischen Verwendungen durch Protected Capabilities erhalten bleibt.
  • Platform – eine Plattform ist eine Sammlung von Ressourcen, die einen Dienst zur Verfügung stellt.
  • Protected Capabilities – der Satz von Befehlen mit exklusiver Erlaubnis dafür, auf Shielded Locations zuzugreifen.
  • Root Of Trust (Bauelement) – ein Bauelement, das sich immer auf die erwartete Art verhalten muss, weil sein nicht konformes Verhalten nicht wahrgenommen werden kann. Der vollständige Satz von Roots Of Trust ist mindestens der Minimalsatz von Funktionen, um eine Beschreibung der Plattformmerkmale zu ermöglichen, die die Vertrauenswürdigkeit der Plattform beeinflussen.
  • RSA – ein kryptographischer Algorithmus, der die Nachnamensinitialen seiner Entwickler, R. L. Rivest, A. Shamir und L. M. Adleman trägt.
  • RTS – ”Root of Trust for Storage” – eine EDV-Maschine, die dazu fähig ist, eine genaue Zusammenfassung von Werten von Integritätsextrakten und die Abfolge von Extrakten aufrecht zu erhalten.
  • RTR – ”Root of Trust for Reporting” – eine EDV-Maschine, die dazu fähig ist, zuverlässig die Information auszuweisen, die von der RTS gehalten wird.
  • SHA-1 – ein Standard für sichere Hashalgorithmen.
  • Shielded Location – eine Stelle (Datenspeicher, Register, usw.), an der es sicher ist, mit sensitiven Daten zu arbeiten; Datenorte, auf die nur durch ”Protected Capabilities” zugegriffen werden kann.
  • Vertrauenswürdigkeit ist die Erwartung, dass sich ein Bauelement für einen bestimmten Zweck auf eine bestimmte Weise verhält.
  • Eine Trusted Computing Platform ist eine Berechnungsplattform, der vertraut werden kann, dass sie ihre Eigenschaften berichtet.
  • TPM – Trusted Platform Module (Komponente einer vertrauenswürdigen Plattform) – eine Implementierung der in der TCG Trusted Platform Module Specification definierten Funktionen; der Satz von Roots Of Trust mit Shielded Locations und Protected Capabilities umfasst normalerweise nur die RTS und die RTR.
  • TSS – Trusted Software Stack (vertrauenswürdiger Softwarestack) – Softwaredienste, die die Verwendung des TPM erleichtern, aber nicht den Schutz erfordern, der für den TPM geleistet wird.
  • Die Anordnung.
  • Sich jetzt im spezifischen Detail auf die Zeichnungen und besonders die 3 beziehend wird ein vereinfachtes Blockdiagramm eines Informationsverarbeitungssystems 300 veranschaulicht, das eingerichtet ist, um entsprechend einer Ausführungsform der Erfindung bedient zu werden.
  • Gemäß 3 umfasst die Informationshandhabungsanordnung 300: einen Prozessor 302, einen TPM Chip 309, einen Anordnungsdatenspeicher 304 und ein Ein-/Ausgabe-(I/O)Subsystem 306. Ein Speichermedium wie ein CDROM 305 ist funktionsfähig mit dem I/O Subsystem 306 verknüpft. Der Prozessor 302 und Bauelemente des Anordnungsdatenspeichers 304 können physisch verknüpft oder funktionsfähig zusammengeschaltet sein. Der TPM Chip 309 kann gesondert vom Prozessor 302 angeordnet sein, oder er kann Teil des Prozessors 302 sein, der ein Kernchipset umfasst. Der Prozessor 302 kann ein Mikroprozessor sein. Der Prozessor 302 umfasst eine Mikroprozessor-CPU 350 und einen Ausführungsraum 322. Der Ausführungsraum 322 ist ein sicherer Bereich, in dem die Daten unabhängig von ihrer Ausführungsform gegen Störung und Neugier geschützt sind. Er wird als eine Shielded Location betrachtet. Nur verifizierter Code wird in den Ausführungsraum 322 geladen.
  • Sicherer Datenspeicher 312 befindet sich im Allgemeinen innerhalb des TPM Chips 309. Der sichere Datenspeicher 312 enthält auch eingebettete Anweisungen in der Form von Mikrocode. Systemspeicher 308 ist ebenfalls außerhalb der Shielded Location verfügbar. TPM Emulationscode 314 kann innerhalb des Mikroprozessors 302 oder im Systemspeicher 308 abgespeichert werden, wie in 3 dargestellt.
  • Der TPM Chip 309 ist entsprechend einer Ausführungsform der vorliegenden Erfindung ein generischer TPM Chip, der unter Verwendung des TPM Emulationscodes 314 unterschiedliche TPMs emulieren kann. Der Emulationscode 314 ermöglicht dem Mikroprozessor 302, jede beliebige Komponente einer vertrauenswürdigen Plattform zu simulieren, und ermöglicht es auf diese Weise, dass ein relativ preisgünstiger generischer TPM Chip mit einem breiten Bereich von Plattformen arbeitet. Dies ist wichtig, weil TPMs sich von Organisation zu Organisation unterscheiden können, und es gibt viele unterschiedliche verfügbare Formate. Zum Beispiel verwendet die Regierung der Vereinigten Staaten eine Art von TPM, und die chinesische Regierung verwendet eine andere Art. TPM Emulationscode ist in der Industrie bekannt. Die Herausforderung besteht darin, den Emulationscode 314 zu schützen, so dass ein nicht vertrauenswürdiger Code nie ausgeführt wird. Dieses Verfahren wird in der Beschreibung bezüglich 4 weiter unten erläutert.
  • Gemäß 3 ist eine Tabelle 332 aus Hashwerten innerhalb des gesicherten Speicherbereichs 312 abgespeichert und wirkt als Nachschlagetabelle. Dieser gesicherte Speicherbereich 312 befindet sich, wie in 3 gezeigt, im Allgemeinen im TPM Chip 309; er könnte jedoch an anderer Stelle abgespeichert werden, etwa im Prozessor 302. Die Werte in der Tabelle 332 werden, wie in 5 gezeigt, vom TPM Code 314 indiziert. Außerdem hält eine weitere Tabelle 342 alle für jedes TPM erzeugte Schlüssel zur Bestätigung der Vertrauenswürdigkeit. Eine zweite Tabelle, die Tabelle 342, wird auch als innerhalb des TPM Chips 309 abgespeichert gezeigt, sie kann aber, um Platz zu sparen, außerhalb des sicheren Bereichs 312 abgespeichert werden, wie in 3 gezeigt. Es ist anzumerken, dass die zwei Tabellen 332 und 342 in 3 veranschaulicht sind. Dies ist lediglich deshalb so, um eine Ausführungsform zu veranschaulichen; die tatsächliche Konfiguration und die Anzahl von Tabellen können jedoch in Abhängigkeit von der abgespeicherten Information, der Hardwarekonfiguration und den individuellen Platzbeschränkungen der Anordnung entsprechend der vorliegenden Erfindung variieren.
  • Entweder zum Herstellungs- oder Installationszeitpunkt wird für jede Instanz des Ausführungscodes ein Hashwert für ein TPM erzeugt. Normalerweise wird dies vom Informationstechnologie-(IT)Eigentümer ausgeführt. Für jede Plattform gibt es eine bekannte Liste von unterstützten TPMs. Jedes der unterstützten TPMs weist seinen eigenen zugehörigen Hashwert auf. Jeder Hashwert (Hash) ist mit dem Schlüssel zur Bestätigung der Vertrauenswürdigkeit (EK) für dieses bestimmte TPM verknüpft. Ein Schlüssel zur Bestätigung der Vertrauenswürdigkeit ist ein kryptographisches Schlüsselpaar, das den RSA Algorithmus verwendet. Zusätzlich zu diesem Schlüsselpaar wird auch ein öffentlicher Schlüssel erzeugt, der die Signatur enthält, mit der der TPM Emulationscode signiert wurde. Dieser öffentliche Schlüssel, der öffentlichen Schlüssel zur Validierung (PK), ist in Tabelle 332 gespeichert. Nur die Hashtabelle 332 muss, um Platz zu sparen, in sicherem Speicher gespeichert werden. Gleichzeitig wird auch ein Hashwert für jeden der Verschlüsselungsalgorithmen für das TPM erzeugt. Der tatsächliche TPM Emulationscode 314 und der Verschlüsselungsalgorithmencode und der entsprechende öffentliche Schlüssel des Verschlüsselungscodes können unverschlüsselt im Systemspeicher 308 abgespeichert werden, um Platz innerhalb des Mikroprozessors 302 zu sparen. Der private Schlüssel des EK (EKprs) kann jedoch nicht im Systemspeicher 308 gespeichert werden.
  • Gemäß 5 speichert die Tabelle 332 auch die signierten Hashwerte (Hashes) ab, die mit dem EK und den öffentlichen Schlüsseln zur Validierung (PK) verknüpft sind. Die Tabelle 332 speichert außerdem den Hashalgorithmus (Alg) für jeden TPM Code ab. Alle diese Werte werden durch den TPM Code indiziert. In dieser Ausführungsform enthält die erste Spalte der Tabelle 332 im Besonderen einen eindeutigen Kennzeichner, der mit dem TPM Code verknüpft ist. Andere Ausführungsformen können die Schlüssel ein wenig unterschiedlich indizieren, bleiben jedoch innerhalb des Schutzumfangs der vorliegenden Erfindung.
  • In 7 wird eine alternative Konfiguration für das Informationsverarbeitungssystem 300 gemäß 3 gezeigt. Die Anordnung 700 zeigt nur eine Tabelle 352, die sich in sicherem Speicher 312 innerhalb des TPM Chips 309 befindet. Diese Tabelle 352 wird in 8 gezeigt. Es ist zu beachten, dass im Gegensatz zu der Tabelle gemäß 5, die Tabelle 352 die öffentlichen Schlüssel zur Validierung (PK), die Hashalgorithmen, die Hashwerte und die Schlüssel zur Bestätigung der Vertrauenswürdigkeit enthält.
  • Eine weitere Ausführungsform innerhalb des Schutzumfangs der vorliegenden Erfindung wird im Blockdiagramm gemäß 9 gezeigt. Das Informationsverarbeitungssystem 900 zeigt wieder nur einer Tabelle 362, die sich in sicherem Speicher 312 befindet. Diese Tabelle 362 hält jedoch im Gegensatz zu Tabelle 352 gemäß 7 die TPM Codes, wie auch die Schlüssel zur Bestätigung der Vertrauenswürdigkeit, die öffentlichen Schlüssel zur Validierung und die Hashinformation. Diese Tabelle 362 wird in 10 gezeigt. Es ist anzumerken, dass der Emulationscode 314 Firmware der Anordnung ist. Andere Konfigurationen von Tabellen und Schlüsseln sind innerhalb des Geists und des Schutzumfangs der vorliegenden Erfindung möglich.
  • Das Verfahren.
  • Das Codevalidierungverfahren validiert entsprechend einer Ausführungsform der vorliegenden Erfindung TPM Emulationscode, ohne seinen eigenen internen Code offen zu legen. Dies ist so, weil die Authentifikation durch die Verwendung von Tabellen und ihre indizierten Werte vor dem Laden des Emulationscodes in den Mikrocontrollerausführungsraum 322 ausgeführt wird. Es wird angenommen, dass hardwareresidente Sicherheitsmaßnahmen die zuverlässigsten sind, und es wird deshalb bevorzugt, so viel Information wie möglich in dem Mikroprozessor und/oder dem Chipset fest zu verdrahten. Platzbedarf wird dabei ein Thema; deshalb muss eine Entscheidung darüber getroffen werden, welche der Informationen fest verdrahtet wird, und was an anderer Stelle abgespeichert werden kann. Die Flexibilität dieses Codevalidierungsverfahrens ermöglicht, dass der TPM Emulationscode 314 auch entweder innerhalb des Mikroprozessors 302 oder außerhalb des Mikroprozessors 302 abgespeichert wird. In diesem Beispiel für 3 wird der Code 314 im Systemspeicher 308 außerhalb des Mikroprozessors 302 abgespeichert. Das hier weiter unten beschriebene Authentifizierungsverfahren gewährleistet die Gültigkeit des Codes, bevor er ausgeführt wird, obwohl er außerhalb eines geschützten Speicherbereichs abgespeichert worden ist. Das Authentifizierungsverfahren ist dazu in der Lage, leicht einen Code zu identifizieren, der verfälscht worden ist.
  • In 4 wird ein Ablaufdiagramm 400 des Codevalidierungsverfahrens entsprechend einer Ausführungsform der vorliegenden Erfindung gezeigt. Das Verfahren beginnt bei Schritt 410, wenn ein Anwender einen TPM Code wählt, um diesen aus dem zuvor geladenen Satz des Emulationscodes 314 im Systemspeicher 308 auszuführen. Der Anwender interagiert mit der Anordnung 300 durch das Ein-/Ausgabesubsystem 306. Der Anwender wählt einen TPM Code aus den verschiedenen verfügbaren TPM Codes aus. Diese Codes sind im Allgemeinen im Systemspeicher, nicht im TPM Chip 309 gespeichert. Der TPM Code, den der Anwender auswählt, ist Code, den der Anwender als einen TPM Emulator ausführen will (der im Folgenden als ”verdächtiger Code” bezeichnet wird). Der Anwender möchte diesen verdächtigen Code laden, so dass er ausgeführt werden kann. Damit er ausgeführt wird, muss es in den Ausführungsraum 322 geladen werden. Wenn er aus dem Ausführungsraum 322 ausgeführt wird, simuliert dieser Emulationscode welches TPM auch immer der Anwender ausgewählt hat.
  • Unter der Annahme, dass der Anwender TPM Code für TPM4 ausgewählt hat, muss der Prozessor 302 die Systemidentität dieses verdächtigen Codes, TPM Code4, bestätigen. Dies bedeutet, dass TPM4 ein ”vertrauenswürdiges” TPM sein muss, und TPM Code4 unverändert geblieben sein muss, da er in die Anordnung 300 geladen wurde. Um dieses zu tun, lädt der Mikroprozessor 302 in Schritt 420 den verdächtigen Code in den TPM Chip 309 und lädt in Schritt 430 den öffentlichen Schlüssel zur Validierung, der verwendet wurde um den TPM Code4 zu signieren, in das Hauptregister 319 des Chips. Dieser öffentliche Schlüssel zur Validierung ist PK4 aus der in 5 gezeigten Tabelle 332. Der TPM Code4 wird in den Datenspeicher 350 innerhalb des TPM 309 geladen. Es ist zu beachten, dass, obwohl der verdächtige Code in das TPM 309 geladen worden ist, dieser nicht in den Ausführungsraum 322 gebracht worden ist, weil er nicht verifiziert worden ist.
  • Als Nächstes verwendet der TPM Chip 309 in Schritt 440 den verdächtigen Code, TPM Code4, als Index, um seinen entsprechenden Hashalgorithmus, A1g4, aus der Tabelle 332 abzurufen. Der Chip 309 führt A1g4 aus, um einen ersten Hashwerte zu berechnen. Dabei ist zu bedenken, dass jede Instanz des TPM Codes mit ihrem eigenen Hashalgorithmus verknüpft ist und Schlüssel, die benötigt werden, um die Algorithmen zu entschlüsseln, im Speicher 308 der Anordnung frei zugänglich sind. Als Nächstes entschlüsselt der TPM Chip 309 in Schritt 450 unter Verwendung des öffentlichen Schlüssels zur Validierung, PK4, der mit dem TPM Code4 verknüpft ist, den Hashwert, Hash4, der den A1g4 (aus Tabelle 332) betrifft. Dies stellt einen zweiten Hashwert zur Verfügung. Diese zwei Hashwerte, der erste in Schritt 440 berechnete Hashwert und der in Schritt 450 entschlüsselte zweite Hashwert, sollten identisch sein. Wenn sie identisch sind, bestätigt dies, dass der TPM Code4 unverändert ist, und dieser nicht verfälscht oder auf irgendeine Weise modifiziert worden ist, seit er in die Anordnung 300 geladen wurde. Dieser Prüfungsschritt ist das, was es ermöglicht, die unterschiedlichen Emulationscodes 314 außerhalb der relativen Sicherheit des Chips 309 zu halten.
  • In Schritt 460 werden die ersten und zweiten Hashwerte durch den Chip 309 verglichen. Wenn die Werte übereinstimmen (der Vergleichscode ein ”wahr” Ergebnis zurückgibt), zeigt dies an, dass der TPM Code4 überprüft worden ist, und er wird als unverändert und vertrauenswürdig angenommen.
  • Als Nächstes wird in Schritt 470 ein optionaler Schritt ausgeführt, um sicherzustellen, dass der Anwender dazu bevollmächtigt ist, den TPM Code4 auszuführen. Nach der Bestätigung wird der verdächtige Code in Schritt 480 in den Ausführungsraum 322 des Mikrocontrollers geladen, so dass er ausgeführt werden kann.
  • In Schritt 485 wird eine Überprüfung ausgeführt, um zu bestimmen, ob dies das erste Mal ist, dass dieser TPM Code4 ausgeführt worden ist. Wenn ja, dann erzeugt der TPM Chip 309 in Schritt 490 einen EK Paar für diesen Code, EK4. Jedes TPM erzeugt sein eigenes EK, das bei seiner Initialisierung eine privaten Schlüsselteilbereich (EKpr) und einen öffentlichen Schlüsselteilbereich (EKpu) umfasst. Dieses Schlüsselpaar wird entsprechend einer Ausführungsform der Erfindung in Tabelle 342 gespeichert.
  • Gemäß 6 enthält Tabelle 342, indiziert durch den TPM Code, das EK für jede Instanz des in die Anordnung 300 geladenen TPM Codes. Der EKpu von EK4 kann anderen Personen gegeben werden, so dass sie sicherstellen können, dass ein Dokument durch den privaten Schlüssel EKpr signiert wurde. Der EKpr wird nicht ausgeteilt.
  • In Schritt 495 wird zum Zeitpunkt, zu dem dieser TPM Code4 in den Ausführungsraum 322 geladen wird, der mit diesem verknüpfte private Schlüssel, EKpr4, aus der Tabelle 342 in das Hauptregister des TPM 319 geladen. Die Register 319 speichern nur die im Moment erforderlichen Schlüssel. Wenn ein neuer TPM Emulator in die Register geladen wird, werden die Schlüssel ersetzt. Dies wird getan, damit ein Anwender die Möglichkeit hat, aus Sicherheitsgründen ein geheimes Paar aus privatem/öffentlichem Schlüssel zu erzeugen. Es ist wichtig zu beachten, dass ein Anwender den Hashalgorithmus nicht kennen kann, der verwendet wird, um das Schlüsselpaar zu erzeugen; deshalb braucht der Anwender dieses Schlüsselpaar, um in der Lage zu sein, den geladenen Code des Anwenders zu signieren und zu validieren. Es gibt einen Prozess, um die privaten Schlüssel zu migrieren/zu sichern. Dieses Verfahren beinhaltet, den privaten Schlüssel während des Exportprozesses zu verschlüsseln, und ist jenen mit Kenntnis in der Technik bekannt. Schließlich führt das TPM in Schritt 497 den Code, TPM Code4, aus dem Ausführungsraum 322 aus, nachdem die EK4 Schlüssel geladen und abgespeichert worden sind.
  • Wenn die Werte des Hashwertvergleichs in Schritt 460 nicht übereinstimmen, wird der Emulationscode 314 nicht in den Ausführungsraum 322 bewegt, deshalb kann er nicht ausgeführt werden, und der Prozess wird beendet. Jeglicher Code, der sich gegenwärtig im Ausführungsraum 322 befindet, ist im Verlauf der gesamten Operation auf keine Weise in seiner Sicherheit verletzt worden. Durch das ausschließliche Sichern des öffentlichen Schlüssels zur Validierung (PKs) und der Hashwerte in sicherem Speicher 322, reduziert dieses Verfahren den erforderlichen Platzbedarf, während es immer noch Sicherheit zur Verfügung stellt. Die PKs und die Hashalgorithmen können in einen weniger sicheren Speicherplatz ausgelagert werden, um Platz zu sparen. Dies ist besonders wichtig auf Grund der physischen Platzbeschränkungen, die durch die wachsende Anzahl von Schlüsseln erzwungenen werden, die berücksichtigt werden müssen.
  • Deshalb wird es, während beschrieben worden ist, was gegenwärtig als die bevorzugten Ausführungsformen angenommen wird, von jenen, die in der Technik ausgebildet sind, verstanden werden, dass andere Abänderungen innerhalb des Geists der Erfindung ausgeführt werden können.

Claims (20)

  1. Anordnung zur Validierung von Code, wobei die Anordnung Nachfolgendes umfasst: einen Prozessor, der einen Ausführungsraum umfasst; eine Bauteilkomponente einer vertrauenswürdigen Plattform, die Komponentenregister einer vertrauenswürdigen Plattform umfasst; ein Schlüsselpaar zur Bestätigung der Vertrauenswürdigkeit für jede Instanz von Komponenten der vertrauenswürdigen Plattform, wobei besagtes Schlüsselpaar zur Bestätigung der Vertrauenswürdigkeit jedes einen privaten Schlüssel zur Bestätigung der Vertrauenswürdigkeit und einen öffentlichen Schlüssel zur Bestätigung der Vertrauenswürdigkeit umfasst; öffentliche Schlüssel zur Validierung und verschlüsselte Hashwerte für jede Instanz von Komponenten der vertrauenswürdigen Plattform; für jede Instanz von Komponenten der vertrauenswürdigen Plattform einen Hashalgorithmus zum Erzeugen eines ersten Hashwerts zum Vergleich mit einem zweiten Hashwert, der aus verschlüsselten Hashwerten mittels des öffentlichen Schlüssels zur Validierung der jeweiligen Instanz von Komponenten der vertrauenswürdigen Plattform erzeugt wird; und einen gesicherten Speicherbereich, der mindestens eine Tabelle zum Abspeichern von Validierungssoftware umfasst.
  2. Anordnung gemäß Anspruch 1, wobei der Code Emulationscode einer Komponente der vertrauenswürdigen Plattform ist, und die öffentlichen Schlüssel zur Validierung und die verschlüsselten Hashwerte durch besagten Emulationscode der Komponente der vertrauenswürdigen Plattform indiziert werden.
  3. Anordnung gemäß Anspruch 2, wobei die mindestens eine Tabelle erste und zweite Tabellen umfasst, wobei die erste Tabelle die öffentlichen Schlüssel zur Validierung und die verschlüsselten Hashwerte und die zweite Tabelle die Schlüsselpaare zur Bestätigung der Vertrauenswürdigkeit umfasst.
  4. Anordnung gemäß Anspruch 3, wobei die erste Tabelle weiterhin umfasst: Hashalgorithmen, verknüpft mit den öffentlichen Schlüsseln zur Validierung und den verschlüsselten Hashwerten.
  5. Anordnung gemäß Anspruch 4, wobei die erste Tabelle weiterhin umfasst: Emulationscode der Komponente der vertrauenswürdigen Plattform und einen Schlüssel zur Bestätigung der Vertrauenswürdigkeit, verknüpft mit einem Emulationscodeverschlüsselungsalgorithmus.
  6. Anordnung gemäß Anspruch 3, wobei die zweite Tabelle weiterhin umfasst: den Emulationscode der Komponente der vertrauenswürdigen Plattform.
  7. Anordnung gemäß Anspruch 4, wobei die erste Tabelle weiterhin umfasst: das Schlüsselpaar zur Bestätigung der Vertrauenswürdigkeit.
  8. Anordnung gemäß Anspruch 1, wobei die Hashalgorithmen in einem nicht verschlüsselten Speicher der Anordnung gespeichert sind.
  9. Anordnung gemäß Anspruch 2, wobei die privaten Schlüssel zur Bestätigung der Vertrauenswürdigkeit in den Komponentenregistern der vertrauenswürdigen Plattform gespeichert sind.
  10. Anordnung gemäß Anspruch 1, wobei sich der gesicherte Speicherbereich in der Bauteilkomponente der vertrauenswürdigen Plattform befindet.
  11. Anordnung gemäß Anspruch 10, wobei die mindestens eine Tabelle im gesicherten Speicherbereich Firmware zur Validierung umfasst.
  12. Anordnung gemäß Anspruch 1, weiterhin umfassend: außerhalb des Prozessors und der Bauteilkomponente der vertrauenswürdigen Plattform angeordneten Speicher der Anordnung, wobei besagter Speicher der Anordnung mindestens eine Tabelle zum Abspeichern der Validierungssoftware umfasst.
  13. Verfahren zur Authentifikation von verdächtigem Code, das die Schritte umfasst: a) Empfangen des verdächtigen Codes für eine erste Instanz einer Komponente einer vertrauenswürdigen Plattform; b) Laden des verdächtigen Codes in eine funktionsfähig mit einem Prozessor verknüpfte Bauteilkomponente einer vertrauenswürdigen Plattform, wobei besagter verdächtiger Code außerhalb eines geschützten Bereichs innerhalb besagter Bauteilkomponente der vertrauenswürdigen Plattform geladen wird; c) Abrufen eines öffentlichen Schlüssel zur Validierung aus einer Tabelle und Abspeichern besagten öffentlichen Schlüssels zur Validierung in einem Register in der Bauteilkomponente der vertrauenswürdigen Plattform, wobei besagter öffentlicher Schlüssel zur Validierung durch den verdächtigen Code indiziert wird; d) Abrufen eines Hashalgorithmus, wobei besagter Hashalgorithmus durch den verdächtigen Code indiziert wird; e) Ausführen des mit dem verdächtigen Code verknüpften Hashalgorithmus, um einen ersten Hashwert abzuleiten; f) Entschlüsseln eines verschlüsselten zweiten, in der Tabelle gespeicherten Hashwerts unter Verwendung des öffentlichen Schlüssels zur Validierung, um einen zweiten entschlüsselten Hashwert abzuleiten, wobei besagter zweiter Hashwert durch den verdächtigen Code indiziert wird; g) Vergleichen, durch die Bauteilkomponente der vertrauenswürdigen Plattform, des zweiten entschlüsselten Hashwerts mit dem ersten Hashwert, um zu bestimmen, ob die ersten und zweiten Hashwerte gleich sind; und bei der Feststellung, dass die ersten und zweiten Hashwerte gleich sind: h) Laden des verdächtigen Codes in einen Ausführungsraum des Prozessors zur Ausführung durch den Prozessor.
  14. Verfahren gemäß Anspruch 13, weiterhin umfassend einen Schritt: vor dem Laden des verdächtigen Codes in den Ausführungsraum des Prozessors sicherstellen, dass ein Anwender dazu bevollmächtigt ist, den verdächtigen Code auszuführen.
  15. Verfahren gemäß Anspruch 13, wobei sich die Tabelle in einem sicheren Speicherplatzbereich befindet.
  16. Verfahren gemäß Anspruch 15, wobei sich der sichere Speicherplatzbereich innerhalb der Bauteilkomponente der vertrauenswürdigen Plattform befindet.
  17. Verfahren gemäß Anspruch 13, weiterhin umfassend die Schritte: i) Feststellen, ob der verdächtige Code nicht initialisiert worden ist; und wenn der verdächtige Code nicht initialisiert worden ist: Erzeugen eines Schlüsselpaars zur Bestätigung der Vertrauenswürdigkeit für den verdächtigen Code, wobei das Schlüsselpaar zur Bestätigung der Vertrauenswürdigkeit einen privaten Schlüssel zur Bestätigung der Vertrauenswürdigkeit und einen öffentlichen Schlüssel zur Bestätigung der Vertrauenswürdigkeit umfasst; und Speichern des privaten Schlüssels zur Bestätigung der Vertrauenswürdigkeit und des öffentlichen Schlüssels zur Bestätigung der Vertrauenswürdigkeit in der Tabelle, wobei besagte Tabelle innerhalb der Bauteilkomponente der vertrauenswürdigen Plattform angeordnet ist; j) Abrufen des privaten Schlüssels zur Bestätigung der Vertrauenswürdigkeit aus der Tabelle; k) Speichern des privaten Schlüssels zur Bestätigung der Vertrauenswürdigkeit in einem Register innerhalb der Bauteilkomponente der vertrauenswürdigen Plattform; l) Abrufen des öffentlichen Schlüssels zur Bestätigung der Vertrauenswürdigkeit aus der Tabelle und Speichern des besagten öffentlichen Schlüssels zur Bestätigung der Vertrauenswürdigkeit im Register; und m) Ausführen des verdächtigen Codes aus dem Ausführungsraum.
  18. Verfahren gemäß Anspruch 13, weiterhin umfassend einen Schritt: Speichern des Hashalgorithmus in einem nicht verschlüsselten Speicher der Anordnung.
  19. Computerlesbares Medium, umfassend: Computercode, der es einem Prozessor ermöglicht, die folgenden Schritte auszuführen: a) Empfangen von verdächtigem Code für eine erste Instanz einer Komponente einer vertrauenswürdigen Plattform; b) Laden des verdächtigen Codes in eine funktionsfähig mit dem Prozessor verknüpfte Bauteilkomponente einer vertrauenswürdigen Plattform, wobei besagter verdächtiger Code außerhalb eines geschützten Bereichs innerhalb besagter Bauteilkomponente der vertrauenswürdigen Plattform geladen wird; c) Abrufen eines öffentlichen Schlüssels zur Validierung aus einer Tabelle und Speichern besagten öffentlichen Schlüssels zur Validierung in einem Register in der Bauteilkomponente der vertrauenswürdigen Plattform, wobei besagter erster öffentlicher Schlüssel zur Validierung durch den verdächtigen Code indiziert wird; d) Abrufen eines Hashalgorithmus aus der Tabelle, wobei besagter Hashalgorithmus durch die erste Instanz der Komponente der vertrauenswürdigen Plattform indiziert wird; e) Ausführen des mit der ersten Instanz der Komponente der vertrauenswürdigen Plattform verknüpften Hashalgorithmus, um einen ersten Hashwert abzuleiten; f) Entschlüsseln, unter Verwendung des öffentlichen Schlüssels zur Validierung, eines in der Tabelle gespeicherten verschlüsselten zweiten Hashwerts, um einen zweiten entschlüsselten Hashwert abzuleiten, wobei besagter zweiter Hashwert durch den verdächtigen Code indiziert wird; g) Vergleichen des zweiten entschlüsselten Hashwerts mit dem ersten Hashwert; und bei der Feststellung, dass die ersten und zweiten Hashwerte gleich sind: h) Laden des verdächtigen Codes in einen Ausführungsraum des Prozessors zur Ausführung durch den Prozessor.
  20. Computerlesbares Medium gemäß Anspruch 19, wobei der Computercode dem Prozessor weiterhin ermöglicht, die folgenden Schritte auszuführen: i) Feststellen, ob der verdächtige Code nicht initialisiert worden ist; und wenn der verdächtige Code nicht initialisiert worden ist, Erzeugen eines Schlüsselpaars zur Bestätigung der Vertrauenswürdigkeit für den verdächtigen Code, wobei das Schlüsselpaar zur Bestätigung der Vertrauenswürdigkeit einen privaten Schlüssel zur Bestätigung der Vertrauenswürdigkeit und einen öffentlichen Schlüssel zur Bestätigung der Vertrauenswürdigkeit umfasst; und Speichern des besagten privaten Schlüssels zur Bestätigung der Vertrauenswürdigkeit und des besagten öffentlichen Schlüssels zur Bestätigung der Vertrauenswürdigkeit in der Tabelle; j) Abrufen des privaten Schlüssels zur Bestätigung der Vertrauenswürdigkeit aus der Tabelle; k) Speichern des privaten Schlüssels zur Bestätigung der Vertrauenswürdigkeit in einem Register innerhalb der Bauteilkomponente der vertrauenswürdigen Plattform; l) Abrufen des öffentlichen Schlüssels zur Bestätigung der Vertrauenswürdigkeit aus der Tabelle und Speichern des besagten öffentlichen Schlüssels zur Bestätigung der Vertrauenswürdigkeit im Register; und m) Ausführen des verdächtigen Codes aus dem Ausführungsraum.
DE102007057900.6A 2006-12-29 2007-11-29 Authentifikation von verdächtigen Daten unter Verwendung von Schlüsseltabellen Active DE102007057900B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/647,932 2006-12-29
US11/647,932 US8024579B2 (en) 2006-12-29 2006-12-29 Authenticating suspect data using key tables

Publications (2)

Publication Number Publication Date
DE102007057900A1 DE102007057900A1 (de) 2008-07-03
DE102007057900B4 true DE102007057900B4 (de) 2017-02-16

Family

ID=38983095

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102007057900.6A Active DE102007057900B4 (de) 2006-12-29 2007-11-29 Authentifikation von verdächtigen Daten unter Verwendung von Schlüsseltabellen

Country Status (3)

Country Link
US (1) US8024579B2 (de)
DE (1) DE102007057900B4 (de)
GB (2) GB2445231B (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006006633A1 (de) * 2006-02-10 2007-08-16 Sia Syncrosoft Verfahren zur Verbreitung von Contents
GB0704963D0 (en) * 2007-03-14 2007-04-25 British Telecomm Verification of movement of items
US8141045B2 (en) * 2007-12-14 2012-03-20 International Business Machines Corporation Automatically identifying the source of copied software
US8285985B2 (en) 2008-12-15 2012-10-09 Sap Ag Systems and methods for detecting exposure of private keys
US10452817B1 (en) * 2009-04-08 2019-10-22 Trend Micro Inc File input/output redirection in an API-proxy-based application emulator
JP4656458B1 (ja) 2009-11-09 2011-03-23 Necインフロンティア株式会社 ハンディターミナル、及びハンディターミナルによる決済方法
MY154286A (en) * 2010-10-29 2015-05-29 Mimos Berhad Method and system to establish a trusted interface in a network environment
US8769302B2 (en) 2011-10-14 2014-07-01 International Business Machines Corporation Encrypting data and characterization data that describes valid contents of a column
US9152793B2 (en) * 2012-09-28 2015-10-06 Intel Corporation Methods, systems and apparatus to self authorize platform code
US9754133B2 (en) * 2013-03-14 2017-09-05 Microchip Technology Incorporated Programmable device personalization
TWI531490B (zh) * 2013-08-20 2016-05-01 Mobiletron Electronics Co Ltd Code and its code method
CN103927488A (zh) * 2014-04-04 2014-07-16 西安电子科技大学 一种针对可信嵌入式系统的可信平台模块
EP3262805A1 (de) * 2015-02-26 2018-01-03 Telefonaktiebolaget LM Ericsson (publ) Auf öffentlichem schlüssel basierendes netzwerk
CN105847011A (zh) * 2016-03-21 2016-08-10 华为技术有限公司 一种密钥加载方法及设备
US11436883B2 (en) * 2018-07-09 2022-09-06 Hampton Products International Corporation Secured tethering process between devices
CN111835779B (zh) * 2020-07-20 2023-04-18 安徽华速达电子科技有限公司 一种设备接入平台的认证方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050138393A1 (en) * 2003-12-22 2005-06-23 Challener David C. Determining user security level using trusted hardware device
US20060005015A1 (en) * 2004-06-30 2006-01-05 David Durham System and method for secure inter-platform and intra-platform communications

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3747520B2 (ja) * 1996-01-30 2006-02-22 富士ゼロックス株式会社 情報処理装置及び情報処理方法
EP1026898A1 (de) * 1999-02-04 2000-08-09 CANAL+ Société Anonyme Verfahren und Vorrichtung zur verschlüsselten Übertragung
US7558965B2 (en) * 2000-08-04 2009-07-07 First Data Corporation Entity authentication in electronic communications by providing verification status of device
US20020129261A1 (en) * 2001-03-08 2002-09-12 Cromer Daryl Carvis Apparatus and method for encrypting and decrypting data recorded on portable cryptographic tokens
US7624272B2 (en) * 2003-03-31 2009-11-24 Intel Corporation Platform information for digital signatures
US7751568B2 (en) 2003-12-31 2010-07-06 International Business Machines Corporation Method for securely creating an endorsement certificate utilizing signing key pairs
US7590867B2 (en) 2004-06-24 2009-09-15 Intel Corporation Method and apparatus for providing secure virtualization of a trusted platform module
US7587595B2 (en) 2005-05-13 2009-09-08 Intel Corporation Method and apparatus for providing software-based security coprocessors
US8806224B2 (en) * 2005-06-28 2014-08-12 Intel Corporation Low cost trusted platform
JP4769608B2 (ja) * 2006-03-22 2011-09-07 富士通株式会社 起動検証機能を有する情報処理装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050138393A1 (en) * 2003-12-22 2005-06-23 Challener David C. Determining user security level using trusted hardware device
US20060005015A1 (en) * 2004-06-30 2006-01-05 David Durham System and method for secure inter-platform and intra-platform communications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Trusted Computing GroupTM, "Trusted Platform Modules Strengthen User and Platform Authenticity", Januar 2005, Seiten 1-8, gefunden im Internet unter http://www.trustedcomputinggroup.org/files/resource_files/8D46621F-1D09-3519-ADB205692DBBE135/Whitepaper_TPMs_Strengthen_User_and_Platform_Authenticity_Final_1_0.pdf *

Also Published As

Publication number Publication date
GB2455004A (en) 2009-05-27
GB2445231A (en) 2008-07-02
DE102007057900A1 (de) 2008-07-03
GB2445231B (en) 2009-04-22
GB0903328D0 (en) 2009-04-08
GB0723883D0 (en) 2008-01-16
US8024579B2 (en) 2011-09-20
US20080162932A1 (en) 2008-07-03
GB2455004B (en) 2011-02-23

Similar Documents

Publication Publication Date Title
DE102007057900B4 (de) Authentifikation von verdächtigen Daten unter Verwendung von Schlüsseltabellen
DE112005003479B4 (de) Ein Verfahren zum Realisieren einer Netzzugriffsauthentifizierung
DE69819485T2 (de) Verfahren und vorrichtung zur sicheren verarbeitung kryptographischer schlüssel
DE112005001666B4 (de) Verfahren zum Bereitstellen von privaten Direktbeweis-Schlüsseln in signierten Gruppen für Vorrichtungen mit Hilfe einer Verteilungs-CD
DE112005003340B4 (de) Mechanismus zum Bestimmen der Vertrauenswürdigkeit von Außerbandverwaltungsagenten
Aucsmith Tamper resistant software: An implementation
DE60007724T3 (de) Chipkarten-benutzerschnittstelle für eine vertraute computerplattform
DE102006046456B4 (de) Schaltkreis-Anordnung, Verfahren zum Hochfahren einer Schaltkreis-Anordnung, Verfahren zum Betreiben einer Schaltkreis-Anordnung und Computerprogrammprodukte
DE60126236T2 (de) Verfahren zum Ermöglichen der Prüfung und Fehlerbeseitigung von Software an einem mobilen Kommunikationsgerät in einem sicheren Umfeld
CN107770159B (zh) 车辆事故数据记录方法及相关装置、可读存储介质
DE602005001351T2 (de) Verteilte Verwaltung einer Zertifikatsrücknahmeliste
DE102008006759B4 (de) Prozessor-Anordnung und Verfahren zum Betreiben der Prozessor-Anordnung ohne Verringerung der Gesamtsicherheit
DE102017205948A1 (de) Nachrichtenauthentifizierung mit sicherer Codeverifikation
DE102011051498A1 (de) Gesicherter Zugriff auf Daten in einem Gerät
DE102018203482A1 (de) Vertrauliche Verifikation von FPGA-Code
WO2009040207A1 (de) Verfahren und system zum schutz gegen einen zugriff auf einen maschinencode eines gerätes
Mladenov et al. 1 trillion dollar refund: How to spoof pdf signatures
EP2434424B1 (de) Verfahren zur Erhöhung der Sicherheit von sicherheitsrelevanten Online-Diensten
Budianto et al. You can’t be me: Enabling trusted paths and user sub-origins in web browsers
CN105912945A (zh) 一种操作系统安全加固装置及运行方法
EP3248136B1 (de) Verfahren zum betreiben einer computereinheit mit einer sicheren laufzeitumgebung sowie eine solche computereinheit
Kumar et al. Top vulnerabilities in cloud computing
DE102015201599A1 (de) Datenverarbeitungssystem und Verfahren
EP1924945B1 (de) Verfahren zur verbesserung der vertrauenswürdigkeit von elektronischen geräten und datenträger dafür
DE102018217432A1 (de) Prüfung der Integrität von eingebetteten Geräten

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R081 Change of applicant/patentee

Owner name: LENOVO PC INTERNATIONAL LIMITED, HK

Free format text: FORMER OWNER: LENOVO (SINGAPORE) PTE. LTD., SINGAPUR, SG

R082 Change of representative

Representative=s name: SCHWEIGER & PARTNERS, DE

R082 Change of representative

Representative=s name: SCHWEIGER, MARTIN, DIPL.-ING. UNIV., DE