DE60211900T2

DE60211900T2 - Verfahren und vorrichtung zur bewahrung von sicherer dateneingabe und datenausgabe

Info

Publication number: DE60211900T2
Application number: DE60211900T
Authority: DE
Inventors: D. David Bainbridge Island NASON; Carson Seattle KAAN; John E. Vashon EASTON; M. Jason Redmond SMITH; John A. Everett PAINTER; William J. Everett HEATON
Original assignee: xSides Corp
Current assignee: xSides Corp
Priority date: 2001-06-08
Filing date: 2002-06-10
Publication date: 2006-10-12
Anticipated expiration: 2022-06-11
Also published as: EP1402334A2; ATE328316T1; WO2002101526A3; JP2005504365A; EP1402334B1; WO2002101526A2; DE60211900D1

Description

Hintergrund der Erfindung
Gebiet der Erfindung
Die Erfindung betrifft Verfahren und Systeme zur Erhaltung der Sicherheit von Daten in einer computerbasierten Umgebung und insbesondere Verfahren und Systeme zur Erhaltung der Sicherheit von Daten bei deren Eingabe seitens einer Eingabevorrichtung, so beispielsweise einer Maus oder Tastatur, und deren Ausgabe beispielsweise über eine Audio- oder Videoeinrichtung.
Hintergrundinformation
Das Konzept der Sicherheit wird in einer Welt, in der Personalcomputersysteme üblicherweise über drahtlose oder verdrahtete Netzwerke und/oder internetbasierte Netzwerke (internetworks), so beispielsweise das Internet, mit anderen Computersystemen verbunden sind, zunehmend wichtig. Zahlreiche Unternehmen und Institutionen haben sich mit Sicherheitsfragen befasst, die beispielsweise die Übertragung von Daten von einem Personalcomputersystem (Clientcomputersystem) zu Servercomputersystemen über Netzwerkdatenaustauschvorgänge betreffen. Firewalls sind in Ortsbereichsnetzwerken (local area networks LANs) üblicherweise vorhanden und bilden Grenzen gegenüber dem Rest der internetvernetzten Welt und Computersystemen in dem LAN. Darüber hinaus finden bei derartigen Datenübertragungen oftmals gängige Verschlüsselungstechniken Anwendung, um die Sicherheit der Datenaustauschwege zu gewährleisten.
Gleichwohl besteht auf den Clientcomputersystemen selbst ein Problem bei wertvollen Daten, die oftmals in gültiger Form auf dem Clientcomputersystem gespeichert sind, obwohl sie in verschlüsselter Form über einen Datenaustauschkanal an ein Servergerät übertragen werden können. So kann beispielsweise ein Anwender, der einen Gegenstand über das Internet zu kaufen wünscht, eine Website aufrufen, sich dort einloggen und seine/ihre Kreditkarteninformation zum Zwecke des Erwerbs des Gegenstandes eingeben. Wiewohl die Website (und der Clientbrowser auf dem Clientgerät) die Über tragung der Kreditkarteninformation unter Verwendung einer sicheren Datenaustauschschicht (so beispielsweise unter Verwendung von SSL – secure socket layer protocol) vornimmt, verbleibt die Kreditkarteninformation, damit sie auf der Anzeigevorrichtung des Clientcomputersystems angezeigt werden kann, in Form gültiger Daten für eine gewisse Zeitspanne im Speicher. Unbefugte „Hacker" (Eindringlinge) können dann unter Verwendung ausgefeilter Mechanismen auf diese gespeicherten Daten zugreifen (vorausgesetzt, sie werden nicht von einer Firewall davon abgehalten oder sind als schädliche Anwendungen (rogue applications) auf dem Clientcomputersystem installiert), und zwar auch dann, wenn die Daten nur kurz gespeichert werden. Es besteht daher ein ständig steigender Bedarf an der Bereitstellung von Techniken zur Sicherung von Daten auf einem Clientgerät.
Das US-Patent 5,825,879 offenbart ein System und ein Verfahren zur Bereitstellung eines Kopierschutzes für einen verteilten Videoinhalt. Elektronische Hardware des Systems ist in einer Sicherheitshülle eingeschlossen, die den Zugriff auf unverschlüsselte digitale Daten verhindert. Digitale Videoinformation wird in einem Frame-Puffer in verschlüsselter Form gespeichert und zum Zwecke einer analogen Ausgabe nach dem Auslesen aus dem Frame-Puffer in der sicheren Hardware entschlüsselt.
Kurzbeschreibung der Erfindung
Die Aufgabe der vorliegenden Erfindung besteht darin, die Sicherheit der Videoinhaltsdaten auf einem Clientcomputersystem zu erhöhen, um Versuche seitens unbefugter Prozesse, Anwendungen oder Geräte, Daten auf unbefugte Weise zu erlangen, zu unterbinden und/oder zu erschweren.
Die Aufgabe wird durch das Verfahren nach Anspruch 1 gelöst. Vorteilhafte Ausführungsbeispiele der Erfindung sind in den abhängigen Ansprüchen niedergelegt.
Nachstehend werden computerbasierte Verfahren und Systeme zur Erhöhung der Sicherheit für Daten während der Eingabe und Ausgabe auf einem Clientcomputersystem beschrieben, um Versuche seitens unbefugter Prozesse, Anwendungen oder Geräte, Daten auf unbefugte Weise zu erlangen, zu unterbinden und/oder zu erschweren. Im Sinne der vorliegenden Beschreibung umfassen „Daten" in einem Computersystem befindliche Digitalbits oder Analogsignale, die zu beliebigen Zwecken übertragen oder gespeichert werden, darunter Grafiken, Texte, Audio, Video, Eingabesignale, Ausgabesi gnale und dergleichen mehr. Als Beispiel angeführte Ausführungsbeispiele stellen eine Mehrzahl von Verschleierungstechniken sowie sicherheitserhöhter Systemniveautreiber bereit, bei denen die Verschleierungstechniken zum Einsatz kommen, um unbefugte Empfänger beziehungsweise Betrachter der Daten davon abzuhalten, die gültigen Daten zu empfangen beziehungsweise zu betrachten. Werden derartige Verschleierungstechniken mit den sicherheitserhöhten Treibern verwendet, so können die Treiber sicherstellen, dass von den unbefugten Empfängern beziehungsweise Betrachtern stets ungültige Daten empfangen beziehungsweise betrachtet werden, wodurch verhindert wird, dass unbefugte Hacker (Eindringlinge) auf gültige Daten zugreifen. Verschiedene Verschleierungstechniken bieten per se verschiedene Sicherheitsniveaus.
Im Sinne der vorliegenden Beschreibung betrifft der Begriff „Verschleierung" („obfuscation") einen beliebigen Mechanismus oder eine beliebige Technik zur Umwandlung oder zum Verbergen gültiger Daten derart, dass die gültigen Daten ohne die richtige Befugnis nur schwer betrachtet, abgefangen, verarbeitet oder abgewandelt werden können und daher bei einem unbefugten Zugriff als ungültige Daten erscheinen.
Verschleierungstechniken können als Software, Hardware oder Firmware implementiert sein, was von der jeweils von Interesse seienden ausführenden Umgebung abhängt.
Bei einigen Ausführungsbeispielen umfassen die verschleierten Daten beispielsweise eine opake Farbe, so beispielsweise reines Schwarz oder reines Weiß, ein Muster, eine Zufallsbitmap, Rauschen, maskierte Daten, ein Bild, ein Firmenlogo oder Werbung. Andere Arten der Verschleierung sind in Abhängigkeit von der Art der Daten ebenfalls möglich.
Zur sicheren Anzeige von Daten auf einer Anzeigevorrichtung und auf anderen Arten von Anzeigespeichern umfassen die Verschleierungstechniken die Techniken „Herauskopieren" („copy out"), _"Ersetzen und Wiederherstellen" („replace und restore") und direkte Ersetzung („in-place replacement"). Durch diese Techniken wird spezifiziert, wo (und wie) verschleierte Daten entschleiert werden, um gültige Daten zum Zwecke der Anzeige zu erzeugen, und wo (und wie) Daten neuverschleiert werden. Bei derartigen Techniken kommt ein Overlay-Puffer oder ein Masken-Puffer in Verbindung mit einem Frame-Puffer zur Bewerkstelligung des Verschleierungsprozesses zum Einsatz. Bei anderen wird vorteilhafterweise eine beliebige Standardrasteroperation oder eine Overlay-Operationslogik verwendet, die bereits auf einer Videokarte vorhanden ist. Bei weiteren Ausführungsbei spielen werden die Verschleierungstechniken auf die Inhaltskoordinierung bei anderen Arten von Speichern angewandt.
Bei einigen Ausführungsbeispielen implementieren sicherheitserhöhte Treiber (security enhanced drivers SEDs) verschiedene Grade und Niveaus der Sicherheit, und zwar von der Bereitstellung von Daten mit verstümmelter Information oder Rauschen bis hin zu verschlüsselten Daten. Die SEDs können mit verschiedenen Verschleierungstechniken verwendet werden, um zu bestimmen, was zur Verschleierung der Daten verwendet wird und wie und wo die Daten herkommen. Die SEDs sind für die Koordinierung der Verschleierung und Entschleierung (wie auch der Neuverschleierung) der Daten zuständig.
Bei einem Ausführungsbeispiel ist ein sicherheitserhöhter Anzeigetreiber (security enhanced display driver SEDD) vorgesehen, um den Inhalt von Abschnitten eines Frame-Puffers gemäß Speicherung in einem Videoanzeigespeicher zu koordinieren. Bei diesem Ausführungsbeispiel erfolgt bei dem SEDD eine Anfrage betreffend die Anzeige von Daten in einem sicheren Bereich auf einer Videoanzeige. In Reaktion hierauf weist der SEDD einen entsprechenden sicheren Abschnitt des Frame-Puffers zu und koordiniert den Dateninhalt dieses sicheren Abschnittes derart, dass gültige Daten nur in dem sicheren Abschnitt und nur zu dem Zeitpunkt vorhanden sind, wenn sie für die Anzeige auf der Anzeigevorrichtung benötigt werden, wobei andere Aufgaben von einem Zugriff (Lesen oder Schreiben) auf den sicheren Abschnitt ausgesperrt sind. Der SEDD bestimmt in Abhängigkeit von der verwendeten Verschleierungstechnik, wann in dem sicheren Abschnitt gespeicherte Daten entschleiert werden müssen und wann eine Neuverschleierung von Nöten ist.
Bei anderen Beispielen werden sicherheitserhöhte Treiber für Eingabevorrichtungen, so beispielsweise für eine Maus, für eine Tastatur oder für eine andere Zeigevorrichtung, bereitgestellt. Diese SEDs wirken durch Abfangen der Eingabedaten direkt bei deren Eintreffen von der Eingabevorrichtung, Umwandeln der Daten in verschleierte Form, wenn sichere Eingabedaten angefordert sind, und Weiterleiten der umgewandelten Daten an den anfordernden Code. Werden Eingabedaten für eine Aufgabe empfangen, die nicht zum Empfang sicherer Daten befugt ist, so werden die Eingabedaten zu Standardbetriebssystemeingabetreibern über einen Standardeingabestapel geleitet.
Bei einigen Beispielen werden die SEDs nach dem _"first-in-line"-Prinzip in der Treiberverarbeitungsreihenfolge installiert, um sicherzustellen, dass der SED die Daten vor je dem anderen Code abfängt. Bei einigen Ausführungsbeispielen werden Überwachungsdienste (monitoring services) und/oder Wachhunddienste (watchdog services) erzeugt, um die Sicherheit dieser „first-in-line"-Hooks zu gewährleisten.
Bei anderen Beispielen werden andere Techniken zur Festlegung bestimmter in dem System angebotener Sicherheitsniveaus bereitgestellt. Einige dieser Techniken bieten zudem Information im Zusammenhang mit der Quelle der Sicherheit. Vorhanden sind Techniken, um Standardanwenderschnittstellenelemente, so beispielsweise Scrollbars, Überschriftenzeilen und dergleichen mehr, zu manipulieren, sowie Techniken, die die Darstellung eines Cursors automatisch abwandeln, wenn sich der Eingabefokus von einem Gebiet in ein anderes Sicherheitsgebiet verlagert.
Kurzbeschreibung der Zeichnung
1 ist ein Beispielsblockdiagramm der Abstraktionsschichten einer Standardcomputerarchitektur, die sicherheitserhöhte Treiber entsprechend Ausführungsbeispielen der vorliegenden Erfindung enthält.
2 ist ein Beispielsblockdiagramm der Art, wie Daten in einem typischen Computersystem auf eine Anzeigevorrichtung übertragen werden.
3 ist ein Beispielsblockdiagramm, in dem die Art gezeigt ist, wie das Hacken einer Anzeige erfolgt.
4 ist ein Beispielsblockdiagramm der allgemeinen Techniken, die von einem als Beispiel angegebenen sicherheitserhöhten Anzeigetreiber verwendet werden, um einen unbefugten Zugriff auf in einem Frame-Puffer gespeicherte Daten zu verhindem.
5 ist ein Beispielsblockdiagramm eines vorbestimmtem sicheren Abschnittes eines Videoanzeigespeichers (video display memory VRAM) entsprechend einem als Beispiel angegebenen sicherheitserhöhten Anzeigetreiber.
6 ist ein Beispielsblockdiagramm von Verschleierungstechniken, die in Verbindung mit Entschleierungstechniken vom "Copy out"-Typ verwendet werden.
7 ist ein Beispielsblockdiagramm von Abwandlungen der Entschleierungstechniken vom „Copy out"-Typ.
8 ist ein Beispielsblockdiagramm von Verschleienrungstechniken, die in Verbindung mit Entschleierungstechniken vom _"Replace and Restore"-Typ verwendet werden.
9 ist ein Beispielsblockdiagramm von Verschleierungstechniken, die in Verbindung mit Entschleierungstechniken vom _"In-place replacement"-Typ verwendet werden.
10 ist eine beispielhafte Darstellung der Koordinierung der Verschleierung und Entschleierung von Inhalten des Frame-Puffers durch einen als Beispiel angegebenen sicherheitserhöhten Anzeigetreiber.
11 ist ein Beispielsblockdiagramm eines weiteren die Verschleierung und Entschleierung betreffenden Lösungsansatzes, der zur Koordinierung der zeitlichen Abstimmung der Verschleierung und der Entschleierung des gesamten Frame-Puffers verwendet werden kann.
12 ist ein Beispielsflussdiagramm einer als Beispiel angegebenen Anwendungsniveauroutine zur Anforderung einer Verlagerung in einen sicheren Anzeigebereich.
13 ist ein Beispielsflussdiagramm von Schnittstellen bei einem als Beispiel angegebenen sicherheitserhöhten Anzeigetreiber zum Zwecke der Steuerung der Verschleierung eines sicheren Anzeigebereiches in einem echten multitasking- und hardwarebasierten sowie ereignisgesteuerten (event-driven) System.
14 ist ein Beispielsflussdiagramm von Schnittstellen bei einem als Beispiel angegebenen sicherheitserhöhten Anzeigetreiber zum Zwecke der Steuerung der Verschleierung eines sicheren Anzeigebereiches auf nichtereignisgesteuerte Weise in einer alternativen Betriebssystemumgebung.
15 ist ein Beispielsflussdiagramm eines Vertical-blank-Zeitabstimmungs- und Synchronisationsthreads, der zur Steuerung des Frame-Pufferinhaltes verwendet wird und die Koordinierung in der alternativen Betriebssystemumgebung von 14 vornimmt.
16 ist ein Beispielsflussdiagramm eines Codes zur Bestimmung von Korrelationen zwischen Vertical-blank und VRAM-Adresse, wie sie zur Steuerung der Koordinierung des Frame-Puffers verwendet wird.
17 ist ein Beispielsflussdiagramm eines Echtzeitverschleierungssteuerungsthreads gemäß Verwendung durch den sicherheitserhöhten Anzeigetreiber zum Zwecke der Bereitstellung gültiger und ungültiger Daten für den Frame-Puffer.
18 ist ein Beispielsblockdiagramm, das die Art darstellt, wie das Erkennen von Eingabedateien erfolgt.
19 ist ein Beispielsblockdiagramm der allgemeinen Techniken, die von einem sicherheitserhöhten Eingabetreiber, so beispielsweise einem sicherheitserhöhten Maustreiber, verwendet werden, um einen unbefugten Zugriff auf die Eingabedaten zu verhindern.
20 ist ein Beispielsflussdiagramm der Verschleierungstechniken gemäß Verwendung durch einen als Beispiel angegebenen sicherheitserhöhten Tastaturtreiber zum Zwecke der Verhinderung eines unbefugten Zugriffs auf die Eingabedaten.
21 ist ein Beispielsblockdiagramm, das die Art darstellt, wie das Hacken von Audiodaten erfolgt.
22 ist ein Beispielsflussdiagramm der Verschleierungstechniken gemäß Verwendung durch einen als Beispiel angegebenen sicherheitserhöhten Audiotreiber zum Zwecke der Verhinderung eines unbefugten Zugriffs auf die Audiodaten.
23 ist ein Beispielsblockdiagramm betreffend das Installieren eines sicherheitserhöhten Treibers als first-in-line-Treiber in Windows-9x-Betriebssystemumgebungen sowie betreffend die damit verbundenen Überwachungsprozesse.
24 zeigt eine als Beispiel angegebene Bildschirmanzeige, die ein Padlock (Vorhängeschloss) zur Festlegung der Sicherheit darstellt, wie sie in bestehenden Softwareanwendungen Verwendung findet.
25 ist eine als Beispiel angegebene Bildschirmanzeige, die die Verwendung des Cursors darstellt, um das Sicherheitsniveau zu bestimmen, sowie andere Darstellungen in Fenstern, die zur Bezeichnung der Sicherheit verwendet werden.
Detailbeschreibung der Erfindung
Nachstehend werden computerbasierte Verfahren und Systeme beschrieben, bei denen die Sicherheit von Daten während der Eingabe und Ausgabe in einem Clientcomputersystem erhöht wird, um Versuche seitens unbefugter Prozesse, Anwendungen oder Geräte, Daten auf unbefugte Weise zu erlangen, zu verhindern und/oder zu erschweren. Im Sinne der vorliegenden Beschreibung umfassen „Daten" Digitalbits oder Analogsignale in einem Computersystem, die zu einem beliebigen Zweck übertragen oder gespeichert werden, darunter Grafiken, Texte, Audio, Video, Eingabesignale, Ausgabesignale und dergleichen mehr. Angegeben werden Beispiele für eine Mehrzahl von Verschleierungstechniken und sicherheitserhöhter Treiber (üblicherweise auf Systemniveau), bei denen derartige Verschleierungstechniken zum Einsatz kommen, um unbefugte Empfänger beziehungsweise Betrachter der Daten davon abzuhalten, gültige Daten zu empfangen beziehungsweise zu betrachten. Werden diese Verschleierungstechniken mit den sicherheitserhöhten Treibern verwendet, so können die Treiber sicherstellen, dass von den unbefugten Empfängern beziehungsweise Betrachtern stets ungültige Daten empfangen beziehungsweise betrachtet werden, wodurch unbefugten Hackern ein Zugriff auf gültige Daten verwehrt wird. Einige Verschleierungstechniken bieten per se veränderliche Sicherheitsniveaus.
Im Sinne der vorliegenden Beschreibung bezeichnet der Ausdruck „Verschleierung" („obfuscation") einen beliebigen Mechanismus oder eine beliebige Technik zum Umwandeln oder Verbergen gültiger Daten derart, dass die gültigen Daten ohne die richtige Befugnis schwer zu betrachten, abzufangen, zu verarbeiten oder abzuwandeln sind und daher bei einem unbefugten Zugriff als ungültige Daten erscheinen (Der Begriff _"Verschleiern" meint ein „Unkenntlichmachen"). Verschleierungstechniken können als Software, Hardware oder Firmware implementiert sein, was von der von Interesse seienden ausführenden Umgebung abhängt. Obwohl Standardverschlüsselungstechniken eine Art der Verschleierung darstellen, kann eine Vielzahl anderer Techniken zum Einsatz kommen, darunter das Umwandeln von Daten zwischen gültigen Formen und ungültigen Formen, das temporäre und dynamische Bewegen von Rauschdaten durch die ansonsten gültigen Daten und dergleichen mehr. Die Verfahren und Systeme beschreiben ver schiedene Techniken, durch die ein unbefugtes Hacken und Abfragen von Daten verhindert wird. „Hacken" meint im Sinne der vorliegenden Beschreibung jede Art von illegaler und/oder unbefugter Verwendung oder Betrachtung von Daten unter Einsatz einer beliebigen Technik zum Abfangen von Daten oder zum Überwachen von Daten oder Zugriffsmustern.
Die sicherheitserhöhten Treiber (SEDs) implementieren verschiedene Grade und Niveaus von Sicherheit, vom einfachen Speichern und Präsentieren der Daten mit verstümmelter Information oder Rauschen, verschlüsselten Daten bis hin zu Daten, die durch einen unbefugten Code als ungültig erfasst oder empfangen werden. In jedem Fall liegt der Schwerpunkt der sicherheitserhöhten Treiber darin, gültige Daten als verschleierte (und damit ungültige) Daten zu speichern und diese Daten unbefugten Clients (Code, Anwendern, Hardware und dergleichen) darzubieten. Bei einem Ausführungsbeispiel der vorliegenden Erfindung umfasst ein sicherheitserhöhter Treiber einen sicherheitserhöhten (Video-)Anzeigetreiber (security enhanced display driver SEDD); einen sicherheitserhöhten Maustreiber (security enhanced mouse driver SEMS), wobei die Techniken im Allgemeinen für eine beliebige Eingabevorrichtung vom Anzeigetyp (oder eine beliebige Eingabevorrichtung auf Basis von x,y-Koordinaten) von Nutzen sind; einen sicherheitserhöhten Tastaturtreiber (security enhanced keyboard driver SEKD); und einen sicherheitserhöhten Audiotreiber (security enhanced audio driver SEAD). Jeder dieser Treiber und jede der entsprechenden verwendbaren Verschleierungstechniken wird in den nachfolgenden Unterabschnitten besprochen. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass andere Treiber für andere Quellen von Eingabe- und Ausgabevorrichtungen auf ähnliche Weise konstruiert und/oder implementiert sein können, und zwar unter Verwendung von Techniken, Verfahren und Systemen gemäß vorliegenden Beschreibung.
1 ist ein Beispielsblockdiagramm der Abstraktionsschichten einer Standardcomputerarchitektur, die sicherheitserhöhte Treiber entsprechend Ausführungsbeispielen der vorliegenden Erfindung enthält. Wie in 1 zu sehen ist, ist, was für viele Computersysteme typisch ist, die Betriebssystemschicht 101 mit dem Kemel und den Betriebssystemvorrichtungstreibern (so beispielsweise den Treibern für die Maus, die Tastatur, die Anzeige, die Audioanwendungen und das Netzwerk) auf der untersten Ebene der Softwareausführungsarchitektur resident. Die Betriebssystemschicht 101 kommuniziert direkt mit der Hardware und/oder Hardwareschnittstellenkarten, so beispielsweise der Maus 110, der Tastatur 120, der Anzeige 130 und der Netzwerkschnittstellenkarte 140. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass andere Hardware und andere Treiber, auch wenn sie nicht dargestellt sind, (darunter Audioabspielgeräte und zugehörige Betriebssystemaudiotreiber) in einem derartigen System ebenfalls resident sein können. Über den Betriebssystemvorrichtungstreibern arbeitet weitere (üblicherweise einem höheren Niveau zugehörige) Treibersoftware 102 und nimmt kompliziertere Abstrahierungen der Hardware bezüglich der Anwendungsschicht 104 und der Anwendungssoftwarebibliotheken 203 vor. Die Treibersoftware 102 enthält Schnittstellen und Bibliotheken von Funktionen, die die Anwendungen beim Empfangen und Verarbeiten von Eingaben und Ausgaben, so beispielsweise im Zusammenhang mit einer Maus- und Tastaturschnittstelle gemäß Bereitstellung durch eine fensterbasierte Schnittstelle, oder einer Anzeigeschnittstelle, so beispielsweise einem Windows-GDI-Betriebssystem, unterstützen. Anwendungen (applications API) 103 stellen oftmals Abstraktionen auf noch höherem Niveau für Anwendungen 104 bereit, so beispielsweise für wiederverwendbare Objekte, die in objektorientiertem Anwendungscode klassifiziert werden können. Auf dem obersten Niveau arbeiten üblicherweise (Desktop-)Anwendungen 104 über allen anderen Schichten und kommunizieren progressiv durch die Schichten, um die Eingaben in die Hardware und die Ausgaben aus der Hardware zu verarbeiten. Bei einigen Beispielen sind die sicherheitserhöhten Treiber (SEDs) 406 vorzugsweise zwischen den Betriebssystemvorrichtungstreibern 105 und der Hardware resident, um so besser die sichere Verarbeitung der Eingabe und Ausgabe in den untersten Schichten des Computersystems zu steuern.
Um eine Datenverschleierung auf eine Weise zu implementieren, die gültige Daten nur für befugte Anwender bereitstellt, benötigt jeder SED üblicherweise eine Art von Mechanismus zum Aussperren eines Teils des Systems (eine Ressource, so beispielsweise einen Abschnitt des Frame-Puffers auf einer Videokarte). Da verschiedene Betriebssysteme (Kernels oder andere Prozesskoordinierungen) verschiedene Mechanismen bereitstellen, um sicherzustellen, dass ein Treiber eine „Priorität" bei der Koordinierung von Aufgaben des Betriebssystems innehat (Prozesse, Threads, Code beliebiger Art und dergleichen mehr), ist oftmals die Implementierung eines Mechanismus von Nöten, um sicherzustellen, dass ein SED in dem System ein „Treiber des ersten Niveaus" (first level driver) ist. Dies bedeutet, dass ein Mechanismus vorhanden sein muss, um sicherzustellen, dass der Treiber, der ein „Hooking" der Eingabe oder Ausgabe vornimmt, die Daten zuerst erhalten kann, bevor andere Treiber oder Codes, so beispielsweise Betriebssystemtreiber (Betriebssystemvorrichtungstreiber 105 in 1) dies tun. Eine Technik besteht in der Implementierung des SED als Systemniveautreiber, in der Initiali sierung des Systems, um diesen Treiber als ersten Treiber „in line" (von diesem Typ oder gegebenenfalls in der Gesamtereignisverarbeitungstreiberkette) bereitzustellen, und in der Bereitstellung eines „Wachhund"-Prozesses zur Überwachung der Position und Sicherheit des SED. Verschiedene Betriebssysteme erfordern verschiedene Techniken bezüglich der Installierung eines Treibers als „first in line" und bezüglich der Bedeutung von „first in line". Techniken zur Installierung eines Treibers als „first in line" sind einem Fachmann auf dem einschlägigen Gebiet bekannt und hängen von dem jeweiligen Betriebssystem ab. Eine Beschreibung von als Beispiel angegebenen Implementierungen unter Verwendung von Abkömmlingen von Windows 9X und Windows NT erfolgt in dem Abschnitt mit dem Titel „First-in-Line-SED-Installierung und Wachhundüberwachung".
Zur Ergänzung der Verschleierungstechniken und sicherheitserhöhten Treiber stellen die beschriebenen Verfahren und Systeme zudem verschiedene Techniken zur Bezeichnung bestimmter Sicherheitsniveaus in dem System bereit. Als Beispiel angegebene Bildschirmanzeigen dieser Techniken sind angegeben und werden anhand 24 und 25 beschrieben. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass andere Techniken zur Bezeichnung der Sicherheit möglich und auch funktionell gleichwertig sind.
Sicheres Speichern und Anzeigen von Videoinhalt
Videoinhalt ist im Allgemeinen auf vielen Niveaus und in verschiedenen Szenarios durch Hacking verwundbar. 2 ist ein Beispielsblockdiagramm der Art, wie Daten in einem typischen Computersystem auf eine Anzeigevorrichtung übertragen werden. Gemäß 2 kommunizieren das Betriebssystem und die Anwendungen 201 mit einer Betriebssystemanzeigeschnittstelle 202 (üblicherweise einer grafischen Bibliothek, so beispielsweise GDI in der Windowsbetriebssystemumgebung), um eine „Desktopfläche" („desktop canvas") zu ziehen, das heißt eine Bitmapdarstellung desjenigen Gebietes der Anzeigevorrichtung 220, das das Betriebssystem für die Anwenderschnittstelle steuert (Diese Bitmap wird üblicherweise in einem Speicher mit wahlfreiem Zugriff (RAM) gespeichert und kann vermöge bestimmter Mechanismen des Betriebssystems gegenüber den Anwendungen verborgen bleiben). Der Anzeigetreiber des Betriebssystems (operating system OS) sendet diese Bitmap anschließend an die Videokarte zum Zwecke der Speicherung in dem Videoanzeigespeicher 203 (beispielsweise VRAM), der auf der Karte resident ist. Die zu ziehende Bitmap wird als statische Bitmap üblicherweise in einem vorbezeichneten Abschnitt des VRAM gespeichert, der als Frame-Puffer 204 bezeichnet wird. Das Gebiet des Frame-Puffers 204, das demjenigen Abschnitt der Anzeigevorrichtung 220 (Schirm) entspricht, der von der Betriebssystemanwenderschnittstelle (üblicherweise als "das Desktop" bezeichnet) verwendet wird, kann ein Abschnitt des gesamten Frame-Puffers 204 sein. Dies bedeutet, dass das Betriebssystem 204 (und die Anwendungen) gegebenenfalls nicht das ganze anzeigbare Gebiet der Anzeige 220 verwenden. Der Abschnitt der Anzeige 220, der von dem Betriebssystem 204 verwendet wird, wird üblicherweise mittels bekannter Videomodi beschrieben und eingestellt, die in Auflösungskoordinaten angegeben sind, so beispielsweise als Gebiet mit 1024 mal 768 Pixel [Anwendungen und Techniken zur Erweiterung der Anwendung einer Anzeigevorrichtung (was man bisweilen als „physische Überabtastung" („physical overscan") bezeichnet) oder zum Teilen der Anzeigevorrichtung zwischen der Betriebssystemanwenderschnittstelle und einem Gebiet der Anzeige, auf die das Betriebssystem keinen Zugriff hat, werden detailliert in dem dem gleichen Inhaber zu Eigenen und am 28. November 2000 eingereichten US-Patent 6,677,964 mit dem Titel "Method and System for Controlling a Complementary User Interface on a Display Surface", dem am 25. Januar 2000 eingereichten US-Patent 6,018,332 mit dem Titel „Overscan User Interface" und dem am 11. Dezember 2001 eingereichten US-Patent mit dem Titel „Secondary User Interface" wie auch in weiteren einschlägigen Patenten beschrieben]. Der VRAM 203 wird von der Videokarte (und den Videotreibern) auch verwendet, um andere Arten von Information zu speichern. In einer typischen PC-Umgebung kann – nunmehr mit weiterentwickelten Videokarten – ein Overlay-Puffer 205 oder mehrere hiervon in dem VRAM 203 resident sein. In diesen Karten ist eine weiterentwickelte Logik bereitgestellt, die eine grafische Verarbeitungseinheit (graphics processing unit GPU) (oder ein anderes Element, das für das Übertragen von Daten aus dem VRAM 203 auf den Anzeigeschirm 220 zuständig ist) in die Lage versetzt, ein Overlaying von Bits aus dem Overlay-Puffer 205 vorzunehmen, wenn die GPU Bits aus dem Frame-Puffer 204 in die Anzeige 220 herauskopiert. Bei einigen Karten werden die Overlay-Bits mit entsprechenden Bits aus dem Frame-Puffer 204 unter Verwendung einer komplexen Logik zwischen UND- und Exklusiv-ODER-Operationen bis hin zu anderen Arten von prozentsatzbasierten Operationen kombiniert (So kann beispielsweise die GPU 70% der Bits x, y aus dem Frame-Puffer 204 mittels „ODER" mit 30% der Bits w, z aus dem Overlay-Puffer 205 kombinieren, was manchmal als „Alpha Blending" bezeichnet wird). Derartige Karten stellen diese Bitmapoperationen oftmals bereit, um ein Gebiet des VRAM 203 mit einem weiteren Gebiet des VRAM 203 (oder einem bezeichneten Speicher an anderer Stelle) zu Code neben der GPU zu kombinieren, was man dann als Rasteroperationen (raster operatons) bezeichnet.
Während die Daten in einem Gebiet des VRAM 203 gespeichert werden, das für Systemniveaucode (so beispielsweise für Software- und Hardwarevideotreiber und anderen Code, bei dem bekannt ist, wie er direkt mit der Videokarte kommuniziert, so beispielsweise bei Direct-X und DirectDraw) zugänglich ist, was typischerweise dann der Fall ist, wenn die Daten auf der Anzeigevorrichtung 220 auftreten, sind die Daten mittels Hacking seitens böswilliger Programme angreifbar. 3 ist ein Beispielsblockdiagramm, in dem gezeigt ist, wie das Hacking einer Anzeige erfolgt. Gemäß 3 hält der Betriebssystemspeicher (RAM) 301, wie anhand 2 beschrieben worden ist, diejenige Bitmap, die die Desktopfläche darstellt. An diesem Punkt kann eine Anwendung 320 nach Art eines Trojanischen Pferdes auf eine Kopie der Desktopfläche zugreifen (vorausgesetzt, sie kann eine Lokalisierung der Desktopfläche in dem VRAM vornehmen) und diese Kopie durch das Netzwerk oder über einen anderen Datenaustauschweg an andere Computer, so beispielsweise an den Hackercomputer 321, übertragen (Die Anwendung 320 wird als „Trojanisches Pferd" bezeichnet, da sie üblicherweise auf unbefugte und nicht erfassbare Weise in das Clientcomputersystemen gelangt ist). Eine Technik zur Vermeidung eines derartigen unbefugten Zugriffs besteht für das Betriebssystem darin, die Bitmap in verschleierter Form zu speichern und die Bitmap erst dann zur entschleiern, wenn sie an die Videokarte zum Zwecke der Speicherung in dem VRAM 302 übersandt wird. Der Begriff „entschleiern" („de-obfuscate" oder „un-obfuscate") wird zur Bezeichnung desjenigen Prozesses verwendet, der die Umkehrung des Prozesses der Verschleierung von Daten darstellt. So ist beispielsweise die Entschlüsselung verschlüsselter Daten ein Entschleierungsprozess, da hier eine Exklusiv-ODER-Operation mit einer Maske für Daten zum Einsatz kommt, die durch die Anwendung einer Exklusiv-ODER-Operation auf dieselbe Maske verschleiert worden sind.
Sobald die Daten in dem VRAM 302 gespeichert sind, sind die Daten gegenüber einem böswilligen Kopieren oder Betrachten seitens eines unbefugten Clients, so beispielsweise seitens einer böswilligen Anwendung 332, die eine Bibliothek, so beispielsweise Direct-X, verwendet, um direkt mit der Videokarte zu kommunizieren, anfällig. Man kann die Daten so lange hacken, wie für die Videokarte eine Speicherung der gültigen Daten in dem VRAM notwendig ist, um die GPU in die Lage zu versetzen, die Daten auf die Anzeigevorrichtung 303 zu projizieren. Ein sicherheitserhöhter Anzeigetreiber wird durch die Verfahren und Systeme der vorliegenden Erfindung bereitgestellt, um diese Art von Hacken auf unteren Niveaus in dem System zu unterbinden, das heißt, der sicherheitserhöhte Treiber unterstützt Techniken, die vorbezeichnete Daten sichern, die temporär im Zusammenhang mit der Videokarte und Anzeigemechanismen gespeichert sind.
4 ist ein Beispielsblockdiagramm für allgemeine Techniken, die von einem als Beispiel angegebenen sicherheitserhöhten Anzeigetreiber eingesetzt werden, um einen unbefugten Zugriff auf in einem Frame-Puffer gespeicherte Daten zu unterbinden. Das Diagramm zeigt dieselben Komponenten wie in 3 sowie den versuchten Hacking-Mechanismus, fügt jedoch eine zusätzliche Komponente hinzu, nämlich den sicherheitserhöhten Anzeigetreiber (SEDD). Der SEDD wirkt derart, dass er Verschleierungstechniken auf Daten anwendet, die in vorbezeichneten Gebieten des Frame-Puffers in dem VRAM 402 (und möglicherweise in dem gesamten Frame-Puffer) gespeichert sind, sodass auch für den Fall einer unbefugtem Anwendung, was beispielsweise dann auftritt, wenn eine böswillige Anwendung 422 versucht, Daten aus dem Frame-Puffer 402 herauszukopieren, die Daten ungültige Daten sind, da sie seitens des SEDD verschleiert worden sind. Da der SEDD (einen oder mehrere) Abschnitte des Frame-Puffers 402 verschleiert, um die gültigen (nicht verschleierten) Daten effektiv anzuzeigen, bedarf der SEDD 404 einer temporären Entschleierung der Daten, sodass die GPU gültige Daten zu demjenigen Zeitpunkt herauskopiert, zu dem die GPU die Daten benötigt, die zum Zwecke einer korrekten Anzeige auf der Anzeigevorrichtung 403 gültig sein müssen. Im Allgemeinen wirkt der SEDD 404 als „Koordinierer"-Prozess für den Inhalt des Frame-Puffers derart, dass er, wenn der Frame-Puffer gültige Daten und ungültige Daten hält, steuert, wo die gültigen beziehungsweise ungültigen Dateien in dem Frame-Puffer lokalisiert sind und wo die gültigen beziehungsweise ungültigen Daten zum Zwecke der Verwendung bei der Belegung von Gebieten des Frame-Puffers gespeichert werden. Der SEDD kann eine Vielzahl von Mechanismen rur Verschleierung und Entschleierung von Daten enthalten, darunter diejenigen, die nachstehend anhand 6 bis 9 beschrieben werden.
Bei einer Alternative unterstützt der SEDD die Fähigkeit einer Anwendung (oder eines anderen Codes), einen Bereich in der Anzeigevorrichtung als sicheren Bereich" zu definieren. In Abhängigkeit vom Sicherheitsniveau, das in dem speziellen System implementiert ist, ist der SEDD in der Lage, jenes Sicherheitsniveau für den sicheren Bereich zu gewährleisten. Ist beispielsweise das höchste Sicherheitsniveau gefordert, so stellt der SEDD sicher, dass kein unbefugter Prozess die gültigen Daten aus demselben Frame-Puffer betrachten oder abfangen kann, wenn diese in dem sicheren Gebiet ange zeigt werden. Bei jenem Szenario kann der Anwender die Daten auf dem Anzeigeschirm sehen, wobei der sicherere Bereich sämtlichem Code (außer den Koordinierer- und den Treiberprozessen) als verschleiert erscheint.
5 ist ein Beispielsblockdiagramm eines vorgezeichneten sicheren Abschnittes des Videoanzeigespeichers (VRAM), wie er von einem als Beispiel angegebenen sicherheitserhöhten Anzeigetreiber bereitgestellt wird. Der VRAM 506 wird in Entsprechung zu dem Abschnitt des Frame-Puffers (in diesem Fall des gesamten Frame-Puffers) gezeigt, der an der Anzeigevorrichtung 501 angezeigt ist. Der Frame-Puffer 507 ist in diesem Beispiel als Gebiet mit 1024 mal 768 Pixel auf der Anzeigevorrichtung 501 gezeigt. Auf der Anzeigevorrichtung 501 ist das ursprüngliche Desktopanzeigegebiet 502 (betriebssystemgesteuerte Anwenderschnittstelle) in Verbindung mit zwei vorbezeichneten sicheren Bereichen 503 und 504 gezeigt. In den entsprechenden Positionen in dem Frame-Puffer 507 des VRAM ist der ursprüngliche Desktopabschnitt 510 in Verbindung mit sicheren Abschnitten des Frame-Puffers 511 und 512 gezeigt. Anderem Code erscheinen die sicheren Abschnitte 511 und 512 als verschleiert (siehe Markierung mittels Kreuzschraffur). Andere Speicherplätze sind ebenfalls in dem VRAM 506 resident, so beispielsweise sichere Treibergebiete 508 und ein Overlay-Puffer 509. Sichere Treibergebiete 508 speichern verschiedene Puffer, die von dem SEDD verwendet werden und nicht von einem Standardbetriebssystem und einer Programmeinrichtung zugewiesen sind (so genannte „malloc"-Funktion), jedoch explizit von der Videokarte angefordert werden, damit der Zugriff seitens der SEDD besser gesteuert werden kann. Insbeson dere sind Puffer zum Halten gültiger Daten (Puffer für gültige Daten, valid data buffer VDB), verschleierter oder maskierter gültiger Daten (Puffer für sichere Daten, secure data buffer SDB) und ein Masken-Puffer (mask buffer MB) als in dem anderen VRAM 508 resident gezeigt.
Sobald ein sicherer Bereich oder mehrere hiervon definiert sind, wird der Inhalt des Frame-Puffers (frame buffer FB) auf geeignete Weise von dem SEDD koordiniert. Im Wesentlichen stellt der SEDD sicher, dass die Inhalte des sicheren Abschnittes des FB entsprechend dem sicheren Bereich auf der Anzeige gültige Daten enthalten, wenn die GPU diese lesen muss (oder die GPU die gültigen Daten über eine andere Einrichtung erhält), wohingegen zu allen anderen Zeitpunkten (in der Theorie wie in der Praxis) die Inhalte des sicheren Abschnittes verschleierte Daten enthalten. Die verschiedenen die Verschleierung und Entschleierung betreffenden Vorgehenseisen, die in Verbindung mit dem SEDD verwendet werden, werden nachstehend anhand 6 bis 9 beschrie ben. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich unmittelbar, dass weitere Änderungen und Abwandlungen bei diesen Vorgehensweisen vorgenommen werden können und dass auch in Zukunft entwickelte Vorgehensweisen im Zusammenhang mit dem SEDD einsetzbar sein sollen, weshalb auch diese als Teil der Erfindung betrachtet werden, genauso wie diejenigen Vorgehensweisen, die nachstehend als Beispiele angegeben sind. Zudem erschließt sich einem Fachmann auf dem einschlägigen Gebiet unmittelbar, dass die jeweils angegebenen "Fälle" zum Zwecke einer einfacheren Beschreibung erdacht sind und einer praxistauglichen Implementierung oder Funktionalitätsteilung durchaus nicht ähneln müssen.
Die erste Verschleierung beziehungsweise Entschleierung betreffende Vorgehensweise wird als _"Herauskopieren" („copy out") bezeichnet, da – kurz gesagt – gültige Daten seitens des SEDD zum Zwecke der Projektion auf die Anzeigevorrichtung zur „Herauskopier"-Zeit bereitgestellt werden, wenn die GPU den sicheren Abschnitt des Frame-Puffers in den entsprechenden sicheren Bereich auf der Anzeige kopiert. 6 ist ein Beispielsblockdiagramm für Verschleierungstechniken, die in Verbindung mit Verschleierungstechniken vom „copy out"-Typ zum Einsatz kommen. Entsprechend dieser „copy out"-Vorgehensweise sind die Daten in dem sicheren Abschnitt ungültig, weshalb die komplizierten Koordinierungstechniken, die gültige Daten zu kritischen Zeitpunkten in den Frame-Puffer einfügen und ungültige Daten zu anderen Zeitpunkten wiederherstellen, nicht zwangsweise benötigt werden (Diese komplizierten Koordinierungstechniken werden nachstehend anhand 10 bis 17 erläutert). Insbesondere werden gültige Daten an die Anzeigevorrichtung weitergereicht. Gleichwohl müssen diese nicht direkt aus dem Frame-Puffer (FB) herauskopiert werden. Vorzugsweise wird anstelle dessen die residente Technik, die von der Videokarte (GPU) zur Kombinierung des Overlay-Puffers mit dem Frame-Puffer vor der Projektion verwendet wird, verwendet, um die verschleierten Daten in dem Frame-Puffer mit den Daten in dem Overlay-Puffer zu kombinieren.
Es sind in diesem Zusammenhang zwei Fälle zu betrachten. Im ersten Fall, Fall 1, enthält der Frame-Puffer 601 ungültige Daten in dem sicheren Abschnitt 605, während gültige Daten in einem weiteren Puffer 602 gespeichert sind. Andere Daten (die als gültige Daten gezeigt sind) sind in denjenigen Gebieten des Frame-Puffers gespeichert, die nicht als sichere Abschnitte bezeichnet sind. Der SEDD bedient sich der gültigen Daten in dem Puffer 602, um die Inhalte des sicheren Abschnittes 605 zu überschreiben, wenn die FB-Daten in die Anzeigevorrichtung 603 herauskopiert werden. Der Puffer 602 ist ebenfalls der Overlay-Puffer, und zwar in Systemen, die eine direkte Rasteroperationskombination der Inhalte des Overlay-Puffers und des Frame-Puffers unterstützen. Darüber hinaus kann der Overlay-Puffer eine verschlüsselte Version der gültigen Daten (beispielsweise mit Rauschen, das in dem sicheren Abschnitt 605 gespeichert ist) enthalten. In letzterem Fall ist ein Entschlüsselungsschlüssel an irgendeiner Behelfsstelle gespeichert. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass trotz der Festlegung auf den Overlay-Puffer (für videokarten- und systemgestützte Mechanismen) andere Puffer, so beispielsweise Puffer für gültige Daten (valid data buffer VDB) oder Puffer für gesicherte Daten (secured data buffer SDB), die an anderer Stelle in dem VRAM gespeichert sind, in Kombination mit Rasteroperationen verwendet werden können. Im zweiten Fall, Fall 2, sind die ungültigen Daten, die in dem sicheren Abschnitt 606 gespeichert sind, eine verschlüsselte oder maskierte Version der gültigen Daten, wobei ein Verschlüsselungsschlüssel oder eine Maske, die zur Demaskierung der maskierten Version der gültigen Daten verwendet wird, in einem weiteren Puffer 604 gespeichert ist. Der Schlüssel beziehungsweise die Maske, der beziehungsweise die in dem Puffer 604 gespeichert sind, werden zum Erzeugen gültiger Daten beim Herauskopieren entweder durch Entschlüsseln der Daten gemäß Speicherung in dem sicheren Abschnitt 606 oder durch Kombinieren der Daten gemäß Speicherung in dem sicheren Abschnitt 606 durch eine Rasteroperation (raster operation ROP) und der Maske gemäß Speicherung in dem Puffer 604 verwendet. Die primäre Unterscheidung zwischen dem ersten und dem zweiten Fall liegt darin, ob die in dem anderen Puffer (602 oder 604) gespeicherten Daten gültige Daten oder andere Daten (Schlüssel oder Masken) sind. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass das Wort „Maske" bisweilen austauschbar mit dem Begriff „Schlüssel" verwendet wird und dass im Sinne der vorliegenden Beschreibung die beiden Begriffe auch tatsächlich austauschbar sind.
7 ist ein Beispielsblockdiagramm für abgewandelte Entschleierungstechniken vom _"copy out"-Typ. Diese Technik ist in Kombination mit den „copy out"-Techniken von 6 von Nutzen, um einen sicheren Abschnitt des Frame-Puffers teilweise zu verschleiern. Insbesondere ist in 7 ein VRAM 700 mit einem sicheren Abschnitt gezeigt (der als anzeigebereiter „Frame" bezeichnet wird). Anstelle der in 6 gezeigten Verschleierung des gesamten sicheren Abschnittes wird eine Technik zur Unterteilung des sicheren Abschnittes in beispielsweise drei Unterabschnitte und zur Behandlung eines der Unterabschnitte als verschleiertes Gebiet, das durch gültige Daten überschrieben oder zur Erzeugung gültiger Daten (Fall 1 und Fall 2 in 6) verwendet wird, beschrieben. Bei dem gezeigten Beispiel werden von dem Betriebssystem stammende gültige Daten (der anzuzeigende Frame), die an die Videokarte (über den SEDD) gesendet werden, in drei Unterteile unterteilt, bevor sie in dem VRAM gespeichert werden. Der erste Unterteil 701 gültiger Daten wird in den ersten Unterabschnitt 707 des Frame-Puffers geladen; der mittlere Unterteil 705 gültiger Daten wird in dem Overlay-Puffer 702 gespeichert; und der letzte Unterteil 706 wird als gültige Daten in dem dritten Unterteil 709 des Frame-Puffers gespeichert. Verschleierte Daten (eines beliebigen gewünschten Inhaltes oder Formates oder aus einer beliebigen Quelle) werden in dem mittleren Unterteil 708 des Frame-Puffers gespeichert. Der untere Teil von 7 zeigt, wie eine GPU eine Kombination aus Overlay-Puffer und den Abschnitten des Frame-Puffers zur Erzeugung gültiger Daten zum Zwecke der Projektion derselben auf die Anzeigevorrichtung einsetzen würde.
Die zweite Vorgehensweise bei Verschleierung beziehungsweise Entschleierung wird als „Ersetzen und Wiederherstellen" („replace and restore") bezeichnet, da – kurz gesagt – der SEDD gültige Daten durch Ersetzen der gültigen Daten gemäß Speicherung in dem sicheren Abschnitt des Frame-Puffers durch gültige Daten genau vor der Projektion (oder während der Projektion) auf die Anzeigevorrichtung – wenn die GPU den sicheren Abschnitt des FB in den entsprechenden sicheren Bereich auf der Anzeige kopiert – und verschleierte Daten durch Wiederherstellen der ungültigen Daten nach (oder während) der Projektion des sicheren Abschnittes des FB durch die TPU bereitstellt (Der genaue Zeitpunkt der Entschleierung und Neuverschleierung hängt davon ab, ob die Daten pixelweise, zeilenabtastungsweise oder in Blockoperationen abgearbeitet werden). 8 ist ein Beispielsblockdiagramm für Verschleierungstechniken, die in Verbindung mit „replace and restore"-Entschleierungstechniken zum Einsatz kommen. Gemäß 8 enthält der Frame-Puffer 801 (ursprünglich) verschleierte Daten in dem sicheren Abschnitt 802 des FB. Andere Daten (die als gültige Daten gezeigt sind) sind in den Gebieten des Frame-Puffers gespeichert, die nicht als sichere Abschnitte bezeichnet sind. Erneut sind zwei Fälle zu betrachten, die sich dahingehend unterscheiden, ob gültige Daten, die für den sicheren Bereich des Frame-Puffers bestimmt sind, als gültige Daten (beispielsweise in einem Puffer für gültige Daten VDB) oder als verschlüsselte oder maskierte Daten (beispielsweise in einem Puffer für sichere Daten SDB) gespeichert sind, deren Entschlüsselung oder Demaskierung vor dem Einkopieren der „gültigen" Daten in den Frame-Puffer erfolgt.
Insbesondere werden in Fall 3 gültige Daten in einem Puffer für gültige Daten (VDB) 803 gespeichert, während verschleierte Daten (oder beispielsweise Daten, eine Maske, die zur Verschleierung der Inhalte des sicheren Abschnittes des FB verwendet wird) in ei nem Maskenpuffer (MB) 804 gespeichert werden. Man beachte, dass diese Puffer überall dort gespeichert sein können, wo dies in dem System möglich ist und wo Sicherheitsbedürfnissen entsprochen wird. Der SEDD kopiert zu einem geeigneten Zeitpunkt vor dem Zeitpunkt, zu dem die Inhalte des sicheren Abschnittes zum Zwecke der Projektion gültig sein müssen, die gültigen Daten aus dem VDB 803 ein. Nachdem die gültigen Daten zum Zwecke der Projektion auf die Anzeige (oder bisweilen auch zwischendurch) abgetastet und herauskopiert worden sind, nimmt der SEDD ein Einkopieren der gültigen Daten aus dem Maskenpuffer 804 vor, um den sicheren Abschnitt des FB 802 neu zu verschleiern. Man beachte, dass ungeachtet der Darstellung als von dem Maskenpuffer 804 her kommend sich einem Fachmann auf dem einschlägigen Gebiet unmittelbar erschließt, dass die ungültigen Daten auf mehrere Weisen erzeugt werden können, darunter Systemoperationen, Rechneranweisungen oder andere Mittel, die eine Gruppe von Bits setzen (altes schwarz) oder die Bits löschen (alles weiß). Wie in der Figur gezeigt ist, kann, wenn die verschleierten Daten durch Maskieren von Versionen der gültigen Daten erzeugt werden sollen, eine Maske in dem MB 804 gespeichert und auf die bereits einkopierten gültigen Daten gemäß Speicherung in dem sicheren Abschnitt 802 unter Verwendung von ROPs zur Neuerzeugung der neuverschleierten Daten angewendet werden. Alternativ können, wenn die verschleierten Daten ungültige Daten sind, so beispielsweise ein Logo, Werbung oder zufällige Bitmuster, die ungültigen Daten aus dem Maskenpuffer 802 in den Frame-Puffer einkopiert werden.
In Fall 4 werden gültige Daten lediglich in einer sichereren Form (so beispielsweise als verschlüsselte oder maskierte Daten) in dem Puffer für sichere Daten (VDB) 805 gespeichert. Dieselben verschlüsselten oder maskierten Daten (da es sich um „verschleierte" Daten handelt) werden als ungültige Daten verwendet, die in den sicheren Bereich des FB einkopiert werden, wenn verschleierte Daten die gültigen Daten in dem Frame-Puffer ersetzen sollen. Eine Maske oder ein Schlüssel ist in dem Maskenpuffer (MB) 804 gespeichert, damit eine Verwendung durch den SEDD zum Zwecke der Entschleierung oder Demaskierung der in dem SDB 805 gespeicherten sicheren Daten erfolgen kann. Daher erzeugt der SEDD zu einem geeigneten Zeitpunkt vor dem Zeitpunkt, zu dem die Inhalte des sicheren Abschnittes 802 zum Zwecke der Projektion gültig sein müssen, gültige Daten und kopiert diese aus dem SDB 805 durch Anwenden eines Schlüssels (Entschlüsseln oder Demaskieren) oder einer Maske aus dem MB 804 auf die in dem SDB 805 gespeicherten sicheren Daten ein und kopiert das Ergebnis (gültige Daten) in den sicheren Bereich des FB 802 ein. Auf ähnliche Weise kopiert der SEDD, nachdem die in dem sicheren Abschnitt 802 gespeicherten gültigen Daten abgetastet und zum Zwecke der Projektion (oder entsprechend) herauskopiert worden sind, die ungültigen Daten (die verschlüsselte oder maskierte Form der gültigen Daten) aus dem SDB 805 ein, um den sicheren Abschnitt des FB 802 neu zu verschleiern.
Die dritte das Verschleiern beziehungsweise Entschleiern betreffende Vorgehensweise wird als „direkte Ersetzung° („in place replacement") bezeichnet, da hier- kurz gesagt – der SEDD die gültigen Daten in dem sicheren Abschnitt des Frame-Puffers bereitstellt, indem die gültigen Daten direkt (in-place) genau vor der Projektion auf die Anzeigevorrichtung manipuliert werden – wenn die GPU den sicheren Abschnitt des FB in den entsprechenden sicheren Bereich auf der Anzeige kopiert – und anschließend die ungültigen Daten mittels Manipulation (toggling) der gültigen Daten direkt zur Neuerzeugung der ungültigen Daten bereitstellt. 9 ist ein Beispielsblockdiagramm von Verschleierungstechniken, die im Zusammenhang mit Entschleierungstechniken vom „inplace replacement"-Typ zum Einsatz kommen. Gemäß 9 enthält der Frame-Puffer 901 (ursprünglich) verschleierte Daten in dem sicheren Abschnitt 902 des FB. Die verschleierten Daten sind eine sichere Version der gültigen Daten, so beispielsweise eine verschleierte oder maskierte Form der gültigen Daten. Daher wendet der SEDD zur Erzeugung gültiger Daten aus den verschleierten Daten (zum Zwecke der Entschleierung der Daten), die in dem sicheren Abschnitt des FB 902 gespeichert sind, einen geeigneten Schlüssel oder eine geeignete Maske, der beziehungsweise die in dem Maskenpuffer (MB) 904 gespeichert sind, an, um die Daten zu entschlüsseln beziehungsweise zu demaskieren. Genau wie bei der _"replace and restore"-Vorgehensweise, die im Zusammenhang mit 8 beschrieben ist, nimmt der SEDD die Entschleierung und Neuverschleierung zu geeigneten Zeitpunkten vor, um sicherzustellen, dass die Projektion der gültigen Daten möglich wird und dass kein anderer Port Zugriff auf die gültigen Daten erlangt, die dem sicheren Abschnitt 802 entsprechen.
Wie vorstehend anhand 8 und 9 beschrieben ist, muss der SEDD die Entschleierung und die Neuverschleierung der in einem sicheren Abschnitt des Frame-Puffers gespeicherten Daten koordinieren, um die gültigen Daten zum Zwecke der Verwendung bei der Projektion zu koordinieren. 10 ist eine Beispielsdarstellung der Koordinierung der Verschleierung und Entschleierung der Inhalte des Frame-Puffers seitens eines als Beispiel angegebenen sicherheitserhöhten Anzeigetreibers. Der in 10 gezeigte Graph bezeichnet die Zeit, die eine Anzeigekanone benötigt, um Daten (üblicherweise auf Basis einer zeilenweise erfolgenden Abtastung) aus dem Frame-Puffer zum Zwecke der Projektion auf die Anzeigevorrichtung abzutasten. Ein VB-Signal (vertical blank VB) wird von der Kanone abgegeben, wenn sie das Ende beim Abtasten der Anzeige erreicht, und zwar genau vor ihrer Rückkehr zum Abtasten der ersten Zeile auf dem Anzeigeschirm. Die Zeit, die die Kanone benötigt, um von der unteren rechten Ecke zum Anfang der nächsten Abtastung in der oberen linken Ecke zu laufen, wird als VB-Intervall bezeichnet (Früher „blinkte" der Schirm hierbei, wobei nunmehr durch weiterentwickelte Techniken diese Zeit kaum mehr erfasst werden kann). Diese Zeitspanne ist für ein bestimmtes System berechenbar, dessen Kanone mit einer bestimmten Rate (üblicherweise in Hz angegeben) arbeitet.
Man beachte, dass der (0,0)-Punkt schlicht der Ursprung relativ zum Schirm (die obere linke Ecke) ist. Die tatsächliche Position des Anzeigeschirmes, die von dem Betriebssystem und anderen Codes verwendet wird, kann in der Praxis kleiner als die Gesamtfläche auf dem Schirm sein. Der relative Ursprungspunkt in dem Frame-Puffer, der als Datenquelle für das zur Anzeige Abgetastete dient, wird auch mit (0,0) beschrieben. Es sollte gleichwohl einsichtig sein, dass dieser Punkt nicht notwendigerweise der erste in dem Frame-Puffer verfügbare Adressort ist.
Die Kanone projiziert Abtastlinien (läuft) mit einer bestimmten Rate. Der SEDD muss nun bestimmen, wann die Kanone den Punkt A erreicht. Der Punkt A stellt die Zeit (relativ zu dem VB-Signalende am Ursprung (0,0)) dar, zu der die Kanone den Anfang eines bezeichneten sicheren Bereiches auf der Anzeige erreicht, der einem bezeichneten sicheren Abschnitt des Frame-Puffers (Speicher) entspricht. An dem Punkt A müssen die Daten in dem sicheren Abschnitt des Frame-Puffers gültige Daten sein. Der Punkt B stellt die relative Zeit dar, zu der die Kanone das Abtastende des bezeichneten sicheren Bereiches auf der Anzeige erreicht, das dem Ende des sicheren Abschnittes des Frame-Puffers entspricht. Bis zu dem Punkt B müssen die Daten in dem sicheren Bereich des Frame-Puffers verschleierte Daten sein, sodass andere Codes (Code, der nicht ein beliebiger SEDD-Code ist, der zur Koordinierung des Inhalts des Frame-Puffers verwendet wird) die gültigen Daten nicht betrachten oder abfangen können. In der Praxis muss aufgrund von Systemlatenzen, darunter das VB-Intervall zum Start des Abtastens vom Anzeigeursprung aus, die Zeit zum Laden des Codes und zum Abrufen der Prozesse, Threads und dergleichen, sowie bedingt durch jede Zeit, die zur Durchführung der Entschleierung (darunter in einigen Fällen zur Entschlüsselung) benötigt wird, der SEDD den Prozess der Entschleierung der in dem bezeichneten sicheren Abschnitt des Frame-Puffers gespeicherten Dateien zu einer beliebigen Zeit vor der Zeit, zu der diese an dem Punkt A benötigt werden, starten. Der Punkt C stellt diese Zeit Δ dar. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass die Werte der Punkte A, B und C hochgradig systemabhängig sind. Bestimmt werden können die Punkte A und B durch Pollen für das VB-Signal oder für den Fall eines ereignisgesteuerten Systems, das VB-Ereignisse unterstützt, durch Empfangen eines VB-Ereignisses und Berechnen (unter Berücksichtigung der Laufrate der Kanone) der Zeit, die benötigt wird, um den Punkt A und den Punkt B zu erreichen. Der Punkt C, die Zeit Δ, wird typischerweise empirisch bestimmt, und zwar auf Basis von Systemlatenzen und den jeweils benutzten speziellen Verschleierungs- und Entschleierungstechniken. Im Allgemeinen berechnet sich der Punkt C wie folgt.
Punkt A (in der Zeit) – Systemlatenzzeit – Verschleierungsprozesszeit (1) Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass vom Standpunkt der Koordinierung aus viele verschiedene Techniken zum Neuverschleiern der Daten bis zum Punkt B verwendet werden können. So kann der Neuverschleierungsprozess beispielsweise abtastlinienweise, pixelweise oder speicherblockweise erfolgen. Der Prozess kann dann der Kanone um ein gewisses Intervall nacheilen. Wie nachstehend im Zusammenhang mit 17 beschrieben ist, wird bei einem Ausführungsbeispiel die Neuverschleierung genau nach dem Abtasten des sicheren Bereiches zum Zwecke der Projektion auf die Anzeige vorgenommen.
Um zu verhindern, dass anderer Code auf die gültigen Daten zugreift, während diese in dem sicheren Abschnitt des Frame-Puffers befindlich sind, muss zudem ein bestimmter Prozess-/Thread-Sperrmechanismus eingesetzt werden, um in kritischen Intervallen anderen Code auszusperren. Bei dem nachstehend im Zusammenhang mit 12 bis 17 beschriebenen Beispiel wird ein von höchster Priorität seiender Echtzeitthread beschrieben, um die gültigen Daten einzukopieren und die Daten vor der Öffnungskontrolle zu verschleiern. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass andere Mechanismen verwendet werden können und dass das Niveau der Sicherheit, das durch das System bereitgestellt wird, danach bemessen wird, wie sperrsicher der Sperrmechanismus ist.
11 ist ein Beispielsblockdiagramm einer alternativen das Verschleiern beziehungsweise Entschleiern betreffenden Vorgehensweise, die zur Koordinierung der Zeit der Verschleierung und Entschleierung des gesamten Frame-Puffers oder eines Abschnittes hiervon verwendet werden kann. Den Frame-Puffer 1100 kann man sich als Abfolge von Gebieten, so beispielsweise 1101 bis 1104 vorstellen, die in einem bestimmten Zustand sind, wo sie verschleierte Daten und gültige Daten enthalten. Bewegt sich der SEDD durch den Frame-Puffer 1100, so läuft er derart durch die Gebiete in Dreiergruppen, dass zu einem beliebigen Zeitpunkt ein Gebiet 1103, das gültige Datum enthält, die für die Anzeige herauskopiert werden, ein Gebiet 1102 (genau vor 1103), das Daten enthält, die gerade entschleiert werden, sowie ein Gebiet 1104 (genau nach 1103), das Daten enthält, die gerade neuverschleiert werden, vorhanden ist. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass Prozess-/Thread-Koordinierungssperren immer als geeignet für das Gebiet durchgesetzt und aufgegeben werden können, in dem gültige Daten vorhanden sind, so beispielsweise bei 1103, um eine größere Sicherheit zu gewährleisten. Alternativ kann aufgrund der Tatsache, dass sich die Variation von Parametern, so beispielsweise des Ortes und der Größe des Gebietes, ändern kann, der Zustand des Frame-Puffers für externen Code in ausreichendem Umfang unvorhersagbar sein.
12 bis 17 beschreiben ein Beispiel dafür, wie Abschnitte eines SEDD die Koordinierung des Inhalts in dem Frame-Puffer bewerkstelligen, um sichere Bereiche auf einer Anzeigevorrichtung zu implementieren. Es wird als Beispiel das Koordinierungsszenario gemäß Beschreibung im Zusammenhang mit 10 verwendet. In der nachfolgenden Beschreibung werden zudem zahlreiche spezifische Details angegeben, so beispielsweise Datenformate, Codesequenzen und dergleichen mehr, um ein tiefgreifendes Verständnis dieser Techniken zu ermöglichen. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich gleichwohl, dass die beschriebenen Beispiele auch ohne die genannten beschriebenen spezifischen Details in der Praxis verwirklicht werden können, oder mit anderen spezifischen Details, so beispielsweise betreffend Änderungen hinsichtlich der Reihenfolge des Codeablaufs, der Art, wie der Codeablauf funktionell organisiert ist, und dergleichen mehr. Darüber hinaus können ungeachtet der Tatsache, dass bestimmte Parameter als Eingabe- und Ausgabeparameter beschrieben sind, weniger oder mehr oder andere Parameter eingeschlossen werden, was von der spezifischen Implementierung abhängt.
Kurz gesagt wird bei einer typischen Anwendung oder auf dem Niveau des Betriebssystems eine Anfrage getätigt, um einen sicheren Bereich auf der Anzeigevorrichtung zu erzeugen, oder um Daten in jenem Bereich sicherer zu machen. Diese Anfrage wird von dem SEDD verarbeitet, der den Inhalt des Frame-Puffers entsprechend dem Koordinie rungsplan (beispielsweise 10 und 11) in der Praxis sowie die verwendeten Techniken betreffend das Verschleiern und Entschleiern koordiniert.
12 ist ein Beispielsablaufdiagramm einer als Beispiel angegebenen Routine auf Anwenderniveau zur Anforderung einer Wandlung in einen sicheren Anzeigebereich. Die Anwendung (application API) (die auch als „CreateSecureDisplayRegion" beziehungsweise „Erzeuge sicheren Anzeigebereich") bezeichnet wird, nimmt als Eingabe einen gewünschten Ort und gibt die Angabe eines sicheren Gebietes auf der Videokarte (beispielsweise einen gültigen Datenpuffer) zum Speichern der gültigen Daten, einen Indikator des zugewiesenen sicheren FB-Ortes und einen Identifikator aus, der verwendet wird, um in diesem Fall einen sicheren Bereich zu identifizieren. Bei Schritt 1201 authentisiert die Anwendung den Anfrager typischerweise unter Verwendung von Standardtechniken aus dem Stand der Technik, so beispielsweise mittels digitaler Signaturen und dergleichen. Bei Schritt 1202 bestimmt die Anwendung, ob der angefragte sichere Bereich zur Verfügung steht, und geht, wenn dem so ist, zu Schritt 1204 über, wohingegen andernfalls ein Fehler ausgegeben wird. Bei einem Ausführungsbeispiel können sichere Bereiche nicht mit FB-Orten in einem anderen sicheren Bereich überlappen (interferieren), um die Integrität und Richtigkeit der angezeigten Daten sicherzustellen. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich gleichwohl, dass andere Implementierungen möglich sind. Bei Schritt 1203 weist die Anwendung den sicheren Bereich (durch Einstellen der verschiedenen Rückgabewerte für den Anfrager) zu. Der Schritt der Zuweisung kann anstatt dessen auch auf dem Niveau des Treibers (SEDD) vollzogen werden. Bei Schritt 1204 ruft die Anwendung den SEDD auf, den Prozess der Verschleierung in dem zugewiesenen Bereich zu starten, und springt zurück. Bei einem Ausführungsbeispiel wird der Treiber von einem _"ioctl"-Mechanismus für einen Standardvorrichtungstreiber aufgerufen, der die Treiber in die Lage versetzt, Standardeingabeparameter und spezielle Eingabeparameter einzustellen.
Sobald der Treiber aufgerufen ist, wird eine Anzahl von Schritten ausgeführt, die vom verwendeten Betriebssystem abhängen, und zwar insbesondere davon, welche Ereignisse (Signale) empfangen werden können und welche Sperrmechanismen für Aufgaben (Prozessor/Threads oder dergleichen) zur Verfügung stehen. 13 und 14 sind Beispiele für den ioctl-Eingabepunkt, der die Verschleierung auf Basis davon startet, ob das System eine VB-Ereignisregistrierung unterstützt beziehungsweise ob eine Polling-Technik (spin-lock) benutzt werden muss.
13 ist ein Beispielsablaufdiagramm für Schnittstellen bei einem als Beispiel angegebenen sicherheitserhöhten Anzeigetreiber zur Steuerung der Verschleierung eines sicheren Anzeigebereiches in einem echten multitasking- und hardwarebasierten sowie ereignisgesteuerten System. Zusammengefasst dargestellt bestimmt der Treibercode, ob die Projektionskanone zum Anfangen der Verschleierung in Reihenfolge sein muss, registriert ein VB-Ereignis an jenem Ort in dem Frame-Puffer und erzeugt einen Echtzeitthread zur Entschleierung und Neuverschleierung des gesamten Abschnittes, wenn das VB-Ereignis empfangen ist. Insbesondere bestimmt der Code bei Schritt 1301, ob der Treiber an dem Eingabepunkt entsprechend dem Prozess „Anfang der Verschleierung" aufgerufen worden ist, und geht, wenn dem so ist, zu Schritt 1302 über, wohingegen andernfalls zu Schritt 1307 übergegangen wird. Bei Schritt 1302 weist der Treibercode einen sicheren Abschnitt des Frame-Puffers entsprechend dem sicheren Bereich auf der Anzeige zu, falls dies nicht schon von der entsprechenden Anwendung erledigt worden ist. Bei Schritt 1303 bestimmt der Code den Ort (die Zeit) VB_event_start (VB-Ereignis_Anf.) in dem Frame-Puffer zum Starten des Entschleierungsprozesses und den Ort (die Zeit) VB_event_end (VB-Ereignis_End.) in dem Framepuffer zum Starten des Neuverschleierungsprozesses, das heißt, eine VB-Ereignisspezifikation, die dem Anfangsort des sicheren Abschnittes in dem Frame-Puffer gemäß Einstellung für Latenzen, Entschleierung und dergleichen (siehe Gleichung 1 oben) entspricht, und bestimmt eine VB-Ereignisspezifikation, die dem Ende entspricht. Ein Prozess zum Bestimmen der Variablen VB_event_start und VB_event_end (VB-Ereignis_Anf. und VB-Ereignis_End.) wird nachstehend anhand 16 beschrieben. Bei Schritt 1304 registriert der Treibercode ein VB-Ereignis zur Zeit VB_event_start und wartet anschließend auf eine Signalisierung dieses Ereignisses. Bei Schritten 1305 und 1306 ruft bei Signalisierung des VB-Ereignisses der Treibercode einen Echtzeitverschleierungssteuerungsthread auf. Nachdem der Thread rückspringt, wodurch die Steuerung der anderen Aufgaben aufgegeben wird, sodass auch diese die Anzeige beschreiben können (oder bis das VB-Ereignis eintritt), wartet der Treiber auf das nächste Signal oder ioctl. Der Echtzeitverschleierungssteuerungsthread wird unter Bezugnahme auf 17 beschrieben.
In Abhängigkeit von der speziellen Implementierung kann eine Anwendung (oder das Betriebssystem) explizit den Verschleierungsprozess stoppen (wodurch der sichere Bereich zerstört wird) oder einfach die dargebotenen Daten in dem bereits zugewiesenen sicheren Bereich ändern oder eine Kombination von beidem ausführen. Der ioctl-Eingabepunkt „Ende d. Verschleierung" ist eine Schnittstelle zum Anhalten des Verschleierungsprozesses in einem bestimmten sicheren Bereich. Bei Schritt 1307 signalisiert der Treibercode für den Fall, dass die empfangene Größe ioctl eine Nachfrage nach „Ende d. Verschleierung" feststellt, bei Schritt 1308, dass der Echtzeitthread (so tatsächlich einer läuft) endet (und den sicheren Bereich verschleiert). Wird eine eigene "Destroy SecureDispIayRegion"-Anwendung (Zerstören des sicheren Anzeigebereiches) (nicht gezeigt) zum Aufrufen des ioctl „Ende d. Verschleierung" verwendet, so sollte ein Löschen des VDB und anderer damit in Verbindung stehender Daten von jener Anwendung vorgenommen werden.
Ungeachtet der Tatsache, dass die Beispiele primär anhand der Implementierung eines Treibercodes für einen bezeichneten sicheren Bereich dargestellt sind, erschließt sich einem Fachmann auf dem einschlägigen Gebiet unmittelbar, dass diese Techniken auf mehrere Anfragen und mehrere sichere Bereiche unter Verwendung standardisierter Programmiertechniken erweitert werden können, so beispielsweise Nachschlagtabellen oder durch Aufrufen eines Echtzeitverschleierungssteuerungsthreads (RTOC-Thread) pro Anfrager, oder unter Verwendung ähnlicher Mechanismen. Werden mehrere sichere Bereiche unterstützt, so kann der Treibercode eine Registrierung für ein eigenes VB-Ereignis für jeden sicheren Bereich vornehmen und einen RTOC-Thread für jeden erzeugen, wohingegen er andernfalls eine Liste relevanter VB-Ereignisse an den RTOC sendet.
14 ist ein Beispielsablaufdiagramm für Schnittstellen in einem als Beispiel angegebenen sicherheitserhöhten Anzeigetreiber zur Steuerung einer Verschleierung eines sicheren Anzeigebereiches auf nichtereignisgesteuerte Weise in einer alternativen Betriebssystemumgebung. Dies bedeutet insgesamt, dass der Treibercode bestimmt, wo die Projektionskanone in Reihenfolge sein muss, um die Verschleierung zu beginnen, ein Spinlocking an dem VB-Signal plus dem berechneten Wert für VB_event_start vornimmt, um festzustellen, wann die Entschleierung des sicheren Bereiches des Frame-Puffers zu erfolgen hat, und den Echtzeitthread erzeugt (der gleiche Thread wie beim Lösungsansatz von 13), um den sicheren Abschnitt zu entschleiern und neu zu verschleiern. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass eine spentechnische Vorgehensweise mit feinerer Granularität ebenfalls eingesetzt werden kann. Insbesondere kann zunächst ein Nichtechtzeitthread erzeugt werden, um eine beliebige Verarbeitung der für die Entschleierung erforderlichen Daten durchzuführen, und zwar vor dem Kopieren der gültigen Daten in den Frame-Puffer. Anschließend wird ein Echtzeitthread lediglich zu dem Zweck erzeugt, das Einkopieren der gültigen Daten während des Neuverschleierungsprozesses vorzunehmen (mit anderen Worten, der Echtzeitthread wird in 10 nur zur Verarbeitung ungefähr ab dem Punkt A bis zu dem Punkt B verwendet).
Insbesondere bestimmt bei Schritt 1404 der Treibercode, ob der Treiber an dem Eingabepunkt entsprechend dem Prozess „Anfang d. Verschleierung" aufgerufen worden ist, und geht, wenn dem so ist, zu Schritt 1403 über, wohingegen er andernfalls zu Schritt 1404 übergeht. Bei Schritt 1402 weist der Treibercode einen sicheren Abschnitt des Frame-Puffers entsprechend dem sicheren Bereich auf der Anzeige zu, wenn dies nicht schon von der entsprechenden Anwendung durchgeführt worden ist. Bei Schritt 1403 ruft der Treibercode einen (nicht Echtzeit-)Zeit- und Synchronisierungsthread zur Emulierung der Ereignisverwaltung auf, um zu bestimmen, ob das VB-Signal der Größe VB_event_start entspricht. Anschließend ruft entweder der Zeit- und Synchronisierungsthread den Echtzeitverschleierungssteuerungsthread direkt auf, oder dies wird im Gefolge von Schritt 1401 (Vorgehensweise nicht gezeigt) erledigt. Der Treibercode wartet anschließend auf das nächste Signal oder ein ioctl-Ereignis. Bei Schritt 1404 signalisiert der Treibercode anschließend für den Fall, dass die empfangene Größe ioctl die Nachfrage nach einem „Ende d. Verschleierung" anzeigt, bei Schritt 1405 dem Echtzeitthread (wenn tatsächlich einer läuft) aufzuhören (und den sicheren Abschnitt zu verschleiern) (Wiederum gilt, dass für den Fall, dass eine eigene Anwendung (nicht gezeigt) verwendet wird, um die Größe ioctl „Ende d. Verschleierung" aufzurufen, ein Löschen des VDB oder anderer damit zusammenhängender Daten von jener Anwendung ausgeführt werden sollte).
15 ist ein Beispielsablaufdiagramm eines VB-Zeit- und Synchronisierungsthreads, der zur Steuerung der Frame-Pufferinhaltskoordinierung in einer alternativen Betriebssystemumgebung gemäß 14 verwendet wird. Dieser Thread wird ab Schritt 1403 von 14 aufgerufen. Wie dargelegt, besteht der primäre Zweck dieses Threads darin, zu simulieren, was sonst von einem Betriebssystem verfügbar wäre, das in der Lage ist, Hardwareereignisse zu simulieren, so beispielsweise eine spezifische Zeit beziehungsweise einen spezifischen Ort für das VB-Signal plus ein bestimmtes Δ (oder einen entsprechenden Frame-Pufferort). Bei Schritt 1501 bestimmt der Zeit- und Synchronisierungsthread (TS-Thread) den Ort beziehungsweise die Zeit VB_event_start in dem Frame-Puffer zum Beginnen des Entschleierungsprozesses und den Ort beziehungsweise die Zeit VB_event_end in dem Frame-Puffer zum Beginnen des Neuverschleierungsprozesses, das heißt eine (hier simulierte) VB-Ereignis-Spezifikation, die dem Anfangsort des sicheren Abschnittes in dem Frame-Puffer gemäß Einstellung für Latenzen, Entschleierung und dergleichen entspricht (siehe Gleichung 1 oben). Zudem wird eine VB-"Ereignis"-Spezifikation bestimmt, die dem Ende entspricht. Ein Prozess zum Bestimmen der beiden Größen VB_event_start und VB_event_end wird nachstehend unter Bezugnahme auf 16 beschrieben. Bei Schritt 1502 nimmt der TS-Thread ein Spinlocking (Pollen und Warten) an der bestimmten Größe VB_event_start vor, wobei er bei einem Treffer bei Schritt 1503 den Echtzeitverschleierungssteuerungsthread (RTOC-Thread) ausführt. Ein Spinlocking kann durch Pollen des VB-Signals und Einstellen eines Zeitgebers (oder mittels eines anderen gleichwertigen Mechanismus) derart erfolgen, dass dieser zu der Zeit VB + VB_event_start losgeht. Der Echtzeitverschleierungssteuerungsthread wird unter Bezugnahme auf 17 beschrieben. Nach dem Rücksprung des RTOC-Threads, wodurch die Steuerung an andere Aufgaben derart abgegeben wird, dass diese ebenfalls die Anzeige beschreiben können, beginnt der TS-Thread einen weiteren Spinlocking-Prozess bei Schritt 1502, um bezüglich der Zeit deR nächsten Größe VB_event_start zu pollen und zu warten. Werden mehrere sichere Bereiche unterstützt, so kann der TS-Thread ein eigenes VB-Ereignis für jeden sicheren Bereich simulieren. Zu einem bestimmten Punkt kann der TS-Thread ein Signal empfangen „aufzuhören" (siehe den zugehörigen Schritt 1504), wobei, wenn dies erfolgt, bei Schritt 1505 der TS-Thread dem RTOC-Thread signalisiert aufzuhören (und beliebige sichere Abschnitte des Frame-Puffers neu zu verschleiern).
16 ist ein Beispielsflussdiagramm für Code zur Bestimmung von Korrelationen zwischen VB und VRAM-Adresse gemäß Verwendung für die Steuerung der Frame-Pufferinhaltskoordinierung. Wie ausgeführt, ist die verwendete Technik systemabhängig, wobei die allgemeine Idee darin besteht zu bestimmen, zu welchem Zeitpunkt das VB-Signal auftritt (in der rechts unten liegenden Ecke der Anzeige, wie lange es anschließend dauert, bis man zu VB_event-start gelangt, dem Punkt, an dem die Entschleierung beginnen sollte (siehe Punkt A in 10) und wie lange es dauert, bis zu dem Punkt VB_event_end zu gelangen, dem Punkt, an dem die Neuverschleierung beginnen sollte) (Der Neuverschleierungspunkt kann in Abhängigkeit von der verwendeten Technik gemäß vorheriger Beschreibung (pixelweise, abtastlinienweise oder blockweise) früher auftreten). Bei Schritt 1601 bestimmt der Code die Zeit, bis zu der die Entschleierung für einen bestimmten sicheren Bereich (Punkt A in 10) vollzogen sein muss. Diese Zeit kann beispielsweise unter Kenntnis der Abtastrate (beispielsweise 80 MHz) sowie der Anzahl der Abtastlinien zur Bestimmung der Rate pro Abtastlinie und der anschließenden Berechnung der Abtastlinienposition bestimmt werden, die dem Start des sicheren Bereiches des Frame-Puffers entspricht. Bei Schritt 1602 geht der Code für den Fall, dass eine Entschlüsselung (oder eine Demaskierung) bei den Entschleierungstechniken verwendet wird, zu Schritt 1603 über, um die Größe VB_event_Start zu berechnen, wobei eine zusätzliche Zeit, die zur Entschlüsselung (oder Demaskierung) notwendig ist, eingerechnet ist. Anderweitig wird anschließend bei Schritt 1604 die Größe VB_event_start mit Systemlatenzen und dergleichen berechnet. Wie ausgeführt, müssen diese Werte empirisch bestimmt werden, und zwar vorzugsweise während eines Systeminitialisierungsprozesses. Bei Schritt 1605 bestimmt der Code die Größe VB_event_end durch Berechnen der Zeitlänge, die zum Abtasten bis zum Ende des sicheren Bereiches und zum Hinzufügen desselben zu VB_event_start nötig ist, oder einfach durch Verfolgen hiervon als Zeitdifferenz.
17 ist ein Beispielsablaufdiagramm eines Echtzeitverschleierungssteuerungsthreads, der von dem sicherheitserhöhten Anzeigetreiber verwendet wird, um gültige und ungültige Daten an den Frame-Puffer zu leiten. Der Echtzeitverschleierungssteuerungsthread (RTOC-Thread), wird von dem Anzeigetreiber verwendet, um andere Prozesse/Aufgaben auszusperren, während der SEDD die gültigen Daten anzeigen muss. Wie ausgeführt, können andere gleichwertige Aussperrprozesse oder Ressourcen für Sperrmechanismen (der Frame-Puffer ist eine solche Ressource) ebenfalls verwendet werden, was vom Betriebssystem und der Hardwareumgebung abhängt. Bei diesem Ausführungsbeispiel ist beabsichtigt, dass der RTOC-Thread eine von höchster Priorität seiende Aufgabe in dem System an jenem Punkt ist, sodass sämtliche anderen Prozesse beziehungsweise Aufgaben effektiv ausgesperrt werden können. Anschließend arbeitet der RTOC-Thread vorzugsweise sehr schnell und hebt die Steuerung auf, sobald die gültigen Daten abgetastet und der sichere Bereich neu verschleiert ist.
Bei Schritt 1701 bestimmt der RTOC-Thread, ob die Entschlüsselung beziehungsweise Demaskierung von Nöten ist, und geht, wenn dem so ist, zu Schritt 1702 über, wohingegen er andernfalls zu Schritt 1703 übergeht. Bei Schritt 1702 erzeugt der RTOC-Thread selbstverständlich in Abhängigkeit von der von dem SEDD verwendeten Verschleierungstechnik gültige Daten durch Entschlüsselung oder Demaskierung und setzt einen Indikator auf diesen Wert (pValdidData, p-gültige_Daten). Bei Schritt 1703 verwendet der RTOC-Thread aufgrund der Tatsache, dass bereits gültige Daten zur Verfügung stehen, genau diejenigen gültigen Daten, die beispielsweise in dem VDB gespeichert sind. Bei Schritt 1704 kopiert der RTOC-Thread die bezeigten gültigen Daten in den sicheren Bereich des Frame-Puffers ein. Bei Schritt 1705 wartet der RTOC-Thread (wenn die Zeit nicht bereits verstrichen ist) bis VB_event_end und nimmt anschließend in Schritt 1706 eine Neuverschleierung des sicheren Abschnittes des Frame-Puffers durch eine beliebige Verschleierungstechnik vor (siehe beispielsweise 8 und 9). An einem bestimmten (nicht angegebenen) Punkt während der Verarbeitung des RTOC-Threads kann der Thread ein Signal zum Beenden der Verschleierung empfangen. Ist dem so, so führt der RTOC-Thread vorzugsweise Schritt 1706 aus, um sicherzustellen, dass der sichere Abschnitt des Frame-Puffers verschleierte Daten enthält.
Sichere Speicherung und Anzeige der Eingabe von einer Tastatur, einer Maus oder einer anderen Anzeigevorrichtung
18 ist ein Beispielsblockdiagramm, das die Art angibt, wie das Hacking von Eingabedaten erfolgt. Das Diagramm soll alle Arten von Eingaben betreffen, so beispielsweise Eingaben von einer Tastatur, einer Maus oder einer beliebigen andern Zeigevorrichtung (Pointer). Gemäß 18 erfolgt mit dem Übersenden einer Eingabe von der Eingabevorrichtung 1801 an einen entsprechenden Betriebssystemvorrichtungstreiber 1802 eine Verarbeitung seitens eines geeigneten „Eingabestapels" (Code, der zur Verarbeitung und Weiterleitung der Eingabe geeignet ist). Als Teil der Verarbeitung durch den Eingabestapel wird die Eingabe weiter an Eingaberoutinen geleitet, die üblicherweise von einer Anwendungseingabebibliothek 1803 bereitgestellt werden, damit die Eingabe an die anfragende Anwendung übersandt werden kann. Die Eingabedaten sind, während sie übertragen werden, für Sniffer-Anwendungen (_"Schnüffler"-Anwendungen) 1804 anfällig, die die Daten überwachen, um diese zu erfassen und/oder um nach Eingabemustern suchen.
19 ist ein Beispielsblockdiagramm allgemeiner Techniken, die von einem sicherheitserhöhten Eingabetreiber, so beispielsweise von einem sicherheitserhöhten Maustreiber, verwendet werden, um einen unbefugten Zugriff auf Eingabedaten zu verhindern. Das Diagramm weist dieselben Komponenten wie in 18 auf, jedoch mit einer zusätzlichen Komponente, nämlich dem sicherheitserhöhten Maustreiber (SEMD) 1905. Der SEMD ist ein sicherer Treiber, der von Anwendungen oder anderen Codes 1906 aufgerufen wird, die die Bereitstellung einer sicheren Eingabe wünschen. Der SEMD ist vorzugsweise nach dem first-in-line-Prinzip derart installiert, dass er die Eingabe zunächst von der Hardware erhält, bevor andere Komponenten, darunter die Betriebssystemtreiber, die Möglichkeit haben, die Eingabe abzufangen. Eine Detailbeschreibung der Art, wie ein Treiber als first-in-line-Treiber installiert ist, sowie der Überwachungsmechanismen zur Sicherstellung, dass der Treiber sicher an seinem Ort ver bleibt, wird nachstehend unter Bezugnahme auf 23 gegeben. Kurz gesprochen fängt der SEMD (oder ein anderer sicherer Eingabetreiber) die Daten von der Eingabevorrichtung ab, bestimmt, ob sie von einer befugten Anwendung, die die sichere Eingabe angefordert hat (beispielsweise von der Anwendung 1906), angefordert sind, und sendet, wenn dem so ist, die Eingabe auf sichere Weise an die befugte Anwendung, wohingegen andernfalls die Eingabe an die Standardbetriebssystemtreiber weitergeleitet wird.
20 ist ein Beispielsablaufdiagramm für Verschleierungstechniken, die von einem als Beispiel angegebenen sicherheitserhöhten Eingabetreiber verwendet werden, um einen unbefugten Zugriff auf die Eingabedaten zu verhindern. Gemäß 20 wartet der Eingabetreiber, so beispielsweise ein Maus- oder Tastaturtreiber, (üblicherweise bei der Anforderung einer Anwendung oder des Betriebssystems als Ergebnis einer „Lese"-Anfrage) bis zum nächsten Eingabeereignis. Bei Schritt 2001 macht der Treiber, wenn ein derartiges Ereignis empfangen worden ist, bei Schritt 2002 weiter, um zu bestimmen, ob ein „sicherheitsbefugter" Anfrager die Leseanfrage gestellt hat, und geht, wenn dem so ist, zu Schritt 2004 über, wohingegen ansonsten zu Schritt 2003 übergegangen wird. Im Sinne der vorliegenden Beschreibung ist ein sicherheitsbefugter Anfrager vorzugsweise eine Anwendung oder ein anderer Code, der den sicheren Eingabetreiber insbesondere darüber in Kenntnis gesetzt hat, dass eine sichere Eingabe gewünscht wird. Standardauthentisierungsmechanismen können zur Authentisierung des Anfragers verwendet werden, nachdem sich der Anfrager anfänglich bei dem sicheren Eingabetreiber registriert hat. Bei Schritt 2003 bestimmt der Treibercode, ob der befugte Anfrager ebenfalls spezifiziert, dass er (im Sinne der Vornahme einer zusätzlichen Sicherheitsmaßnahme) eine verschleierte Eingabe spezifiziert hat, und geht, wenn dem so ist, zu Schritt 2006 über, wohingegen er andernfalls zu Schritt 2005 übergeht. Bei Schritt 2005 wird die Eingabe anschließend an den „Eingabeübersetzungsstapel° weitergeleitet, der von dem sicheren Betreiber oder von den Bibliotheken angeboten wird, die die sichere Eingabe verarbeiten, um die Eingabe an den sicherheitsbefugten Anfrager westerzuleiten. Der Eingabeübersetzungsstapel bestimmt üblicherweise, so beispielsweise bei einer Tastatureingabe, das eingegebene Zeichen aus dem Tastencode. Bei Schritt 2006 verschleiert für den Fall, dass eine Verschleierung angefordert worden ist, der Eingabetreiber den Eingabecode unter Verwendung einer beliebigen implementierten oder spezifizierten Verschleierungstechnik. So kann der Eingabecode beispielsweise als Kombination aus Bool'schen Operatoren und einer Maske, so beispielsweise einem Rauschen, einem Muster und dergleichen, nahezu auf dieselbe Weise verschlüsselt werden, wie die Anzeigeausgabe verschleiert werden kann. Bei Schritt 2007 leitet der sichere Eingabe treibercode den verschleierten Eingabecode an den Eingabeübersetzungsstapel weiter, der zum Zwecke der Entschleierung des Eingabecodes unter Verwendung der Umkehr technik bezüglich derjenigen Technik, die zur Verschleierung des Eingabecodes verwendet wurde, kodiert ist.
Sichere Speicherung und Anzeige von Audioinhalt
21 ist ein Beispielsblockdiagramm, das die Art darstellt, wie das Hacking von Audiodaten erfolgt. Mit dem Senden von Audiodaten aus dem Betriebssystemspeicher 2101 oder an den Speicher auf einer Soundkarte 2103 zum Zwecke einer Wiedergabe auf. einem Lautsprecher 2104 sind die Audiodaten durch schädlichen Code, so beispielsweise eine Sniffer Anwendung (Schnüffelanwendung) 2106, angreifbar, während sie in dem Soundkartenspeicher 2103 gespeichert sind. Darüber hinaus nimmt das Betriebssystem (oder andere Anwendungsbibliotheken) bei Anwendungen, die die Audiodaten mittels Streaming verarbeiten, temporär eine Audiopufferung in den Audiopuffern 2102 vor. Die gepufferten Audiodaten 202 sind ebenfalls durch Hacking angreifbar, so beispielsweise seitens einer unbefugten Sniffer-Anwendung 2205.
Bei einem Ausführungsbeispiel verschleiert der SEAD den Inhalt des Pools an Audiopuffern 2202 durch eine auf SEAD-spezifische Weise erfolgende Auswahl dahingehend, welche Puffer zur Sequenzierung der Audiodaten zu verwenden sind. So kann beispielsweise eine zufällige oder pseudozufällige Abfolge von Zahlen verwendet werden, um die Auswahl dahingehend zu treffen, welche Puffer zur Ansammlung der digitalen Form des Audiosignals verwendet werden. Um Versuche abzuwehren, die Nutzung der Puffer nachzuvollziehen, wird Zerstreuerinformation (distracter information) in die Puffer eingebracht, die nicht verwendet werden. Werden die Audiodaten in digitaler Form an die nächste Softwarekomponente weitergeleitet und ist diese Komponente befugt, den SEAD zur Verschleierung der Audiodaten zu verwenden, so werden die Audiodaten aus dem Audiopuffer 2202 unter Verwendung derselben Zufalls- oder Pseudozufallsabfolge von Zahlen extrahiert, um den richtigen Quellenpuffer zu bestimmen. Werden die Audiodaten nicht mehr benötigt, so wird der Puffer an den Pool verfügbarer Puffer zurückgegeben oder weist optional darin befindliche Zerstreuerinformation auf.
Der SEAD kann auch derart implementiert werden, dass er die an die Karte gesendeten Audiodaten beispielsweise mittels Ausführung einer Operation „F" an den Audiodaten zum Zwecke der Verschlüsselung oder einer geeigneten Kodierung oder Maskierung der Daten vornimmt (Die Operation „F" ist soundkartenabhängig und hat, wie dies auch bei anderen Formen der Verschlüsselung der Fall ist, eine zugehörige Umkehroperation für Entschlüsselungszwecke). Werden die Audiodaten von dem SEAD der Soundkarte zum Zwecke der Umwandlung in ein analoges Audiosignal zur Verfügung gestellt, so weist der SEAD zusätzliche Software auf der Soundkarte, so beispielsweise einen auf bestimmten Soundkarten vorhandenen DSP, an, die Entschleierung vorzunehmen. Dies kann auf manchen Soundkarten durch Erzeugen eines Equalizers und eines Soundprozessorcodes sowie durch Verarbeiten der Entschleierungscodes auf eine Weise erfolgen, die ähnlich zu Echo- oder Halleffekten oder anderen Spezialeffekten ist.
Darüber hinaus kann, wenn der SEAD einen Stream von Audioinformation empfängt oder die empfangende sicherheitsbefugte Software einen Stream von Audioinformation an den SEAD sendet, die digitale Darstellung der digitalen Audioinformation vorab verschleiert oder verschlüsselt werden, und zwar auf eine sichere treiberspezifische Weise, sodass der SEAD die Audiodaten auf sichere Weise entschlüsseln kann. So kann beispielsweise das Format verschlüsselt oder codetechnisch in eine Form überführt werden, die für eine Verwendung durch jenes Systems geeignet ist. Der Anfang des Audiostreams wird aus einer herkömmlichen Quelle hergeleitet, so beispielsweise aus MP3-Daten oder MP3-Streams, Streamingservern oder anderen codierten digitalen Audioquellen. Die empfangende sichere Software, die Kenntnis darüber hat, wie diese kodierten Audioquellen zu entschlüsseln sind, führt anschließend den Audiostream in das SEAD-interne Verschleierungsformat über, wodurch der Klartext der Audiodaten auf dem System zu keinem Zeitpunkt in digitaler Form verfügbar ist.
First-in-Line-SED-Installation und Watchdog-Überwachung
Die Eigenschaft, Kontrolle darüber zu haben, zu welchem Zeitpunkt ein Treiber Zugriff auf eine Eingabe und/oder Ausgabe hat, ist für sicherheitserhöhte Treiber von besonderer Wichtigkeit. Jedes Betriebssystem stellt Mechanismen bereit, um zu gewährleisten, dass ein bestimmter Treiber vor allen anderen Treibern oder vor allen Treibern seines Typs (beispielsweise Festplattentreiber) Zugriff hat, was vom Betriebssystem abhängt. Bei Windows-9x-Betriebssystemen ähnlichen Betriebssystemen wird die Ereignisverarbeitung in Form einer „Kette^„ (chain) vorgenommen, wobei Treiber in verschiedenen Teilen der Kette in Abhängigkeit davon installiert sein können, wann sie in das System geladen werden.
Die Eingabeereignisverarbeitung für Windows-9x-Betriebssysteme geht beispielsweise üblicherweise folgendermaßen vonstatten: • Es tritt ein Hardwareereignis, so beispielsweise eine Maus- oder Tastaturaktion, auf (Mausbewegung oder Tastendruck); • Ein (virtueller) Vorrichtungstreiber vom VxP-Typ (oder ein Systemniveautreiber) erfasst die Eingabe von der Hardware, liest sie und sendet das Ereignis an die Hardwarevirtualisierungsschicht; • Die Virtualisierungsschicht sendet sukzessiv die Treiberereigniseingaben an die Liste von Vorrichtungshandlern, die für derartige Ereignisse registriert sind, wobei jeder Vorrichtungshandlerfunktion gestattet wird, die Daten zu verarbeiten oder sie ohne Verarbeitung wieder auszugeben, wobei dann dem nächsten Vorrichtungshandler in der Kette eine Verarbeitung der Daten ermöglicht wird; • Die Treiberereignisse können von dem Handler verarbeitet oder an diejenige Anwendung übersandt werden, die hierfür registriert ist.
Die hier beschriebenen Techniken stellen, wenn sie in Verbindung mit Windows-9x-Betriebssystemen verwendet werden, sicher, dass (insbesondere) Eingabe-SEDs optimal sicher sind, da die relevanten Treiber als oberste (erste) Ereignishandler in der Handlerkette für jede Eingabevorrichtung installiert sind. Darüber hinaus wird ein Watchdog-Prozess aufgerufen, wie nachstehend noch beschrieben wird, um die Position des Handlers periodisch zu validieren. 23 ist ein Beispielsblockdiagramm für die Installierung eines SEDs als first-in-line-Treiber in Windows-9x-Betriebssystemumgebungen sowie für die zugehörigen Überwachungsprozesse.
Bei den Betriebssystemen Windows NT sowie dessen Abkömmlingen erfolgt die Eingabeereignisverarbeitung nach einem anderen Modell. So sieht die Eingabeereignisverarbeitung bei diesen Systemen typischerweise folgendermaßen aus: • Eine Hardwareinterruptserviceroutine (ISR) sammelt rasch Daten und schnürt daraus ein IRP-I/O-Anforderungspaket; • Die ISR nimmt eine Weiterleitung zu einem Miniport vor, der die Hardwareschnittstelle umfasst sowie Kenntnis von der Vorrichtung hat; • Daten werden abstrahiert und weiter an den Porttreiber geleitet. Es liegt üblicherweise ein Porttreiber pro I/O-Vorrichtung vor. Der Porttreiber abstrahiert den Prozess weiter und nimmt eine weitere Verarbeitung an der IRP vor; • Die Daten werden anschließend an den Klassentreiber weitergeleitet. Beispiele hierfür sind die Mausklasse (mouse class) und die Tastaturklasse (kbdclass). Es handelt sich hierbei um die Standardmaus- und Tastaturtreiberklassen für das Windows-Betriebssystem; • Über den Klassentreibern sind die Filtertreiber, wobei die Filtertreiber zu den ersten werden können, die die Eingabe empfangen und anschließend bestimmen, ob diese dem bestehenden System zugeleitet wird oder nicht. So kann sich beispielsweise im Microsoft-Windows-Betriebssystem ein Kemeltreiber selbst in den oberen Filterschlüssel der Registry einfügen, um kundzutun, dass er Schlüsselereignisse empfangen möchte.
Unter Verwendung der vorstehend beschriebenen Abfolge für das NT-Betriebssystem-I/O-Laden und Verarbeiten kann bei einem Ausführungsbeispiel ein SED als Klassentreiber (dass driver) erzeugt werden. Der SED platziert in einem solchen Fall einen Wert in dem oberen Filter der Registry, um für sich herauszustellen, dass sein eigener Eingabeschwerpunkt innerhalb des Betriebssystems liegt. Bei diesem Ausführungsbeispiel muss der SED sicherstellen, dass er der erste Filter in der Registry ist und dass er der erste der Filtertreiber ist, der das I/O-Anforderungspaket direkt von dem Klassentreiber empfängt.
Die Konzepte zur Implementierung eines Watchdog-Dienstes zum Zwecke der Überwachung der Sicherheit sind bei Windows 9x und Windows NT ähnlich, wobei jedoch leichte Abweichungen bei der Implementierung auftreten, was vom Treibermodell des Betriebssystems abhängt. Durch Einfügen einer SED-Filterfunktion (und gegebenenfalls einer Verschleierungsfunktion) als erster Funktion zur Untersuchung und/oder Verarbeitung der Treiberereignisdaten stellen SEDs die Gültigkeit (Validität) und Sicherheit der Maus, der Tastatur und anderer Eingabevorrichtungen sicher, und zwar entweder die Verarbeitung der Daten für die sichere Umgebung oder das Bereitstellen der Möglichkeit, dass die Daten an das Betriebssystem über den normalen Mechanismus zurückgegeben werden. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass ähnliche Techniken in anderen Betriebssystemumgebungen entwickelt werden können, solange nur das Treibermodell bekannt ist und eine SED-Filterfunktion geeignet eingefügt werden kann.
Einem Fachmann auf dem einschlägigen Gebiet erschließt sich zudem, dass keine Unterscheidung zwischen den Maus- und Tastaturvorrichtungen im Zusammenhang mit den vorliegenden Techniken getroffen werden muss. Die Vorrichtungstreiber arbeiten beide im Sinne der vorliegenden Beschreibung auf ähnliche Weise. Dariüber hinaus können diese Techniken auch bei einem Trackball, einer Digitalplatte, einer Schnurlostastatur, einer Schnurlosmaus, einer numerischen Tastatur, einer berührungsempfindlichen Fläche (Touchpad) oder einer anderen zeiger- oder tastenbasierten Eingabevorrichtung verwrendet werden.
Bei einer als Beispiel angegebenen Implementierung von Windows 9x ist der SED-Sicherheitsdienst installiert, der als Zeitgeber wirkt. Beim Hochfahren legt der SED-Sicherheitsdienst einen Kommunikationsweg zu dem SED-Treiber unter Verwendung eines Standardmechanismus, IOCTL(), an. Über den IOCTL-Weg signalisiert der SED-Sicherheitsdienst an den SED, sicherzustellen, dass der SED in der ersten (oberen) Vorrichtungshandlerposition in der Ereignisverarbeitungshandlerkette der Maus oder der Tastatur befindlich ist. Ist dies nicht der Fall, so versucht der SED, den SED-Handler durch Neuregistrierung in die erste Position zu bringen. Schlägt dieser Versuch fehl, so wird eine Fehlermeldung registriert, und das System wird nunmehr, was die Verschleierung angeht, als unsicher betrachtet.
Bei Erfassung einer unsicheren Umgebung wird ein Ereignis, so beispielsweise ein anwendungsspezifisches Ereignis, in der Umgebung verbreitet, damit hierüber sämtliche relevanten Anwendungen informiert werden. So breitet sich beispielsweise in einer xSides-Umgebung, wie detailliert in der am 28. November 2000 eingereichten US-Patentanmeldung mit der Nummer 09/726,202 und dem Titel „Method and System for Controlling a Complementary User Interface on a Display Surface" beschrieben ist, ein xSides-Ereignis aus, wodurch sämtliche xSides-Anwendungen, die auf einer sicheren Eingabefunktionalität beruhen, informiert werden, dass jene Vorrichtung, beispielsweise die Maus- und Tastaturvorrichtung, nicht mehr als sicher betrachtet werden kann. Diese Änderung der Sicherheit wird vorzugsweise auch dem Nutzer über einen Icon mitgeteilt, der in einem sicheren Bereich (wie vorstehend in dem Abschnitt mit dem Titel „Sicheres Speichern und Anzeigen von Videoinhalt" beschrieben worden ist) angezeigt wird. Gemeinsame Bitmaps, die für diesen Zweck verwendet werden, sind ein verschlossenes oder unverschlossenes Vorhängeschloss.
Um sicherzustellen, dass fortwährende Sicherheitsvalidierungsüberprüfungen von dem Sicherheitsdienst vorgenommen werden, wird ein zweiter Dienst gestartet, der als Wachhund (watchdog) für den SED-Sicherheitsdienst arbeitet, was man dann als SED-Sicherheitswatchdog bezeichnet. Der Zweck des Sicherheitswatchdogs besteht im Errichten eines bidirektionalen Datenaustauschweges zu dem Sicherheitsdienst, auf dem Nachrichten zwischen den beiden Diensten hin und hergesandt werden können. Diese Nachrichten können als "Ich-lebe-noch"- oder Pingmechanismen ausgestaltet sein, die jeden Dienst davon in Kenntnis setzen, dass der andere Dienst normal arbeitet. Gelingt es einem Dienst nicht, eine Nachricht von dem anderen Dienst innerhalb einer willkürlich vorgegebenen Zeitperiode zu empfangen, so wird von dem empfangenen Dienst der Versuch unternommen, den jeweils anderen Dienst neuzustarten.
Ist der empfangende Dienste nicht in der Lage, den jeweils anderen Dienst neuzustarten, so wird das System zu Zwecken der Verschleierung als unsicher betrachtet, und es wird dieselbe Nachricht an den Nutzer übersandt, die vorstehend im Zusammenhang mit dem Sicherheitsdienst beschrieben worden ist.
Der Sicherheitsdienst für von Windows NT abgeleitete Betriebssysteme ist im Wesentlichen derselbe wie bei der Windows-9x-Version. Ein Unterschied besteht darin, dass der verifizierte Wert nicht eine Handlerkette, sondern anstatt dessen der Wert des Rückruffunktionszeigers in den I/O-Vollzugsstrukturen für die Eingabevorrichtungen (beispielsweise Maus oder Tastatur) ist. Dies erfolgt durch einen Vergleich der Funktionszeiger. Ist die SED-Rückruffunktion nicht diejenige Rückruffunktion, auf die in der I/O-Vollzugsstruktur verwiesen wird, wird ein Ersetzungsversuch unternommen. Die im Zusammenhang mit Windows 9x beschriebenen Fehlermodi betreffend Fehler beim Ändern des Funktionszeigers für die Rückruffunktion auf die SED-Version sind vorzugsweise auch bei der Windows-NT-Technik verfügbar, das heißt eine Benachrichtigung hinsichtlich „Sicherheit/Unsicherheit".
Der grundlegende SED-Sicherheits-Watchdog-Dienst arbeitet in einer Windows-NT-Umgebung auf ähnliche Weise wie in einer Windows-9x-Umgebung.
Ein zusätzlicher Watchdog-Dienst (oder eine Erweiterung eines bestehenden Dienstes) kann verfügbar gemacht werden, um den Status von Hooks nachzuweisen und um nachzuweisen, dass die SEDs keine Manipulationen erfahren haben. Eine NT-Implementierung umfasst zwei separate Prozesse, die ein Interesse an zwei verschiedenen System-Registry-Einträgen registrieren. Sind diese nicht in Synchronisierung, so benachrichtigt der Watchdog-Dienst die unrichtigen Registry-Einträge und repariert diese automatisch.
Die beiden Registry-Einträge weisen einen ausreichenden Zustand auf, um der Watchdog-Ausführung zu ermöglichen nachzuweisen, dass keinerlei Manipulationen an den Registry-Einträgen vorgenommen wurden. Dies kann beispielsweise durch Speichern der Prüfsumme, Zertifizierungen oder die Signatur der Anwendung in den Registry-Einträgen des Watchdogs selbst zusammen mit einer Exklusiv-ODER-Operation der Signatur oder eines anderen bekannten Wertes oder alternativ einer Signatur erfolgen, die von einem anderen als dem ersten Mechanismus hergeleitet ist. Der Wachhund wird aufgerufen, wenn Registry-Einträge modifiziert werden, und verifiziert, dass die Einträge zu jenem Zeitpunkt richtig sind, und bestimmt für den Fall, dass diese unrichtig sind, die richtigen Werte und ersetzt sie. Da es unwahrscheinlich ist, dass (1) die in der Registry gespeicherten Signaturen, (2) der Watchdog selbst, (3) die Software, von der die Signatur abgeleitet wurde, und (4) die Software, die den Watchdog selbst prüft, alle dergestalt modifiziert worden sind, dass sie als gültig erscheinen, kann dieser Mechanismus allein oder in Kombination mit anderen Maßnahmen verwendet werden, um das Vorliegen einer Manipulation von außen oder einer Abänderung der Softwarecodes zu bestimmen.
Bezeichnen der Sicherheit in Benutzerschnittstellen
Wie dargelegt, stellen zur Ergänzung der Verschleierungstechniken und der sicherheitserhöhten Treiber die Verfahren und Systeme der vorliegenden Erfindung auch verschiedene Techniken zum Bezeichnen der verschiedenen Sicherheitsniveaus in dem System bereit. Einige bestehende Systeme, so beispielsweise Anwendungen wie ein Webbrowser, stellen eine grundsätzliche grafische Darstellung der Sicherheit oder des Sicherheitsniveaus bereit. Der Internetexplorer von Microsoft bedient sich beispielsweise der Darstellung eines „Vorhängeschlosses" (padlock), das in dem Bereich der Statuszeile des Browsers angeordnet ist, um dem Nutzer anzuzeigen, dass eine Website gegenwärtig unter Verwendung sicherer beziehungsweise unsicherer Kommunikationsprotokolle läuft, was üblicherweise mittels Technologien wie SSL oder HTTPS erfolgt. 24 ist eine als Beispiel angegebene Schirmanzeige, die ein Vorhängeschloss zur Bezeichnung der Sicherheit aufweist, wie es bei einer bestehenden Softwareanwendungen verwendet wird.
Die sicherheitserhöhten Treiber gemäß vorliegender Beschreibung stellen einen Mechanismus bereit, durch den ein sicherer Bereich auf einer Anzeigevorrichtung, so beispielsweise ein angezeigtes Desktop, Fenster oder eine alternative Anzeigefläche, den Anzeigecursor (Laufmarke) verwenden kann, um für den Nutzer das Sicherheitsniveau des Bereiches intuitiv anzugeben. Insbesondere ist jeder sichere Bereich mit einem Eigenschaftswert verknüpft, der den Anzeigecursor veranlasst, einen Farbwert entsprechend dem Niveau der Sicherheit in Verbindung mit dem spezifischen Bereich anzuzeigen. Wird der Cursor, was entweder automatisch oder vom Nutzer veranlasst erfolgen kann, von einem Anzeigebereich in einen anderen Anzeigebereich mit einem höheren oder niedrigeren Sicherheitsniveau bewegt, so kann sich die Cursorfarbe und/oder die Cursordarstellung auf den dann richtigen Wert ändern. Bewegt beispielsweise ein Benutzer den Cursor von einer unsicheren Windows-Desktopanzeigefläche in eine alternative Anzeigefläche nach Erzeugung durch eine alternative Anzeigetechnologie, so beispielsweise der von der xSides Corporation entwickelten, so kann die Cursorfarbe von weiß nach rot wechseln, oder sie kann sich vom pfeilförmigen Windows-Standardcursor zur Darstellung eines goldenen Schlüssels wechseln.
Auf ähnliche Weise kann dieser Bezeichnungsmechanismus in einer Umgebung verwendet werden, um mehrere sichere (oder unsichere) Bereiche auf einer Anzeigevorrichtung anzuzeigen, wobei jede andere inhärente Eigenschaften oder Sicherheitswerte aufweist. Die Sicherheitswerte in Verbindung mit jeder Region werden unter Verwendung eines Mechanismus, so beispielsweise einer API-Routine, die in Microsoft Windows Standard ist, wie SetCursor(), abgefragt. Der Rückgabewert der Routine SetCursor() enthält diejenige Information, die zur Anwendung der Identifizierung des Sicherheitsniveaus in Verbindung mit dem spezifischen Bereich notwendig ist.
Der Bezeichnungsmechanismus ist nicht auf die Verwendung des Cursors als Mittel zur Darstellung der Sicherheit beschränkt. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich unmittelbar, dass andere Bestandteile der Desktopanzeige oder Bereiche innerhalb oder außerhalb der Desktopanzeige das Sicherheitsniveau und die entsprechenden Fähigkeiten für den Nutzer anzeigen können. Ist ein Sicherheitsdesktop geladen, so kann dieses Eigenschaften enthalten, die den Endnutzer in die Lage versetzen, das jeweilige Sicherheitsniveau durch eine sichtbare oder hörbare Veränderung bezüglich der Fenster des sicheren Desktops zu unterscheiden. Ein sicheres Desktop kann beispielsweise ein Schloss oder einen damit verknüpften Schlüssel enthalten und in einer Ecke der Desktopanzeige eingeblendet sein. Das Desktop kann auch einen anderen Farbgradienten annehmen, wenn ein anderes Sicherheitsniveau vorliegt. Ein Fenster, eine alternative Anzeige oder ein beliebiger sicherer Bereich können einen farbigen Rand umfassen, der mit dem Sicherheitsniveau verknüpft ist. Alternativ kann die umgebende Berandung ihre Breite, ihre Musterung oder beispielsweise ihr Aussehen (kettenartig) in Abhängigkeit vom Sicherheitsniveau des Fensters, der alternativen Anzeige oder des sicheren Bereiches ändern. Weitere Implementierungen betreffend Änderungen oder Hinzufügungen zu dem Fenster, der Anzeige oder dem Bereich können optional eingesetzt werden, so beispielsweise die Anordnung einer zusätzlichen Verzierung über dem Bereich, so beispielsweise eines diagonal gestreiften schwarzgelben Streifens, oder eine andere Anordnung in unmittelbarer Nähe zu jener Fläche, oder innerhalb der Fläche selbst. Eine weitere Alternative besteht in der Änderung des Aussehens der Standartnutzerschnittstellenelementverzierung, so beispielsweise der Scrollbar, in eine altemative Form, in ein alternatives Muster, eine altemative Farbe oder eine beliebige Kombination hieraus. Darüber hinaus oder in Kombination mit den vorgenannten Variationen können Veränderungen an der Titelzeile, der Überschrift oder an dem Navigationsicon vorgenommen werden, um das Sicherheitsniveau zu bezeichnen, das durch die jeweilige Software eines bestimmten Fensters oder Bereiches gegeben ist. Diese Änderungen können derart einfach sein, dass nur die Titelzeilenüberschrift in einer anderen Farbe angegeben wird, oder sie können eine Zahl oder ein anderes Symbol über dem Navigationsicon des Fensters bezeichnen. 25 ist eine als Beispiel angegebene Schirmanzeige, die die Verwendung des Cursors zur Bestimmung eines Sicherheitsniveaus und andere Darstellungen an Fenstern zum Zwecke der Bezeichnung der Sicherheit darstellen. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich, dass andere ähnliche Techniken ebenfalls mitumfasst sein können.
Für den Fall, dass die Sicherheit über mehrere „Agenten" oder Instanzen der Software bereitgestellt beziehungsweise sichergestellt wird, kann es für den Nutzer von Vorteil sein, den Ursprung der Bezeichnung der Sicherheit zu kennen. Das System gibt vorzugsweise das Sicherheitsniveau über einen beliebigen der vorbeschriebenen Mechanismen an, wobei entweder ein Dauertext bereitgestellt wird, der den Sicherheitsprovider in der Titelzeile, in der Statuszeile oder an einem anderen vergleichsweise festen Ort angibt, oder dies erfolgt auf nichtdauerhafte Weise, wie dies bei einer Popup-Anzeige, einer Tooltip-Anzeige oder einer nichtdauerhaften Textanzeige in einem anderen Abschnitt des Fensters oder des sicheren Bereiches der Anzeigevorrichtung der Fall ist. Die – vorübergehende Textanzeige kann periodisch oder durch irgendein äußeres Ereignis ausgelöst werden, so beispielsweise durch den Eintritt in den Sicherheitsstatus oder die Bewegung des Textes oder des Mauscursors über den Sicherheitsicon.
Es wird deutlich, dass ungeachtet der Tatsache, dass spezifische Beispiele zu Zwecken der Darstellung beschrieben wurden, verschiedene Abwandlungen an der Erfindung vorgenommen werden können. So erschließt sich beispielsweise einem Fachmann auf dem einschlägigen Gebiet unmittelbar, dass Verfahren und Systeme zum Sichern von Dateneingaben und Datenausgaben auch auf andere Arten von Speichern und Eingabevorrichtungen sowie auf andere Arten von Daten, ob sie nun in Streams oder auf andere Weise vorliegen, über das hier Beschriebene hinausgehend angewandt werden können.
So können beispielsweise Verschleierungstechniken, die zur Verschleierung von Daten innerhalb des Frame-Puffers verwendet werden, auch auf die Verschleierung anderer Arten von Speicher ausgedehnt werden. Darüber hinaus können diese Beispiele zur Bereitstellung eines Inhaltskoordinierers für eine derartige Speicherung unter Verwendung von Techniken erweitert werden, die ähnlich zu denjenigen sind, die im Zusammenhang mit den erfindungsgemäßen sicherheitserhöhten Treibern beschrieben worden sind.

Claims

Verfahren in einem Computersystem zum Gewährteisten sicherer Anzeige von Daten auf einer Videoanzeigevorrichtung eines Videoanzeigesystems, wobei das Videoanzeigesystem Videoanzeigespeicher zum Speichern von auf der Videoanzeigevorrichtung anzuzeigenden Daten hat, gekennzeichnet durch: Steuern von Koordinierung (404) des Inhaltes des Videoanzeigespeichers (402), um verschleierte Daten in dem Videoanzeigespeicher zu speichern; und wenn Daten zur Anzeige benötigt werden, temporäres Umwandeln der gespeicherter verschleierten Daten, die in wenigstens einem Abschnitt des Videoanzeigespeichers (402) gespeichert sind, in entschleierte Daten in dem Speicherabschnitt mit einem Exklusiv-Sperrmechanismus, der es keinem anderen Prozess (422) als dem Koordinierungsprozess gestattet, auf den Videoanzeigespeicher zuzugreifen.
Verfahren nach Anspruch 1, wobei die verschleierten Daten erzeugt werden, indem die Daten in wenigstens verschlüsselte Daten oder maskierte Daten umgewandelt werden und die umgewandelten Daten in dem Videoanzeigespeicher gespeichert werden.
Verfahren nach Anspruch 1, wobei die verschleierten Daten wenigstens wertlose Daten, eine Bitmap oder ein opaker einfarbiger Bereich sind.
Verfahren nach Anspruch 3, wobei die Bitmap ein Firmenlogo ist.
Verfahren nach Anspruch 3, wobei der Bereich schwarz ist.
Verfahren nach Anspruch 3, wobei die Bitmap eine Werbung ist.
Verfahren nach Anspruch 3, wobei der Bereich die gesamte Videoanzeigevorrichtung ist.
Verfahren nach Anspruch 1, wobei die Daten in einem Bereich auf der Videoanzeigevorrichtung angezeigt werden und der Bereich einer Gruppe von Positionen in dem Videoanzeigespeicher entspricht und des Weiteren umfasst: Speichern der Daten in einem Overlay-Puffer (509); und Speichern verschleierter Daten an der entsprechenden Gruppe von Positionen (511, 512) in dem Videoanzeigespeicher.
Verfahren nach Anspruch 8, das des Weiteren Kopieren der Daten aus dem Overlay-Puffer zu der Videoanzeigevorrichtung während der Anzeige der Daten auf der Videoanzeigevorrichtung umfasst.
Verfahren nach Anspruch 8, wobei die an der entsprechenden Gruppe von Positionen in dem Videoanzeigespeicher gespeicherten verschleierten Daten wenigstens wertlose Daten, eine Bitmap oder ein opaker einfarbiger Bereich sind.
Verfahren nach Anspruch 10, wobei die Bitmap ein Firmenlogo ist.
Verfahren nach Anspruch 10, wobei der Bereich schwarz ist.
Verfahren nach Anspruch 1, wobei die Daten in einem Bereich auf der Videoanzeigevorrichtung angezeigt werden und der Bereich einer Gruppe von Positionen in dem Videoanzeigespeicher entspricht, und das des Weiteren umfasst: Speichern verschleierter Daten in einem Overlay-Puffer (602); Speichern verschleierter Daten an der entsprechenden Gruppe von Positionen (605) in dem Videoanzeigespeicher; und Umwandeln der in dem Overlay-Puffer gespeicherten verschleierten Daten in entschleierte Daten, wenn die in dem Overlay-Puffer gespeicherten Daten zu dem Bereich auf der Videoanzeigevorrichtung (603) kopiert werden.
Verfahren nach Anspruch 13, wobei die in dem Overlay-Puffer gespeicherten verschleierten Daten eine verschlüsselte Form der Daten sind.
Verfahren nach Anspruch 14, wobei die Umwandlung der in dem Overlay-Puffer gespeicherten verschleierten Daten Entschlüsseln der verschleierten Daten umfasst, wenn die verschleierten Daten zu der Videoanzeigevorrichtung kopiert werden.
Verfahren nach Anspruch 13, wobei die an der entsprechenden Gruppe von Positionen in dem Videoanzeigespeicher gespeicherten verschleierten Daten wenigstens wertlose Daten, eine Bitmap oder ein opaker einfarbiger Bereich sind.
Verfahren nach Anspruch 13, wobei die Bitmap ein Firmenlogo ist.
Verfahren nach Anspruch 16, wobei der Bereich schwarz ist.
Verfahren nach Anspruch 1, das des Weiteren umfasst: Speichern von Daten als verschlüsselte Daten (606) an der entsprechenden Gruppe von Positionen in dem Videoanzeigespeicher; Entschlüsseln der verschlüsselten Daten an der entsprechenden Gruppe von Positionen in dem Videoanzeigespeicher rechtzeitig zum Anzeigen auf der Videoanzeigevorrichtung und so, dass nur die verschlüsselten Daten für Code außerhalb der Koordinierung zugänglich sind.
Verfahren nach Anspruch 1, wobei das Videoanzeigesystem einen Grafikprozessor aufweist, der Daten aus dem Videoanzeigespeicher zu der Videoanzeige kopiert, um Daten in einem Bereich auf der Videoanzeigevorrichtung anzuzeigen, wobei der Bereich einem Abschnitt des Videoanzeigespeichers entspricht, und das des Weiteren umfasst. Speichern verschleierter Daten in dem Abschnitt des Videoanzeigespeichers, der dem Bereich entspricht; und wenn der Grafik-Prozessor auf den Abschnitt des Videoanzeigespeichers zugreift, der dem Bereich entspricht: Abrufen der verschleierten Daten aus dem Abschnitt; und Umwandeln der verschleierten Daten in entschleierte Daten als Teil des Kopierens der Daten aus dem Videoanzeigespeicher zu der Videoanzeige, um so die Daten auf der Videoanzeigevorrichtung anzuzeigen.
Verfahren nach Anspruch 20, wobei die verschleierten Daten eine verschlüsselte Form der gültigen Daten sind und wobei das Umwandeln der verschleierten Daten Entschlüsseln der verschleierten Daten umfasst.
Verfahren nach Anspruch 20, wobei die verschleierte Daten erzeugt werden, indem eine Rasteroperation angewendet wird, um die Daten mit einer Maske zu kombinieren, und wobei das Umwandeln der Daten Anwenden einer Rasteroperation zum Kombinieren der ungültigen Daten mit einer Maske umfasst.
Verfahren nach Anspruch 22, wobei die Rasteroperation eine Exklusiv-ODER-Operation ist und die auf die Daten angewendete Maske die gleiche ist wie die auf die entschleierten Daten angewendete Maske.
Verfahren nach Anspruch 23, wobei das Umwandeln der gespeicherten verschleierten Daten Entschlüsseln, Anwenden einer Rasteroperation auf die gespeicherten verschleierten Daten unter Verwendung einer Maske oder Kopieren entschleierter Daten aus einem Puffer umfasst.
Verfahren nach Anspruch 24, wobei der Puffer ein Overlay-Puffer ist.
Verfahren nach Anspruch 24, wobei der Puffer ein weiterer Bereich des Videoanzeigespeichers ist, der nicht der Abschnitt ist, der dem Bereich entspricht.
Verfahren nach Anspruch 24, wobei der Puffer ein sicherer Datenpuffer ist.
Verfahren nach Anspruch 23, wobei der Exklusiv-Sperrmechanismus ein Interprozess-Sperrmechanismus ist, der durch ein Betriebssystem bereitgestellt wird.
Verfahren nach Anspruch 23, wobei der Exklusiv-Sperrmechanismus hergestellt wird, indem sichergestellt wird, dass der Koordinierungsprozess ein Echtzeit-Prioritätsprozess ist.
Verfahren nach Anspruch 23, wobei das Computersystem ein Betriebssystem hat, das Zugriff auf Gerätetreiber in gesteuerter Reihenfolge zulässt, die Reihenfolge einen ersten Treiber hat und der Exklusiv-Sperrmechanismus hergestellt wird, indem sichergestellt wird, dass ein Gerätetreiber, der die Koordinierung implementiert, der erste Treiber ist.
Verfahren nach Anspruch 1, wobei das Videoanzeigesystem einen Grafikprozessor aufweist, der während einer Vielzahl von Zeitscheiben Daten aus dem Videoanzeigespeicher zu der Videoanzeige kopiert, die Daten in einem Bereich auf der Videoanzeigevorrichtung angezeigt werden und der Bereich einem Abschnitt des Videoanzeigespeichers entspricht, und das des Weiteren umfasst: Speichern verschleierter Daten in dem Abschnitt des Videoanzeigespeichers, der dem Bereich entspricht; und Ersetzen der verschleierten Daten in dem Videoanzeigespeicher durch entschleierte Daten während einer Zeitscheibe, so dass, wenn der Grafikprozessor auf den Abschnitt des Videoanzeigespeichers zugreift, der dem Bereich entspricht, der Grafikprozessor die entschleierten Daten abrufen kann, und, wenn der Grafikprozessor nicht auf den Abschnitt des Videospeichers zugreift, der Abschnitt die verschleierten Daten enthält.
Verfahren nach Anspruch 31, wobei die verschleierten Daten durch entschleierte Daten ersetzt werden, indem die verschleierten Daten während der Zeitscheibe temporär in entschleierte Daten in dem Videoanzeigespeicher umgewandelt werden und die verschleierten Daten dann wiederhergestellt werden.
Verfahren nach Anspruch 32, wobei das Umwandeln Entschlüsseln oder Anwenden einer Rasteroperation ist.
Verfahren nach Anspruch 32, wobei bei dem Umwandeln ein Masken-Puffer auf die ungültigen Daten unter Verwendung einer Exklusiv-ODER-Rasteroperation angewendet wird.
Verfahren nach Anspruch 31, wobei die verschleierten Daten durch entschleierte Daten ersetzt werden, indem Daten aus einem Overlay-Puffer kopiert werden und dann die verschleierten Daten nach der Zeitscheibe wiederhergestellt werden.
Verfahren nach Anspruch 35, wobei das Wiederherstellen durchgeführt wird, indem verschleierte Daten aus einem Masken-Puffer kopiert werden.
Verfahren nach Anspruch 31, wobei die verschleierten Daten durch die entschleierten Daten ersetzt werden, indem Daten aus einem sicheren Puffer kopiert werden, der die Daten enthält, und dann die verschleierten Daten nach der Zeitscheibe wiederhergestellt werden.
Verfahren nach Anspruch 37, wobei das Wiederherstellen durchgeführt wird, indem verschleierte Daten aus einem Masken-Puffer kopiert werden.
Verfahren nach Anspruch 37, wobei die entschleierten Daten in einem sicheren Gebiet des Videoanzeigespeichers gespeichert werden.
Verfahren nach Anspruch 37, wobei der Puffer entschleierter Daten in einem sicheren Gebiet des Computersystems gespeichert wird, das nicht als Teil des Videoanzeigesystems resident ist.
Verfahren nach Anspruch 37, wobei der Puffer entschleierter Daten nur für Code zugänglich ist, der die Koordinierung steuert.
Verfahren nach Anspruch 31, wobei die verschleierten Daten in dem Videoanzeigespeicher unter Verwendung von Daten aus einem Masken-Puffer zum direkten Ersetzen der verschleierten Daten in dem Videoanzeigespeicher durch die entschleierten Daten verarbeitet werden und die Daten in dem Videoanzeigespeicher nach der Zeitscheibe durch die verschleierten Daten ersetzt werden.
Verfahren nach Anspruch 31, wobei die verschleierten Daten wertlose Daten, eine Bitmap oder ein opaker einfarbiger Bereich sind.
Verfahren nach Anspruch 31, wobei die verschleierten Daten erzeugt werden, indem die entschleierten Daten zu wenigstens verschlüsselten Daten oder maskierten Daten umgewandelt werden und die umgewandelten Daten als verschleierte Daten in dem Abschnitt des Videoanzeigespeichers gespeichert werden.