DE102009013384A1

DE102009013384A1 - System und Verfahren zur Bereitstellung einer sicheren Anwendungsfragmentierungsumgebung

Info

Publication number: DE102009013384A1
Application number: DE102009013384A
Authority: DE
Inventors: Markus Gueller; Karl-Harald Hewel
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2008-05-30
Filing date: 2009-03-16
Publication date: 2009-12-10
Anticipated expiration: 2029-03-17
Also published as: DE102009013384B4; US20090300366A1; US8478973B2

Abstract

Es wird ein System und ein Verfahren zur Bereitstellung und Verwendung einer sicheren Anwendungsumgebung mit erweiterten Speicherressourcen offenbart. Ein Ausführungsbeispiel umfasst ein System und ein Verfahren zur Bereitstellung einer sicheren Anwendungsfunktionalität, die das Empfangen einer Anforderung einer sicheren Operation, das Feststellen, ob ein benötigter Anwendungscode für die sichere Operation in einem Anwendungsfragmentspeicher vorhanden ist oder nicht, das sequentielle Laden einer Vielzahl von Fragmenten des benötigten Anwendungscodes aus einem externen Speicher, wenn der benötigte Anwendungscode nicht in dem Anwendungsfragmentspeicher vorhanden ist, das sequentielle Ausführen der Vielzahl von Fragmenten des benötigten Anwendungscodes und das Senden einer Antwort auf die Anforderung der sicheren Operation umfassen. Das System und das Verfahren können des Weiteren das Entschlüsseln jedes der Vielzahl von Fragmenten des benötigten Anwendungscodes unter Verwendung eines sicheren Schlüssels vor der Ausführung des Fragments und das Verifizieren der Integrität des Codefragments umfassen.

Description

Die vorliegende Erfindung betrifft allgemein ein System und ein Verfahren zur Bereitstellung einer sicheren Anwendungsumgebung und insbesondere ein System und ein Verfahren zur Bereitstellung von erweiterten Speicherressourcen für die Verwendung in einer sicheren Anwendungsumgebung.
Die Sicherheit ist eine der wichtigsten Konstruktionsherausforderungen für die meisten Systeme und Anwendungen. Angriffe und ein unberechtigter Zugriff auf ein System können zum Verlust von kritischen Daten, zu Netzwerkausfallzeiten sowie zu einem Produktivitätsverlust und einem Einkommensverlust führen. Es besteht oftmals eine Notwendigkeit, mit Hilfe von privaten Schlüsseln und Zertifikaten Benutzer zu authentifizieren und eine Netzwerkinfrastruktur sowie die assoziierten Benutzer zu schützen, um die Sicherheit bereitzustellen.
Ein Trusted Platform Module (TPM), das die Spezifikationen erfüllt, die von der Trusted Computing Group (TCG) herausgegeben wurden, ist ein Mikrocontroller-Sicherheitschip, der verwendet werden kann, um die internen Datenstrukturen gegenüber Angriffen zu verteidigen. Der TPM-Sicherheitschip gewährleistet, dass die gespeicherten Informationen wie zum Beispiel Schlüssel, Passwörter und digitale Zertifikate vor externen Softwareangriffen und physischem Diebstahl sicher sind, indem er kryptographische Funktionen auf dem Chip durchführt. Das TPM kann in den Boot-Vorgang (Startvorgang) integriert werden, um eine Vertrauensstufe aufzubauen und um Messwerte bezüglich der Ablaufumgebung für eine vertrauenswürdige Berichterstattung zu sammeln. Ein TPM-Chip kann auf der Systemplatine (Motherboard) eines Computersystems angebracht werden, um diese Funktionalität bereitzustellen.
Der TPM-Chip speichert Schlüssel, Passwörter und digitale Zertifikate. Die Beschaffenheit der Vorrichtung – d. h., ein Mikrocontroller auf Siliziumbasis – gewährleistet, dass die gespeicherten Informationen vor externen Softwareangriffen und physischem Diebstahl sicher sind. Sicherheitsprozesse, wie etwa der Austausch von digitalen Signaturen und Schlüsseln, werden durch Subsysteme auf dem Chip beschützt. Der Zugriff auf Daten und Geheimnisse auf einer Plattform kann zum Beispiel verweigert werden, wenn eine System-Bootsequenz nicht so ist, wie diese von dem TPM-Chip erwartet wird. Kritische Anwendungen und Fähigkeiten, wie etwa eine sichere E-Mail-Kommunikation, ein sicherer Web-Zugriff und der lokale Schutz von Daten, werden dadurch viel sicherer gemacht.
Eine Beschränkung von TPM-Chips liegt in ihrer Unfähigkeit, eine Speichergröße zu erweitern oder aufzurüsten, wenn dies zum Beispiel bedingt durch eine neue Sicherheitsanwendung, eine Änderung bei der Größe einer existierenden Sicherheitsanwendung oder eine Speicherung von zusätzlichen sicheren Daten, die von dem TPM-Chip verarbeitet werden sollen, notwendig wird. Ein TPM weist typischerweise eine passive Rolle in einem System auf. Der TPM-Chip wählt nicht aus, welche Software er ablaufen lässt, sondern agiert statt dessen als ein Slave für übergeordnete Anwendungen, indem er Konfigurationsinformationen von vorab der Laufzeit speichert und berichtet. Typische TPM-Chips verwenden ihre eigene interne Firmware und ihre eigenen logische Schaltungen zum Verarbeiten von Anweisungen und stützen sich nicht auf das darunterliegende System.
In ähnlicher Weise ist das Mobile Trusted Module (MTM) eine neu zugelassene TCG-Spezifikation für die Verwendung in mobilen und eingebetteten Vorrichtungen. Das MTM ist aus dem TPM der Version v. 1.2 hervorgegangen und führt ein sicheres Boot-Konzept ein. Das MTM unterstützt auch eher eine Implementierung in der Form einer Funktionalität an Stelle einer physischen Implementierung in Hardware, was es Geräteherstellern möglich macht, das MTM zu bereits sich im Einsatz befindlichen, proprietären Sicherheitslösungen hinzufügen.
Die Erfindung löst das o. g. bzw. weitere Probleme durch die Gegenstände der Ansprüche 1, 19, 26.
Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
Durch Ausführungsbeispiele der vorliegenden Erfindung, die einen sicheren Anwendungscode und sichere Anwendungsdaten in chipexternen Ressourcen speichern, werden die o. g. bzw. andere Probleme allgemein gelöst oder umgangen und im Allgemeinen technische Vorteile erzielt. Es werden nur Fragmente oder Abschnitte des sicheren Anwendungscodes oder der sicheren Anwendungsdaten je nach Bedarf oder auf Anforderung auf den Chip geladen, um eine angeforderte sichere Anwendungsfunktionalität bereitzustellen.
Sichere Anwendungen, wie etwa TPM 1.2 und MTM, können in isolierten Ausführungsumgebungen, wie etwa innerhalb einer integrierten Sicherheits-Schaltung (Sicherheits-IC) ausgeführt werden. Die vollständige sichere Anwendung kann mit Hilfe einer Programmlogik bereitgestellt werden, die in internen sicheren Speicherressourcen, wie zum Beispiel in einem ROM, RAM oder einem anderen nichtflüchtigen Speicher (NVM; non-volatile memory), implementiert ist, oder kann statisch aus üblichen externen Speicherressourcen, wie zum Beispiel einem Flash-Speicher, in die internen sicheren Speicherressourcen geladen werden. Die sicheren internen Speicherressourcen repräsentieren für Gewöhnlich die komplette sichere Anwendungslogik. Typischerweise müssen die sicheren internen Speicherressourcen dann, wenn die sichere Anwendungsfunktionalität vergrößert wird, ebenfalls vergrößert werden. Außerdem stellt der Prozess des Ladens der sicheren Anwendung aus üblichen externen Speicherressourcen im Allgemeinen einige Voraussetzungen an die Minimumgröße der internen sicheren Speicherressourcen.
Ausführungsbeispiele der vorliegenden Erfindung stellen ein isoliertes Ausführungsumgebungsdesign bereit, in dem die benötigten sicheren internen Speicherressourcen auf eine minimale Größe optimiert sind.
Ausführungsbeispiele der Erfindung stellen des weiteren eine Konstruktion bereit, in der die Größe der sicheren internen Speicherressourcen auf einem Minimum gehalten werden kann und gleichzeitig die gewünschte Funktionalität unterstützt werden kann, selbst wenn die sichere Anwendungsfunktionalität später vergrößert oder erweitert wird.
Frühere Aufrüstungen bei Anwendungen in isolierten Ausführungsumgebungen haben eine Vergrößerung der Größe der sicheren internen Speicherressourcen oder das Laden der kompletten sicheren Anwendungen aus einem üblichen externen Speicher erfordert. Als Folge davon steigen die Kosten für das isolierte Ausführungsumgebungssystem in Folge der höheren Kosten für den sicheren internen Speicher.
Ausführungsbeispiele der vorliegenden Erfindung stellen eine sichere Anwendungsumgebung bereit, die einen minimalen Betrag an sicheren internen Speicherressourcen benötigt. Ausführungsbeispiele dieser Umgebung können als eine sichere Anwendungsfragmentierungsumgebung (SAFE; Secure Application Fragmentation Environment) bezeichnet werden. In einem Ausführungsbeispiel kann die komplette Funktionalität der sicheren Anwendung in standardmäßigen externen Speicherressourcen gespeichert werden und dynamisch während der Laufzeit auf der Grundlage eines Anwendungsfragmentierungsalgorithmus geladen werden. Die Anwendung und die Daten können sicher in die SAFE geladen werden, wodurch die Integrität der Anwendung und die Vertraulichkeit bzw. das Datengeheimnis bewahrt werden.
Der Anwendungsfragmentierungsalgorithmus kann auf verschiedenen Richtlinien (Policies) basieren. Die fragmentierte Anwendung kann in einem Ausführungsbeispiel von einer internen sicheren Speicherressource aus innerhalb einer isolierten Anwendungsumgebung ausgeführt werden. Der Anwendungsfragmentierungsalgorithmus gewährleistet, dass jeder Code, der zur Erfüllung einer angeforderten Anwendungsfunktion benötigt wird, in dem sicheren internen Speicher vorhanden ist. Der externe Code kann während einer Anforderung einer Anwendungsfunktion von dem System x-mal oder nie geladen werden (d. h., 0 bis n Male). Die Integrität und die Vertraulichkeit des Codes, der aus dem externen Speicher geladen wird, werden in Ausführungsbeispielen der vorliegenden Erfindung geschützt.
Ausführungsbeispiele der vorliegenden Erfindung halten die Grundfläche für einen internen sicheren Speicher so klein wie möglich, während sie es dem System gleichzeitig erlauben, die Funktionalität einer Sicherheitsanwendung zu benutzen, die nicht vollständig in dem internen sicheren Speicher gehalten werden kann.
Ausführungsbeispiele der vorliegenden Erfindung benötigen keine Vergrößerung der sicheren internen Speicherressourcen, wenn die Funktionalität der sicheren Anwendung vergrößert wird, und deshalb erlauben sie eine skalierbare Anwendungserweiterung, ohne dass die Kosten für den internen sicheren Speicher steigen.
Außerdem ist es bei Ausführungsbeispielen der vorliegenden Erfindung nicht erforderlich, dass der interne sichere Speicher ein Flash-Speicher oder ein EEPROM-Speicher ist, was eine Prozessoptimierung und eine Ersparnis bei den Herstellungskosten zulässt.
Ein Ausführungsbeispiel der vorliegenden Erfindung ist auf ein System gerichtet, das Folgendes umfasst: einen Fragmentierungsmanager, der mit einem Anwendungsspeicher gekoppelt ist; eine Schnittstelle für einen externen Speicher (im Folgenden ‚externe Speicher-Schnittstelle’ genannt), die mit dem Fragmentierungsmanager gekoppelt ist, wobei der Fragmentierungsmanager ein benötigtes Codefragment von einem externen Speicher über die externe Speicher-Schnittstelle bezieht, wenn das benötigte Codefragment nicht in dem Anwendungsspeicher vorhanden ist; einen kryptographischen Mechanismus, der mit dem Anwendungsspeicher und einem sicheren Schlüsselspeicher gekoppelt ist, wobei der kryptographische Mechanismus das benötigte Codefragment, falls dies notwendig ist, unter Verwendung des sicheren Schlüssels entschlüsselt und die Integrität des Codefragments verifiziert; und einen Ausführungsmechanismus, der mit dem kryptographischen Mechanismus und dem Anwendungsspeicher gekoppelt ist, wobei der Ausführungsmechanismus ein entschlüsseltes Codefragment ausführt.
Das System kann des Weiteren eine Systemschnittstelle umfassen, die einen Systemanwendungsbefehl mit dem Fragmentierungsmanager koppelt. Der Systemanwendungsbefehl kann eine Anforderung einer Authentifizierungsoperation bzw. einer Zugriffsberechtigungsprüfungsoperation, ein Schlüsselverwaltungsbefehl, ein Befehl zur sicheren Speicherung, ein Befehl zur sicheren Plattformberichterstattung oder eine sichere Boot-Operation sein. Das System kann des Weiteren eine Systemschnittstelle umfassen, die den Fragmentierungsmanager mit einer Zentraleinheit auf einer gedruckten Leiterplatte (PCB; Printed Circuit Board), wie zum Beispiel einer Hauptplatine (Mainboard) oder einer Computer-Systemplatine (Motherboard), koppelt. Der Fragmentierungsmanager kann feststellen, ob das benötigte Codefragment in dem Anwendungsspeicher vorhanden ist oder nicht. Eine Speicherverwaltungseinheit kann mit dem Ausführungsmechanismus gekoppelt sein. Ein Hash-Mechanismus kann eine Integritätsverifizierung für entschlüsselte Codefragmente bereitstellen. Die externe Speicher-Schnittstelle kann eine Flash-Speicher-Schnittstelle sein, die mit einem externen Flash-Speicher gekoppelt ist, oder kann eine Festplatten-Schnittstelle sein, die mit einem externen Magnetspeicher oder einer externen optischen Speichervorrichtung gekoppelt ist. Es können auch andere nichtflüchtige Speicher (NVM) für den externen Speicher verwendet werden, wie zum Beispiel ein Flash-Speicher, ein elektrisch löschbarer programmierbarer Festspeicher (EEPROM; Electrically Erasable Programmable Read-Only Memory), ein löschbarer programmierbarer Festspeicher (EPROM; Erasable Programmable Read-Only Memory), ein magnetischer RAM (MRAM), ein ferroelektrischer RAM (FeRAM), eine programmierbare metallbeschichtete Zelle (PMC; Programmable Metallization Cell) oder ein Phasenwechselspeicher (PCM; Phase-change Memory). Die passende externe Speicher-Schnittstelle würde dann mit dem ausgewählten Format des externen Speichers verwendet werden.
Der Fragmentierungsmanager kann eine Logik umfassen, die in einem nichtflüchtigen Speicher implementiert ist. Der Anwendungsspeicher kann einen flüchtigen Speicher, wie zum Beispiel einen SRAM oder DRAM, umfassen. Der sichere Schlüsselspeicher kann einen nichtflüchtigen Speicher umfassen, wie etwa einen einmal programmierten Speicher, einen batteriegepufferten RAM oder einen Flash-Speicher.
In einem anderen Ausführungsbeispiel umfasst ein Verfahren zur Bereitstellung einer sicheren Anwendungsfunktionalität das Empfangen einer Anforderung einer sicheren Operation, das Feststellen, ob ein benötigtes Anwendungscodefragment für die sichere Operation in einem Anwendungsfragmentspeicher vorhanden ist oder nicht, das Laden des benötigten Anwendungscodefragments aus einem externen Speicher, wenn das benötigte Anwendungscodefragment nicht in dem Anwendungsfragmentspeicher vorhanden ist, das Entschlüsseln des benötigten Anwendungscodefragments unter Verwendung eines sicheren Schlüssels, das Ausführen des entschlüsselten benötigten Anwendungscodefragments und das Senden einer Antwort auf die Anforderung einer sicheren Operation.
Die Anforderung einer sicheren Operation kann von einer Zentraleinheit auf einer gedruckten Leiterplatte (PCB), wie zum Beispiel einer Computer-Systemplatine, erzeugt werden. Die sichere Operation kann eine Authentifizierungsoperation bzw. eine Zugriffsberechtigungsprüfungsoperation, ein Schlüsselverwaltungsbefehl, ein Befehl zur sicheren Speicherung, ein Befehl zur sicheren Plattformberichterstattung oder eine sichere Boot-Operation sein. Die Anforderung der sicheren Operation kann während einer Boot-Funktion erzeugt werden.
Der externe Speicher kann eine Flash-Speicher-Vorrichtung oder eine Magnetspeichervorrichtung sein. Das Verfahren kann des Weiteren das Laden eines zweiten benötigten Anwendungscodefragments aus dem externen Speicher, wenn das zweite benötigte Anwendungscodefragment nicht in dem Anwendungsfragmentspeicher vorhanden ist, das Entschlüsseln des zweiten benötigten Anwendungscodefragments unter Verwendung des sicheren Schlüssels und das Verifizieren der Integrität des Codefragments sowie das Ausführen des zweiten entschlüsselten benötigten Anwendungscodefragments umfassen.
Ausführungsbeispiele der vorliegenden Erfindung umfassen ein System und ein Verfahren zur Bereitstellung einer sicheren Anwendungsfunktionalität, die das Empfangen einer Anforderung einer sicheren Operation, das Feststellen, ob der benötigte Anwendungscode für die sichere Operation in einem Anwendungsfragmentspeicher vorhanden ist oder nicht, das sequentielle Laden einer Vielzahl von Fragmenten des benötigten Anwendungscodes aus einem externen Speicher, wenn der benötigte Anwendungscode nicht in dem Anwendungsfragmentspeicher vorhanden ist, das sequentielle Ausführen der Vielzahl von Fragmenten des benötigten Anwendungscodes und das Senden einer Antwort auf die Anforderung der sicheren Operation umfassen. Das System und das Verfahren können des Weiteren das Entschlüsseln jedes der Vielzahl von Fragmenten des benötigten Anwendungscodes unter Verwendung eines sicheren Schlüssels und das Verifizieren der Integrität des Codefragments vor der Ausführung des Fragments umfassen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Zum Zwecke eines vollständigeren Verständnisses der vorliegenden Erfindung und der Vorteile der vorliegenden Erfindung wird nun Bezug auf die nachfolgenden Beschreibungen genommen, die in Verbindung mit den beigefügten Zeichnungen betrachtet werden, in denen:
1 ein Blockdiagramm auf hoher Ebene eines Ausführungsbeispiels einer sicheren Anwendungsfragmentierungsumgebung veranschaulicht;
2 ein Blockdiagramm auf hoher Ebene eines anderen Ausführungsbeispiels einer sicheren Anwendungsfragmentierungsumgebung veranschaulicht;
3 ein Blockdiagramm auf hoher Ebene eines weiteren Ausführungsbeispiels einer sicheren Anwendungsfragmentierungsumgebung veranschaulicht; und
4 ein Ablaufdiagramm für ein exemplarisches Ausführungsbeispiel eines Verfahrens für die Bereitstellung einer sicheren Anwendungsfunktionalität veranschaulicht.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Die vorliegende Erfindung stellt viele anwendbare erfinderische Konzepte bereit, die in einer breiten Vielfalt von spezifischen Kontexten verwirklicht werden können. Die spezifischen Ausführungsbeispiele, die hier besprochen werden, dienen lediglich zur Veranschaulichung spezifischer Möglichkeiten, wie die Erfindung umgesetzt und verwendet werden kann, und stellen keine Beschränkung des Schutzumfangs der Erfindung dar.
1 zeigt ein Blockdiagramm auf hoher Ebene eines Ausführungsbeispiels einer sicheren Anwendungsfragmentierungsumgebung (SAFE) 101, die so konfiguriert sein kann, dass sie innerhalb eines Systems 102 und eines Systems 103 arbeitet. In einem Ausführungsbeispiel fordert das externe System 103 Funktionen an, die von der sicheren Anwendung angeboten werden, die in der SAFE 101 läuft. Die SAFE 101 kann ein diskretes Bauelement sein, wie zum Beispiel eine integrierte Schaltung (IC) oder ein Chip, die bzw. der auf dem System 102 angebracht ist. Alternativ dazu kann die SAFE 101 ein integrales Bauelement oder ein Funktionsblock sein, das bzw. der als Teil des Systems 102 gestaltet ist. So kann das System 102 zum Beispiel ein System auf einem Chip bzw. ein Ein-Chip-System (System an a Chip), ein Basisband-Chipsatz, ein Southbridge Chipsatz oder ein anderes Bauelement sein. Die SAFE 101 kann in Abhängigkeit von Konstruktionsbedürfnissen in Hardware oder in Software verwirklicht werden.
Die Systemschnittstelle 104 stellt eine Verbindung von der SAFE 101 zu dem externen System 103 bereit, wie zum Beispiel über den Systemschnittstellenbus 105. Die Systemschnittstelle 104 kann zum Beispiel eine Schnittstelle zu einem peripheren Bus auf einem Basisband-Chipsatz oder einem Southbridge Chipsatz sein.
Die externe Speicher-Schnittstelle 106 stellt eine Schnittstelle zu üblichen externen Speicherressourcen 107 über einen optionalen Fragmentierungsmanager 108 bereit. Die externe Speicher-Schnittstelle 106 kann zum Beispiel eine Standardschnittstelle zu einem Flash-Speicher sein, und der Fragmentierungsmanager 108 kann eine serielle periphere Schnittstelle (SPI; Serial Peripheral Interface) oder ein LPC-Bus oder ein Flash-Speicher-Bus sein, die einen Zugriff auf die Speicherressourcen 107 bereitstellen, welche ein Flash-Speicher sein können. Die externen Speicherressourcen 107 können auch eine Festplatte, ein Magnetspeicher oder eine andere Speichervorrichtung sein, die kein Flash-Speicher ist. Der Speicher 109 für eine komplette Anwendung in den externen Speicherressourcen 107 speichert den sicheren Anwendungscode, wie etwa einen TPM 1.2- oder MTM-Anwendungscode. Die externe Speicher-Schnittstelle 106 stellt einen Zugriff auf den externen Anwendungscode in dem Anwendungsspeicher 109 bereit. In einigen Ausführungsbeispielen können die Systemschnittstelle 104 und die externe Speicher-Schnittstelle 106 identisch sein.
Ein isolierter Ausführungsumgebungsmechanismus (IEEE; Isolated Execution Environment Engine) 110 führt eine sichere Fragmentierunsgmanagerlogik und einen sicheren Anwendungsfragmentcode aus. Der IEEE 110 kann zum Beispiel anwendungsspezifische Funktionen für eine TPM 1.2- oder MTM-Anwendung ausführen. In einem Ausführungsbeispiel fordert das System 103 eine Ausführung einer sicheren Anwendungsfunktion über die Systemschnittstelle 104 an. Ein Anwendungsfragmentierungsalgorithmus ermittelt, ob die angeforderte Funktionalität der sicheren Anwendung in den sicheren internen Speicherressourcen 111 zur Verfügung steht oder nicht. Wenn der Code nicht bereits intern zur Verfügung steht, dann wird der Code dynamisch und sicher aus der standardmäßigen externen Speicherressource 107 in einen Anwendungsfragmentespeicher (AFS; Application Fragments Store) 112 über die externe Speicher-Schnittstelle 106 geladen. Das Laden kann 0 bis n Male durchgeführt werden, bis die angeforderte Funktionalität der sicheren Anwendung vollständig bereitgestellt ist. Der Code kann aus dem Anwendungsfragmentespeicher 112 heraus ausgeführt werden. In einigen Ausführungsbeispielen kann in Abhängigkeit von dem Fragmentierungsalgorithmus eine Speicherverwaltungseinheit (MMU; Memory Management Unit) 113 den Fragmentierungsalgorithmus unterstützen.
Der sichere Fragmentierungsmanager (SFM) 114 ermittelt, ob ein externer Code in den Anwendungsfragmentspeicher 112 geladen werden muss. Der SFM wird in den internen sicheren Datenverarbeitungsressourcen in einer isolierten Ausführungsumgebung ausgeführt. Wenn der Code aus einem Speicher 109 für eine komplette Anwendung geladen wird, so wird nur das Laden eines vertraulichen und bezüglich der Integrität geschützten Codes zugelassen. Der sichere Fragmentierungsmanager 114 hat Zugriff auf den sicheren Schlüsselspeicher (SKS; Secure Key Store) 115, in dem Integritäts- und Vertraulichkeits-Kryptographieschlüssel gespeichert sind. Die sicheren Schlüssel können für jedes System einzigartig sein, können für eine Gruppe von Systemen gleich sein oder können global für alle Systeme sein. Der sichere Fragmentierungsmanager 114 besitzt auch Zugriff auf den kryptographischen Mechanismus 116, der die relevanten kryptographischen Operationen bei den sicheren Schlüsseln von dem sicheren Schlüsselspeicher 115 durchführt. Der kryptographische Mechanismus 116 verifiziert die Integrität des extern geladenen Codes und entschlüsselt diesen.
In einigen Ausführungsbeispielen können einige Kernfunktionen der sicheren Anwendung permanent in den sicheren internen Speicherressourcen zur Verfügung stehen. In anderen Ausführungsbeispielen kann ein externer, nicht sicherer Fragmentierungsmanager (FM) auf einem externen System 103 ablaufen (was nicht gezeigt ist).
In Ausführungsbeispielen der vorliegenden Erfindung muss der komplette Anwendungscode von einem Anbieter einer sicheren Anwendung (SAP; Secure Application Provider) (nicht gezeigt) authentifiziert werden. Die Instanz, die die Authentizitätsprüfung bzw. Zugriffsberechtigungsprüfung durchführt und die komplette Anwendung in dem Speicher für die komplette Anwendung, der sich in den standardmäßigen externen Speicherressourcen befindet, installiert, wird sicherer Aktualisierungsmanager (SUM; Secure Update Manager) (nicht gezeigt) genannt. Der SUM wird nach der Authentifizierung der kompletten Anwendung die Integrität und Vertraulichkeit des kompletten Anwendungscodes in dem externen Speicher für die komplette Anwendung unter Verwendung des gleichen Algorithmus und der gleichen Schlüssel-Richtlinien beschützen, die der SFM 114 verwendet, um den Code zu laden.
Der SFM 114 stellt ein Verfahren zum sicheren Laden externer Anwendungscodefragmente bereit und stellt ein Verfahren zum Ermitteln, ob eine benötigte Funktionalität der Anwendung innerhalb der SAFE zur Verfügung steht oder nicht, auf der Grundlage eines Anwendungsfragmentierungsalgorithmus bereit. Der Anwendungsfragmentierungsalgorithmus kann auf einer der folgenden Richtlinien basieren:

1) Applications Feature Policy (Anwendungenmerkmalsrichtlinie) – in einem TPM 1.2- oder MTM-Modul würde ein Merkmal zum Beispiel von einer Gruppe von Befehlen repräsentiert werden;
2) Application Command Policy (Anwendungsbefehlsrichtlinie) – in einem TPM 1.2- oder MTM-Modul würde zum Beispiel ein einzelner Befehl von dem Befehl TPM_LoadKey (TMP_SchlüsselLaden) repräsentiert;
3) Isolated Execution Environment Engines Internal Architecture Policy (interne Architekturrichtlinie der isolierten Ausführungsumgebungsmechanismen) – zum Beispiel ein Speicherbankumschaltmechanismus (Bank- Switching-Mechanism), wobei in diesem Fall eine Speicherverwaltungseinheit erforderlich ist;
4) Isolated Execution Environment Engines Code-based Policy (codebasierte Richtlinie der isolierten Ausführungsumgebungsmechanismen) – zum Beispiel ein sicherer Cacheverwendungsmechanismus, der eine Speicherverwaltungseinheit benötigen würde; oder
5) Irgendwelche anderen Richtlinien

In einem Ausführungsbeispiel wird das sichere Laden eines externen Anwendungsfragments wie folgt durchgeführt: Zugreifen auf den externen Speicher 109 für die komplette Anwendung über eine standardmäßige externe Speicher-Schnittstelle 106, Zugreifen auf den sicheren Schlüsselspeicher 115, um Vertraulichkeits- und Integritätsschutz-Schlüssel abzurufen, Zugreifen auf einen kryptographischen Mechanismus 116, um eine Integritätsverifizierungsprüfungs- und Vertraulichkeitsoperation bei dem extern geladenen Anwendungsfragmentcode durchzuführen; und Zugreifen auf sichere Wiedergaberichtlinien-Daten, was gewährleistet, dass nur das Laden von Anwendungscodefragmenten, die zu einer Anwendungsversion gehören, die in den sicheren Wiedergaberichtlinien-Daten genehmigt wurde, zugelassen wird. Die sicheren Schlüssel können für jedes System einzigartig sein, sie können für eine Gruppe von Systemen gleich sein, oder sie können für alle Systeme global sein.
In einem anderen Ausführungsbeispiel kann das System von 1 wie folgt verwendet werden. Das System 103 fordert eine anwendungsspezifische Funktion über den Systemschnittstellenbus 105 an. Die Anforderung kann zum Beispiel eine TPM-Schlüsselladen-Anforderung oder eine Anforderung zur Durchführung einer Signatur sein. Der AFS 112 und der IEEE 110 stellen fest, ob der benötigte Code bereits in den sicheren internen Speicherressourcen 111 vorhanden ist oder nicht. Wenn der benötigte Code nicht vorhanden ist, dann lädt der SFM 114 den Code aus den externen Speicherressourcen 107. Wenn der Code dann vorliegt, wird die angeforderte Anwendungsfunktion durchgeführt und das Ergebnis wird zu dem System 103 zurückgesendet. Der Anwendungscode kann in Fragmenten geladen werden, die größenmäßig so bemessen sind, dass sie passend für die zur Verfügung stehenden internen Speicherressourcen 111 sind.
Ausführungsbeispiele der vorliegenden Erfindung erlauben es, dass ein interner Speicher, wie zum Beispiel ein SRAM, klein sein kann. Das SAFE-System muss den Sicherheitsanwendungscode nicht selbst verwalten, sondern kann den Code aus einem externen Speicher laden. Der Code kann komplett auf einmal oder in Fragmenten geladen werden. Eine spezifische Funktion kann aus einem externen Speicher geladen werden, oder eine Sequenz von Codes oder Anweisungen kann so geladen werden, wie sie gebraucht wird. Wenn man Ausführungsbeispiele der Erfindung verwendet, dann kann die Logik, die benötigt wird, um eine sichere Anwendung bereitzustellen, vergrößert werden, ohne dass eine entsprechende Vergrößerung der Größe des internen Speichers erforderlich wird. Während der Operation kann der SFM 114, während eine Operation durchgeführt wird, feststellen, dass der benötigte Code für eine nächste Operation in dem AFS 112 nicht vorhanden ist. Der SFM 114 kann dann den nächsten benötigten Code in den AFS 112 laden, und die SAFE 101 führt den Rest des Befehls aus, wenn der erste Code vollständig ist.
Schlüssel, die in dem sicheren Schlüsselspeicher 115 gespeichert sind, können mit der Verschlüsselung von externen Speicherressourcen 107 assoziiert sein. Die Daten oder der Code, die in standardmäßigen externen Speicherressourcen 107 gespeichert sind, können verschlüsselt werden, so dass sie von anderen Vorrichtungen nicht verwendet oder gelesen werden können. Dem entsprechend wären die Inhalte solcher Daten vor dem unberechtigten Weitergeben bzw. vor der Offenlegung geschützt, obwohl andere Vorrichtungen auf die Daten und den sicheren Anwendungscode in standardmäßigen externen Speicherressourcen 107 zugreifen können. Ein kryptographischer Mechanismus 116 verwendet einen sicheren Schlüssel aus dem SKS 115, um den geschützten Code zu entschlüsseln, der von dem SFM 114 geladen wird. Der entschlüsselte Code wird dann von dem IEEE 110 zum Beispiel dafür verwendet, eine angeforderte Funktion bereitzustellen. In Ausführungsbeispielen der vorliegenden Erfindung ist der SFM 115 die Master-Vorrichtung, die den kryptographischen Mechanismus 116 so steuert und konfiguriert, dass der richtige Schlüssel aus dem SKS 115 verwendet wird. Der SFM 114 bewegt die Daten zwischen dem kryptographischen Mechanismus 116 und dem IEEE 110, der den entschlüsselten Code ausführt. Nach dem Ausführen des Codes in dem IEEE 110 werden die sich ergebenden Daten, die sich ergebende Ausgabe oder Antwort zurück zu dem System 102 und/oder 103 gesendet.
So kann die SAFE 101 zum Beispiel in einer Authentifizierungs- oder Verifizierungsanwendung verwendet werden. Eine Anwendung auf dem System 103 kann eine von einem Benutzer eingegebene persönliche Kennzahl (PIN) in die SAFE 101 zum Zwecke der Verifizierung oder Authentifizierung senden. Die SAFE 101 benötigt den korrekten sicheren Anwendungscode, um eine Authentifizierung durchführen zu können. Der benötigte Authentifizierungsanwendungscode kann in verschlüsselter Form in einem standardmäßigen externen Speicher 107 gespeichert sein. Der SFM 114 kann Fragmente des Authentifizierungscodes in den AFS 112 laden und/oder die bekannten PIN-Daten unter Verwendung des kryptographischen Mechanismus 116 und eines Schlüssels aus dem SKS 115 entschlüsseln. Der IEEE 110 führt dann den entschlüsselten Code aus, um die Authentifizierungs- bzw. Zugriffsberechtigungsüberprüfungsoperation durchzuführen. Wenn die PIN-Daten verifiziert oder authentifiziert sind, dann kann eine korrekte bzw. positive Antwort zurück zu der Anwendung auf dem System 103 gesendet werden, ohne dass der sichere Authentifizierungsanwendungscode zu dem System 103 gesendet zu werden braucht. Dem gemäß bleibt der sichere Code in den standardmäßigen externen Speicherressourcen 107 sicher. Jede weitere Speicherspeicherung wird von den üblichen externen Speicherressourcen 107 gehandhabt.
2 veranschaulicht eine sichere Anwendungsfragmentierungsumgebung (SAFE; Secure Application Fragmentation Environment) 201, die als ein Ein-Chip-System verwirklicht ist oder als ein Funktionsblock oder ein Intellectual Property (IP) Block auf einem Chipsatz 202 aufgebaut ist. 2 veranschaulicht eine logische Umgebung an Stelle einer physischen Anordnung der SAFE 201. So kann die SAFE 201 zum Beispiel ein Funktionsblock innerhalb eines Southbridge Chipsatzes, ein I/O Controller Hub (Ein-/Ausgabe-Controller und -Verteiler) oder ein Basisband-Controller sein. Der Chipsatz 202 kann auf einer gedruckten Leiterplatte (PCB) 203, wie zum Beispiel einer Systemplatine (Motherboard) für einen Personal Computer, montiert sein. Ein Mikrocontroller 204 ist ein anderer Funktionsblock in dem Chipsatz 202, der den Betrieb des Chipsatzes 202, einschließlich der SAFE 201, steuert.
Die SAFE 201 umfasst ähnliche Komponenten wie die SAFE 101 (1). Ein isolierter Ausführungsumgebungsmechanismus 110 kann als ein IC-Kern 205 oder ein Mikrocontroller, der eine Speicherverwaltungseinheit MMU 206 enthält, verkörpert sein. In einem Ausführungsbeispiel können Merkmale der Sicherheits-Controller-Familie SLE 76 der Firma Infineon verwendet werden, um den IC-Kern 205 und/oder die MMU 206 bereitzustellen. Ein kryptographischer Beschleuniger kann als ein Krypto-Beschleuniger 207, wie zum Beispiel als ein AES-Krypto-Beschleuniger, verwirklicht werden. Der Krypto-Beschleuniger 207 kann Verschlüsselungs- und Entschlüsselungsfunktionen durchführen. Ein Hash-Beschleuniger 220 kann für die Integritätsverifizierung des Codefragments verwendet werden. Die Integritätsverifizierung kann vor oder nach einer Entschlüsselung durchgeführt werden. In einem Ausführungsbeispiel kann ein kryptographischer Mechanismus für die Codevertraulichkeit auf dem Algorithmus AES 128 mit CBC-Betriebsmodi oder einem ähnlichen Algorithmus mit den gleichen Bits of Security (Sicherheitsbits) basieren. Ein kryptographischer Mechanismus für die Codeintegrität kann auf SHA 256 oder einem ähnlichen Algorithmus mit den gleichen Bits of Security basieren.
Die interne Busschnittstelle 208 des Chipsatzes stellt eine Schnittstelle zu dem Bus 209 bereit, welcher die SAFE 201 mit dem Chipsatz-Mikrocontroller 204 verknüpft. Die Zentraleinheit (CPU; Central Processing Unit) 210 ist ebenfalls auf der PCB 203 montiert. Der Bus 211 verknüpft den Chipsatz-Mikrocontroller 204 mit der CPU 210. Eine externe Speicher-Schnittstelle 212 kann eine SPI-Schnittstelle sein, die die SAFE 201 mit dem Flash-Controller 213 und dem externen Flash-Speicher 214 koppelt.
Die sicheren internen Speicherressourcen 215 umfassen einen Anwendungsfragmentespeicher (AFS) 216, einen sicheren Schlüsselspeicher (SKS) 217 und einen sicheren Fragmentierungsmanager (SFM) 218. Der AFS 216 kann als ein SRAM-Speicher auf dem Chipsatz 202 verkörpert sein. Der SKS 217 kann Daten umfassen, die in einem NVM, einem einmal programmierten (OTP-)Speicher, einem batteriegepufferten RAM oder einer Kombination von Speicherarten implementiert sind. Der SFM 218 kann als eine Logik verkörpert sein, die in einem ROM- oder OTP-Speicher implementiert ist. Der NVM-, OTP- und RAM-Speicher ist in dem Chipsatz 202 eingebaut. Der Flash-Speicher 214 befindet sich außerhalb von dem Chipsatz 202 und kann, falls dies notwendig ist, durch einen größeren Flash-Speicher erweitert oder ersetzt werden, um Daten und/oder einen Anwendungscode, wie zum Beispiel eine TPM 1.2- oder MTM-Anwendung 219, gespeichert zu halten.
3 veranschaulicht ein weiteres Ausführungsbeispiel der vorliegenden Erfindung, in dem die sichere Anwendungsfragmentierungsumgebung (SAFE) 301 als eine diskrete Sicherheits-IC (DSIC) verkörpert ist, die auf einer gedruckten Leiterplatte (PCB) 302, wie etwa einer Hauptplatine (Mainboard) oder einer Systemplatine (Motherboard), in einem Personal Computer oder einem Laptop 303 montiert ist. Das Ausführungsbeispiel, das in 3 veranschaulicht ist, ist im Gegensatz zu der SAFE-Funktionalität, die Bestandteil des Chipsatzes 202 in 2 ist, ein diskretes SAFE-Bauelement.
Die SAFE 301 umfasst einen isolierten Ausführungsumgebungsmechanismus 304, der als ein IC-Kern oder ein Mikrocontroller verkörpert sein kann, wie zum Beispiel als ein Sicherheits-IC-Kern (Security IC Core) der Firma Infineon, der eine Speicherverwaltungseinheit (MMU) 305 enthält. Der kryptographische Beschleuniger kann als ein Krypto-Beschleuniger 306, wie zum Beispiel ein AES-Krypto-Beschleuniger, verwirklicht sein. Der Krypto-Beschleuniger 306 kann Verschlüsselungs- und Entschlüsselungsfunktionen durchführen. Ein Hash-Mechanismus (nicht gezeigt) kann, falls dies benötigt wird, für die Integritätsverifizierung des Codes verwendet werden.
Eine LPC-Bus-Schnittstelle 307 stellt eine Systemschnittstelle zu der PCB 302 über den LPC-Systemschnittstellen-Bus 308 bereit. Die LPC-Bus-Schnittstelle 307 stellt auch eine standardmäßige externe Speicher-Schnittstelle zu dem externen Fragmentierungsmanager 308 bereit, der ein Software-Modul sein kann, das eine Verwaltung der Abrufung und Speicherung von Anwendungsfragmenten für die Festplatte 310 bereitstellt. Wie in dem Ausführungsbeispiel von 3 gezeigt ist, kann die standardmäßige externe Speicherressource eine Festplatte oder jede andere Speichervorrichtung außer dem Flash-Speicher sein, der in den anderen exemplarischen Ausführungsbeispielen veranschaulicht ist. Die Festplatte 310 kann sichere Anwendungsdaten und einen sicheren Anwendungscode, wie zum Beispiel TPM 1.2 Anwendungsdaten 311, speichern.
Die sicheren internen Speicherressourcen 312 umfassen einen Anwendungsfragmentespeicher (AFS) 313, einen sicheren Schlüsselspeicher (SKS) 314 und einen sicheren Fragmentierungsmanager (SFM) 315. Der AFS 313 kann zum Beispiel als ein RAM-Speicher auf einer DSIC 301 verkörpert sein. Der SKS 314 kann Daten umfassen, die in einem NVM, wie zum Beispiel einem OTP-Speicher, einem batteriegepufferten RAM, oder in einer Kombination aus Speicherarten implementiert sind. Der SFM 315 kann als eine Logik, die in einem NVM, wie zum Beispiel einem ROM- oder OTP-Speicher, implementiert ist, verwirklicht sein. Der NVM-, OTP- und RAM-Speicher ist in der IC 301 eingebaut.
In anderen Ausführungsbeispielen kann die SAFE als ein Sicherheits-IC auf einer mobilen Plattform implementiert werden, wie zum Beispiel einer Vorrichtung, die zwischen einem Ein-Chip-System (SoC) und einer externen Speicherkomponente angeordnet ist.
4 veranschaulicht ein Ablaufdiagramm für ein exemplarisches Ausführungsbeispiel eines Verfahrens zur Bereitstellung einer sicheren Anwendungsfunktionalität. Das Verfahren, das in 4 veranschaulicht ist, kann zum Beispiel unter Verwendung von sicheren Anwendungsfragmentierungsumgebungen 201, 301, 401 (1–3) implementiert werden, soll aber nicht auf derartige Konfigurationen beschränkt sein. Vielmehr wird es selbstverständlich sein, dass die Schritte des Verfahrens, das in 4 veranschaulicht ist, in der angegebenen Reihenfolge oder in irgendeiner anderen Reihenfolge oder gleichzeitig oder in Verbindung mit anderen Schritten oder Verfahren durchgeführt werden können. Im Schritt 401 wird eine Anforderung einer sicheren Operation empfangen. In Ausführungsbeispielen der Erfindung stammt die Anforderung einer sicheren Operation von einer Zentraleinheit auf einer gedruckten Leiterplatte (PCB), wie etwa einer Computer Systemplatine, oder von einem Mikrocontroller auf einem SoC. Die sichere Operation kann eine Authentifizierungsoperation bzw. Zugriffsberechtigungsprüfungsoperation, ein Schlüsselverwaltungsbefehl, ein Befehl zur sicheren Speicherung, ein Befehl zur sicheren Plattformberichterstattung oder eine sichere Boot-Operation sein. Die Anforderung der sicheren Operation kann während einer Boot-Operation erzeugt werden. Im Schritt 402 wird eine Feststellung dahingehend getroffen, ob ein benötigtes Anwendungscodefragment für die sichere Operati on in einem Anwendungsfragmentspeicher vorhanden ist oder nicht. Im Schritt 403 wird das benötigte Anwendungscodefragment aus einem externen Speicher geladen, wenn das benötigte Anwendungscodefragment nicht in dem Anwendungsfragmentspeicher vorhanden ist. Der externe Speicher kann zum Beispiel eine Flash-Speichervorrichtung oder eine Magnetspeichervorrichtung sein. Im Schritt 404 wird das benötigte Anwendungscodefragment unter Verwendung eines sicheren Schlüssels entschlüsselt. Im Schritt 405 wird die Integrität eines benötigten Anwendungscodefragments verifiziert. Im Schritt 406 wird das entschlüsselte benötigte Anwendungscodefragment ausgeführt. Im Schritt 407 wird eine Antwort auf die Anforderung der sicheren Operation gesendet.
Ausführungsbeispiele des Verfahrens können des Weiteren das Laden eines zweiten benötigten Anwendungscodefragments aus dem externen Speicher, wenn das zweite benötigte Anwendungscodefragment nicht in dem Anwendungsfragmentspeicher vorhanden ist, das Entschlüsseln des zweiten benötigten Anwendungscodefragments unter Verwendung des sicheren Schlüssels und das Verifizieren der Integrität des Codefragments sowie das Ausführen des zweiten entschlüsselten benötigten Anwendungscodefragments umfassen.
Obwohl die vorliegende Erfindung und ihre Vorteile im Einzelnen beschrieben worden sind, sollte es klar sein, dass verschiedene Veränderungen, Ersetzungen und Abänderungen daran durchgeführt werden können, ohne dass von dem Erfindungsgedanken und dem Schutzumfang der Erfindung, wie sie von den angehängten Ansprüchen definiert ist, abgewichen wird. Vielmehr soll der Schutzumfang der vorliegenden Erfindung nicht auf die bestimmten Ausführungsbeispiele des Prozesses, der Maschine, der Herstellung, der Stoffverbindung, der Einrichtungen, der Verfahren und der Schritte beschränkt sein, die in der Beschreibung beschrieben sind. Ein Durchschnittsfachmann auf dem Gebiet wird aus der Offenbarung der vorliegenden Erfindung ohne weiteres Prozesse, Maschinen, Herstellungsarten, Stoffverbindungen, Einrichtungen, Verfahren oder Schritte, die im Augenblick existieren oder später noch entwickelt werden, erkennen, die im Wesentlichen die gleiche Funktion durchführen oder im Wesentlichen zu den gleichen Ergebnissen führen wie die entsprechenden Ausführungsbeispiele, die hier beschrieben worden sind, und die in Übereinstimmung mit der vorliegenden Erfindung verwendet werden können.
Dem entsprechend ist es so gedacht, dass die angehängten Ansprüche derartige Prozesse, Maschinen, Herstellungsarten, Stoffverbindungen, Einrichtungen, Verfahren oder Schritte in ihrem Schutzumfang einschließen sollen.

Claims

System, das Folgendes umfasst: einen sicheren Fragmentierungsmanager, der mit einem Anwendungsfragmentespeicher gekoppelt ist; eine externe Speicher-Schnittstelle, die mit dem sicheren Fragmentierungsmanager gekoppelt ist, wobei der sichere Fragmentierungsmanager ein benötigtes Codefragment aus einem externen Speicher über die externe Speicher-Schnittstelle bezieht, wenn das benötigte Codefragment nicht in dem Anwendungsfragmentespeicher vorhanden ist; einen kryptographischen Mechanismus, der mit dem Anwendungsfragmentespeicher und einem sicheren Schlüsselspeicher gekoppelt ist, wobei der kryptographische Mechanismus das benötigte Codefragment, falls dies notwendig ist, unter Verwendung eines sicheren Schlüssels entschlüsselt und die Integrität eines Codefragments verifiziert; und einen Ausführungsmechanismus, der mit dem kryptographischen Mechanismus und dem Anwendungsfragmentespeicher gekoppelt ist, wobei der Ausführungsmechanismus ein entschlüsseltes Codefragment ausführt.
System nach Anspruch 1, wobei die Größe des Anwendungsspeichers auf der Grundlage einer verwendbaren Minimum-Codefragmentgröße ausgewählt wird.
System nach Anspruch 1 oder 2, das des Weiteren Folgendes umfasst: eine Systemschnittstelle, die einen Systemanwendungsbefehl mit dem sicheren Fragmentierungsmanager koppelt.
System nach Anspruch 3, wobei der Systemanwendungsbefehl eine Anforderung einer Authentifizierungsoperation bzw. einer Zugriffsberechtigungsprüfungsoperation, ein Schlüsselverwaltungsbefehl, ein Befehl zur sicheren Speicherung, ein Befehl zur sicheren Plattformberichterstattung oder eine sichere Boot-Operation ist.
System nach einem der vorhergehenden Ansprüche, wobei der sichere Fragmentierungsmanager, der Anwendungsfragmentespeicher, der kryptographische Mechanismus und der Ausführungsmechanismus Teil einer sicheren Anwendungsfragmentierungsumgebung (SAFE; Secure Application Fragmentation Environment) sind, wobei das System des Weiteren Folgendes umfasst: eine Systemschnittstelle, die die SAFE mit einer Zentraleinheit auf einer gedruckten Leiterplatte (PCB; Printed Circuit Board) koppelt.
System nach einem der vorhergehenden Ansprüche, wobei der sichere Fragmentierungsmanager, der Anwendungsfragmentespeicher, der kryptographische Mechanismus und der Ausführungsmechanismus Teil einer sicheren Anwendungsfragmentierungsumgebung (SAFE) sind, wobei sich die SAFE in einem Ein-Chip-System (SoC) befindet; wobei das System des Weiteren Folgendes umfasst: eine Systemschnittstelle, die die SAFE mit einem Mikrocontroller auf dem SoC koppelt.
System nach einem der vorhergehenden Ansprüche, wobei der sichere Fragmentierungsmanager feststellt, ob das benötigte Codefragment in dem Anwendungsspeicher vorhanden ist oder nicht.
System nach einem der vorhergehenden Ansprüche, das des Weiteren Folgendes umfasst: eine Speicherverwaltungseinheit, die mit dem Ausführungsmechanismus und mit dem sicheren Fragmentierungsmanager gekoppelt ist.
System nach einem der vorhergehenden Ansprüche, das des Weiteren Folgendes umfasst: einen Hash-Mechanismus, der die Integritätsverifizierung für die Codefragmente bereitstellt.
System nach einem der vorhergehenden Ansprüche, wobei der externe Speicher ein nichtflüchtiger Speicher (NVM; Non-Volatile Memory) ist.
System nach Anspruch 10, wobei der NVM einen Flash-Speicher, einen elektrisch löschbaren programmierbaren Festspeicher (EEPROM), einen löschbaren programmierbaren Festspeicher (EPROM), einen magnetischen RAM (MRAM), einen ferroelektrischen RAM (FeRAM), eine programmierbare metallbeschichtete Zelle (PMC) oder einen Phasenwechselspeicher (PCM) umfasst.
System nach Anspruch 11, wobei die externe Speicher-Schnittstelle eine Festplatten-Schnittstelle ist.
System nach einem der vorhergehenden Ansprüche, das des Weiteren Folgendes umfasst: eine externe Magnetspeichervorrichtung oder eine externe optische Speichervorrichtung.
System nach einem der vorhergehenden Ansprüche, wobei der sichere Fragmentierungsmanager eine Logik umfasst, die in einem nichtflüchtigen Speicher implementiert ist.
System nach einem der vorhergehenden Ansprüche, wobei der Anwendungsfragmentespeicher einen flüchtigen Speicher umfasst.
System nach Anspruch 15, wobei der flüchtige Speicher einen SRAM oder DRAM umfasst.
System nach einem der vorhergehenden Ansprüche, wobei der sichere Schlüsselspeicher einen nichtflüchtigen Speicher (NVM) umfasst.
System nach Anspruch 17, wobei der NVM einen einmal programmierbaren (OTP-)Speicher, einen batteriegepufferten RAM oder einen Flash-Speicher umfasst.
Verfahren zur Bereitstellung einer sicheren Anwendungsfunktionalität, das Folgendes umfasst: Empfangen einer Anforderung einer sicheren Operation; Feststellen, ob ein benötigtes Anwendungscodefragment für die sichere Operation in einem Anwendungsfragmentspeicher vorhanden ist oder nicht; Laden des benötigten Anwendungscodefragments aus einem externen Speicher, wenn das benötigte Anwendungscodefragment nicht in dem Anwendungsfragmentspeicher vorhanden ist; Entschlüsseln des benötigten Anwendungscodefragments unter Verwendung eines sicheren Schlüssels; Verifizieren der Integrität eines benötigten Anwendungscodefragments; Ausführen des entschlüsselten benötigten Anwendungscodefragments; und Senden einer Antwort auf die Anforderung der sicheren Operation.
Verfahren nach Anspruch 19, wobei die Anforderung einer sicheren Operation von einer Zentraleinheit auf einer gedruckten Leiterplatte oder von einem Mikrocontroller auf einem Ein-Chip-System (SoC) erzeugt wird.
Verfahren nach Anspruch 19 oder 20, wobei der externe Speicher eine nichtflüchtige Speicher-(NVM)-Vorrichtung ist.
Verfahren nach einem der Ansprüche 19 bis 21, wobei der externe Speicher eine Magnetspeichervorrichtung oder eine optische Speicherungsvorrichtung ist.
Verfahren nach einem der Ansprüche 19 bis 22, das des Weiteren Folgendes umfasst: Laden eines zweiten benötigten Anwendungscodefragments aus dem externen Speicher, wenn das zweite benötigte Anwendungscodefragment nicht in dem Anwendungsfragmentspeicher vorhanden ist; Entschlüsseln des zweiten benötigten Anwendungscodefragments unter Verwendung des sicheren Schlüssels; Verifizieren der Integrität eines zweiten benötigten Anwendungscodefragments; und Ausführen des zweiten entschlüsselten benötigten Anwendungscodefragments.
Verfahren nach einem der Ansprüche 19 bis 23, wobei die sichere Operation eine Anforderung einer Authentifizierungsoperation bzw. einer Zugriffsberechtigungsprüfungsoperation, ein Schlüsselverwaltungsbefehl, ein Befehl zur sicheren Speicherung, ein Befehl zur sicheren Plattformberichterstattung oder eine sichere Boot-Operation ist.
Verfahren nach einem der Ansprüche 19 bis 24, wobei die Anforderung der sicheren Operation während einer Boot-Funktion erzeugt wird.
Verfahren zur Bereitstellung einer sicheren Anwendungsfunktionalität, das Folgendes umfasst: Empfangen einer Anforderung einer sicheren Operation; Feststellen, ob ein benötigter Anwendungscode für die sichere Operation in einem Anwendungsfragmentspeicher vorhanden ist oder nicht; sequentielles Laden einer Vielzahl von Fragmenten des benötigten Anwendungscodes aus einem externen Speicher, wenn der benötigte Anwendungscode nicht in dem Anwendungsfragmentspeicher vorhanden ist; sequentielles Ausführen der Vielzahl von Fragmenten des benötigten Anwendungscodes; und Senden einer Antwort auf die Anforderung der sicheren Operation.
Verfahren nach Anspruch 26, das des Weiteren Folgendes umfasst: Entschlüsseln jedes der Vielzahl von Fragmenten des benötigten Anwendungscodes unter Verwendung eines sicheren Schlüssels vor der Ausführung des Fragments; und Verifizieren der Integrität jedes der Vielzahl von benötigten Anwendungscodefragmenten.