Systeme und ihr Umfeld

Hardware-Sicherheitsmodule

Sicherheitsverwahrung für Funktionen

Von Andrew Newton, Hamburg

Durch die Secure Execution Engine erweitert nCipher die Aufgaben von Hardware-Sicherheitsmodulen auf das Kapseln und Ausführen sensitiver Funktionen von Anwendungssoftware. Bei ihrer Entwicklung kommen Standard-Java-Tools zum Einsatz.

Durch Outsourcing-Programme und die Beteiligung mehrerer Parteien an der Bereitstellung von E-Business-Diensten verteilen sich Anwendungen heute immer stärker über Netzwerke. Daraus ergeben sich zwangsläufig Sicherheitslücken, die Daten anfällig für Angriffe machen. Als mögliche Gegenmaßnahme hat nCipher die Secure Execution Engine, kurz SEE, entwickelt. Diese Technik ermöglicht es, sicherheitsrelevante Programmcodes und Anwendungen in ein Hardware-Sicherheitsmodul (HSM) zu laden, sie darin zu verwalten und auszuführen.

Damit verlagert sich die Verarbeitung sensitiver Daten in einen gesicherten Hardwarebereich, der erheblich schwerer anzugreifen ist als ein Server. SEE erweitert somit die Möglichkeiten der HSM von bloßem Schlüsselmanagement auf Anwendungsroutinen. Mithilfe des CodeSafe Developer Kit können Entwickler unter Verwendung der SEE E-Business-Anwendungen in einer offenen und standardisierten Java-Entwicklungsumgebung absichern.

CodeSafe signiert dabei die Software, damit nShield-Hardware-Sicherheitsmodule sie vor ihrer Ausführung authentifizieren können. Eine derart bestätigte und signierte Software bezeichnet nCipher als "Trusted Agent". Sie kann als zuverlässig und sicher betrachtet werden, da Zugriffe – entsprechend der zugewiesenen Rechte – auf eine bestimmte Datenmenge begrenzt sind; verschlüsselte Daten werden nur innerhalb der zugriffssicheren HSM-Umgebung dechiffriert.

Trusted Agents übernehmen typischerweise in nicht vertrauenswürdigen Umgebungen die Ausführung anwendungsspezifischer Sicherheitsfunktionen im Namen des Anwenders. Die SEE-Umgebung tritt hier als Vermittler zwischen ungeschütztem Server und HSM auf. Jede Transaktion wird durch die Vorlage eines sicheren Tokens beim HSM bestätigt. Beispiele für Trusted Agents sind digitale Messgeräte, Authentifizierungsagenten, Zeitstempel, Audit Devices, Agenten für digitale Signaturen und kundenspezifische Verschlüsselungsverfahren.

Glass Box vs. Black Box

Manche Entwicklungsumgebungen mit Sicherheitsfunktionen zwingen Entwickler, sich mit einem undurchsichtigen "Black Box"-System auseinanderzusetzen. Traditionelle Entwicklungs- und Debugging-Verfahren können dann nur begrenzt oder gar nicht zum Einsatz kommen. Teilweise verhindert gesicherte Hardware das schrittweise Durchschalten einzelner Programmschritte, da gewonnene Einblicke in die Betriebsweise des Programms die Geheimhaltung der Betriebsumgebung gefährden würden.

CodeSafe liefert hingegen mit einer virtuellen SEE eine "gläserne" Umgebung (Glass Box). SEE basiert auf geregelter Zugriffsteuerung und nicht auf der Geheimhaltung seiner Arbeitsweise. Dies ermöglicht das gewohnte Debuggen von Anwendungscodes mit Standard-Java-Programmier-Tools, ohne die Integrität des Systems zu gefährden. Allerdings verwendet SEE eigene Sicherheitsfunktionen, die nicht auf den standardmäßigen Java-Routinen aufbauen. Die Ausführung der resultierenden Programme erfolgt auf einer Java Virtual Machine (JVM), die innerhalb der sicheren Umgebung des HSM läuft und mit entsprechendem Code auf dem Server kommuniziert.

[Datenfluss mit und ohne SEE]
Die Secure Execution Engine (SEE) ermöglicht die Ausführung speziell programmierter Anwendungsroutinen innerhalb der Sicherheitsperipherie eines Hardwaremoduls.

Schlüsselbuch

nCipher-Produkte arbeiten in Sachen logischer Sicherheit mit signierten Berechtigungen, die jedem Schlüssel beigefügt sind. Diese Zugriffskontrolllisten (Access Control List, ACL) beschreiben die Aktivitäten, die mit einem bestimmten Schlüssel ausgeführt werden dürfen, und die Bedingungen, unter denen dies erlaubt ist. Sobald die erteilten Berechtigungen abgelaufen sind, verliert der Schlüssel seine Gültigkeit. Die Zugriffskontrollliste wird signiert, chiffriert und zusammen mit dem Schlüssel in einem gesicherten Dateiformat (Key BLOB) gespeichert.

Die SEE arbeitet mit diesem System von Schlüsseln und entsprechenden Berechtigungen, um Programme zu authentifizieren und ihre Ausführung auf dem Server und dem HSM zu genehmigen. Nur ein signierter Programmcode kann ablaufen.

Bei Verwendung der SEE kann der Code in einem verschlüsselten Format gespeichert werden. Das Java-Archiv (JAR) und die SEE-JVM lassen sich mit dem Dienstprogramm Trusted Code mithilfe eines 3DES-Keys verschlüsseln, der durch eine Sicherheitsumgebung oder ein Operator Card Set geschützt wird.

Die Schlüssel können einen Eintrag in die ACL enthalten, der darauf hinweist, dass sie für die Entschlüsselung von SEE-Objekten auf dem Modul vorgesehen sind. Allerdings ist es mit diesen Schlüsseln nicht möglich, den Code zu entschlüsseln und für den Host offen zu legen. Das Programm selbst steht außerhalb der SEE-Umgebung nur in chiffrierter Form zur Verfügung. Urheberrechtlich geschützte oder algorithmisch sensitive Programme bleiben also vor neugierigen Blicken geschützt.

[Module im Test und im Einsatz]
Zum Testen und zur Fehlerbereinigung übernimmt eine virtuelle SEE die Rolle des HSM. Dadurch sind jegliche gewohnten Debugging-Routinen möglich.

Ladehemmung

Um verschlüsselte Software laden zu können, muss der Benutzer zunächst den entsprechenden Chiffrierschlüssel laden. Ist der Chiffrierschlüssel beispielsweise durch ein Operator Card Set, nach dem Mehraugen-Prinzip geschützt, so können nur Benutzer mit einer ausreichenden Anzahl von Smartcards dieses Operator Card Sets den Code laden (evtl. aus einem größeren Pool, beispielsweise mit vier beliebigen von sechs möglichen Karten).

Ein Anwendungsbeispiel für SEE sind Protokoll-Konvertierungen: Gehen sensitive Daten über WAP zur Bearbeitung an einen Web-Server, so muss dieser die Informationen von WTLS in SSL umwandeln. Diese Konvertierung ist nur im Klartext möglich – während der Umchiffrierung liegen die Daten daher ungeschützt auf dem System. Beim Einsatz von SEE erfolgt diese Konvertierung jedoch in einer sicheren Umgebung.

----------Anfang Textkasten----------

Agenten-Entwicklung

Der Entwicklungsprozess eines Trusted Agent lässt sich am Beispiel einer Anwendung für das Erzeugen von Zeitstempeln verdeutlichen. Hierbei dient die Signatur auf den Java-Dateien dazu, eine Berechtigung zur Verwendung des Stempeldienst-Signatur-Schlüssels zu erteilen. Für das Setzen eines Zeitstempels sind die von der Echtzeituhr generierte Zeit, eine Seriennummer und ein Schlüssel erforderlich, der mit der Schlüsselmanagement-Software KeySafe erstellt wird.

Den Code für den Trusted Agent kann man mit jeder beliebigen Java-Entwicklungsumgebung verfassen, die zum Sun JDK 1.2x kompatibel ist. Eine Reihe nCipher-spezifischer API-Aufrufe dient dazu, Funktionen aus dem Modul aufzurufen. Die in CodeSafe enthaltene Support-Software und die Dienstprogramme erleichtern das Schreiben von Programmen, die diese Funktionen verwenden. Alle nCipher-APIs sind vollständig dokumentiert. Darüber hinaus steht im Development Kit ein umfassend dokumentierter Beispielcode zur Verfügung.

Die Klassen auf Modulseite sowie alle übrigen Klassendateien, die für das Ausführen auf der Java Virtual Machine des HSM erforderlich sind, sollte man gemeinsam hinzufügen und als Java-Archiv (JAR) speichern. Sie enthalten den Code der Zeitstempelung. Das Class Analysis Tool prüft die JAR-Datei und die Java-Klassen für die Ausführung auf dem HSM und erstellt Java-Stub-Klassen für die host-seitige Schnittstelle.

[Zusammenhang verschiedener Code-Module bei SEE]
Erstellen einer SEE-Anwendung: Die verschiedenen Quelltexte/Java-Classes werden über Dienstprogramme zusammengestellt.

Im nächsten Schritt wird die JAR-Datei mithilfe des Trusted Code Tool signiert und, falls erforderlich, komprimiert. Nachdem der Code als SAR-Datei signiert und gespeichert wurde, kommt er erst nach der Authentifizierung durch das HSM zum Einsatz. Das HSM gestattet dem Code nur Zugriff auf die Daten, für die er laut Zugriffskontrollliste (ACL) eine Leseberechtigung besitzt. Die SAR-Datei, die vom Class Analysis Tool erstellte Klassendatei und die Klassen auf der Hostseite landen gemeinsam in einer JAR-Datei. Beim Ausführen der Host-Anwendung ruft diese die auf dem HSM befindliche JVM auf. Der im HSM ausgeführte Java-Code verarbeitet unter anderem Anforderungen für Zeitstempel und Protokolldateieinträge, sofern die eingehenden Anforderungen authentifiziert sind.

Mithilfe des in CodeSafe enthaltenen Dienstprogramms Virtual SEE lässt sich der Java-Bytecode testen und debuggen. Die Virtual SEE ahmt die HSM-Umgebung auf dem Server nach. Hier kann der Code dann getestet und debuggt werden, was bei einer Ausführung auf dem echten HSM in dieser Weise nicht möglich wäre.

----------Ende Textkasten----------

Auch das Digital-Rights-Management (DRM) stellt ein Einsatzfeld dar. Fordert ein Abonnent bestimmte digitale Inhalte über eine geschützte SSL-Verbindung an, so müssen seine Zugangsinformationen mit der User-Datenbank verglichen werden. Während dieser Zeit liegen die Daten im Klartext auf dem Server. Sobald der Abonnent zweifelsfrei identifiziert worden ist, erfolgt die Freigabe der angeforderten Inhalte, die möglicherweise verschlüsselt in einer zweiten Datenbank vorliegen und sodann in ein sicheres Transportprotokoll, das ebenfalls auf SSL basiert, zu konvertieren sind. In beiden Phasen liegen – wenn auch nur für kurze Zeit – sensitive Information im Klartext vor und sind im Prinzip auf dem Server angreifbar. Mit SEE lässt sich auch dieser Vorgang in die sichere Hardwareumgebung verlagern.

Andrew Newton ist European Sales Director bei der nCipher Corporation Ltd. ([externer Link] www.ncipher.com).

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 5/2001, Seite 22