-
Die
Erfindung betrifft drahtlose Datenkommunikationen und betrifft insbesondere
sichere leichtgewichtige Transaktionen zwischen mobilen Vorrichtungen
und Landleitungsservern bzw. Festnetz-Servern oder drahtlosen Datennetzwerken;
wobei die mobilen Vorrichtungen bzw. Mobilfunk-Vorrichtungen eine
sehr beschränkte
Fähigkeit
für eine Rechenleistung,
einen Speicher und eine graphische Anzeige haben.
-
Ein
schnell wachsender Trend im Internet ist der elektronische Handel.
Der elektronische Handel ist ein integriertes Konzept, das entwickelt
ist, um einen weiten Bereich von Geschäftsunterstützungsdiensten, von Handel-Unterstützungssystemen
für Waren
bzw. Artikel, Produkte, an Kunden angepasste Produkte und für Kunden
gebildete Güter
und Dienste; von Bestell- und Logistik-Unterstützungssystemen; von Einstell-Unterstützungssystemen;
und von Systemen für
Managementinformation und für
ein statistisches Berichten zusammenzuziehen, und zwar alle über das
Internet. Es ist jedoch wohlbekannt, dass das Internet ein weites
offenes öffentliches
und internationales Netzwerk von miteinander verbundenen Computern
und elektronischen Vorrichtungen auf der ganzen Welt ist. Jemand,
der einen Zugriff auf einen Computer im Netzwerk hat, kann Signale
abfangen, die Eigentümerinformation
tragen, die über
das Netz laufen. Zum Abwickeln von Geschäften über das offene Netzwerk müssen Firmen oder
Individuen eine effiziente, zuverlässige und gesicherte Weise
zum Durchführen
von privaten Kommunikationen dazwischen haben. Somit wird Sicherheit
eine primäre
Sorge bezüglich
des offenen Internets, und es hat viele fortgesetzte Anstrengungen
gegeben, die auf ein Schützen
der Eigentumsinformation abzielten, die im Internet läuft. Eine
der Anstrengungen besteht im Verwenden von Kryptographie-Techniken
zum Sichern einer privaten Kommunikation zwischen zwei Parteien.
Die Kryptographie-Techniken stellen eine Art zum Senden von Information über einen
nicht vertrauenswürdigen
Kommunikationskanal zur Verfügung,
ohne die Inhalte der Information irgendjemandem zu offenbaren, der
auf den Kommunikationskanal zugreift.
-
Das
US-Patent Nr. 5,671,279 von Taher Elgamal offenbart ein elektronisches
Kurier-Bezahlungssystem
zum Durchführen
des elektronischen Handels unter Verwendung eines sicheren Kuriersystems.
Das System beherrscht die Beziehung zwischen einem Kunden, einem
Händler
und einem Erwerber-Gateway zum Durchführen von Kreditkartenverkäufen über das
offene Netzwerk durch Verwenden einer sicheren Verbindung, um das
Problem der auf dem Internet basierenden finanziellen Transaktionen
zu vereinfachen. Die internationale Dienstvereinigung VISA stellt
in Zusammenarbeit mit Microsoft Corporation eine gesicherte Transaktionstechnologie unter
Verwendung einer digitalen Signatur zum Authentifizieren einer Kreditkarte
und eines Händlerhinweises
zur Verfügung,
siehe für
Details http://www.visa.com. Die von RSA Data Security, Inc. entwickelten Technologien
sind der globale heutige Standard für eine Verschlüsselung
mit einem öffentlichen
Schlüssel
und eine digitale Signatur und können
ein Teil von existierenden und vorgeschlagenen Standards für das Internet
sowie für
Geschäfts-
und Finanz-Netzwerke auf der ganzen Welt sein. Mehr Information über die
Internetsicherheit kann unter http://www.rsa.com gefunden werden.
-
Die
obigen und weitere laufende Anstrengungen sind alle primär auf das
Internet gerichtet, das eine Vielzahl von landgebundenen oder verdrahteten
Netzwerken ist. Zum Verwenden des Internets muss man einen physikalischen
Zugriff auf einen Computer haben, der mit dem Netzwerk verdrahtet ist.
Zum Bereitstellen der Mobilität
des Netzwerks wurden drahtlose Datennetzwerke eingeführt, so dass
die landgebundenen Netzwerke ein integraler Teil der drahtlosen
Datennetzwerke werden. Mit den drahtlosen Datennetzwerken sind Leute,
wenn sie reisen oder sich bewegen, dazu fähig, über drahtlose Rechenvorrichtungen
oder in der Hand gehaltene Kommunikationsvorrichtungen genau dieselben
Aufgaben durchzuführen,
wie sie es mit Computern in Landleitungsnetzwerken bzw. landgebundenen
Netzwerken bzw. Festnetzen durchführen könnten. Gleich dem Internet
liefert jedoch die Natur der drahtlosen Kommunikationen eine Gelegenheit
für eine
Störung, da
die mobilen Daten durch die Luft gesendet werden. Jemand, der einen
geeigneten Empfänger
mit einer entwickelten Antenne hat, kann Signale abfangen, die zwischen
einer drahtlosen Rechenvorrichtung und einer Festnetz-Basisstation
oder einem festen Netz kommuniziert werden. Eine Privatheit, eine Authentifizierung,
eine Autorisierung und eine Integrität bzw. Unversehrtheit werden
somit als die wichtigsten Elemente in einem drahtlosen Datennetzwerk
erachtet. Daher sind zusätzliche
Anstrengungen begonnen worden, um sicherzustellen, dass die Eigentumsinformation über drahtlose
Netzwerke gesendet wird, die nur auf diejenigen beschränkt werden
muss, die sie kennen müssen.
-
Viele
Netzwerke verwenden eine Verschlüsselung
und andere Sicherungsmaßnahmen
zum Schützen
von mobilen Daten vor einem Zugriff durch eine nicht autorisierte
dritte Partei. Bestimmte Technologien und Zugriffsverfahren tragen
zur Netzwerksicherheit bei. Beispielsweise ist die Spreizspektrumstechnologie
in sich sicher, aber sie sorgt nur für eine Sicherheit auf einer
Verbindungsebene. Es gibt keine Garantie, dass eine mobile Vorrichtung
eine sichere Kommunikation zu einer Festnetzvorrichtung durch ein
vollständiges
drahtloses Netzwerk hat, das allgemein ein Luftnetz, das Internet
und ein Gateway dazwischen aufweist. Das US-Patent Nr. 5,604,806 von
Hassan, et al. offenbart eine Vorrichtung und ein Verfahren für eine sichere
Funkkommunikation durch Verwenden von Schlüsselsequenzen, die aus der Kurzzeit-Reziprozität und einer
Funkraum-Dekorrelation einer Phase des Funkkanals abgeleitet sind.
Das US-Patent 5,371,794 von DIFFIE et al. zeigt ein weiteres Verfahren
und eine weitere Vorrichtung zum Bereitstellen einer sicheren Kommunikation
zwischen einer mobilen drahtlosen Datenverarbeitungsvorrichtung
und einer Basis-Datenverarbeitungsvorrichtung.
Die mobile Vorrichtung sendet der Basisvorrichtung ein digital signiertes
wechselseitig vertrauensvolles Zertifikat gemäß einem öffentlichen Verschlüsselungsschlüssel und
die Basisvorrichtung sendet eine modifizierte Version zu der mobilen
Vorrichtung auf ein erfolgreiches Wiedergewinnen des Zertifikats
hin. Wenn die mobile Vorrichtung die modifizierte Version wiedergewinnt,
treten beide Vorrichtungen in eine sichere Datenkommunikation ein.
Das offenbarte System von DIFFIE kann gut bei mobilen Vorrichtungen
arbeiten, die sich widersprechende Rechenbetriebsmittel haben, um
die auf einem öffentlichen
Schlüssel
basierende Verschlüsselungsgeschwindigkeit
zu erfüllen.
Nichts desto weniger ist die Verbin dungszeit in einem Luftnetz teuer
bemaßt, und
viele mobile Vorrichtungen, wie beispielsweise Mobilfunktelefone,
haben einen gleichen Bruchteil der Rechenbetriebsmittel, die in
einem typischen Tischrechner oder einem tragbaren Computer bzw. Laptop
vorgesehen sind. Die Rechenleistung in einem typischen zellularen
Telefon ist kleiner als ein Prozent von derjenigen, die es in einem
regulären Tischrechnercomputer
gibt, die Speicherkapazität davon
ist allgemein kleiner als 250 Kilobyte, und die LCD-Anzeige ist
vielleicht vier Linien hoch und hat 12 oder 20 Zeichen, und die
Graphikfähigkeiten
davon sind sehr beschränkt
oder nahezu nicht existent. Es hat somit eine große Notwendigkeit
für eine
allgemeine Lösung
gegeben, die eine sichere Kommunikation mit einer sich widersprechenden
Leistungsfähigkeit zwischen
mobilen Vorrichtungen mit beschränkten Rechenbetriebsmitteln
und Festnetzvorrichtungen durch ein offenes Netzwerk zur Verfügung stellt.
-
Weiterhin
arbeiten viele gegenwärtige
Netzwerke basierend auf dem Hypertext-Übertragungsprotokoll
(HTTP), das auf dem Übertragungssteuerungsprotokoll/Internetprotokoll
(TCP/IP = Transmission Control Protocol/Internet Protocol) aufgebaut
ist. Aber das TCP-Protokoll erfordert eine beachtliche Rechenleistung
und beachtliche Netzwerk-Bandbreitenressourcen. Eine einzige Verbindung
kann beispielsweise einen Austausch von mehr als zehn Paketen zwischen
einem Sender und einem Empfänger im
Internet erfordern. Daher hat es weiterhin eine Notwendigkeit für ein allgemeines
Verfahren und ein allgemeines System gegeben, die eine sichere Kommunikation
zwischen mobilen Vorrichtungen und landgebundenen Vorrichtungen
unter Verwendung einer geringeren Anzahl von Paketen zur Verfügung stellen,
um eine Übertragungseffizienz
in mobilen Vorrichtungen mit beschränkten Rechenbetriebsmitteln
bzw. Rechenressourcen zu erhöhen.
-
Gemäß einem
Aspekt der Erfindung ist ein Verfahren zum Aufbauen einer authentifizierten
und sicheren Kommunikationssession für Transaktionen zwischen einem
Klienten und einem Server über
ein drahtloses Datennetzwerk zur Verfügung gestellt, wobei der Klient
in Bezug auf den Server entfernt angeordnet ist, wobei das Verfahren
folgendes aufweist:
Senden eines Session-Anforderungssignals
vom Klienten über
das drahtlose Datennetzwerk zum Server, wobei das Session-Anforderungssignal
eine Klientennachricht enthält,
die gemäß einem
gemeinsam genutzten geheimen Verschlüsselungsschlüssel verschlüsselt ist,
der zuvor auf sowohl dem Klienten als auch dem Server liegt;
Durchführen eines
ersten Schritts einer Klientenauthentifizierung beim Server durch
Prüfen
auf die erfolgreiche Entschlüsselung
der verschlüsselten
Klientennachricht gemäß dem gemeinsam
genutzten geheimen Verschlüsselungsschlüssel;
Erzeugen
eines Sessionsschlüssels
für die
Session, einer ersten Ableitung der entschlüsselten Klientennachricht und
einer Servernachricht beim Server, wenn der erste Schritt der Klientenauthentifizierung erfolgreich
ist;
Senden eines Session-Antwortsignals vom Server zum Klienten über das
drahtlose Datennetzwerk, wobei das Session-Antwortsignal den Sessionschlüssel, die
erste Ableitung der entschlüsselten
Klientennachricht und die Servernachricht enthält, die gemäß dem gemeinsam genutzten geheimen
Verschlüsselungsschlüssel verschlüsselt sind;
Durchführen eines
ersten Schritts einer Serverauthentifizierung beim Klienten durch
Prüfen
auf die erfolgreiche Entschlüsselung
des verschlüsselten Session-Antwortsignals gemäß dem gemeinsam
genutzten geheimen Verschlüsselungsschlüssel und Wiedergewinnen
der ersten Ableitung der entschlüsselten
Klientennachricht und der Servernachricht;
Durchführen eines
zweiten Schritts der Serverauthentifizierung beim Klienten durch
für Gültigerklären der
ersten Ableitung der Klientennachricht mit der im Session-Anforderungssignal
enthaltenen Klientennachricht;
Erzeugen einer ersten Ableitung
der entschlüsselten Servernachricht
beim Klienten, wenn die Serverauthentifizierung erfolgreich ist;
Senden
eines Session-Beendigungssignals vom Klienten über das drahtlose Datennetzwerk
zum Server, wobei das Session-Beendigungssignal die erste Ableitung
der entschlüsselten
Servernachricht enthält, wobei
die erste Ableitung gemäß dem gemeinsam genutzten
geheimen Verschlüsselungsschlüssel verschlüsselt ist;
Durchführen eines
zweiten Schritts der Klientenauthentifizierung beim Server durch
für Gültigerklären der
ersten Ableitung der entschlüsselten
Servernachricht mit der im Session-Antwortsignal enthaltenen Servernachricht;
und
Aufbauen einer authentifizierten und sicheren Kommunikationssession,
wenn der zweite Schritt der Klientenauthentifizierung erfolgreich
ist.
-
Auf
das Aufbauen der sicheren Kommunikation zwischen dem Klienten und
dem Server hin kann entweder der Klient oder der Server eine Transaktion dazwischen
initiieren. Zum Sichern der Transaktion zwischen einer gültigen Session
wird die Transaktion durch einen wechselseitig akzeptierten Schlüssel bzw.
eine wechselseitig akzeptierte Verschlüsselung gemäß dem Sessionschlüssel verschlüsselt und durch
eine darin eingebettete Session-ID identifiziert. Der wechselseitig
akzeptierte Schlüssel
kann durch den Server über
eine Schlüsselverhandlung
mit dem Klienten erhalten werden, und die Transaktions-ID in der
Transaktion wird immer im Server untersucht, bevor der Server dem
Klienten mit einer Serviceantwort antwortet. Auf ein Empfangen der
Serviceantwort vom Server hin kann der Klient mit der Transaktion mit
dem Server fortfahren.
-
Vorzugsweise
enthält
das Session-Anforderungssignal weiterhin eine modifizierte Version
der Klientennachricht, die gemäß dem gemeinsam
genutzten geheimen Verschlüsselungsschlüssel verschlüsselt ist;
wobei die modifizierte Version eine betriebsmäßige Beziehung zu der Klientennachricht hat.
-
Bei
einem Ausführungsbeispiel
hat die erste Ableitung der Klientennachricht eine mathematische Beziehung
zu der Klientennachricht.
-
Herkömmlich weist
die Klientennachricht eine Klienten-ad-hoc-Bildung auf.
-
Angenehmerweise
wird das Session-Beendigungssignal durch die Transaktionsanforderung vom
Klienten im Huckepack getragen.
-
Bei
einem Ausführungsbeispiel
ist die Transaktionsanforderung gemäß dem Sessionschlüssel verschlüsselt, der
im Session-Antwortsignal enthalten ist.
-
Bei
einem bevorzugten Ausführungsbeispiel enthält das Session-Anforderungssignal
weiterhin einen Vorrichtungsidentifizierer, der zum Klienten gehört, und
wobei der Server den gemeinsam genutzten geheimen Verschlüsselungsschlüssel basierend auf
dem Vorrichtungsidentifizierer bestimmt.
-
Es
ist bevorzugt, dass das Session-Anforderungssignal einen Klientenschlüssel enthält, der
anzeigt, welche Verschlüsselung
der Klient gegenwärtig verwendet.
-
Es
wird offensichtlich sein, dass das Verfahren weiterhin den Schritt
der Serververhandlung eines wechselseitig akzeptierten Schlüssels mit
dem Klienten für
die Session aufweisen kann.
-
Gemäß einem
weiteren Aspekt der vorliegenden Erfindung ist eine Vorrichtung
zum Aufbauen einer authentifizierten und sicheren Kommunikationssession
für Transaktionen
mit einem Server über ein
drahtloses Datennetzwerk zur Verfügung gestellt, wobei der Server
in Bezug auf die Vorrichtung entfernt angeordnet ist, wobei die
Vorrichtung folgendes aufweist:
einen Anzeigeschirm;
einen
Speicher zum Speichern eines Codes für ein Klientenmodul;
einen
Prozessor, der mit dem Speicher gekoppelt ist, wobei der Prozessor
den Code in dem Speicher ausführt,
um das Klientenmodul zu folgendem zu veranlassen:
ein Session-Anforderungssignal über das
drahtlose Datennetzwerk zum Server zu senden, wobei das Session-Anforderungssignal
eine Klientennachricht enthält,
die gemäß einem
gemeinsam genutzten geheimen Verschlüsselungsschlüssel verschlüsselt ist, der
zuvor auf sowohl der Vorrichtung als auch dem Server sitzt;
einen
ersten Schritt einer Serverauthentifizierung durch Prüfen auf
die erfolgreiche Entschlüsselung
eines Session-Antwortsignals durchzuführen, das vom Server in Antwort
auf das Session-Anforderungssignal empfangen wird, das gemäß dem gemeinsam
genutzten geheimen Verschlüsselungsschlüssel verschlüsselt ist,
und durch Wiedergewinnen einer ersten Ableitung der Klientennachricht
und einer Servernachricht;
einen zweiten Schritt der Serverauthentifizierung beim
Klienten durchzuführen,
durch für
gültig
Erklären
der entschlüsselten
ersten Ableitung der Klientennachricht, wobei die Klientennachricht
im Session-Anforderungssignal
enthalten ist;
eine erste Ableitung der entschlüsselten
Servernachricht zu erzeugen, wenn die Serverauthentifizierung erfolgreich
ist; und
ein Session-Beendigungssignal zum Server über das drahtlose
Datennetzwerk zu senden, wobei das Session-Beendigungssignal die
erste Ableitung der entschlüsselten
Servernachricht enthält,
wobei die erste Ableitung gemäß dem gemeinsam
genutzten geheimen Verschlüsselungsschlüssel verschlüsselt ist.
-
Vorzugsweise
enthält
das Session-Anforderungssignal weiterhin eine modifizierte Version
der Klientennachricht, die gemäß dem gemeinsam
genutzten geheimen Ver schlüsselungsschlüssel verschlüsselt ist;
wobei die modifizierte Version eine betriebsmäßige Beziehung zu der Klientennachricht hat.
-
Bei
einem Ausführungsbeispiel
hat die erste Ableitung der Klientennachricht eine mathematische Beziehung
zu der Klientennachricht.
-
Angenehmerweise
weist die Klientennachricht eine Klienten-ad-hoc-Bildung auf.
-
Bei
einem weiteren bevorzugten Ausführungsbeispiel
veranlasst der Prozessor das Klientenmodul, eine Transaktionsanforderung
auf dem Session-Beendigungssignal im Huckepack zu tragen.
-
Bei
einem Ausführungsbeispiel
veranlasst der Prozessor das Klientenmodul, die Transaktionsanforderung
gemäß dem Sessionschlüssel zu
verschlüsseln,
der im Session-Antwortsignal enthalten ist.
-
Bei
einem weiteren Ausführungsbeispiel
enthält
das Session-Anforderungssignal weiterhin einen Vorrichtungsidentifizierer,
so dass der Server den gemeinsam genutzten geheimen Verschlüsselungsschlüssel basierend
auf dem Vorrichtungsidentifizierer bestimmen kann.
-
Angenehmerweise
enthält
das Session-Anforderungssignal einen Klientenschlüssel, der
anzeigt, welche Verschlüsselung
die Vorrichtung gegenwärtig
verwendet.
-
Demgemäß ist es
eine wichtige Aufgabe der vorliegenden Erfindung, eine allgemeine
Lösung
für eine
sichere leichtgewichtige Transaktion in drahtlosen Datennetzwerken
zur Verfügung
zu stellen. Andere Aufgaben zusammen mit den vorangehenden werden
bei der Ausführung
der Erfindung in der folgenden Beschreibung und resultierend in
dem in den beigefügten
Zeichnungen dargestellten Ausführungsbeispiel
erhalten.
-
Diese
und andere Merkmale, Aspekte und Vorteile der vorliegenden Erfindung
werden angesichts der folgenden Beschreibung, der beigefügten Ansprüche und
der beigefügten
Zeichnungen besser verstanden werden, wobei:
-
1 eine schematische Darstellung
eines Mobilfunk-Datennetzes zeigt, bei welchem die vorliegende Erfindung
ausgeführt
werden kann;
-
2 ein Blockdiagramm eines
typischen digitalen zellularen GSM-Telefons zeigt, das bei dem Ausführungsbeispiel
der offenbarten Erfindung verwendet wird;
-
3 den Prozess einer wechselseitigen Authentifizierung
zwischen einem Klienten und einem Server darstellt;
-
4a und 4b ein Datenablaufdiagramm zeigen, das
jeweils den Session-Erzeugungsprozess
im Klienten und im Server darstellt, und zwar der 3 bei einem Ausführungsbeispiel der vorliegenden
Erfindung;
-
5 ein schematisches Diagramm
einer Servicetransaktion bzw. Diensttransaktion zeigt;
-
6 ein schematisches Diagramm
einer Benachrichtigungstransaktion zeigt; und
-
7 ein schematisches Diagramm
einer Posttransaktion zeigt.
-
Die
detaillierte Beschreibung der vorliegenden Erfindung im Folgenden
wird großenteils
in einer Datenablaufdarstellung präsentiert, die den Operationen
von Datenverarbeitungsvorrichtungen ähnelt, die an Netzwerke gekoppelt
sind. Diese Prozessbeschreibungen und -darstellungen sind die Mittel,
die von Fachleuten auf dem Gebiet verwendet werden, um die Substanz
ihrer Arbeit anderen Fachleuten auf dem Gebiet am effektivsten zu übermitteln.
Die vorliegende Erfindung ist ein Verfahren und ein System für sichere
Datenkommunikationen. Das Verfahren zusammen mit dem System oder
der Architektur, die nachfolgend detailliert beschrieben werden,
ist eine in sich konsistente Sequenz von Schritten, die zu einem
erwünschten
Ergebnis führen.
Diese Schritte oder Prozesse sind diejenigen, die physikalische
Manipulationen von physikalischen Größen erfordern. Normalerweise,
obwohl es nicht nötig
ist, können
diese Größen die
Form von elektrischen Signalen annehmen, die dazu fähig sind,
gespeichert, transferiert bzw. übertragen,
kombiniert, verglichen, angezeigt oder auf andere Weise manipuliert
zu werden. Es erweist sich manchmal als angenehm, und zwar grundsätzlich aus
Gründen
einer allgemeinen Anwendung, diese Signale als Bits, Werte, Elemente,
Symbole, Operationen, Nachrichten, Ausdrücke, Nummern bzw. Zahlen oder ähnliches
zu bezeichnen. Es sollte im Gedächtnis
behalten werden, dass alle dieser ähnlichen Ausdrücke mit
den geeigneten physikalischen Größen zu verbinden
sind und lediglich angenehme Bezeichnungen sind, die auf diese Größen angewendet
sind.
-
Nun
wird auf die Zeichnungen Bezug genommen, in welchen gleiche Bezugszeichen
in allen mehreren Ansichten gleiche Teile bezeichnen. 1 zeigt eine schematische
Darstellung eines drahtlosen Datennetzwerks 100, in welchem
die vorliegende Erfindung ausgeführt
werden kann. Das Datennetzwerk 100 weist ein Luftnetz 102 und
das Festnetz 104 auf, wobei jedes als ein Kommunikationsmedium für eine Datenübertragung
dort hindurch wirkt. Das Festnetz 104 kann das Internet,
das Intranet oder ein anderes privates Netz sein. Der Einfachheit
halber wird das Festnetz 104 hierin einfach das Internet
genannt werden, was wörtlich
entweder das Internet oder das Intranet oder ein anderes privates
Netz bedeutet. Weiterhin wird das Luftnetz 102, das ein
nicht verdrahtetes Netz bedeutet, in welchem eine Datenübertragung über die
Luft erfolgt, manchmal als Trägernetz
bezeichnet, weil jedes Luftnetz durch einen Träger gesteuert und betrieben
wird, wie beispielsweise von AT & T
und GTE, von welchen jeder sein eigenes Kommunikationsschema hat,
wie beispielsweise CDPD, CDMA, GSM und TDMA. Mit 106 ist eine
mobile Datenvorrichtung bezeichnet, die aber einem Mobilfunk-Telefon ähnelt, und
zwar in Kommunikation mit dem Luftnetz 102 über eine
Antenne 104. Es wird allgemein verstanden, dass das Luftnetz 102 gleichzeitig
mit einer Vielzahl von mobilen Rechenvorrichtungen kommuniziert,
von welchen ein Mobilfunk-Telefon 106 in der Figur gezeigt
ist. Gleichermaßen
ist eine Vielzahl von Tischrechner-PCs 110 und eine Vielzahl
von Web-Servern 112 mit dem Internet 104 verbunden,
obwohl nur jeweils ein Repräsentant in
der Figur gezeigt ist. Der PC 110, wie er in der Figur
gezeigt ist, kann ein Personalcomputer SPL 300 von NEC
Technologies Inc. sein und lässt
einen Web-Browser über
das Internet 104 laufen, um auf Information zuzugreifen,
die im Web-Server 112 gespeichert ist, der eine Workstation
von SUN Microsystems Inc. sein kann. Es wird von Fachleuten auf dem
Gebiet verstanden, dass der PC 110 Information speichern
kann, auf die zugegriffen werden kann, um ebenso gut ein Web-Server
zu werden. Zwischen dem Internet 104 und dem Luftnetz 102 gibt
es einen Verbindungsserver 114, der eine Datenkommunikation
zwischen dem Internet 104 und dem Luftnetz 102 durchführt. Der
Verbindungsserver 114, der auch als Verbindungs-Proxi oder
Gateway bezeichnet wird, kann eine Workstation oder ein Personalcomputer sein,
und er führt
eine Protokollabbildung von einem Kommunikationsprotokoll zu einem
anderen durch, und dadurch kann eine mobile Vorrichtung 106 in Kommunikation
mit jeweils einem der Web-Server 112 oder der PCs 110 sein.
-
Das
Kommunikationsprotokoll im Internet 104 ist HTTP, das auf
dem TCP läuft,
und das die Verbindung eines HTML-Web-Browsers zu einem Web-Server
und den Austausch von Information zwischen steuert. Eine erweiterte
Version davon, die HTTPS genannt wird, liefert eine verschlüsselte Authentifizierung
und eine Sessionübertragung
zwischen einem Klienten und einem Server. Das Kommunikationsprotokoll
zwischen der mobilen Vorrichtung 106 und dem Verbindungsserver 114 über das Luftnetz 102 ist
ein Transportprotokoll für
eine in der Hand gehaltene Vorrichtung (HDTP = Handheld Device Transport
Protocol) oder ein sicheres Aufwärtsstrecken-Gatewayprotokoll
(SUGP = Secure Uplink Gateway Protocol), das vorzugsweise auf einem
Anwender-Datengramprotokoll (UDP = User Datagram Protocol) läuft und
die Verbindung eines HDML-Web-Browsers mit einem Verbindungsserver steuert,
wobei HDML für
Hand Held Markup Language steht. Die Spezifikation davon und die
HDTP-Spezifikation
sind unter http://www.w3.org oder http://www.uplanet.com zur Verfügung gestellt,
die hierin durch Bezugnahme enthalten sind. Weiterhin ist eine Referenzspezifikation
mit dem Titel "Magellan SUGP
Protokoll" hierin
durch Bezugnahme enthalten. Das HDTP ist ein Sessionpegelprotokoll,
das dem HTTP ähnelt,
aber ohne ein Auftreten des Zusatzes davon, und ist äußerst optimiert
für eine
Anwendung in mobilen Vorrichtungen, die signifikant weniger Rechenleistung
und Speicher haben. Weiterhin wird von Fachleuten auf dem Gebiet
verstanden, dass das UDP nicht erfordert, dass eine Verbindung zwischen
einem Klienten und einem Server aufzubauen ist, bevor Information
ausgetauscht werden kann, was die Notwendigkeit eines Austauschens
einer großen
Anzahl von Paketen während
einer Sessionerzeugung eliminiert. Ein Austauschen einer sehr geringen
Anzahl von Paketen während
einer Transaktion ist eines der wünschenswerten Merkmale für eine mobile
Vorrichtung mit sehr beschränkter Rechenleistung
und sehr beschränktem
Speicher zum effektiven Interagieren mit einer Festnetzvorrichtung.
-
Gemäß einem
bevorzugten Ausführungsbeispiel
kann die vorliegende Erfindung mit einem zellularen Telefon ausgeführt werden,
welches ein typisches Beispiel für
die mobile Vorrichtung 106 ist, die eine sehr beschränkte Rechenleistung
und einen sehr beschränkten
Speicher hat. Das zellulare Telefon 106 wird als Klient
bei einer Kommunikation mit einer Festnetzvorrichtung verwendet,
die oft Server genannt wird, der Information, auf welche zugreifbar ist,
darin zu anderen Vorrichtung zur Verfügung stellt. 2 zeigt ein Blockdiagramm eines typischen
digitalen zellularen GSM-Telefons 120.
Jede der Hardwarekomponenten im zellularen Telefon 120 ist Fachleuten
auf dem Gebiet bekannt, und somit sind die Hardwarekomponenten hierin
nicht detailliert zu beschreiben. Obwohl die Anwenderschnittstelle
des Telefons 120 in der Figur nicht gezeigt ist, kann auf die
mobile Vorrichtung 118, die einem zellularen Telefon ähnelt, in 1 Bezug genommen werden,
wobei mit 116 ein LCD-Schirm und mit 118 ein Tastenknopffeld
bezeichnet ist. Durch den Schirm 116 und das Tastenfeld 118,
die durch einen Anwender des Telefons gesteuert werden, kann das
Telefon in eine interaktive Kommunikation mit einem Server über das
Luftnetz, den Verbindungsserver und das Internet in Kommunikation
versetzt werden. Gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung sind kompilierte und gebundene Prozesse
der vorliegenden Erfindung in einem ROM 122 als Klientenmodul 124 und
Unterstützungsmodul 126 gespeichert. Auf
eine Aktivierung einer vorbestimmten Tastensequenz unter Verwendung
des Tastenfelds 118 hin initiiert ein Prozessor einer physikalischen
Schicht oder eine Mikrosteuerung 118 eine Sessionkommunikation
zum Server unter Verwendung des Moduls 124 im ROM 122.
-
Zum
Aufbauen einer gesicherten Kommunikation zwischen einem Klienten
und einem Server muss zuerst ein Authentifizierungsprozess durchgeführt werden,
um sicherzustellen, dass nur interessierte Parteien tatsächlich in
der Kommunikation zwischen ihnen sind. Der Prozess wird über zwei
Runden von unabhängigen
Authentifizierungen beendet, von welchen eine im Authentifizieren
des Klienten durch den Server betrifft, die als Klientenauthentifizierung
bezeichnet wird, und die andere die Authentifizierung des Servers
durch den Klienten betrifft; die als Serverauthentifizierung bezeichnet
wird. Weiterhin wird jede Authentifizierung in zwei getrennten Schritten
für ein
hohes Maß an
Sicherheit beendet, was nachfolgend detailliert beschrieben wird.
Der Erfolg der wechselseitigen Authentifizierungsprozesse liefert
einen Beweis dafür,
dass die zwei kommunizierenden Parteien einen gültigen gemeinsam genutzten
geheimen Verschlüsselungsschlüssel besitzen, und
zwar über
eine wechselseitige Entschlüsselung und
einen Anforderung/Antwort-Mechanismus. Der wechselseitige Entschlüsselungsmechanismus
weist die Schritte zum wechselseitigen Entdecken von verschlüsselten
Nachrichten von zwei beteiligten kommunizierenden Parteien auf.
Der Anforderung/Antwort-Mechanismus, der ad-hoc-Bildungsverifizierung ge nannt
wird, verifiziert eine vorbestimmte Beziehung zwischen einer gesendeten
ad-hoc-Bildung und einer
empfangenen Ableitung davon.
-
Bei
einem bevorzugten Ausführungsbeispiel der
vorliegenden Erfindung wird der Authentifizierungsprozess mit drei
Nachrichtenaustauschungen durchgeführt: einer Sessionanforderung
(SR = Session Request), einer Sessionantwort (SP = Session rePly)
und einer Sessionbeendigung (SC = Session Completion). 3 stellt eine schematische
Darstellung des Authentifizierungsprozesses dar. Der Klient 140,
der eine mobile Vorrichtung darstellt, initiiert zum Durchführen einer
Transaktion mit einem Server 142, der einen Festnetzserver
oder einen PC darstellt, eine SR 144, die zum Server 142 zu
senden ist, indem zuerst eine Klienten-Protosession erzeugt wird.
Eine Klienten-Protosession ist eine Session-Datenstruktur, die initialisiert
wird, wenn eine Sessionerzeugung startet. Die initialisierte SR 144 weist die
folgende Information auf:
Session-ID – einen Identifizieren, der
alle Anforderungen vom Klienten zum Server identifiziert; im Fall einer
Anforderung einer Sessionerzeugung ist der Session-ID immer eine
O zugeordnet;
Schlüssel – eine 2-Byte-Zahl,
die die Auswahl der Verschlüsselung
darstellt, welche der Klient gerade verwendet, wenn es eine Anzahl
von Verschlüsselungsschemen
gibt, die in einem Kommunikationsprotokoll verfügbar sind;
Version – eine 1-Byte-Zahl,
die die HDTP-Protokollversion darstellt, die gerade verwendet wird,
die zum Bestimmen des zugrundeliegenden Formats des Kommunikationsprotokolls
verwendet wird, wie beispielsweise des PDU;
Typ – entweder
eine feste 5-Byte-Zahl, die darstellt, welche Vorrichtung der Klient
ist, z. B. bedeutet 2PCSI, das der Klient eine PCSI-Telefonversion
2 ist.
Vorrichtungs-ID – eine
Variable von bis zu 255 Bytes, die den Vorrichtungsidentifizierer
oder den Klientenidentifizierer darstellt, der eine Telefonnummer
der Vorrichtung oder eine IP-Adresse und eine Anschlussnummer aufweist,
wie z. B. 204.163.165.132:01905;
Anfangsblock – bis zu
32767 Bytes mit Token-Wert-Paaren, die für eine gesamte Session gelten
und automatisch auf nachfolgende Dienstanforderungen oder sessionspezifische
Parameter angewendet werden können,
weshalb der Anfangsblock allgemein im Server in einem Cache gespeichert wird,
bis die aktuelle Session endet; und
C-ad-hoc-Bildung – eine Klienten-ad-hoc-Bildung, die
mit einer nicht wiederholbaren Zahl dargestellt wird, und zwar normalerweise
2 Bytes, die für
den Klienten zum Durchführen
einer folgenden Serverauthentifizierung verwendet wird.
Modifizierte
C-ad-hoc-Bildung – eine
modifizierte Version der Klienten-ad-hoc-Bildung, die für den Server zum Durchführen einer
ad-hoc-Bildungsverifizierung
bei der folgenden Klientenauthentifizierung verwendet wird.
-
Weiterhin
enthält
der Schlüssel
in der SR 144 einen Identifizierer zu einem Verschlüsselungsalgorithmus
und zugehörige
Parameter davon. Um genauer zu sein, stellt das erste Byte in dem
Schlüssel
einen Identifizierer zu einer Kombination des Verschlüsselungsalgorithmus,
die Schlüsselgröße (z. B. 128
Bits für
US oder 40 Bits für
fremde Länder)
und einen Inhalt einer Sicherheitsanbringung daran dar, und zeigt
das zweite Byte in dem Schlüssel
die zusätzlichen
Parameter in Bezug auf das erste Byte an. Beispielsweise zeigt ein
Wert 1 im ersten Byte an, dass der Verschlüsselungsalgorithmus ein Blockschlüssel RC5
ist, die Schlüsselgröße davon
128 Bits ist, eine 2-Byte-Prüfsumme
darin als der NAC (Nachrichtenauthentifizierungscode) verwendet
wird, und kein IV (Initialisierungsvektor für Blockschlüssel) dafür über das Netzwerk übertragen
wird, und werden Auffüll-Bytes
hinzugefügt,
wenn es nötig
ist. Der Blockschlüsselalgorithmus
RC5 ist ein Teil des BSAFE-Produkt RSA. Es kann weiterhin erkannt werden,
dass der Identifizierer im Schlüssel
einem eindeutigen Wert zugeordnet sein kann, um eine nicht sichere
Session zu identifizieren, wenn es so erwünscht ist. Die C-ad-hoc-Bildung
ist eine nicht wiederholbare Zahl bzw. Nummer, die anfänglich und
zufällig
im Klienten und der modifizierten Version davon erzeugt wird: Eine
modifizierte C-ad-hoc-Bildung wird aus der C-ad-hoc-Bildung durch
eine betriebsmäßige Beziehung
erzeugt; beispielsweise die Exklusiv-ODER-Beziehung, oder ausgedrückt wie
folgt:
Modifizierte C-ad-hoc-Bildung = 2-Byte-Zahl ⊕ C-ad-hoc-Bildung.
-
Es
kann durch Fachleute auf dem Gebiet erkannt werden, dass es viele
Arten zum Bekommen der modifizierten C-ad-hoc-Bildung aus einer C-ad-hoc-Bildung
gibt, wobei die Exlusiv-ODER-Verknüpfung eine der betriebsmäßigen Beziehungen
ist, die bei einem Ausführungsbeispiel
der vorliegenden Erfindung verwendet wird. Sowohl die C-ad-hoc-Bildung
als auch die modifizierte C-ad-hoc-Bildung werden unter Verwendung
des gemeinsam genutzten geheimen Verschlüsselungsschlüssels zwischen dem
Klienten 140 und dem Server 142 verschlüsselt. Der
Zweck der modifizierten C-ad-hoc-Bildung besteht im Versehen des
Servers, der die SR empfängt, mit
einer Einrichtung zum Sicherstellen, dass die C-ad-hoc-Bildung richtig
entschlüsselt
wird, und für gültig erklärt, indem
die C-ad-hoc-Bildung und ihre Beziehung zu der modifizierten C-ad-hoc-Bildung
untersucht wird. Beide sollten nach einer erfolgreichen Entschlüsselung
der C-ad-hoc-Bildung und der modifizierten C-ad-hoc-Bildung nicht
geändert
werden. Anders ausgedrückt
kann eine SR-Nachricht oder ein SR-Signal wie folgt ausgedrückt werden:
SR
= {Session-ID.Schlüssel.Version,
Typ, Vorrichtungs-ID, Anfangsblock, Verschlüsseln [ad-hoc-Bildung, modifizierte
ad-hoc-Bildung]};
wobei Verschlüsseln [] bedeutet, dass die
Parameter oder Inhalte in der Klammer entsprechend verschlüsselt werden.
Wenn die SR durch den Klienten zum Server gesendet wird, um eine
Sessionerzeugung anzufordern, werden beide, nämlich die C-ad-hoc-Bildung
und die modifizierte C-ad-hoc-Bildung, gemäß dem Schlüssel verschlüsselt, welchen der
Klient zu der Zeit verwendet, zu welcher SR ausgesendet wird.
-
Auf
ein Empfangen der SR vom Klienten 140 hin erzeugt der Server 142 eine
Server-Protosession für den Klienten 140 mit
einem Sessionidentifizierer, der Session-ID genannt wird, um den
Sessionkontext für
die gerade im Server 142 erzeugte Session zu identifizieren.
Eine Server-Protosession ist ein Sessioneintrag, der als Protozustand
in einer Sessiontabelle markiert ist, welche anzeigt, dass die Session nicht
authentifiziert ist und nicht dazu fähig ist, irgendwelche Transaktionen
mit dem Klienten durchzuführen.
Es ist von Fachleuten auf dem Gebiet zu versehen, dass die Protosession
im RAM des Servers gehalten werden kann. Wenn bereits eine Protosession für diesen
Klienten existiert, wird sie wieder verwendet. Die Information in
der emp fangenen SR wird in der Server-Protosession gesichert. Wenn
der Server 142 mit der Tatsache zufrieden gestellt ist,
dass der Klient bekannt ist, nämlich
Verschlüsseln [C-ad-hoc-Bildung, modifizierte
C-ad-hoc-Bildung] in der empfangenen SR erfolgreich mit dem gemeinsam
genutzten geheimen Verschlüsselungsschlüssel entschlüsselt sind,
ist der Schritt Eins in der Klientenauthentifizierung erfolgreich
und wird ein entsprechender Sessionschlüssel erzeugt und mit dem Server-Protosessioneintrag
gespeichert. Es kann hierbei angemerkt bzw. beachtet werden, dass
viele Verschlüsselungsschemen,
die bei dieser Erfindung verwendet werden, wie beispielsweise RC5,
eine Prozedur haben, die den Nachrichtenauthentifizierungscode,
wie beispielsweise die Prüfsumme,
hinzufügt und
für gültig erklärt, um sicherzustellen,
dass die verschlüsselte
Nachricht richtig entschlüsselt
wird, und hierin wird die Prozedur jedes Mal dann, wenn die Entschlüsselung
stattfindet, dazu verwendet, die Transaktionsintegrität zu untersuchen,
nämlich
sicherzustellen, dass die empfangenen Nachrichten oder Signale im
Fall einer Datenübertragung
unverändert
sind. Wenn bei dem Schritt Eins eine Klientenauthentifizierung nicht
erfolgreich ist, d. h. Verschlüsseln
[C-ad-hoc-Bildung,
modifizierte C-ad-hoc-Bildung] in der empfangenen SR nicht vollständig entschlüsselt oder
unterstützt
werden, wird die Protosession abgebrochen und aus der Protosession-Tabelle
entfernt, was in einer fehlgeschlagenen Sessionerzeugung resultiert.
Die Unterstützung
bedeutet hierin, dass der durch den Klienten vorgeschlagene oder
verwendete Schlüssel
auch von dem Server verwendet wird, beispielsweise verwendet der Klient
die RC5-Verschlüsselung
zum Verschlüsseln Verschlüsseln [C-ad-hoc-Bildung,
modifizierte C-ad-hoc-Bildung], zum Entschlüsseln Verschlüsseln [C-ad-hoc-Bildung,
modifizierte C-ad-hoc-Bildung], der Server muss mit derselben RC5-Verschlüsselungsfähigkeit
darin ausgestattet sein. Wenn Verschlüsseln [C-ad-hoc-Bildung, modifizierte C-ad-hoc-Bildung]
aufgrund anderer Gründe,
wie beispielsweise von Übertragsfehlern,
nicht erfolgreich entschlüsselt
werden kann, muss der Klient erneut eine neue Sessionanforderung
zum Server initiieren, um eine sichere Kommunikation mit dem Server
aufzubauen. Zum Anfordern eines Schritts Zwei für eine Serverauthentifizierung
darauf folgend auf der Klientenseite, wird eine Ableitung der Klienten-ad-hoc-Bildung
oder der C-ad-hoc-Bildung dafür erzeugt.
Bei einem Ausführungsbeispiel
der vorliegenden Erfindung wird die Ableitung durch Addieren einer
Konstanten zu der Klienten-ad-hoc-Bildung erzeugt, wie beispielsweise
Ableitung = C-ad-hoc-Bildung + 1. Der Zweck der Ableitung besteht
im Versehen des Klientens mit einer Einrichtung zum erneuten Sicherstellen,
dass die C-ad-hoc-Bildung
durch den Server richtig entschlüsselt
wird und der Server der authentifizierte ist, der mit ihm kommuniziert.
-
Genau
nach dem erfolgreichen Schritt Eins für eine Klientenauthentifizierung
antwortet der Server 142 zu dem Klienten mit einer Sessionantwort (SP
= Session rePly) 146, um eine Authentifizerung einer zweiten
Runde zu beginnen: Serverauthentifizierung. Die SP 146 weist
die folgende Information auf:
C-SID – eine 1-Byte-Zahl zeigt die
Session-ID an, die ursprünglich
im Klienten zugeordnet ist, genauer gesagt zeigt C-SID = 0 eine
Klartext-Klientensession an, zeigt C-SID = 1 eine verschlüsselte Session
eines gemeinsam genutzten geheimen Schlüssels an und zeigt C-SID =
2 eine verschlüsselte
Session für
einen Sessionschlüssel
an. In Zusammenhang mit der gegenwärtigen Beschreibung gilt C-SID
= 1.
Session-ID – eine
4-Byte-Zahl, die eine Identifikation und Parameter darstellt, wie
beispielsweise einen Session-Verschlüsselungsschlüssel von
der durch den Server für
den Klienten erzeugten Session;
Schlüssel – ein Sessionschlüssel, der
mit einer wechselseitig akzeptierbaren Verschlüsselung zu verwenden ist und
der zur Verschlüsselung
und Entschlüsselung
bei allen Transaktionen in der Session zu verwenden ist;
Ableitung – eine Zahl,
die von der C-ad-hoc-Bildung für
den Klienten abgeleitet ist, um die darauf folgende Serverauthentifizierung
durchzuführen;
S-ad-hoc-Bildung – eine nicht
wiederholbare Zahl, die für
den Server verwendet wird, um eine folgende Klientenauthentifizierung
eines Schritts 2 durchzuführen;
es sollte beachtet werden, dass S-ad-hoc-Bildung durch den Server
erzeugt wird und allgemein unterschiedlich von der C-ad-hoc-Bildung
durch den Klienten ist; und
Schlüssel – eine 2-Byte-Zahl, die die
Auswahl der Verschlüsselung
darstellt, welche der Server vorschlägt, nachdem der vom Klienten
vorgeschlagene Schlüssel
empfangen wird. Er kann derselbe wie derjenige sein, der im Klienten
verwendet wird, oder auch nicht; genauer gesagt ist der Schlüssel derselbe wie
derjenige, der durch den Klienten vorgeschlagen wird, wenn der Server den
vom Klienten vorgeschlagenen Schlüssel unterstützt; sonst
ist der Schlüssel derjenige,
der gegenwärtig
im Server verwendet wird.
-
Anders
ausgedrückt
kann die SP wie folgt ausgedrückt
werden:
SP = {C-SID, Verschlüsseln [Session-ID, Schlüssel, S-ad-hoc-Bildung,
Ableitung, Schlüssel]};
-
Wenn
der Klient 140 die SP 146 vom Server 142 empfängt, führt er die
Serverauthentifizierung des Schritts 1, durch welcher als erfolgreich
angesehen wird, wenn Verschlüsseln
[Session-ID, Schlüssel,
S-ad-hoc-Bildung, Ableitung, Schlüssel] in der empfangenen SP 146 mit
dem gemeinsam genutzten Verschlüsselungsschlüssel erfolgreich
entschlüsselt wird.
Wenn die Serverauthentifizierung des Schritts Eins fehlschlägt, wirft
der Klient 140 die SP 146 weg, und eine neue Sessionerzeugung
kann wieder begonnen werden. Auf den Erfolg der Serverauthentifizierung
des Schritts Eins hin fährt
der Klient 140 mit der Serverauthentifizierung des Schritts
2 fort; d. h. die vorbestimmte Beziehung zwischen der C-ad-hoc-Bildung
und der Ableitung davon sollte für eine
erfolgreiche Serverauthentifizierung des Schritts 2 gehalten werden:
C-ad-hoc-Bildung
= Ableitung – 1
-
Wenn
die aus der SP 146 abgeleitete C-ad-hoc-Bildung dieselbe
wie die ursprünglich durch
den Klienten erzeugte C-ad-hoc-Bildung ist, ist die Serverauthentifizierung
des Schritts Zwei erfolgreich, und somit wird der Server 142 als
authentifiziert betrachtet, als vertrauensvoll von dem Standpunkt
des Klienten aus, und wird die SP 146 als gültige Nachricht
akzeptiert, was bedeutet, dass der Klient 140 dann den
Sessionschlüssel
und andere Information in der SP 146 für die Session verwendet, die erzeugt
wird. Nur mit beiden erfolgreichen Schritten der Serverauthentifizierung
markiert der Klient 140 die Session als begonnen, was bedeutet,
dass Transaktionen darauf folgend in der Session durchgeführt werden
können,
und zwar wiederum nur vom Standpunkt des Klienten 140 aus.
Wenn die vorbestimmte Beziehung zwischen der Klienten-ad-hoc-Bildung
und der Ableitung davon nicht gilt, schlägt die Serverauthentifizierung
des Schritts Zwei fehl und wird die empfangene SP 146 weggeworfen.
Der Klient 140 kann den Sessionerzeugungsprozess abbrechen,
wenn keine weiteren SPs empfangen werden, und beide Schritte der
Serverauthentifizierung während
der Zeitperiode durchlaufen, die für eine Sessionerzeugung zugelassen ist.
Zum Versehen des Servers mit einer Einrichtung zum erneuten Feststellen
bzw. Sicherstellen der Klientenauthentifizierung durch selbst über den
Klienten wird eine Ableitung der S-ad-hoc-Bildung ähnlich der
Ableitung der C-ad-hoc-Bildung erzeugt.
-
Der
Klient 140 sendet dann dem Server 142 eine SC 148,
um den Sessionerzeugungsprozess zu beenden. Die SC 148 weist
die folgende Information auf:
SC = {Verschlüsseln[Ableitung]};
wobei
die Ableitung die Klientenantwort auf die Server-ad-hoc-Bildungsanforderung
ist, d. h. das Ergebnis der Verifizierung, die Ableitung durch den
Server 142 für
eine Klientenauthentifizierung des Schritts 2 verwendet wird. Weiterhin
ist anzumerken, dass die SC 148 eine verschlüsselte Nachricht
ist, was bedeutet, dass der Klient die Information in der SC 148 gemäß entweder
seinem eigenen Schlüssel
oder dem vom Server vorgeschlagenen Schlüssel verschlüsselt. Allgemein
verschlüsselt
der Klient 140 die Information in der SC 148 gemäß dem vom
Server vorgeschlagenen Schlüssel,
wenn er den vom Server vorgeschlagenen Schlüssel akzeptiert, und sonst
verschlüsselt
er die SC gemäß seinem
eigenen Schlüssel.
-
Es
muss bei einem Ausführungsbeispiel
der vorliegenden Erfindung beachtet werden, dass die SC ungleich
der SR 144 und der SP 146 durch eine folgende
Transaktionsanforderung im Huckepack getragen wird, um eine Datenübertragungseffizienz
zu erhöhen.
Das Tragen von Daten im Huckepack bedeutet, dass unabhängige Dateneinheiten
logisch in einer physikalischen Dateneinheit gruppiert werden können, die
zu einem Empfänger
zu übertragen
ist, der alle unabhängigen
Dateneinheiten auf den Empfang der physikalischen Dateneinheit hin
entdeckt bzw. wiedergewinnt, als ob alle unabhängigen Dateneinheiten gesendet
wurden, und zwar unabhängig und
jeweils, in getrennten physikalischen Dateneinheiten.
-
Auf
ein Empfangen einer Sessionbeendigung oder SC 148 hin testet
der Server 142, ob der Klient seinen eigenen vorgeschlagenen
Schlüssel oder
den vom Server vorgeschlagenen Schlüssel verwendet, indem er die
SC zweimal unter Verwendung zwei Schlüssel entschlüsselt, wenn
es nötig
ist. Wenn der Server 142 die verschlüsselte Nachricht in der SC 148 entschlüsselt und
die Beziehung davon mit der S-ad-hoc-Bildung
verifiziert, ist die Klientenauthentifizierung des Schritts Zwei
erfolgreich.
-
Darauf
folgend fördert
der Server 142 die Server-Protosession zu der aktiven Session
und ist der Sessionerzeugungsprozess beendet; sonst wird die Protosession
entfernt und wird die Sessionerzeugung abgebrochen.
-
Nimmt
man nun Bezug auf 4a und 4b sind dort zwei Daten-Ablaufdiagramme 180 und 181 gezeigt,
die einen Sessionerzeugungsprozess im Klienten bzw. im Server darstellen,
und zwar bei einem Ausführungsbeispiel
der vorliegenden Erfindung. Es gibt allgemein drei Typen von Transaktionen,
die zwischen einer mobilen Vorrichtung und einem Festznetzserver
durchgeführt
werden; eine Diensttransaktion bzw. Servicetransaktion, eine Benachrichtigungstransaktion
und eine Posttransaktion. Sowohl eine Dienst- als auch eine Posttransaktion
wird durch die mobile Vorrichtung initiiert, die hierin als Klient
betrachtet wird, und die Benachrichtigungstransaktion wird durch
den Festnetzserver initiiert, der hierin als Server betrachtet wird.
Alle Transaktionen müssen im
Zusammenhang einer gültigen
und aufgebauten Session durchgeführt
werden. Wenn es keine Session oder keine gültige Session gibt, muss eine
Session erzeugt werden, bevor irgendeine Transaktion starten kann.
Der Einfachheit halber ist angenommen, dass die Transaktion auf
der Klientenseite bei 182 initiiert wird. Wie es oben beschrieben
ist, muss für
eine Transaktion, damit sie in einer sicheren Kommunikation stattfindet,
eine Session zwischen einem Klienten und einem Server zuerst aufgebaut
werden. Daher wird bei 184 die Existenz einer gültigen Session
untersucht. Wenn eine gültige
Session stattfindet, kann die Transaktion bei 186 fortfahren.
Wenn es keine aufgebaute Session gibt, wie beispielsweise in dem
Fall, in dem eine mobile Vorrichtung gerade zum ersten Mal eingeschaltet
wird, oder in dem Fall, in welchem eine vorherige Session über einer
Zeitbegrenzung ist, wie beispielsweise 8 Stunden, muss eine Sessionanforderung
initiiert und zu dem Server gesendet werden, und zwar bei 188.
Der Klient ist dann in einem Betrieb eines Wartens auf eine Antwort
von dem Server, während
er konstant nach der Antwort schaut, und zwar bei 190 und 192.
Wenn es keine Antwort vom Server gibt, kann der Klient eine weitere
Sessionanforderung initiieren, wenn eine feste Zeitperiode verstreicht,
und zwar bei 194, oder Fehlerauftreten, um die initiierte
Sessionanforderung abzubrechen, und zwar bei 196 und 198.
Die Fehler treten dann auf, wenn der Klient außerhalb eines Dienstbereichs
ist, der durch ein Luftnetz versorgt wird, das mit dem Server kommuniziert,
oder einfach entweder der Klient oder der Server nicht funktioniert, und
zwar bei 199.
-
Zwischenzeitlich
wird die Sessionanforderung durch den Server bei 216 empfangen.
Eine Protosession wird bei 222 für die Sessionanforderung von
dem Klienten erzeugt, wenn die Sessionanforderung nicht eine kopierte
ist. Es ist sehr gewöhnlich, dass
eine Sessionanforderung erneut gesendet oder erneut angefordert
werden kann, und zwar durch den Klienten, und zwar aufgrund einiger
unerwarteter Fehlerzustände
in dem drahtlosen Datennetzwerk, so dass kopierte Anforderungen
empfangen werden können.
Der Server verwendet jedoch ein Taq bzw. eine Fahne, das bzw. die
aus der verschlüsselten Nachricht
in der Sessionanforderung erzeugt wird, die zuerst empfangen wird
und eindeutig für
jede Sessionanforderung von einem bestimmten Klienten ist, um ein
Erzeugen von mehrfachen Protosessions aus den kopierten bzw. duplizierten
Sessionanforderungen zu verhindern. Einiges der Information in der Sessionanforderung,
wie beispielsweise eine Protokollversion und eine Vorrichtungs-ID,
wird bei 224 verifiziert. Wenn die verifizierte Information
nicht unterstützt
wird, könnte
es einen Vorrichtungsfehler bei 226 geben, was in der Entfernung
der gerade erzeugten Protosession resultiert. Wenn der Verifizierungsprozess
bei 224 erfolgreich ist, fährt der Server mit einem Entschlüsselungsprozess
gemäß einem
gemeinsam genutzten geheimen Verschlüsselungsschlüssel, wie
er oben beschrieben ist, fort, um die C-ad-hoc-Bildung und die modifizierte
C-ad-hoc-Bildung bei 230 zu entschlüsseln. Wenn die betriebsmäßige Beziehung
zwischen der C-ad-hoc-Bildung und
der modifizierten C-ad-hoc-Bildung auf der Serverseite gilt, endet
die Klientenauthentifizierung des Schritts Eins. CIP bei 203 in 4a und 234 und 236 der 4b steht für einen
Kryptographie-Auslöseprozess,
welcher ein Prozess zum Ausstatten eines Klienten mit einer aktualisierten
Verschlüsselungsinformation
ist, wie beispielsweise zum Aktualisieren des gemeinsam genutzten
geheimen Schlüssels.
Da der CIP ein hinzugefügter
Prozess ist und bei der vorliegenden Erfindung kein Hauptelement
ist, ist daher keine detaillierte Beschreibung dafür vorgesehen.
Mit der erfolgreichen Klientenauthentifizierung des Schritts Eins
sendet der Server bei 238 eine Sessionantwort zum Klienten.
-
Wenn
ein Server erreicht wird und die Sessionanforderung vom Klienten
erfolgreich verarbeitet, nämlich
die Klientenauthentifizierung des Schritts, wie es oben beschrieben
ist, wird eine Sessionantwort durch den Server zum Klienten gesendet,
um eine Serverauthentifizierung auf der Klientenseite zu beginnen.
Auf ein Empfangen der Sessionantwort von dem Server hin, der angeschlossen
ist, untersucht der Klient das Antwortsignal bei 200 und 201, und
die Sessionantwort sollte in einem erkannten Format sein, wie beispielsweise
mit einer unzerstörten
wesentlichen Information dar in. Wenn die empfangene Sessionantwort
nicht erkannt oder unterstützt
wird, wirft der Klient die empfangene Sessionantwort bei 202 weg
und fährt
damit fort, auf eine gültige
Sessionantwort zu warten. Sonst können Probleme mit Vorrichtungen
im Schritt 199 beansprucht werden. Auf ein Empfangen der
Sessionantwort vom Server hin fährt
der Klient mit zwei Schritten der Serverauthentifizierung bei 204 fort,
was oben detailliert beschrieben worden ist. Logischerweise wird
die Session bei 202 weggeworfen, wenn die Serverauthentifizierung
fehlschlägt,
d. h. der Klient darin fehlschlägt,
die verschlüsselte
S-ad-hoc-Bildung zu entschlüsseln
und zu verifizieren und die Ableitung der durch den Server erzeugten
C-ad-hoc-Bildung für gültig zu
erklären.
Wenn die Serverauthentifizierung vorbei ist, wählt der Klient entweder seinen
eigenen Schlüssel
oder den vom Server vorgeschlagenen Schlüssel, der von der Sessionantwort
vom Server erhalten wird, bei 208 und 210, und
weiterhin gewinnt der Klient den Sessionschlüssel daraus wieder und sendet
ein Sessionbeendigungssignal zum Server, um die Sessionerzeugung
zu beenden, und zwar bei 212 und 214.
-
Zwischenzeitlich
erwartet der Server ein Sessionbeendigungssignal vom Klienten, wenn
er gerade die Sessionantwort zu ihm sendet, und zwar bei 238.
Zu Sicherheitszwecken lässt
der Server die Protosession bei 242 fallen, wenn die Wartezeit
auf das Sessionbeendigungssignal über eine Schwelle gelangt, 240.
Auf ein Empfangen des Sessionbeendigungssignals bei 244 hin
fährt der
Server mit der Klientenauthentifizierung des Schritts Zwei bei 246 und 248 fort,
indem er die verschlüsselte
Ableitung der S-ad-hoc-Bildung entschlüsselt und die Beziehung davon
zu der ursprünglichen
S-ad-hoc-Bildung verifiziert. Wenn die Entschlüsselung der Ableitung oder die
Verifizierung mit der S-ad-hoc-Bildung fehlschlägt, schlägt die Sessionerzeugung fehl,
und somit erfolgt die Entfernung der Protosession. Wenn die Klientenauthentifizierung
des Schritts Zwei erfolgreich ist, was bedeutet, dass die Klientenauthentifizierung
des Schritts Eins und die Serverauthentifizierung des Schritts Eins
und des Schritts Zwei alle beendet sind, wird die Session durch
Fördern
der Protosession zu der regulären
Session bei 250 erfolgreich erzeugt, und dadurch kann die
Transaktion, die ursprünglich
durch den Klienten initiiert ist, und zwar bei 182 der 4a, daraus fortgeführt werden.
-
Zum
Durchführen
von Transaktionen bei einer authentischen und sicheren Session muss
jede Transaktion einer Transaktions-ID zugeordnet sein. Bei einem
Ausführungsbeispiel
der Erfindung muss eine neue Transaktion eine neue Transaktions-ID haben,
und sie muss in einer Trans-Sequenz sein, d. h. die Transaktions-ID
muss größer als
irgendeine andere sein, die beendet ist, und anhängige Transaktions-IDs, und
kleiner als 255, und zwar zu der Zeit, zu welcher die neue
Transaktion in der Session begonnen wird, wie beispielsweise Transaktions-ID
= 12 für eine
aktuelle Transaktion, und die nächste
Transaktions-ID vom Klienten muss 13 oder größer in einer Reihenfolge für die durch
den Server zu akzeptierende Transaktion sein. Die Konstante 255 ist
die maximale Zahl von Transaktionen, die in einer gültigen Session
durchgeführt
werden können.
Wenn eine Transaktions-ID kleiner als das ist, was die Session erwartet,
wird die Transaktion ohne Notiz bzw. Nachricht weggeworfen. Wenn
die Transaktions-ID größer als
255 ist, wird automatisch eine neue Session erzeugt, um die entsprechende
Transaktion anzupassen. Alle Dateneinheiten in Bezug auf Transaktionen werden
mit den Sessionschlüssel
verschlüsselt,
der im Sessionrzeugungsprozess erzeugt wird, und der dabei verwendete
Schlüssel
ist entweder der vom Klienten vorgeschlagene Schlüssel oder
vom Server vorgeschlagene Schlüssel.
-
Gemäß 5 ist ein schematisches
Diagramm einer Diensttransaktion gezeigt. Der mobile Klient 140 initiiert
eine Dienstanforderung (tSR) 152 zum Server 142.
Eine Diensttransaktion ist typischerweise an einer Interaktion mit
einem Dienstprovider beteiligt, der durch einen universellen Betriebsmittellokalisierer
URL (= Universal Resource Locator) in einem Festnetzserver identifiziert
ist, und daher weist die Information in einer tSR einen URL und
einen optionalen Anfangsblock auf, der zusätzliche Sessioninformation
zu Verfügung
stellt. Auf ein Empfangen der tSR 152 hin verarbeitet der
Server 142 die empfangene tSR 152, um die Session-ID
und die Transaktions-ID darin zu untersuchen. Wenn die Transaktions-ID
kleiner als das ist, was erwartet wird, wird die tSR 152 weggeworfen.
Zusätzlich
wird die tSR 152 weggeworfen, wenn die Transaktions-ID
in der empfangenen tSR 152 größer als 255 ist. Wie
es oben beschrieben ist, ist aus Sicherheitsgründen ein Maximum von 256 Transaktionen
in einer Session zugelassen. Wenn mehr als die zugelassene Anzahl
von Transaktionen in einer aufgebauten Session auftreten, wird automatisch
eine neue Session initiiert, wobei die Transaktions-ID von Null
an begonnen wird. Auf die erfolgreiche Untersuchung der Dienstanforderung
tSR 152 hin antwortet der Server 142 mit einer
Dienstantwort (tSP) 154, die ein Ergebnis in der Form einer
Auswahl aus der URL-Dienstanforderung und eines optionalen Anfangsblocks
aufweist. Auf ein Empfangen der tSP 154 vom Server 142 hin
sendet der Klient 140 dem Server 142 eine Bestätigung (ASK) 156,
um die Transaktion zu beginnen, wenn das Ergebnis in der empfangenen
tSP 154 positiv ist. Alternativ dazu kann der in der Hand
gehaltene Klient dem Server eine Löschung zum Abbrechen der Transaktion
senden. Ein typisches Beispiel besteht darin, dass der Klient 140 anfordert,
auf Informationen zuzugreifen, die durch den URL gespeichert und identifiziert
ist, als www.abc.com, was bei dem Server 142 gestützt ist
bzw. unterstützt
wird, jedoch wird in den URL in der tSR 152 als www.abcd.com
eingetreten, und das Ergebnis in der tSP 154 bringt eine
Fehlernachricht zurück,
die anzeigt, dass der erwünschte URL
nicht gefunden werden konnte, und sonst zeigt das Ergebnis in der
tSP 154, dass die erwünschte URL
gefunden worden ist, und nun ist es Sache des Anwenders des Klientens,
zu bestimmen, ob der Klient mit der tSP 156 fortfahren
soll oder sie löschen soll,
um die aktuelle Transaktion abzubrechen, um einen neuen oder anderen
URL zu versuchen.
-
Nimmt
man nun Bezug auf 6,
ist dort ein schematisches Diagramm einer Benachrichtungstransaktion
gezeigt. Eine Benachrichtigungstransaktion kann durch entweder den
Klienten 140 oder den Server 142 initiiert werden.
Im Fall einer Serverinitiierung initiiert der Server 142 die
Benachrichtigungstransaktion durch Senden einer Signaldateneinheit zum
Klienten 140, oder einer Benachrichtungsanforderung (NS) 162,
um den Klienten 140 darüber
zu informieren, dass es eine Benachrichtigung gibt, die im Server 142 anhängig ist,
wie beispielsweise eine elektronische Mail, die auf eine direkte
Aufmerksamkeit von dem identifizierten Klienten wartet. Auf ein Empfangen
der NS 162 hin sendet der Klient 140 ein Benachrichtigt
werden bzw. Nachricht bekommen (GN = Get-Notify) 164 zum
Server 142 und gewinnt seine Benachrichtigungsinhalte,
wie beispielsweise Alarme und E-Mails, wieder. Der Server 142 antwortet
wie bei der Diensttransaktion mit einer tSR 146. Die Transaktion
wird begonnen, nachdem ein Bestätigungssignal
(AS) 156 zum Server 142 gesendet wird und der
Server 142 dieses empfängt:
Im Fall der Klientenbenachrichtigung initiiert der Klient 140 die Benachrichtigungstransaktion,
wenn er eingeschaltet wird oder zu dem Datenmode aus dem Sprachmode zurückschaltet,
in dem er den Server 142 fragt, ob es irgendwelche Benachrichtigungen
gibt, die anhängig sind.
Wenn es eine Benachrichtigung gibt, die anhängig ist, behandelt der Klient 140 die
Benachrichtigungstransaktion so, als ob ein Signal empfangen wird.
Das AS 146 kann mit einem GN im Huckepack getragen werden,
wenn mehrere Benachrichtigungstransaktionen sequentiell durchgeführt werden. Wenn
es mehrere Benachrichtigungen gibt, die beim Server 142 anhängig sind,
zeigt der optionale Anfangsblock in der tSR 146 an, dass
dies so ist, so dass der Klient automatisch eine weitere Benachrichtigungstransaktion
beginnen wird.
-
Nimmt
man nun Bezug auf 7,
ist dort die Posttransaktion gezeigt. Eine Posttransaktion wird durch
den mobilen Klienten 140 initiiert. Die Posttransaktion
wird für
eine mobile Vorrichtung zum Aktualisieren von Information verwendet,
die in einem WWW-Dienst gespeichert ist, wie er im URL spezifiziert
ist. Der Klient 140 sendet eine Postanforderung (PR) 172,
die einen URL enthält,
Daten zur Aktualisierung und einen optionalen Anfangsblock. Der
Server 142 verarbeitet die PR 172 und antwortet
zum Klienten mit einer tSR 146. Das Ergebnis in der tSR 146 kommt
von dem WWW-Dienst und zeigt normalerweise an, ob eine Informationsaktualisierung
durchgeführt
ist. Auf ein Empfangen der tSR 146 hin sendet der Klient 140 dem
Server 142 ein AS 156, um die Transaktion zu beginnen.
Alternativ dazu kann der mobile Klient 140 dem Server 142 eine
Löschung zum
Abbrechen der Transaktion senden.
-
Die
vorliegende Erfindung ist in ausreichendem Detail mit einem beispielhaften
Ausführungsbeispiel
beschrieben worden. Alternative Ausführungsbeispiele werden Fachleuten
auf dem Gebiet, zu welchem die vorliegende Erfindung gehört, offensichtlich werden.
Beispielsweise betrifft das Gebiet drahtlose Kommunikationen zwischen
einem Server und einem persönlichen
digitalen Assistenten, wie beispielsweise Palm Pilot von 3Com Corporation
und auch einen tragbaren Computer, der unter einem Betriebssystem,
wie beispielsweise Windows CE von Microsoft Corporation, läuft. Demgemäß ist der
Schutzumfang der vorliegenden Erfindung eher durch die beigefügten Ansprüche als
durch die vorangehende Beschreibung eines Ausführungsbeispiels definiert.