DE60114220T2

DE60114220T2 - System und verfahren zur implementierung des verbesserten transportschicht-sicherheitsprotokolls

Info

Publication number: DE60114220T2
Application number: DE60114220T
Authority: DE
Inventors: S. Michael BROWN; A. Herb LITTLE; David Yach
Original assignee: Research in Motion Ltd
Current assignee: BlackBerry Ltd
Priority date: 2000-08-25
Filing date: 2001-08-24
Publication date: 2006-07-27
Anticipated expiration: 2021-08-25
Also published as: AU2001287427A1; HK1057434A1; US8516242B2; US7631180B2; CA2420252A1; EP1314294B1; CN1449617A; US8145896B2; DE60114220D1; US20120159150A1; DE60140014D1; CA2420252C; US20100088504A1; ATE443964T1; EP1524815B1; EP1524815A1; EP1314294A2; BR0113510A; HK1080310A1; CN100499641C

Description

Diese Anmeldung beansprucht eine Priorität von der folgenden früheren Anmeldung und bezieht sich auf diese: Enhanced Transport Layer Security Handshake For Mobile Communication Devices, Publikation Nr. US 2003/0159029 A1 20030821.
HINTERGRUND
1. GEBIET DER ERFINDUNG
Diese Erfindung betrifft im Allgemeinen den Bereich von Computernetzwerk-Sicherheitsprotokollen. Insbesondere sieht die Erfindung ein verbessertes Transportschicht-Sicherheitsprotokoll (ETLS – Enhanced Transport Layer Security) vor, das insbesondere zur Verwendung mit mobilen Kommunikationsvorrichtungen geeignet ist, wie PDAs (Personal Digital Assistants), zellularen Telefonen und drahtlosen Zweiweg-E-Mail-Kommunikationsvorrichtungen (im Folgenden insgesamt als „mobile Vorrichtungen" bezeichnet).
2. BESCHREIBUNG DES STANDES DER TECHNIK
WO 00/11832 beschreibt ein System und ein Verfahren zum Ermöglichen eines sicheren Zugriffs auf Dienste in einem Computernetz. Ein globaler Server umfasst eine Kommunikationsmaschine zum Herstellen einer Kommunikationsverbindung mit dem Client; Sicherheitsmittel sind mit der Kommunikationsmaschine verbunden, um Client-Privilege zu bestimmen; eine Servlet-Host-Maschine ist mit den Sicherheitsmitteln verbunden. Der globale Server kann mit mehreren Standorten verbunden sein, wobei jeder Standort mehrere Dienste anbietet. Jeder Standort kann von einer Firewall geschützt sein. Demgemäß speichert der globale Server die Schlüssel zur Freigabe einer Kommunikation mit den Diensten über die Firewalls.
WO 98/55930 betrifft ein Authentisierungssystem, das zumindest eine Station und einen Host aufweist. Die Station weist einen Speicher zum elektronischen Speichern einer Vielzahl von Authentisierungselementen auf. Konstruktionsmittel werden verwendet, um ein Authentisierungssteuerungselement, wie einen Schlüssel, aus einem Teil der Authentisierungselemente zu konstruieren, der für jede Meldung gewählt wird. Authentisierungsmittel authentifizieren die Meldung im Wesentlichen eindeutig unter der Steuerung des für die Meldung konstruierten Authentisierungssteuerungselements. Die authentifizierte Meldung wird an den Host gesendet. Der Host weist einen Speicher zum elektronischen Speichern der Authentisierungselemente der Station auf. Der Host weist Konstruktionsmittel zum Konstruieren eines Authentisierungssteuerungselements für jede empfangene authentifizierte Meldung auf dieselbe Weise wie die Station auf. Verifikationsmittel werden unter Steuerung des Authentisierungssteuerungselement zur Verifizierung der Authentizität der empfangenen Meldung verwendet.
Sicherheitsprotokolle zum Aufbau einer sicheren Verbindung zu einem Computernetz, wie dem Internet, sind bekannt. Ein Sicherheitsprotokoll, dass üblicherweise zur sicheren Verbindung mit einem Internet-Host verwendet wird, ist das Transportschicht-Sicherheitsprotokoll (TLS – Transport Layer Security), das ehemals als das SSL(Secure Socket Layer)-Protokoll bekannt war.
1 ist ein Signalflussdiagramm 10, das die grundlegenden Schritte darstellt, die typischerweise verwendet werden, um eine sichere Verbindung zwischen einem Client 12 und einem Internet-Server 14 unter Verwendung des TLS-Protokolls aufzubauen. In Schritt 16 wird ein anfängliches Datagramm von dem Client 12 an den Server 14 übertragen, um einen Kontakt herzustellen und die Algorithmen oder Sprachen zu identifizieren, die der Client 12 unterstützen kann. Sobald das anfängliche Datagramm empfangen wird, akzeptiert der Server 14 typischerweise die Verbindung und antwortet mit einem Datagramm, das die Algorithmen oder Sprachen identifiziert, die der Server unterstützen wird (Schritt 18). Zusätzlich umfasst das Antwort-Datagramm von dem Server 14 typischerweise einen öffentlichen Schlüssel in einem digitalen Zertifikat, das die Identität des Servers 14 authentifiziert. Das digitale Zertifikat wird im Allgemeinen von einer gesicherten dritten Partei, wie VeriSign^TM oder einer anderen Zertifikatsautorität, erlangt, die verifiziert, dass der öffentliche Schlüssel zu dem Server 14 gehört. Zusätzlich weist der öffentliche Schlüssel typischerweise einen zugehörigen privaten Schlüssel auf, der nur von dem Server 14 geführt wird, wodurch mit dem öffentlichen Schlüssel verschlüsselte Daten nur unter Verwendung des privaten Schlüssels entschlüsselt werden können.
In den Schritten 20 und 22 verhandelt der Client 12 einen Sitzungsschlüssel mit dem Server 14. Der Sitzungsschlüssel ist typischerweise eine von dem Client 12 erzeugte zufällige Zahl, die nur für eine Abruf-Antwort-Operation zwischen dem Client 12 und dem Server 14 verwendet wird. Der zufällige Sitzungsschlüssel wird typischerweise zuerst verwendet, um einige zufällige Daten als „Beweis des Schlüssels" zu verschlüsseln. Der Sitzungsschlüssel und die Daten werden dann mit dem öffentlichen Schlüssel verschlüsselt und in Schritt 20 an den Server übertragen. Der Sitzungsschlüssel und die „Schlüsselbeweis"-Daten werden von dem Server unter Verwendung seines privaten Schlüssels entschlüsselt. Die „Schlüsselbeweis"-Daten werden dann weiter mit dem Sitzungsschlüssel ent schlüsselt. Dann überträgt in Schritt 22 der Server typischerweise die „Schlüsselbeweis"-Daten zurück an den Client 12, um nachzuweisen, dass er den Sitzungsschlüssel richtig empfangen und entschlüsselt hat.
Sobald der öffentliche TLS-Schlüssel ausgetauscht und ein Sitzungsschlüssel verhandelt wurde, wird ein sicherer TLS-Socket errichtet und Anwendungsdaten können sicher zwischen dem Client 12 und dem Server 14 unter Verwendung des Sitzungsschlüssels übertragen werden (Schritt 24). Durch Anwenden dieses vierfachen Handshakes zwischen einem Client und einem Server jedes Mal, wenn eine Kommunikation initiiert wird, stellt das TLS-Protokoll sowohl die Authentizität des Servers als auch die Echtheit der Übertragung sicher. Um zum Beispiel die Bedeutung einer Echtheit darzustellen, wenn ein Benutzer über einen Client mit einem Bank-Server kommuniziert hat, um elektronisch Geld von einem Konto zu übertragen, verhindert der vierfache TLS-Handshake, dass die Übertragungsoperation durch „Wiederholen" derselben verschlüsselten Meldung entweder von demselben Client oder einem anderen Client wiederholt wird, wenn die Kommunikation abgefangen wurde.
Obwohl das TLS-Protokoll eine sichere Verbindung mit einem Server vorsieht, ist dieses Protokoll für mobile Anwendungen nicht so gut geeignet, da die in dem vierfachen TLS-Handshake übertragenen Datagramme typischerweise eine relativ große Menge von Daten enthalten, die nicht schnell über ein drahtloses Netzwerk übertragen werden können. Um somit die Anzahl von über das drahtlose Netz übertragenen Datagrammen zu reduzieren, verwenden mobile Anwendungen üblicherweise ein drahtloses Anwendungsprotokoll (WAP – Wireless Application Protocol), um eine sichere Verbindung mit einem Internet-Server aufzubauen.
2 ist eine Blockdarstellung, die ein typisches mobiles Kommunikationssystem 30 darstellt, welches das drahtlose Anwendungsprotokoll (WAP) verwendet.
In diesem System 30 wird eine Dienstanforderung von einer mobilen Vorrichtung 32, die an einen Server 34 adressiert ist, unter Verwendung eines drahtlosen Transportschicht-Sicherheitsprotokolls (WTLS – Wireless Transport Layer Security) verschlüsselt und über ein drahtloses Gateway 36 an ein WAP-Gateway 38 übertragen, das typischerweise als ein Proxy zum Internet wirkt. Das drahtlose Gateway und das WAP-Gateway können zusammen eingerichtet sein, müssen es aber nicht sein. Typischerweise weist das WAP-Gateway 38 sein eigenes digitales Zertifikat auf, das von einer gesicherten dritten Partei signiert ist, das von der mobilen Vorrichtung 32 verwendet wird, um seine Authentizität zu validieren. Sobald die WTLS-verschlüsselte Dienstanforderung empfangen wird, baut das WAP-Gateway 38 im Allgemeinen eine TLS-Verbindung mit dem Server 34 über das Internet auf. Die Dienstanforderung wird dann von dem WAP-Gateway 38 entschlüsselt, unter Verwendung des TLS-Protokolls wieder verschlüsselt und über das Internet an den Server 34 gesendet. Um auf die Dienstanforderung zu antworten, überträgt der Server 34 typischerweise TLS-verschlüsselte Daten an das WAP-Gateway 38, die dann entschlüsselt und unter Verwendung des WTLS-Protokolls wieder verschlüsselt und an die mobile Vorrichtung 32 übertragen werden. Obwohl dieses System 30 typischerweise schneller als das TLS-Protokoll für mobile Anwendungen ist, hinterlässt es eine Lücke in der sicheren Verbindung, wodurch riskiert wird, dass Daten abgefangen werden können, während sie sich in unverschlüsseltem Textformat in dem WAP-Gateway 38 befinden.
ZUSAMMENFASSUNG
Ein System und ein Verfahren zur Implementierung eines verbesserten Transportschicht-Sicherheitsprotokolls (ETLS – Enhanced Transport Layer Security) ist vorgesehen. Das System umfasst einen primären Server, ein ETLS-Servlet und ein ETLS-Softwaremodul. Der primäre Server arbeitet auf einem Computernetzwerk und ist konfiguriert, über das Computernetz unter Verwendung eines nicht-proprietären Sicherheitsprotokolls zu kommunizieren. Das ETLS-Servlet arbeitet ebenso auf dem Computernetz und ist mit dem primären Server sicher verbunden. Das ETLS-Servlet ist konfiguriert, über das Computernetz unter Verwendung eines ETLS-Sicherheitsprotokolls zu kommunizieren. Das ETLS-Softwaremodul arbeitet auf einer mobilen Vorrichtung und ist konfiguriert, über das Computernetz unter Verwendung entweder des nicht-proprietären Sicherheitsprotokolls oder des ETLS-Sicherheitsprotokolls zu kommunizieren. In Betrieb kontaktiert das ETLS-Softwaremodul zuerst den Server über das Computernetz unter Verwendung des nicht-proprietären Sicherheitsprotokolls und kontaktiert anschließend den Server durch das ETLS-Servlet unter Verwendung des ETLS-Sicherheitsprotokolls.
Der Gegenstand der vorliegenden Anmeldung ist in den angehängten Ansprüchen definiert.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Signalflussdiagramm, das die grundlegenden Schritte darstellt, die typischerweise verwendet werden, um eine sichere Verbindung zwischen einem Client und einem Internet-Server unter Verwendung des TLS-Protokolls aufzubauen;
2 ist eine Blockdarstellung, die ein typisches mobiles Kommunikationssystem unter Verwendung eines drahtlosen Anwendungsprotokolls (WAP) darstellt;
3 ist ein Signalflussdiagramm, das eine drahtlose Kommunikation zwischen einem Client und einem Server unter Verwendung eines verbesserten Transportschicht-Sicherheitsprotokolls (ETLS) darstellt;
4 ist eine Blockdarstellung eines beispielhaften ETLS-Systems, das eine sichere Verbindung zwischen einer mobilen Vorrichtung und einem HTTP-Server unter Verwendung des ETLS-Protokolls darstellt; und
5 ist ein Flussdiagramm eines beispielhaften Verfahrens zur sicheren Kommunikation zwischen einer mobilen Vorrichtung und einem Netzwerk-Server unter Verwendung des ETLS-Protokolls.
DETAILLIERTE BESCHREIBUNG
Unter Bezugnahme nun auf die verbleibenden Zeichnungen ist 3 ein Signalflussdiagramm 40, das eine drahtlose Kommunikation zwischen einem Client 42 und einem Server 44 unter Verwendung eines verbesserten Transportschicht-Sicherheitsprotokolls (ETLS) darstellt. Der Client 42 kann jedes System sein, das auf einer mobilen Vorrichtung arbeitet, die fähig ist, drahtlos auf ein Computernetz zuzugreifen. Der Server 44 umfasst vorzugsweise einen primären Server, wie einen HTTP-Server 46, und ein ETLS-Servlet 48, die beide auf einem Computernetzwerk, wie dem Internet, arbeiten. Das ETLS-Servlet 48, das detaillierter im Folgenden unter Bezugnahme auf 4 diskutiert wird, ist vorzugsweise ein JAVA^TM-Servlet, das auf dem HTTP-Server 46 arbeitet, kann aber alternativ ein anderer Mechanismus auf der Seite des Servers sein, wie ein CGI-Skript. Das ETLS-Servlet 48 ist vorzugsweise auf dem HTTP-Server 46 mit seiner eigenen URL (Uniform Resource Locator) installiert, die zu einem spezifischen HTTP-Antwort-Header zusammen mit einem öffentlichen ETLS-Schlüssel hinzugefügt wird.
In Schritt 50 versucht der Client 42, eine sichere Verbindung mit dem Server 44 herzustellen. Zu diesem Punkt hat der Client 42 das ETLS-Servlet 48 noch nicht erfasst und verwendet deswegen ein nicht-proprietäres Sicherheitsprotokoll, wie das TLS-Protokoll. Der vierfache TLS-Handshake, der oben unter Bezugnahme auf 1 diskutiert wird, wird in den Schritten 50–56 durchgeführt. In den Schritten 50 und 52 bestimmen der Client 42 und der Server 44, welche Operationen oder Sprachen sie gemeinsam haben und ein öffentlicher TLS-Schlüssel in einem digitalen Zertifikat wird an den Client 42 übertragen. In den Schritten 54 und 56 wird ein zufälliger TLS-Sitzungsschlüssel verhandelt. Dann wird in Schritt 58 die anfängliche Dienstanforderung von dem Client 42 mit dem TLS-Sitzungsschlüssel verschlüsselt und an den HTTP-Server 46 übertragen. Der HTTP-Server 46 entschlüsselt die Dienstanforderung und überträgt seine anfängliche verschlüsselte Antwort in Schritt 60. Zusammen mit den verschlüsselten Daten umfasst die anfängliche Antwort 60 von dem HTTP-Server 46 auch den spezifischen HTTP-Antwort-Header mit der URL des ETLS-Servlets 48 und den öffentlichen ETLS-Schlüssel. Der öffentliche ETLS-Schlüssel wird vorzugsweise von dem ETLS-Servlet 48 erzeugt und weist einen zugehörigen privaten ETLS-Schlüssel auf, der ausschließlich von dem ETLS-Servlet 48 geführt wird. Der Client 42 speichert vorzugsweise den öffentlichen ETLS-Schlüssel und die zugehörige URL in einem Speicherort auf der mobilen Vorrichtung. Danach verwendet der Client 42 jedes Mal, wenn er eine sichere Verbindung mit dem Server 44 herstellt, den öffentlichen ETLS-Schlüssel und die zugehörige URL, um durch das ETLS-Servlet 48 zu kommunizieren.
Die Schritte 62–68 zeigen zwei sichere ETLS-Übertragungen zwischen dem Client 42 und dem Server 44, nachdem der öffentliche ETLS-Schlüssel und die zugehörige URL von dem Client 42 empfangen und gespeichert wurden. Um eine sichere Verbindung unter Verwendung des ETLS-Protokolls herzustellen, stellt der Client 42 zuerst einen zufälligen ETLS-Sitzungsschlüssel her und verschlüsselt ihn mit dem von dem spezifischen HTTP-Antwort-Header empfangenen öf fentlichen ETLS-Schlüssel. Der Client 42 verwendet dann den ETLS-Sitzungsschlüssel, um die Datenmenge zu verschlüsseln, die seine Dienstanforderung an den Server 44 darstellt, und um ebenso einen digitalen Zeitstempel zu verschlüsseln. In Schritt 62 überträgt der Client 42 die Daten an das ETLS-Servlet, vorzugsweise in der Form einer HTTP-POST-Anforderung, die den verschlüsselten Sitzungsschlüssel, die Dienstanforderung und den Zeitstempel umfasst. Sobald das ETLS-Servlet 48 die HTTP-POST-Anforderung empfangen hat, wird die Anforderung entschlüsselt und mit einem Verbindungs-Protokoll (Log) verglichen, um festzustellen, dass die Übertragung originär ist. Zu diesem Punkt ist die Sicherheit der Kommunikation hergestellt und das ETLS-Servlet 48 kann eine Fetch-Antwort-Operation mit dem HTTP-Server 46 durchführen. Sobald eine Antwort von dem HTTP-Server 46 zurückgesendet wurde, verschlüsselt das ETLS-Servlet 48 die Antwort mit dem ETLS-Sitzungsschlüssel und überträgt sie in Schritt 64 an den Client 42. Das ETLS-Protokoll einschliesslich der Operationen des digitalen Zeitstempels und des Verbindungs-Logs wird im Folgenden detaillierter unter Bezugnahme auf 4 diskutiert.
Die Schritte 66 und 68 zeigen, dass jede nachfolgende Kommunikation zwischen dem Client 42 und dem Server 44 unter Verwendung desselben zweistufigen ETLS-Handshakes, der oben unter Bezugnahme auf die Schritte 62 und 64 beschrieben wird, durchgeführt werden kann. Auf diese Weise ermöglicht das ETLS-Protokoll sichere Kommunikationen zwischen einer mobilen Vorrichtung und einem Internet-Server ohne die Notwendigkeit der sehr langen mehrfachen Übertragungen, die normalerweise zu nicht-proprietären Sicherheitsprotokollen, wie dem TLS-Protokoll, gehören.
4 ist eine Blockdarstellung eines beispielhaften ETLS-Systems 70, das eine sichere Verbindung zwischen einer mobilen Vorrichtung 72 und einem primären Server 74 unter Verwendung des ETLS-Protokolls darstellt. Unter Querverweis auf die 3 und 4 stellt das in 4 gezeigte ETLS-System 70 die in den Schritten 62–68 von 3 durchgeführten Verbindungen dar und danach die in den Schritten 50–60 von 3 gezeigte anfängliche TLS-Verbindung. Das ETLS-System 70 umfasst die mobile Vorrichtung 72, den primären Server 74, ein drahtloses Gateway 76, das ETLS-Servlet 78 und das Verbindungs-Log 80. Der primäre Server 74, das ETLS-Servlet 78 und das Verbindungs-Log 80 befinden sich auf einem Computernetzwerk, wie dem Internet, und sind vorzugsweise hinter einer gemeinsamen Firewall 82 geschützt. Kommunikationen zwischen der mobilen Vorrichtung 72 und dem Computernetz werden vorzugsweise durch das drahtlose Gateway 76 unter Verwendung jeder bekannten Web-Browser-Typ-Software durchgeführt, die zur Verwendung auf einer mobilen Vorrichtung vorgesehen ist. Die mobile Vorrichtung 72 umfasst vorzugsweise ein ETLS-Softwaremodul 71, das konfiguriert ist, eine sichere Verbindung mit dem Computernetz unter Verwendung entweder des ETLS-Protokolls oder eines nicht-proprietären Sicherheitsprotokolls, wie dem TLS-Protokoll, aufzubauen.
Um eine Dienstanforderung an den primären Server 74 unter Verwendung des ETLS-Protokolls zu senden, stellt die mobile Vorrichtung 72 vorzugsweise einen zufälligen ETLS-Sitzungsschlüssel her, den sie verwendet, um die Dienstanforderung zu verschlüsseln, und verschlüsselt den Sitzungsschlüssel unter Verwendung des gespeicherten öffentlichen ETLS-Schlüssels für das ETLS-Servlet 78. Zusätzlich wird, um gegen „Wiederholungs"-Kommunikationen zu schützen, vorzugsweise ein elektronischer Zeitstempel von der mobilen Vorrichtung erzeugt und unter Verwendung des ETLS-Sitzungsschlüssels verschlüsselt. Dann werden die verschlüsselte Dienstanforderung, der Sitzungsschlüssel und der Zeitstempel zusammen in einer HTTP-POST-Anforderung oder einem anderen geeigneten Übertragungsmechanismus zusammengefasst und durch das drahtlose Gateway 76 an das ETLS-Servlet 78 übertragen.
Wenn die HTTP-POST-Anforderung an dem ETLS-Servlet 78 empfangen wird, wird der ETLS-Sitzungsschlüssel vorzugsweise mit dem privaten ETLS-Schlüssel entschlüsselt, der von dem ETLS-Servlet 78 geführt wird. Der ETLS-Sitzungsschlüssel wird dann von dem ETLS-Servlet 78 verwendet, um die Dienstanforderung und den Zeitstempel zu entschlüsseln. Vorzugsweise wurde von der mobilen Vorrichtung 72 ein digitales Zertifikat von dem primären Server 74 empfangen und gespeichert, als diese zuerst den primären Server 74 unter Verwendung eines nicht-proprietären Sicherheitsprotokolls kontaktierte. Somit wurde die Identität des primären Servers 74 bereits verifiziert. Die Verbindung ist jedoch noch nicht sicher, da kein mehrfacher Handshake, wie der TLS-Handshake, verwendet wurde, um den ETLS-Sitzungsschlüssel zu verhandeln und festzustellen, dass die Übertragung originär ist. Das ETLS-Servlet 78 schützt somit vorzugsweise gegen „Wiederholungs"-Kommunikationen durch Vergleich der entschlüsselten Dienstanforderung und des Zeitstempels mit früheren Übertragungen, die in dem Verbindungs-Log 80 gespeichert sind. Auf diese Weise erkennt das ETLS-Servlet 78, wenn es eine verschlüsselte HTTP-POST-Anforderung empfängt, die eine Dienstanforderung und einen Zeitstempel umfasst, die identisch zu der einer in dem Kommunikations-Log gespeicherten früheren Übertragung ist, dass die Dienstanforderung keine originäre (ursprüngliche) Kommunikation ist und ignoriert vorzugsweise die Dienstanforderung. In einem bevorzugten Ausführungsbeispiel speichert das Kommunikations-Log alle von dem ETLS-Servlet 78 in einer vorgegebenen Zeitdauer empfangenen Dienstanforderungen und Zeitstempel. Alternativ kann das ETLS-Servlet 78 nur die Zeitstempel oder andere Daten, wie eine Ordinalzahl, speichern, welche die Originalität der Übertragung anzeigen.
Sobald die HTTP-POST-Anforderung von dem ETLS-Servlet 78 entschlüsselt und mit den in dem Verbindungs-Log 80 gespeicherten früheren Übertragungen verglichen wurde, ist eine sichere Verbindung zwischen der mobilen Vorrichtung und dem ETLS-Servlet 78 hergestellt. Die entschlüsselte Dienstanforderung kann dann von dem ETLS-Servlet 78 an den primären Server 74 übertragen werden, der die gewünschte Operation ausführt und eine Antwort an das ETLS-Servlet 78 zurücksendet. Da das ETLS-Servlet 78 und der primäre Server 74 hinter der gemeinsamen Firewall 82 arbeiten, können die nicht verschlüsselten Daten unter Verwendung eines standardmäßigen Übertragungsprotokolls, wie HTTP, sicher übertragen werden. Sobald die Antwort von dem primären Server 74 von dem ETLS-Servlet 78 empfangen wird, wird sie mit dem ETLS-Sitzungsschlüssel verschlüsselt und durch das drahtlose Gateway 76 an die mobile Vorrichtung 72 übertragen. An der mobilen Vorrichtung 72 wird die Antwort mit dem Sitzungsschlüssel entschlüsselt. Dann kann, wenn eine neue Dienstanforderung gewünscht wird, ein neuer Sitzungsschlüssel von der mobilen Vorrichtung 72 erzeugt werden und der oben beschriebene Vorgang wird wiederholt.
5 ist ein Flussdiagramm eines beispielhaften Verfahrens zur sicheren Kommunikation zwischen einer mobilen Vorrichtung und einem Netzwerk-Server unter Verwendung des ETLS-Protokolls. Das Verfahren beginnt in Schritt 92, in dem eine Kommunikation zwischen einer mobilen Vorrichtung und einem Netzwerk-Server, der auf einem Computer-Netzwerk, wie dem Internet, arbeitet, hergestellt wird. Sobald eine Kommunikation mit dem Computer-Netzwerk hergestellt wurde, greift die mobile Vorrichtung in Schritt 100 vorzugsweise auf einen internen Speicherort zu, um festzustellen, ob ein öffentlicher ETLS-Schlüssel und eine ETLS-Servlet-URL früher für den bestimmten Netzwerk-Server gespeichert wurden. Wenn dem so ist, erkennt die mobile Vorrichtung, dass eine sichere Verbindung unter Verwendung eines ETLS-Servlets, das in Verbindung mit dem Server arbeitet, hergestellt werden kann und ein ETLS-Handshake wird beginnend bei Schritt 108 durchgeführt. Wenn jedoch die mobile Vorrichtung keine gespeicherte ETLS-URL und keinen öffentlichen Schlüssel für den Server aufweist, sollte vorzugsweise ein sicherer Socket geöffnet werden unter Verwendung eines nicht-proprietären Sicherheitsprotokolls, wie das TLS-Protokoll (Schritt 102). Nachdem ein sicherer Socket mit dem Server verhandelt wurde, kann die mobile Vorrichtung eine verschlüsselte Dienstanforderung senden, auf die der Server mit einer verschlüsselten TLS-Antwort antworten kann (Schritt 104). Wenn der Ser ver mit einem ETLS-Servlet ausgestattet ist (Schritt 106), dann umfasst die von dem Server in Schritt 104 gesendete TLS-Antwort vorzugsweise einen spezifischen HTTP-Antwort-Header, der den öffentlichen ETLS-Schlüssel und die zugehörige URL für das ETLS-Servlet identifiziert, der in Schritt 107 auf der Vorrichtung gespeichert wird. Die Vorrichtung wartet dann auf eine Anforderung für die nächste Verbindung in Schritt 109. Wenn der Server jedoch nicht mit einem ETLS-Servlet ausgestattet ist (Schritt 106), wartet die Vorrichtung vorzugsweise bis die Vorrichtung die nächste Verbindung in Schritt 109 anfordert.
In Schritt 108 beginnt die mobile Vorrichtung vorzugsweise den ETLS-Handshake durch Erzeugen eines Sitzungsschlüssels und dessen Verschlüsseln mit dem öffentlichen ETLS-Schlüssel, der vorher von dem Server in dem spezifischen HTTP-Antwort-Header empfangen wurde. In Schritt 110 werden sowohl die Dienstanforderung von der mobilen Vorrichtung als auch ein digitaler Zeitstempel unter Verwendung des Sitzungsschlüssels verschlüsselt (Schritt 110). Der digitale Zeitstempel umfasst vorzugsweise die Zeit und das Datum, zu der die Übertragung stattfindet. Dann werden in Schritt 112 die verschlüsselte Dienstanforderung, der Zeitstempel und der Sitzungsschlüssel an das ETLS-Servlet übertragen, vorzugsweise in der Form einer HTTP-POST-Anforderung oder eines anderen geeigneten Übertragungsmechanismus.
Wenn die HTTP-POST-Anforderung von dem ETLS-Servlet empfangen wird, wird der ETLS-Sitzungsschlüssel unter Verwendung eines privaten Schlüssels entschlüsselt, der ausschließlich von dem ETLS-Servlet geführt wird, und der entschlüsselte Sitzungsschlüssel wird dann verwendet, um die Dienstanforderung und den digitalen Zeitstempel zu entschlüsseln (Schritt 114). In Schritt 116 wird der digitale Zeitstempel mit denen früherer Übertragungen verglichen, die in einem Verbindungs-Log gespeichert sind, das von dem ETLS-Servlet geführt wird. Wenn der Zeitstempel mit einem einer in dem Verbindungs-Log gespeicherten früheren Übertragung übereinstimmt, ist die Übertragung nicht originär (Schritt 118) und die Dienstanforderung wird von dem ETLS-Servlet vorzugsweise ignoriert (Schritt 120). Wenn jedoch die Übertragung originär ist (Schritt 118), dann wird der digitale Zeitstempel in dem Verbindungs-Log gespeichert (Schritt 122), um zu verhindern, dass die Übertragung in nachfolgenden Kommunikationen wiederholt wird. In alternativen Ausführungsbeispielen können sowohl der Zeitstempel als auch die Dienstanforderung in dem Verbindungs-Log gespeichert und mit der HTTP-POST-Anforderung verglichen werden oder der Zeitstempel kann durch ein anderes Mittel ersetzt werden, um zu bestimmen, ob die Anforderung originär ist, wie eine Ordinalzahl.
In Schritt 124 ist eine sichere Verbindung hergestellt und eine Fetch-Antwort-Operation wird zwischen dem ETLS-Servlet und dem Server durchgeführt, um die Funktion durchzuführen, die in der Dienstanforderung von der mobilen Vorrichtung angegeben wird. Dann wird in Schritt 126 die Antwort von dem Server von dem ETLS-Servlet unter Verwendung des Sitzungsschlüssels verschlüsselt und an die mobile Vorrichtung übertragen. Die Antwort wird von der mobilen Vorrichtung in Schritt 128 entschlüsselt und eine neue Dienstanforderung kann dann von der mobilen Vorrichtung in Schritt 109 initiiert werden.
Die hier beschriebenen Ausführungsbeispiele sind Beispiele von Strukturen, Systemen oder Verfahren mit Elementen, die den Elementen der in den Ansprüchen rezitierten Erfindung entsprechen. Diese geschriebene Beschreibung kann Fachleuten ermöglichen, Ausführungsbeispiele mit alternativen Elementen herzustellen und zu verwenden, die gleichfalls den Elementen der in den Ansprüchen rezitierten Erfindung entsprechen.

Claims

Verfahren zur sicheren Kommunikation zwischen einer mobilen Vorrichtung (72) und einem sich in einem Computernetzwerk in Betrieb befindenden Server (44, 46, 76), welches die folgenden Schritte umfasst: – Bereitstellen eines sich in einem Computernetzwerk in Betrieb befindenden Sicherheitsservlets (48, 78), wobei das Sicherheitsservlet mit dem Server über einen sicheren Anschluss kommuniziert und durch eine eindeutige Adresse im Computernetzwerk identifiziert wird, – Einrichten einer drahtlosen Verbindung zwischen der mobilen Vorrichtung und dem Computernetzwerk; – Einrichten einer sicheren Verbindung (50, 52, 54, 56) zwischen der mobilen Vorrichtung (72) und dem Server (44, 46, 74) unter Verwendung eines nicht-proprietären Sicherheitsprotokolls; – Senden einer ersten verschlüsselten Serviceanforderung (58) von der mobilen Vorrichtung an den Server (44, 46, 74) über das nicht-proprietäre Sicherheitsprotokoll; wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist: – Senden einer ersten verschlüsselten Antwort (60) vom Server an die mobile Vorrichtung, welche die eindeutige Adresse des Sicherheitsservlets (48, 78) im Computernetzwerk enthält; – Senden einer zweiten verschlüsselten Serviceanforderung (62) von der mobilen Vorrichtung an das Sicherheitsservlet (48, 78) unter Verwendung der eindeutigen Adresse des Sicherheitsservlets; – Entschlüsseln der zweiten verschlüsselten Serviceanforderung durch das Sicherheitsservlet (48, 78), um eine entschlüsselte Serviceanforderung zu erzeugen; – Übermitteln der entschlüsselten Serviceanforderung vom Sicherheitsservlet (48, 78) an den Server (44, 46, 74).
Verfahren nach Anspruch 1, wobei die zweite verschlüsselte Serviceanforderung unter Verwendung eines proprietären Sicherheitsprotokolls verschlüsselt wird.
Verfahren nach einem der Ansprüche 1 oder 2, umfassend den zusätzlichen Schritt: Speichern der eindeutigen Adresse des Sicherheitsservlets in einer Speicheradresse der mobilen Vorrichtung.
Verfahren nach einem der Ansprüche 1 bis 3, umfassend den zusätzlichen Schritt: Empfang eines digitalen Zertifikats vom Server unter Verwendung des nicht-proprietären Sicherheitsprotokolls.
Verfahren nach einem der Ansprüche 1 bis 4, wobei die eindeutige Adresse des Sicherheitsservlets im Computernetzwerk eine Internetadresse (uniform resource locator), URL, ist.
Verfahren nach einem der Ansprüche 1 bis 5, wobei das nicht-proprietäre Sicherheitsprotokoll das Transportschicht-Sicherheitsprotokoll (TLS-Protokoll) ist.
Verfahren nach einem der Ansprüche 1 bis 5, wobei das nicht-proprietäre Sicherheitsprotokoll das SSL-Protokoll ist
Verfahren nach einem der Ansprüche 1 bis 7, wobei die erste verschlüsselte Antwort vom Server einen speziellen HTTP-Antwortkopf enthält, der die eindeutige Adresse des Sicherheitsservlets im Computernetzwerk identifiziert.
Verfahren nach einem der Ansprüche 1 bis 8, wobei die entschlüsselte Serviceanforderung vom Sicherheitsservlet an den Server unter Verwendung einer Hypertextübertragungsprotokoll-Verbindung (HTTP-Verbindung) übertragen wird.
Verfahren nach einem der Ansprüche 1 bis 9, wobei eine Vielzahl zusätzlicher verschlüsselter Serviceanforderungen von der mobilen Vorrichtung an das Sicherheitsservlet gesendet, vom Sicherheitsservlet entschlüsselt und an den Server übertragen werden.
Verfahren nach einem der Ansprüche 1 bis 10, umfassend den zusätzlichen Schritt: Überprüfen der Echtheit der zweiten verschlüsselten Serviceanforderung durch deren Vergleich mit einer Verbindungsprotokolldatei, die vom Sicherheitsservlet geführt wird.
Verfahren nach einem der Ansprüche 1 bis 11, wobei ein verschlüsselter aktueller Zeitstempel von der mobilen Vorrichtung an das Sicherheitsservlet zusammen mit der zweiten verschlüsselten Serviceanforderung geschickt wird, und welches den zusätzlichen Schritt umfasst: Überprüfen der Echtheit der zweiten verschlüsselten Serviceanforderung durch Entschlüsseln des verschlüsselten aktuellen Zeitstempels und dessen Vergleich mit einer Verbindungsprotokolldatei, die durch das Sicherheitsservlet geführt wird.
Verfahren nach einem der Ansprüche 1 bis 12, wobei die drahtlose Verbindung zwischen der mobilen Vorrichtung und dem Computernetzwerk durch ein drahtloses Netzwerk bewerkstelligt wird.
Verfahren nach einem der Ansprüche 1 bis 13, wobei – die erste verschlüsselte Antwort vom Server auch einen öffentlichen Schlüssel enthält; – das Sicherheitsservlet einen privaten Schlüssel besitzt, der so konfiguriert ist, dass er Daten entschlüsselt, die unter Verwendung des öffentlichen Schlüssels verschlüsselt worden sind; und – die zweite verschlüsselte Serviceanforderung durch die mobile Vorrichtung unter Verwendung des öffentlichen Schlüssels verschlüsselt und durch das Sicherheitsservlet unter Verwendung des privaten Schlüssels entschlüsselt wird.
Verfahren nach Anspruch 14, wobei der Sendeschritt der zweiten verschlüsselten Serviceanforderung von der mobilen Vorrichtung an das Sicherheitsservlet die folgenden zusätzlichen Schritte umfasst: – Erzeugung eines Einmalschlüssels (session key); – Verschlüsseln einer Serviceanforderung durch den Einmalschlüssel; – Verschlüsseln des Einmalschlüssels durch den öffentlichen Schlüssel; – Einkapseln der verschlüsselten Serviceanforderung und des verschlüsselten Einmalschlüssels in einen Übertragungsmechanismus um die nachfolgende verschlüsselte Serviceanforderung zu bilden; und – Übertragen der nachfolgenden verschlüsselten Serviceanforderung von der mobilen Vorrichtung zum Sicherheitsservlet; – wobei der verschlüsselte Einmalschlüssel durch das Sicherheitsservlet unter Verwendung des privaten Schlüssels entschlüsselt und die verschlüsselte Serviceanforderung durch das Sicherheitsservlet unter Verwendung des Einmalschlüssels entschlüsselt wird, und wobei die Serviceanforderung vom Sicherheitsservlet zum Server übermittelt wird.
Verfahren nach Anspruch 15, wobei ein aktueller Zeitstempel gleichfalls durch den Einmalschlüssel verschlüsselt und in der nachfolgenden verschlüsselten Serviceanforderung eingekapselt wird, und wobei der aktuelle Zeitstempel mit einer Verbindungsprotokolldatei durch das Sicherheitsservlet verglichen wird, um die Echtheit der nachfolgenden verschlüsselten Serviceanforderung zu überprüfen.
Verfahren nach einem der Ansprüche 15 oder 16, wobei die nachfolgende verschlüsselte Serviceanforderung in Form einer HTTP POST-Anforderung zum Sicherheitsservlet geschickt wird.
Verfahren nach einem der Ansprüche 15 bis 17, umfassend die folgenden zusätzlichen Schritte: – Erzeugen einer Antwort auf die Serviceanforderung am Server; – Übertragen der Antwort vom Server zum Servlet; – Verschlüsseln der Antwort unter Verwendung des Einmalschlüssels; – Senden der verschlüsselten Antwort vom Sicherheitsservlet zur mobilen Vorrichtung.
Erweitertes Transportschicht-Sicherheitssystem (ETLS-System) (70) für eine mobile Vorrichtung (72), umfassend: – einen sich in einem Computernetzwerk in Betrieb befindenden Primärserver (74), der so konfiguriert ist, dass er über das Computernetzwerk unter Verwendung eines nicht-proprietären Sicherheitsprotokolls kommuniziert; gekennzeichnet durch – ein sich in einem Computernetzwerk in Betrieb befindendes Sicherheitsservlet (78), das sicher an den Primärserver gekoppelt ist, wobei das Sicherheitsservlet so konfiguriert ist, dass es über das Computernetzwerk unter Verwendung eines proprietären Sicherheitsprotokolls kommuniziert; – ein sich in der mobilen Vorrichtung (72) in Betrieb befindendes ETLS-Software-Modul (71), das so konfiguriert ist, dass es über das Computernetzwerk unter Verwendung entweder des nicht-proprietären Sicherheitsprotokolls oder des proprietären Sicherheitsprotokolls kommuniziert; – wobei das ETLS-Software-Modul zuerst den Primärserver über das Computernetzwerk unter Verwendung des nicht-proprietären Sicher heitsprotokolls kontaktiert, um die eindeutige Adresse des Sicherheitsservlets im Computernetzwerk zu erhalten, und anschließend den Primärserver durch das Sicherheitsservlet unter Verwendung des proprietären Sicherheitsprotokolls kontaktiert.
System nach Anspruch 19, wobei das ETLS-Software-Modul mit dem Computernetzwerk über eine drahtlose Schnittstelle kommuniziert.
System nach einem der Ansprüche 19 oder 20, wobei das Sicherheitsservlet auf dem Primärserver installiert wird.
System nach einem der Ansprüche 19 bis 21, wobei das Computernetzwerk ein Internet ist.
System nach einem der Ansprüche 19 bis 21, wobei das Computernetzwerk ein Intranet ist.
System nach einem der Ansprüche 19 bis 23, wobei der Primärserver und das Sicherheitsservlet innerhalb des Computernetzwerks durch ein Zugangsschutzsystem (firewall) geschützt sind.
System nach einem der Ansprüche 19 bis 24, wobei das Sicherheitsservlet ein JAVA-Servlet ist.
System nach einem der Ansprüche 19 bis 25, wobei der Primärserver ein HTTP-Server ist.
System nach einem der Ansprüche 19 bis 26, wobei Kommunikationen, die vom Primärserver übertragen werden, einen Kopf beinhalten, welcher eine Internetadresse (URL) für das Sicherheitsservlet anzeigt.
System nach Anspruch 27, wobei der Kopf ein spezieller HTTP-Antwortkopf ist.
System nach einem der Ansprüche 19 bis 28, wobei die Kommunikationen, die vom Primärserver übermittelt werden, ein digitales Zertifikat beinhalten.
System nach einem der Ansprüche 19 bis 29, wobei das Sicherheitsservlet ermittelt, ob das Verschlüsselungssystem das Sicherheitsservlet enthält.
System nach einem der Ansprüche 19 bis 30, wobei der Primärserver ein öffentlich-privates Schlüsselpaar unterstützt, welches für das nicht-proprietäre Sicherheitsprotokoll spezifisch ist, und das Sicherheitsservlet ein öffentlich-privates Schlüsselpaar unterstützt, das für das proprietäre Sicherheitsprotokoll spezifisch ist.
System nach einem der Ansprüche 19 bis 31, weiter umfassend: eine Verbindungsprotokolldatei, die an den Primärserver gekoppelt ist, welche eine oder mehrere vorhergehende ETLS-Übertragungen speichert, welche vom Primärserver empfangen wurden, wobei der Primärserver die Verbindungsprotokolldatei benützt, um die Echtheit einer aktuellen ETLS-Übertragung zu überprüfen.
System nach einem der Ansprüche 19 bis 32, weiter umfassend: eine Verbindungsprotokolldatei, welche an den Primärserver gekoppelt ist, welche ein oder mehrere Zeitstempel speichert, die mit vorhergehenden ETLS-Übertragungen verknüpft sind, welche vom Primärserver empfangen wurden, wobei der Primärserver jeden gespeicherten Zeitstempel mit einem aktuellen Zeitstempel vergleicht, um die Echtheit einer aktuellen ETLS-Übertragung zu überprüfen.