Heutige
Datenverarbeitungssysteme bzw. Personalcomputer (PC) zeichnen sich
aufgrund ihrer Hardware- und Betriebssystemstruktur unter dem Gesichtspunkt
von Performance und Funktionalität
eher durch eine transparente als eine unter dem Aspekt der Sicherheit
entwickelte Architektur aus. In derzeitigen Microsoft Betriebssystemen
werden Systemressourcen transparent verwaltet, daß heißt, die
die Interaktion eines Programms mit dem Betriebssystem regelnden
Attribute der einzelnen Programme bzw. Applikationen, wie beispielsweise
Prozessnummern, Klassennummern oder Ressourcen-Handles, sind einfach
auslesbar und sind somit frei zugänglich, so daß bei der
Auswahl eines entsprechenden Zeigers oder Handles eine Kommunikation
bzw. ein Datenaustausch gestartet werden kann. Es können somit
Daten aus Programmen beispielsweise über die eindeutigen und frei
zugänglichen
Attribute ausgelesen werden. Neben der Schaffung von gewünschten
Funktionalitäten
(DLLs, OLE usw.) bietet diese transparente Architektur auch eine
Basis für
den Bau von Trojaner- oder ähnlicher
Maleware.
In
der Regel kann ein Benutzer nur schwer erkennen, welche Auswirkungen
die Installation und Ausführung
von Softwarepaketen auf sein bisheriges Computersystem hat. Da der
Benutzer den Source-Code nicht kennt, kann er keine Rückschlüsse bezüglich der
tatsächlichen
Realisierung der gewünschten
Programmfunktion ziehen. Somit muß der Benutzer darauf vertrauen,
daß ein
Programm nur die tatsächlich
gewünschte
Funktion ausführt.
Gerade aber im Free- und Shareware-Bereich sind im mer öfter zusätzliche
unerwünschte
Spionagefunktionen implementiert, die natürlich nicht im Interesse des
Anwenders liegen. In der Regel sind für den Benutzer die Attribute
einer jeweiligen ausgeführten
Applikation ermittelbar, jedoch sind die ausgeführten Aktionen nicht ersichtlich.
Weiterhin sind heutige PCs sicherheitstechnisch nicht in der Lage,
die auf dem Computersystem ausgeführten Programme vor Angriffen
insbesondere von außen
zu schützen.
Vor
diesem Hintergrund werden von einigen Systemherstellern, wie beispielsweise
IBM, bereits Computersysteme auf der Basis einer sicheren Plattform,
der sogenannten "Trusted
Computing Platform",
TCP, angeboten, in denen ein sogenanntes "Trusted Platform Module", TPM, im Volksmund
auch Fritz-Chip genannt, als zusätzliche
Hardware mit Sicherheitsmechanismen im Computersystem integriert
ist. Dieser Chip ist vom Prinzip her eine SmartCard und übernimmt
die Funktion der Benutzerauthentifikation und -identifikation sowie Verschlüsselung.
Das TPM kann asymmetrische Schlüssel
erzeugen, arbeitet als Verschlüsselungs-Coprozessor
und erzeugt Zufallszahlen, speichert empfangene Schlüssel und
verifiziert Zertifikate. Das Sicherheitskonzept von TCP basiert
darauf, daß der
Personalcomputer eine feindliche Umgebung ist. In Verbindung mit "Digital Right Management", DRM, als Technologie
zum Schutz von digitalen Inhalten lassen sich per DRM geschützte Daten
erst dann darstellen bzw. nutzen, wenn der TPM bestätigt hat,
daß die
Umgebung sicher ist. Dazu wird die Hardware und Firmware eines Computersystems
bei jedem Neustart vom TPM auf ihre Vertrauenswürdigkeit überprüft. Während des Betrieb kontrolliert
er das Betriebssystem sowie bestimmte Treiber und Applikationen.
Besitzt eine Komponente kein gültiges
Zertifikat, verweigert er dieser den Zugriff auf geschützte Inhalte.
Die
Anwendung selbst bestimmt, welche Sicherheitsrichtlinien für ihre Dateien
gelten. Ein Media Player beispielsweise wird also erkennen, welche
Nutzungsbedingungen an ein geschütztes
Programm bzw. an geschützte
Dateien geknüpft
sind. Programme, die einem Anwender erweitere Kontrollen über seinen
Personalcomputer geben, werden unter TCP nicht mehr funktionieren.
TCP bietet somit keine Sicherheit für den Benutzer sondern vielmehr
für den
PC Hersteller, Softwareanbieter oder die Contentindustrie. Einem
Benutzer werden die Anwendungsmöglichkeiten
für seine
Hardware eingeschränkt.
Auch
Microsoft plant mit dem Windows2000/WindowsXP nachfolgenden "Palladium"-Betriebssytem die
Nutzung verschlüsselter
Ressourcen. Somit kann eine Anwendung nur für den Fall ausgeführt werden,
daß sie
die korrekten Schlüssel
besitzt. Ein Nachteil dieser Zertifizierungsmethode ist jedoch,
daß ein
Betriebssystemhersteller als Zertifizierungsinstanz eine Monopolstellung
erzielen kann, da die Vergabe der Zertifikate in Absprache mit dem
Betriebssystemhersteller selbst erfolgen muß und Free- oder Sharewareprodukte
bzw. Produkte von Mitbewerbern ohne die Zertifizierung des Betriebssystemherstellers
nicht ausführbar
sind.
Aus
EP 1 220 079 A2 ist
eine Anordnung und Verfahren bekannt, bei der ein verschlüsselter
Datenbereich zwischen zwei oder mehreren Prozessen geteilt wird.
Dabei erhält
jeder der Prozesse vorher einen gemeinsamen Schlüssel. Über diesen Schlüssel kann
auf einen gemeinsamen verschlüsselten
Datenbereich zugegriffen werden, wobei die Daten des verschlüsselten
Datenbereich in die Prozessbereich der Prozess abgebildet werden.
Die Adress-Information der Prozesse wird in einem mit dem gemeinsamen
Schlüssel
verschlüsselten,
manipulationssichern Register abgelegt.
In
der Druckschrift
US
6 615 350 B1 ist eine Anordnung und ein Verfahren beschrieben,
mit dem zwischen einem ersten und einem zweiten Programm eine gesicherte
Kommunikation durchgeführt
werden kann. Beide Programme erhalten dazu ein Authentifizierungsmodul,
das für
das erste Programm ein eindeutig zugeordnetes Merkmal beinhaltet
und für
das zweite Programm ein Möglichkeit
zur Verifizierung des Merkmals des ersten Programms aufweist. Nach
gelungener Verifizierung können
die beiden Programme über
ein Binde-Modul kommunizieren.
Aufgabe
der vorliegenden Erfindung ist es Verfahren zur sicheren Ausführung von
Programmen in einem ein Sicherheitsmodul aufweisenden Datenverarbeitungssystem,
unter Verwendung eindeutiger, den Programmen zugeordneter Attribute
zur Interaktion mit einem Betriebssystem des Datenverarbeitungssystems vorzuschlagen,
bei dem die Ausführung
von Programmen ein hohes Sicherheitsniveau aufweist und die Kriterien
der Sicherheitsmechanismen dezentral verwaltbar sind.
Diese
Aufgabe wird erfindungsgemäß dadurch
gelöst,
daß ein
Verfahren zur sicheren Ausführung
von Programmen vorgesehen mit den Merkmalen des Patentanspruchs
1 ist.
Da
eine jeweilige Applikation bzw. ein Programm ein Attribut vom Sicherheitsmodul
anfordert, muß der Programmablauf
entsprechend geändert
werden. Beispielsweise ist in der Windows-Arbeitsumgebung der Kern einer Applikation
ein Prozess, der als Objekt mittels eines Fensters auf dem Bildschirm
dargestellt wird. Zur eindeutigen Identifizierung des Prozesses
auf dem Bildschirm wird das Attribut, beispielsweise der sogenannte
Fensterhandle, benötigt.
Fenster können,
wie im folgenden Beispiel aufgezeigt, mit API (Application Programmable
Interface) erstellt werden:
Zunächst wird die Funktion "WinMain" definiert, die die
Einsprungadresse für
die Windows-Anwendung darstellt:
Es
wird ein Fenster für
eine vordefinierte Klasse erzeugt:
Die
Variable "hwnd" beschreibt nun,
ob ein Fensterobjekt angelegt werden konnte. Ist der Wert NULL, konnte
kein Fenster erzeugt werden.
Nach
dem Befehl "CreateWindow()" wurde das Fensterobjekt
erzeugt, jedoch noch nicht auf dem Bildschirm angezeigt. Das Fenster
wird jetzt angezeigt mit:
Des
weiteren muß das
Fenster im Folgenden auf Benutzereingaben oder Aktionen des Betriebssystem
reagieren. Hierzu werden die Botschaften des Betriebsystems empfangen
und ausgewertet. Die Variable "&msg" beschreibt hierbei
einen Meldungsbezeichner und gibt an, welches Ereignis stattgefunden
hat. Die Funktionen "GetMessage,
TranslateMessage und DispatchMessage" beschreiben die im Microsoft-Betriebssystem übliche Bearbeitung
von Meldungen. Eine Verallgemeinerung dieser Beschreibung auf beliebige
Multitasking-Betriebsysteme ist jederzeit möglich:
Gemäß dem Vorschlag
der vorliegenden Erfindung kann das Anlegen und Registrieren von
Objekten beim Betriebssystem nicht mehr durch die Applikation allein
erfolgen, sondern muß cryptographisch
abgesichert über
den Crypto-Prozessor des Sicherheitsmodul, der als Co-Prozessor
fungiert, erfolgen. Wie im herkömmlichen
Fall bereits beschrieben, benötigt
auch jetzt die Applikation ein Fensterobjekt, jedoch ist es ihr
untersagt, dieses direkt vom Betriebssystem anzufordern:
Als
Erweiterung herkömmlicher
Betriebssystemarchitekturen muß die
Applikation sich zuerst mit gültigen
Schlüsseln
beim Crypto-Prozessor ausweisen, um nach erfolgter positiver Prüfung einen
Crypto-handle als Attribut von diesem zugewiesen zu bekommen. Hierbei
wird insbesondere betont, daß unter
auszuführenden
Programmen bzw. Applikationen auch Security-Domänen,
wie beispielsweise Java-Cards, Dongles etc., verstanden werden.
So soll beispielsweise ein Download von Daten eines Datenverarbeitungssystems
auf die oben genannte Security-Domäne cryptographisch abgesichert
erfolgen, indem ein Download erst nach erfolgreicher Authentifizierung
mittels beispielsweise eines an das Sicherheitsmodul übermittelten
gültigen
Schlüssels
und erfolgter positiver Prüfung
durch den Crypto-Prozessor erlaubt ist. Hierbei kann die gesamte
Attribut-Verwaltung auf dem Sicherheitsmodul alleine erfolgen bzw.
in einer Kooperation zwischen MainProzessor und Crypto-Coprozessor:
Hierbei
können
verschiedene Schlüsseldefinitionen
sowie Verschlüsselungsalgorithmen
vom Benutzer, im Rahmen der von ihm gewählten Sicherheitsrichtlinien,
festgelegt werden. Eine mögliche
Implementierung der erweiterten "HWND"-Variablen könnte wie
folgt implementiert werden:
Die
Verschlüsselungsfunktionen "EnCrypt" und "DeCrypt" sind virtuell implementiert
und können
in abgeleiteten Objekten in einer nach den Vorgaben des Benutzers
definierten Sicherheitsstufe angepaßt werden. Ebenso können im
Feld "Keyset" beliebige Schlüssel und
Zertifikate verarbeitet werden.
Das
Fenster wird unter Verwendung des verschlüsselten Attributs bzw. des
verschlüsselten
Fensterhandle erzeugt:
Die
Anzeige des Fensters und Interaktion mit Botschaften des Betriebssystem
erfolgt in analoger Weise zum bisher beschriebenen Verfahren:
Anstelle
der herkömmlichen "hwnd"-Variablen wird jetzt
die Variable "cryptohwnd" verwendet, die zusätzliche
cryptographisch abgesicherte Bestandteile verwendet:
Nach
Beendigung der Applikation wird das verschlüsselte Attribut wieder freigegeben:
Der
Zugriff aus Ressourcen erfolgt somit verschlüsselt.
Die 1 zeigt
ein Datenverarbeitungssystem 1 mit für die Erläuterung des Verfahrens relevanten Hardware-Komponenten
wie einem MainProzessor 2 und einem Sicherheitsmodul 3,
das einen hier nicht dargestellten Crypto-Coprozessor beinhaltet.
Der Block 4 symbolisiert das in dem Datenverarbeitungssystem 1 installierte
Betriebssystem; der Block 5 steht stellvertretend für ausführbare Programme
bzw. Applikationen. Soll eine Applikation ausgeführt werden, ist eine Registrierung
der Applikation zur Zuteilung eines Attributs, das zur eindeutigen
Identifizierung der Applikation und zur Interaktion der Applikation
mit dem Betriebssystem benötigt
wird, notwendig. Hierzu läßt die Applikation
dem Crypto-Coprozessor des Sicherheitsmoduls 3 einen Schlüssel zukommen
(Pfeil A), der vom Crypto-Coprozessor des Sicherheitsmoduls 3 auf
seine Gültigkeit
hin überprüft wird.
Ist der Schlüssel
gültig,
wird der Applikation durch den Crypto-Coprozessor ein eindeutiges
Attribut zugewiesen (Schritt B). Die Erzeugung des Attributs kann
mittels verschiedener Schlüsseldefinitionen bzw.
unter Verwendung verschiedener Verschlüsselungsalgorithmen, die durch
den Benutzer festlegbar sind, erfolgen. Die Verwaltung der durch
den Crypto-Coprozessor erzeugten Attribute kann entweder vom Crypto-Coprozessor
selbst oder in Kooperation mit dem MainProzessor erfolgen. Der Zugriff
auf Systemressourcen durch die Applikation erfolgt unter Verwendung
dieses Attributs und somit verschlüsselt.
