-
GEBIET DER ERFINDUNG
-
Diese
Erfindung betrifft ein Gerät,
das Tamper-Evidence für
ausführbare
Codes, die auf einem Wechseldatenträger gespeichert sind, liefert.
Dieses Gerät
stellt ein Element eines Plattform-Sicherheitskonzepts dar.
-
BESCHREIBUNG
DES STANDES DER TECHNIK
-
Plattformsicherheit
umfasst die Philosophie, das Konzept und die Anwendung von Plattform-Abwehrmitteln
gegen bösartige
oder schlecht geschriebene Codes. Diese Abwehrmittel verhindern,
dass diese Codes Schaden zufügen.
Bösartige
Codes umfassen üblicherweise
zwei Komponenten: einen Payload-Mechanismus, der den Schaden anrichtet,
und einen Ausbreitungs-Mechanismus zur Verbreitung des Ersteren.
Diese werden normalerweise wie folgt klassifiziert:
Trojanisches
Pferd: fungiert als legitime Anwendung, die dem Benutzer gutartig
und attraktiv erscheint.
Wurm: kann sich ohne weitere manuelle
Einwirkung seitens dessen Täter
oder Benutzer replizieren und ausbreiten.
Virus: infiltriert
legitime Programme und ändert
bzw. zerstört
Daten.
-
Die
Sicherheitsbedrohungen umfassen (a) eine potentielle Verletzung
der Vertraulichkeit, Integrität
oder Verfügbarkeit
von Leistungen oder Daten in der Wertschöpfungskette sowie der Integrität der Leistung,
und (b) eine Bedrohung der Leistungsfunktionen. Die Bedrohungen
werden in folgende Kategorien klassifiziert:
- 1.
Bedrohungen der Vertraulichkeit und Integrität von Daten. Beispiele: die
Erlangung des Benutzerpasswortes; die Beschädigung von Dateien.
- 2. Bedrohungen der Vertraulichkeit und Integrität von Leistungen.
Beispiele: die Benutzung der Bandbreite von Teilnehmern eines Telefonnetzes, ohne
dafür zu
bezahlen; die Ablehnung von Transaktionen mit Netzwerk Dienstleistern.
- 3. Bedrohungen der Verfügbarkeit
von Leistungen (auch Leistungsverweigerung genannt). Beispiele:
das Hindern des Benutzers, eine Textnachricht zu senden; das Hindern
des Benutzen, einen telefonischen Anruf entgegen zu nehmen.
-
Drahtlose,
mobile Geräte
stellen demzufolge für
den Designer eines Plattform-Sicherheitskonzepts
eine sehr große
Herausforderung dar. Ein kritischer Aspekt dieser Herausforderung
liegt darin, dass mobile, drahtlose Geräte regelmäßig Programme auf Wechseldatenträgern installieren.
Der Hauptgrund dafür
ist zusätzlichen
Speicherplatz zur Verfügung
zu stellen, den der Benutzer des drahtlosen Gerätes ändern kann, je nachdem, welche
Gruppe von Programmen er/sie benutzen möchte. Ein wohl bekanntes Beispiel
ist die Benutzung von Floppy-Disketten oder Speicherkarten in PC-Umgebungen.
Der Wechseldatenträger
kann im Prinzip irgendwie manipuliert werden, wenn dieser nicht
an das mobile, drahtlose Gerät
angeschlossen ist und die auf dem Gerät gespeicherten Programme würden demzufolge
ihre Integrität
verlieren. Es ist entscheidend, dass ein drahtloses Gerät unter
allen Umständen
bezüglich
der Integrität
des ausführbaren
Codes sicher ist, auch dann, wenn ein Wechseldatenträger wieder
angeschlossen werden soll (z.B. dass keine bösartigen Änderungen zur Überschreibung
von Sicherheitsmerkmalen erfolgt sind und kein Virus eingeführt wurde
etc.).
-
Bis
dato sind jedoch noch keine wirksamen Vorschläge zur Garantie der Integrität eines
ausführbaren
Codes erbracht worden, der von einem mobilen, drahtlosen Gerät herunter
transferiert und dann wieder auf das Originalgerät zurück geschickt wurde.
-
Es
kann weiterhin auf WO 00/18162 verwiesen werden, in der die Identität eines
entfernten Endgeräts
authentifiziert wird, um das Herunterladen von Software über eine
Langstreckenverbindung nur auf zulässige Computer zu erlauben.
Sie befasst sich weder mit der Verifizierung der Authentizität des Inhalts
eines Speichermittels, das dazu ausgelegt ist, bei normalem Betrieb
leicht entfernt und dann wieder an ein mobiles, drahtloses Gerät angeschlossen
zu werden, noch mit der spezifischen Gegebenheit, ausführbaren
Code zu diesem leicht zu entfernenden Speichermittel zu schreiben
bzw. der Notwendigkeit, die Integrität dieses Codes zu garantieren,
wenn das Gerät
wieder an das drahtlose Gerät
angeschlossen wird. Weiterhin kann auf das Dokument US-6026293 verwiesen
werden; dieses befasst sich jedoch auch nicht mit den obigen Gegebenheiten.
-
ZUSAMMENFASSUNG
DER VORLIEGENDEN ERFINDUNG
-
Als
erster Aspekt der vorliegenden Erfindung liegt ein mobiles, drahtloses
Gerät vor,
das dazu benutzt werden kann, einen selbst ausführbaren Code auf einem Wechseldatenträger zu installieren,
wobei das Gerät
dazu programmiert ist, einen Digest (bei einem Digest handelt es
sich um einen Wert, der anhand des vollständigen Inhalts des Codes unter
Verwendung eines Algorithmus generiert wurde und der garantiert,
dass derselbe Wert nicht regeneriert werden kann, falls der Inhalt
geändert
wurde) dieses Codes zu berechnen und in einem persistenten nicht auswechselbaren
Speicher innerhalb des Geräts
zu speichern. Selbst ausführbarer
Code besteht aus Befehlen, die von einer CPU oder einem Gerät direkt ausgeführt werden.
Der Datenträger
kann bei normalem Betrieb leicht entfernt und wieder angeschlossen werden.
-
Wenn
der Wechseldatenträger
wieder angeschlossen ist und die ausführbare Datei aufgerufen wurde,
berechnet das Gerät
einen Digest des Codes neu, den es von dem Wechseldatenträger laden
will und vergleicht ihn mit demjenigen, der innerhalb des persistenten
nicht auswechselbaren Speichers gespeichert ist. Falls diese nicht übereinstimmen,
wurde die ausführbare
Datei manipuliert und das Gerät kann
diesem somit nicht vertrauen. Der Digest ist nur von den Komponenten
einer Trusted Computing Base (siehe weiter unten) zugänglich und
ist somit selbst sicher. Bei dem Digest kann es sich um einen Hash
oder einen anderen eindeutigen und repräsentativen Wert handeln, der
von der gesamten ausführbaren
Datei wieder berechnet werden kann.
-
Dieser
Ansatz unterscheidet sich von herkömmlichen Wasserzeichenmarkierungen,
bei denen ein Hash von einer Datenträgerdatei abgeleitet und dann
wieder in die Datei eingefügt
wird, wobei er diese unmerklich verändert.
-
Bei
einer Anwendung werden sowohl der Digest als auch die „Fähigkeit" der ausführbaren
Datei sicher auf dem Gerät
gespeichert. Unter einer „Fähigkeit" kann man sich ein
Zugriffsmerkmal vorstellen, das einem Recht zur Durchführung einer
sensiblen Handlung entspricht. (Der Zweck des Fähigkeitsmodells ist es, den
Zugriff auf sensible System-Ressourcen
zu kontrollieren.) Zur Ladezeit überprüft das Ladegerät den Hash
vor dem Ladevorgang. Falls die ausführbare Datei unbekannt ist
(kein zugehöriger Digest),
wird die ausführbare
Datei ohne Fähigkeit (d.h.
keine Zugriffsrechte auf sensible Ressourcen) und ohne Identität (keine
Zugriffsrechte auf Daten, die zu einem identifizierten Prozess des
Betriebssystems gehören)
geladen. Falls die Verifizierung erfolgreich war, wird die ausführbare Datei
geladen und die gespeicherte Fähigkeit
dem neu geladenen Code zugeordnet.
-
Die
vorliegende Erfindung ermöglicht
es den Benutzern, Speicherkarten und andere Arten von Wechseldatenträgern ohne
Einschränkungen
bei mehreren Geräten
gemeinsam zu benutzen. Sie erlaubt es jedem Benutzer weiterhin,
die Rechte zu behalten, die er bezüglich der auf diesen Karten
gespeicherten Anwendungen innehat, unabhängig von dem Datenträger und
der Auswahl anderer Benutzer.
-
Die
Erfindung wird entsprechend dem Gerät nach Anspruch 1 und dem Verfahren
nach Anspruch 7 definiert.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
Die
vorliegende Erfindung wird unter Bezugnahme auf das Sicherheitskonzept
des objektorientierten Symbian OS Betriebssystems beschrieben, das
für drahtlose
Geräte
für Einzelanwender
entworfen wurde. Das Symbian OS Betriebssystem wurde von der Symbian
Ltd., London, Großbritannien,
für mobile,
drahtlose Geräte
entwickelt.
-
Der
Grundriss des Symbian OS Sicherheitskonzeptes entspricht den Verteidigungsanlagen
einer mittelalterlichen Burg. Ähnlich
wie diese verwendet es einfache und gestaffelte Sicherheitsschichten oberhalb
und außerhalb
des Installationsumfangs. Bei den Hauptbedrohungen, die das Modell
zu lösen versucht,
handelt es sich um diejenigen in Verbindung mit nicht genehmigtem
Zugriff auf Benutzerdaten und Systemleistungen, vor allem dem Phone Stack
Der Phone Stack ist im Zusammenhang mit einem Smart Phone von besonderer
Bedeutung, da dieses eine permanente Datenverbindung zu dem Telefonnetz
steuert. Hinter dem Modell stehen zwei Hauptdesign Treiber:
- • Firewall
Schutz von Schlüsselsystemressourcen mittels
der Verwendung von fähigkeitsbezogener Zugriffskontrolle.
- • Datenpartitionierung,
die einen geschützten
Teil des Dateiensystems erzeugt, auf den Standardsoftware nicht
in der Lage ist, zuzugreifen.
-
Das
Hauptkonzept des unten beschriebenen Fähigkeitsmodells besteht in
der Steuerung, was ein Prozess tun darf anstatt der Steuerung, was
ein Benutzer tun darf. Dieser Ansatz unterscheidet sich weitgehend
von bekannten Systemen wie Windows NT und Unix. Die Hauptgründe sind
folgende:
-
- – Die
grundsätzliche
Beschaffenheit von Symbian OS ist auf Einzelbenutzer ausgerichtet.
- – Symbian
OS bietet Leistungen durch unabhängige
Serverprozesse. Diese laufen immer und hängen nicht an einer Benutzersitzung.
Solange die Stromversorgung besteht, ist Symbian OS eingeschaltet,
selbst wenn kein Benutzer eingeloggt ist.
- – Symbian
OS ist dazu ausgelegt, in Geräten
verwendet zu werden, die von einem großen Publikum ohne technische
Kenntnisse benutzt werden. Bei der Installation der Software verfügt der Benutzer
eventuell nicht über
die Kenntnisse um zu entscheiden, welche Rechte einer Anwendung
zu erteilen sind. Mit immer angeschlossenen Geräten können die Konsequenzen einer
falschen oder böswilligen
Entscheidung eine Domäne
viel stärker
betreffen, als das Gerät
selbst.
-
1 Trusted Computing Plattform
-
1.1 Trusted Computing
Base
-
Eine
Trusted Computing Base (TCB) ist eine architektonische Grundvoraussetzung
für robuste Plattformsicherheit.
Die Trusted Computing Base besteht aus einer Anzahl von architektonischen
Elementen, die nicht untergraben werden können und die die Integrität des Gerätes garantieren.
Es ist wichtig, diese Base so klein wie möglich zu halten und das Principle
of Least Privilege anzuwenden, damit gewährleistet ist, dass die Systemserver
und -anwendungen keine Rechte erhalten müssen, die diese zum Betrieb
nicht benötigen.
Bei geschlossenen Geräten
besteht die TCB aus dem Kernel, Ladeprogramm und Datenserver, bei
offenen Geräten
wird außerdem
ein Software-Installer benötigt.
All diese Prozesse sind systemweit vertrauenswürdig und haben demzufolge vollen
Zugriff auf das System. Dieser vertrauenswürdige Kern würde mit
einer "Grund"-Fähigkeit
arbeiten, über
die andere Plattform-Codes nicht verfügen (siehe Abschnitt 2.1).
-
Es
gibt noch ein anderes wichtiges Element zur Aufrechterhaltung der
Integrität
der Trusted Computing Base, das außerhalb des Rahmens der vorliegenden
Erfindung liegt, und zwar die Hardware. Vor allem bei Geräten, die
die Funktionalität
der Trusted Computing Base im Flash-ROM enthalten, ist es notwendig, über ein
sicheres Boot-Ladegerät
zu verfügen,
um zu gewährleisten,
dass die Trusted Computing Base nicht mit einem bösartigen
ROM Image untergraben werden kann.
-
1.2 Trusted Computing
Environment
-
Jenseits
des Kerns bekämen
andere Systemkomponenten begrenzte orthogonale Systemfähigkeit
und würden
die Trusted Computing Environment (TCE) bilden; diese würden Systemserver
wie Anschluss-, Telefon- und Window-Server enthalten. Dem Window-Server
würde zum
Beispiel nicht die Fähigkeit
des Zugriffs auf den Phone Stack gewährt werden, und dem Telefonserver
würde nicht
die Fähigkeit
des direkten Zugriffs auf Tastaturereignisse gewährt werden. Es wird sehr empfohlen,
einer Softwarekomponente so wenig Systemfähigkeit wie möglich zu
geben, um einen möglichen
Schaden aufgrund eines Missbrauchs dieser Rechte einzugrenzen.
-
Die
TCB garantiert die Integrität
des gesamten Systems, so wie jedes Element der TCE die Integrität einer
Leistung gewährleistet.
Die TCE kann nicht ohne TCB existieren, die TCB kann jedoch alleine
existieren, um einen sicheren „Sand
Box" für jeden
Prozess zu gewähren.
-
2 Prozessfähigkeiten
-
Unter
einer „Fähigkeit" kann man sich ein
Zugriffsmerkmal vorstellen, das einem Recht zur Durchführung einer
sensiblen Handlung entspricht. Der Zweck des Fähigkeitsmodells ist es, den
Zugriff auf sensible Systemressourcen zu kontrollieren. Die wichtigste
Ressource, die eine Zugriffskontrolle erfordert, ist die Kernel-Exekutive
selbst, und eine System-Fähigkeit
(siehe Abschnitt 2.1) wird von einem Client verlangt, um einen Zugriff
auf gewisse Funktionalitäten
durch das Kernel API zu erhalten. Alle anderen Ressourcen befinden
sich in benutzerseitigen Servern, auf die via IPC [Inter Process
Communication] zugegriffen wird. Eine kleine Gruppe von Grundfähigkeiten
würde dazu
definiert werden, spezifische Client-Tätigkeiten
auf den Servern zu kontrollieren. Der Besitz einer Anruf-Fähigkeit
zum Beispiel würde einem
Client erlauben, einen Telefonserver zu benutzen. Es läge in der
Verantwortlichkeit des entsprechenden Servers, den Client-Zugriff
auf Ressourcen zu kontrollieren, die die Fähigkeiten repräsentieren. Fähigkeiten
würden
auch mit jeder Library (DLL) und jedem Programm (EXE) in Verbindung
gebracht und mittels des Ladegerätes
während
der Laufzeit kombiniert, um reine Bearbeitungsfähigkeiten zu erzeugen, die
im Kernel enthalten sein würden.
Bezüglich
offener Geräte
würden
der Fremdsoftware Fähigkeiten zugewiesen
werden, entweder während
der Installation der Software basierend auf dem zur Signierung des
Installationspakets benutzten Zertifikat oder durch den Benutzer
nach der Softwareinstallation. Die Überwachung der Fähigkeiten
würde zwischen dem Ladegerät, dem Kernel
und den betroffenen Servern geregelt, durch den IPC-Mechanismus
jedoch über
den Kernel geregelt werden.
-
Bei
den Hauptmerkmalen des Prozessfähigkeitsmodells
handelt es sich um folgende:
- • Dieses
konzentriert sich hauptsächlich
auf Systemserver und Client-Server IPC Interaktionen zwischen diesen
Einheiten.
- • Fähigkeiten
sind mit Prozessen und nicht mit Strängen verbunden. Stränge in demselben
Prozess teilen dieselben Rechte bezüglich Adressplatz und Speicherzugriff.
Dies bedeutet, dass alle von einem Strang benutzten Daten von allen
anderen Strängen
desselben Prozesses gelesen und geändert werden können.
- • Die Überwachung
der Fähigkeiten
erfolgt durch das Ladegerät
und den Kernel sowie mittels der Fähigkeitsüberwachung bei den Ziel-Servern.
Der Kernel IPC Mechanismus ist an der Letzteren beteiligt.
- • Wenn
der Code nicht läuft,
werden die Fähigkeiten
innerhalb von Libraries und Programmen gespeichert. In Libraries
und Programmen gespeicherte Fähigkeiten
sind nicht modifizierbar, da diese während der Installation an einer
Speicherstelle gespeichert würden,
die nur seitens der Trusted Computing Base zugänglich ist.
- • Nicht
alle Server müssten
Client Fähigkeiten
behandeln. Server wären
verantwortlich, Fähigkeiten
nach eigenem Wunsch zu interpretieren.
- • Die
einzige an diesem Schema beteiligte Kryptographie fände zum
Zeitpunkt der Softwareinstallation statt, bei der Zertifikate gegen
ein geeignetes Rootzertifikat geprüft werden.
-
2.1 Systemfähigkeiten:
Schutz der Integrität
des Geräts
-
Root. "Vollständiger Zugriff auf alle Dateien-Fähigkeiten
in Verbindung mit ausführbaren
Dateien können geändert werden"
-
"Root" Fähigkeit – Diese
wird nur von der Trusted Computing Base benutzt und gewährt vollständigen Zugriff
auf alle Dateien des Geräts.
-
Systemfähigkeiten
-
Einige
Systemserver erfordern einen spezifischen Zugriff auf die Trusted
Computing Base. Aufgrund der objektorientierten Implementierung
von Symbian OS bezieht sich die Art der Ressourcen, die von einem
System Server benötigt
werden, meistens ausschließlich
auf diesen. Aus diesem Grund würde einem
Systemserver einige Systemfähigkeiten
gewährt
werden, die orthogonal zu den von einem anderen Server benötigten wären. Dem
Window-Server würde
zum Beispiel Zugriff auf die vom Kernel ausgegebenen Tastatur- und
Schreibvorgänge
gewährt werden,
er würde
jedoch kein Recht auf einen Zugriff auf den Phone Stack haben. Ebenso
würde dem
Telefonserver Zugriff auf den Phone Stack gewährt, dieser hätte jedoch
kein Recht, Vorgänge
von dem Kernel zu sammeln.
-
Als
Beispiel kann Folgendes aufgeführt
werden:
| WriteSystemData | Erlaubt
die Änderung von
Konfigurationssystemdaten |
| CommDD | Gewährt Zugriff
auf alle Nachrichtenverbindungs- und Ethernet-Kartengerättreiber. |
| DiskAdmin | Kann
Administratoraufgaben auf der Platte durchführen (Reformatieren, Umbenennung
eines Laufwerks, ... ). |
-
2.2 Dem Benutzer zugängliche
Fähigkeiten:
das Mappen von Real-World-Rechten
-
Der
Prozess der Generierung von Fähigkeiten
kann schwierig sein. Dazu müssen
zuerst diejenigen Zugriffe identifiziert werden, die eine Überwachung
erfordern, danach müssen
diese Anforderungen in etwas gemappt werden, das für einen
Benutzer aussagekräftig
ist. Mehr Fähigkeiten
bedeuten zudem eine größere Komplexität, und die
Komplexität
wird überwiegend
als der Hauptfeind der Sicherheit angesehen. Eine auf Fähigkeiten
beruhende Lösung
sollte daher darauf ausgerichtet sein, die insgesamt eingesetzte
Anzahl zu minimieren. Die folgenden Fähigkeiten können relativ breitflächig auf
die Hauptbedrohungen gemappt werden, bei denen es sich um nicht
autorisierten Zugriff auf Systemleistungen (z.B. den Phone Stack)
und die Wahrung der Vertraulichkeit/Integrität der Benutzerdaten handelt.
- PhoneNetwork. „Ermöglicht den
Zugriff auf Telefon-Netzwerkdienste und die mögliche Ausgabe von Benutzergeld"
„Einen
Anruf tätigen"
„Eine SMS
senden".
- WriteUserData. „Kann
die privaten Informationen des Benutzen lesen und ändern"
„Einen
Kontakt hinzufügen".
„Einen
Termin löschen".
- ReadUserData. „Kann
die privaten Informationen des Benutzers lesen"
„Zugriff auf Kontaktdaten".
„Zugriff
auf die Terminplanung".
- LocalNetwork. „Ermöglicht den
Zugriff auf das lokale Netzwerk"
„Eine Bluetooth
Nachricht senden".
„Eine IR
Verbindung herstellen"
„Eine USB
Verbindung herstellen"
- Location. „Ermöglicht den
Zugriff auf den aktuellen Standort des Geräts"
„Finde das Gerät auf einer
Karte"
„Zeige
das Restaurant und Kino in nächster
Nähe an"
-
Root-
und Systemfähigkeiten
sind zwingend erforderlich; wenn sie einer ausführbaren Datei nicht gewährt sind,
kann der Benutzer des Geräts
nicht über
die Durchführung
entscheiden. Deren strikte Überwachung
gewährleistet
die Integrität
der Trusted Computing Plattform. Die Art und Weise jedoch, auf die
Server die den Benutzern zugänglichen
Fähigkeiten überprüfen oder
interpretieren, kann völlig
flexibel sein und sogar im Ermessen des Benutzers liegen.
-
2.3 Fähigkeiten einem Prozess zuordnen
-
Die
Zuordnung einer Laufzeitfähigkeit
zu einem Prozess bindet das Ladegerät ein. Im Wesentlichen werden
die den individuellen Libraries und Programmen zugeordneten statischen
Fähigkeitseinstellungen
in eine Laufzeitfähigkeit
verwandelt, die der Kernel enthält
und bezüglich
der mittels einer Kernel-Benutzer-Library-API Queries durchgeführt werden
können.
Das Ladegerät
wendet folgende Regeln an:
- Regel 1. Bei der
Anlage eines Prozesses ordnet das Ladegerät dieselbe Gruppe von Fähigkeiten wie
die dessen Programms zu.
- Regel 2. Bei dem Laden einer Library innerhalb einer ausführbaren
Datei muss die Fähigkeit
der Library größer als
oder gleich der Gruppe Fähigkeiten
der ladenden ausführbaren
Datei sein. Falls dies nicht der Fall ist, wird die Library nicht
in die ausführbare
Daten geladen.
- Regel 3. Eine ausführbare
Datei kann eine Library mit höheren
Fähigkeiten
laden, gewinnt dadurch jedoch nicht an Fähigkeiten.
- Regel 4. Das Ladegerät
lehnt alle ausführbaren Dateien
ab, die sich nicht in dem Bereich der Caged-Daten des dem TCB vorbehaltenen
Dateiensystems befinden.
-
Folgendes
ist hierbei zu beachten:
- • Die Fähigkeiten der Libraries werden
nur zum Zeitpunkt des Ladens überprüft. Darüber hinaus werden
alle in Libraries enthaltenen Codes frei betrieben und dieselbe
Gruppe von Fähigkeiten wie
die des Programms zugeordnet, in das es bei der Initiierung einiger
IPC Anrufe läuft.
- • Für ROM Images
mit etablierter Durchführung löst das ROM
erstellte Werkzeug alle Symbole auf, die dieselbe Aufgabe wie das
Ladegerät
zur Laufzeit durchführen.
Das ROM erstellte Werkzeug muss daher bei der Bildung eines ROM Image
dieselben Regeln wie das Ladegerät durchsetzen.
-
Diese Regeln
-
- • verhindern,
dass Malware in sensible Prozesse geladen wird, zum Beispiel einen
Anschluss an einen Systemserver
- • fördern die
Einkapselung von sensiblen Codes innerhalb eines Prozesses ohne
mögliche
Umgehungen
-
Die
unten stehenden Beispiele zeigen, wie diese Regeln im Falle von
statisch bzw. dynamisch geladenen Libraries angewendet werden.
-
2.3.1 Beispiele für verlinkte
DLL
-
Das
Programm P.EXE ist mit der Library L1.DLL verlinkt.
-
Die
Library L1.DLL ist mit der Library L0.DLL verlinkt.
- Fall 1:
- P.EXE enthält
Fäh1 & Fäh2
- L1.DLL enthält
Fäh1 & Fäh2 & Fäh3
- L0.DLL enthält
Fäh1 & Fäh2.
- Der Prozess P kann nicht angelegt werden, das Ladegerät versagt,
da L1.DLL nicht L0.DLL laden kann. Da L0.DLL nicht über eine
Gruppe Fähigkeiten
größer als
oder gleich L1.DLL verfügt,
wird Regel 2 angewendet.
- Fall 2:
- P.EXE enthält
Fäh1 & Fäh2
- L1.DLL enthält
Fäh1 & Fäh2 & Fäh3
- L0.DLL enthält
Fäh1 & Fäh2 & Fäh3 & Fäh4
- Der Prozess P wird angelegt, das Ladegerät ist erfolgreich und dem neuen
Prozess werden Fäh1 & Fäh2 zugeordnet.
Die Fähigkeit
des neuen Prozesses wird durch die Anwendung von Regel 1 bestimmt;
L1.DLL kann nicht die in L0.DLL enthaltene Fäh4 Fähigkeit erlangen und P1.EXE
kann nicht die in L1.DLL enthaltene Fäh3 Fähigkeit erlangen, wie laut
Regel 3 bestimmt.
-
2.3.2 Beispiele für dynamisch
geladene DLL
-
Das
Programm P.EXE lädt
dynamisch die Library L1.DLL.
-
Die
Library L1.DLL lädt
dann dynamisch die Library L0.DLL.
-
- Fall 1:
- P.EXE enthält
Fäh1 & Fäh2
- L1.DLL enthält
Fäh1 & Fäh2 & Fäh3
- L0.DLL enthält
Fäh1 & Fäh2
- Der Prozess P wird erfolgreich angelegt und der Fäh1 & Fäh2 zugeordnet.
- Wenn P das Ladegerät
auffordert, L1.DLL & L0.DLL
zu laden, ist das Ladegerät
erfolgreich, da P L1.DLL und L0.DLL laden kann. In diesem Fall wird
Regel 2 angewendet, da die ausführbare
Ladedatei Prozess P und nicht die Library L1.DLL darstellt: Der
IPC-Ladevorgang erfordert, dass der Ladegerätprozess seitens des Programms
P gesendet wird. Der Umstand, dass der gesamte Anruf innerhalb L1.DLL
stattfindet, ist hier nicht relevant. Regel 1 & 3 werden wie oben angewendet und
P wird durch das Laden von L1.DLL nicht Fäh3 zugeordnet
-
- Fall 2:
- P.EXE enthält
Fäh1 & Fäh2
- L1.DLL enthält
Fäh1&Fäh2&Fäh3
- L0.DLL enthält
Fäh1&Fäh2&Fäh4
- Der Prozess P wird erfolgreich angelegt und der Fäh1 & Fäh2 zugeordnet.
- Wenn P das Ladegerät
auffordert, L1.DLL & L0.DLL
zu laden, ist das Ladegerät
erfolgreich, da P L1.DLL und L0.DLL laden kann. Regel 2 wird wiederum
mit P als ausführbarer
Ladedatei anstatt von L1.DLL angewendet, während die Regel 3 garantiert,
dass P weder Fäh3
noch Fäh4
erlangt.
-
2.4 Wie man die Flexibilität austauschbarer
Datenträger
mit Plattformsicherheit kombinieren kann
-
2.4.1 Heutiger Stand
-
2.4.1.1 Geräteintegrität
-
Heutzutage
sind auf Wechseldatenträgern gespeicherte
Dateien völlig
ungeschützt.
Diese sind voll zugänglich
und können
geändert
werden. Wenn ein Wechseldatenträger
wieder an das Gerät
angeschlossen wird, werden keine Verifizierungen zur Gewährleistung
der Integrität
des Systems durchgeführt.
Die mit diesem Umstand verbundenen Risiken mögen als niedrig eingestuft
werden, da für
die Gefährdung
der Besitz des Datenträgers
erforderlich ist. Ein böswilliger
Benutzer kann jedoch Malware installieren und nicht deren Gerät beschädigen, sondern diese
zum Beispiel als Waffe gegen den Netzbetreiber benutzen. Ohne Plattformsicherheit
besteht heutzutage der einzige Schutz darin, ein Ladegerät einzuführen, welches
es ablehnt, Codes von Wechseldatenträgern zu laden. Auf lange Sicht
gesehen wird jedoch mehr Speicherplatz erforderlich sein um mehr Anwendungen
zu speichern, und diese Strategie wird Benutzer davon abhalten,
Software für
ihre Geräte
zu kaufen und sie möglicherweise
davor abschrecken, offene Plattformen zu kaufen, wenn sie daraus
keine Vorteile ziehen können.
-
2.4.1.2 Datenvertraulichkeit
-
Die
Bedrohungen der Datenvertraulichkeit sind tatsächlich vorhanden, beschränken sich
jedoch nur auf die Daten, die sich auf gestohlenen Wechseldatenträgern befinden.
Die Mehrheit der Bedrohungen können
schon ohne die Hilfe von Plattformsicherheit verhindert werden:
- 1. Hardware Zugriffskontrolle auf den Datenträger
Selbst
wenn er nicht an das Gerät
angeschlossen ist, ist der Datenträger mit einem Passwort geschützt, zum
Beispiel Secure MMC, PIN-geschützte
SIM, etc.
- 2. Dateienverschlüsselung
Wenn
der Benutzer um die Sicherheit sensibler Daten besorgt ist und diese
auf einem Wechseldatenträger
speichern möchte,
kann er diese verschlüsseln.
- 3. Verschlüsselung
des Dateiensystems
Eine Verschlüsselung des Dateiensystems
kann auf dem Niveau des Diskettenlaufwerktreibers angeboten werden.
-
2.4.2 Vorgeschlagene Erfindung
-
Die
vorgeschlagene Erfindung zielt nicht nur darauf ab, aktuelle Bedrohungen
zu verhindern, sondern auch darauf, die Interoperabilität und Codeverteilungsanwendungen
von Wechseldatenträgern
aufrechtzuerhalten.
-
Kein
Plattformsicherheitskonzept kann die Änderung von Wechseldatenträgern verhindern, wenn
diese nicht an das drahtlose Gerät
angeschlossen sind. Sogar bei einem mit einem Passwort geschützten Wechseldatenträger ist
es einem autorisierten Benutzer möglich, diesen zu ändern. Das Beste,
das die Plattformsicherheit daher bieten kann, ist ein Tamper-Evidence Mechanismus
für bekannte ausführbare Dateien
und eine sichere Ausführung unbekannter
Codes.
-
2.4.2.1 Software-Installer
-
Während der
Installation, wenn ein Anwendungspaket auf einem Wechseldatenträger gespeichert
werden muss:
-
Schritt
1. Der Software-Installer überprüft, dass
die auf einem Wechseldatenträger
zu installierenden ausführbaren
Dateien über
einen korrekten Security Identifier (SID) verfügen und keine andere legitime
ausführbare
Datei verkörpern,
um Zugriff auf deren private Daten zu erhalten.
-
Schritt
2. Der Software-Installer ordnet den in dem Anwendungspaket enthaltenen
ausführbaren Dateien
einige System- und Benutzerfähigkeiten
zu.
-
Schritt
3. Der Software-Installer hasht die ausführbaren Dateien.
-
Schritt
4. Der Software-Installer speichert alle Fähigkeiten sowie den Hash (d.h.
Digest) in einem TCB-eingeschränkten
Bereich eines permanenten Dateiensystems (das zum Beispiel nicht
entfernt werden kann).
-
Zum
Zeitpunkt der Deinstallation entfernt der Software-Installer die
ausführbaren
Dateien von dem Wechseldatenträger,
falls diese vorliegen, und vernichtet die zugeordnete Datei, die
unter Installationsschritt 4 angelegt wurde.
-
Bezüglich vorformatierter
Wechseldatenträger
(bereits installierte Dateien) muss eine einfachere Version des
Anwendungspakets zur Verfügung
gestellt werden, damit der Software-Installer Schritt 1 bis 3 durchführen kann.
Die vorliegende Erfindung beschreibt kein Gerät zur Erkennung von neuen Anwendungen
auf vorformatierten Wechseldatenträgern; eine mögliche Option
wäre, das
Vorliegen von neuen Anwendungen zum Zeitpunkt des Einführens des
Wechseldatenträgers
in das Gerät
festzustellen, und das Entfernen eines vorformatierten Wechseldatenträgers als
die Deinstallation der darauf enthaltenen Anwendung anzusehen.
-
2.4.2.2 Ladegerät
-
Zum
Ladezeitpunkt identifiziert das Ladegerät eine von dem Wechseldatenträger zu ladende ausführbare Datei.
Dabei schaut es auf die entsprechende HASH-Datei: Der Hash auf einem
TCB-beschränkten
Bereich eines permanenten Dateiensystems (d.h. das nicht entfernt
werden kann).
- – Falls dieser existiert, wird
die ausführbare
Datei gehasht und beide Hashs verglichen.
- – Falls
diese identisch sind, ordnet das Ladegerät die aus der HASH Datei extrahierten
System- und Benutzerfähigkeiten
der ausführbaren
Datei zu und führt
den Standard Ladeprozess durch.
- – Falls
diese nicht identisch sind, zeigt das Ladegerät eine Fehlermeldung.
- – Falls
keine entsprechende HASH Datei existiert, ordnet das Ladegerät der ausführbaren
Datei keine System und Benutzerfähigkeiten
zu und führt den
Standard Ladeprozess durch. Weiterhin ordnet es den Security Identifier
(SID) (bei dem SID (Security Identifier) eines Prozesses handelt
es sich um einen Weg, ein Stück
Code, das auf dem Betriebssystem laufen kann, eindeutig zu identifizieren,
und der dann auf der diesbezüglichen
ausführbaren
Datei gespeichert wird) „Unbekannt" zu, um die Impersonation
eines legitimen Prozesses zu verhindern. Da einem unbekannten Code keine
Fähigkeit
und kein SID gewährt
werden, kann dieser die Integrität
der Trusted Computing P1attform nicht beeinträchtigen.
-
Der
Hash-Prozess muss unabhängig
von dem Wechseldatenträger
sein. Das Ziel muss sein, ein Stück
Code zu authentifizieren, nicht den Wechseldatenträger, von
dem dieses stammt. Die bevorzugte Ausführungsform verwendet SHA-1,
da diese verhältnismäßig sicher
und schnell in einem drahtlosen Gerät zu verwenden ist.
-
2.4.3 Anwendungsfälle
-
2.4.3.1 Akteure
-
- 1. U ein Benutzer.
- 2. P1, P2 zwei drahtlose Geräte
im Besitz von Benutzer U.
- 3. C1, C2 zwei Wechseldatenträger im Besitz von U.
- 4. APP eine Anwendung mit nur einer ausführbaren Datei.
- 5. Ladegerät
- 6. SWInstall, der Software-Installer
- 7. ETEL, der Prozess, der den Zugriff auf das Telefonnetzwerk
kontrolliert.
-
2.4.3.2 Annahmen
-
- 1. APP wird als signiertes Anwendungspaket
geliefert, APP.sis mit PhoneNetwork Fähigkeit.
- 2. C: ist das interne Laufwerk
- 3. D: ist das Wechseldatenträger-Laufwerk
- 4. C1 enthält
APP.sis unter root. APP.sis ist das Installationspaket von APP.
-
2.4.3.3 Anwendungsfall
1 – U
installiert APP auf P1.
-
- 1. U schließt C1 an P1 an.
- 2. U benutzt P1.
- 3. U fordert SWInstall auf, D:\APP.sis auf dem Laufwerk D:\
zu installieren.
- 4. SWInstall überprüft das Signierungszertifikat. {E1}
- 5. SWInstall extrahiert APP.app.
- 6. SWInstall entfernt System- und Benutzerfähigkeiten von der ausführbaren
Datei und kopiert diese auf ein c:\ <nur TCB zugängliches Laufwerkt>\APP.cap.
- 7. SWInstall hasht APP.app und speichert es auf c:\ <nur TCB zugängliches
Laufwerk >\APP.cap.
- 8. SWInstall kopiert APP.app auf D:
- 9. SWInstall vervollständigt
die Installation.
-
E1 – Ungültige Signatur
-
- 1. Ende des Anwendungsfalls.
-
2.4.3.4 Anwendungsfall
2 – U
kopiert C1 in C2 off line und benutzt C2 mit P1.
-
- 1. U kopiert C1 in C2 off line.
- 2. U schließt
C2 an P1 an.
- 3. U verwendet P1.
- 4. U fordert das Ladegerät
auf, APP zu starten.
- 5. Das Ladegerät
findet APP.app in D:\
- 6. Das Ladegerät öffnet c:\ <nur TCB zugängliches
Laufwerk>\APP.cap.
- 7. Das Ladegerät überprüft die Hashs
mit Erfolg. {E2}
- 8. Das Ladegerät
extrahiert die System- und Benutzerfähigkeiten von APP.cap
- 9. Das Ladegerät
lädt APP.app
und ordnet APP.app Fähigkeiten
zu.
- 10. U fordert APP auf, eine Nummer zu wählen.
- 11. APP fordert ETEL auf, eine Nummer zu wählen.
- 12. ETEL überprüft erfolgreich,
ob APP PhoneNetwork besitzt.
- 13. ETEL wählt
die Nummer.
- 14. U benutzt die Telefonverbindung.
-
E2-Hashe passen nicht
zusammen
-
- 1. Das Ladegerät lädt APP nicht und bringt eine Binäre-Hash-Unverträglichkeits-Fehlermeldung.
- 2. U kann APP nicht benutzen.
-
2.4.3.5 Anwendungsfall
3 – U
verwendet C1 mit P2
-
- 1. U schließt C1 an P2 an.
- 2. U verwendet P2.
- 3. U fordert das Ladegerät
auf, APP zu starten.
- 4. Das Ladegerät
findet APP.app in D:\
- 5. Das Ladegerät
findet c:\ <nur
TCB zugängliches
Laufwerk>\APP.cap
nicht.
- 6. Das Ladegerät
lädt APP.app
und ordnet APP.app keine System- und Benutzerfähigkeiten zu.
- 7. U fordert APP auf, eine Nummer zu wählen.
- 8. APP fordert ETEL auf, eine Nummer zu wählen.
- 9. ETEL erkennt, dass APP kein PhoneNetwork besitzt.
- 10. ETEL fragt U, ob er den Anruf tätigen möchte.
- 11. U akzeptiert {E1}
- 12. ETEL wählt
die Nummer.
- 13. U benutzt die Telefonverbindung.
-
E1 –U akzeptiert nicht
-
- 1. ETEL wählt
die Nummer nicht.
- 2. APP zeigt U eine Fehlermeldung an.
-
2.4.3.6 Anwendungsfall
4 – U
installiert APP auf P2 und stuft APP's PhoneNetwork zurück
-
- 1. U schließt C1 an P2 an.
- 2. U verwendet P2.
- 3. U installiert APP erfolgreich auf P2 D:\ ( siehe Anwendungsfall
1)
- 4. U fordert SWInstall auf, PhoneNetwork aus den Fähigkeiten
von APP zu entfernen.
- 5. SWInstall ändert
c:\ <nur TCB zugängliches Laufwerk>\APP.cap und setzt
die Benutzerfähigkeiten
in der Datei zurück
- 6. U fordert das Ladegerät
auf, APP zu starten.
- 7. Das Ladegerät
findet APP.app in D:\
- 8. Das Ladegerät öffnet c:\ <nur TCB zugängliches
Laufwerk>\APP.cap.
- 9. Das Ladegerät überprüft die Hashs
erfolgreich. {E2}
- 10. Das Ladegerät
extrahiert die Fähigkeiten
aus APP.cap
- 11. Das Ladegerät
lädt APP.app
und ordnet APP.app Fähigkeiten
zu.
- 12. U fordert APP auf, eine Nummer zu wählen.
- 13. APP fordert ETEL auf, eine Nummer zu wählen
- 14. ETEL stellt fest, dass APP kein PhoneNetwork besitzt.
- 15. ETEL fragt U ob er den Anruf tätigen möchte.
- 16. U akzeptiert. {E1}
- 17. ETEL wählt
die Nummer.
- 18. U benutzt die Telefonverbindung.
- 19. U schließt
C1 an P1 an.
- 20. U fordert APP auf, eine Nummer zu wählen.
- 21. APP fordert ETEL auf, eine Nummer zu wählen
- 22. ETEL überprüft erfolgreich,
dass APP PhoneNetwork besitzt.
- 23. ETEL wählt
die Nummer.
- 24. U benutzt die Telefonverbindung.
-
E1 – U akzeptiert nicht
-
- 1. ETEL wählt
die Nummer nicht.
- 2. APP zeigt U eine Fehlermeldung an.
-
E2 – Hash-Unverträglichkeit
-
- 1. Das Ladegerät lädt APP nicht und bringt eine Binäre-Hash-Unverträglichkeits-Fehlermeldung.
- 2. U kann APP nicht benutzen.
-
2.4.3.7 Anwendungsfall
5 – U
deinstalliert APP von P2 mit C2
-
- 1. U schließt C2 an P2 an.
- 2. U benutzt P2.
- 3. U fordert SWInstall auf, APP zu deinstallieren.
- 4. SWInstall löscht
c:\ <nur TCB zugängliches Laufwerk> \APP.cap.
- 5. SWInstall fordert U auf, die Löschung auf D: zu bestätigen.
- 6. U bestätigt.
{E1}
- 7. SWInstall löscht
APP.app von D:.
- 8. U kann C2 auf P1 oder P2 nicht benutzen, um APP zu starten.
-
E2 – U bestätigt nicht
-
- 1. SWInstall löscht APP.app nicht von D.
- 2. U kann immer noch C2 mit P1 benutzen, um APP zu starten.
-
2.4.3.8 Anwendungsfall
6 – U
hackt APP.app, um einige System-Fähigkeiten hinzuzufügen.
-
- 1. U ändert
die Systemfähigkeiten
von APP.app off line auf C1.
- 2. U schließt
C1 an P1 an.
- 3. U benutzt P1.
- 4. U fordert das Ladegerät
auf, APP zu starten.
- 5. Das Ladegerät
findet APP.app in D:
- 6. Das Ladegerät öffnet c:\ <nur TCB zugängliches
Laufwerk>\APP.cap.
- 7. Das Ladegerät überprüft den Hash
ohne Erfolg.
- 8. Das Ladegerät
lädt APP
nicht und bringt eine Binäre-Hash-Unverträglichkeits-Fehlermeldung.
- 9. U kann APP nicht benutzen.
-
2.4.3.9 Schlussfolgerung
-
Diese
Anwendungsfälle
zeigen, dass die von Wechseldatenträgern zur Verfügung gestellte
Flexibilität
sogar mit Plattformsicherheit beibehalten wird:
-
- – Um
Karten zwischen Geräten
mit unterschiedlichen Einstellungen bezüglich der Benutzerfähigkeiten
gemeinsam zu benutzen.
- – Um
Karten zu duplizieren und die Kopien ohne Einschränkungen
zu benutzen.
- – Um
Codes sicher von Wechseldatenträgern
aus auszuführen.