DE60311146T2

DE60311146T2 - Verfahren zur vertrauenswürdigen Kommunikation zwischen zwei Einheiten

Info

Publication number: DE60311146T2
Application number: DE60311146T
Authority: DE
Inventors: Benoit De Boursetty; Manuel Gruson; Dimitri Mouton
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2002-12-18
Filing date: 2003-10-29
Publication date: 2007-10-31
Anticipated expiration: 2023-10-30
Also published as: DE60311146D1; AU2003292291A1; ES2280807T3; US7660863B2; FR2849314B1; US20060168237A1; FR2849314A1; WO2004066581A1; EP1574002A1; EP1574002B1

Description

Die vorliegende Erfindung betrifft die Personal-Computer-Endgeräte, die es Benutzern ermöglichen, auf Online-Dienste zuzugreifen.
Solche Endgeräte können insbesondere Telefone, die das drahtlose Anwendungsprotokoll (WAP, "wireless application protocol") verwenden, Bürocomputer, tragbare Computer oder persönliche digitale Assistenten (PDA, "personal digital assistant") sein. Sie haben die Eigenschaft gemeinsam, dass sie mit einem digitalen Datennetz verbunden sind, das in vielen praktischen Fällen ein Netz ist, das gemäß dem Protokoll IP ("Internet protocol") arbeitet, insbesondere das Internet.
Bei diesen Endgeräten ist es möglich, verschiedene Anwendungen zu installieren. Unter diesen Anwendungen wird häufig eine Unterscheidung gemäß verschiedenen Kriterien gemacht, wie zum Beispiel ihr Ursprung, der ihnen von einem Administrator gewährte Vertrauensgrad, usw., was zu unterschiedlichen Fähigkeiten mancher Anwendungen bezüglich anderer führt.
Bei den Systemen, die unter dem Betriebssystem "Unix" arbeiten, sind zum Beispiel die Ausführungsrechte der Anwendungen der Klasse "setuid root" die maximalen Rechte der Administratorebene, während die Ausführungsrechte der anderen Anwendungen einfach die Rechte des Benutzers sind, der die Anwendung startet. Bei einem anderen Beispiel, bei den Web Navigatoren, die eine virtuelle Java-Maschine aufweisen, sind die Anwendungen, "Applets" genannt, die von einer gegebenen Webseite heruntergeladen werden, bezüglich ihrer Fähigkeiten des Zugriffs auf das Netz beschränkt, d.h., dass sie nur zu dieser Webseite Anfragen des HTTP-Protokolls ("hypertext transfer protocol") senden können.
Manche dieser Ausführungsrechte der Anwendungen sind rein lokal. Dies ist zum Beispiel der Fall bei dem Recht, die Kontrolle des Bildschirms eines Endgeräts zu übernehmen, oder dem Recht, alle auf der Tastatur des Endgeräts gedrückten Tasten, selbst für andere Anwendungen, zu kennen.
Andere Ausführungsrechte können aber aus der Ferne beobachtet werden. Dies ist zum Beispiel der Fall bei dem Recht, beliebige IP-Pakete zu senden, einschließlich der IP-Pakete, die sich nicht den Formaten der üblichsten Transportprotokolle anpassen würden, nämlich TCP ("transmission control protocol") oder UDP ("user datagram protocol"). Bei den Unix-Systemen wird dieses Recht den Anwendungen, die nicht zu der Klasse "setuid root" gehören, nicht verliehen. Durch Verwendung dieser unterschiedlichen Fähigkeit, Anfragen zu senden, kann ein Fernbeobachter wie ein Server feststellen, ob ein gegebenes Paket von einer Anwendung der Klasse "setuid root" gesendet wurde: Wenn er beobachtet, dass dieses Paket nicht dem Format TCP oder UDP entspricht, handelt es sich zwangsweise um eine Anwendung der Klasse "setuid root"; ansonsten kann es sich um eine Anwendung ohne privilegierte Rechte handeln.
Im Fall der Applets in den Navigatoren bei Personal-Computern sind die Fähigkeiten, HTTP-Anfragen zu senden, nur auf die Webseite begrenzt, von der das Applet heruntergeladen wurde. Für jede empfangene HTTP-Anfrage kann ein Webserver also ableiten, dass sie entweder von einem Applet, das auf der Seite vorhanden ist, oder von einer anderen Anwendung kommt (zum Beispiel dem Navigator). In jedem Fall kommen die von einem Webserver empfangenen Anfragen nicht von "fremden" Applets, die auf anderen Seiten vorhanden sind.
Hier geht es um das Problem zu erfahren, wie ein Server auf gesicherte Weise die Zustimmung des Benutzers zu einer gegebenen Frage einholen kann. Die dem Benutzer zu stellende Frage muss dem Benutzer mittels einer Anwendung auf seinem Endgerät präsentiert werden. Die Anwendung holt die Zustimmung (oder die Nicht-Zustimmung) des Benutzers ein und überträgt dann eine entsprechende Anzeige an den Server.
Der Server empfängt also Mitteilungen über das Netz und interpretiert sie als die Zustimmung (oder Nicht-Zustimmung) des Benutzers. Hierzu muss er annehmen, dass die Anwendung wirklich dem Benutzer die Frage präsentiert und seine Zustimmung nach bestem wissen eingeholt hat. Der Server nimmt also an, dass die Anwendung kein "Trojanisches Pferd" ist, das zum Beispiel dem Benutzer eine andere Frage präsentiert hätte oder das ganz einfach dem Benutzer nicht die Frage gestellt sondern so getan hätte, als ob dieser einverstanden gewesen wäre. Um den Benutzer vor möglichen Programmen der Art "Trojanisches Pferd" zu schützen, ist es wichtig, sich dieser Vertrauenshypothese zu vergewissern.
Es gibt mehrere Mittel, diese Hypothese des Vertrauens in die Anwendung vernünftig zu erfüllen.
Manche Anwendungen werden als "vertrauenswürdig" anerkannt. Eine solche Anwendung ist zum Beispiel der WAP-Navigator. Ein Server kann einem WAP-Navigator vertrauen, dass er eine Seite anzeigt, die dem Benutzer eine Frage stellt, und erwartet, dass der Benutzer seine Antwort eingibt.
Im Fall eines "geschlossenen" Endgeräts (Beispiel: Minitel) sind die im Endgerät vorhandenen Anwendungen bekannt und können während der Lebensdauer des Endgeräts nicht verändert werden. Alle diese Anwendungen sind als "vertrauenswürdig" anerkannt.
Das Öffnen eines Endgeräts bezieht sich auf die dem Benutzer angebotene Möglichkeit, neue Anwendungen zu installieren und oft herunterzuladen, die dazu bestimmt sind, vom Endgerät selbst ausgeführt zu werden. Beispiele von "offenen" Endgeräten, die diese Möglichkeit bieten, sind:

• die Telefone mit Herunterladen von Anwendungen, zum Beispiel vom Typ Java MIDP ("Mobile Information Device Profile", Sun Microsystems, Inc.);
• die Navigatoren, die Scripting genannte Funktionalitäten aufweisen, zum Beispiel vom Typ WMLScript (siehe "WAP WMLScript Language Specification", Version 1.1, WAP Forum, November 2001) oder ECMAScript (auch JavaScript genannt, siehe "ECMAScript Language Specification". Standard ECMA-262, 3. Ausgabe, Dezember 1999), oder Applets empfangen;
• die meisten PDA, die unter den Betriebssystemen PalmOS, WindowsCE, Symbian usw. arbeiten;
• die Bürocomputer oder tragbaren Computer.

Die "halb-offenen" Endgeräte sind die offenen Endgeräte, bei denen bestimmte Funktionalitäten nicht direkt für die Anwendungen zugänglich sind, die vom Benutzer installiert oder heruntergeladen werden. Bei einem Endgerät, dessen einzige "Öffnung" ECMAScript ist, können zum Beispiel die heruntergeladenen Anwendungen nicht auf alle Funktionalitäten des Netzes zugreifen (zum Beispiel beliebige IP-Pakete senden). Diese Funktionalitäten können indirekt und kontrolliert zugänglich sein. Zum Beispiel kann eine Funktion ECMASCript das Laden einer Seite über HTTP steuern, wodurch das Netz benutzt, aber kontrolliert benutzt wird.
Bei den "halb-offenen" Endgeräten gibt es eine Koexistenz:

• von Anwendungen, die als "vertrauenswürdig" angesehen werden, zum Beispiel, weil sie in der Fabrik vom Hersteller des Endgeräts installiert wurden, oder aufgrund der Garantie, die von Mitteln wie der elektronischen Signatur der Anwendung usw. vermittelt werden;
• und anderen Anwendungen, die vom Benutzer selbst nach seinem Gutdünken im Endgerät installiert werden können, die aber nicht auf die gleichen Rechte zugreifen wie die vertrauenswürdigen Anwendungen.

Die "vollständig offenen" Endgeräte sind dagegen die offenen Endgeräte, bei denen alle Funktionalitäten für die heruntergeladenen Anwendungen zugänglich sind. Der Begriff der Öffnung eines Endgeräts hängt in großem Maße von dem Kontext ab, in den man sich begibt. Zum Beispiel können verschiedene Schichten des OSI-Modells (Link / Netz / Sitzung / Transport / ...) verschiedene Öffnungsgrade haben.
Hier geht es um die Funktionalitäten, die aus der Ferne ausgehend von einem Server beobachtet werden können, d.h. um die Netzfunktionalitäten. In diesem Rahmen bedeutet der "halb-offene" Charakter eines Endgeräts im Allgemeinen, dass Ausführungsrechte, die aus der Ferne beobachtet werden können und für die vertrauenswürdigen Anwendungen zugänglich sind, nicht für die nicht-vertrauenswürdigen Anwendungen zugänglich sind (zum Beispiel das Recht, andere Anfragen als HTTP auf einem IP-Netz zu senden). Dadurch wird es einem Server ermöglicht, unter den bei ihm ankommenden Anfragen diejenigen, die von vertrauenswürdigen Anwendungen kommen und diejenigen, die von anderen Anwendungen kommen, zu unterscheiden.
Die Druckschrift "Wireless Java Security", XP2249490, offenbart Personal-Computer-Endgeräte, die es Benutzern ermöglichen, auf Online-Dienste zuzugreifen. Bei diesen Endgeräten gibt es Anwendungen, die als "vertrauenswürdig" und als "nicht-vertrauenswürdig" angesehen werden.
Die "Applets", die der Benutzer nach seinem Gutdünken installiert, sind nicht unbedingt vertrauenswürdig, um auf einen beliebigen Server zuzugreifen. Die Beschränkung der Anfragen jedes Applets auf die Webseite, von der es heruntergeladen wurde, ermöglicht es aber einer Webseite, die Kontrolle über die Applets zu behalten, die Anfragen an sie senden können. Es ist also vernünftig, dass der Server annimmt, dass die Anwendungen, die dem Benutzer Fragen präsentieren, keine Trojanischen Pferde sind. Diese Anwendungen sind also "vertrauenswürdig", aber nur für eine Webseite.
Bei den offenen Endgeräten muss die Möglichkeit berücksichtigt werden, dass ein Programm sich gegenüber einem Benutzer irreführend verhält (Trojanisches Pferd). So kann nichts einem Server garantieren, dass eine Anfrage wirklich vom Benutzer und nicht von einem Programm kommt, das die Zustimmung des Benutzers auf der Netzebene simuliert hat. Diese Gefahr zerstört das Vertrauen, das der Server in die Daten haben kann, die er von einem Kunden empfängt. Die Annahme, gemäß der die an den Server gerichteten Anfragen die Aktionen des Benutzers reflektieren, ist nicht vernünftig, wenn ein Trojanisches Pferd die Möglichkeit hat, sie anstelle des Benutzers zu senden.
Die klassische Antwort auf die Gefahr eines Trojanischen Pferds ist es, die Fähigkeiten der nicht-vertrauenswürdigen Anwendungen zu begrenzen.
Die Begrenzung des Sendens der Rahmen ausgehend von den halb-offenen Endgeräten erfolgt im Allgemeinen äußerst strikt. Nur die vertrauenswürdigen Anwendungen sind berechtigt, bestimmte Rahmen zu senden. Diese Unterscheidung wird verwendet, damit der Server nicht als für die Zustimmung des Benutzers repräsentativ Rahmen verwendet, die von nicht-vertrauenswürdigen Anwendungen gesendet werden, die den Benutzer verraten können.
Es wird für eine nicht-vertrauenswürdige Anwendung also unmöglich, Rahmen an einen Server zu senden. Es wird für diese Anwendung insbesondere unmöglich, diesem Server die Zustimmung des Benutzers zu beweisen. Es ist zum Beispiel einer nicht-vertrauenswürdigen Anwendung unmöglich, dem Benutzer vorzuschlagen, unter Verwendung eines elektronischen Handelsservers zu zahlen.
Für ein "Applet", das darauf beschränkt ist, Anfragen nur an die Webseite zu senden, von der es heruntergeladen wurde, wird das Vertrauen nur für diesen Server verliehen. Es ist diesem Applet also möglich, die Zustimmung des Benutzers einzuholen und das Ergebnis an die Webseite zu übertragen, von der es heruntergeladen wurde. Dann wird die – vernünftige – Hypothese aufgestellt, dass der Server niemals vorgeschlagen hat, Anwendungen vom Typ "Trojanisches Pferd" herunterzuladen.
Es gibt Systeme auf Kryptographie-Basis, um elektronische Signaturen zu erzeugen. Ein Beispiel dafür ist in der Spezifikation "WAP WMLScript Crypto Library", WAP Forum, Juni 2001 beschrieben. Diese Systeme können verwendet werden, um die Zustimmung des Benutzers einzuholen, sie stellen die Hypothese auf, dass das System halb-offen ist, d.h. in diesem Fall, dass die Zugriffsfunktionen zu den kryptographischen Schlüsseln den nicht-vertrauenswürdigen Anwendungen nicht direkt zur Verfügung stehen. Der Zugriff auf die kryptographischen Schlüssel wird von einer besonderen Softwarekomponente verwaltet, die wir "elektronische Signaturkomponente" nennen, die die Aufgabe hat, die Zustimmung des Benutzers für die Anwendung einzuholen. Diese Komponente führt von sich aus die folgende Verkettung von Operationen für nicht-vertrauenswürdige Anwendungen aus:

• den zu signierenden Text auf dem Bildschirm anzuzeigen;
• die Bestätigung des Benutzers abzuwarten;
• wenn eine Bestätigung empfangen wird, die kryptographischen Schlüssel des Benutzers zu verwenden, um den angezeigten Text zu signieren;
• sonst den angezeigten Text nicht zu signieren.

Dies ermöglicht es also nicht-vertrauenswürdigen Anwendungen, eine elektronische Signatur der Zustimmung des Benutzers über die elektronische Signaturkomponente zu erlangen. Dieses Verfahren ermöglicht es dem Server, die Zustimmung des Benutzers bezüglich eines beliebigen Texts zu erhalten.
Es muss hier angenommen werden, dass das Endgerät nicht vollständig offen ist. Wenn es einer nicht-vertrauenswürdigen Anwendung möglich wäre, direkt auf die Verschlüsselungsfunktionen zuzugreifen, könnte man nicht wissen, ob vor dem Einsetzen der kryptographischen Funktionen eine Anzeige des ganzen zu signierenden Texts liegt oder ob das Endgerät wirklich die Zustimmung des Benutzers abgewartet hat, ehe es die Signatur ausführt.
Andererseits verwendet dieses Verfahren kryptographische Techniken, die sich in der Ausführungszeit, in der Größe der über das Netz ausgetauschten Mitteilungen sowie im Stromverbrauch (hoch bei tragbaren Endgeräten) als teuer erweisen können. Außerdem kann die Gesetzgebung bezüglich der kryptographischen Techniken die Möglichkeit des Zurückgreifens auf dieses Verfahren ggf. beschränken.
Es ist also wünschenswert, ein Verhalten zu liefern, das bezüglich der Öffnung für die nicht-vertrauenswürdigen Anwendungen praktisch gleichwertig ist, aber nicht auf die Kryptographie zurückgreift.
Ein Ziel der vorliegenden Erfindung ist es, einer "nicht-vertrauenswürdigen Anwendung" in halb-offener Umgebung zu ermöglichen, die Zustimmung des Benutzers zu einer gegebenen Frage einzuholen und einen fernen Server darüber zu informieren, indem ihm bewiesen wird, dass dies auf ehrliche Weise erfolgt ist.
Die Erfindung schlägt ein Kommunikationsverfahren zwischen einer ersten Einheit und einer zweiten Einheit über ein Telekommunikationsnetz vor, bei dem die erste Einheit eine erste Familie von Anwendungen und eine zweite Familie von Anwendungen aufweist, die Kommunikationsfähigkeiten im Netz hat, die über die Kommunikationsfähigkeiten der Anwendungen der ersten Familie hinausgehen. Erfindungsgemäß weist dieses Verfahren die folgenden Schritte auf:

/a/ eine Vertrauenskomponente, die zur zweiten Familie von Anwendungen gehört, erhält den Wortlaut einer an einen Benutzer der ersten Einheit zu stellenden Frage im Rahmen der Ausführung einer Anwendung der ersten Familie;
/b/ die Vertrauenskomponente präsentiert die Frage mittels einer Benutzerschnittstelle und empfängt eine Antwort vom Benutzer; und
/c/ für mindestens einen Typ von Antwort vom Benutzer überträgt die Vertrauenskomponente über das Netz mindestens eine Mitteilung an die zweite Einheit, die die präsentierte Frage identifiziert und die empfangene Antwort angibt, wobei die Mitteilung unter Bedingungen übertragen wird, die für die Anwendungen der ersten Familie unzugänglich sind.

Ein anderer Aspekt der vorliegenden Erfindung bezieht sich auf eine Software-Vertrauenskomponente zur Anwendung des obigen Verfahrens auf der Ebene der ersten Einheit sowie auf ein Kommunikations-Terminal, das eine solche Software-Vertrauenskomponente enthält. Diese Vertrauenskomponente gehört zur erwähnten zweiten Familie von Anwendungen und umfasst Befehle, um bei ihrer Ausführung in der ersten Einheit die folgenden Schritt zu steuern:

/a/ den Wortlaut einer an einen Benutzer der ersten Einheit im Rahmen der Ausführung einer Anwendung der ersten Familie zu stellenden Frage zu erhalten;
/b/ die Frage mittels einer Benutzerschnittstelle zu präsentieren und eine Antwort vom Benutzer zu empfangen; und
/c/ für mindestens einen Antworttyp vom Benutzer an die zweite Einheit über das Netz mindestens eine Mitteilung zu übertragen, die die präsentierte Frage identifiziert und die eingeholte Antwort anzeigt, wobei die Mitteilung unter für die Anwendungen der ersten Familie unzugänglichen Bedingungen erfolgt.

Weitere Besonderheiten und Vorzüge der vorliegenden Erfindung gehen aus der nachfolgenden Beschreibung von nicht einschränkenden Ausführungsbeispielen unter Bezugnahme auf die beiliegenden Zeichnungen hervor, in denen die 1 und 2 Schaltbilder eines die Erfindung verwendenden Systems sind.
Man möchte es einer fernen Einheit wie einem Server 1 ermöglichen, auf sichere und flexible Weise die Zustimmung des Benutzers eines halb-offenen Endgeräts 2 bezüglich einer gegebenen Frage zu erhalten. Die Zustimmung kann durch vertrauenswürdige Anwendungen 3, wie im Fall der Navigation, aber auch ausgehend von nicht-vertrauenswürdigen Anwendungen 4 erhalten werden, die beschränktere Kommunikationsfähigkeiten (sogar nicht vorhandene) im Telekommunikationsnetzwerk R haben, das verwendet wird, um mit dem Server 1 zu dialogisieren.
Man versetzt sich hier in den Rahmen eines Endgeräts 2, das zwischen vertrauenswürdigen Anwendungen 3 und nicht-vertrauenswürdigen Anwendungen 4 unterscheidet. Diese Unterscheidung drückt sich in unterschiedlichen Fähigkeiten des Sendens von Rahmen oder Anfragen über das Netz R aus. Die nicht-vertrauenswürdigen Anwendungen 4 sind bezüglich der Rahmen, die sie senden können, begrenzt, was im Schaltbild der 1 durch eine Kontrollschicht 5 symbolisiert wird, die Teil der Zugriffsressourcen 6 zum Netz ist, mit denen das Endgerät 2 ausgestattet ist.
Die Kontrollschicht 5 prüft, ob bestimmte Eigenschaften von den von den nicht-vertrauenswürdigen Anwendungen 4 gesendeten Rahmen erfüllt werden. Wenn diese Eigenschaften erfüllt werden, lässt die Kontrollschicht die Rahmen durch. Ansonsten kann sie sie entweder nicht zum Netz R durchlassen und die nicht-vertrauenswürdige Anwendung 4, die sie gesendet hat, darüber informieren, oder die Rahmen verändern, um sie den Zwängen der nicht-vertrauenswürdigen Anwendungen anzupassen. In diesem letzteren Fall verliert der Rahmen dann seine Glaubwürdigkeit in den Augen des Servers 1, der ihn nicht nutzt.
Die Erfindung nutzt diese Kontrollschicht 5 (deren Vorhandensein nur implizit sein und aus Eigenschaften des Betriebssystems oder allgemeiner der Ausführungsumgebung der Anwendungen im halb-offenen Endgerät resultieren kann), um eine nicht-vertrauenswürdige Anwendung 4 daran zu hindern, selbst Anfragen zu senden, die einem Server die Zustimmung des Benutzers bezüglich der gestellten Frage beweisen würden. Eine solche Anwendung kann also nicht selbst die Zustimmung des Benutzers in einer Form einholen, die vom Server 1 nutzbar ist.
So wird in das Endgerät 2 zwischen der nicht-vertrauenswürdigen Anwendung, dem Server und dem Benutzer eine Software-Vertrauenskomponente 8 eingefügt, über deren "ehrliches" Verhalten man sich vorher vergewissert hat. In der Praxis kommt diese Sicherheit oft vom Hersteller des halb-offenen Endgeräts. Die Vertrauenskomponente 8 kann nicht von einer nicht-vertrauenswürdigen Anwendung ersetzt oder verändert werden, was vom halb-offenen System selbst gewährleistet wird, für das eine Vertrauensanwendung vertrauenswürdig bleiben muss. Es gibt also keine Gefahr, dass die Komponente 8 sich wie ein Trojanisches Pferd verhält. Eine Hauptaufgabe der Vertrauenskomponente 8 ist es, die Zustimmung des Benutzers für eine oder mehrere nicht-vertrauenswürdige Anwendungen 4 mittels einer Benutzerschnittstelle 9 des Endgeräts einzuholen.
Die Vertrauenskomponente 8 ist bezüglich der Anfragen, die sie senden kann, nicht begrenzt, oder zumindest erfährt sie weniger strenge Einschränkungen als die nicht-vertrauenswürdigen Anwendungen 4. Im durch die obige 2 schematisch dargestellten Beispiel wird sie nicht von der Kontrollschicht 5 überwacht.
Man interessiert sich für eine Anwendung 3 oder 4, die einem fernen Server 1 beweisen möchte, dass sie die Zustimmung des Benutzers für eine gegebene Frage erhalten hat.
Sie verfügt ursprünglich über den Wortlaut der Frage sowie über einen Adressierungsdatenwert, der es ermöglicht, den fernen Server zu kontaktieren, zum Beispiel eine Angabe vom Typ URL ("Uniform Resource Locator").
Die Kommunikationen dieser Anwendungen 3, 4 sind den folgenden Regeln unterworfen:

– die Anwendungen können Fernkommunikationen mittels der Ressourcen 6 und des Netzes R ausführen, aber diese Kommunikationen werden vom halb-offenen Betriebssystem begrenzt, das eine logische Kontrollschicht 5 aufweist;
– jeder ferne Server 1, der die angewendeten Begrenzungen kennt, kann bestimmen, ob die Mitteilungen, die er empfängt, von vertrauenswürdigen Anwendungen kommen oder nicht, indem er untersucht, ob die Begrenzungen angewendet werden;
– die Vertrauenskomponente 8 hat die Möglichkeit, Kommunikationen außerhalb der Begrenzungen auszuführen, die den nicht-vertrauenswürdigen Anwendungen 4 aufgezwungen sind, aber auch innerhalb dieser Begrenzungen, wenn sie dies wünscht. Sie kann in dieser Hinsicht als zur gleichen Familie wie die vertrauenswürdigen Anwendungen 3 gehörend angesehen werden.

Eine nicht-vertrauenswürdige Anwendung, die die Zustimmung des Benutzers zu einer gegebenen Frage erhalten und diese Zustimmung einem fernen Server 1 beweisen möchte, liefert der Vertrauenskomponente 8 den Wortlaut der Frage sowie die Adresse des Servers. Die Vertrauenskomponente 8 präsentiert dann die Frage dem Benutzer mittels der Schnittstelle 9. Die Entscheidung des Benutzers (annehmen oder ablehnen, wobei die Abwesenheit einer Antwort nach einer bestimmten Frist als eine Ablehnung interpretiert werden kann) wird von der Vertrauenskomponente eingeholt.
Wenn die eingeholte Entscheidung eine Zustimmung ist, wird eine Anfrage außerhalb der an die nicht-vertrauenswürdigen Anwendungen angewendeten Begrenzungen von der Vertrauenskomponente an den Server an die vorher durch die Anwendung 4 angegebene Adresse gesendet. Diese Anfrage enthält:

– den Wortlaut der Frage
– die Antwort des Benutzers

Der Server 1 prüft implizit oder explizit, ob die Anfrage wirklich außerhalb der an die nicht-vertrauenswürdigen Anwendungen angewendeten Begrenzungen übertragen wurde und antwortet auf diese Anfrage nach Validierung. Die Antwort auf die Anfrage wird schließlich von der Vertrauenskomponente 8 an die nicht-vertrauenswürdige Anwendung 4 übertragen.
Im Fall einer Nicht-Zustimmung des Benutzers, die von der Vertrauenskomponente 8 beobachtet wird, kann diese direkt an die Anwendung 4 eine Antwort übertragen, die das Scheitern anzeigt. Die negative Antwort des Benutzers wird in diesem Fall nur optional zum Server 1 übertragen.
Wenn er der "Vertrauenskomponente" 8 vertraut, ist der ferne Server 1 sicher, dass die außerhalb der Begrenzungen liegenden Anfragen, die er empfängt, wirklich Fragen entsprechen, die dem Benutzer gestellt wurden, und dass die Wahl des Benutzers korrekt eingeholt wurde. Eine nicht-vertrauenswürdige Anwendung kann dieses Verhalten nicht simulieren. Die Gefahr eines Trojanischen Pferds ist also beseitigt.
Wenn die Überprüfung der Anfrage, die die Zustimmung des Benutzers anzeigen soll, durch den Server 1 zeigt, dass sie innerhalb der an die nicht-vertrauenswürdigen Anwendungen angelegten Begrenzungen übertragen wurde, wird diese Anfrage nicht als für die Zustimmung des Benutzers repräsentativ interpretiert. Diese Ablehnung durch den Server kann optional dem Endgerät zurückgemeldet werden.
Natürlich kann die dem Benutzer präsentierte Frage eine Antwort beliebigen Typs verlangen, die ausführlicher ist als "ja/nein". Die Frage kann insbesondere die Form eines Formulars annehmen, in das mehrere Eingaben vom Benutzer einzutragen wären. In diesem Fall können die verschiedenen vom Benutzer eingetragenen Eingaben an den Server übertragen werden, nachdem die Vertrauenskomponente 8 eine Validierung von Seiten des Benutzers angefordert und erhalten hat.
In der obigen Beschreibung erzeugt die nicht-vertrauenswürdige Anwendung 4 selbst den Text der Frage. Wenn man vorzieht, dass der Server 1 den Text der Frage erzeugt, kann man zum Beispiel folgendermaßen vorgehen:

– eine nicht-vertrauenswürdige Anwendung 4 unterbreitet der Vertrauenskomponente 8 die Adresse eines Servers 1 (zum Beispiel eine URL) und eine geeignete, an ihn zu sendende Anfrage, um den Wortlaut der zu stellenden Frage zu erhalten;
– die Vertrauenskomponente 8 sendet die Anfrage über das Netz R, um von diesem Server 1 den Wortlaut der Frage anzufordern. Die Anfrage geht vorzugsweise über die Kontrollschicht 5, um zu gewährleisten, dass sie sich innerhalb der für die nicht-vertrauenswürdigen Anwendungen 4 genehmigten Grenzen befindet;
– der Server 1 schickt den Wortlaut der Frage in Zusammenhang mit einer Referenz zurück, die später bei der Übertragung der Zustimmung des Benutzers erwähnt werden muss;
– die Vertrauenskomponente 8 präsentiert die Frage dem Benutzer wie vorher;
– der Benutzer trifft seine Entscheidung;
– die Entscheidung des Benutzers wird von der Vertrauenskomponente 8 eingeholt;
– bei Zustimmung sendet die Vertrauenskomponente 8 eine Anfrage an den Server 1, dieses Mal außerhalb der den nicht-vertrauenswürdigen Anwendungen auferlegten Begrenzungen, indem sie die Referenz des Wortlauts hinzufügt und festlegt, dass der Benutzer wirklich seine Zustimmung gegeben hat (die Referenz kann optional sein, in welchem Fall die Vertrauenskomponente den Wortlaut der Frage in der in diesem Schritt übertragenen Anfrage wiederholt; allgemein genügt es, dass die gestellte Frage ausreichend in der an den Server übertragenen Mitteilung identifiziert ist, um die Zustimmung des Benutzers anzuzeigen);
– der Server 1 validiert die Anfrage, indem er überprüft, dass sie tatsächlich außerhalb der den nicht-vertrauenswürdigen Anwendungen auferlegten Begrenzungen empfangen wird, und antwortet auf diese Anfrage;
– die Antwort wird an die Anwendung übertragen, die die Frage initiiert hat.

Da man sich vergewissert hat, dass die direkt von der nicht-vertrauenswürdigen Anwendung 4 kommende Anfrage durch die Kontrollschicht 5 geht, bleibt der Server 1 sicher, dass die außerhalb der Begrenzungen liegenden Anfragen, die er von der Vertrauenskomponente 8 empfängt, sehr wohl von einer ausdrücklichen Zustimmung des Benutzers stammen.
In einer besonderen Ausführungsform der Erfindung verfügt das Endgerät über eine virtuelle Java-Maschine, die dem Modul 6 in der Darstellung der 1 und 2 entsprechen kann. Die virtuelle Maschine ermöglicht es, heruntergeladene Anwendungen auszuführen, die in der Programmiersprache Java geschrieben sind, die von der Firma Sun Microsystems, Inc. entwickelt wurde. Alle Befehle der Programmiersprache Java werden von der virtuellen Maschine ausgeführt, die die Systemfunktionen nach einer gewissen Kontrolle verwendet. Für die Java-Anwendungen befindet man sich tatsächlich in einer halb-offenen Umgebung, da die Systemfunktionen nicht ohne Kontrolle aufgerufen werden.
Die nicht-vertrauenswürdige Anwendung 4 wird dann in der Programmiersprache Java geschrieben.
In dieser Ausführungsform sind die für die Austauschvorgänge des Endgeräts 2 im Netz eingesetzten Protokolle die Protokolle HTTP (RFC 1945 ("Request For Comments"), veröffentlicht im Mai 1996 von der IETF ("Internet Engineering Task Force")), TCP (RFC 793, IETF, September 1981) und IP (RFC 791, IETF, September 1981). Die an die nicht-vertrauenswürdigen Anwendungen angewendete Begrenzung ist, dass sie keine Anfragen an die URL vom Typ: "http://<Server>/<Weg>/Zustimmung?<Folge>" richten können, wobei <Server> ein beliebiger Servername ist, <Weg> eine Folge von Buchstabenketten der Form "Repertoir_1/Repertoir_2/.../Repertoir_n", und <Folge> eine beliebige Buchstabenkette ist. Diese Begrenzung ist natürlich ein Beispiel, jede beliebige andere Begrenzung kann den Zweck erfüllen. Der Dienst ist in einem HTTP-Server untergebracht.
Die Vertrauenskomponente 8 kann dann durch die Klasse UserConfirmation in der virtuellen Java-Maschine implementiert werden. Sie ist ausgehend von den Anwendungen Java 4 über eine Klassenfunktion zugänglich: InputStream UserConfirmation.ask(String url, String question), deren Betrieb wie folgt ist. Wenn eine nicht-vertrauenswürdige Anwendung 4 die Funktion UserConfirmation.ask (String url, String question) aufruft:

– öffnet die Vertrauenskomponente 8 ein Fenster oder übernimmt die Kontrolle des Endgeräts über die gerade ausgeführte Anwendung;
– wird die Frage, deren Wortlaut durch die Buchstabenkette "Frage" angegeben wird, auf dem Bildschirm angezeigt, und dem Benutzer werden zwei Wahlmöglichkeiten vorgeschlagen, nämlich "OK" und "Annullieren";
– wenn der Benutzer zustimmt, indem er "OK" wählt: • sendet die Vertrauenskomponente 8 im Netz R die HTTP-Anfrage, die durch die Verkettung (i) der als Parameter angegebenen URL ("url"), (ii) der Kette "/Zustimmung?Frage=", (iii) des Wortlauts der an den Benutzer gestellten Frage (codiert im Codierformat in der URL x-www-urlencoded), und der Kette "&AntwortOK" gebildet wird. Dieses Verhalten ist natürlich nur ein Beispiel, das der Begrenzung entspricht, die an die von den Java-Anwendungen kommenden Anfragen angewendet wird. Für einen Server wird durch diese Kombination sichergestellt, dass die in diesem Stadium von der Vertrauenskomponente gesendeten Anfragen nicht von den Java-Anwendungen hätten gesendet werden können, was der Erfordernis entspricht; • wenn die Vertrauenskomponente 8 anschließend die Antwort vom Server 1 (oder eine Ausnahmebedingung, wenn der Server nicht verfügbar ist) empfängt, sendet sie an die anrufende Anwendung 4 ein Objekt InputStream zurück, das es dieser Anwendung ermöglicht, die Antwort des Servers zu erfahren;
– wenn der Benutzer nicht zustimmt, indem er "Annullieren" wählt: • sendet die Vertrauenskomponente 8 eine Ausnahmebedingung an die anrufende Anwendung 4 zurück.

Um diese besondere Ausführungsform zu veranschaulichen, wird der Fall betrachtet, in dem der Server einen Mikrozahlungsdiensts verwaltet, der für das Konto des Benutzers durch einfache Zustimmung dieses letzteren Online-Zahlungen ausführt. Die Zahlungen werden von einem dem Benutzer entsprechenden Konto abgebucht. Wenn er eine Zahlungsanweisung empfängt, will dieser Dienst also sichergehen, dass diese Anweisung wirklich vom Benutzer bestätigt wird und nicht von einem böswilligen Java-Programm kommt, das dem Benutzer keine Frage präsentiert hat, oder das ihm eine irreführende Frage präsentiert hat. Dieser Dienst ist natürlich ein Beispiel, da ein beliebiger anderer Dienst, der die Zustimmung des Benutzers anfordert, mit Hilfe dieser Technik ausgeführt werden kann (Veröffentlichung von Dokumenten, Dateiverwaltung, Mitteilungs-Übermittlung, usw.).
In diesem Beispiel kontrolliert der Zahlungsdienst die Webseite "Zahlung.com". Wenn eine nicht-vertrauenswürdige Anwendung dem Benutzer eine Zahlung vorschlagen möchte, ruft sie die Funktion UserConfirmation.ask auf, indem sie ihr als Parameter angibt:

• als URL: http://Zahlung.com/Zahlung
• als Fragewortlaut: "Zahlen
an Acme Co.?"

Die Vertrauenskomponente 8 übernimmt die Kontrolle des Endgeräts 2 und fragt den Benutzer "Zahlen
an Acme Co.? OK / Annullieren". Wenn der Benutzer das Link "OK" wählt, sendet die Vertrauenskomponente die Anfrage "http://Zahlung.com/Zahlung/Zustimmung?Frage=zahlen+
+an+Acme+Co.?&Antwort=K" und überträgt die Antwort des Servers an die aufrufende Anwendung 4, indem sie ihr die Kontrolle wieder übergibt.
Wenn der Benutzer das Link "Annullieren" wählt, sendet die Vertrauenskomponente 8 keine Anfrage und sendet eine Ausnahmebedingung auf die aufrufende Anwendung 4 zurück.
Wenn eine Anwendung 4 versucht, direkt die Seite "http://Zahlung.com/Zahlung/Zustimmung?Frage=zahlen+
+an+Acme+Co.?&Antwort=OK" anzufordern, wird diese Anfrage von der an die nicht-vertrauenswürdigen Anwendungen angewendete Begrenzung abgelehnt.
Als andere Veranschaulichung des erfindungsgemäßen Verfahrens wird der Fall betrachtet, in dem der Server einen E-Commerce-Dienst verwaltet. Im Rahmen eines solchen Diensts wird der Kunde dazu gebracht, ein Bestellungsformular auszufüllen. Dieses Formular soll gemäß dem Verfahren HTTP POST an die Adresse "http://Dienst.com/Bestellung gesendet werden.
Die Vertrauenskomponente kann dann in der virtuellen Java-Maschine implementiert werden. Sie ist zugänglich für die Java-Anwendungen durch eine Funktion "UserConfirmation.askForm(String url, byte[] Formular)".
Wenn diese Funktion von einer Java-Anwendung 4 aufgerufen wird, wird die Vertrauenskomponente 8:

• auf dem Bildschirm das in der Tabelle "Formular" enthaltene Formular anzeigen, das in Parameter der Funktion übergegangen ist. Dieses Formular liegt zum Beispiel in einem Format XML vor;
• den Benutzer die Felder des Formulars ausfüllen lassen und ihn auffordern, es zu validieren, indem er "OK" oder "Annullieren" am Ende des Formulars wählt;
• wenn der Benutzer das Formular validiert, eine Anfrage HTTP POST an die URL "url+/Zustimmung?" senden, wobei diese Anfrage das Formular, das dem Benutzer präsentiert wurde, sowie die Daten, die vom Benutzer in die verschiedenen Felder eingegeben wurden, enthält.

Wenn eine nicht-vertrauenswürdige Java-Anwendung 4 versucht, direkt auf die Adresse "url+/Zustimmung?" zuzugreifen, wird die Anfrage von der Kontrollschicht abgelehnt.
Außerdem könnte eine Anwendung versuchen, einen Benutzer in die Irre zu führen, indem sie ihn ein Formular ausfüllen lässt, das die gleichen Einträge wie das authentische Formular enthält, aber mit unterschiedlichen Wortlauten. Dieser Angriff wird ebenfalls durch die Tatsache vereitelt, dass das Formular an den Server 1 durch die Vertrauenskomponente 8 übertragen wird. Auf diese Weise kann der Server 1 nämlich überprüfen, ob das vom Benutzer ausgefüllte Formular tatsächlich ein legitimes Formular ist.
Um die Darlegung klarzustellen, wurde ein einfaches Beispiel einer Begrenzung genommen, die den nicht-vertrauenswürdigen Anwendungen aufgezwungen wird, nämlich, dass bestimmte URL nicht zugänglich sind, was zum Zeitpunkt des Sendens einer Anfrage geprüft wird. Es wäre aber jede andere Begrenzung akzeptabel.
Man kann insbesondere eine vollständige Blockierung jedes Zugriffs auf das Netz R für die nicht-vertrauenswürdigen Anwendungen 4, eine selektive Blockierung, die nur die Anfragen zur Webseite autorisiert, die der Ursprung einer heruntergeladenen Anwendung ist, usw. verwenden.
Die Begrenzung kann sich auch auf eine spezifische Markierung beziehen, die entweder den nicht-vertrauenswürdigen Anwendungen 4 oder den vertrauenswürdigen Anwendungen 3 zugeordnet ist. Jede von einer nicht-vertrauenswürdigen Anwendung 4 stammende Anfrage, die im Netz R an den Server 1 gesendet wird, wird dann von der Kontrollschicht 5 gezwungen:

/1/ entweder eine der Familie der nicht-vertrauenswürdigen Anwendungen zugeordnete Markierung zu enthalten,
/2/ oder keine der Familie der vertrauenswürdigen Anwendungen zugeordnete Markierung zu enthalten, wobei diese Markierung dann in zumindest bestimmten der Anfragen enthalten ist, die im Netz R gesendet werden und von vertrauenswürdigen Anwendungen stammen.

Im Fall /1/ fügt die Vertrauenskomponente 8 nicht die Markierung bei den Anfragen an, die gesendet werden, um die Zustimmung des Benutzers anzuzeigen, was dem Server 1 die Gewissheit gibt, dass diese Zustimmung tatsächlich vom Benutzer kommt. Die Vertrauenskomponente 8 kann dagegen die im Netz R gesendete Anfrage markieren, um den Wortlaut der zu stellenden Frage zu erhalten, wenn dieser Wortlaut nicht direkt durch die Anwendung 4 geliefert wird.
Umgekehrt fügt im Fall /2/ die Vertrauenskomponente 8 die Markierung bei den Anfragen an, die gesendet werden, um die Zustimmung des Benutzers anzuzeigen, und ggf. markiert sie nicht die Anfrage, die im Netz R gesendet wird, um den Wortlaut der zu stellenden Frage zu erhalten.
In dem Beispiel, in dem die Vertrauenskomponente 8 Teil einer virtuellen Java-Maschine 6 ist, besteht die Markierung des Falls /1/ zum Beispiel darin, dass das Vorspannfeld "User-Agent" der HTTP-Anfragen (siehe Sektion 10.15 der erwähnten RFC 1945) eine spezifische Kette wie "nicht-vertrauenswürdige Anwendung: VM Java 1.2" enthält, die durch ihr Vorhandensein anzeigt, dass die Anfrage nicht von einer vertrauenswürdigen Anwendung kommt. Eine umgekehrte Anmerkung kann im Fall /2/ vorgesehen werden.

Claims

Kommunikationsverfahren zwischen einer ersten Einheit (2) und einer zweiten Einheit (1) über ein Telekommunikationsnetz (R), bei dem die erste Einheit eine erste Familie von Anwendungen (4) und eine zweite Familie von Anwendungen (3) aufweist, die Kommunikationsfähigkeiten im Netz hat, die über die Kommunikationsfähigkeiten der Anwendungen der ersten Familie hinausgehen, wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist: /a/ eine Vertrauenskomponente (8), die zur zweiten Familie von Anwendungen gehört, erhält den Wortlaut einer an einen Benutzer der ersten Einheit zu stellenden Frage im Rahmen der Ausführung einer Anwendung (4) der ersten Familie; /b/ die Vertrauenskomponente präsentiert die Frage mittels einer Benutzerschnittstelle (9) und empfängt eine Antwort vom Benutzer; und /c/ für mindestens einen Typ von Antwort vom Benutzer überträgt die Vertrauenskomponente über das Netz mindestens eine Mitteilung an die zweite Einheit, die die präsentierte Frage identifiziert und die empfangene Antwort angibt, wobei die Mitteilung unter Bedingungen übertragen wird, die für die Anwendungen der ersten Familie unzugänglich sind.
Verfahren nach Anspruch 1, bei dem die präsentierte Frage in der Mitteilung des Schritts /c/ identifiziert wird, indem der Wortlaut der Frage in die Mitteilung eingefügt wird.
Verfahren nach Anspruch 1 oder 2, bei dem für mindestens einen anderen Antworttyp, der eine Zurückweisung des Benutzers bezüglich der präsentierten Frage ausdrückt, die Vertrauenskomponente (8) der Anwendung (4) der ersten Familie die Zurückweisung anzeigt.
Verfahren nach Anspruch 3, bei dem für den Antworttyp, der eine Zurückweisung des Benutzers bezüglich der präsentierten Frage ausdrückt, die Vertrauenskomponente (8) die Mitteilung des Schritts /c/ nicht an die zweite Einheit (1) überträgt.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die zweite Einheit (1) die Antwort des Benutzers bei Empfang der im Schritt /c/ übertragenen Mitteilung validiert, indem sie sicherstellt, dass sie tatsächlich unter Bedingungen übertragen wurde, die für die Anwendungen der ersten Familie unzugänglich sind.
Verfahren nach Anspruch 5, bei dem die zweite Einheit (1) nach Validierung der Antwort des Benutzers eine Antwort-Mitteilung über das Netz (R) an die Vertrauenskomponente (8) zurückschickt.
Verfahren nach Anspruch 6, bei dem die Vertrauenskomponente (8) der Anwendung (4) der ersten Familie den Gehalt der Antwort-Mitteilung anzeigt, die sie von der zweiten Einheit (1) empfangen hat.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Wortlaut der Frage der Vertrauenskomponente (8) im Schritt /a/ direkt von der Anwendung (4) der ersten Familie angezeigt wird.
Verfahren nach Anspruch 8, bei dem die Anwendung (4) der ersten Familie eine Adresse der zweiten Einheit (1) mit dem Wortlaut der Frage im Schritt /a/ anzeigt.
Verfahren nach einem der Ansprüche 1 bis 7, bei dem der Schritt /a/ die folgenden Unterschritte aufweist: /a1/ die Anwendung (4) der ersten Familie zeigt der Vertrauenskomponente (8) eine Adresse der zweiten Einheit (1) sowie eine vorzulegende Anfrage an, um den Wortlaut der Frage von der zweiten Einheit zu erhalten; /a2/ die Vertrauenskomponente sendet die Anfrage über das Netz (R) an die angezeigte Adresse; /a3/ die Vertrauenskomponente erlangt den Wortlaut der Frage in einer Antwort auf die Anfrage, die von der zweiten Einheit über das Netz zurückgeschickt wird.
Verfahren nach Anspruch 10, bei dem die Anfrage von der Vertrauenskomponente (8) im Unterschritt /a2/ unter Bedingungen gesendet wird, die für die Anwendungen der ersten Familie zugänglich sind.
Verfahren nach Anspruch 10 oder 11, bei dem die Antwort auf die Anfrage, die von der zweiten Einheit (1) zurückgeschickt wird, außerdem eine Referenz enthält, die die Vertrauenskomponente (8) speichert und dann in die im Schritt /c/ übertragene Mitteilung einfügt, um die präsentierte Frage zu identifizieren.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Anwendung (4) der ersten Familie ein Programm ist, das in der Programmiersprache Java geschrieben ist, und die Vertrauenskomponente (8) in eine virtuelle Java-Maschine (6) eingefügt ist, mit der die erste Einheit (2) versehen ist.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Anwendungen (3) der zweiten Familie die Fähigkeit haben, über das Netz (R) zu mindestens einer URL zu gelangen, die der zweiten Einheit (1) zugeordnet und für die Anwendungen (4) der ersten Familie unzugänglich ist.
Verfahren nach einem der Ansprüche 1 bis 13, bei dem die Anwendungen (4) der ersten Familie nicht in der Lage sind, ins Netz (R) zu gelangen.
Verfahren nach einem der Ansprüche 1 bis 13, bei dem die Anwendungen (4) der ersten Familie in einem bestimmten Transferprotokoll die Fähigkeit haben, nur zu einer einzigen fernen Internetseite zu gelangen, die nicht die zweite Einheit (1) aufweist.
Verfahren nach einem der Ansprüche 1 bis 13, bei dem jede von einer Anwendung (4) der zweiten Familie stammende und über das Netz (R) an die zweite Einheit (1) gesendete Anfrage gezwungen wird, eine Markierung zu enthalten, die der zweiten Familie von Anwendungen (3) zugeordnet ist.
Verfahren nach einem der Ansprüche 1 bis 13, bei dem jede von einer Anwendung (4) der zweiten Familie stammende und über das Netz (R) an die zweite Einheit (1) gesendete Anfrage gezwungen wird, keine der ersten Familie zugeordnete Markierung zu enthalten, wobei die Markierung in zumindest manchen der über das Netz gesendeten und von Anwendungen (3) der ersten Familie stammenden Anfragen enthalten ist.
Verfahren nach Anspruch 17 oder 18, bei dem die Anfragen HTTP-Anfragen enthalten und die Markierung in die Vorspanne der HTTP-Anfragen eingefügt ist.
Software-Vertrauenskomponente für eine erste Einheit (2), die in der Lage ist, über ein Telekommunikationsnetz (R) mit einer zweiten Einheit (1) zu kommunizieren, wobei die erste Einheit eine erste Familie von Anwendungen (4) und eine zweite Familie von Anwendungen (3) aufweist, die Kommunikationsfähigkeiten im Netz hat, die über die Kommmunikationsfähigkeiten der Anwendungen der ersten Familie hinausgehen, wobei die Vertrauenskomponente (8) zur zweiten Familie von Anwendungen gehört und Anweisungen enthält, um bei einer Ausführung der Komponente in der ersten Einheit die Schritte eines Verfahrens nach einem der Ansprüche 1 bis 19 zu steuern.
Kommunikationsterminal, das eine Software-Vertrauenskomponente nach Anspruch 20 enthält, um über ein Telekommunikationsnetz (R) mit einer fernen Einheit (1) zu kommunizieren.