DE10392208T5

DE10392208T5 - Mechanismus zum Unterstützten drahtgebundener und drahtloser Verfahren für eine client- und serverseitige Authentifizierung

Info

Publication number: DE10392208T5
Application number: DE10392208T
Authority: DE
Inventors: Koteshwerrao San Diego Adusumilli
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2002-01-12
Filing date: 2003-01-10
Publication date: 2004-12-23
Also published as: CN1615632B; TW200307439A; CN102143160A; US20030097592A1; US8601566B2; GB2399480B; GB0415250D0; WO2003061246A1; AU2003214827A1; GB2399480A; HK1065196A1; CN102143160B; CN1615632A

Abstract

Verfahren, das folgende Schritte umfaßt:
Senden einer Nachricht von einem Client zu einem Server, wobei die Nachricht dazu bestimmt ist, eine gesicherte Verbindung aufzubauen;
Abfangen der Daten an einem Sicherheitssystem, das dem Server zugeordnet ist, um Authentifizierungsfunktionen durchzuführen; und
Ausbauen einer gesicherten Verbindung, wenn richtige Authentifizierungen durchgeführt werden.

Description

Verwandte Anmeldungen
Dieser Anmeldung ist eine continuation-in-part der parallelen US-Patentanmeldung Nr. 10/000.154 mit dem Titel "Selecting a Security Format Convertierung for Wired and Wireless Devices" ("Auswählen einer Sicherheitsformatkonvertierung für drahtgebundene und drahtlose Einrichtungen"), eingereicht am 23. Oktober 2001, deren Priorität beansprucht wird.
Urheberrechtshinweis
Ein Teil der Offenbarung dieser Patentunterlagen enthalten Material, welches dem Urheberrechtsschutz unterliegt. Der Inhaber des Urheberrechts hat keine Einwendungen gegen die Reproduktion der Patentunterlagen oder der Patentoffenbarung, wie sie in der Akte oder den Aufzeichnungen des Patent- und Markenamts erscheinen. Darüber hinaus sind jedoch alle Urheberrechte vorbehalten. Der folgende Hinweis bezieht sich auf die Software und die Daten, wie sie nachfolgend und den beigefügten Zeichnungen beschrieben werden: Copyright 2001, Intel Corporation, alle Rechte vorbehalten.
Gebiet der Erfindung
Die Erfindung bezieht sich allgemein auf das Erweitern der Möglichkeiten der Netzwerksicherheit und insbesondere auf einen Mechanismus zum Unterstützen drahtgebundener und drahtloser Architekturen für clientseitige Zertifizierungen und serverseitige Zertifizierungen.
Hintergrund der Erfindung
Der Bedarf an sicheren, skalierbaren und flexiblen Internetanwendungen und -dienstleistungen steigt in der drahtlosen Welt enorm an. Seit drahtlose Internetanwendungen üblich wurden, gibt es eine große Chance für Anwendungen, mit denen Authentifikationen und Verschlüsselungsmechanismen gehandhabt werden können, sowie sicherheitsbezogene Funktionen beschleunigt werden können.
In der drahtlosen Internetwelt sorgt Wireless-Transport-Layer-Security (WTLS) für Datenschutz und Integrität für Kommunikationen unter Verwendung von Verschlüsselungs- und Authentifizierungsfunktionen. Das WTLS-Handshake-Protokoll des WAP (Wireless Access Protocol) Forum baut eine gesicherte Verbindung zwischen dem Client und dem Server auf, indem dem Server ermöglicht wird, sich selbst dem Client gegenüber durch Übersenden seines Zertifikats zu authentifizieren. Genauso kann der Client sich selbst durch Senden seines Zertifikats (oder einem Link davon) authentifizieren, wenn eine Clientauthentifizierung von dem Server angefordert wird.
In der drahtgestützten Internetwelt kann zur Sicherheit in der Form von SSL (Secure Sockets Layer) gesorgt werden. SSL ist ein Protokoll, das Authentifizierungen des Clients und/oder des Servers sowie eine Verschlüsselung während der Kommunikationssitzung unterstützt.
Da jede Netzwerkgeneration ausgefeilter wird, müssen Anwendungen sowohl für das drahtgestützte wie auch für das drahtlose Internet sicher sein. Bei dem aktuellen Stand der Technik des drahtlosen Internets können sicherheitsbezogene Funktionen bei einem WAP-Gateway stattfinden. Dies liefert jedoch keine End-to-End-Lösung, da bei einer Benutzeranfrage, die bei der WAP-Gateway abgefangen wird, zwar der Benutzer die Gateway autorisieren kann, nicht jedoch den Server.
Eine Lösung dieses Problems und eine Lösung für das drahtgebundene Internet ist es, sicherheitsbezogene Funktionen auf die Server in diesem^` Netzwerken abzuladen, um die sicherheitsrelevanten Dinge, einschließlich dem Verschlüsseln und Authentifizieren, zu handhaben. Dadurch verbleibt dem Server jedoch eine geringere Rechenleistung zur Datenverarbeitung und für den Inhalt, der z. B. an Clients geliefert wird.
Obgleich einige Anbieter sicherheitsbezogene Funktionen außerhalb des Servers zur Verfügung stellen, bieten diese Lösungen nur unvollständige Sicherheitslösungen. Obgleich beispielsweise nChiper von Woburn, Massachusetts, einen Verschlüsselungsdienst außerhalb des Servers zur Verfügung stellt, bietet es keinen Authentifizierungsdienst an.
Kurze Zusammenfassung der Zeichnungen
Die vorliegende Erfindung wird in den Figuren und den beigefügten Zeichnungen im Wege eines Beispiels und nicht im Sinne einer Beschränkung dargestellt, wobei sich gleiche Bezugszeichen sich auf vergleichbare Elemente beziehen.
1 zeigt ein Sicherheitssystem mit einem Datenzentrum entsprechend einer Ausführungsform.
2 zeigt einen WAP-Stapel gemäß einer Ausführungsform.
3 zeigt eine Systemarchitektur gemäß einer Ausführungsform.
4 zeigt ein Verfahren zum Betreiben eines Sicherheitssystems gemäß einer Ausführungsform.
5 zeigt eine WTLS-Sicherheitsprotokollarchitektur gemäß einer Ausführungsform.
6 zeigt ein WTLS-Handshake gemäß einer Ausführungsform.
7 zeigt eine Client-Hello-Nachricht gemäß einer Ausführungsform.
8 zeigt ein Sicherheitssystem gemäß einer Ausführungsform.
9 zeigt eine Architektur eines Datenzentrum gemäß einer Ausführungsform.
10 zeigt ein Sicherheitssystem gemäß einer Ausführungsform.
11 zeigt ein Flußdiagramm, das ein Verfahren zum Aufbau eines Handshakes zwischen einem Client und einem Server entsprechend allgemeiner Ausführungsformen der Erfindung darstellt.
12 ist ein Pseudocode zum Aufbau eines Handshakes zwischen einem Client und einem Server gemäß allgemeinen Ausführungsformen der Erfindung.
13 stellt eine Systemarchitektur zur drahtgegebundenen und drahtlosen Authentifizierung entsprechend allgemeiner Ausführungsformen der Erfindung dar:
14 stellt eine alternative Systemarchitektur zur drahtgebundenen und drahtlosen Authentifizierung gemäß allgemeinen Ausführungsformen der Erfindung dar.
15 ist ein Diagramm, das einen Arbeitsablauf für eine serverseitige Zertifizierung sowohl für drahtgebundene wie auch für drahtlose Clients darstellt.
16 ist ein Flußdiagramm, das ein Verfahren zur serverseitigen Zertifizierung gemäß allgemeinen Ausführungsformen der Erfindung darstellt.
17 ist ein Flußdiagramm, das ein Verfahren zur serverseitigen Zertifizierung für drahtlose Clients darstellt.
18 ist ein Flußdiagramm, das ein Verfahren zur serverseitigen Zertifizierung für drahtgebundene Clients darstellt.
19 ist ein Diagramm, das einen Arbeitsablauf für eine clientseitige Zertifizierung für sowohl drahtgebundene wie auch drahtlose Clients darstellt.
20 ist ein Flußdiagramm, das ein Verfahren zur clientseitigen Zertifizierung gemäß allgemeinen Ausführungsformen der Erfindung darstellt.
21 ist ein Flußdiagramm, das ein Verfahren zur clientseitigen Zertifizierung für drahtlose Clients darstellt.
22 ist ein Flußdiagramm, das ein Verfahren zur clientseitigen Zertifizierung für drahtgebundene Clients darstellt.
23 ist ein Diagramm, das ein Sicherheitssystem gemäß allgemeinen Ausführungsformen der Erfindung darstellt.
24 stellt eine Beispielkonfiguration eines Sicherheitssystems dar.
Detaillierte Beschreibung der Erfindung
Ein Aspekt der Erfindung ist ein Verfahren zum Einbeziehen von Sicherheitsfunktionen, einschließlich Verschlüsseln und Authentifizieren, in einer einzelnen Netzwerkeinrichtung für sowohl das drahtgebundene wie auch das drahtlose Internet, so daß Server von dieser Funktion und der Notwendigkeit, auf die unterschiedlichen Sicherheitsstandards und Authentifizerungsmechanismen Rücksicht zu nehmen, befreit werden.
Das Verfahren umfaßt das Senden einer Nachricht von einem Client zu einem Server zum Ausbauen einer sicheren Verbindung. Die Nachricht wird von einem Sicherheitssystem abgefangen, das dem Server zugeordnet ist. Das Sicherheitssystem führt Authentifizierungsfunktionen, einschließlich der Authentifizierung des Clients, sowie Unterstützungsfunktionen für die Authentifizierung des Servers durch. Wenn die Authentifizierungsfunktionen korrekt vorgenommen werden, wird anschließend eine sichere Verbindung aufgebaut.
Der Ausdruck Internet kann, wie er hierin benutzt wird, ein internes Netzwerk, das als ein Satz von Computernetzwerken definiert ist, die verschieden sein können und mittels Gateways miteinander verbunden sind, welche die Datenübertragung und die Konvertierung von Nachrichten von den sendenden Netzwerkprotokollen zu denen des empfangenden Netzwerks durchführen; ein Internet, welches ein privates Netzwerk ist, das auf Internetprotokollen, wie TCP/IP beruht, jedoch für ein Informationsmanagement innerhalb eines Unternehmens oder einer Organisation konstruiert ist; oder das Internet, welches als eine weltweite Ansammlung von Netzwerken und Gateways definiert ist, welche den TCP/IP-Satz von Protokollen benutzt, um mit den anderen zu kommunizieren, umfassen.
In der folgenden Beschreibung werden nur zum Zweck der Darstellung viele spezielle Details dargestellt, um ein vollständiges Verständnis der vorliegenden Erfindung zu liefern. Es wird jedoch für den Fachmann deutlich, daß die vorliegende Erfindung ohne einige dieser speziel len Details ausgeführt werden kann. In anderen Fällen werden gut bekannte Strukturen und Vorrichtungen in Form von Blockdiagrammen gezeigt.
Die vorliegende Erfindung umfaßt verschiedene Abläufe, die nachfolgend beschrieben werden. Die Abläufe der vorliegenden Erfindung können durch Hardwarekomponenten ausgeführt werden oder in maschinenausführbaren Befehlen implementiert sein, die benutzt werden können, um die Ausführungen der Abläufe auf einem Prozessor für allgemeine Zwecke oder für Spezialzwecke oder auf einer Logikschaltung, die mit den Befehlen programmiert ist, hervorzurufen. Alternativ können die Befehle durch eine Kombination von Hardware und Software ausgeführt werden.
Die vorliegende Erfindung kann als ein Computerprogrammprodukt zur Verfügung gestellt werden, welches ein maschinenlesbares Medium mit darauf gespeicherten Befehlen umfaßt, die benutzt werden können, um einen Computer (oder andere Elektronikeinrichtungen) zu programmieren, um ein Verfahren gemäß der vorliegenden Erfindung auszuführen. Das maschinenlesbare Medium kann Floppydisks, optische Disketten, CD-ROMs (Compact Disc-Read Only Memories) und magneto-optische Disketten, ROMs (Read Only Memories), RAMs (Random Access Memories), EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electromagnetic Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash Memory oder andere Arten von Meiden oder maschinenlesbaren Medien, die zum Speichern elektronischer Befehle geeignet sind, umfassen, wobei die Aufzählung nicht abschließend ist.
Darüber hinaus kann die vorliegende Erfindung auch als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z. B. einem Server) zu einem anfragenden Computer (z. B. einem Client) mittels Datensignalen, die in einer Trägerwelle oder anderen Propagationsmedien eingebettet sind, über eine Kommunikationsverbindung (z. B. einem Modem oder einer Netzwerkanbindung) übertragen werden. Demgemäß soll hierin eine Trägerwelle als von einem maschinenlesbares Medium umfaßt betrachtet werden.
Einleitung
1 zeigt ein vereinfachtes Blockdiagramm eines sicheren Kommunikationssystems 100. Wie hierin diskutiert, kann ein System, wie ein System zum Auswählen einer Sicherheitsformatkonvertierung, eine Vorrichtung sein, die Hardware, Software oder irgendeine Kombination von Hardware und Software zur Datenverarbeitung umfaßt. Das System 100 umfaßt eine Netzwerkzugriffseinrichtung 110, die mit einem Datenzentrum 150 über ein öffentliches Netzwerk 120 zur Kommunikation verbunden ist, um eine Angabe (Indikation) eines sicheren Formats 130 und sicherer Daten 140 zu dem Datenzentrum 150 zu liefern. Das Datenzentrum 150 umfaßt ein Sicherheitssystem 160 mit einem Auswahlsystem 170, um eine Sicherheitskonvertierung auf Grundlage der Angabe 130 auszuwählen, und ein Konvertierungssystem 180, um die ausgewählte Sicherheitskonvertierung auf den sicheren Daten 140 auszuführen.
Die Netzwerkzugriffseinrichtung 110 kann irgendeine elektronische Einrichtung sein, die mit einem Netzwerk 120 verbunden werden kann und über dieses Daten übertragen kann. Die Zugriffseinrichtung 110 kann beispielsweise eine drahtgebundene Einrichtung (z. B. ein Personalcomputer oder eine Workstation) oder eine drahtlose Einrichtung (z. B. ein Laptop, ein Personal Digital Assistant (PDA), ein Handy, ein Pager, ein Smartphone oder ein Kommunikator) sein. Typischerweise verwenden drahtgebundene Einrichtung andere Sicherheitsformate oder Protokolle als drahtlose Einrichtungen, um auf einen größeren Speicher, den Prozessor und Bandbreitenressourcen Rücksicht zu nehmen.
Das öffentliche Netzwerk 120 kann ein beliebiges Netzwerk sein, das wenigstens einen nicht privaten Teil umfaßt, den sich Einheiten teilen, die von der Netzwerkzugriffseinrichtung 110 und dem Datenzentrum 150 verschieden sind. Das öffentliche Netzwerk 120 kann verhältnismäßig unzuverlässig, unsicher und anfälliger für Sicherheitslücken bei der Übertragung (z. B. ein Angriff durch jemanden in der Mitte (man-in-the-mittle-attack)) im Vergleich zu einem privaten Netzwerk (z. B. einem Intranet) sein, das intern innerhalb des Datenzentrums 150 benutzt werden kann. Gemäß einer Ausführungsform umfaßt das öffentliche Netzwerk 120 ein drahtloses Netzwerk, einen WAP-Gateway und das Internet und sorgt für eine End-to-End-Sicherheit zwischen einer drahtlosen Zugriffseinrichtung 110 und einem Datenzentrum 150.
Das Datenzentrum 150 kann ein Computersystem oder mehrere Computersysteme sein, die mit dem öffentlichen Netzwerk 120 verbunden sind, um sichere Daten über das öffentliche Netzwerk 120 zu empfangen oder zu liefern. Das Datenzentrum 150 kann z. B. mehrere privat vernetzte Computersysteme umfassen, welche solche Funktionen, wie eine Firewall, einen Server und eine Datenquelle, zur Verfügung stellen.
Die Netzwerkzugriffseinrichtung 110 überträgt die Angabe eines sicheren Protokolls 130 zu dem Datenzentrum 150 über das Netzwerk 120. Verschiedene Ausführungsformen der Angabe 130 werden in Betracht gezogen. Gemäß einer ersten Ausführungsform umfaßt die Angabe 130 Informationen, um eine Verbindung zwischen der Netzwerkzugriffseinrichtung 110 und dem Datenzentrum 150 aufzurufen und zu definieren.
Entsprechend einer zweiten Ausführungsform umfaßt die Angabe 130 einen Port, z. B. eine Nachricht, die einem speziellen Sicherheitsformat zugeordnet ist, das auf einem Port empfangen wird, der dafür konfiguriert ist, dieses spezielle Sicherheitsformat zu empfangen. Der Ausdruck "Port" wird benutzt, um eine logische Verknüpfung oder ein Interface zwischen Daten, die von dem Netzwerk 120 empfangen werden, und einer Komponente des Datenzentrums 150, wie eine Anwendung, ein Modul oder ein Higher-Level-Protokoll zu bezeichnen. Der Port kann eine entsprechende Port-Nummer aufweisen, die der Komponente zugeordnet ist und die benutzt werden kann, um aus dem Netzwerk 120 empfangende Daten mit der Komponente oder dem Dienst zu verknüpfen oder zu diesem zu leiten. Gemäß einer Ausführungsform kann der Port ein bekannter Port mit einer bekannten Port-Nummer sein. Zum Beispiel kann der Port der bekannte Port 80 sein, der für HTTP-Daten benutzt wird, oder der Port kann der bekannte Port 443 sein, der für SSL-Daten benutzt wird. Eine aus dem Netzwerk 120 empfangene Nachricht kann eine Port-Bezeichnung umfassen, welche die Komponente bezeichnet. Gemäß einer Ausführungsform kann ein Port von einem durch ein Betriebssystem geleiteten Softwareprozess implementiert werden, der die Daten abhört, die aus dem Netzwerk 120 an einem physikalischen Interface empfangen werden, wie mit einer Netzwerkinterfacekarte (NIC), die mit dem Netzwerk über eine Gigabit-Ethernet oder RJ45-Verbindung verknüpft ist, für die Port-Bezeichnung, die den Port und die Komponente bezeichnet. Die Port-Bezeichnung und eine IP-Adresse bilden zusammen einen Socket, der eine Endpunkt der Verbindung spezifiziert. Eine End-to-End-Kommunikation zwischen der Einrichtung 110 und dem Datenzentrum 150 kann durch einen Vierertuppel spezifiziert werden, das einen Port und eine IP-Adresse für die Einrichtung 110 und einen Port und eine IP-Adresse für das Datenzentrum 150 umfaßt.
Gemäß einer dritten Ausführungsform umfaßt die Angabe 130 eine Angabe eines sicheren Datenformats, das von der Netzwerkzugriffseinrichtung 110 unterstützt, bevorzugt oder sowohl unterstützt als auch bevorzugt wird. Zum Beispiel kann die Angabe 130 ein Sicherheitsmerkmal umfassen, das von der Zugriffseinrichtung 110 unterstützt oder bevorzugt wird, die in einer Sicherheitsaushandlungsnachricht der Vordatenphase, wie einer Client-Hello-Nachricht, die während eines Sicherheits-Handshakes gesendet wird, angekündigt ist. Der Ausdruck "Sicherheitsmerkmal" wird benutzt, um in aller Breite Merkmale, Parameter und Optionen zu bezeichnen, die ein Sicherheitsformat beschreiben oder definieren, und umfaßt Sicherheitsmerkmale, die aus der Gruppe ausgewählt sind, aber nicht darauf beschränkt sind, die Versionsinformationen, Optionsinformationen (z. B. Zertifizierung oder keine Zertifizierung), Verschlüsselungsalgorithmusinformationen, Sicherheitsparameterinformationen, Verschlüsselungsparameterinformationen, Zuverlässigkeitszertifikationsinformationen und andere Sicherheitsmerkmalsinformationen umfaßt.
Gemäß einer vierten Ausführungsform umfaßt die Angabe 130 sowohl eine Angabe eines Ports, der dem Sicherheitsformat zugeordnet ist, als auch eine Angabe des Sicherheitsmerkmals, das von der Einrichtung 110 unterstützt wird. Zum Beispiel umfassen beispielhafte Angaben 130B ein Sicherheitsmerkmal 131, das zu einem Port 190 (welches den bekannten Port 443 umfassen kann) des Datenzentrums 150 geliefert wird.
Gemäß einer fünften Ausführungsform umfaßt die Angabe 130 eine Sitzungsidentifikation, die einem früheren Sicherheitsformat oder -konvertierung entspricht. Entsprechend einer sechsten Ausführungsform umfaßt die Angabe 130 eine Profilidentifikation (z. B. eine Benutzerkennung oder ein Paßwort), das den Zugriff auf ein Sicherheitsformat oder eine Sicherheitskonvertierung von einem Profil in dem Datenzentrum 150 ermöglicht. Gemäß einer siebten Ausführungsform umfaßt die Angabe 130 eine zweckgebundene eindeutige Angabe eines Sicherheitsformats, z. B. SSL-Version 3.0. Gemäß einer achten Ausführungsform umfaßt die Angabe 130 eine zweckgebundene eindeutige Angabe einer Sicherheitskonvertierung, z. B. eine Logik oder ein Modul, um von SSL-Version 3.0 zu Klartextdaten zu konvertieren. Viele andere Ausführungsformen der Angabe 130 werden in Betracht gezogen, und eine Per son mit durchschnittlichem Fachwissen auf diesem Gebiet und den Vorteilen der vorliegenden Offenbarung wird erkennen, daß die Angabe 130 breit auszulegen ist.
Wie vorhergehend diskutiert, werden verschiedene Angaben 130 in Betracht gezogen und das Auswahlsystem 170 kann dementsprechend verschiedene Auswahlen vornehmen. Entsprechend einer ersten Ausführungsform basiert die Auswahl auf Informationen, die aus dem Netzwerk 120 empfangen werden. Gemäß einer zweiten Ausführungsform basiert die Auswahl auf Verbindungsinformationen, die mit dem Aufbau einer Verbindung zwischen der Netzwerkzugriffseinrichtung 110 und dem Datenzentrum 150 verknüpft sind. Gemäß einer dritten Ausführungsform basiert die Auswahl auf Port-Informationen. Zum Beispiel kann das Auswahlsystem 170 eine ersten Konvertierung auswählen, wenn eine Verbindungsinformation an einem ersten vorbestimmten konfigurierten Port empfangen wird, und eine zweite Konvertierung auswählen, wenn eine Verbindungsinformation an einem zweiten Port empfangen wird. Gemäß einer vierten Ausführungsform basiert die Auswahl auf Sicherheitsmerkmalinformationen, welche Sicherheitsformatmerkmale bezeichnen, die von der Einrichtung 110 unterstützt, bevorzugt oder sowohl unterstützt als auch bevorzugt werden. Zum Beispiel kann das Auswahlsystem 170 eine Konvertierung aufgrund eines unterstützten und eines bevorzugten Sicherheitsformats auswählen, das in der Client-Hello-Nachricht angekündigt ist.
Gemäß einer fünften Ausführungsform kann die Auswahl auf Port-Informationen und Sicherheitsmerkmalsinformationen beruhen. Zum Beispiel kann das Auswahlsystem 170 eine Konvertierung aus einem Sicherheitsformat aufgrund eines Ports auswählen, auf dem eine Client-Hello-Nachricht empfangen wird, und aufgrund von Sicherheitsmerkmalen, die in der Client-Hello-Nachricht als von der Clienteinrichtung 110 unterstützt und bevorzugt angegeben sind.
Gemäß einer sechsten Ausführungsform kann die Auswahl auf einer Sitzungsidentifikation beruhen, die einem (einer) vorherigen Sicherheitsformat oder -konvertierung entspricht. Gemäß einer siebten Ausführungsform kann die Auswahl auf einer Profilidentifikation (z. B. einer Benutzerkennung und einem Paßwort) beruhen, die dem Auswahlsystem 170 ermöglicht, auf ein Sicherheitsformat oder eine Sicherheitsformatskonvertierung von einem Profil zuzugreifen. Gemäß einer achten Ausführungsform kann die Auswahl auf einem spezifizierten Sicherheitsformat oder einer Sicherheitsformatskonvertierung (z. B. "SSL V3.0 zu Klartextdaten) beruhen. Viele andere Auswahlen und Auswahlsysteme 170 sind vorgesehen und eine Person mit durchschnittlichem Fachwissen auf diesem Gebiet und dem Vorteil der vorliegen den Offenbarung wird erkennen, daß die Auswahl und das Auswahlsystem 170 breit auszulegen ist.
Die Konvertierung erfolgt von einem empfangenen Sicherheitsformat in ein anderes Format. Das andere Format kann ein einfaches Klartextdatenformat sein. Dies kann vorteilhaft sein, wenn das Datenzentrum 150 intern ausreichend gesichert ist und nur ein geringes Risiko eines unbeabsichtigten oder nicht autorisierten Datenzugriffs bietet. Dadurch kann vorteilhaft eine nachfolgende Entschlüsselung in dem Datenzentrum 150 vermieden werden. Gemäß einer alternativen Ausführungsform kann das andere Format ein anderes Sicherheitsformat sein. Das heißt, das Sicherheitssystem 160 kann eine Konvertierung von einem Sicherheitsformat in einen anderes Sicherheitsformat auswählen und durchführen. Zum Beispiel kann die Konvertierung zu einer IP-Security (IPSec) führen, die zur Sicherheit in einem Intranet des Datenzentrums 150 gewünscht sein kann.
Die Netzwerkzugriffseinrichtung 110 überträgt sichere Daten 140 zu dem Datenzentrum 150 über das Netzwerk 120. Das Datenzentrum 150 empfängt die sicheren Daten 140 von dem Netzwerk 120. Das Konvertierungssystem 180 führt die ausgewählte Sicherheitskonvertierung auf den sicheren Daten 140 durch. Ohne Beschränkung können die sicheren Daten 140 Transaktions- und/oder Finanzdaten sein, und das Datenzentrum 150 kann die Daten verwenden und/oder auf diese antworten, wie es für eine bestimmte Anwendung gewünscht ist.
Gemäß einer Ausführungsform ist die Netzwerkzugriffseinrichtung 110 eine drahtlose Netzwerkzugriffseinrichtung, welche einen WAP-Stapel 200, der in 2 gezeigt ist, benutzt, um mit der Datenzentrale 150 zu kommunizieren. Der WAP-Stapel 200 ist eine Sicherheitsspezifikation, die es ermöglicht, daß die drahtlose Einrichtung sicher auf Informationen über das Netzwerk 120 zugreift. Der WAP-Stapel 200 umfaßt eine Anwendungsschicht 210, eine Sitzungsschicht 220, eine Übertragungsschicht 230, eine Sicherheitsschicht 240, eine Transport-Schicht 250 und eine Netzwerkschicht 260. Der WAP-Stapel 200 ist einer Person mit durchschnittlichem Fachwissen auf diesem Gebiet gut bekannt und wird im größeren Detail in der Version 1.2 und 2.0 der WAP-Spezifikation beschrieben, welche über http://www.wapforum.org erhältlich ist.
Die Sicherheitsschicht 240 umfaßt das WTLS-Protokoll und kann Geheimhaltung, Datenintegrität und Client/Server-Authentifikation für WAP-fähige drahtlose Einrichtungen zur Verfü gung stellen. Das WTLS-Protokoll arbeitet oberhalb der Transportschicht 250 und stellt die WAP-Schichten 210 bis 230 des oberen Levels mit einem sicheren Transportserviceinterface zur Verfügung, welches das Transportinterface darunter erhält und außerdem Verfahren bietet, um die Sicherheitskonvertierungen auszuführen. WTLS bezieht sich auf nicht drahtlose Protokolle, wie Secure Sockets Layer (SSL), involviert jedoch seitens der Einrichtung eine verhältnismäßig geringe Bearbeitungsleistung und Speichererfordernisse, eine niedrige Bandbreite und Datagrammverbindung.
Die Transportschicht 250 kann verschiedene Datagramm-basierende Transportschichtprotokolle, wie UDP/IP und WDP, umfassen. UDP arbeitet mit IP-Übermittlungsdiensten, während WDP mit nicht-IP-Übermittlungsdiensten arbeitet. Zum Beispiel kann WDP mit dem Short Message Service (SMS) und ähnlichen drahtlosen Übermittlungsdiensten verwendet werden, während UDP mit Circuit Swichted Data (CSD) und ähnlichen Übermittlungsdiensten benutzt werden kann.
3 zeigt ein vereinfachtes Blockdiagramm der Systemarchitektur 300 einer Ausführungsform der Erfindung. Die Systemarchitektur 300 umfaßt eine drahtlose Zugriffseinrichtung 305 und eine drahtgebundene Zugriffseinrichtung 320, um heterogen verschlüsselte Nachrichten über ein öffentliches Netzwerk 325 zu einem Datenzentrum 340 zu übertragen, das ein Sicherheitssystem 345 umfaßt, um verschiedene Sicherheitskonvertierungsbearbeitungen für die empfangenen heterogen verschlüsselten Nachrichten auszuwählen und zu implementieren.
Die drahtlose Zugriffseinrichtung 305, die in einer Ausführungsform ein WAP-Mikrobrowser-fähiges Handy ist, wird mit dem öffentlichen Netzwerk 325, das in einer Ausführungsform das Internet ist, über ein drahtloses Netzwerk 310 und einem WAP-Gateway 315 gekoppelt. Die drahtlose Zugriffseinrichtung 305 erzeugt und überträgt eine WTLS-Client-Hello-Nachricht, die Sicherheitsmerkmalsinformationen umfaßt, welche Sicherheitsmöglichkeiten und Leistungen der Einrichtung 305 entsprechen und überträgt diese zu dem drahtlosen Netzwerk 310 unter Verwendung- von entweder einem UDP- oder eine WDP-Übertragungsprotokoll. Das drahtlose Netzwerk 310 empfängt die Nachricht und übermittelt sie zu dem WAP-Gateway. Das WAP-Gateway konvertiert das Übertragungsprotokolhnedium entweder von LTDP oder WDP zu TCP und führt die Nachricht zu dem öffentlichen Netzwerk 325 unter Verwendung von TCP.
Eine drahtgebundene Zugriffseinrichtung 320, welche gemäß einer Ausführungsform ein Personalcomputer mit Browser ist, erzeugt eine Nachricht, die Sicherheitsmerkmalsinformationen enthält, und überträgt diese zu dem öffentlichen Netzwerk 325. Die Nachricht kann eine SSL-Client-Hello-Nachricht umfassen, die verwendet wird, μm eine Aushandlung eines Sicherheitsformats in einem SSL-Handshake zu initiieren.
Das öffentliche Netzwerk 325 ist funktionell mit der drahtlosen Zugriffseinrichtung 305, der drahtgebundenen Zugriffseinrichtung 320 und dem Datenzentrum 340 verbunden, um die Nachrichten von den Einrichtung 305, 320 zu empfangen und die Nachrichten zu dem Datenzentrum 340 zu liefern. Gemäß einer Ausführungsform umfaßt das Netzwerk 325 das Internet und kann TCP oder UDP als Protokolle für das Transportmedium benutzen. Das Netzwerk 325 überträgt oder kommuniziert die Nachrichten zu dem Datenzentrum 340, wie die Angaben 330 und 335.
Das Datenzentrum 340 ist mit dem öffentlichen Netzwerk 325 gekoppelt, um die Nachrichten zu empfangen, die den Einrichtungen 305 und 320 zugeordnet sind. Das Datenzentrum 340 umfaßt ein Sicherheitssystem 345, das gemäß einer Ausführungsform funktionell zwischen dem öffentlichen Netzwerk 325 und einem Server 390 angeordnet ist, so daß das Sicherheitssystem 345 eine Sicherheitskonvertierungsauswahl und -abwicklung für den Server 390 ausführen kann.
Gemäß einer Ausführungsform umfaßt das Sicherheitssystem 345 ein Netzwerkinterface 350, um Angaben und Sicherheitsdaten zu empfangen, ein Auswahlsystem 360, um eine Konvertierung aufgrund der Angaben auszuwählen, ein Konvertierungssystem 370, um die ausgewählte Konvertierung zu empfangen und die ausgewählte Konvertierung auf Sicherheitsdaten anzuwenden, die über das Netzwerkinterface 350 empfangen werden, und ein zweites Netzwerkinterface 380, um die konvertierten Daten zu empfangen und um die konvertierten Daten an andere Komponenten des Datenzentrums 340, wie in einer Ausführungsform ein Server 390, zu liefern.
Das Netzwerkinterface 350 kann ein oder mehrere NIC umfassen, um die Nachrichten und die Sicherheitsdaten für das Datenzentrum 340 zu empfangen. Gemäß einer Ausführungsform umfaßt das Netzwerkinterface 350 wenigstens einen Port 354, um Informationen von der drahtlosen Zugriffseinrichtung 305 zu empfangen, und wenigstens einen Port 352, um Infor mationen von der drahtgebundenen Zugriffseinheit 320 zu empfangen. Das Netzwerkinterface 350 kann z. B. einen ersten und zweiten Port 354 aufweisen, um jeweils gesicherte und ungesicherte Daten von der drahtlosen Zugriffseinrichtung 305 zu empfangen, und einen zweiten und dritten Port 352, um jeweils gesicherte und ungesicherte Daten von der drahtgebundenen Zugriffseinrichtung 320 zu empfangen.
Das Auswahlsystem 360 ist mit dem Netzwerkinterface 350 gekoppelt, um Sicherheitskonvertierungsauswahlinformationen von dem Netzwerkinterface 350 zu empfangen, und um eine Sicherheitskonvertierung aufgrund der Informationen auszuwählen. Die Sicherheitskonvertierung kann eine Konvertierung von einem Sicherheitsformat, das den Information zugeordnet ist, in ein anderes Format (z. B. ein anderes geschütztes Format oder ein Klartextdatenformat) sein. Gemäß einer ersten Ausführungsform wählt das Auswahlsystem 360 eine Sicherheitskonvertierung aufgrund der empfangenen Angabe des Ports aus. Das Auswahlsystem 360 kann z. B. eine Angabe eines vorbestimmten Ports empfangen, der für die Verwendung von SSL-verschlüsselten Daten bekannt ist, und wählt wenigstens eine Sicherheitskonvertierung von den SSL-verschlüsselten Format in ein anderes Format aus. Gemäß einer zweiten Ausführungsform wählt das Auswahlsystem 360 wenigstens eine Sicherheitskonvertierung aufgrund der empfangenen Sicherheitsmerkmalsinformationen aus. Das Auswahlsystem 360 kann z. B. Sicherheitsmerkmalsinformationen empfangen, die ein Sicherheitsmerkmal oder einen Satz von Sicherheitsmerkmalen bezeichnen, die von der drahtgebundenen Zugriffseinrichtung 320 unterstützt werden, und wählt eine Konvertierung von diesem Sicherheitsformat zu einem anderen Format aus. Gemäß einer dritten Ausführungsform wählt das Auswahlsystem 360 eine Konvertierung aufgrund von sowohl einer Port-Information als auch einer Sicherheitsmerkmalsinformation aus. Das Auswahlsystem 360 kann z. B. entweder ein WTLS-Konvertierungssystem 372 auswählen mit wenigstens einer teilweisen Konvertierung von einem WTLS-Format in ein anderes Format oder ein SSL-Konvertierungssystem 374 mit wenigstens einer teilweisen Konvertierung von einem SSL-Format in ein anderes Format aufgrund der Port-Information und kann entweder die teilweise WTLS- oder SSL-Konvertierung aufgrund der Sicherheitsmerkmalsinformation auswählen.
Das Auswahlsystem 360 kann eine ausgewählte Sicherheitskonvertierung zu anderen Komponenten des Systems 300 zur Verfügung stellen. Gemäß einer Ausführungsform verknüpft das Auswahlsystem 360 eine Sitzungsidentifikation für eine Sitzung zwischen einer Einrichtung 305 oder 320 und dem Datenzentrum 340 mit der ausgewählten Sicherheitskonvertie rung. Dies kann ermöglichen, daß aufeinanderfolgend empfangene Daten in einem gesicherten Format mit der ausgewählten Sicherheitskonvertierung verknüpft werden. In einer Ausführungsform kann das Auswahlsystem 360 dem Konvertierungssystem 370 die ausgewählten Konvertierung durch Angeben eines Sicherheitskonvertierungsauswahlsignals melden. Das Auswahlsystem 360 kann z. B. einen Verfahrensaufruf an das Konvertierungssystem 370, das WTLS-Konvertierungssystem 372 oder das SSL-Konvertierungssystem 374, welches die ausgewählte Konvertierung übermittelt, durchführen.
Nachdem das Sicherheitsformat zwischen den Einrichtungen 305, 320 und dem Sicherheitssystem 345 ausgehandelt wurde, können die Einrichtungen 305, 320 sichere Daten zu dem Sicherheitssystem 345 übertragen. Insbesondere kann die drahtlose Einrichtung 305 Daten in einer vorbestimmten Version von WTLS übertragen. Das drahtlose Netzwerk 310 kann die sicheren Daten empfangen und an den WAP-Gateway 315 liefern. Typischerweise wird der WAP-Gateway 315 eine Konvertierung von entweder UDP oder WDP zu TCP durchführen und die Daten im TCP-Format an das öffentliche Netzwerk 325 liefern.
Gemäß einer Ausführungsform ist der WAP-Gateway 315 so konfiguriert, daß er die empfangenen sicheren WTLS-Daten ohne eine Sicherheitskonvertierung passieren läßt. Vorteilhafterweise kann dieser Zugang eine End-to-End-Sicherheit zwischen der drahtlosen Zugriffseinrichtung 305 und dem Datenzentrum 340 zur Verfügung stellen und kann die WAP-Lücke verhindern, die existiert, wenn WTLS-Daten in SSL-Daten über einen ungeschützten Klartextdatenzustand konvertiert werden, der für einen man-in-the-middle-Angriff offen ist. Verschiedene Konfigurationen werden in Erwägung gezogen, einschließlich einer, in welcher der WAP-Gateway 315 so konfiguriert ist, daß alle drahtlosen Verbindungen zu dem Datenzentrum 340 ohne eine Sicherheitsformatkonvertierung bleiben. Dieser Ansatz sorgt auch für eine verringerte Latenz im Vergleich zu den Ansätzen aus, dem Stand der Technik, die in 1 bis 3 gezeigt sind, da eine Bearbeitung einer unnötigen Sicherheitsformatkonvertierung und eine Übertragung zu dem System 330 vermieden werden kann.
Die drahtgebundene Zugriffseinrichtung 320 kann Daten in einer vorbestimmten Version von SSL übertragen, die mit dem Sicherheitssystem 345 ausgehandelt wurde. Die Daten können im SSL-Format unter Verwendung von TCP über das Internet 325 übertragen werden.
Das Konvertierungssystem 370 ist mit dem Auswahlsystem 360 gekoppelt, um die ausgewählte Sicherheitskonvertierung zu empfangen, und ist mit dem Netzwerkinterface 350 gekoppelt, um die sicheren Daten von der drahtlosen Einrichtung 305 und der drahtgebundenen Einrichtung 320 zu empfangen. Das Konvertierungssystem 370 führt die ausgewählte Konvertierung an den empfangenen sicheren Daten aus. Das Konvertierungssystem 370 kann eine Logik aufweisen, welche Software, Hardware oder einige Kombinationen aus Software und Hardware umfaßt, um die empfangenen sicheren Daten (z. B. WTLS- oder SSL-verschlüsselte Daten) in ein unverschlüsseltes Klartext-Datenformat zu entschlüsseln und, falls dies gewünscht ist, wieder in ein alternatives Sicherheitsprotokollformat zu verschlüsseln. Gemäß einer Ausführungsform kann die Logik eine herkömmliche Konvertierungslogik aufweisen, die für eine Person mit durchschnittlicher Fachkenntnis und den Vorteilen der vorliegenden Offenbarung gut bekannt ist.
Wie bereits dargelegt, kann das Sicherheitssystem 345 verschiedene Konvertierungsmodule aufweisen, um die Konvertierung von einem empfangenen Sicherheitsformat in ein anderes Format durchzuführen. Gemäß einer Ausführungsform umfaßt das Konvertierungssystem 370 ein WTLS-Konvertierungssystem 372 und ein SSL-Konvertierungssystem 374, um WTLS- oder SSL-Sicherheitsdaten jeweils in ein anderes Sicherheitsformat zu konvertieren. Das WTLS-Konvertierungssystem 372 kann mehrere Konvertierungsmodule aufweisen, z. B. ein erstes Konvertierungsmodul von einer ersten Version von WTLS mit einem ersten Sicherheitsmerkmal in Klartextdaten, ein zweites Konvertierungsmodul von einer zweiten Version von WTLS mit einem zweiten Sicherheitsmerkmal in Klartextdaten und ein drittes Konvertierungsmodul von einer dritten Version von WTLS in ein anderes Sicherheitsformat, wie SSL, IPSec oder anderen. Genauso kann das Konvertierungssystem 374 mehrere Konvertierungsmodule besitzen.
Das Konvertierungssystem 370 liefert konvertierte Daten zu einem Netzwerkinterface 380, das mit dem Server 390 gekoppelt ist. Das Netzwerkinterface 380 kann ein NIC aufweisen. Typischerweise liefert das Netzwerkinterface 380 Klartextdaten zu dem Server 390 über einen Klartextdatenport, wie den Port 80, obgleich andere Ausführungsformen auch in Betracht gezogen werden.
Der Server 390 empfängt die konvertierten Daten. Wenn die konvertierten Daten in einem gesicherten Format vorliegen, kann der Server 390 eine Entschlüsselung durchführen. Der Server kann ohne Einschränkung eine beliebige Bearbeitung durchführen, die für eine bestimmte Implementierung verlangt wird. Typischerweise wird die Bearbeitung ein Liefern von Antwortdaten zu den Einrichtung 305, 320 über das Sicherheitssystem 345 umfassen. Gemäß einer Ausführungsform liefert der Server 390 Klartextdaten an das Sicherheitssystem 345.
Das Sicherheitssystem 345 kann die Antwortdaten empfangen und eine Sicherheitsbearbeitung an den Daten vornehmen. Gemäß einer Ausführungsform bearbeitet das Sicherheitssystem 345 die Antwortdaten durch im wesentlichen eine Umkehrung der anfänglichen Konvertierung. Zum Beispiel kann das Sicherheitssystem 345 für Antwortdaten für die drahtlosen Einrichtung 305 Klartextdaten von dem Server 390 in das WTLS-Format konvertieren und liefert die Sicherheitsdaten zu der drahtlosen Einrichtung 305. Genauso kann das Sicherheitssystem 345 für Antwortdaten für die drahtgebundene Einrichtung 320 Klartextdaten von dem Server 390 in das SSL-Format konvertieren und die gesicherten Daten zu der drahtgebundenen Einrichtung 320 liefern.
Das System 300 kann eine Reihe von Vorteilen bieten. Ein erster Vorteil kann die Möglichkeit sein, von dem Server 390 Sicherheitsbearbeitungsfunktionen an das Sicherheitssystem 345 abzugeben. Eine Sicherheitsbearbeitung kann recht prozessor- und speicherintensiv sein und kann ohne ein solches Abgeben einen erheblichen Teile der Ressourcen des Systems 390 in Anspruch nehmen. Das Abgeben kann dem Server auch erlauben, mehrere Verbindungen zu handhaben. Mit einem Sicherheitssystem 345, das eine Sicherheitskonvertierung durchführt, kann dem Server 390 z. B. ermöglicht werden, die fünf- bis zehnfache Anzahl von Verbindungen zu handhaben, als ohne ein solches System.
Ein zweiter Vorteil ist die End-to-End-Sicherheit zwischen den Zugriffseinrichtungen 305, 320 und dem Server 390. Ein dritter Vorteil ist eine einzelne Sicherheitskonvertierung zwischen den Zugriffseinrichtungen 305, 320 und dem Server 390. Dies kann für einen schnelleren Austausch von Daten aufgrund geringerer Rechenintensität und geringerer Latenz sorgen. Ein vierter Vorteil ist, daß das Sicherheitssystem 345 eine Einzelpunktsicherheitslösung für sowohl drahtlose als auch für drahtgebundene Sicherheitsprotokolle zur Verfügung stellt. Ein fünfter Vorteil ist, daß es häufig einfacher ist, das Sicherheitssystem 345 mit den aktuellsten Sicherheitsstandards und -konvertierungen zu aktualisieren, als den Server 390 zu aktualisieren.
Das Sicherheitssystem 345 wurde in einer vereinfachten Form gezeigt, um nicht von der Erfindung abzulenken. Personen mit durchschnittlichem Fachwissen auf dem Gebiet und dem Vorteil der vorliegenden Offenbarung werden erkennen, daß andere Komponenten 385 in das Sicherheitsystem 345 eingebunden werden können. Häufig umfassen die anderen Komponen- ten 385 ein Betriebssystem oder eine Plattform. Die anderen Komponenten 385 können auch Komponenten umfassen, die für bestimmte Implementierungen gewünscht sein können, wie Komponenten, um eine XML-Transformation, eine XML-Zerlegung, eine auf Inhalte bezogene Weiterleitung und andere Klartextdatenfunktionen durchzuführen. Die anderen Komponenten 385 können Komponenten umfassen, die in einem herkömmlichen zweckgebundenen Sicherheitsbeschleuniger verwendet werden, wie ein Intel(R) NetStructure^TM 7110 e-Commerce Accelerator,. ein 7115 e-Commerce Accelerator, ein 7140 Traffic Director, ein 7175 Traffic Director, ein 7180 e-Commerce Director, ein 7280 XML Director oder ein 7210 XML Accelerator, die alle von Intel Corporation von Santa Clara, Kalifornien, erhältlich sind.
4 stellt ein Blockdiagramm von dem Verfahren 400 zum Betreiben eines Sicherheitssystems, wie das Sicherheitssystem 160 oder 345, gemäß einer Ausführungsform dar. Das Verfahren 400 kann in einer Logik implementiert sein, die Software, Hardware oder eine Kombination von Software und Hardware umfaßt.
Das Verfahren 400 beginnt mit dem Block 401 und fährt anschließend mit dem Block 405 fort, bei dem das Sicherheitssystem konfiguriert wird. Gemäß einer Ausführungsform kann dies das Lesen einer Konfigurationsdatei umfassen, die Systemkonfigurationsinformationen enthält. Das Sicherheitssystem kann beispielsweise, ohne einzuschränken, auf Konfigurationsinformationen zugreifen, wie sie in der folgenden Tabelle enthalten sind: Tabelle 1
In der obigen Tabelle liefert die Map-ID eine abiträtre Kennung für eine Verbindung, die Verbindungsart liefen den Typ die Verbindung, der entweder gesichert oder ungesichert ist, die Schlüssel-ID liefert Schlüsselkennungen zur Benutzung für die gesicherten Verbindung, die Server-IP liefert eine Internetprotokolladresse, um mit Servern in dem Datenzentrum zu kommunizieren, der Netzwerkport liefert eine vorbestimmte bekannte Port-Nummer zum Empfangen von gesicherten oder ungesicherten Daten aus dem öffentlichen Netzwerk, der Serverport liefert einen bekannten vorbestimmten Port, um Klartextdaten zu dem Server in dem Datenzentrum zu übermitteln, die Chiffrier-Suites enthalten eine Angabe des Sicher-heitsmaßstabs, der für die gesicherten und ungesicherten Verbindungen benutzt wird, und die Umleitung liefert eine Option, um eine Zugriffseinrichtung auf sichere Upgraderessourcen für den Fall umzuleiten, daß die Einrichtung die benutzten Sicherheitsmerkmale nicht unterstützt.
Die folgende beispielhafte Implementierung des Umleitungsmerkmals ist nicht als Beschränkung zu betrachten. Das Sicherheitssystem ermittelt, ob der Client den in der Konfiguration spezifizierte Sicherheitslevel erfüllt. Wenn der Client den spezifizierte Sicherheitslevel nicht erfüllt, kann das Sicherheitssystem ermitteln, ob eine Umleitungsseite als ein Uniform Resource Locator (URL) geschickt werden soll, um eine Möglichkeit zu geben, den Client auf den spezifizierten Sicherheitslevel zu aktualisieren. Wenn die Umleitungsseite nicht gesendet werden soll, kann statt dessen eine Default-Error-Nachricht gesendet werden.
Anstelle der Benutzung von separaten Servern kann alternativ der gleiche Server benutzt werden, um sowohl HTML als auch Wireless Markup Language (WML) Inhalte in verschiedenen Netzports zu bedienen, so daß die Server-IP-Netzport-Kombination eindeutig ist. Das Sicherheitssystem kann z. B. Konfigurationsinformationen benutzen, wie sie in der folgenden Tabelle enthalten sind: Tabelle 2
Das Verfahren 400 führt vom Block 405 mit dem Block 410 fort, bei dem Prozesse die konfigurierten Ports auf Aktivitäten oder Nachrichten abhören. Gemäß einer Ausführungsform hören die Prozesse eindeutige Sockets ab, die eine eindeutige Kombination einer IP-Adresse und eines Ports aufweisen. Gemäß einer Ausführungsform erzeugt das Sicherheitssystem separate Prozesse oder Teilprozesse, um die Ports abzuhören, die in der Konfigurationsdatei bezeichnet sind. Ein Prozeß kann beispielsweise den Port 9208 für WTLS-bezogenen Nach-. richten abhören, ein Prozeß kann den Port 443 für SSL-bezogene Nachrichten abhören und ein Prozeß kann den Port 80 für ungesicherte Daten abhören.
Das Verfahren 400 kann von dem Block 410 mit dem Block 415 fortfahren, wenn eine Sicherheitsmerkmalsinformation an dem Port 9208 empfangen wird. Gemäß einer Ausführungsform kann die Sicherheitsmerkmalsinformation eine Client-Hello-Nachricht von einer drahtlosen Zugriffseinrichtung umfassen. Die Sicherheitsmerkmalsinformation kann z. B. eine Client-Hello-Nachricht für eine existierende oder zukünftige Version von WTLS aufweisen.
Das Verfahren 400 kann von dem Block 415 mit dem Block 420 fortfahren, wo ein WTLS-Sicherheitsformat ausgehandelt wird. Die Aushandlung kann auf einer Sicherheitsmerkmalsinformation beruhen, die Sicherheitsmerkmale angibt, welche die drahtlose Einrichtung bevorzugt oder die es zu benutzen in der Lage ist. Die Aushandlung kann einen Rückwärts- und Vorwärtsaustausch für Sicherheitsmerkmalsmöglichkeiten und/oder -präferenzen zwischen der Zugriffseinrichtung und dem Datenzentrum umfassen, um bei einem gegenseitig unterstützten Sicherheitsformat zuzustimmen. Gemäß einer Ausführungsform umfaßt die Aushandlung beim Block 420 ein WTLS-Handshake-Protokoll. Verschiedene Ausführungsformen des ausgehandelten Sicherheitsformats werden in Erwägung gezogen. Gemäß einer ersten Ausführungsform umfaßt das Sicherheitsformat eine existierende oder zukünftige Version von WTLS. Gemäß einer zweiten Ausführungsform umfaßt das Sicherheitsformat ein ausgehandeltes Sicherheitsmerkmal, wie ein Verschlüsselungsparameter, einen Verschlüsselungsalgorithmus (z. B. Data Encryption Standard (DES)), oder beide.
Das Verfahren 400 fährt vom Block 420 mit dem Block 425 fort, bei dem eine Konvertierung von dem ausgehandelten Sicherheitsformat in ein unverschlüsseltes Klartextdatenformat ausgewählt wird. Die Konvertierung in ein Klartextdatenformat kann in Architekturen vorteilhaft sein, bei denen das Sicherheitssystem mit einem Datenziel (z. B. einem Datenzentrumserver) über einer ausreichend vertrauenswürdigen Verbindung oder Netzwerk gekoppelt ist, da der Server dann Klartextdaten empfangen kann und keine Entschlüsselung vornehmen muß.
Gemäß einer ersten Ausführungsform wird die Konvertierung aufgrund der am Port 9208 empfangenen Informationen ausgewählt. Die Konvertierung kann z. B. aufgrund von Informationen ausgewählt werden, die dem Block 415 zugeordnet sind. Gemäß einer zweiten Ausführungsform basiert die Konvertierung auf einer Sicherheitsaushandlung. Die Konvertierung kann z. B. aufgrund von Informationen ausgewählt werden, die dem Block 420 zugeordnet sind. Die ausgewählte Sicherheitskonvertierung kann zu anderen Komponenten, wie einem Konvertierungssystem oder einem Konvertierungsmodul, übermittelt werden.
Das Verfahren 400 führt vom Block 425 mit dem Block 430 fort, bei dem die gesicherten verschlüsselten Daten empfangen werden. Die gesicherten Daten können über den Port 9208 empfangen werden und können in dem ausgehandelten Sicherheitsformat von Block 420 vorliegen. Das Verfahren 400 fährt vom Block 430 mit dem Block 435 fort, bei dem die empfangenen verschlüsselten Daten in Klartextdaten konvertiert werden. Dies kann unter Verwendung herkömmlicher oder bekannter Verfahren ausgeführt werden. Die Blöcke 430 und 435 können unter Verwendung eines Batch-Modus oder eines kontinuierlichen Modus implementiert werden.
Das Verfahren 400 fährt vom Block 410 mit dem Block 440 fort, wenn eine Sicherheitsmerkmalsinformation an dem Port 443 empfangen wird. Die Sicherheitsmerkmalsinformation kann z. B. mit einer Verbindung https://www.intel.com verknüpft sein, die dem Datenzentrum anzeigt, daß die Clienteinrichtung versuchen wird, sich mit dem Port 443 zu verbinden. Gemäß einer Ausführungsform kann die Sicherheitsmerkmalsinformation einen Client-Hello-Nachricht von einer drahtgebundenen Zugriffseinrichtung aufweisen. Die Sicherheitsmerkmalsinformation kann z. B. eine Client-Hello-Nachricht für eine existierende oder zukünftige Version von SSL sein.
Das Verfahren 400 führt vom Block 440 mit dem Block 445 fort, bei dem ein SSL-Sicherheitsformat ausgehandelt wird. Die Aushandlung kann in analoger Weise ausgeführt werden, wie sie im Block 420 beschrieben wurde, um ein Sicherheitsformat zu bestimmen, das auf SSL basieren kann und das einen SSL-Verschlüsselungsparameter und einen SSL-Algorithmus umfassen kann.
Das Verfahren 400 führt vom Block 445 mit dem Block 450 fort, bei dem eine Konvertierung von dem ausgehandelten Sicherheitsformat zu einem unverschlüsselten Klartextdatenformat ausgewählt wird. Gemäß einer ersten Ausführungsform wird die Konvertierung aufgrund am Port 443 empfangenen Informationen ausgewählt. Die Konvertierung kann z. B. aufgrund von Information ausgewählt werden, die mit dem Block 440 verknüpft sind. Gemäß einer zweiten Ausführungsform basiert die Konvertierung auf einer Sicherheitsaushandlung. Die Konvertierung kann z. B. aufgrund von Informationen ausgewählt werden, die mit dem Block 445 verknüpft sind.
Das Verfahren 400 führt vom Block 450 mit dem Block 455 fort, bei dem Daten in dem ausgehandelten Sicherheitsformat am Port 443 empfangen werden. Das Verfahren 400 führt von dem Block 455 mit dem Block 460 fort, bei dem die empfangenen Daten von dem Sicherheitsformat in ein Klartextdatenformat konvertiert werden.
Das Verfahren 400 kann von dem Block 410 mit dem Block 465 fortfahren, wenn unverschlüsselten Klartextdaten an dem Port 80 empfangen werden.
Das Verfahren 400 kann von dem Block 435, 460 oder 465 mit dem Block 470 fortfahren, bei dem Klartextdaten an ein gewünschtes Ziel geliefert werden. Gemäß einer Ausführungsform werden die Daten zu einem Server oder einem anderen Computersystem des Datenzentrums geliefert. Der Server kann durch eine Netzwerkadresse in der Konfigurationsinformation identifiziert werden. Gemäß einer Ausführungsform werden die Daten zu dem Server über den bekannten Port 80 geliefert. Das Verfahren 400 kann bei dem Block 475 enden.
Alternative Ausführungsformen des Verfahrens 400 werden betrachtet. Entsprechend einer ersten alternativen Ausführungsform werden unterschiedliche Ports konfiguriert und benutzt. Typischerweise werden die Ports zum Empfangen von Sicherheitsmerkmalsinformationen und Daten mit Zielen von der Internet Assigned Numbers Authority (IANA) oder einer ähnli chen Stelle Übereinstimmen. Gemäß einer Ausführungsform kann der WTLS-Port ein Port sein, der aus der Gruppe von Ports mit den Nummern zwischen 9208 und 9282 ausgewählt werden. Gemäß einer zweiten Ausführungsform kann eine Sicherheitskonvertierung von dem ausgehandelten Format der Blöcke 420 oder 445 in ein anderes Sicherheitsformat anstelle eines Klartextdatenformats ausgewählt werden. Dies kann vorteilhaft sein, wenn das Datenziel mit dem Sicherheitssystem über eine Verknüpfung gekoppelt ist, die nicht ausreichend gesichert ist. Anstellte des Lieferns der Klartextdaten beim Block 470 können z. B. die gesicherten Daten im WTLS-Format zu gesicherten Daten im SSL-Format konvertiert werden und zu dem Datenziel geliefert werden. Eine solche Konvertierung kann vorteilhaft sein, wenn das Datenziel nicht in der Lage ist, das Sicherheitsformat vor der Konvertierung zu entschlüsseln.
5 zeigt eine WTLS-Sicherheitsarchitektur 500 gemäß einer Ausführungsform. Die Architektur 500 umfaßt ein Rekord-Protokoll 550 zum Aufnehmen ungesicherter Daten aus oberen Stapel-Schichten, die übertragen werden sollen, um auf Datenintegrität und Authentisierung Rücksicht zu nehmen, und zum Anwenden von Kompressions- und Verschlüsselungsalgorithmen auf die Daten. Die Architektur 500 umfaßt außerdem Vier-Protokoll-Clients, die ein Handshake-Protokoll 510, wie nachfolgend diskutiert, ein Alarm-Protokoll 520, um Möglichkeiten zum Schließen sicherer Verbindungen zu liefern, ein Anwendungsprotokoll 530, um mit den oberen Stapel-Schichten in Verbindung zu treten, und ein Austausch-Chiffrier-Spezifikationsprotokoll 540, um einen koordinierten Austausch zwischen Lese-, Schreib- und Schwebezuständen zu ermöglichen, umfassen.
Das Handshake-Protokoll 510 stellt eine Ausführungsform einer Sicherheitsaushandlung zwischen einer drahtlosen Zugriffseinrichtung und einem Datenzentrum dar. Das Handshake-Protokoll 510 ermöglicht der Einrichtung und dem Datenzentrum, über Sicherheitsverfahren und -parameter, wie ein Sicherheitsprotokoll, eine Protokollversion, einen Verschlüsselungsalgorithmus, eine Authentifizierung, eine Technik mit einem öffentlichen Schlüssel und andere Sicherheitsmerkmale, zu verhandeln oder diesen zuzustimmen.
6 zeigt ein Flußdiagramm eines WTLS-Handshakes 600 gemäß einer Ausführungsform. Der Handshake 600 kann benutzt werden, um ein Sicherheitsformat zwischen einem drahtlosen Zugriffseinrichtungs-Client 610 und einem Datenzentrumserver 670 auszuhandeln. Gemäß einer Ausführungsform umfaßt der Handshake 600 Sicherheitsmerkmalsinformationen.
Der Handshake 600 beginnt bei dem Client 610 mit dem Liefern einer Client-Hello-Nachricht zu dem Datenzentrum 670 bei dem Block 620. Das Hello des Clients kündigt typischerweise unterstützte Sicherheitsmerkmale (z. B. Protokolle, Versionen, Optionen, Verschlüsselungsalgorithmen und vertrauenswürdige Zertifikate) an. Gemäß einer Ausführungsform gibt das Hello des Clients wenigstens ein Sicherheitsformat an. Nach dem Hello des Clients empfängt der Zugriffseinrichtungs-Client 610 Nachrichten, bis der Datenzentrumserver 670 eine Server-Hello-Done-Nachricht sendet.
Der Handshake 600 fährt vom Block 620 mit dem Block 630 fort, bei dem der Datenzentrumserver 670 mit dem Handshake 600 fortfährt. Der Datenzentrumsserver 670 kann eine Server-Hello-Nachricht liefern, die dem Sicherheitsformatverfahren und den Parametern zustimmt oder diese neu aushandelt. Der Server 670 kann auch eine Serverzertifikat-Nachricht senden, wenn eine Authentifizierung benutzt werden soll, eine Server-Schlüsselaustausch-Nachricht, um einen öffentlichen Schlüssel zu liefern, der benutzt werden kann, um einen Premaster-Sicherheitswert zu leiten oder auszutauschen, eine Zertifikatsanfragenachricht, um den Client nach einem Zertifikat oder einer Authentifizierung zu fragen, und eine Server-Hello-Done-Nachricht, um anzuzeigen, daß die Hello-Nachricht-Phase des Handshakes 600 abgeschlossen ist. Der Server 670 wartet anschließend auf eine Antwort von dem Client 610.
Der Handshake 600 fährt vom Block 630 mit dem Block 640 fort, bei dem der Zugriffseinrichtungs-Client 610 mit dem Handshake 600 fortfährt. Der Client 610 kann eine Clientzertifizierungsnachricht senden, falls diese angefordert wurde, um sich selbst zu authentifizieren (oder einen nicht-zertifiziert-Alarm), eine Client-Schlüsselaustausch-Nachricht, die auf einem Algorithmus mit öffentlichen Schlüsseln beruht, der zwischen dem Client-Hello und dem Server-Hello ausgewählt wurde und eine Pre-Master-Sicherheitsveschlüsselung mit dem öffentlichen Schlüssel des Datenzentrumsservers umfaßt, eine digital signierte Zertifikat-Verifizierungs-Nachricht, um das Zertifikat ausdrücklich zu verifizieren, wenn der Client 610 ein Zertifikat mit einer Signierungsmöglichkeit geschickt hat, eine Change-Cipher-Spec-Nachricht, um den Beginn der Benutzung der ausgehandelten Sicherheitsparamter anzuzeigen, und eine Finished-Nachricht, die eine Verifikation der vorherigen Daten umfaßt, einschließlich von Sicherheitsinformationen, die mit den neuen Algorithmen, Schlüsseln und Sicherheiten berechnet wurden.
Der Handshake 600 fährt vom Block 640 mit dem Block 650 fort, bei dem der Datenzentrumserver 670 den Handshake 600 fortsetzt. Der Datenzentrumserver 670 kann mit einer Cipher-Spec-Nachricht antworten, um die Sitzung zu bestätigen und den Client 610 zu informieren, die ausgehandelten Sitzungsparameter zu benutzen, und eine Finished-Nachricht, die eine Bestätigung der ausgetauschten und berechneten Informationen enthält.
Der Handshake 600 fährt vom Block 650 mit dem Block 660 fort, bei dem der Client 610 und der Server 670 gesicherte Daten unter Verwendung der aufgebauten und ausgehandelten gesicherten Verbindung austauschen. Der Handshake 600 kann auch Erhaltungsinformationen über die sichere Verbindung, wie eine Sitzungsidentifikation, aufweisen, so daß ein zukünftiger gesicherter Datenaustausch auf die vorhergehend ausgetauschten Sicherheitsverfahren und Parameter gestützt werden kann.
7 zeigt eine Client-Hello-Nachricht 700 gemäß einer Ausführungsform. Die Client-Hello-Nachricht 700 kann für ein SSL, WTLS oder ein andere Sicherheitsformat bestimmt sein. Gemäß einer Ausführungsform umfaßt die Client-Hello-Nachricht 700, die an einem Port empfangen wird, eine Angabe eines Sicherheitsformats. Die Client-Hello-Nachricht 700 umfaßt Sicherheitsmerkmalsinformationen, wie Informationen über die Clientsicherheitsmöglichkeiten 710, Zufallsstrukturinformationen 720, Sitzungsidentifikationsinformationen 730, Informationen über die unterstützten Verschlüsselungsoptionen 740 und Informationen über Kompressionsverfahren 750.
Die Informationen über die Clientsicherheitsmöglichkeiten 710 können eine Protokollversion umfassen. Die Protokollversion kann eine Version sein, die der Client zu verwenden in der Lage ist, zu verwenden bevorzugt oder beides. Die Information 710 kann z. B. die SSL-Version 3.0 oder andere Protokollversionen angeben. Gemäß einer Ausführungsform kann ein Sicherheitssystem in dem Datenzentrum die Clientversionsinformation benutzen, um ein Sicherheitsformat auszuhandeln, und eine entsprechende Sicherheitskonvertierung auszuwählen. Die Zufallstrukturinformation 720 kann eine vom Client erzeugte Zufallsstruktur umfassen. Die Zufallsstruktur kann mehrere Bits umfassen, die auf der aktuellen Zeit und dem Datum entsprechend einer internen Uhr des Clients beruhen, und mehrere Zufallsbytes, die von einem Sicherheitszufallszahlengenerator erzeugt werden.
Die Sitzungsidentifikationsinformation 730 können eine Sitzungsidentifikation mit variabler Länge umfassen, die, sofern sie nicht leer ist, eine vorherige Sitzung zwischen dem Client und dem Server angibt, einschließlich früherer Sicherheitsverfahren und Parameter, die der Client für die aktuelle Sitzung wieder zu benutzen wünscht. Die Sitzungsidentifikation kann aus einer früheren Verbindung, dieser Verbindung oder einer anderen aktuell aktiven Verbindung sein. Der Server kann die tatsächlichen Inhalte der Sitzungsidentifikation definieren. Die Sitzungsidentifikationsinformation 730 kann leer sein, wenn eine frühere Sitzung nicht verfügbar ist, oder wenn der Client wünscht, Sicherheitsverfahren und Parameter neu auszuhandeln. Gemäß einer Ausführungsform umfaßt die Sitzungsidentifikation die Angabe einer Sicherheitskonvertierung. Eine Sitzungsidentifikation kann z. B. einer früher ausgewählten Sicherheitskonvertierung entsprechen, und der Empfang der Sitzungsidentifikation ermöglicht einem Auswahlsystem, die Sicherheitskonvertierung wieder auszuwählen.
Die unterstützte Verschlüsselungsinformation 740 kann eine Angabe der Verschlüsselungsoptionen und Kombinationen umfassen, die von dem Client unterstützt werden und entsprechend der Präferenzen des Clients angepaßt sind. Dieser kann auch ähnliche Informationen aus früheren Sitzungen umfassen, die wieder benutzt werden sollen.
Die Kompressionsverfahrensinformation 750 kann eine Liste von Kompressionsalgorithmen oder Verfahren, die von dem Client unterstützt werden, und eine Angabe von Clientpräferenzen für jedes Verfahren enthalten. Wenn die Sitzungsidentifikationsinformation 730 anzeigt, eine Sitzung wieder zu benutzen, kann die Kompressionsverfahrensinformation 750 ein Kompressionsverfahren umfassen, das für die frühere Sitzung benutzt wurde. Gemäß einer Ausführungsform gibt die Information 750 die Unterstützung von CompressionMethod.Null an.
8 zeigt ein Auswahlsystem 800 einer Ausführungsform. Das Auswahlsystem 800 empfängt eine Angabe 810. Die Angabe 810 ist eine Angabe, die geeignet ist, dem Auswahlsystem 800 zu ermöglichen, eine Sicherheitsformatkonvertierung auszuwählen. Die gezeigte Angabe 810 umfaßt eine Angabe eines Sicherheitsformats und besitzt Port-Informationen 812 und Sicherheitsmerkmalsinformationen 814.
Die Port-Information 812, die eine Angabe eines Ports umfassen kann, über den Daten (z. B. Client-Hello-Nachrichten, Sicherheitsmerkmalsinformationen, etc.) empfangen wurden, wird an eine Protokollauswahllogik 820 des Auswahlsystems 800 geliefert. Die Protokollauswahllogik 820 ist in der Lage, zwischen unterschiedlichen Sicherheitsprotokollen aufgrund der Port-Information 812 auszuwählen. Gemäß der gezeigten Ausführungsform ist die Protokollauswahllogik 820 in der Lage, zwischen einem drahtlosen Protokoll, einem drahtgebundenen Protokoll und einem ungesicherten Klartextprotokoll aufgrund der Port-Information 812 auszuwählen. Ohne einzuschränken, wird die folgende konzeptionelle Protokollauswahllogik 820 betrachtet: wenn die Port-Information 812 den Port 9208 angibt, dann Auswählen eines drahtlosen Protokolls; sonst, wenn die Port-Information 812 den Port 443 angibt, dann Auswählen eines drahtgebundenen Protokolls; sonst, wenn die Portinformation 812 den Port 80 angibt, dann Auswählen eines ungesicherten Klartextprotokolls. Die Protokollauswahllogik 820 bestätigt eine Protokollauswahl 830, die entweder das drahtlose Protokoll (drahtlose Auswahl), das drahtgebundene Protokoll (drahtgebundene Auswahl) oder das ungesicherte Klartextprotokoll (SS) angibt.
Das Auswahlsystem 800 umfaßt auch eine Sicherheitsmerkmalsauswahllogik 840, die mit der Protokollauswahllogik 820 zum Empfangen der Protokollauswahl 830 gekoppelt ist. Die Logik 840 ist in der Lage, verschiedene Sicherheitsformatkonvertierungen aufgrund der Protokollauswahl 830 und aufgrund der Sicherheitsmerkmalsinformation 814 auszuwählen. Die Auswahl S5 kann die Logik 840 umgehen, da eine Sicherheitsformatkonvertierung üblicherweise nicht an Klartextdaten ausgeführt wird. Gemäß der gezeigten Ausführungsform ist die Logik 840 in der Lage, eine von vier verschiedenen Konvertierungen (d. h. entsprechend der Auswahl S1, S2, S3 oder S4) auszuwählen, obgleich dies keine Beschränkung anderer Ausführungsformen darstellt.
Die Logik 840 umfaßt einen drahtlosen Logikabschnitt 850 und einen drahtgebundenen Logikabschnitt 860, wobei beide in der Lage sind, die Sicherheitsmerkmalsinformation 814 zu empfangen. Der Logikabschnitt 850 ist in der Lage, eine Konvertierung auszuwählen, wenn die Protokollauswahl 830 eine drahtlose Auswahl angibt. Ohne einzuschränken, werden die folgenden konzeptionellen Logikabschnitte 850 betrachtet: wenn die Sicherheitsmerkmalsinformation 814 einen Satz F1 von wenigstens einem Sicherheitsmerkmal angibt, dann Auswählen einer ersten Sicherheitsformatkonvertierung; sonst, wenn die Sicherheitsmerkmalsinformation 814 einen Satz F2 von wenigstens einem Sicherheitsmerkmal angibt, dann Auswählen einer zweiten Sicherheitsformatkonvertierung; sonst Senden einer Umleitungs-URL, falls so konfiguriert.
Der Logikabschnitt 860 ist in der Lage, eine Konvertierung auszuwählen, wenn die Protokollauswahl 830 eine drahtgebundene Auswahl angibt. Ohne einzuschränken, wird der folgende konzeptionelle Logikabschnitt 860 betrachtet: wenn die Sicherheitsmerkmalsinformation 814 einen Satz F3 von wenigstens einem Sicherheitsmerkmal angibt, dann Auswählen einer dritten Sicherheitsformatkonvertierung; sonst, wenn die Sicherheitsmerkmalsinformation 814 einen Satz F4 von wenigstens einem Sicherheitsmerkmal angibt, dann Auswählen einer fünften Sicherheitsformatkonvertierung; sonst Senden einer Umleitungs-URL, falls so konfiguriert.
Die Logik 840 bestätigt eine Sicherheitsformatkonvertierungsauswahl 870, welche eine Sicherheitsformatkonvertierung angibt, die anzeigt, eine Sicherheitsformatkonvertierung auf gesicherten Daten auszuführen, die konsistent mit der Port-Information 812 und der 814 ist. Die Auswahl 870 kann S1 oder S2 für eine drahtlose Einrichtung und S3 oder S4 für eine drahtgebundene Einrichtung umfassen. Die Auswahl 870 kann zu einem Konvertierungssystem oder Modul übermittelt werden.
9 zeigt ein Datenzentrum 900 gemäß einer Ausführungsform. Das Datenzentrum 900 kann mit einem öffentlichen Netzwerk, wie dem Internet, gekoppelt sein, um Angaben und gesicherte Daten von dem öffentlichen Netzwerk zu empfangen. Das Datenzentrum 900 umfaßt ein Sicherheitssystem 920, das funktionell mit zwischen einem Schalter/Router 910 und einem Schalter/Router 930 und ausreichend nahe zu einem oder mehreren Servern 940 bis 960 des Datenzentrums 900 angeordnet ist. Das Sicherheitssystem 920 empfängt potentiell heterogen verschlüsselte Daten von dem Schalter/Router 910 und liefert geeignet sicherheitsformatierte konvertierte Daten zu dem Schalter/Router 930. Der Schalter/Router 930 liefert die konvertierten Daten, die in einem Klartextdatenformat sein können, zu dem einen oder den mehreren Servern 940 bis 960. Gemäß einer ersten Ausführungsform umfaßt der eine oder die mehreren Server 940 bis 960 einen WML-Inhalt-Server 940, der über die Adresse 10.1.1.30 erreichbar ist, um drahtlose Daten zu empfangen und zu liefern, und um einen HTTP-Inhalt-Server 950, der über eine Adresse 10.1.1.31 erreichbar ist, um drahtgebundene Daten zu empfangen und zu liefern. Entsprechend einer zweiten Ausführungsform kann ein Approach-Server 960, der über eine Adresse 10.1.1.32 erreichbar ist, sowohl drahtlose wie auch drahtgebundene Daten empfangen und liefern.
10 zeigt ein Sicherheitssystem 1000 gemäß einer Ausführungsform. Das Sicherheitssystem 1000 umfaßt ein Front-Panel-Interface. Das Front-Panel-Interface kann verschiedene Informationen (z. B. 1011–1018), Datenlinks (z. B. 1019–1022) und Benutzersteuerungen (z. B. 1023–1024) zur Verfügung stellen, die für die speziellen Implementationen gewünscht sind. Insbesondere können die Datenanschlüsse einen Anschluß 1019 zu einer Konsole aufweisen, die eine Anzeigeeinrichtung (z. B. einen Monitor) eine Dateneingabeeinrichtung (z. B. eine Tastatur) eine Curser-Steuereinrichtung (z. B. eine Maus) und andere Komponenten umfassen, die dem Benutzer ermöglichen, das System 1000 zu konfigurieren und zu überwachen. Die Datenübertragungsanschlüsse können auch einen Netzwerkanschluß 1021 zu einem öffentlichen Netzwerk oder ein Public-Network-Interface und einen Serveranschluß 1022 zu einem Bestimmungsort von Sicherheitsformatkonvertierungsdaten aufweisen. Diese Anschlüsse können Gigabit Ethernet oder RJ45-Anschlüsse umfassen.
Das Sicherheitssystem 1000 umfaßt einen Bus und andere Kommunikationseinrichtungen 1050, die mit dem Front-Panel-Interface 1010 zur Übermittlung von Informationen gekoppelt sind, eine Bearbeitungseinrichtung, wie einen Prozessor 1060, der mit dem Bus 1050 zur Datenbearbeitung gekoppelt ist, einen Hauptspeicher 1070 (z. B. ein RAM-Speicher) der mit dem Bus 1050 zum Speichern von Daten und von dem Prozessor 1060 auszuführenden Befehlen gekoppelt ist, einen nur lesbaren Speicher 1080, der mit dem Bus 1050 zum Speichern statischer Informationen und Befehle für den Prozessor 1060 gekoppelt ist (z. B. einem BIOS), und eine Sicherheitshardware 1090.
Der Hauptspeicher 1070 kann Auswahlbefehle 1072 und Konvertierungsbefehle 1074 speichern. Die Befehle 1072, 1074 können als Anwendungen, Module, Datenstrukturen oder andere Logiken enthalten sein.
Gemäß einer Ausführungsform kann die Sicherheitsformatkonvertierungsauswahl oder die Sicherheitsformatkonvertierung teilweise in der Hardware ausgeführt werden. Z. B. kann die Hardware 1090 eine Schaltung umfassen, um modulare Exponentation, Pseudo-Zufallszahlenerzeugung, Pseudo-Zufallsschlüsselerzeugung, DES/3DES-Verschlüsselung und -Entschlüsselung und andere gewünschte Sicherheitsoptionen durchzuführen. Gemäß einer Ausführungsform umfaßt die Hardware 1090 eine Verschlüsselungskarte, Field-Programmable-Gate-Array (FPGA) oder einen Application-Specific-Integrated-Circuit (ASIC), um solche Sicherheitsvorgänge auszuführen.
Alternative Ausführungsformen
Die Erfindung ist nicht beschränkt auf die besonderen Ausführungsformen, die vorhergehend diskutiert wurden, und Personen mit durchschnittlichem Fachwissen und dem Vorteil der vorliegenden Offenbarungen werden erkennen, daß viele andere Ausführungsformen mit einbezogen sind.
Verschiedene Sicherheitsformate
Entsprechend einer ersten alternativen Ausführungsform kann die Erfindung mit anderen Sicherheitsformaten, als die vorhergehend beschriebenen, verwendet werden. Das Sicherheitsformat kann ein von der Internet-Engineering-Task-Force (IETF) akzeptiertes Format sein, ein Format, das auf Transport-Layer-Security (TLS) beruht, ein Format, das eine zukünftige Weiterentwicklung von TLF, SSL oder WTLS ist, oder ein Format, wie Secure-HTTP (S-HTTP), IP-security (IPSec), Private-Communications-Technology oder andere sein.
Verteilte Sicherheitssysteme
Gemäß einer zweiten alternativen Ausführungsform kann das hierin beschriebene Sicherheitssystem über mehrere Computersysteme verteilt sein. Z. B. kann ein erstes Computersystem oder eine Einrichtung ein Auswahlsystem aufweisen, ein zweites System oder eine Einrichtung kann ein WTLS-Konvertierungssystem aufweisen und ein drittes System oder eine Einrichtung kann ein SSL-Konvertierungssystem aufweisen.
Server mit einem Sicherheitssystem
Gemäß einer dritten alternativen Ausführungsform kann ein Sicherheitssystem, ein Auswahlsystem oder ein Konvertierungssystem in einem Server eingebaut sein.
Web-Schalter
Gemäß einer vierten alternativen Ausführungsform kann ein Sicherheitssystem, ein Auswahlsystem oder ein Konvertierungssystem in einem Web-Schalter mit mehr Netzwerkverbindungsmöglichkeiten für eine erhöhte Verbindungsstabilität aufweisen.
Push-Mode
Gemäß einer fünften alternativen Ausführungsform kann ein Sicherheitssystem, ein Auswahlsystem oder ein Konvertierungssystem in einem Push-Mode betrieben werden. Ein Server in einem Datenzentrum kann z. B. Klartextdaten zu einem Sicherheitssystem liefern, das ein Sicherheitsformatkonvertierungsauswahlsystem aufweist, um eine Konvertierung zu einem SSL-Format für eine drahtgebundene Einrichtung und eine Konvertierung zum WTLS-Format für eine drahtlose Einrichtung auszuwählen.
Authentifizierung
Authentifizierung ist eine Sicherheitsfunktion oder ein Prozeß, bei dem ein System Benutzer und Computer validiert, die mit dem System interagieren. Es ist eine Sicherung, die zusätzlich zur Verschlüsselung implementiert werden kann. Eine Vorrichtung kann unter Verwendung einer Authentifikationsinformation authentifiziert werden. Dies kann ein digitales Zertifikat, digitale Signaturen oder beides umfassen.
In der Beschreibung soll sich Authentifizierung einer Quelle auf die Authentifizierung eines Benutzers und/oder einer Einrichtung beziehen. Authentifizierung soll auch bedeuten, die Identität eines Clients zu verifizieren, und Validieren soll sich auf Verfahren beziehen, die typischerweise in Verbindung mit einem digitalen Zertifizierungsprozeß ausgeführt werden, einschließlich, jedoch nicht ausschließlich, einem Verifizieren von CA-Signaturen, einem Verifizieren der Gültigkeitsdauer der Zertifikate und einem Sicherstellen, daß die Zertifikate nicht auf Certificat-Revocation-List (CRL) existieren.
Weiterhin sollen WAP (Wireless Application Protocol) -Standards benutzt werden, um Beispiele für den Aspekt der drahtlosen Einrichtungen der Erfindung zu liefern. WAP ist ein glo baler Standart zur Darstellung und Lieferung von drahtlosen Informationen und Telefondiensten auf Mobiltelefonen und auf anderen drahtlosen Einrichtungen. Aus der Sicherheitsperspektive wird hierin insbesondere WTLS (Wireless Transport Layer Security) beschrieben, welche in enger Verwandtschaft zu SSL (Secure Socket Layer) steht, einem Protokoll, das zur Sicherung des drahtgebundenen Internets verwendet wird.
Digitale Zertifikate
Ein Verfahren zur Authentisierung einer Einrichtung geht über die Verwendung von digitalen Zertifikaten. Ein digitales Zertifikat ist eine Sicherung dafür, daß Daten, die vom Internet heruntergeladen werden, aus einer vertrauenswürdigen Quelle stammen. Digitale Zertifikate sichern den legitimierten Online-Transfer von vertraulichen Informationen, Geld und anderen sensiblen Inhalten durch eine öffentliche Verschlüsselungstechnologie. Ein digitales Zertifikat wird durch eine CA (Certificate Authority) ausgegeben und stellt Informationen zur Verfügung, wie die Zeit, zu der das digitale Zertifikat ausgestellt wurde, und seine Gültigkeitsdauer.
Ein Zertifikat kann auch kompromittiert werden, bevor es abläuft. Zum Beispiel kann es in falsche Hände fallen, oder die CA kann entscheiden, daß die Quelle, für die es ausgestellt wurde, nicht mehr vertrauenswürdig ist. Um Zertifikate zurückzuweisen, die vor dem Ablauf als kompromittiert bekannt sind, gibt die CA zurückgewiesene Zertifikate in einer Certificate-Revocation-List (CRL) bekannt. Eine CRL ist eine Liste von Zertifikaten, die von der CA vor ihrem Ablauf zurückgerufen wurden, und ist von einer Public-Domain erhältlich.
Digitale Signaturen
Digitale Signaturen stellen ein anderes Verfahren zur Authentifizierung von Einrichtungen zur Verfügung. Eine digitale Signatur dient sowohl zur Authentifizierung der Identität des Unterzeichners (d. h. der Quelle) und der Integrität der übertragenen Informationen durch die Benutzung eines öffentlichen und eines privaten Schlüssels. Eine Voraussetzung digitaler Signaturen ist, daß der Unterzeichner der Daten einen privaten Schlüssel besitzt, und andere, die Daten mit dem Unterzeichner austauschen, einen öffentlichen Schlüssel des Unterzeichners erhalten können. Die anderen können den öffentlichen Schlüssel benutzen, um Daten zu verschlüsseln oder zu entschlüsseln und der Unterzeichner kann den privaten Schlüssel benutzen, um Daten zu verschlüsseln oder zu entschlüsseln.
Z. B. kann ein Unterzeichner ein Dokument signieren, indem er die Daten zerhackt, um ein Message-Digest zu erzeugen, und anschließend das Message-Digest mit dem privaten Schlüssel des Unterzeichners verschlüsselt. Das verschlüsselte Message-Digest wird dann an das Dokument angehängt. Wenn ein Empfänger das verschlüsselte Message-Digest und das Dokument empfängt, benutzt der Empfänger den öffentlichen Schlüssel des Unterzeichners, um das Message-Digest zu entschlüsseln, wodurch das Message-Digest erzeugt wird. Das Dokument wird dann validiert, indem die Daten in dem Dokument zerhackt werden und mit dem erzeugten Message-Digest verglichen werden. Wenn sie zueinander passen, wurde das Dokument bestätigt. Wenn sie nicht zueinander passen, weiß der Empfänger, daß die Daten in dem Dokument verfälscht wurden, da sie nicht das gleiche Message-Digest, wie das gesendete, erzeugen.
PKI/WPKI-Infrastrukturen
In den beschriebenen Ausführungsformen der Erfindung wird Bezug genommen auf PKI (Public Key Infrastructure) und WKPI (Wireless Public Key Infrastructure) -Systeme der digitalen Zertifikate, Zertifizierungsstellen und anderen Registrierungsstellen, welche die Richtigkeit jeder Partei, die in einer Internettransaktion involviert ist, verifizieren und authentifizieren. Wenn eine Einrichtung ein digitales Zertifikat (nachfolgend "Zertifikat") anfordert, wird es unter der PKI/WPKI-Infrastruktur allgemein von einer Registrierungsstelle freigegeben und dann zu einer Zertifikatstelle weitergeleitet. Die Zertifikatstelle kann das Zertifikat dann herausgeben. Typischerweise umfassen die Registrierungsstelle und die Zertifikatstelle die gleiche Einheit. In einigen Fällen können diese jedoch auch unterschiedlich sein.
Überblick
11 ist ein Flußdiagramm, das ein Verfahren zum Aufbau einer sicheren Verbindung gemäß Ausführungsformen der Erfindung darstellt. Das Verfahren startet bei dem Block 1100 und fährt mit dem Block 1102 fort, bei dem ein Client einer Client-Hello-Nachricht sendet, um bei einem Server nach einer sicheren Verbindung anzufragen. Bei dem Block 1104 antwortet ein Sicherheitssystem mit einer Server-Hello-Nachricht für den Servers und bestätigt die Anfrage des Clients. Das Sicherheitssystem startet dann einen Zertifikataustauschprozeß im Block 1106, bei dem ermittelt wird, ob der Client nach einer Authentifizierung angefragt hat (d. h. Anfordern einer sicheren Verbindung). Wenn der Client eine Authentifikation angefordert hat, sendet das Sicherheitssystem im Block 1108 Authentifizierungsinformationen.
Wenn der Client keine Authentifizierung angefordert hat, springt das Verfahren zum Block 1110, bei dem der Server ebenfalls eine Authentifizierung anfordern kann (d. h. fordert den Client auf, sich selbst zu identifizieren). Wenn der Server eine Authentifizierung anfordert, sendet der Client im Block 1112 Authentifizierungsinformationen zu dem Sicherheitssystem und fährt mit Block 1114 fort. Wenn der Server keine Authentifizierung anfordert, springt das Verfahren vom Block 1114, bei dem das Sicherheitssystem eine Server-Hello-Done-Nachricht zu dem Clienten sendet, welche anzeigt, daß die Hello-Nachrichten-Phase des Handshakes abgeschlossen ist. Wenn der Client die Server-Hello-Done-Nachricht empfängt, sendet er eine Finished-Nachricht zu dem Sicherheitssystem im Block 1116, und im Block 1118 antwortet das Sicherheitssystem mit einer Finished-Nachricht. Das Verfahren endet beim Block 1120.
Der Handshake ist nun abgeschlossen und der Client und der Server können verschlüsselte Daten zueinander schicken und/oder, wenn Daten bereits gesendet wurden, kann eine Entschlüsselung unter Verwendung eines Entschlüsselungsverfahrens stattfinden, das für das Verfahren geeignet ist, mit dem die Daten verschlüsselt wurden.
12 ist ein Pseudocode, der die wesentlichen Funktionen, wie vorhergehend diskutiert, darstellt. Der Pseudocode beginnt bei der Zeile 1, und bei der Zeile 3 wird ein Verfahren zum Verschlüsseln ermittelt. Wenn die Daten in WTLS verschlüsselt sind (Zeile 5) wird ein WTLS-Handshake in der Zeile 6 gestartet. In der Zeile 7 wird die WTLS-Authentifizierung abgeschlossen und in der Zeile 8 werden die WTLS-Daten entschlüsselt.
Wenn die Daten in SSL verschlüsselt sind (Zeile 9) wird ein SSL-Handshake in der Zeile 10 gestartet. In der Zeile 11 wird die SSL-Authentifizierung abgeschlossen und in der Zeile 12 werden die SSL-Daten entschlüsselt. Wenn die Daten nicht verschlüsselt sind (Zeile 13) wird mit den Daten in der Zeile 14 nichts gemacht.
13 stellt eine Systemarchitektur 1300 für eine drahtgebundene und eine drahtlose Authentifikation gemäß den allgemeinen Ausführungsformen der Erfindung dar. Sie kann eine drahtlose Zugriffseinrichtung 1302 (wie ein Handy oder einen Personal-Digital-Assistent) oder eine drahtgebundene Zugriffseinrichtung 1308 (wie ein Personalcomputer mit Browser) sein. In dem Fall einer drahtlosen Zugriffseinrichtung 1302 werden WTLS-Daten durch ein drahtloses Netzwerk 1304 z. B. unter Verwendung eines UDP (User Datagram Protocol) oder WDP (Wireless Datagram Protocol)-Übertragungsprotokoll gesendet. Das drahtlose Netzwerk 1304 empfängt die Nachricht und befördert sie zu dem WAP-Gateway 1306, bei dem das Übertragungsprotokoll von WDP/UDP zu TCP/IP konvertiert wird und bei dem ein Verschlüsseln und Entschlüsseln stattfindet.
Zusätzlich werden bei dem herkömmlichen Ansatz WTLS-verschlüsselte Daten zu SSLverschlüsselte Daten bei dem WAP-Gateway konvertiert, und die Zertifikate des drahtlosen Clients werden bei der WAP-Gateway authentifiziert. Dies ist jedoch keine End-to-End-Lösung für die Authentifizierung. In Ausführungsformen der Erfindung findet jedoch die Entschlüsselung nicht in der WAP-Gateway statt. Statt dessen werden die WTLS-Daten zu dem Datenzentrum 1316 über ein öffentliches Netzwerk 1310, wie das Internet, übermittelt. In dem Fall einer drahtgebundenen Zugriffseinrichtung 1308 werden SSL-Daten zu dem Datenzentrum 1316 direkt über das öffentliche Netzwerk 1310 gesendet.
Bei dem Datenzentrum 1316 wird der Sender der Daten (d. h. der Client) authentifiziert, die WTLS/SSL-verschlüsselten Daten werden zu Klartext entschlüsselt und die Klartextdaten werden zu einem von vielen möglichen Servern 1314 (gezeigt ist nur einer) in dem Datenzentrum gesendet. Das Datenzentrum 1316 kann ein Sicherheitssystem 1312 umfassen, wie in das Sicherheitssystem 345 der 3.
Die Architektur 1300, die in 13 dargestellt ist, bildet die Architektur 300, die in 3 dargestellt ist, in vielen Aspekten nach, außer daß das Sicherheitssystem der 13 zusätzlich ein Authentifizierungssystem gegenüber dem Sicherheitssystem 345 der 3 besitzt.
In einer alternativen Ausführungsform, wie sie in 14 dargestellt ist, umfaßt die Systemarchitektur 1400 ein Sicherheitssystem 1312, das vor dem WAP-Servers 1306 untergebracht ist, der die Funktionen eines WAP-Gateways und eines Web-Server ausführt. Alternativ kann das Sicherheitssystem 1312 vor einem WAP-Gateway untergebracht sein, dem ein Web-Server (nicht gezeigt) folgt. Diese Ausführungsform kann eine Firewall 1402 aufweisen. Z. B. können einige Unternehmen ihr eigenen Gateway in ihrem Datenzentrum für ihre Anwendungen betreiben und diese beruhen nicht auf mobilen Service-Providern für den mobilen Gateway-Service.
In dieser Ausführungsform werden WTLS-Daten von der drahtlosen Einrichtung 1302 zu einem drahtlosen Netzwerk 1304 unter Verwendung z. B. eines UDP (User Datagram Protocol) oder WDP (Wireless Datagram Protocol)-Übertragungsprotokolls gesendet. Das drahtlose Netzwerk 1304 empfängt die Nachricht und leitet die Daten durch das öffentliche Netzwerk 1310 weiter und anschließend durch die Firewall 1302.
Wenn die Daten in dem Sicherheitssystem 1312 empfangen sind, authentifiziert das Sicherheitssystem 1312 WTLS-verschlüsselten Daten und, falls zutreffend, konvertiert die WTLSverschlüsselten Daten in Klartext. Das Sicherheitssystem 1312 nimmt dann Rücksicht auf die Authentifizierung und die Entschlüsselung. Im Fall einer drahtlosen Zugriffseinrichtung 1308 werden SSL-Daten zu dem Datenzentrum 1316 über das öffentliche Netzwerk 1310 gesendet, bei dem das Sicherheitssystem 1312 die SSL-verschlüsselten Daten authentifiziert und, falls zutreffend, die SSL-verschlüsselten Daten in Klartext konvertiert. Die Klartextdaten können dann zu einem von vielen möglichen Servern 1314 (nur einer ist gezeigt) in dem Datenzentrum gesendet werden.
Das Sicherheitssystem 1312 führt eine CRL, die in definierten Abständen von einer öffentlich zugänglichen CRL aktualisiert wird, die von der CA aktualisiert wird. Das Sicherheitssystem aktualisiert seine CRL aus der öffentlich zugänglichen CRL und umfaßt ein Authentifizierungssystem, um zu ermitteln, ob die clientseitigen Zertifikate, die es von den Clienteneinrichtungen erhält, gültig sind, indem es sie mit seinem CRL vergleicht.
Das Sicherheitssystem 1312 fordert auch serverseitige Zertifizierungen an, um sie zu den Clients zu schicken, wenn Clients nach einer Authentifizierung anfragen. Das System 1312 erhält reguläre Zertifikate zum Versenden an drahtgebundene Einrichtungen, sowie langlebige und kurzlebige Zertifikate zum Versenden an drahtlose Clients. Drahtgebundene Clients können die Identität eines Servers durch Prüfen der Serverzertifikate gegen eine CRL, die in der drahtlosen Einrichtung geführt wird, authentifizieren.
Im Fall von drahtlosen Clients werden, da drahtlose Einrichtungen nicht über die lokalen Ressourcen oder die Kommunikationsbandbreite verfügen, um Rückrufverfahren , wie eine CRL, zu implementieren, Server einmal in einer Langzeitperiode authentifiziert (d. h. ein langlebiges Zertifikat wird ausgestellt), und Servern werden Kurzzeitzertifikate während der Langzeitperiode ausgestellt, die an Clients ausgestellt werden können. Die Server senden umgekehrt sowohl ein langlebiges Zertifikat als auch ein kurzlebiges Zertifikat zu dem Client, die beide für den Clienten zur Authentifizierung des Servers bestätigt werden müssen.
Wenn die CA einen Server zurückrufen möchte, beendet sie einfach das Ausstellen weiterer kurzlebiger Zertifikate an den Server. Wenn das kurzlebige Zertifikat nicht bestätigt wird, wird der Client dementsprechend nicht weiter mit einem aktuell gültigen Zertifikat präsentiert und wird so aufhören, den Server als authentifiziert zu betrachten. Dies verringert die Notwendigkeit für den Client, eine CRL zu führen, um serverseitige Zertifikate damit zu vergleichen.
Unterstützung serverseitiger Zertifikate
Eine Serverauthentifizierung ermöglicht Clients, Serverzertifikate zur Authentisierung von Servern zu nutzen, und ermöglicht nur Servern mit gültigen Serverzertifikaten sich mit einem Client zu verbinden. Serverzertifikate werden von einer CA erteilt (wie VeriSign von Montain View, Californien), die prüft, ob ein Serverzertifikatanmelder den CA-Kriterien für die Vertrauenswürdigkeit entspricht, bevor das Serverzertifikat erteilt wird. Das Serverzertifikat ermöglicht einem Server, sich mit einem Clienten bis zum Ablaufen der Gültigkeit des Serverzertifikats zu verbinden. Nach dem Ablauf wird der Server blockiert. Um den Zugang zu erneuern, muß die Vertrauenswürdigkeit des Servers von der CA wieder bestätigt werden.
Ein Serverzertifikat kann jedoch kompromittiert werden, bevor es abläuft. Drahtgebundene Einrichtungen können eine CRL zum Authentifizieren von Servern führen, während drahtlosen Einrichtungen kurzlebige Zertifikate ausgestellt werden (siehe oben).
15 ist ein Diagramm, das einen Arbeitsablauf 1500 für serverseitige Zertifizierungen für sowohl drahtgebundene als auch drahtlose Clients darstellt. Ein Sicherheitssystem 1312 fordert Serverzertifikate von einer Zertifizierungsstelle 1502 an, und die Zertifizierungsstelle leitet diese zu einer Zertifikataufbewahrungsstelle 1504, bei der Zertifikatinformationen (einschließlich Zertifikatnummern und auf wen sie ausgestellt wurden) geführt werden.
Ein Client 1302, 1308 kann mit einen Server 1312 in dem Datenzentrum 1316 über das Sicherheitssystem 1312 Verbindung aufnehmen. Eine drahtlose Zugriffseinrichtung 1302 versucht eine sichere Verbindung (die eine implizite Authentifizierungsanfrage ist, und manchmal als "Authentifizierungsanfrage" bezeichnet wird) mit dem Server durch Übertragen einer WTLS-Nachricht zu dem drahtlosen Netzwerk 1304 aufzubauen. Das drahtlose Netzwerk 1304 überträgt die Meldung zu einem WAP-Gateway 1306, während eine drahtlose Zugriffseinrichtung 1308 direkt eine Verbindung durch das öffentliche Netzwerk 1310 aufnehmen kann. Der WAP-Gateway 1306 überträgt dann die verschlüsselte Client-Nachricht an das Sicherheitssystem 1312 über ein öffentliches Netzwerk 1310. In Reaktion auf die Authentifizierungsanfrage des Clients sendet das Sicherheitssystem 1312 ein Serverzertifikat zu dem Client 1302, 1308. Der Client 1302, 1308 kann das Serverzertifikat anschließend authentifizieren.
16 zeigt ein Flußdiagramm, das ein Verfahren für serverseitige Zertifizierungen gemäß den allgemeinen Ausführungsformen der Erfindung darstellt. Das Verfahren startet beim Block 1600 und führt mit dem Block 1602 fort, bei dem das Sicherheitssystem nach Serverzertifikaten von einem CA anfragt, und das CA sendet die Zertifikate an das Sicherheitssystem beim Block 1604. Im Block 1606 sendet das Sicherheitssystem ein Serverzertifikat zu einem Client, wie in Reaktion auf eine Clientauthentifizierungsanfrage. Im Block 1608 wird ermittelt, ob das Serverzertifikat gültig ist. Im Block 1610 wird eine sichere Verbindung aufgebaut, wenn das Serverzertifikat gültig ist. Andernfalls beendet der Client die Verbindung im Block 1612. Das Verfahren endet im Block 1614.
Das Sicherheitssystem kann die Zertifikataufbewahrungsstelle in vom Benutzer definierten Intervallen abfragen, um die Zertifikate zu erhalten, kurzlebige und langlebige Zertifikate zu aktualisieren und/oder seine CRL zu aktualisieren.
Drahtloser Client
In dem drahtlosen Internet ist ein WTLS-Server-Zertifikat ein Zertifikat, das die Identität eines Servers gegenüber einer drahtlosen Einrichtung authentifiziert. Wenn ein Benutzer einer drahtlosen Einrichtung vertrauliche Informationen zu einem Server senden möchte, fragt die WAP-Einrichtung nach einem digitalen Zertifikat des Servers an. Das Zertifikat, das den öffentlichen Schlüssel des WAP-Servers enthält, wird von der drahtlosen Einrichtung benutzt, um:

– die Identität des Servers zu authentifizieren und
– Informationen für den Server unter Verwendung des WTLS-Protokolls zu verschlüsseln.

Die WPKI-Architektur benutzt jedoch eine andere Implementierung, da es für eine WAP-Einrichtung schwierig ist, kontinuierlich die CRL-Liste zu aktualisieren, um nach Widerrufen serverseitiger Zertifikate zu prüfen. In der WPKI-Architektur führt das Sicherheitssystem kurzlebige Zertifikate und langlebige Zertifikate. Die Nachfrageintervalle können benutzerdefiniert sein.
17 zeigt ein Flußdiagramm eines Verfahrens für serverseitige Zertifizierungen für drahtlose Clients gemäß Ausführungsformen der Erfindung. Das Verfahren beginnt beim Block 1700 und führt mit dem Block 1702 fort, bei dem ein Sicherheitssystem nach Serverzertifikaten (einschließlich dem Herunterladen und Aktualisieren von kurzlebigen und langlebigen Zertifikaten) von einer CA für den Servers anfragt. Da Serverzertifikate in benutzerdefinierten Intervallen abgefragt werden können, muß dieser Schritt nicht notwendigerweise jedesmal stattfinden.
Bei dem Block 1704 sendet die CA Serverzertifikate zu dem Sicherheitssystem. Bei dem Block 1706 werden sowohl langlebige als auch kurzlebige Zertifikate zu dem Client gesendet. Z. B. kann das Serverzertifikat zu dem Client in Reaktion auf eine Authentifizierungsanfrage eines Clients gesendet werden.
Beim Block 1708 wird durch verifizieren der CA-Signatur und der Gültigkeitsdauer des Zertifikats ermittelt, ob die Serverzertifikate gültig sind. Wenn sowohl das langlebige als auch das kurzlebige Zertifikat noch gültig sind, wird eine gesicherte Verbindung beim Block 3710 auf gebaut. Andernfalls kann der Client die Verbindung beim Block 1712 schließen. Das Verfahren endet beim Block 1714.
Drahtgebundener Client
In dem drahtgebundenen Internet ist gleichfalls ein SSL-Zertifikat ein Zertifikat, das die Identität des Servers gegenüber einer drahtgebundenen Einrichtung (d. h. einem Personalcomputer) authentifiziert.
Um Serverzertifikate zurückzuweisen, die als vor dem Ablauf kompromittiert bekannt sind, konsultiert ein Client eine Certificate-Revocation-List (CRL), welche in einer Public-Domain geführt wird, die aber von dem Client heruntergeladen werden kann. Typischerweise wird der Client die Verbindung schließen, wenn das Serverzertifikat in der CRL gefunden wird.
18 ist ein Flußdiagramm, das ein Verfahren für serverseitige Zertifizierungen für drahtgebundenen Clients gemäß Ausführungsformen der Erfindung darstellt. Das Verfahren beginnt beim Block 1800 und fährt mit dem Block 1802 fort, bei dem ein Sicherheitssystem Serverzertifikate von einer CA für den Server anfordert. Die CA sendet Serverzertifikate zu dem Sicherheitssystem im Block 1804. Beim Block 1806 wird ein Serverzertifikat zu dem Client geschickt. Das Serverzertifikat kann z. B. zu dem Clienten in Reaktion auf eine Authentifizierungsanfrage eines Clients gesendet werden.
Bei dem Block 1808 verifiziert der Client das Serverzertifikat, indem er ermittelt, ob das Serverzertifikat auf der CRL ist. Wenn das Serverzertifikat nicht auf der CRL ist, wird beim Block 1810 eine gesicherte Verbindung zwischen dem Client und dem Server aufgebaut. Andernfalls schließt beim Block 1812 der Client die Verbindung. Das Verfahren endet beim Block 1814.
Clientseitige Zertifikatunterstüztung
Eine Clientenauthentifizierung kann Clientzertifikate benutzen, die in Web-Browsern der Benutzer oder anderen Anwendungen des Client installiert sind, um Benutzer zu authentifizieren, und gestattet nur Clients mit gültigen Clientzertifikaten in einem autorisierten Bereich (d. h. beispielsweise in einem beschränkten Bereich auf einer Website). Ein Clientzertifikat wird von einer Certificate Authority (CA) ausgegeben. Eine CA prüft, ob ein Clientzertifikatanmelder den Kriterien der CA zur Vertrauenswürdigkeit entspricht, bevor ein Clientzertifikat ausgegeben wird. Das Clientzertifikat dient dem Zugang zu dem autorisierten Bereich bis seine Gültigkeit abläuft. Nach dem Ablauf wird der Benutzer blockiert. Um den Zugriff zu erneuern, muß die Vertrauenswürdigkeit des Benutzers von der CA vor dem Erneuern des Clientzertifikats wieder bestätigt werden. Das Abprüfen, wann Clientzertifikate ausgestellt und erneuert wurden, hilft dabei sicherzustellen, daß gültige Clientzertifikate nur in Händen von Benutzern sind, die vertrauenswürdig sind, um in einen autorisierten Bereich zu gelangen.
Ein Clientzertifikat kann jedoch auch bevor es abläuft kompromittiert werden. Z. B. kann es in falsche Hände fallen oder die CA kann entscheiden, daß der Benutzer, für den es ausgestellt wurde, nicht mehr vertrauenswürdig ist. Wenn ein Clientzertifikat kompromittiert wird, bevor es abläuft, kann die CA es zurückrufen durch Zufügen des zurückgerufenen Zertifikats zu einer Certificate-Revocation-List (CRL). Die CRL wird bei der CA geführt, kann jedoch vom Servern zur Authentifizierung von Clientidentitäten heruntergeladen werden.
Um Clientzertifikate zurückzuweisen, die als vor ihrem Ablauf kompromittiert bekannt sind, befragt ein Server eine Certificate-Revocation-List (CRL), die in einer Public-Domain geführt wird, die jedoch von den Servern heruntergeladen werden kann. Clients mit widerrufenen Clientzertifikaten wird der Zugriff zu einem autorisierten Bereich verweigert, wenn die widerrufenen Clientzertifikate in der CRL sind.
In Ausführungsformen der Erfindung unterstützt das Sicherheitssystem 1312 eine CRL. Das Sicherheitssystem 1312 lädt die CRL aus der Public-Domain herunter. Wenn ein Clientzertifikat in Antwort auf eine Authentifizierungsanfrage eines Servers empfangen wird, wird das Zertifikat gegen die CRL des Servers geprüft, um zu ermitteln, ob es widerrufen wurde.
In erfindungsgemäßen Ausführungsformen kann eine Authentifizierung über clientseitige Zertifikate durch das Sicherheitssystem für den Server ermöglicht oder verhindert werden. Eine Authentifizierung kann z. B. für Transaktionen, wie zum Plazieren von Aktienordern, ermöglicht werden, aber für Transaktionen, wie dem Bedienen von Klartextwebseiten verhindert werden.
19 ist ein Diagramm, das ein Arbeitsablauf 1900 für clientseitige Zertifikate für sowohl drahtgebundenen wie auch drahtlosen Clients darstellt. Ein drahtloser Client 1302 beantragt ein Zertifikat durch eine Verbindung zu einer CA 1504 über ein drahtloses Netzwerk 1902. Die CA 1502 stellt das Zertifikat aus und leitet es zu der Zertifikat-Aufbewahrungsstelle 1504 weiter. Die CA 1502 sendet anschließend ein Clientzertifikat oder eine Zertifikat-URL zu dem Client und der Client 1302 kann versuchen, eine Verbindung mit dem Server 1314 aufzubauen unter Verwendung einer WTLS-Nachricht und dem Clientzertifikat oder einem Link zu dem Clientzertifikat.
Das Sicherheitssystem 1312 aktualisiert seine CRL in benutzerdefinierten Intervallen. Es entschlüsselt die WTLS-Nachricht und prüft die Gültigkeit des Clientzertifikats, indem sie es mit der CRL vergleicht. Wenn des Clientzertifikat gültig ist, wird eine sichere Verbindung aufgebaut. Andernfalls kann der Server wählen, entweder die Verbindung zu schließen oder die Verbindung zu ermöglichen, dabei jedoch z. B. den Clientzugriff auf einen autorisierten Bereich zu verweigern.
Für einen drahtgebundenen Client 1308 wird ein Clientzertifikat von der Zertifizierungsstelle 1502 über ein öffentliches Netzwerk 1310 (d. h. das Internet) angefordert. Ein drahtgebundener Client 1308 kann den Versuch unternehmen, eine Verbindung mit dem Server 1314 aufzunehmen, indem er eine SSL-Nachricht und ein Clientzertifikat sendet. Wenn das Clientzertifikat gültig ist, wird die sichere Verbindung aufgebaut. Andernfalls kann der Server wählen, entweder die Verbindung zu schließen oder beispielsweise eine Verbindung zu ermöglichen, dabei jedoch z. B. den Clientzugriff auf einen autorisierten Bereich zu verweigern.
20 ist ein Flußdiagramm, das ein Verfahren für drahtgebundene Clientzertifikate gemäß allgemeinen Ausführungsformen der Erfindung darstellt. Es startet beim Block 2000 und fährt mit dem Block 2002 fort, bei dem ein Client nach drahtgebundenen Clientzertifikaten anfragt. Beim Block 2004 gibt die Zertifizierungsstelle drahtgebundene Clientzertifikate an den Client aus. Beim Block 2006 kann der Client ohne das drahtgebundene Clientzertifikat nach einer gesicherten Verbindung anfragen, und das drahtgebundene Clientzertifikat wird zu dem Server in Reaktion auf die Anfrage des Servers nach einer Clientauthentifizierung beim Block 2008 gesendet.
Ein Sicherheitssystem validiert das drahtgebundene Clientzertifikat für den Server beim Block 2010. Wenn es gültig ist, wird eine gesicherte Verbindung beim Block 2012 aufgebaut. Andernfalls wird keine gesicherte Verbindung beim Block 2014 aufgebaut und der Server kann wählen, entweder die Verbindung zu schließen, oder eine Verbindung ermöglichen, jedoch beispielsweise den Zugriff auf einen autorisierten Bereich dem Client zu verweigern. Das Verfahren endet beim Block 2016.
Drahtlose Clients
In dem drahtlosen Internet wird ein WTLS-Clientzertifikat benutzt, um eine drahtlose Einrichtung gegenüber einem Server zu authentifizieren. Als ein Beispiel werden WTLS-Clientzertifikate als ein Teil von WAP 1.2 definiert und entweder z. B. als X.509-Zertifikate oder als Minizertifikate formatiert.
21 ist ein Flußdiagramm, das ein Verfahren für drahtlose clientseitige Zertifikate gemäß Ausführungsformen der Erfindung darstellt. Das Verfahren beginnt beim Block 2100 und fährt mit dem Block 2102 fort, bei dem ein Client nach einem drahtlosen Clientzertifikat anfragt. Beim Block 2104A erzeugt eine CA ein URL (Uniform Resource Locator) zu den drahtlosen Clientzertifikat und sendet die Zertifikat-URL zu dem Client. Alternativ kann ein drahtloses Clientzertifikat, das von der CA ausgestellt wird, zu dem Clienten gesendet werden und in einem Wireless-Identity-Module (WIM) in der WAP-Einrichtung 2104B gespeichert werden. WIM wird benutzt, um WTLS und Anwendungslevel-Sicherheitsfunktionen auszuführen und um Informationen zu speichern und zu bearbeiten, die für Benutzeridentifikationen und Authentifizierungen benötigt werden.
Der Client kann nach einer gesicherten Verbindung bei 2106 anfragen und danach das Clientzertifikat (oder ein Link zu ihm) in Antwort auf die Anforderung des Servers zur Authentifizierung bei 2108 senden. Das Sicherheitssystem entschlüsselt die WTLS-Nachricht und vergleicht das Clientzertifikat mit einer CRL beim Block 2110, um zu ermitteln, ob das Clientzertifikat authentisch ist. Wenn das Clientzertifikat gültig ist, wird beim Block 2112 eine gesicherte Verbindung zwischen dem Client und dem Server aufgebaut. Andernfalls wird keine gesicherte Verbindung beim Block 2114 aufgebaut und der Server kann wählen, entweder die Verbindung zu schließen, oder die Verbindung zu ermöglichen, ohne dem Client den autorisierten Bereich zu ermöglichen. Das Verfahren endet beim Block 2116.
Drahtgebundene Clients
In dem drahtgebundenen Internet ist ein SSL-Clientzertifikat ein Clientzertifikat, das die Identität einer drahtgebundenen Einrichtung gegenüber dem Server authentifiziert. 22 ist ein Flußdiagramm, das ein Verfahren für drahtgebundene clientseitige Zertifikate gemäß Ausführungsformen der Erfindung darstellt.
Das Verfahren beginnt beim Block 2200 und führt bei dem Block 2202 fort, bei dem ein Client ein drahtgebundenes Clientzertifikat anfordert. Beim Block 2204 gibt die CA das Zertifikat aus und sendet es zu dem Client. Beim Block 2206 versucht der Client eine sichere Verbindung zu dem Server aufzubauen und sendet danach ein drahtgebundenes Clientzertifikat in Antwort auf die Authentifizierungsanfrage des Servers beim Block 2208.
Beim Block 2208 entschlüsselt das Sicherheitssystem die SSL-Nachricht und vergleicht das Clientzertifikat mit einer CRL, um festzustellen, ob das Clientzertifikat authentisch ist. Wenn das Clientzertifikat gültig ist, wird eine gesicherte Verbindung zwischen dem Client und dem Server beim Block 2212 aufgebaut. Andernfalls wird beim Block 2214 keine gesicherte Verbindung aufgebaut, und der Server kann entscheiden, entweder die Verbindung zu schließen oder die Verbindung zu ermöglichen, ohne dem Client den autorisierten Bereich zu ermöglichen. Das Verfahren endet beim Block 2216.
Digitale Signaturen
Zusätzlich zum Senden eines Clientzertifikats kann der Client eine digitale Signatur senden. Wenn ein Client eine digitale Signatur sendet, wird sie von dem Server verifiziert. Wenn die digitale Signatur gültig ist, wird eine gesicherte Verbindung aufgebaut. Andernfalls wird dem Clienten der Zugriff zu dem autorisierten Bereich verwehrt.
Für einen drahtlosen Client können digitale Signaturen beispielsweise unter Verwendung verfügbarer WAP-Funktionen implementiert werden. WAP 1.2 definiert auch eine auf WPKIbasierende Funktion, die nicht ein Teil von WTLS ist. Diese Funktion, welche einem WAP-Client ermöglicht, eine Übertragung digital zu signieren, ist als die Wireless-Markup- Language (WML) Script-Sign-Text-Function bekannt und ist für Anwendungen gedacht, die Unbedenklichkeitssignaturen von Clients benötigen.
Sicherheitssystem
23 stellt die Architektur des Sicherheitssystems dar. Das Sicherheitssystem 2300 umfaßt ein Anwendungsmodul 2302, ein SSL-Modu1 2304, ein PKI-Modul 2308, ein WTLS-Modul 2306 und ein WPKI-Modul 2310. Der Eingang des Sicherheitssystems umfaßt eingehende Daten 2314, welche SSL-verschlüsselte Daten, WTLS-verschlüsselte Daten oder Klartextdaten sein können. Die Ausgabe des Sicherheitssystems sind Klartextdaten 2316, die anschließend von einem Server bearbeitet werden können.
Das Anwendungsmodul 2302 ermittelt, ob die eingehenden Daten 2314 SSL-verschlüsselt, WTLS-verschlüsselt oder Klartext sind. Es anschließend den WTLS/SSL-Handshake für den Servers hinter ihm durch und arbeitet mit PKI/WPKI-Modulen für die server- und clientseitige Authentifizierung zusammen.
Wenn die eingehenden Daten 2314 SSL-verschlüsselt sind und die Authentifizierung aufgebaut wurde, ruft das Anwendungsmodul das SSL-Modu1 2304 auf. Das SSL-Modul 2304 liest die Daten und entschlüsselt es zu Klartext 2316. Wenn es den Vorgang abgeschlossen hat, informiert es das Anwendungsmodul 2302. Das SSL-Modul 2304 kann die Hardware-Verschlüsselungskarte für SSL-Funktionen benutzen und um für eine SSL-Beschleunigung zu sorgen. Das SSL-Modul kann ein SSL-Konvertionssystem 374 der 1 umfassen. In allgemeinen Ausführungsformen der Erfindung kann das SSL-Modul 2304 ein Entschlüsselungsmodul für drahtgebundene Einrichtungen sein, das Daten akzeptiert, die unter Verwendung eines drahtgebundenen Sicherheitsprotokolls verschlüsselt sind (d. h. Daten, die SSLverschlüsselt sind) und das solche Daten zu Klartext entschlüsselt.
Das WTLS-Modul 2306 wird aufgerufen, wenn das Anwendungsmodul 2302 WTLSverschlüsselte Daten erkennt und die Authentifizierung aufgebaut wurde. Das WTLS-Modul 2306 liest die eingehenden Daten 2314 und entschlüsselt sie zu Klartext 2316. Es informiert das Anwendungsmodul 2302, wenn es fertig ist. Das WTLS-Modul 2306 kann entweder reine Software oder eine Kombination von Software und Hardware sein. Die WTLS-Verschlüsselung und -Entschlüsselung kann durch Ausführen der prozessorintensiven Funk tionen in der Hardware beschleunigt werden. Das WTLS-Modul kann das WTLS-Konvertierungsmodul1 372 der 3 umfassen. In allgemeinen Ausführungsformen der Erfindung kann das WTLS-Modul 2306 ein Entschlüsselungsmodul für drahtlose Einrichtungen sein, das Daten akzeptiert, die unter Verwendung eines drahtlosen Sicherheitsprotokolls verschlüsselt sind (d. h. Daten, die WTLS-verschlüsselt sind) und das solche Daten in Klartext entschlüsselt.
Das PKI-Modul 2308 besitzt die Funktionen zum Verifizieren von digitalen Signaturen und/oder zur Authentifizierung von drahtgebundenen Clientzertifikaten durch Überprüfen ihrer CRL für beliebige Clientzertifikate, die von der CA widerrufen wurden. Die CRL-Liste wird in benutzerdefinierten Intervallen unter Verwendung eines LDAP/FTP/HTTP-Aufrufs zu dem LDAP-Server aktualisiert. Das PKI-Modul 2308 unterstützt auch eine Authentifizierung des Servers durch Herunterladen von serverseitigen Zertifikaten von einer CA und durch Ausgeben von ihnen an Clients. In erfindungsgemäßen allgemeinen Ausführungsformen kann das PKI-Modul 2308 ein Authentifizierungsmodul für drahtgebundene Einrichtungen sein, das drahtgebundene Authentifizierungsinformationen aufnimmt und das die drahtgebundenen Einrichtungen unter Verwendung der drahtgebundenen Authentifizierungsinformationen authentifiziert.
Das WPKI-Modul 2310 besitzt die Funktionen zum Verifizieren drahtloser digitaler Signaturen und/oder zum Authentifizieren drahtloser Clientzertifikate durch Überprüfen seiner CRL für beliebige Clientzertifikate, die von der CA widerrufen wurden. Die CRL-Liste wird in benutzerdefinierten Intervallen unter Verwendung eines LDAP (Lightweight Directory Access Protocol)/FTP (File Transfer Protocol)/HTTP (Hyper Text Transfer Protocol) -Aufrufs an dem LDAP-Server aktualisiert. In allgemeinen Ausführungsformen der Erfindung kann das WPKI-Modul 2310 ein Authentifizierungsmodul für drahtlose Einrichtungen sein, das drahtlose Authentifizierungsinformationen aufnimmt und unter Verwendung der Authentifizierungsinformationen die drahtlose Einrichtung authentifiziert.
Das WPKI-Modul 2310 unterstützt auch eine Authentifikation des Servers unter Verwendung serverseitiger Zertifikate. Es gibt zwei Arten von serverseitigen Zertifikaten, die von dem Modul gehandhabt werden. Kurzlebige Zertifikate können so gesetzt werden, daß sie alle 24 Stunden ablaufen, und langlebige Zertifikate können so gesetzt werden, daß sie in einem Jahr ablaufen. Sie werden in benutzerdefinierten Intervallen aktualisiert, d. h. von einer CA heruntergeladen.
Andere Module
Wenn eine Anwendung einen Klartext 2314 von dem SSL-Modul 2304 oder dem WTLS-Modul 2306 erhält, kann sie andere Module 2312 aufrufen, wie ein XML-Bearbeitungsmodul, ein Lastausgleichsmodul oder ein XML-Übertragungsmodul, um zum Beispiel andere Funktionen auf der Netzwerkeinrichtung zur Verfügung zu stellen. Es kann mit Merkmalen kombiniert werden, wie inhaltsbezogene Schalten, XML-bezogenes Weiterleiten und das Erkennen von Einrichtungen.
Konfigurationen
24 ist ein Beispiel, wie ein Sicherheitssystem konfiguriert werden kann. Felddefinitionen sind Folgende:

– das Map-ID-Feld liefert eine arbiträre Kennung für eine Verbindung;
– das Verbindungstypfeld liefert einen Verbindungstyp, beispielsweise entweder gesichert oder ungesichert, sowie den Verschlüsselungstyp (d. h. SSL oder WTLS);
– das Schlüssel-ID-Feld liefert Schlüsselidentifikationen zum Gebrauch für die gesicherte Verbindung;
– das Server-IP-Feld liefert eine Internetprotokolladresse, um mit Servern in dem Datenzentrum zu kommunizieren;
– das Netzwerk-Port-Feld liefert vorbestimmte bekannte Port-Nummern, um gesicherte oder ungesicherte Daten aus dem öffentlichen Netzwerk zu empfangen;
– das Server-Port-Feld liefert einen bekannten vorbestimmten Port, um Klartextdaten mit den Servern in dem Datenzentrum zu übermitteln;
– das Chiffrier-Suites-Feld enthält eine Angabe des Sicherheitsmaßstabs, der für die gesicherten und ungesicherten Verbindungen benutzt wird;
– das Umleitungs-Feld liefert eine Option, um eine Zugriffseinrichtung auf Sicherheitsupgrade-Resourcen in dem Fall umzuleiten, daß an die Einrichtungen die verwendeten Sicherheitsmerkmale nicht unterstützt;
– das Client-Authentifizierungs-Feld bestimmt, ob eine Clientauthentifizierung, welche digitale Zertifikate verwendet, angefordert wird oder nicht;
– das Digital-Signatur-Feld bestimmt, ob eine Clientauthentifizierung, welche digitale Signaturen verwendet, aufgerufen wird oder nicht.

Die Konfiguration des Sicherheitssystems kann entweder über GUI (Graphical User Interface) oder CLI (Common Language Interface) durchgeführt werden. Beispielsweise können Clientzertifikate und Serverzertifikate von einer CLI von Sicherheitsanbietern erhalten werden. Die Erneuerungszeiten für eine CRL kann über ein CLI eingestellt werden. Die CRL-Liste kann von einem LDAP-Server über HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol) oder LDAP-Anfragen aktualisiert werden. Die kurzlebigen Server-Zertifikate können auch automatisch von der CA-Aufbewahrungsstelle abhängig von benutzerdefinierten Intervallen aktualisiert werden. Der Umleitungsparameter wird zur Umleitung des Client zu einer URL mit den benötigten sicherheitsbezogenen Informationen benutzt, wenn der Client die benötigten Sicherheitsfunktionen clientseitig nicht unterstützt.
Fazit
In der vorhergehenden Beschreibung wurde die Erfindung in Bezug auf spezielle Ausführungsformen davon beschrieben. Es ist jedoch deutlich, daß verschiedene Modifikationen und Änderungen daran vorgenommen werden könne, ohne von dem breiteren Grundge danken und Umfang der Erfindung abzuweichen. Die Beschreibung und die Zeichnungen sind daher als eine Darstellung und nicht im beschränkenden Sinne zu betrachten.
Obgleich die PKI/WPKI und SSL/WTLS-Protokolle hierin beschrieben wurden, wird ein Durchschnittsfachmann verstehen, daß beispielsweise diese Protokolle nur zur Darstellung beschrieben sind und nicht zur Beschränkungen der Erfindung bestimmt sind. So können auch andere Protokolle benutzt werden.
Zusammenfassung der Erfindung
Authentifizierungsfunktionen werden in einem Sicherheitssystem zentral zusammengefaßt, um Server von diesen Funktionen zu befreien und um eine End-to-End-Lösung für gesicherte Internettransaktionen zur Verfügung zu stellen. Das Sicherheitssystem unterstützt Authentifizierungsfunktionen zum Authentifizieren eines Servers durch Anfragen nach Serverzertifikaten von einer Zertifizierungssstelle und durch Senden von Serverzertifikaten zu Clients, die nach einer Authentifizierung anfragen. Das Sicherheitssystem authentifiziert außerdem Clients durch Prüfen digitaler Signaturen, Überprüfen der Clientzertifikate, das ein Prüfen der CA-Signaturen umfaßt, durch Prüfen der Gültigkeitsdauer der Signaturen, durch Führen einer Certificate-Revocation-List (CRL) und durch Prüfen der Clientzertifikate mit der CRL.

Claims

Verfahren, das folgende Schritte umfaßt: Senden einer Nachricht von einem Client zu einem Server, wobei die Nachricht dazu bestimmt ist, eine gesicherte Verbindung aufzubauen; Abfangen der Daten an einem Sicherheitssystem, das dem Server zugeordnet ist, um Authentifizierungsfunktionen durchzuführen; und Ausbauen einer gesicherten Verbindung, wenn richtige Authentifizierungen durchgeführt werden.
Verfahren nach Anspruch 1, bei dem die richtigen Authentifizierungen ein Ermitteln umfassen, ob der Server authentisch ist, wenn der Client nach einer Authentifizierung angefragt hat.
Verfahren nach Anspruch 2, bei dem die richtigen Authentifizierungen zusätzlich ein Ermitteln umfassen, ob der Client authentisch ist, wenn der Server nach einer Authentifizierung angefragt hat.
Verfahren nach Anspruch 1, bei dem die richtigen Authentifizierungen ein Überprüfen digitaler Zertifikate umfassen.
Verfahren nach Anspruch 1, das zusätzlich ein Entschlüsseln der Nachricht umfaßt, wenn die Nachricht verschlüsselt ist.
Verfahren nach Anspruch 1, bei dem die Authentifizierungsfunktionen folgende Schritte umfassen: Authentisierungsanfrage des Servers bei dem Client; Empfangen eines Clientzertifikats von dem Client; und Ermitteln, ob der Client authentisch ist, wobei das Ermitteln bei dem Sicherheitssystem für den Server stattfindet.
Verfahren nach Anspruch 6, bei dem die Nachricht eine digitale Signatur zum Validieren der Identität des Clients umfaßt und das Ausführen der richtigen Authentifizierungen ein Validieren der digitalen Signatur umfaßt.
Verfahren, das folgende Schritte umfaßt: Empfangen einer Client-Hello-Nachricht von einem Client an einer Einrichtung, die einem Server zugeordnet ist, wobei die Client-Hello-Nachricht eine Anforderung zum Aufbau einer gesicherten Verbindung mit dem Server anzeigt; Senden einer Server-Hello-Nachricht von der Einrichtung für den Server in Antwort auf die Client-Hello-Nachricht, um die Client-Hello-Meldung zu bestätigen; falls eine Authentifizierung von wenigstens dem Client oder dem Server angefragt wird, Austauschen von Authentifizierungsinformation; Senden einer Server-Hello-Done-Nachricht von der Einrichtung zu dem Client, wobei das Senden für den Server erfolgt; Empfangen einer Finished-Nachricht von dem Client und Senden einer Finished-Nachricht von der Einrichtung an den Client, wobei das Senden für den Server erfolgt.
Verfahren nach Anspruch 8, bei dem der Austausch der Authentifizierungsinformation folgende Schritte umfaßt: falls die Client-Hello-Nachricht eine Authentifizierungsanfrage von dem Server umfaßt, Senden von Authentifizierungsinformationen von der Einrichtung zu dem Client für den Server und, falls der Server nach einer Authentifizierung bei dem Client anfragt, Empfangen von Authentifizierungsinformationen von dem Client.
Verfahren nach Anspruch 8, bei dem das Senden der Finished-Nachricht von der Einrichtung zu dem Client für den Server folgende Schritte umfaßt: Ermitteln, ob der Client authentisch ist, und, falls der Client authentisiert wurde, Aufbauen einer gesicherten Verbindung zwischen dem Client und dem Server.
Verfahren nach Anspruch 10, bei dem die Authentifizierungsinformationen ein Clientzertifikat umfassen und das Ermitteln, ob der Client authentisch ist, ein Validieren des Clientzertifikats umfaßt.
Verfahren nach Anspruch 11, bei dem das Validieren des Clientzertifikats die Feststellung umfaßt, daß das Clientzertifikat nicht auf einer Certificate-Revocation-Liste steht.
Verfahren nach Anspruch 11, bei dem die Authentifizierungsinformationen zusätzlich eine digitale Signatur umfassen und das Ermitteln, ob der Client authentisch ist, zusätzlich ein Verifizieren der digitalen Signatur umfaßt.
Verfahren nach Anspruch 8, das zusätzlich ein Entschlüsseln der Nachricht umfaßt, falls die Nachricht verschlüsselt ist.
Vorrichtung, die Folgendes umfaßt: ein Anwendungsmodul zum: Empfangen eingehender Daten, die von einem Client gesendet werden und für einen gegebenen Server von mehreren Servern in einem Datenzentrum bestimmt sind, und Weiterleiten der Daten zu einem Authentifizierungsmodul, um die Identität des Clients zu validieren; ein Authentifizierungsmodul für drahtgebundene Einrichtungen, das den mehreren Servern zugeordnet ist, zum: Empfangen der eingehenden Daten von dem Anwendungsmodul, wenn die eingehenden Daten unter Verwendung drahtgebundener Authentifizierungsinformationen gesendet werden, und Authentifizieren der drahtgebundenen Einrichtung; ein Authentifizierungsmodul für drahtlose Einrichtungen, das den mehreren Servern zugeordnet ist, zum: Empfangen der eingegebenen Daten von dem Anwendungsmodul, wenn die eingegebenen Daten unter Verwendung drahtloser Authentifizierungsinformationen gesendet werden, und Authentifizieren der drahtlosen Einrichtung; ein Entschlüsselungsmodul für drahtgebundene Einrichtungen, das den mehreren Servern zugeordnet ist, zum: Empfangen der eingehenden Daten von dem Anwendungsmodul, wenn die eingehenden Daten unter Verwendung eines drahtgebundenen Sicherheitsprotokolls verschlüsselt sind, und Entschlüsseln der Daten zu Klartext und ein Entschlüsselungsmodul für drahtlose Einrichtungen, das den mehreren Servern zugeordnet ist, zum: Empfangen der eingehenden Daten von dem Anwendungsmodul, wenn die eingehenden Daten unter Verwendung eines drahtlosen Sicherheitsprotokolls verschlüsselt sind; und Entschlüsseln der Daten zu Klartext.
Vorrichtung nach Anspruch 15, bei der das Authentifizierungsmodul für drahtgebundene Einrichtungen und das Authentifizierungsmodul für drahtlose Einrichtungen zusätzlich Authentifizierungsfunktionen zum Authentifizieren des gegebenen Servers unterstützen durch:
Anfordern von Serverzertifikaten von einer Zertifizierungsstelle; Speichern der Serverzertifikate und Senden wenigstens eines der Serverzertifikate an einen Client in Antwort auf die Authentifizierungsanfrage des Clients.
Vorrichtung nach Anspruch 16, bei welcher der Client ein drahtloser Client ist und das Senden ein Senden eines langlebigen Zertifikates und eines kurzlebigen Zertifikates zu dem drahtlosen Client umfaßt.
Vorrichtung nach Anspruch 16, bei der das Anfragen nach Serverzertifikaten von der Zertifizierungsstelle ein Anfragen der Serverzertifikate in benutzerdefinierten Intervallen umfaßt.
System, das Folgendes umfaßt: einen oder mehrere Server, um Daten mit Clients auszutauschen, und ein Sicherheitssystem, das einem oder mehreren Servern zugeordnet ist, zum: Unterstützen von Authentifizierungsfunktionen zum Authentifizieren der Identität des einen oder der mehreren Server und Authentifizieren der Identität von Clients, die nach einer gesicherten Verbindung mit dem einen oder den mehreren Servern anfragen.
System nach Anspruch 19, bei dem die Authentifizierungsfunktionen zum Authentifizieren der Identität des einen oder der mehreren Server Folgendes umfassen: Anfragen nach Serverzertifikaten von einer Zertifizierungsstelle; und Senden eines Serverzertifikats zu dem Client in Antwort auf eine Client-Authentifizierungsanfrage von einem der Server.
System nach Anspruch 19, bei dem die Authentifizierung der Identität der Clients, die nach einer gesicherten Verbindung mit einem oder mehreren Servern anfragen, Folgendes umfaßt: Aktualisieren einer Certificate-Revocation-Liste (CRL); Empfangen eines Clientzertifikats von einem Client, der nach einer gesicherten Verbindung mit einem bestimmten Server von den Servern anfragt, die dem Sicherheitssystem zugeordnet sind; Ermitteln, ob das Clientzertifikat in der CRL steht; und falls das Clientzertifikat in der CRL steht, Verweigern des Clientzugriffs zu dem bestimmten Server.
Vorrichtung, die Folgendes umfaßt: eine erste Einrichtung zum: Empfangen eingehender Daten, die von einem Client gesendet werden und für einen bestimmten Server von einer Mehrzahl von Servern in einem Datenzentrum bestimmt sind; und Weiterleiten der Daten zu einer Einrichtung zum Überprüfen der Identität des Clients durch Authentifizieren einer Einrichtung, die dem Client zugeordnet ist; eine zweite Einrichtung zum: Empfangen eingehender Daten von der ersten Einrichtung, wenn die eingehenden Daten unter Verwendung drahtgebundener Authentifizierungsinformationen gesendet wurden; und Authentifizieren der drahtgebundenen Einrichtung; eine dritte Einrichtung zum: Empfangen der eingehenden Daten von der ersten Einrichtung, falls die eingehenden Daten unter Verwendung drahtloser Authentifizierungsinformationen gesendet wurden; und Authentifizieren der drahtlosen Einrichtung; eine vierte Einrichtung zum: Empfangen der eingehenden Daten von der ersten Einrichtung, falls die eingehenden Daten unter Verwendung eines drahtgebundenen Sicherheitsprotokolls verschlüsselt wurden und Entschlüsseln der Daten zu Klartext und eine fünfte Einrichtung zum: Empfangen der eingehenden Daten von der ersten Einrichtung, falls die eingehenden Daten unter Verwendung eines drahtlosen Sicherheitsprotokolls verschlüsselt wurden; und Entschlüsseln der Daten zu Klartext.
Vorrichtung nach Anspruch 22, bei der die zweite und dritte Einrichtung zusätzlich Authentifizierungsinformationen zum Authentifizieren des bestimmten Servers unterstützen durch: Anfragen nach Serverzertifikaten von einer Zertifizierungsstelle; Speichern der Serverzertifikate und Senden wenigstens eines der Serverzertifikate zu einem Client in Antwort auf die Authentifizierungsanfrage des Clients.
Vorrichtung nach Anspruch 23, bei der der Client ein drahtloser Client ist und das Senden ein Senden eines langlebigen Zertifikats und eines kurzlebigen Zertifikats zu dem drahtlosen Client umfaßt.
Maschinenlesbares Medium nach Anspruch 23, bei dem das Anfragen nach Serverzertifikaten von einer Zertifizierungsstelle ein Anfragen nach Serverzertifikate in benutzerdefinierten Intervallen umfaßt.
Maschinenlesbares Medium, auf dem Daten gespeichert sind, die Befehlsabfolgen darstellen, wobei die Befehlsabfolgen, wenn sie auf einem Prozessor ausgeführt werden, den Prozessor veranlassen, folgende Schritte auszuführen: Empfangen einer Nachricht von einem Client an einen Server, wobei die Nachricht dazu bestimmt ist, eine gesicherte Verbindung aufzubauen; Abfangen der Daten an einem Sicherheitssystem, das dem Server zugeordnet ist, um Authentifizierungsfunktionen aufzuführen, und Aufbauen einer gesicherten Verbindung, wenn richtige Authentifizierungen durchgeführt werden.
Maschinenlesbares Medium nach Anspruch 26, bei dem die korrekten Authentifizierungen ein Ermitteln umfassen, ob der Server authentisch ist, wenn der Client nach einer Authentifizierung angefragt hat.
Maschinenlesbares Medium nach Anspruch 26, bei dem die Nachricht ein Clientzertifikat zum Validieren der Identität des Clients umfaßt und das Ausführen der korrekten Authentifizierungen ein Validieren des Clientzertifikats umfaßt.
Maschinenlesbares Medium nach Anspruch 26, bei dem die Authentifizierungsfunktionen folgende Schritte umfassen: Anfragen nach einer Authentifizierung des Sicherheitssystems von dem Client für den Server; Empfangen eines Clientzertifikats von dem Client und Ermitteln, ob der Client authentifiziert ist, wobei das Ermitteln bei dem Sicherheitssystem im Auftrag des Servers stattfindet.
Vorrichtung, die Folgendes umfaßt: wenigstens einen Prozessor und ein maschinenlesbares Medium mit darauf codierten Befehlen, welche, wenn sie von dem Prozessor ausgeführt werden, in der Lage sind, den Prozessor zu folgenden Schritten anzuweisen: Empfangen einer Nachricht von einem Client an einen Server, wobei die Nachricht dazu bestimmt ist, eine gesicherte Verbindung aufzubauen; Abfangen der Daten an einem Sicherheitssystem, das dem Server zugeordnet ist, um Authentifizierungsfunktionen auszuführen, und Aufbauen einer gesicherten Verbindung, wenn richtige Authentifizierungen ausgeführt werden.
Verfahren nach Anspruch 30, bei dem die korrekten Authentifizierungen ein Ermitteln umfassen, ob der Server authentifiziert ist, wenn der Client nach einer Authentifizierung angefragt hat.
Vorrichtung nach Anspruch 30, bei der die Nachricht ein Clientzertifikat umfaßt, um die Identität des Clients zu validieren, und das Ausführen der korrekten Authentifizierungen ein Validieren des Clientzertifikats umfaßt.