Sicherere Benutzeroberflächen mittels DirectX
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Sicherere Benutzeroberflächen mittels DirectX
Hanno Langweg
Institut für Informatik III
Rheinische Friedrich-Wilhelms-Universität Bonn
Römerstraße 164
53117 Bonn
langweg@informatik.uni-bonn.de
Abstract: Ursprünglich für die Nutzung durch Spieleentwickler vorgesehene
Schnittstellen sind für Sicherheitszwecke nutzbar. Wir zeigen, wie mittels
Microsofts DirectX eine direkte Kommunikation zwischen einer Anwendung und
einem Benutzer hergestellt werden kann. Simulationen und Verfälschungen durch
andere Programme werden ausgeschlossen. Mit begrenztem Aufwand können
Integrität und Authentizität der Benutzereingabe und die Integrität der
Programmausgabe gewahrt werden.
1 Einleitung
Computerspiele zielen stets darauf ab, die Möglichkeiten eines PCs weitestgehend
auszunutzen – aufwändige Graphikdarstellung und eine schnelle Reaktion auf
Benutzereingaben sind typisch für solche Anwendungen. In früheren Zeiten waren
Personal Computer so entworfen, dass nur ein Programm gleichzeitig ausgeführt werden
konnte. Spiele konnten alle Ressourcen eines Computers ungestört einsetzen und hatten
direkten Zugriff auf Eingabe- und Ausgabegeräte. Mit dem Erscheinen
multitaskingfähiger Betriebssysteme änderte sich das, Programme mussten nun
Ressourcen untereinander teilen. Spieleentwickler beklagten sich über eine
eingeschränkte Systemleistung.
Multitasking-Betriebssysteme wurden unter Safety-Gesichtspunkten begrüßt. Eine
Anwendung konnte nicht mehr das gesamte System blockieren. Das Betriebssystem
hatte die Aufsicht über Ressourcen und konnte ihre Nutzung den Programmen entziehen.
Anwendungen konnten sich nicht darauf verlassen, exklusiven Zugriff auf Geräte zu
bekommen.
227Anwendungsentwickler, die direkt mit dem Benutzer kommunizieren möchten, haben
einen schweren Stand ohne exklusiven Gerätezugriff. Im Kontext elektronischer
Signaturen, Homebanking oder Online-Abstimmungen wird eine bewusste Bestätigung
des Benutzers für von ihm ausgelöste Aktionen benötigt. Kann die Integrität und
Authentizität der Eingabe und Ausgabe nicht garantiert werden, besteht ein
Sicherheitsproblem. Nichtvertrauenswürdige Programme, z.B. Viren oder Trojanische
Pferde ([Ce99]), könnten Benutzereingaben simulieren oder den Benutzer durch
Täuschung zu fragwürdigen Aktionen verleiten. Oft wird keine Abwehr angeboten oder
aber auf zusätzliche sichere und teure Hardware verwiesen.
Interessanterweise werden Möglichkeiten direkter Hardwarezugriffe neuerdings aus
ganz anderen Motiven forciert. Spieleentwicklern soll eine attraktive Plattform geboten
werden, auf der sie ihre anspruchsvollen Programme schnell ausführen können. In Bezug
auf die weitverbreiteten Microsoft Windows-Systeme hat sich die DirectX-Schnittstelle
durchgesetzt.
Nicht nur Spiele profitieren von einem direkten Hardwarezugriff. Anwendungen mit
erhöhtem Sicherheitsbedarf haben dadurch ebenfalls Vorteile. Ihnen wird – wie in
früheren Nicht-Multitasking-Umgebungen – Kontrolle über Ressourcen gegeben. Damit
kann auf teure Spezialhardware verzichtet werden. Kurze Reaktionszeiten und bunte
Graphik sind hier keine vordringlichen Ziele. Direkter Zugriff ermöglicht allerdings
Integrität und Authentizität ansonsten gemeinsam genutzter Kanäle. Benutzereingaben
können nicht (mehr) simuliert oder verfälscht werden. Programmausgaben können nicht
(mehr) manipuliert werden. Bei elektronischen Signaturen ist dies unter dem Schlagwort
„What you see is what you sign“ bekannt.
In diesem Beitrag zeigen wir, wie Anwendungsentwickler die Microsoft DirectX-
Schnittstelle nutzen können, um direkten Hardwarezugriff für Sicherheitszwecke zu
erlangen. Wir betrachten Integrität und Authentizität der Benutzereingabe sowie
Integrität der Programmausgabe. Authentizität der Programmausgabe ist in dieser Arbeit
nicht enthalten. Dabei geht es uns um die Sicherheit gegenüber Anwendungen, die im
selben Benutzerkontext ausgeführt werden. Angriffe, bei denen Teile des
Betriebssystems ausgetauscht werden, oder bei denen der Angreifer mit erweiterten
Privilegien agiert, betrachten wir nicht.
Im nächsten Kapitel stellen wir frühere und verwandte Arbeiten vor. Es folgen
Behandlungen der Integrität und Authentizität der Eingabe und Integrität der Ausgabe.
Das fünfte Kapitel stellt überblickshaft eine Beispielimplementierung vor.
2282 Frühere und verwandte Arbeiten
In mehreren Veröffentlichungen wurde gezeigt, dass Anwendungen unter Microsoft
Windows oder X-Windows anfällig gegenüber Trojanischen Pferden sind. Übliche
Angriffe zielen auf eine Fernsteuerung anderer Programme ab ([Cu03]). Als
Mechanismen kommen dabei in der Regel simulierte Benutzereingaben oder verfälschte
Benutzeroberflächen zum Einsatz, welche den Austausch von Nachrichten zwischen
Programmen bedingen ([SCL01]).
Zur Abwehr solcher Angriffe kann der Austausch von Nachrichten systemweit oder auf
Anwendungsebene eingeschränkt werden. Das X-Windows-System erlaubt
beispielsweise die Unterdrückung von Nachrichten, die vermöge der SendEvents-
Funktion erzeugt werden ([Fi95], [Br98]). Microsoft Windows erlaubt die
Einschränkung bestimmter Nachrichtentypen für einen Desktop. Es gibt allerdings
Situationen, in denen die Fernsteuerung anderer Programme erwünscht ist,
beispielsweise in interaktiven Hilfesystemen. Nur wenige Anwendungen stellen hier eine
gesonderte Schnittstelle zu kontrollierter Fernsteuerung bereit. Fernsteuerung mittels
simulierter Benutzeraktionen bleibt somit eine schnelle und einfache Methode bei der
Erstellung einfacher Hilfsprogramme.
Viele Ansätze zur Schaffung eines sicheren Pfads zwischen sicherheitsrelevanten
Anwendungen und ihren Benutzern konzentrieren sich auf die Abschottung der
Programme voneinander. [Ba01] schlägt getrennte Desktops vor und nimmt dafür eine
eingeschränkte Kooperationsmöglichkeit der eingesetzten Anwendungen in Kauf.
[JO01] fordern, dass ein Benutzer seinen Computer neu starten müsse, um in einen
sicheren Ein-Anwendungs-Modus zu gelangen. [Pf01] möchten ein neues
Betriebssystem installieren, das Anwendungen vollständig voneinander trennt und
Zusammenarbeit nur mittels weniger verlässlicher Systemprogramme erlaubt.
[TW96] sehen Fenster-Personalisierung durch den Benutzer als eine geeignete Methode
um festzustellen, dass ein Benutzer mit der korrekten Anwendung arbeitet. [We98],
[FHW00], [MM02], [Fr03] argumentieren, dass nur spezielle Hardware unter Kontrolle
des Benutzers (z.B. PDAs) frei von nichtvertrauenswürdigen Programmen seien und für
sichere Eingabe und Ausgabe genutzt werden könnten.
2292.1 Windows Eingabemodell
Microsoft Windows verwendet ein internes
Nachrichtenmodell zur Steuerung der
Kommunikation mit Windows-
Anwendungen. Nachrichten werden erzeugt,
wenn ein Ereignis eintritt. Drückt ein
Benutzer eine Taste oder lässt er sie los oder
bewegt er die Maus, wird eine Nachricht
erzeugt. Das Betriebssystem stellt die
Nachricht in die Nachrichtenwarteschlange
des entsprechenden Programms (bzw. des
Threads) ein. Eine Anwendung prüft
regelmäßg ihre Nachrichtenwarteschlange
und holt an sie adressierte Nachrichten ab
([Mi98]).
Eingaben für eine Anwendung werden vom Betriebssystem an das entsprechende
Fenster geleitet, für das sie bestimmt sind. Jedes Fenster hat dafür eine Schnittstelle, die
sogenannte Window Procedure. Die Window Procedure verarbeitet die Nachricht und
gibt die Kontrolle an das Betriebssystem zurück. Aussehen und Verhalten eines Fensters
werden durch die Window Procedure als Reaktion auf Nachrichten bestimmt.
Im Windows-Nachrichtenmodell ist es nicht möglich, zwischen Nachrichten zu
unterscheiden, die vom Betriebssystem oder von anderen Anwendungen in die
Nachrichtenwarteschlange eingefügt wurden. Es steht sogar eine Funktion SendInput zur
Verfügung (bzw. keybd_event, mouse_event vor Windows NT4 SP3), über die beliebige
Programme Benutzereingaben komfortabel simulieren können. Diese simulierten
Eingaben werden vom Betriebssystem dann in Nachrichten an die aktuelle Anwendung
umgesetzt. Ursprünglich waren diese Mechanismen dafür gedacht, spezielle
Eingabegeräte abwärtskompatibel zu integrieren. Für Viren, Würmer und Trojaner sind
sie ebenfalls geeignet.
2302.2 DirectX
Microsoft DirectX ist eine Zusammenfassung verschiedener Techniken und
Schnittstellen mit dem Ziel, Microsoft Windows zu einer von Spieleentwicklern
bevorzugten Plattform zu machen. Es ist in die neueren Versionen Windows 98, Me
sowie 2000, XP fest integriert.
DirectX gibt Spieleentwicklern über standardisierte Schnittstellen schnellen und direkten
Zugriff auf Hardware. Diese Schnittstellen steuern u.a. Graphikspeicher und -darstellung
sowie Eingabegeräte wie Tastatur, Maus oder Joystick. Sie sind gruppiert in
verschiedene Teilgebiete, die zusammen als DirectX bezeichnet werden: Direct3D,
DirectDraw, DirectInput usw. Auch Netzwerk- und Musikgeräte werden unterstützt,
werden aber für Sicherheitszwecke hier nicht betrachtet. Für unsere Zwecke genügen
DirectInput und DirectDraw.
DirectInput stellt Informationen über Eingabeereignisse bereit, bevor diese vom
Betriebssystem zu Nachrichten verarbeitet werden. Simulierte Nachrichten in der
Nachrichtenwarteschlange einer Anwendung können damit erkannt und ignoriert
werden.
DirectDraw erlaubt die Ansteuerung der Ausgabehardware in einem exklusiven Modus,
sodass andere Programme an der Verfälschung der Ausgabe gehindert werden.
In der Skizze ist dargestellt, welche
Komponenten bei der Darstellung von
Daten einer Anwendung auf dem
Bildschirm beteiligt sind. Ohne DirectX
wird das GDI (Graphical Device Interface)
und das DDI (Display Driver Interface)
verwendet. Mit DirectX – genauer
DirectDraw – wird statt des DDI der HAL
(Hardware Abstraction Layer) genutzt. Ist
keine direkte Hardwareunterstützung
vorhanden, wird statt des HAL ein HEL
(Hardware Emulation Layer) verwendet
([Mi01]). Die Umgehung des GDI
ermöglicht den exklusiven Zugriff.
2313 Integrität und Authentizität der Eingabe
DirectInput erlaubt den Zugriff auf Eingabedaten, noch bevor diese in Windows-
Nachrichten umgewandelt werden. Hierfür werden keine besonderen Privilegien
benötigt. Aus Entwicklersicht ist diese Zugriffsmethode weniger komfortabel als mit den
angesprochenen Nachrichten. Es muss fortlaufend geprüft werden, ob neue Daten
vorhanden sind. Die üblichen Windows-Dialogkomponenten sind auf die Verarbeitung
von Nachrichten vorbereitet. Bei der Nutzung von DirectInput muss das Verhalten bei
Eingaben individuell programmiert werden. Es ist daher vorteilhaft, zuerst die
sicherheitsrelevanten Teile einer Applikation zu identifizieren und anschließend die
Eingabebehandlung von Windows-Nachrichten auf DirectInput umzustellen.
Ein Angreifer könnte nicht nur Windows-Nachrichten verfälschen, sondern auch
Eingaben mittels der SendInput API (bzw. keybd_event/mouse_event) simulieren. Diese
Eingaben würden im System erscheinen als wären sie von einem vertrauenswürdigen
Gerätetreiber erzeugt worden. Es funktioniert auch bei der Verwendung von DirectInput,
was Microsofts Bezeichnung „Direct“ relativiert.
Man könnte geneigt sein, einen Gerätetreiber zu verwenden, der seine an das System
übermittelten Eingabedaten signiert, um reale von verfälschten zu unterscheiden. Ein
weiterer Weg wäre die Eröffnung eines separaten Kommunikationskanals zwischen
Treiber und Anwendung mittels Inter-Prozess-Kommunikation. Wir stehen der Idee
eines separaten Kanals skeptisch gegenüber, da dies eine weitere proprietäre
Schnittstelle bedeuten würde, die zudem vom Gerätetreiber abhängig wäre. Ein
Filtertreiber könnte zu jedem Eingabeereignis Zusatzinformationen weitergeben, die
beispielsweise eine digitale Signatur der Daten beinhalteten. Empfangende Programme
könnten auf diese Informationen mittels GetMessageExtraInfo zugreifen und die
Gültigkeit des vorgeblichen Eingabeereignisses prüfen. Allerdings birgt auch dies
Probleme. Anwendung und Gerätetreiber müssten sich auf kryptographische Schlüssel
einigen, das Verfahren müsste gegen das Wiedereinspielen alter Nachrichten resistent
sein, und die Nutzung des ExtraInfo-Parameters könnte Konflikte mit bestehenden
Projekten hervorrufen, die diesen Parameter bereits für andere Zwecke nutzen.
Wir halten es für besser, andere Programme daran zu hindern, verfälschte Ereignisse
mittels SendInput einzuspielen. Verfälschungen können dann nur noch über Windows-
Nachrichten erfolgen, und solche können bei Nutzung von DirectInput erkannt und
ignoriert werden. Hierzu verwenden wir sogenannte Low-Level-Keyboard-Hooks, die
injizierte Eingaben unterdrücken. Diese Hooks müssen bei der Anmeldung eines
Benutzers aktiviert werden und verlangen eine Anpassung der Zugriffsrechte für den
Windows-Desktop des Benutzers.
2324 Integrität der Ausgabe
Sicherheitsrelevante Information wie beispielsweise Inhalte eines Vertragsentwurfs, für
den eine elektronische Signatur erstellt werden soll, sollte hinreichend korrekt sein zur
Zeit ihrer Verwendung für den gewünschten Zweck. Bei der herkömmlichen GDI-
Schnittstelle, die Windows-Anwendungen zur Ausgabe verwenden, kann ein Programm
nicht davon ausgehen, dass von ihm auf Ausgabegeräte geschriebene Information
unverändert durch andere Programme bleibt. DirectDraw erlaubt einer Applikation, den
Bildschirm in exklusivem Vollbildmodus zu nutzen – für Computerspiele der
Normalfall.
Ein Programm kann seine eigene exklusive Oberfläche erzeugen, um darauf Daten zu
schreiben. Inhalte dieser Oberfläche können von Angreifern nicht verändert werden und
erreichen den Benutzer daher unverfälscht. Die exklusive Oberfläche ist allerdings
unabhängig vom GDI und es können daher die GDI-Funktionen nicht verwendet werden.
Für den Anwendungsentwickler ist mehr Arbeit bei der Programmierung der Ausgabe
gefordert. Sicherheitskritische Bereiche einer Anwendung sollten identifiziert werden,
um den Aufwand dieser alternativen Ausgabemethode zu minimieren. Die starke
Nutzung von DirectDraw im Spielebereich zeigt, dass der Aufwand handhabbar ist.
Die Verwendung einer exklusiven Ansteuerung des Bildschirms ist ein weiterer Schritt,
Alternativen zu teuren Hardwarelösungen wie z.B. PDAs im Sicherheitsumfeld
aufzuzeigen.
Exklusive Ansteuerung des Bildschirms hindert andere Anwendungen nicht daran, selbst
im Vordergrund tätig zu sein. Die Integrität der Ausgabe wird mittels DirectDraw
gewahrt, nicht aber die Authentizität. Hier kann die Nutzung von Fenster-
Personalisierung (vgl. [TW96]) einen möglichen Angriff erschweren. Der Wechsel von
einer Anwendung zu einer anderen könnte auch detektiert und der Benutzer auf anderem
Wege, beispielsweise akustisch, gewarnt werden.
5 Implementierung
Wir zeigen an einem Beispiel die Nutzung der Mechanismen unter Microsoft Windows
2000/XP. Das erste Beispiel zeigt die Auswertung von Tastatureingaben, das zweite die
Darstellung eines Fensters auf einer sicheren Oberfläche.
Für unsere Tests verwenden wir DirectX Version 8.1. Die verwendete DirectDraw-
Schnittstelle trägt die Version 7. Quellkode ist in Borland Delphi geschrieben, die
DirectX-Header-Dateien sind dem Delphi-Jedi-Projekt entnommen ([De02]).
5.1 Eingabe
Im Beispiel prüfen wir, ob der Benutzer „j“ für „ja“ oder „n“ für „nein“ als Reaktion auf
eine Bestätigungsaufforderung eingegeben hat.
233SetCooperativeLevel auf Vordergrund
Stelle Verbindung zu Eingabegerät her
Warte auf Eingabedaten
Prüfe Gerätezustand
Prüfe Eingabedaten
Um andere, möglicherweise nichtvertrauenswürdige, Anwendungen daran zu hindern,
durch Aufruf von SendInput Benutzereingaben zu simulieren, ergänzen wir einen
sogenannten Low-Level-Keyboard-Hook. Dieser ermöglicht die Filterung von Eingaben.
Ist bei einem Tastaturereignis das Flag "LLKHF_INJECTED" gesetzt ([Mi03]), so wird
diese Eingabe verworfen und nicht weiter verarbeitet.
5.2 Ausgabe
DirectDraw wird in unserem Beispiel genutzt, um den Inhalt eines bestehenden Fensters
auf eine sichere Oberfläche zu zeichnen, die nicht manipuliert werden kann. Zunächst
fordern wir einen exklusiven Vollbildzugang zum Bildschirm an und erzeugen die
sichere Oberfläche. Wird die sichere Oberfläche nicht mehr benötigt, beispielsweise weil
eine sicherheitskritische Transaktion abgeschlossen wurde, geben wir den Bildschirm
wieder frei und kehren zur herkömmlichen GDI-Schnittstelle zurück.
Der Quellkode zeigt den grundsätzlichen Ansatz. In einer kommerziellen Anwendung
wären zusätzliche Routinen zur Behandlung von Fehlerereignissen angezeigt und es
sollte auf die aktuelle Auflösung und Farbtiefe Rücksicht genommen werden. Eine
Anwendung kann den Zugriff auf den Bildschirm auch verlieren, wenn mittels Alt+Tab
zu einer anderen Anwendung gewechselt wird.
In der ersten Prozedur aktivieren wir DirectDraw für unser Programm und schalten den
Vollbildmodus ein. Es werden zwei Oberflächen erzeugt, eine primäre und eine
sekundäre, welche wir als sichere Oberfläche nutzen.
Erzeuge DirectDraw-Objekt
SetCooperativeLevel Vollbild+Exklusiv
Erzeuge primäre Oberfläche
Erzeuge sekundäre Oberfläche (als sichere Oberfläche)
Nun wird der Inhalt eines bestehenden Fensters auf die sekundäre Oberfläche
gezeichnet. Die Oberflächen werden gewechselt, sodass die sichere sekundäre
Oberfläche sichtbar wird. Im Beispiel wird das Fenster zentriert auf schwarzem
Hintergrund angezeigt.
Ermittle Gerätekontext für sichere Oberfläche
Zeichne Fensterinhalt auf sichere Oberfläche
Wechsle sichtbare Oberfläche
234Schließlich stellen wir die GDI-Oberfläche wieder her und erlauben anderen
Programmen wieder die Nutzung des Bildschirms.
Wechsle sichtbare Oberfläche zur GDI-Oberfläche
SetCooperativeLevel Normal
6 Zusammenfassung
Trojanische Pferde, Programme mit einer zusätzlichen Funktionalität, die gegen die
Interessen des Benutzers gerichtet ist, sind zunehmend beliebtere Formen von Angriffen
auf Rechensysteme. Anwendungen, die in einer solchen unsicheren Umgebung
ausgeführt werden, sollten die Kontrolle über ihre Kommunikation mit dem Benutzer
haben.
Wir haben einen Weg gezeigt, mit dem Applikationen existierende Schnittstellen für die
Spieleprogrammierung nutzen können, um Eingabe- und Ausgabegeräte direkt
anzusteuern. Im Vergleich mit spezieller Hardware oder der Entwicklung neuer sicherer
Betriebssysteme bietet unsere Lösung handhabbare und kostensparende Mittel, ein
höheres Schutzniveau in sicherheitskritischen Anwendungen zu schaffen.
Diese Arbeit betrachtet Integrität und Authentizität. Vertraulichkeit der Benutzereingabe
oder der Programmausgabe werden nicht diskutiert.
Derzeit arbeiten wir daran, Anwendungsentwicklern Komponenten bereitzustellen, um
bestehende Anwendungen nachträglich mit einer sicheren Benutzerschnittstelle
auszustatten. Oft benötigen nur wenige Teile einer Anwendung erhöhte Sicherheit. Um
die Modifikation bestehenden Programmkodes gering zu halten, könnten auch Schichten
in Frage kommen, die Ausgabeintegrität um eine Anwendung herum gewährleisten.
Eingabeintegrität scheint als externe Schicht problematisch. Für die Authentizität der
Programmausgabe untersuchen wir Fenster-Personalisierung und den Ersatz der
bestehenden Windows-Shell.
Literaturverzeichnis
[Ba01] Balfanz, D.: Access Control for Ad-hoc Collaboration. Dissertation, Princeton
University, 2001.
[Br98] Bråthen, R.: Crash Course in X Windows Security. In: GridLock 1.
http://www.hackphreak.org/gridlock/issues/issue.1/xwin.html, 1998.
[Ce99] CERT Coordination Center. CERT Advisory CA-99-02-Trojan-Horses.
http://www.cert.org/advisories/CA-1999-02.html, 1999.
[Cu03] Cult of the Dead Cow. Back Orifice 2000. http://bo2k.sourceforge.net, 2003.
[De02] Delphi-Jedi Project. DirectX headers and samples. http://www.delphi-jedi.org,
2002.
235[Fi95] Fisher, J. Securing X Windows. UCRL-MA-121788. CIAC-2316 R.0.
http://ciac.llnl.gov/ciac/documents/ciac2316.html, 1995.
[Fr03] Fraunhofer-Institut für Sichere Telekooperation SIT. TruPoSign. Trusted
Pocket Signer. Projektflyer.
http://www.sit.fhg.de/german/SICA/sica_projects/project_pdfs/trupos.pdf,
2003.
[FHW00]Freudenthal, M., Heiberg, S., Willemson, J. Personal Security Environment on
Palm PDA. In: Proceedings of 16th Annual Computer Security Applications
Conference (ACSAC ’00), 2000. S. 366-372.
[JO01]
Proceedings of IFIP Working Conference on Security and Control of IT in
Society II, 2001. S. 63-74.
[MM02] Maña, A., Matamoros, S. Practical Mobile Digital Signatures. In: Bauknecht,
K., Min Tjoa, A., Quirchmayr, G. (Hrsg.) E-Commerce and Web Technologies.
LNCS 2455, 2002. S. 224-233.
[Mi98] Microsoft. Microsoft Windows Architecture for Developers Training Kit.
[Mi01] Microsoft. DirectDraw Architecture, System Integration. In: Microsoft
Developer Network Library, 2001.
[Mi03a] Microsoft. Microsoft Developer Network Library, 2003.
[Mi03b] Microsoft. KBDLLHOOKSTRUCT Structure. In: Microsoft Developer
Network Library, 2003.
[Pf01] Pfitzmann, B., Riordan, J., Stüble, C., Waidner, M., Weber, A. The PERSEUS
System Architecture. IBM Research Report RZ 3335 (#93381) 04/09/01, IBM
Research Division, Zürich, 2001. http://www-krypt.cs.uni-sb.de/~perseus/
[SCL01] Spalka, A., Cremers, A.B., Langweg, H. The Fairy Tale of »What You See Is
What You Sign«. Trojan Horse Attacks on Software for Digital Signatures. In:
Proceedings of IFIP Working Conference on Security and Control of IT in
Society II, 2001. S. 75-86.
[TW96] Tygar, J.D., Whitten, A. WWW Electronic Commerce and Java Trojan Horses.
Proceedings of Second USENIX Workshop on Electronic Commerce, 1996.
[We98] Weber, A. See What You Sign: Secure Implementations of Digital Signatures.
5th International Conference on Intelligence in Services and Networks.
IS&N’98. LNCS 1430, 1998. S. 509-520.
236Sie können auch lesen
