Verfahren und Sicherheitsmodul zum Bereitstellen einer

Sicherheitsfunktion für ein Gerät

Die Erfindung bezieht sich auf ein Verfahren und ein Sicherheitsmodul zum kryptographischen Schutz von Geräten.

Geräte, beispielsweise eingebettete Systeme (engl. Embedded Systems) , sind heutzutage in allen Industriezweigen zu fin ^¬ den. Der (kryptographische) Schutz dieser Geräte spielt eine zunehmend wichtigere Rolle, um einen sicheren Betrieb gewähr ^¬ leisten zu können. Durch kryptographische Funktionen können Ziele wie Integrität, Vertraulichkeit oder Authentizität die- ser Plattformen erreicht werden. Dadurch werden absichtliche, zielgerichtete Angriffe abgewehrt.

Eine Möglichkeit, ein eingebettetes System abzusichern, ist die Integration eines hardwarebasierten Vertrauensankers. Dieser kann diverse Aufgaben erfüllen, beispielsweise kann eine Sicherheitsfunktion einer Sicherheitsanwendung zur Laufzeit kryptographische Schlüssel zur Verfügung stellen, Integ ^¬ ritätsprüfwerte von Anwendungs- und Konfigurationsdaten er ^¬ stellen und prüfen, Daten signieren, kryptographisch starke Zufallszahlen bereitstellen, und vieles mehr.

In vielen Fällen haben Vertrauensanker nur sehr beschränkte Ressourcen zur Verfügung, beispielsweise wenig Arbeitsspeicher oder Flash Speicher. Dies bedeutet, dass die Vertrauens- anker beispielsweise auf Veränderungen von Sicherheitsstandards nur kompliziert aktualisiert werden können.

Die Aufgabe der vorliegenden Erfindung ist es, ein Verfahren und ein Sicherheitsmodul bereitzustellen, die möglichst fle- xibel und sicher Sicherheitsfunktionen einem Gerät bereitstellen . Die Aufgabe wird durch die in den unabhängigen Ansprüchen an gegebenen Merkmale gelöst. In den abhängigen Ansprüchen sind vorteilhafte Weiterbildungen .er Erfindung dargestellt.

Gemäß einem ersten Aspekt betrifft die Erfindung ein Verfahren zum Bereitstellen einer Sicherheitsfunktion, insbesonder einer kryptographischen Funktion, für ein Gerät, wobei folgende Verfahrensschritten ausgeführt werden:

In einem Verfahrensschritt wird eine Anforderung zum Ausführen der Sicherheitsfunktion empfangen. In einem weiteren Ver fahrensschritt wird eine Sicherheitsanwendung für die Sicher heitsfunktion durch eine Steuerungsanwendung geladen, wobei die Steuerungsanwendung auf einem ersten internen Speicher eines Sicherheitsmoduls gespeichert ist, und die Sicherheits anwendung von einem sicherheitsmodulexternen Speicher übertragen wird.

In einem weiteren Verfahrensschritt wird eine Integrität der Sicherheitsanwendung mittels einer Sicherheitsinformation überprüft .

In einem weiteren Verfahrensschritt wird die Sicherheitsanwendung ausgeführt und die Sicherheitsfunktion bereitgestellt, wobei das Ausführen und Bereitstellen nach dem erfolgreichen Überprüfen der Integrität durchgeführt wird.

Unter einer Sicherheitsanwendung kann beispielsweise eine Programmbibliothek verstanden werden die eine oder mehrere Sicherheitsfunktionen umfasst. Somit kann eine Sicherheitsan wendung nur eine einzige Sicherheitsfunktion umfassen, wobei in einem solchen Fall die Ausdrücke „Sicherheitsfunktion" un „Sicherheitsanwendung" als synonym angesehen werden können.

Unter einem (technischen) Gerät oder einem (technischen) Sys tem kann beispielsweise ein Messgerät für die Hochfrequenz ^¬ technik, ein Empfangsgerät einer Satellitenkommunikationssta tion, ein Feldgerät einer Kraftwerksanlage, ein Steuerungsge rät, ein eingebettetes System, ein IC (integrierter Schalt ^¬ kreis, engl, integrated circuit) , ein FPGA (engl, field pro- grammable gate array) , ein ASIC (anwendungsspezifische inte ^¬ grierte Schaltung, engl, application-specific integrated cir- cuit) , ein MikroController oder ein DSP (digitaler Signalprozessor, engl. Digital Signal Processor) verstanden werden.

Die Verfahrensschritte können beispielsweise rechnergestützt mittels eines Prozessors ausgeführt werden.

Die Anforderung kann beispielsweise von einem Betriebssystemtreiber oder einem Betriebssystem erzeugt werden, welches die Sicherheitsfunktion benötigt. Die Anforderung umfasst dazu beispielsweise eine Datenstruktur, die die Sicherheitsanwen- dung, Nutzerdaten, die Sicherheitsinformation, beispielsweise in Form einer Integritätsinformation, über die Sicherheitsanwendung und/oder weitere Informationen umfasst. Die Sicherheitsanwendung und die Integritätsinformation sind vorzugsweise auf dem sicherheitsmodulexternen Speicher gespeichert und werden beispielsweise von dem Betriebssystemtreiber mittels der Anforderung an das Sicherheitsmodul gesendet.

Unter "sicherheitsmodulextern" können Komponenten verstanden werden, die kein integraler Bestandteil des Sicherheitsmoduls sind.

Unter interne, häufig auch "sicherheitsmodulintern" genannt, können Komponenten oder Verfahrensschritte verstanden werden, die ein integraler Bestandteil des Sicherheitsmoduls sind oder auf sicherheitsmodulinternen Komponenten vorzugsweise exklusiv ausgeführt werden.

Das Laden und Ausführen wird beispielsweise zur Laufzeit des Betriebssystems und/oder des Sicherheitsmoduls und/oder der Steuerungsanwendung des Sicherheitsmoduls ausgeführt.

Der Begriff „Laden" kann im Zusammenhang mit der Patentanmeldung breit verstanden werden. Es kann darunter eine Variante verstanden werden, bei der eine zusätzliche Sicherheitsanwendung geladen wird. In einer anderen Variante kann darunter verstanden werden, dass eine geladene Sicherheitsanwendung durch die neu geladene Sicherheitsanwendung ersetzt wird, d.h. überschrieben wird. In einer weiteren Variante kann durch das Laden einer leeren Sicherheitsapplikation ein Löschen einer geladenen Sicherheitsanwendung erfolgen. Dies kann durch eine Lösch-Ladeanweisung erfolgen. Das Sicherheitsmodul stellt die Sicherheitsfunktion infolge des erfolgreichen Überprüfens beispielsweise eines autori ^¬ sierten Anfordernden, insbesondere dem Betriebssystem, dem Betriebssystemtreiber, dem Sicherheitsmodul selbst, einem anderen Sicherheitsmodul oder einer Kombination hiervon, be- reit. Die Sicherheitsanwendung oder die Sicherheitsfunktion generieren dabei beispielsweise Daten, die von dem Anfordernden und/oder dem Sicherheitsmodul selbst, beispielsweise für ein späteres Bereitstellen einer weiteren Sicherheitsfunktion, und/oder einer später geladenen und ausgeführten Sicher- heitsanwendung oder Sicherheitsfunktion genutzt werden können .

Unter einer Sicherheitsfunktion können kryptographische Funktionen, beispielsweise zum Erstellen einer digitalen Signa- tur, zum Entschlüsseln oder Verschlüsseln einer Datenstruktur, oder Funktionen zum Bereitstellen von Lizenzinformationen verstanden werden.

Das offenbarte Verfahren ist vorteilhaft gegenüber bisherigen Lösungen, da es einen dynamischen Austausch von (kryptogra- phischen) Sicherheitsfunktionen oder Sicherheitsanwendungen, beispielsweise kryptographischen Funktionen, zur Laufzeit des Betriebssystems des Gerätes erlaubt. Beispielsweise erlaubt das Verfahren, eine Vielzahl von Sicherheitsfunktionen durch ein Sicherheitsmodul, beispielsweise einen Vertrauensanker, bereitzustellen, wo zuvor aus Platzgründen nur eine einzige Sicherheitsfunktion oder Sicherheitsanwendung integrierbar war. Dadurch kann das Sicherheitsmodul kostengünstig gefer ^¬ tigt werden.

Bei einer ersten Ausführungsform des Verfahrens kann die Sicherheitsanwendung vor dem Überprüfen mittels eines ersten kryptographischen Schlüssels entschlüsselt werden.

Hierzu liegt die Sicherheitsanwendung auf dem sicherheitsmo- dulexternen Speicher in verschlüsselter Form vor, wobei auch die Integritätsinformation zur Sicherheitsanwendung verschlüsselt sein kann. Hier können symmetrische oder asymmet ^¬ rische Verfahren zum Einsatz kommen. Der erste kryptographi- sche Schlüssel ist vorzugsweise auf dem ersten sicherheitsmo- dulinternen Speicher abgelegt und vor sicherheitsmodulexter- nen Zugriffen geschützt. Hierdurch wird die Sicherheit des Verfahrens verbessert. Das Entschlüsseln kann dann beispiels ^¬ weise beim Laden oder beim Überprüfen der Integrität der Sicherheitsanwendung durchgeführt werden.

Bei weiteren Ausführungsformen des Verfahrens kann vor dem Überprüfen der Sicherheitsanwendung eine Headerinformation der Sicherheitsanwendung auf deren Integrität überprüft werden. Die Sicherheitsanwendung kann erst nach oder infolge der erfolgreichen Prüfung der Headerinformation geladen werden.

Die Headerinformation kann beispielsweise in der Anforderung zusammen mit der Sicherheitsanwendung und der Sicherheitsinformation enthalten sein. Die Steuerungsanwendung lädt die Sicherheitsanwendung erst, nachdem das Überprüfen erfolgreich war und hat den Vorteil, dass ein Ladevorgang einer potenti ^¬ ell manipulierten Sicherheitsanwendung frühzeitig abgebrochen wird, und damit die Sicherheit des Verfahrens verbessert wird .

Bei weiteren Ausführungsformen des Verfahrens kann die

Sicherheitsanwendung als ein Teil Anforderung übertragen werden, ein Speicherort der Sicherheitsanwendung als ein Teil der Anforderung übertragen werden, oder die Sicherheitsanwen- dung durch die Steuerungsanwendung von dem sicherheitsmodul- externen Speicher geladen werden.

Die verschiedenen Varianten des Ladens der Sicherheitsanwendung erlauben es beispielsweise dem Verfahren, dass die Da ^¬ tenquelle flexibel gewählt werden kann.

Bei weiteren Ausführungsformen des Verfahrens kann die

Sicherheitsanwendung zum Entschlüsseln, zum Überprüfen der Sicherheitsanwendung oder zum Überprüfen der Headerinformation in einen zweiten internen Speicher geladen werden.

Hierdurch kann die Sicherheit des Verfahrens erhöht werden, um zu verhindern, dass beispielsweise gefährlicher Programmcode nicht direkt in einen Speicher geladen wird, in dem ausführbare Anwendungen und/oder auch Daten liegen.

Bei weiteren Ausführungsformen des Verfahrens kann die

Sicherheitsanwendung zum Ausführen in den ersten internen Speicher oder in einen internen Anwendungsspeicher des

Sicherheitsmoduls geladen werden.

Dadurch, dass die Sicherheitsanwendung zum Ausführen in einen speziellen internen Speicher des Sicherheitsmoduls geladen wird, kann die Sicherheit des Verfahrens noch weiter erhöht werden .

Bei weiteren Ausführungsformen des Verfahrens können die Sicherheitsfunktion und/oder weitere Sicherheitsfunktionen von der Sicherheitsanwendung und/oder von weiteren Sicherheitsanwendungen bereitgestellt werden.

Je nach Konfiguration kann beispielsweise eine Sicherheitsanwendung mehrere Sicherheitsfunktionen bereitstellen. Dadurch können unterschiedliche Anwendungsszenarien realisiert werden und auf die individuellen Bedürfnisse des Gerätes angepasst werden. Beispielsweise können von der Sicherheitsanwendung, insbesondere mittels des Sicherheitsmoduls, Sicherheitsfunk- tionen exklusiv bereitgestellt werden. Auch kann eine Anforderung mehrere Sicherheitsanwendungen enthalten, die paralle oder nacheinander, beispielsweise durch einen Scheduler, aus geführt werden.

Bei weiteren Ausführungsformen des Verfahrens kann ein Daten austausch zwischen Sicherheitsanwendungen in dem Sicherheits modul über einen dritten internen Speicher des Sicherheitsmo duls erfolgen.

Durch den dritten internen Speicher, beispielsweise einen flüchtiger Speicher, lassen sich beispielsweise Ausgaben der Sicherheitsanwendung als Eingabe für eine weitere Sicherheitsanwendung verwenden, falls sich beispielsweise zu einem Zeitpunkt nur eine Sicherheitsanwendung in dem Sicherheitsmo dul befinden kann. Die Ausgaben der Sicherheitsanwendung kön nen beispielsweise die Daten sein die von der Sicherheits ^¬ funktion generieret werden. Hierdurch lassen sich vorzugswei se komplexe und/oder geschachtelte kryptographische Funktio ^¬ nen realisieren.

Bei weiteren Ausführungsformen des Verfahrens kann eine auszuführende Anzahl von Sicherheitsanwendungen durch die Steue rungsanwendung festgelegt werden.

Die auszuführende (maximale) Anzahl von Sicherheitsanwendungen wird vorzugsweise durch die Steuerungsanwendung begrenzt Hierzu kann beispielsweise während der Fertigung des Sicher ^¬ heitsmoduls die auszuführende Anzahl festgelegt werden. Soll eine neue und/oder zusätzliche Sicherheitsanwendung geladen werden, vergleicht die Steuerungsanwendung die auszuführende (maximale) Anzahl mit der ausgeführten Anzahl von Sicherheitsanwendungen. Würde mit der neuen Anwendung die die auszuführende Anzahl überschritten werden (also die ausgeführte Anzahl wäre größer als die auszuführende Anzahl) , kann die Steuerungsanwendung nach einem festgelegten Schema eine bereits geladene Sicherheitsanwendung entladen, was auch als ein Überschreiben betrachtet werden kann. Das festgelegte Schema kann beispielsweise festlegen, dass eine nicht mehr benötigte Sicherheitsanwendung überschrieben wird. Ist der Speicher oder die Rechenkapazität des Sicherheitsmoduls stark beschränkt, so kann beispielsweise festgelegt werden, dass nur eine einzige Sicherheitsanwendung zu einem Zeitpunkt geladen und ausgeführt werden kann. Das hat den Vorteil, dass der Speicherplatzbedarf beispielsweise auf einem FPGA gering gehalten werden kann.

Bei weiteren Ausführungsformen des Verfahrens kann anhand einer Autorisierungsinformation eine auszuführende Anzahl der Sicherheitsanwendungen festlegt werden, und/oder die Autorisierungsinformation legt fest, ob

die Sicherheitsanwendung ladbar ist; und/oder

die Sicherheitsanwendung von dem sicherheitsmodulexter- nen Speicher oder einem anderen Speicherort ladbar ist; und/oder

das Gerät sich in einem vorgegebenen Betriebsmodus be ^¬ findet, damit die Sicherheitsanwendung ladbar ist;

und/oder

für die Sicherheitsanwendung vorbestimmte Speicherberei ^¬ che des Sicherheitsmoduls oder kryptographische Funktio ^¬ nen der Steuerungsanwendung zugreifbar sind.

Die Autorisierungsinformation kann auch als Lizenzinformation bzw. Lizensierungsinformation bezeichnet werden.

Hierdurch kann das Laden und das Ausführen der Sicherheitsanwendung einfach über die Autorisierungsinformation, beispielsweise eine Sicherheitsrichtlinie oder eine Autorisie- rungspolicy, gesteuert werden. Beispielsweise kann die auszu ^¬ führende (maximale) Anzahl von Sicherheitsanwendungen beschränkt werden. Alternativ und/oder zusätzlich kann ein Zugriff auf die vorbestimmten Speicherbereiche, beispielsweise vordefinierte Speicherbereiche des ersten internen Speichers, des zweiten internen Speichers oder des dritten internen Speichers, entsprechend den Sicherheitsanforderungen festge ^¬ legt werden. Bei weiteren Ausführungsformen des Verfahrens kann die Auto- risierungsinformation als Teil der Anforderung empfangen werden, die Autorisierungsinformation in dem ersten internen Speicher abgelegt werden oder in einer Headerinformation der Sicherheitsanwendung abgelegt werden.

Hierdurch wird die Autorisierungsinformation flexibel dem Sicherheitsmodul oder der Steuerungsanwendung durch den ers- ten internen Speicher oder einen anderen internen Speicher des Sicherheitsmoduls, beispielsweise der zweite interne Speicher, der interne Anwendungsspeicher und/oder der dritte interne Speicher, bereitgestellt. Bei weiteren Ausführungsformen des Verfahrens kann beim Laden der Sicherheitsanwendung ein anwendungsspezifischer kryptog- raphischer Schlüssel bereitgestellt werden.

In einer Variante bildet die Steuerungsanwendung beispiels- weise einen anwendungsspezifischen kryptographischen Schlüssel oder anwendungsspezifische Rohdaten, einen sogenannten Primary Seed bzw. Private Primary Seed, zur Bildung eines kryptographischen Schlüssels abhängig von einer Identifizierungsinformation der geladenen Sicherheitsanwendung.

Hierdurch lässt sich die Sicherheit des Verfahrens noch wei ^¬ ter verbessern, da es vorzugsweise zu einer Sicherheitsanwendung nur einen kryptographischen Schlüssel gibt, um beispielsweise eine Sicherheitsinformation in Form einer digita- len Signatur zu überprüfen.

Bei weiteren Ausführungsformen des Verfahrens kann beim Laden der Sicherheitsanwendung ein anwendungsspezifischer Identifizierer bereitgestellt werden.

Beispielsweise kann zu einer Erstellung eines anwendungsspe ^¬ zifischen kryptographischen Schlüssels der anwendungsspezifische Identifizierer, der auch als Identifikator bezeichnet werden kann, in die Schlüsselgenerierung eingehen, um auf re produzierbare Weise einen anwendungsspezifischen kryptogra- phischen Schlüssel zu generieren.

Bei weiteren Ausführungsformen des Verfahrens können die Ver fahrensschritte durch das Sicherheitsmodul, insbesondere ei ^¬ nem Vertrauensanker, ausgeführt werden.

Beispielsweise kann durch ein exklusives Ausführen aller Ver fahrensschritte des Sicherheitsmoduls eine sehr hohe Sicher ^¬ heit des Verfahrens erreicht werden. Dabei können die weiter unten genannten Komponenten bzw. Einheiten des Sicherheitsmo duls zentral oder auch dezentral organisiert sein.

Bei weiteren Ausführungsformen des Verfahrens kann beim Über tragen der Sicherheitsanwendung eine Identitätsinformation und/oder eine Kontextinformation mit übertragen werden.

Bei weiteren Ausführungsformen des Verfahrens kann die

Sicherheitsanwendung Daten für eine danach ausgeführte

Sicherheitsanwendung bereitstellen.

Hierdurch lassen sich die Sicherheitsfunktionen von Sicherheitsanwendungen miteinander verketten und es können Vorzugs weise komplexe Anwendungsszenarien implementiert werden.

Bei weiteren Ausführungsformen des Verfahrens kann die Anfor derung zum Laden und Ausführen der Sicherheitsanwendung von dem Sicherheitsmodul erzeugt werden oder die Anforderung sicherheitsmodulextern erzeugt werden.

Hierdurch lässt sich das Verfahren flexibel für unterschied ^¬ liche Anwendungsszenarien einsetzen.

Gemäß einem weiteren Aspekt betrifft die Erfindung ein

Sicherheitsmodul, insbesondere einen Vertrauensanker, zum Be reitstellen einer Sicherheitsfunktion, insbesondere einer kryptographischen Funktion, für ein Gerät. Das Sicherheitsmo dul umfasst einen Prozessor und einen ersten internen Speicher. Das Sicherheitsmodul umfasst zusätzlich eine Schnitt ^¬ stelle zum Empfangen einer Anforderung zum Ausführen der Sicherheitsfunktion. Das Sicherheitsmodul umfasst zusätzlich eine Ladeeinheit zum Laden einer Sicherheitsanwendung für die Sicherheitsfunktion durch eine Steuerungsanwendung, wobei die Steuerungsanwendung auf dem ersten internen Speicher des Sicherheitsmoduls gespeichert ist und die Sicherheitsanwen ^¬ dung von einem sicherheitsmodulexternen Speicher übertragen wird. Das Sicherheitsmodul umfasst zusätzlich eine Überprü ^¬ fungseinheit zum Überprüfen einer Integrität der Sicherheits ^¬ anwendung mittels einer Sicherheitsinformation. Das Sicherheitsmodul umfasst eine Ausführungseinheit zum Ausführen der Sicherheitsanwendung und zum Bereitstellen der Sicherheitsfunktion, wobei das Ausführen und das Bereitstellen nur nach dem erfolgreichen Überprüfen der Integrität durchgeführt werden .

Dabei können die Einheiten des Sicherheitsmoduls zentral oder auch dezentral organisiert sein.

Gemäß einem weiteren Aspekt betrifft die Erfindung ein Gerät, das ein erfinderisches Sicherheitsmodul und/oder ein erfinde- risches anwendungsspezifisches Sicherheitsmodul oder mehrere erfinderische anwendungsspezifisehe Sicherheitsmodule auf- weist .

Unter einem anwendungsspezifischen Sicherheitsmodul kann ein erfindungsgemäßes Sicherheitsmodul verstanden werden, das beispielsweise aufgrund einer Autorisierungsinformation nur bestimmte Sicherheitsanwendungen ausführt. Es kann beispiels ^¬ weise auch nur eine vordefinierte Sicherheitsanwendung auf einem anwendungsspezifischen Sicherheitsmodul ausgeführt werden. Hierdurch kann beispielsweise das Gerät mehrere Sicher ^¬ heitsanwendungen parallel auf mehreren Sicherheitsmodulen verwenden . Desweiteren wird ein Computerprogrammprodukt mit Programmbe ^¬ fehlen zur Durchführung des genannten erfindungsgemäßen Verfahrens beansprucht. Zusätzlich wird eine Variante des Computerprogrammproduktes mit Programmbefehlen zur Konfiguration eines Erstellungsgeräts, beispielsweise ein 3D-Drucker oder ein ähnliches Gerät, beansprucht, wobei das Erstellungsgerät mit den Programmbe ^¬ fehlen derart konfiguriert wird, dass die genannte erfin- dungsgemäße Vorrichtung erstellt wird.

Darüber hinaus wird eine Bereitstellungsvorrichtung zum Speichern und/oder Bereitstellen des Computerprogrammprodukts be ^¬ ansprucht. Die Bereitstellungsvorrichtung ist beispielsweise ein Datenträger, der das Computerprogrammprodukt speichert und/oder bereitstellt. Alternativ und/oder zusätzlich ist die Bereitstellungsvorrichtung beispielsweise ein Netzwerkdienst, ein Computersystem, ein Serversystem, insbesondere ein verteiltes Computersystem, ein cloudbasiertes Rechnersystem und/oder virtuelles Rechnersystem, welches das Computerpro ^¬ grammprodukt vorzugsweise in Form eines Datenstroms speichert und/oder bereitstellt.

Diese Bereitstellung erfolgt beispielsweise als Download in Form eines Programmdatenblocks und/oder Befehlsdatenblocks, vorzugsweise als Datei, insbesondere als Downloaddatei, oder als Datenstrom, insbesondere als Downloaddatenstrom, des vollständigen Computerprogrammprodukts. Diese Bereitstellung kann beispielsweise aber auch als partieller Download erfol- gen, der aus mehreren Teilen besteht und insbesondere über ein Peer-to-Peer Netzwerk heruntergeladen oder als Datenstrom bereitgestellt wird. Ein solches Computerprogrammprodukt wird beispielsweise unter Verwendung der Bereitstellungsvorrichtung in Form des Datenträgers in einem System eingelesen und führt die Programmbefehle aus, sodass das erfindungsgemäße Verfahren auf einem Computer zur Ausführung gebracht wird oder das Erstellungsgerät derart konfiguriert wird, dass die ^¬ ses die erfindungsgemäße Vorrichtung erstellt. Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusam- menhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Figuren näher erläutert werden. Dabei zeigen in schematischer Darstellung:

Fig. 1 ein Ablaufdiagramm eines ersten Ausführungsbei- spiels des offenbarten Verfahrens;

Fig. 2 ein Bereitstellen einer Sicherheitsfunktion mittels des offenbarten Verfahrens in einem zweiten Ausführungsbeispiel;

Fig. 3 ein Bereitstellen einer Sicherheitsfunktion mittels des offenbarten Verfahrens in einem dritten Ausführungsbeispiel; Fig. 4 ein autorisiertes Laden einer Sicherheitsanwendung zum Bereitstellen einer Sicherheitsfunktion entsprechend einem vierten Ausführungsbeispiel des of ^¬ fenbarten Verfahrens; Fig. 5 ein Sicherheitsmodul eines fünften Ausführungsbei ^¬ spiels; und

Fig. 6 ein Gerät eines sechsten Ausführungsbeispiels.

In den Figuren sind funktionsgleiche Elemente mit denselben Bezugszeichen versehen, sofern nichts anderes angegeben ist.

Fig. 1 ist ein Ablaufdiagramm eines ersten Ausführungsbei- spiels des offenbarten Verfahrens 100.

Das Verfahren 100 ist in der Lage, einem Gerät, beispielswei ^¬ se einem Messgerät für die Hochfrequenztechnik, ein Messge- rät, ein Steuergerät, ein Empfangsgerät einer Satellitenkom ^¬ munikationsstation oder ein Feldgerät einer Kraftwerksanlage, eine Sicherheitsfunktion, beispielsweise eine kryptographi- sche Funktion, bereitzustellen.

Um die Sicherheitsfunktion bereitzustellen, wird beispielsweise in dem Gerät ein Sicherheitsmodul installiert oder das Sicherheitsmodul ist eine Teilkomponente des Gerätes, wobei das Sicherheitsmodul insbesondere mehrere, vorzugsweise alle der nachfolgenden Verfahrensschritte ausführt.

In einem ersten Verfahrensschritt wird eine Anforderung zum Ausführen der Sicherheitsfunktion, beispielsweise über eine Kommunikationsschnittstelle, empfangen. Bei der Sicherheits- funktion kann es sich beispielsweise um eine kryptographische Funktion handeln, die insbesondere kryptographische Schlüs ^¬ sel, digitale Zertifikate oder kryptographische Funktionen bereitstellt. Die kryptographischen Funktionen können beispielsweise kryptographische Verfahren wie den Advanced Enc- ryption Standard (AES) implementieren. Alternativ und/oder zusätzlich können beispielsweise Lizenzinformationen zum Freischalten von Funktionen des Gerätes bereitgestellt werden. Die Lizenzinformationen können beispielsweise Messalgorithmen eines Messgerätes oder Frequenzbereiche freischalten, die von Messalgorithmen verarbeitet werden können.

In einem zweiten Verfahrensschritt 120 wird eine Sicherheits ^¬ anwendung für die Sicherheitsfunktion durch eine Steuerungsanwendung geladen, wobei die Steuerungsanwendung auf einem ersten internen Speicher des Sicherheitsmoduls gespeichert ist und die Sicherheitsanwendung von einem sicherheitsmodul- externen Speicher übertragen wird. Die Sicherheitsanwendung stellt dabei die angeforderte Sicherheitsfunktion bereit. Die Steuerungsanwendung wird während des Betriebes des

Sicherheitsmoduls vorzugsweise sicherheitsmodulintern ausge ^¬ führt, sodass vorzugsweise eine sicherheitsmodulexterne Ver- änderung, häufig auch als externe Veränderung bezeichnet, der Steuerungsanwendung unterbunden wird.

Die Sicherheitsanwendung selbst kann beispielsweise als ein Teil der Anforderung empfangen werden. Zusätzlich und/oder alternativ kann die Anforderung auch einen Speicherort angeben, von dem die Sicherheitsanwendung geladen werden kann.

Die Sicherheitsanwendung wird dabei vorzugsweise in den ers- ten internen Speicher oder in einen internen Anwendungsspeicher des Sicherheitsmoduls geladen. Unter einem externen Speicher kann hierbei eine Speichereinrichtung, beispielsweise eine Festplatte des Gerätes, verstanden werden, die nicht innerhalb des Sicherheitsmoduls angeordnet ist.

In einer Variante wird die Sicherheitsanwendung durch die Steuerungsanwendung ausgewählt. Dabei können beispielsweise eine oder mehrere Sicherheitsanwendungen einer bestimmten Sicherheitsfunktion fest zugeordnet sein. Diese Zuordnung kann beispielsweise als eine Liste, als eine Umsetzungstabel ^¬ le (engl, lookup table) oder in der Anforderung gespeichert sein .

In einem dritten Verfahrensschritt 130 wird eine Integrität der Sicherheitsanwendung anhand einer Sicherheitsinformation, beispielsweise einer Integritätsinformation, überprüft. Dies kann beispielsweise mittels einer Integritätsinformation in Form eines digitalen Zertifikates, einer digitalen Signatur oder einer Prüfsumme geschehen, die in der Anforderung ent- halten war. Eine Implementierung mittels digitaler Signaturen lässt sich beispielsweise mit dem RSA (Rivest, Shamir,

Adleman) , dem DSA (Digital Signature Algorithm) oder dem ECDSA (Elliptic Curve Digital Signature Algorithm) realisie ^¬ ren .

In einer Variante sind die Sicherheitsanwendungen verschlüsselt abgespeichert und werden mittels eines ersten kryptogra- phischen Schlüssels vor dem Überprüfen entschlüsselt. Sofern die Überprüfung der Integrität erfolgreich war, wird in einem vierten Verfahrensschritt 140 die Sicherheitsanwendung ausgeführt und die angeforderte Sicherheitsfunktion bei- spielsweise über die Kommunikationsschnittstelle bereitge ^¬ stellt. Mit anderen Worten wird die Sicherheitsanwendung infolge einer erfolgreichen Prüfung der Integrität ausgeführt. Somit wird bei einem Fehlschlag der Überprüfung ein Ausführen der Sicherheitsanwendung und des Bereitstellens der Sicher- heitsfunktion unterbunden.

Mit anderen Worten wird vor dem Ausführen der Sicherheitsanwendung im Sicherheitsmodul vorzugsweise die Integrität der Sicherheitsanwendung überprüft. Falls die Sicherheitsanwen- dung verschlüsselt ist, wird diese vor dem Überprüfen ent ^¬ schlüsselt .

Das „Ausführen" einer Sicherheitsanwendung kann auch als sicherheitsmodulinternes Aktivieren des Codes oder Programm- codes der Sicherheitsanwendung bezeichnet werden.

Ist beispielsweise die zu ladende Sicherheitsanwendung ver ^¬ schlüsselt, so kann dies mit einem symmetrischen oder einem asymmetrischen kryptographisches Verfahren durchgeführt wor- den sein. Der notwendige erste kryptographische Schlüssel zum Entschlüsseln der Sicherheitsanwendungen ist vorzugsweise im Sicherheitsmodul gespeichert, beispielswiese dem ersten in ^¬ ternen Speicher. Der erste kryptographische Schlüssel ist vorzugsweise vor sicherheitsmodulexternen Zugriffen ge- schützt, sodass vorzugsweise nur ein Zugriff durch die Steue ^¬ rungsanwendung auf den ersten kryptographischen Schlüssel erfolgen kann.

Dieser erste kryptographische Schlüssel kann beispielsweise während der Fertigung des Sicherheitsmoduls oder durch eine kryptographisch geschützte Aktualisierung auf dem Sicherheitsmodul gespeichert werden. Mit anderen Worten wird ein Verfahren offenbart, bei dem eine Anwendung, beispielsweise die Sicherheitsanwendung, des

Sicherheitsmoduls, beispielsweise eines Vertrauensankers, zu ^¬ nächst nicht intern gespeichert werden muss, sondern auch ex- tern vorliegen kann, und dass diese beispielsweise durch au ^¬ torisierte Entitäten auch austauschbar sein kann. Unter einer autorisierten Entität kann dabei eine Komponente des Gerätes verstanden werden, die eine Anforderung an den Vertrauensanker sendet und die notwendigen Informationen zur Prüfung der Integrität bereitstellen kann.

Dabei ist die Software, die auf dem Vertrauensanker bereit ^¬ steht, zunächst auf die Steuerungsanwendung beschränkt. Also auf dem Vertrauensanker steht vorzugsweise zunächst nur die Steuerungsanwendung zur Verfügung. Mit anderen Worten sind permanent auf dem Vertrauensanker gespeicherte Daten auf die Steuerungsanwendung beschränkt, da die Sicherheitsanwendung oder weitere Sicherheitsanwendungen in den Vertrauensanker geladen werden können und von dem Vertrauensanker gelöscht werden können.

Die Steuerungsanwendung ist in der Lage eine Anwendung, beispielsweise die Sicherheitsanwendung, von einem externen Speicher oder von der empfangenen Anforderung in den Vertrau- ensanker nachzuladen, wobei die Steuerungsanwendung fest im Vertrauensanker kodiert ist. Das bedeutet, dass insbesondere die Sicherheitsfunktion oder weitere Sicherheitsfunktionen die vom Vertrauensanker bereitgestellt werden sollen, vorzugsweise mittels eines Nachladens und eines Ausführens der Sicherheitsanwendung oder weiterer Sicherheitsanwendungen in den Vertrauensanker, bereitgestellt werden.

Im Vertrauensanker wird zu einem Zeitpunkt vorzugsweise nur eine Sicherheitsanwendung ausgeführt. Um Sicherheitsanwendun- gen die Möglichkeit zu geben, Daten, beispielsweise generier ^¬ te kryptographische Schlüssel oder Prüfsummen, sicher an spä ^¬ ter geladene Sicherheitsanwendungen weiter zu geben, kann der Vertrauensanker einen vorzugsweise exklusiv dafür genutzten zweiten internen Speicher, beispielsweise einen flüchtigen Speicher, aufweisen.

Die Steuerungsanwendung bleibt beim Laden und Ausführen der Sicherheitsanwendung vorzugsweise unverändert. Zugleich stellt die Steuerungsanwendung insbesondere sicher, dass die Konsistenz, also das korrekte Ausführen von Sicherheitsfunktionen, des vorzugsweise kompletten Systems im Vertrauensanker sichergestellt ist.

In einer ersten Implementierungsvariante kann die Konsistenz dadurch sichergestellt werden, dass eine neue Sicherheitsanwendung zunächst in einen dritten internen Speicher, beispielsweise einem Zwischenpuffer, des Sicherheitsankers gela- den wird. Sobald die Sicherheitsanwendung in dem dritten internen Speicher geladen ist, wird diese Sicherheitsanwendung, falls notwendig, entschlüsselt und auf ihre Integrität ge ^¬ prüft. Ist das Prüfen der Integrität erfolgreich, wird die Sicherheitsanwendung ausgeführt, was auch als aktiv geschal- tet bezeichnet werden kann. Die vorherige Sicherheitsanwendung kann dann deaktiviert und gegebenenfalls überschrieben werden .

In der ersten Implementierungsvariante ist es ausreichend, eine digitale Signatur oder einen MAC (Message Authentication Code) über die geladene Sicherheitsanwendung nach erfolgtem Laden zu überprüfen. Falls das Überprüfen der Integrität fehlschlägt, wird der Zwischenpuffer wieder freigegeben und die geladene Sicherheitsanwendung wird nicht ausgeführt.

In einer zweiten Implementierungsvariante teilen sich eine neu geladene Sicherheitsanwendung und die alte Sicherheitsanwendung, also eine vorher geladene Sicherheitsanwendung, die nicht mehr benötigt wird, einen gemeinsamen Speicherbereich im Vertrauensanker. Dieser Speicherbereich kann vorzugsweise im ersten internen Speicher oder der interne Anwendungsspeicher des Vertrauensankers sein. Die alte Sicherheitsanwendung wird insbesondere bereits beim Laden der neuen Sicherheitsan- wendung ersetzt. In diesem Fall wird vorzugsweise sicherge ^¬ stellt, dass bei einem Fehler während des Ladens das Nachla ^¬ den einer geeigneten Sicherheitsanwendung weiterhin möglich ist .

In der zweiten Implementierungsvariante ist es gegebenenfalls sinnvoll, zunächst eine Headerinformation der neuen Sicherheitsanwendung zu übertragen und die Integrität dieser Headerinformation zu überprüfen. Erst nachdem eine Überprüfung der Headerinformation erfolgreich war, wird infolgedessen die Sicherheitsanwendung übertragen und die alte Sicherheitsanwendung ersetzt. Eine Überprüfung der Integrität der Sicherheitsanwendung wird vorzugsweise nach abgeschlossener Übertragung zusätzlich durchgeführt. In die Headerinformation können beispielsweise Informationen über die zu ladende

Sicherheitsanwendung einfließen wie Version, Größe und/oder auszuführende Sicherheitsfunktionen .

In einer weiteren Variante kann mittels einer Autorisierungs- Information, beispielsweise eine Sicherheitsrichtlinie in Form einer Authorization Policy, festgelegt werden, welche nachladbaren Sicherheitsanwendungen genutzt werden dürfen und/oder aus welcher (Daten-) Quelle diese Sicherheitsanwendungen stammen dürfen. Dabei können nachfolgende Kriteri- en/Daten für eine Sicherheitsrichtlinie genutzt werden, für die beispielsweise eine Liste, häufig auch (Anwendungs/Si- cherheitsanwendungs ) Whitelist genannt, erstellt wird.

Sicherheitsanwendungen können beispielsweise nach deren Quel- le zugelassen werden. Es ist beispielsweise möglich, den „Subj ectName" und/oder den „Subj ectAltName" des digitalen Zertifikates, mit dem die digitale Signatur der Sicherheits ^¬ anwendung erstellt wurde, zu verwenden. Alternativ und/oder zusätzlich kann auch die Seriennummer und/oder der Aussteller des Zertifikates, mit dem die digitale Signatur der Sicher ^¬ heitsanwendung erstellt wurde, verwendet werden. Sicherheitsanwendungen können aber auch nach deren Kennzeichnung zugelassen werden. Es ist beispielsweise möglich, einen anwendungsspezifischen Identifizierer einer Sicherheitsanwendung zum Abgleich mit einer Liste von erlaubten Sicherheits- anwendungen zu verwenden. Alternativ und/oder zusätzlich kann auch ein Fingerabdruck (engl, fingerprint) einer Sicherheitsanwendung, beispielsweise in Form eines kryptographischen hash-Werts oder einer digitalen Signatur, verwendet werden. Alternativ und/oder zusätzlich zur beschriebenen Liste kann die Autorisierungsinformation auch in der Headerinformation der jeweiligen nachladbaren Sicherheitsanwendung eingetragen werden. Der Vorteil dieses Ansatzes liegt darin, dass die Autorisierungsinformation nicht explizit in Form einer Liste geladen wird und damit nicht zusätzlichen Speicherplatz im Vertrauensanker benötigt.

Neben der Autorisierungsinformation kann zusätzlich auch der Betriebsmodus des Gerätes in die Autorisierung des Ladens ei- ner Sicherheitsanwendung mit einbezogen werden. Ein Beispiel hierfür ist: wenn es sich um ein Gerät mit einer bestimmten Sicherheitszulassung handelt, darf im Falle einer Sicherheitskritischen Operation kein Code nachgeladen/ausgetauscht werden. Hierzu können weitere Schnittstellen am Vertrauensan- ker notwendig sein, um diese Zustandsinformation mit auszuwerten .

Weiterhin kann anhand der Autorisierungsinformation festgelegt werden, auf welche kryptographischen Schlüssel oder wel- che kryptographischen Operationen des Vertrauensankers die Sicherheitsanwendung zugreifen kann. Dazu kann der Zugriff auf manche vordefinierte Speicherbereiche, wie beispielsweise Schlüsselspeicherbereiche, vordefinierte Funktionsaufrufe oder Opcodes, gesperrt werden.

In einer weiteren Variante wird für eine geladene Sicherheitsanwendung ein dafür anwendungsspezifischer kryptographi- scher Schlüssel bereitgestellt. Dieser kann beispielsweise beim Laden der Sicherheitsanwendung gebildet werden, oder der anwendungsspezifische krypto- graphische Schlüssel kann bei Nutzung einer kryptographischen Operation oder bei einem Zugriff auf einen Schlüsselspeicher gebildet werden. Der anwendungsspezifische kryptographische Schlüssel kann dabei zufällig gewählt werden oder er kann de ^¬ terministisch durch eine Schlüsselableitung gebildet werden. In die Schlüsselableitung geht vorzugsweise ein sicherheits- anwendungsabhängiger Ableitungsparameter ein, beispielsweise ein anwendungsspezifischer Identifizierer, eine Prüfsumme der Sicherheitsanwendung, z.B. ein kryptographischer Hash-Wert, oder eine Herausgeberinformation der Sicherheitsanwendung. Insbesondere kann abhängig von einem Master Key des Vertrau- ensankers ein anwendungsspezifischer Master Key gebildet werden und der Sicherheitsanwendung als anwendungsspezifischer Master Key bereitgestellt werden.

Unter Master Key wird hier auch eine Information verstanden, die zur Bildung eines oder mehrerer kryptographischen Schlüssel verwendbar ist, ein sogenannter Private Primary Seed. Ein Private Primary Seed kann als Eingabeparameter für unterschiedliche Schlüsselbildungsfunktionen verwendet werden, um deterministisch einen privaten Schlüssel bzw. ein Schlüssel- paar aus privatem und öffentlichem Schlüssel zu bilden.

In einer weiteren Variante wird analog zum Bereitstellen des anwendungsspezifischen kryptographischen Schlüssels ein anwendungsspezifischer Identifizierer der Sicherheitsanwendung bereitgestellt. Dadurch können beispielsweise für unter ^¬ schiedliche Sicherheitsanwendungen des Vertrauensankers un ^¬ terschiedliche anwendungsspezifische Identifizierer bereitge ^¬ stellt werden. Dadurch wird erreicht, dass eine Sicherheits ^¬ anwendung nicht den gleichen Identifizierer wie eine andere Sicherheitsanwendung des gleichen Vertrauensankers verwenden kann. Der Identifizierer kann der Sicherheitsanwendung beispielsweise kryptographisch geschützt bereitgestellt werden (Attestierung) oder er kann in einer Schlüsselableitung, die durch die Sicherheitsanwendung angestoßen wurde, als Ableitungsparameter verwendet werden.

Die Fig. 2 zeigt ein Bereitstellen einer Sicherheitsfunktion durch ein Sicherheitsmodul eines zweiten Ausführungsbeispiels 200. In Einzelnen wird eine Variante des Verfahrens verwen ^¬ det, welches in Fig. 1 beschrieben wurde.

Die Fig. 2 zeigt ein Sicherheitsmodul 230, das eine Steue- rungsanwendung 232 umfasst. Darüber hinaus zeigt Fig. 2 sicherheitsmodulexterne Komponenten wie ein Betriebssystem 220, beispielsweise einen Linux-Kernel, mit Treibern 222, ei ^¬ ne Ladeanwendung 210 des Betriebssystems 220, eine erste Sicherheitsanwendung 214 und eine n-te Sicherheitsanwendung 216. Die sicherheitsmodulexternen Komponenten können ein Teil eines Gerätes sein, indem das Sicherheitsmodul 230 verbaut ist .

Das Sicherheitsmodul 230 ist beispielsweise ein Vertrauensan- ker, der als ein FPGA-Modul realisiert ist. Eine Integrität der Sicherheitsanwendungen ist mit einem kryptographischen Algorithmus, beispielsweise dem HMAC-SHA256 (Keyed-Hash Mes ^¬ sage Authentication Code, Secure Hash Algorithm 256) , geschützt und als Integritätsinformation zusammen mit den

Sicherheitsanwendungen auf einem sicherheitsmodulexternen

Speicher abgelegt. Die Ladeanwendung 210 des Betriebssystems 220 wählt beispielsweise die erste Sicherheitsanwendung 214 aus, damit der Vertrauensanker 230 eine Sicherheitsfunktion der ersten Sicherheitsanwendung 214 ausführt und bereit- stellt.

Die Ladeanwendung 210 übergibt dazu die erste Sicherheitsanwendung 214 mit der Integritätsinformation, beispielsweise eine digitale Signatur über die Integritätsinformation, dem Betriebssystem 220, damit das Betriebssystem 220 über den

Treiber 222 an den Sicherheitsanker 230 eine Datenübertragung 201 durchführen kann und eine Anforderung zur Bereitstellung der Sicherheitsfunktion der ersten Sicherheitsanwendung 214 stellen kann.

Der Treiber 222 schickt also eine Anforderung, die die

Sicherheitsanwendung und die Integritätsinformation umfasst, an den Vertrauensanker 230, damit der Vertrauensanker die erste Sicherheitsanwendung 214 ausführt und die Sicherheits ^¬ funktion bereitstellt. Hierzu wird die erste Sicherheitsan ^¬ wendung 214 durch die Steuerungsanwendung 232 in einen zwei- ten internen Speicher des Vertrauensankers geladen, und die

Steuerungsanwendung 232 überprüft anschließend die Integrität der ersten Sicherheitsanwendung 214 mit Hilfe der IntegritätsInformation . Erst wenn die Überprüfung der Integrität der ersten Sicherheitsanwendung 214 erfolgreich war, wird diese als eine im Vertrauensanker 230 auszuführende Sicherheitsanwendung 234 angesehen . Die Steuerungsanwendung 232 lädt dann beispielsweise von dem zweiten internen Speicher die erste Sicherheitsanwendung 214 in einen ersten internen Speicher des Vertrauensankers oder in einen internen Anwendungsspeicher des Vertrauensankers. Die erste Sicherheitsanwendung 214 wird dann ausgeführt und die angeforderte Sicherheitsfunktion dem Betriebssystem 220 bereitgestellt .

Die Fig. 3 zeigt ein Bereitstellen einer Sicherheitsfunktion durch ein Sicherheitsmodul eines dritten Ausführungsbeispiels 300. In Einzelnen wird eine Variante des Verfahrens verwen ^¬ det, welches in Fig. 1 beschrieben wurde verwendet.

Die Fig. 3 zeigt ein Sicherheitsmodul 330, das eine Steue ^¬ rungsanwendung 232 und einen dritten internen Speicher 336 des Sicherheitsmoduls 330 umfasst. Darüber hinaus zeigt Fig. 3 sicherheitsmodulexterne Komponenten wie ein Betriebssystem 220, beispielsweise einen Linux-Kernel, mit Treibern 222, ei ^¬ ne Ladeanwendung 210 des Betriebssystems 220, eine erste Sicherheitsanwendung 214 und zweite Sicherheitsanwendung 316. Die sicherheitsmodulexternen Komponenten können ein Teil eines Gerätes sein, in dem das Sicherheitsmodul 330 verbaut ist .

Das Sicherheitsmodul 330 ist beispielsweise ein Vertrauensan ^¬ ker, der als ein FPGA-Modul realisiert ist. Eine Integrität der Sicherheitsanwendungen ist mit einem kryptographischen Algorithmus, beispielsweise dem HMAC-SHA256 (Keyed-Hash Mes- sage Authentication Code, Secure Hash Algorithm 256) , geschützt und als Integritätsinformation zusammen mit den

Sicherheitsanwendungen auf einem sicherheitsmodulexternen Speicher abgelegt. Die Ladeanwendung 210 des Betriebssystems 220 wählt beispielsweise die erste Sicherheitsanwendung 214 zu einem ersten Zeitpunkt ti aus, damit der Vertrauensanker 230 eine erste Sicherheitsfunktion der ersten Sicherheitsanwendung 214 ausführt und bereitstellt.

Die Ladeanwendung 210 des Betriebssystems 220 wählt bei- spielsweise die zweite Sicherheitsanwendung 316 zu einem zweiten Zeitpunkt t ₂ aus, damit der Vertrauensanker 230 eine zweite Sicherheitsfunktion der zweiten Sicherheitsanwendung 316 ausführt und bereitstellt. Die Ladeanwendung 210 übergibt dazu die erste Sicherheitsan ^¬ wendung 214 mit der zugehörigen Integritätsinformation, beispielsweise eine digitale Signatur über die Integritätsinformation, dem Betriebssystem 220, damit das Betriebssystem 230 über den Treiber 222 an den Sicherheitsanker 330 eine erste Datenübertragung 301 zu dem ersten Zeitpunkt ti durchführen kann und eine erste Anforderung zur Bereitstellung der ersten Sicherheitsfunktion der ersten Sicherheitsanwendung 214 stellen kann. Analog wird eine zweite Datenübertragung 302 zum zweiten

Zeitpunkt t ₂ für die zweite Sicherheitsanwendung 316 durchge ^¬ führt. Die zweite Sicherheitsfunktion wird dann analog zur ersten Sicherheitsfunktion bereitgestellt. Der Treiber 222 schickt hierzu beispielsweise die erste An ^¬ forderung, die die erste Sicherheitsanwendung 214 und die zugehörigen Integritätsinformationen umfasst, zum ersten Zeit- punkt ti an den Vertrauensanker 330, damit der Vertrauensanker 330 die erste Sicherheitsanwendung 214 ausführt und die erste Sicherheitsfunktion bereitstellt.

Der Treiber 222 schickt zum zweiten Zeitpunkt t ₂ beispiels- weise eine zweite Anforderung, die die zweite Sicherheitsan ^¬ wendung 316 und die zugehörige Integritätsinformation umfasst, an den Vertrauensanker 330, damit der Vertrauensanker 330 die zweite Sicherheitsanwendung 316 ausführt und die zweite Sicherheitsfunktion bereitstellt.

Zunächst wird die erste Sicherheitsanwendung 214 durch die Steuerungsanwendung 232 in einen zweiten internen Speicher des Vertrauensankers geladen, und die Steuerungsanwendung 232 überprüft anschließend die Integrität der ersten Sicherheits- anwendung 214 mit Hilfe der Integritätsinformation.

Erst wenn die Überprüfung der Integrität der ersten Sicherheitsanwendung erfolgreich war, wird diese als eine im Vertrauensanker 230 auszuführende Sicherheitsanwendung 234 ange- sehen.

Die Steuerungsanwendung 232 lädt dann beispielsweise von dem zweiten internen Speicher die erste Sicherheitsanwendung 214 in einen ersten internen Speicher des Vertrauensankers oder in einen internen Anwendungsspeicher des Vertrauensankers. Die erste Sicherheitsanwendung 214 wird dann ausgeführt und die angeforderte Sicherheitsfunktion dem Betriebssystem 220, dem Vertrauensanker 330 oder der Steuerungsanwendung 232 bereitgestellt. Die erste Sicherheitsanwendung 214 oder die erste Sicherheitsfunktion kann auch Daten generieren, die auf einem dritten internen Speicher 336 des Sicherheitsmoduls abgelegt werden, damit die zweite Sicherheitsanwendung 316 die ^¬ se zu einem späteren Zeitpunkt nutzen kann. Wenn die zweite Sicherheitsanwendung 316 analog zur ersten Sicherheitsanwendung 214 geladen und ausgeführt wird, kann die zweite Sicherheitsfunktion die von der ersten Sicher- heitsfunktion generierten Daten aus dem dritten internen Speicher 336 lesen und verarbeiten.

Auf diese Weise lassen sich beliebig viele Sicherheitsanwendungen nacheinander laden und die Sicherheitsanwendungen kön- nen über den dritten internen Speicher 336 Daten sicherheitsgeschützt austauschen.

Durch dieses Nacheinanderschalten von Sicherheitsanwendungen wird es möglich, komplexe Funktionalitäten, die insgesamt die Ressourcen des Vertrauensankers übersteigen würden, durch eine Sequenz von Sicherheitsanwendungen zu realisieren. Beispielsweise kann die Berechnung einer SHA256-ECDSA Signatur in die Berechnung des Hashs (SHA256) und der Signatur (ECDSA) unterteilt werden. Dabei berechnet die erste Sicherheitsan- wendung 214 den SHA256 Hash, auch Prüfsumme genannt. Die zweite Sicherheitsanwendung 316 berechnet eine digitale Sig ^¬ natur. Der benötigte Zwischenwert (Hashwert) wird über den dritten internen Speicher 336 ausgetauscht. Der Vertrauensanker kann beispielsweise auch eine Stack- Maschine realisieren, die jeweils einzelne Befehle nachlädt.

In einer Variante enthält die erste Anforderung bereits alle auszuführenden Sicherheitsanwendungen, deren Integritätsin- formation und eine Information über die angeforderten Sicher- heitsfunktionen .

In einer weiteren Variante stellt die erste Sicherheitsanwendung Daten für eine danach ausgeführte Sicherheitsanwendung bereit. Im Einzelnen kann hierdurch beispielsweise eine Auto ^¬ risierung von der ersten Sicherheitsanwendung 214 zu der zweiten Sicherheitsanwendung 316 implementiert werden. Dabei hinterlegt die erste Sicherheitsanwendung neben den (optiona- len) Zwischenwerten einen Authentisierungstoken, beispielsweise in dem dritten internen Speicher 336 des Sicherheitsmoduls 330. Das Authentisierungstoken wird ausgewertet, bevor die Berechnung fortgesetzt wird. Dabei sind zwei Implementie- rungsvarianten vorstellbar:

Bei der ersten Implementierungsvariante legt die erste

Sicherheitsanwendung oder die erste Sicherheitsfunktion eine Beschränkung fest, dass nur bestimmte Sicherheitsanwendungen später nachgeladen und/oder ausgeführt werden können. Die Beschränkung wird durch die Steuerungsanwendung 232 des Vertrauensankers durchgesetzt.

In der zweiten Implementierungsvariante ist ein Akzeptieren von Zwischenergebnissen von vorher ausgeführten Sicherheitsanwendungen, beispielsweise der ersten Sicherheitsanwendung 214, durch die zweite Sicherheitsanwendung 316 auf vorgegebene Zwischenergebnisse beschränkt. Das Beschränken wird in der zweiten Implementierung von der zweiten Sicherheitsanwendung 316 durchgesetzt.

In einer weiteren Variante können die vorherigen Ausführungsbeispiele dahingehend erweitert werden, dass zusätzlich zur Überprüfung der Integrität auch noch die Autorisierung für das Nachladen bestimmter Sicherheitsanwendungen überprüft wird. Die damit zusammenhängende Autorisierungsinformation kann vom Gerätebetreiber erstellt werden und kann beispielsweise in Form einer signierten Information zur Verfügung gestellt werden. Dazu verfügt die Steuerungsanwendung über eine Erweiterung, die das Festlegen einer Besitzerinformation oder Operatorinformation ermöglicht. Dies kann während der Produktion oder auch bei der Inbetriebnahme realisiert werden. Ein möglicher Ablauf beim Laden in der Variante mit einer externen Autorisierungsinformation, beispielsweise eine Autorisie- rungs-Policy, ist aus Sicht des Sicherheitsmoduls in Fig. 4 dargestellt . Im Einzelnen zeigt Fig. 4 ein Ablaufdiagramm mit einem Startelement 405 und einem Endelement 460.

In einem ersten Verfahrensschritt 410 wird beispielsweise versucht, die Besitzerinformation oder die Operatorinformati ^¬ on zu lesen. In einem zweiten Verfahrensschritt 415 wird überprüft, ob die Besitzerinformation oder die Operatorinformation lesbar war. Falls das Überprüfen fehlschlägt, also die Besitzerinformati ^¬ on oder die Operatorinformation nicht vorhanden ist, wird beispielsweise in einem Verfahrensschritt 420 eine (Daten-) Quelle der nachzuladenden Sicherheitsanwendung oder eine Art, beispielsweise ein bestimmter Typ von Sicherheitsanwendungen wie Verschlüsselungsanwendungen, der nachzuladenden Sicherheitsanwendung uneingeschränkt zum Laden und Ausführen akzeptiert .

Falls das Überprüfen erfolgreich ist, also die Besitzerinfor- mation oder die Operatorinformation vorhanden ist, wird beispielsweise in einem Verfahrensschritt 425 die Autorisie- rungsinformation geladen und die Authentizität der Autorisie- rungsinformation verifiziert. In einem Verfahrensschritt 430 wird dann entschieden, welche weiteren Verfahrensschritte anhand des Ergebnisses des Veri ^¬ fizierens ausgeführt werden sollen.

Falls das Verifizieren fehlschlägt, wird beispielsweise in einem Verfahrensschritt 435 eine Fehlermeldung ausgegeben und die Sicherheitsanwendung nicht geladen und/oder ausgeführt.

Falls das Verifizieren erfolgreich ist, wird beispielsweise in einem Verfahrensschritt 440 die Sicherheitsanwendung gela- den und deren Integrität überprüft. Alternativ und/oder zu ^¬ sätzlich wird die Autorisierungsinformation geladen und die Sicherheitsanwendung und/oder deren Sicherheitsfunktion überprüft, ob diese ausführbar sind. In einem Verfahrensschritt 445 wird dann über eine Ausführung der Sicherheitsanwendung anhand eines Ergebnisses der Überprüfung der Integrität und/oder Autorisierungsinformation entschieden.

Ist die Überprüfung erfolgreich, wird beispielsweise in einem Verfahrensschritt 455 die Sicherheitsanwendung ausgeführt und die Sicherheitsfunktion der Sicherheitsanwendung demjenigen bereitgestellt, der diese angefordert hat.

Ist die Überprüfung fehlgeschlagen, wird beispielsweise in einem Verfahrensschritt 450 eine Fehlermeldung ausgegeben und eine Ausführung der Sicherheitsanwendung unterbunden.

Die Fig. 5 zeigt ein Sicherheitsmodul 500 eines fünften Aus ^¬ führungsbeispiels .

Das Sicherheitsmodul 500, das beispielsweise als ein Vertrau- ensanker realisiert ist, stellt eine Sicherheitsfunktion, beispielsweise eine kryptographischen Funktion, für ein Gerät bereit. Das Sicherheitsmodul 500 umfasst einen Prozessor 510, einen ersten internen Speicher 520, eine Ladeeinheit 530, eine Überprüfungseinheit 540, eine Ausführungseinheit 550 und eine Schnittstelle 585, die mittels eines ersten Busses 580 kommunikativ miteinander in Verbindung stehen.

Im Einzelnen empfängt die Schnittstelle 585 eine Anforderung zum Ausführen einer Sicherheitsfunktion. Die Ladeeinheit 530 lädt eine Sicherheitsanwendung für die Sicherheitsfunktion mittels einer Steuerungsanwendung, wobei die Steuerungsanwendung auf einem ersten internen Speicher 520 des Sicherheitsmoduls 500 gespeichert wird und die Sicherheitsanwendung von einem sicherheitsmodulexternen Speicher übertragen wird.

Die Sicherheitsanwendung wird dann beispielsweise durch den Prozessor 510 sicherheitsmodulintern ausgeführt, sodass das in den Fig. 1-4 offenbarte Verfahren rechnergestützt ausge ^¬ führt werden kann.

Die Überprüfungseinheit 540 überprüft eine Integrität der Sicherheitsanwendung anhand einer Sicherheitsinformation. Die Ausführungseinheit 550 führt die Sicherheitsanwendung aus und stellt die Sicherheitsfunktion beispielsweise über die

Schnittstelle 585 bereit, wobei das Ausführen und Bereitstel ^¬ len nur nach dem erfolgreichen Überprüfen der Integrität durchgeführt wird.

Das Sicherheitsmodul kann beispielsweise in einem Gerät 600, wie in Fig. 6 gezeigt, integriert sein. Das Gerät 600 kann beispielsweise ein eingebettetes System, ein Herzschrittma- eher, ein Feldgerät einer Kraftwerksanlage oder ein Steuerge ^¬ rät einer Feuerlöschanlage sein.

Im Einzelnen umfasst das Gerät 600 ein Sicherheitsmodul 500, so wie dieses in Fig. 5 beschrieben wird. Darüber hinaus um- fasst das Gerät eine Betriebssystemkomponente 620 und eine

Treiberkomponente 630, die über einen zweiten Bus 610 mit dem Sicherheitsmodul kommunikativ in Verbindung stehen.

Benötigt die Betriebssystemkomponente 620 eine Sicherheits- funktion, sendet diese mit Hilfe der Treiberkomponente 630 eine Anforderung zum Ausführen der Sicherheitsfunktion über den zweiten Bus 610 an das Sicherheitsmodul 500. Das Sicher ^¬ heitsmodul stellt dann, wie in den vorherigen Ausführungsbei ^¬ spielen beschrieben, die Sicherheitsfunktion bereit, sofern zumindest die Integrität einer Sicherheitsanwendung, die die Sicherheitsfunktion bereitstellt, erfolgreich überprüft wurde .

Obwohl die Erfindung im Detail durch die Ausführungsbeispiele näher illustriert und beschrieben wurde, ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt, und an ^¬ dere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.