DE602004001717T2 - Authentisierungsmethode in einem Draht/drahtlos-Kommunikationssystem mit Auszeichnungssprache - Google Patents

Authentisierungsmethode in einem Draht/drahtlos-Kommunikationssystem mit Auszeichnungssprache Download PDF

Info

Publication number
DE602004001717T2
DE602004001717T2 DE602004001717T DE602004001717T DE602004001717T2 DE 602004001717 T2 DE602004001717 T2 DE 602004001717T2 DE 602004001717 T DE602004001717 T DE 602004001717T DE 602004001717 T DE602004001717 T DE 602004001717T DE 602004001717 T2 DE602004001717 T2 DE 602004001717T2
Authority
DE
Germany
Prior art keywords
authentication
client
server
authentication method
type
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE602004001717T
Other languages
English (en)
Other versions
DE602004001717D1 (de
Inventor
Se-Wan Gu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of DE602004001717D1 publication Critical patent/DE602004001717D1/de
Application granted granted Critical
Publication of DE602004001717T2 publication Critical patent/DE602004001717T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Description

  • Hintergrund der Erfindung
  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft die Authentifikation in einem drahtgebundenen/drahtlosen Kommunikationssystem mittels einer Auszeichnungssprache, genauer gesagt ein Authentifikationsverfahren zwischen einem Client und einem Server in einem drahtgebundenen/drahtlosen Kommunikationssystem mittels einer Synchronisationsauszeichnungssprache (SyncML).
  • 2. Beschreibung des Standes der Technik
  • Ist im Falle einer Authentifikation durch Zugangsanforderung zwischen einem Client und einem Server in einem drahtgebundenen/drahtlosen Kommunikationssystem mittels Auszeichnungssprache die Authentifikation erfolgreich durchgeführt, kann der Zugriff aufrechterhalten und mit einem Folgeschritt fortgefahren werden.
  • Ist beispielsweise wegen der Verteilung der gleichen Daten in dem drahtgebundenen/drahtlosen Kommunikationssystem und den Terminals eine Datensynchronisierung nötig, so erfordert dies einen Authentifikationsprozess zwischen einem Client und einem Server, die eine Datensynchronisation aufrechterhalten müssen.
  • SyncML ist ein Standardprotokoll zur Datensynchronisierung, das zur Synchronisation persönlicher Informationen auf einem Webportal, Mobilfunkgerät oder PC eingesetzt wird. Zusätzlich kann SyncML eine Datensynchronisationsfunktion für verschiedene Anwendungsdienste wie eine E-Mail und ein Textmemo wie auch eine Verwaltungsfunktion für persönliche Information unterstützen.
  • 1 veranschaulicht ein allgemeines Authentifikationsverfahren zwischen einem Client und einem Server durch Datensynchronisation eines Kommunikationssystems mittels SyncML.
  • Bezugnehmend auf 1, wenn Datensynchronisation zwischen dem Client und dem Server unter Verwendung der SyncML durchgeführt wird, fordert der Client eine Datensynchronisation mit dem Server an (S10). Der Server verlangt eine Identität und ein Passwort vom Client (S12). Der Client verschlüsselt seine Identität und sein Passwort oder komprimiert seine Identität und sein Passwort mittels eines vorbestimmten Algorithmus wie MD5 und verschlüsselt die komprimierte Identität und das Passwort und übermittelt die verschlüsselte Identität und das Passwort an den Server (S14). Der Server bestätigt die Identität und das Passwort, und benachrichtigt den Client von einem Authentifikationsergebnis (S16).
  • Wurde die Authentifikation für den Client erfolgreich durchgeführt, so übermittelt der Server seine eigene Identität und Passwort an den Client, um vom Client authentifiziert zu werden. Der Client bestätigt die Identität und das Passwort, und benachrichtigt den Server von einem Authentifikationsergebnis.
  • Wurde die bidirektionale Authentifikation erfolgreich abgeschlossen, so wird eine bidirektionale oder einseitige Synchronisationsprozedur für die geänderten Daten zwischen dem Client und dem Server durchgeführt.
  • Das allgemeine Authentifikationsverfahren in dem die Auszeichnungssprache benutzenden Kommunikationssystem kann die Authentifikation lediglich durch den Gebrauch von Identitäten und Passwörtern durchführen. Dementsprechend muss der Authentifikationsprozess auf der Basis von den Identitäten und Passwörtern durchgeführt werden. An dieser Stelle kann Sicherheitsinformation für die Authentifikation entweichen, was in einer schwachen Sicherheit resultiert. Ein besonderer Authentifikationsserver zur Kompensation der schwachen Sicherheit des Authentifikationsprotokolls kann ebenfalls verwendet werden. Es ist jedoch schwierig, zusätzlich den Authentifikationsserver anzuschließen.
  • Zusammenfassung der Erfindung
  • Es ist daher ein Ziel der vorliegenden Erfindung, ein Authentifikationsverfahren in einem drahtgebundenen/drahtlosen, eine Auszeichnungssprache verwendenden Kommunikationssystem bereitzustellen, das verschiedene Authentifikationsverfahrensarten zwischen einem Client und einem Server auswählen kann, indem ein Strukturprotokoll für eine in der Auszeichnungssprache verwendete Nachricht so umgesetzt wird, dass es verschiedene Authentifikationsverfahrensarten hat.
  • Ein weiteres Ziel der vorliegenden Erfindung ist, ein Authentifikationsverfahren in einem eine Auszeichnungssprache verwendenden, drahtgebundenen/drahtlosen Kommunikationssystem bereitzustellen, das starke bidirektionale Authentifikation durch dynamisches Auswählen von Authentifikationsverfahrensarten zwischen einem Client und einem Server durchführen kann.
  • Um diese und andere Vorzüge zu verwirklichen und in Übereinstimmung mit der Zielsetzung der vorliegenden Erfindung wird, wie in diesem Dokument ausgeführt und allgemein beschrieben, ein Authentifikationsverfahren in einem drahtgebundenen/drahtlosen, eine Auszeichnungssprache verwendenden Kommunikationssystem bereitgestellt, das verschiedene Authentifikationsverfahrensarten in einer Dokumententypdefinition (DTD) zur Angabe einer Auszeichnungssprachenstruktur angibt und dynamisch die Authentifikationsverfahrensart zwischen einem Client und einem Server aus den angegebenen Authentifikationsverfahrensarten auswählt.
  • Übermittelt der Client eine Zugangsanforderung, so wählt der Server zufallsgesteuert eine der Authentifikationsverfahrensarten aus und fordert vom Client der zufallsgesteuert ausgewählten Authentifikationsverfahrensart gemäße Sicherheitsinformationen an.
  • Gemäß einem Aspekt der vorliegenden Erfindung beinhaltet ein Authentifikationsverfahren zwischen einem Client und einem Server in einem drahtgebundenen/drahtlosen, eine Auszeichnungssprache verwendenden Kommunikationssystem die folgenden Schritte: Erkennen identischer Authentifikationsverfahrensarten zwischen dem Client und dem Server; serverseitiges Authentifizieren des Clients durch zufallsgesteuertes Auswählen einer Authentifikationsverfahrensart der identischen Authentifikationsverfahrensarten; und clientseitiges Authentifizieren des Servers durch Verwenden einer anderen zufallsgesteuerten Authentifikationsverfahrensart der identischen Authentifikationsverfahrensarten.
  • Die eine zufallsgesteuert ausgewählte Authentifikationsverfahrensart und die andere zufallsgesteuert ausgewählte Authentifikationsverfahrensart sind einander gleich oder verschieden.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung beinhaltet ein eine Auszeichnungssprache verwendendes Authentifikationsprotokoll in einem drahtgebundenen/drahtlosen Kommunikationssystem: eine Dokumententypdefinition in einer erweiterbaren Auszeichnungssprache (XML DTD) zur Angabe verschiedener Authentifikationsverfahrensarten mittels eines erweiterbaren Authentifikationsprotokollelements (EAP); und eine Nachricht mit einem EAP-Element, das Informationen über eine zufallsgesteuert ausgewählte Authentifikationsverfahrensart der angegebenen Authentifikationsverfahrensarten enthält.
  • Das EAP Element beinhaltet im Wesentlichen ein <Code> Element, um eine Art einer Authentifikationsnachricht anzuzeigen, und ein <Identifier> Element, um die Authentifikationsnachricht zu identifizieren, und beinhaltet optional ein <EAPData> Element, welches eigentliche Daten einer Authentifikationsnachricht enthält.
  • Das <EAPData> Element enthält ein <DataKind> Element, um eine Art der Daten anzuzeigen, und ein Informationselement, welches Informationen über die zufallsbasiert ausgewählte Authentifikationsverfahrensart enthält.
  • Das Gesagte sowie andere Objekte, Merkmale, Aspekte und Vorzüge der vorliegenden Erfindung werden anhand der folgenden detaillierten Beschreibung der vorliegenden Erfindung in Verbindung mit den begleitenden Figuren ersichtlich werden.
  • Kurze Beschreibung der Zeichnungen
  • Die begleitenden Figuren, die beigefügt sind, um ein eingehenderes Verständnis der Erfindung zu vermitteln und welche in diese Spezifikation eingebunden sind und einen Teil davon bilden, veranschaulichen Ausführungen der Erfindung und dienen zusammen mit der Beschreibung dazu, die Prinzipien der Erfindung zu erklären.
  • Zu den Figuren:
  • 1 veranschaulicht ein allgemeines Authentifikationsverfahren zwischen einem Client und einem Server mittels Datensynchronisation eines eine Auszeichnungssprache verwendenden Kommunikationssystems;
  • 2 veranschaulicht eine XML DTD gemäß der vorliegenden Erfindung;
  • 3 veranschaulicht ein Bestätigungsverfahren für verfügbare Authentifikationsverfahren zwischen einem Client und einem Server gemäß der vorliegenden Erfindung;
  • 4 veranschaulicht ein Authentifikationsverfahren für Datensynchronisation zwischen dem Client und dem Server gemäß der vorliegenden Erfindung;
  • 5 veranschaulicht eine Authentifikationsnachricht (beispielsweise EAP-Anforderungs/Identitätsnachricht) zum Anfordern einer Identität durch Anwenden eines EAP gemäß der vorliegenden Erfindung;
  • 6 veranschaulicht eine Authentifikationsnachricht (beispielsweise EAP-Antwort/Identitätsnachricht) um mit einem eigentlichen Wert für die Identität mittels eines EAP gemäß der vorliegenden Erfindung zu antworten;
  • 7 veranschaulicht eine Authentifikationsnachricht (beispielsweise EAP-Anforderungs/Challengenachricht) zum Anfordern von einer zufallsbasiert ausgewählten Authentifikationsverfahrensart entsprechenden Sicherheitsinformationen durch Anwenden des EAP gemäß der vorliegenden Erfindung;
  • 8 veranschaulicht eine Authentifikationsnachricht (beispielsweise EAP-Antwort/Berechtigungsnachweisnachricht) um die der Authentifikationsverfahrensart entsprechenden Sicherheitsinformationen mittels des EAP gemäß der vorliegenden Erfindung zurückzusenden; und
  • 9 veranschaulicht eine Authentifikationsnachricht um ein Authentifikationsergebnis mittels des EAP gemäß der vorliegenden Erfindung zu übersenden.
  • Detaillierte Beschreibung der bevorzugten Ausführungen
  • Es wird nun ausführlich Bezug auf die bevorzugten Ausführungsformen der vorliegenden Erfindung genommen, von denen Beispiele in den begleitenden Figuren veranschaulicht sind.
  • Allgemein wird Datensynchronisation durch Übertragen/Empfangen einer auf einer erweiterbaren Auszeichnungssprache (XML) basierenden Nachricht zwischen einem Client und einem Server durchgeführt, und ein Protokoll für Datensynchronisation beinhaltet ein Repräsentationsprotokoll, ein Synchronisationsprotokoll und ein Transportprotokoll. Das Synchronisationsprotokoll definiert ein Verfahren und einen Ablauf, um eine SyncML Nachricht zwischen dem Client und dem Server auszutauschen, ein Verfahren zur Durchführung einer Synchronisation und eine Synchronisationsart. Das Transportprotokoll definiert verbindliche Regeln zur Benutzung allgemeiner Transportprotokolle wie einem Hypertext Transport Protocol (HTTP) und einem drahtlosen Sitzungsprotokoll (WST) zum Nachrichtentransport.
  • Das Repräsentationsprotokoll ist ein Strukturprotokoll für die SyncML Nachricht, welches eine Dokumententypdefinition einer erweiterbaren Auszeichnungssprache (XML DTD) für die Synchronisation definiert. Die XML DTD, die eine in dem XML Dokument verwendete Auszeichnungssprache angibt, definiert logische und physikalische Strukturen für das Dokument.
  • Allgemein müssen Sprachregeln, die zur Erstellung eines Dokuments verwendet werden, genau an jeden einzelnen Benutzer übermittelt werden, so dass die Benutzer den Inhalt des Dokuments erkennen können. XML verdeutlicht die Sprachregeln durch Verwendung der DTD. Das bedeutet, die DTD beschreibt im XML Dokument verwendete Elemente, Attribute der Elemente, Beziehungen zwischen den Elementen und Entitäten.
  • Gemäß der vorliegenden Erfindung sind schon vorher eine Anzahl Authentifikationsverfahrensarten in XML DTD definiert, und der Client und der Server wählen zufallsgesteuert einige Authentifikationsverfahrensarten aus den definierten Authentifikationsverfahrensarten aus. Der Client und der Server, die einen Zugriff ermöglichen müssen, vergleichen ihre Authentifikationsverfahrensarten und erkennen identische Authentifikationsverfahrensarten. In der bidirektionalen Authentifikation zur Datensynchronisation schlagen der Client und der Server einander dynamisch ihre Authentifikationsverfahrensarten unter den identischen Authentifikationsverfahrensarten vor, wodurch sie das Authentifikationsverfahren verschiedenartiger und sicherer durchführen.
  • Gemäß der vorliegenden Erfindung wird ein neues SyncML Schema für ein erweiterbares Authentifikationsverfahren zur zufallsgesteuerten Auswahl und Entscheidung über eine Authentifikationsverfahrensart zwischen dem Client und dem Server zusätzlich definiert, um eine XML DTD wie in 2 gezeigt auszubilden.
  • 2 veranschaulicht die XML DTD gemäß der vorliegenden Erfindung. Die XML DTD enthält ein Schema in Form eines im IETF RFC 2284 definierten erweiterbaren Authentifikationsprotokoll, um verschiedene Authentifikationsverfahrensarten zu erhalten.
  • Die XML DTD gibt die Struktur der SyncML Nachricht an. Gemäß der XML DTD enthält die Nachricht ein Kopfelement <SyncHdr> und ein Körperelement <SyncBody>, und das Kopfelement <SyncHdr> beinhaltet DTD Version <VerDTD>, Protokoll Version <VerProto>, Nachrichten ID <MsgID>, <Target>, <Source>, <RespURI>; <NoResp>, <Cred>, <Meta> und <EAP> Elemente. Herbei beziehen sich <Target>, <Source>, <RespURI>, <NoResp>, <Cred> und <Meta> Elemente selten auf die EAP der vorliegenden Erfindung, und daher sind ihre Erklärungen weggelassen. Das Körperelement beinhaltet eine Vielzahl von Kommandos zur Durchführung einer Synchronisationsprozedur, jedoch sind deren Erklärungen ebenfalls weggelassen.
  • Das <EAP> Element enthält im Wesentlichen ein <Code> Element und ein <Identifier> Element und enthält optional ein <EAPData> Element. Das <Code> Element zur Angabe einer Art der EAP Nachricht enthält Informationen über Anforderung, Antwort, Erfolg und Versagen. Das <Identifier> Element ist ein Bezeichner zum Kennzeichnen der EAP Nachricht. Das <EAPData> Element, welches eigentliche Daten der EAP Nachricht enthält, beinhaltet hauptsächlich Informationen der Authen tifikation. Das <EAPData> Element beinhaltet eines der Elemente <Identity>, <Notification>, <Nak>, <MD5Chal>, <OTP>, <TokenCard> und <TLS> sowie <DataKind> Element.
  • Das <Identity> Element gibt ein Authentifikationsverfahren an, welches eine Identität des Client oder Server verwendet, das <Notification> Element gibt Nachrichten an, die der anderen Seite gemeldet werden müssen, das <Nak> Element impliziert „Authentifikation ist notwendig, nicht antworten", und das <MD5Chal> Element wird verwendet um eine Challenge mittels eines MD5 Kompressionsalgorithmus anzufordern oder zu beantworten. Das <OTP> Element bezeichnet ein Authentifikationsverfahren, welches einen Einmal-Passwort (OTP) Algorithmus verwendet, das <TokenCard> Element bezeichnet ein Identifikationsverfahren, welches Information (Token) in Form einer physischen Eingabe, wie einer Smart-Card-Eingabe, Pupilleneingabe oder Fingerabdruckeingabe verwendet, und das <TLS> Element, welches ein von der IETF vorgeschlagener Standard ist, bezeichnet ein Authentifikationsverfahren zur Bereitstellung von Verschlüsselung und Zertifizierung durch eine Transportschicht (beispielsweise das Transmission Control Protocol (TCP)), so dass Daten über einen sicheren Kanal übermittelt werden können, ohne die Applikationsprogramme des Clients oder des Servers anzupassen. Das bedeutet, das <TLS> Element bezeichnet beispielsweise ein zertifikatsbasierendes Authentifikationsverfahren.
  • Gemäß der vorliegenden Erfindung gibt die XML DTD eine Vielzahl von Authentifikationsverfahrensarten wie das Identitäts/Passwort-basierende Authentifikationsverfahren, das MD5-basierende Authentifikationsverfahren, das OTP-basierende Authentifikationsverfahren, das TokenCard-basierende Authentifikationsverfahren und das zertifikatsbasierende Authentifikationsverfahren unter Verwendung von TLS (Transport Layer Security) an.
  • Weil die XML DTD die Vielzahl von Authentifikationsverfahrensarten angibt, können der das SyncML benutzende Client und der Server eine vorher festgelegt Anzahl Authentifikationsverfahrensarten unter den angegebenen Authentifikationsverfahrensarten optional beinhalten.
  • Der Client und der Server beinhalten jeweils einen Authentifikationsagenten. Der Authentifikationsagent führt die durch das Schema empfohlene SyncML basierte EAP Prozedur durch, um die Vielzahl von Authentifikationsverfahrensarten anzugeben.
  • Jeder der Clients und jeder der Server kann verschiedene Authentifikationsverfahrensarten haben. Deswegen melden die zueinander gehörenden Clients und Server einander ihre Authentifikationsverfahrensarten und erkennen identische verfügbare Authentifikationsverfahrensarten, bevor sie die Authentifikationsprozedur zur Datensynchronisation beginnen.
  • 3 veranschaulicht ein Bestätigungsverfahren für die verfügbaren Authentifikationsverfahren zwischen dem Client und dem Server gemäß der vorliegenden Erfindung.
  • In dem Fall, dass der Client und der Server Datensynchronisation anfordern, übermittelt der Client seine Authentifikationsverfahrensarten an den Server (S20). Der Client empfängt die Authentifikationsverfahrensarten des Servers vom Server (S22).
  • Der Client vergleicht seine Authentifikationsverfahrensarten mit den Authentifikationsverfahrensarten des Servers, und erkennt identische verfügbare Authentifikationsverfahrensarten (S24). Zusätzlich erkennt der Server die identischen verfügbaren Authentifikationsverfahrensarten zwischen seine Authentifikationsverfahrensarten und den Authentifikationsverfahrensarten des Clients.
  • Sind beispielsweise die Authentifikationsverfahrensarten des Clients Identity, MD5Chal, OTP und TLS, und die Authentifikationsverfahrensarten des Servers sind Identity, MD5Chal, OTP, TokenCard und TL, dann bestätigen der Client und der Server die identischen Authentifikationsverfahrensarten Identity, MD5Chal, OTP und TLS.
  • Nachdem sie die identischen verfügbaren Authentifikationsverfahrensarten bestätigt haben, führen der Client und der Server die Authentifikationsprozedur zur Datensynchronisation durch.
  • 4 veranschaulicht das Authentifikationsverfahren zur Datensynchronisation zwischen dem Client und dem Server im Kommunikationssystem mittels SyncML gemäß der vorliegenden Erfindung.
  • Wie in 4 veranschaulicht, fordert der Client eine Datensynchronisation vom Server an (S30), und der Server fordert eine Identität vom Client an (S32). Der Client übermittelt auf die Anforderung hin seine Identität an den Server (S34). Um zu bestätigen, dass der Client die Identität tatsächlich besitzt, wählt der Server zufallsge steuert eine der identischen verfügbaren Authentifikationsverfahrensarten zwischen dem Server und dem Client aus und fordert vom Client der Authentifikationsverfahrensart entsprechende Sicherheitsinformationen an (S36). Der Client übermittelt die Sicherheitsinformationen seiner Identität entsprechend der gewählten Authentifikationsverfahrensart an den Server (S38). Ist die Sicherheitsinformation des Clients normale Sicherheitsinformation, so entscheidet der Server, dass die Authentifikation entsprechend der zufallsgesteuert ausgewählten Authentifikationsverfahrensart erfolgreich durchgeführt wurde und übermittelt Erfolgsinformation an den Client (S40).
  • Der Server kann auch Authentifikation vom Client verlangen, die auf dieselbe Weise durchgeführt wird. Daher sind detaillierte Erklärungen davon weggelassen.
  • Das Authentifikationsverfahren des Clients durch den Server wird hier detailierter beschrieben.
  • Zuerst versucht der Client, auf den Server zuzugreifen, um eine Datensynchronisation anzufordern. Das bedeutet, dass der Client eine Datensynchronisationsanforderungsnachricht Request Sync generiert und die generierte Nachricht Request Sync mittels TCP/IP an den Server übermittelt (S30).
  • Um das EAP der Erfindung zu benutzen, generiert der Server wie in 5 gezeigt eine erste EAP Anforderungsnachricht EAP-Request-Identity um mittels eines <EAP> Elements und Subelementen davon eine Identität anzufordern. Die erste EAP Anforderungsnachricht EAP-Request/Identity beinhaltet ein <Code> Element um eine Anforderung anzuzeigen, ein <Identifier> Element um „1" anzuzeigen, und ein <EAP> Element als Subelemente des <EAP> Elements. Das <EAPData> Element beinhaltet ein <DataKind> Element um eine dem ausgewählten Authentifikationsverfahren entsprechende Identität anzuzeigen, und ein <Data> Element um Daten anzuzeigen, die der Client dem User anzeigen wird. Der Server übermittelt die erste EAP Anforderungsnachricht EAP-Request-Identity an den Client (S32).
  • Der Client untersucht die erste EAP Anforderungsnachricht EAP-Request-Identity. Erfasst der Client das <EAP> Element, so erkennt er, dass der Authentifikationsablauf mittels des EAP durchgeführt wird und erkennt auch, dass die erste EAP Anforderungsnachricht EAP-Request-Identity eine Authentifikationsnachricht ist, um eine Identität auf der Basis des <Code> Element und des <DataKind> Element des <EAP> Elements anzufordern, und stellt eine erste EAP Antwortnachricht EAP-Response-Identity wie in 6 gezeigt bereit. Das bedeutet, der Client registriert „Response" um eine Antwort im <Code> Element des <EAP> Elements der ersten EAP Antwortnachricht EAP-Response/Identity anzuzeigen, und „Identity" im <DataKind> Element des <EAPData> Elements. Ist die Identität des Clients „Hong", registriert der Client auch „Hong" im <Identity> Element. Der Client übermittelt die erste EAP Antwortnachricht EAP-Response/Identity an den Server (S34).
  • Der Server untersucht die erste EAP Antwortnachricht EAP-Response/Identity. Der Server erkennt, dass der Client der Identität „Hong" auf eine Authentifikation auf der Basis von <Code>Response</Code>, <DataKind>Identity</DataKind> und <Identity>Hong</Identity> des <EAP> Elements der ersten EAP Antwortnachricht EAP-Response/Identity erwartet. Dementsprechend wählt der Server zufallsgesteuert eine der verfügbaren Authentifikationsverfahrensarten aus und fordert Sicherheitsinformation der Identität vom Client gemäß der ausgewählten Authentifikationsverfahrensart an, um zu bestätigen, dass der Client tatsächlich die Identität von „Hong" besitzt, wodurch der eigentliche Authentifikationsprozess durchgeführt wird.
  • Das bedeutet, wenn die vom Server zufallsbasiert aus den verfügbaren Authentifikationsverfahrensarten ausgewählte Authentifikationsverfahrensart „MD5Chal" ist, wie in 7 gezeigt, so registriert der Server „Request" im <Code> Element des <EAP> Elements, „MD5Chal" im <DataKind> Element des <EAPData> Element, eine Zufallszahl, „90384029304802039480230" im <MD5Chal> Element, und „Wie lautet Ihr Passwort?" im <Data> Element, wodurch er eine zweite EAP Anforderungsnachricht EAP-Request/challenge erstellt. Ist die vom Server zufallsbasiert von den verfügbaren Authentifikationsverfahrensarten ausgewählte Authentifikationsverfahrensart „OTP", so fügt der Server <DataKind>OTP<DataKind> und <OTP>x<OTP> ein, wodurch er die zweite EAP Anforderungsnachricht EAP-Request/challenge erstellt. Der Server übermittelt die zweite EAP Anforderungsnachricht EAP-Request/challenge an den Client (S36).
  • Der die zweite EAP Anforderungsnachricht EAP-Request/challenge empfangende Client erkennt, dass der Client mit dem Passwort (Sicherheitsinformation) seiner Identität dem Server mit dem auf dem <MD5Chal> Element eingetragenen Zufallswert durch anwenden eines MD5 Kompressionsalgorithmus auf der Basis von <DataKind>MD5Chal<DataKind> und <MD5Chal>90384029304802039480230</MD5Chal> des <EAP> Element antworten muss.
  • Der Client berechnet einen Antwortwert, in dem er auf das Passwort (Sicherheitsinformation) seiner Identität und die in dem <MD5Chal> Element eingetragenen Zufallszahl Wert den MD5 Kompressionsalgorithmus anwendet, wie in Formel 1 ausgedrückt: MD5 (Zufallsgesteuerter Wert + Passwort + α) Formel 1
    • Hier bezeichnet α einen voreingestellten Wert zur Bezeichnung einer Identität, etwa eine Anwohnermeldenummer.
  • Das bedeutet, der Client komprimiert den Zufallswert, sein Passwort und α mit Hilfe des MD5 Kompressionsalgorithmus. Der Kompressionsergebniswert (Antwortwert) hat immer vorbestimmte Bits (beispielsweise 128 Bits), und ein Eingabewert wird nicht aus dem Ausgabewert bestimmt. Der MD5 ist eine nicht umkehrbare Funktion. Sollte daher der resultierende Kompressionswert (Antwortwert) entweichen, kann daraus das Passwort nicht gefolgert werden.
  • Werden <DataKind>OTP<DataKind> und <OTP>x<OTP> im <EAP> Element der zweiten EAP Anforderungsnachricht EAP-Request/challenge eingetragen, so bereitet der Client einen Antwortwert vor, in dem er das empfangene „x" und sein Passwort verwendet.
  • Der Client erstellt eine zweite EAP Antwortnachricht EAP-Response/Credentials mit dem Antwortwert der in 8 gezeigt ist und übermittelt die zweite EAP Antwortnachricht EAP-Response/Credentials an den Server (S38). In der zweiten EAP Antwortnachricht EAP-Response/Credentials in 8 bezeichnet der für das <MD5Chal> Element eingetragene Wert „slkdjflsldjfljsldjkfljlsdjkftuir" den Antwortwert.
  • Der die zweite EAP Antwortnachricht EAP-Response/Credentials empfangende Server sucht ein Passwort der entsprechenden Identität aus einer Benutzerregistrationsdatenbank heraus. Der Server komprimiert das herausgesuchte Passwort und den vom Server an den Client als Challenge übermittelten Zufallswert auf die gleiche Weise wie in der oben angegebenen Formel 1. Der Server vergleicht den durch die Kompression berechneten Wert mit dem Antwortwert des Clients. Ist der Wert identisch mit dem Antwortwert, so entscheidet der Server, dass die Authentifikation entsprechend der zufallsgesteuert ausgesuchten Authentifikationsverfahrensart erfolgreich durchgeführt worden ist, und wenn der berechnete Wert unterschiedlich zum Antwortwert ist, entscheidet der Server, dass die Authentifikation versagt hat.
  • Wie in 9 veranschaulicht, erstellt der Server eine Authentifikationsergebnisnachricht, indem er ein Authentifikationsergebnis im <Code> Element des <EAP> Element einträgt, und übermittelt die Authentifikationsergebnisnachricht an den Client (S40).
  • Der die Authentifikationsergebnisnachricht aus 9 empfangende Client erkennt auf Basis des <Code>Success</Code>, dass die Authentifikation erfolgreich durchgeführt wurde. Die Authentifikationsergebnisnachricht braucht kein <EAPData> Element.
  • Wie oben beschrieben, sind gemäß der vorliegenden Erfindung eine Vielfalt von Authentifikationsverfahrensarten in der XML DTD definiert, so dass die Authentifikationsverfahrensarten unbehindert zwischen dem Client und dem Server mittels der Auszeichnungssprache ausgewählt werden können.
  • Weiterhin können die Authentifikationsverfahrensarten dynamisch zwischen dem Client und dem Server ausgewählt werden, was in einer starken bidirektionalen Authentifikation resultiert.
  • Da die vorliegende Erfindung in verschiedenen Formen ausgeführt werden kann, ohne von ihrer grundlegenden Ausprägung abzurücken, sollte auch klar sein, dass die oben beschriebenen Ausgestaltungen, soweit nicht anders angegeben, durch kein Detail der vorangegangenen Beschreibung beschränkt werden, sondern stattdessen breit im Rahmen des durch die beigefügten Ansprüche definierten Umfangs zu verstehen sind, weswegen alle Änderungen und Abwandlungen, die in den Rahmen und die Schranken der Ansprüche fallen, oder Äquivalente dieses Rahmens und dieser Schranken von den beigefügten Ansprüchen erfasst sein sollen.

Claims (15)

  1. Authentifikationsverfahren zwischen einem Client und einem Server in einem drahtgebundenen/drahtlosen Kommunikationssystem, gekennzeichnet durch die Schritte der Bereitstellung einer eine Mehrzahl von Authentifikationsverfahrensarten spezifizierenden Dokumententypdefinition für eine Auszeichnungssprache, des Auswählens einer der in der Dokumententypdefinition spezifizierten Authentifikationsverfahrensarten sowie der Übermittlung (S32, S36) einer die ausgewählte Authentifikationsverfahrensart angebenden Authentifikationsnachricht in der Auszeichnungssprache zwischen dem Client und dem Server.
  2. Verfahren nach Anspruch 1, wobei die in der Dokumententypdefinition spezifizierten Authentifikationsverfahrensarten ein Authentifikationsverfahren auf Identitätsbasis, ein Authentifikationsverfahren auf Basis des Message Digest Algorithm 5, ein Authentifikationsverfahren auf Basis eines Einmalpassworts, ein Authentifikationsverfahren auf Basis einer TokenCard sowie ein Authentifikationsverfahren auf Zertifikatbasis mit Transport-Schicht-Sicherheit umfassen.
  3. Verfahren nach Anspruch 1, wobei der Client und der Server vor dem Start einer Authentifikationsprozedur gleiche verfügbare Authentifikationsverfahrensarten erkennen (S20, S22, S24).
  4. Verfahren nach Anspruch 1, wobei der Server eine der in der Dokumententypdefinition seitens des Servers nach Empfang einer Zugangsanforderung (S30) von dem Client spezifizierten Authentifikationsverfahrensarten auswählt und nach Maßgabe der ausgewählten Authentifikationsverfahrensart Sicherheitsinformationen von dem Client anfordert (S32, S36).
  5. Verfahren nach Anspruch 4, wobei der Server an den Client eine Anforderungsnachricht übermittelt (S32, S36), welche die ausgewählte Authentifikationsverfahrensart angibt und eine Anforderung von Sicherheitsinformationen nach der ausgewählten Authentifikationsverfahrensart enthält.
  6. Verfahren nach Anspruch 5, bei dem der Client nach Empfang der Anforderungsnachricht die ausgewählte Authentifikationsverfahrensart sowie die Anforderung von Sicherheitsinformationen aus der Anforderungsnachricht ermittelt und als Antwort Sicherheitsinformationen nach der ausgewählten Authentifikationsverfahrensart an den Server übermittelt (S34, S38).
  7. Verfahren nach Anspruch 6, wobei der Client die ausgewählte Authentifikationsverfahrensart anhand eines Authentifikationsverfahrensart-Hinweiselements (<DataKind>) eines Authentifikationsinformationen enthaltenden Elements (<EAPData>) eines authentifikationsbezogenen Elements (<EAP>) der Anforderungsnachricht ermittelt.
  8. Verfahren nach Anspruch 6, wobei die Anforderungsnachricht ferner einen Zufallswert enthält.
  9. Verfahren nach Anspruch 8, wobei eine Antwort nach der ausgewählten Authentifikationsverfahrensart einen durch Verarbeiten des Zufallwerts, der Sicherheitsinformationen und eines gegebenen Werts nach der ermittelten Authentifikationsverfahrensart erhaltenen Ergebniswert umfasst, wobei der Zufallswert aus der Anforderungsnachricht ermittelt wird.
  10. Verfahren nach Anspruch 9, wobei der gegebene Wert einen weiteren Wert zur Identifizierung des Client umfasst.
  11. Verfahren nach Anspruch 9, wobei der Server die Sicherheitsinformationen, welche er von dem Client angefordert hat, aus einer Datenbank entnimmt, die entnommenen Sicherheitsinformationen nach der ausgewählten Authentifikationsverfahrensart verarbeitet, um einen Ergebniswert zu erhalten, und den Ergebniswert mit der Antwort des Client vergleicht, um Erfolg oder Versagen der Authentifikation zu bestimmen.
  12. Datenstruktur für eine Auszeichnungssprache, umfassend eine Dokumententypdefinition für eine erweiterbare Auszeichnungssprache zum Zugang durch einen Client oder einen Server im Rahmen eines Authentifikationsverfahrens nach einem der Ansprüche 1 bis 11, gekennzeichnet durch ein eine Mehrzahl von Authentifikationsverfahrensarten spezifizierendes erweiterbares Authentifikationsprotokollelement EAP.
  13. Verfahren nach Anspruch 1, wobei der Client und der Server in dem eine Auszeichnungssprache nutzenden drahtgebundenen/drahtlosen Kommunikationssystem nutzbare Authentifikationsverfahrensarten zwischen dem Client und dem Server erkennen, wobei der Server den Client mit Hilfe einer ersten zufälligen Authentifikationsverfahrensart aus den nutzbaren Authentifikationsverfahrensarten authentifiziert und wobei der Client den Server mit Hilfe einer zweiten zufälligen Authentifikationsverfahrensart aus den nutzbaren Authentifikationsverfahrensarten authentifiziert.
  14. Verfahren nach Anspruch 13, wobei die erste und die zweite zufällige Authentifikationsverfahrensart unterschiedlich sind.
  15. Verfahren nach Anspruch 13, wobei die erste und die zweite zufällige Authentifikationsverfahrensart identisch sind.
DE602004001717T 2003-06-14 2004-06-09 Authentisierungsmethode in einem Draht/drahtlos-Kommunikationssystem mit Auszeichnungssprache Active DE602004001717T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR2003038545 2003-06-14
KR1020030038545A KR100548354B1 (ko) 2003-06-14 2003-06-14 동기화 프로토콜에서의 사용자 인증 방법

Publications (2)

Publication Number Publication Date
DE602004001717D1 DE602004001717D1 (de) 2006-09-14
DE602004001717T2 true DE602004001717T2 (de) 2006-12-07

Family

ID=36782494

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004001717T Active DE602004001717T2 (de) 2003-06-14 2004-06-09 Authentisierungsmethode in einem Draht/drahtlos-Kommunikationssystem mit Auszeichnungssprache

Country Status (7)

Country Link
US (1) US20050021957A1 (de)
EP (1) EP1487170B1 (de)
JP (1) JP2005004769A (de)
KR (1) KR100548354B1 (de)
CN (1) CN1574741A (de)
AT (1) ATE335346T1 (de)
DE (1) DE602004001717T2 (de)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9614772B1 (en) 2003-10-20 2017-04-04 F5 Networks, Inc. System and method for directing network traffic in tunneling applications
KR100644616B1 (ko) * 2004-06-10 2006-11-10 세종대학교산학협력단 마크업 랭귀지 기반의 단일인증 방법 및 이를 위한 시스템
US20060174103A1 (en) * 2004-09-16 2006-08-03 Nokia Corporation System and method for integrating PKI and XML-based security mechanisms in SyncML
US8423788B2 (en) 2005-02-07 2013-04-16 Sandisk Technologies Inc. Secure memory card with life cycle phases
US8321686B2 (en) 2005-02-07 2012-11-27 Sandisk Technologies Inc. Secure memory card with life cycle phases
US8108691B2 (en) 2005-02-07 2012-01-31 Sandisk Technologies Inc. Methods used in a secure memory card with life cycle phases
US20060218393A1 (en) * 2005-03-23 2006-09-28 Hernandez Hendrich M Systems and methods for adaptive authentication
BRPI0611696B1 (pt) * 2005-06-13 2019-05-07 Nokia Technologies Oy Método, dispositivo e sistema para fornecer identidades de nós móveis em conjunto com preferências de autenticação em uma arquitetura de inicialização genérica
US8353011B2 (en) 2005-06-13 2013-01-08 Nokia Corporation Apparatus, method and computer program product providing mobile node identities in conjunction with authentication preferences in generic bootstrapping architecture (GBA)
US8087069B2 (en) 2005-06-13 2011-12-27 Nokia Corporation Method, apparatus and computer program product providing bootstrapping mechanism selection in generic bootstrapping architecture (GBA)
US8286223B2 (en) 2005-07-08 2012-10-09 Microsoft Corporation Extensible access control architecture
US7748031B2 (en) 2005-07-08 2010-06-29 Sandisk Corporation Mass storage device with automated credentials loading
US8418233B1 (en) * 2005-07-29 2013-04-09 F5 Networks, Inc. Rule based extensible authentication
US8533308B1 (en) 2005-08-12 2013-09-10 F5 Networks, Inc. Network traffic management through protocol-configurable transaction processing
US7934049B2 (en) 2005-09-14 2011-04-26 Sandisk Corporation Methods used in a secure yet flexible system architecture for secure devices with flash mass storage memory
US8966284B2 (en) 2005-09-14 2015-02-24 Sandisk Technologies Inc. Hardware driver integrity check of memory card controller firmware
CN100459522C (zh) * 2006-03-08 2009-02-04 华为技术有限公司 利用同步标记语言进行终端管理的方法
US8423794B2 (en) 2006-12-28 2013-04-16 Sandisk Technologies Inc. Method and apparatus for upgrading a memory card that has security mechanisms for preventing copying of secure content and applications
CN101431413B (zh) * 2007-11-08 2012-04-25 华为技术有限公司 进行认证的方法、系统、服务器及终端
KR100925636B1 (ko) * 2007-12-04 2009-11-06 주식회사 케이티 응용 서비스 제공을 위한 비-피씨형 단말과 서버 간의 통신방법
US9832069B1 (en) 2008-05-30 2017-11-28 F5 Networks, Inc. Persistence based on server response in an IP multimedia subsystem (IMS)
US9130846B1 (en) 2008-08-27 2015-09-08 F5 Networks, Inc. Exposed control components for customizable load balancing and persistence
CN102208978A (zh) * 2010-03-30 2011-10-05 腾讯科技（深圳）有限公司 验证输入的系统及方法
US8769299B1 (en) 2010-10-13 2014-07-01 The Boeing Company License utilization management system license wrapper
US9563751B1 (en) 2010-10-13 2017-02-07 The Boeing Company License utilization management system service suite
EP2782035B1 (de) 2013-03-19 2021-06-09 Nxp B.V. Chipkarte, Chipkartensystem und Verfahren zur Konfiguration einer Chipkarte
JP6465542B2 (ja) * 2013-09-02 2019-02-06 キヤノン株式会社 情報処理装置、その制御方法及びプログラム
EP3029925A1 (de) 2014-12-01 2016-06-08 Thomson Licensing Verfahren und Vorrichtung zur Schätzung einer Farbzuordnung zwischen zwei Versionen mit unterschiedlicher Farbgradierung eines Bildes
KR101720630B1 (ko) 2015-08-31 2017-03-28 고려대학교 산학협력단 내부 공격에 안전한 id 기반의 양방향 인증 방법
CN107483456A (zh) * 2017-08-25 2017-12-15 北京元心科技有限公司 身份认证方法及装置
CN108234109B (zh) * 2017-12-22 2020-12-11 中国电子科技集团公司第三十研究所 一种在eap-md5协议嵌入生物特征的准入控制方法
WO2019194155A1 (en) * 2018-04-06 2019-10-10 Nec Corporation An authentication method for next generation systems

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5341426A (en) * 1992-12-15 1994-08-23 Motorola, Inc. Cryptographic key management apparatus and method
US5784566A (en) * 1996-01-11 1998-07-21 Oracle Corporation System and method for negotiating security services and algorithms for communication across a computer network
US6021202A (en) * 1996-12-20 2000-02-01 Financial Services Technology Consortium Method and system for processing electronic documents
US6182215B1 (en) * 1997-02-28 2001-01-30 Matsushita Electric Industrial Co., Ltd. Information devices which select and use one out of plurality of encryption utilization protocols for protecting copyrights of digital productions
US6671810B1 (en) * 1997-09-18 2003-12-30 Intel Corporation Method and system for establishing secure communication over computer networks
US6931532B1 (en) * 1999-10-21 2005-08-16 International Business Machines Corporation Selective data encryption using style sheet processing
GB2357229B (en) * 1999-12-08 2004-03-17 Hewlett Packard Co Security protocol
US6834341B1 (en) * 2000-02-22 2004-12-21 Microsoft Corporation Authentication methods and systems for accessing networks, authentication methods and systems for accessing the internet
EP1211588B1 (de) * 2000-12-04 2005-09-21 Siemens Aktiengesellschaft Verfahren zum Nutzen einer Datenverarbeitungsanlage abhängig von einer Berechtigung, zugehörige Datenverarbeitungsanlage und zugehöriges Programm
US7003662B2 (en) * 2001-05-24 2006-02-21 International Business Machines Corporation System and method for dynamically determining CRL locations and access methods
US20040107360A1 (en) * 2002-12-02 2004-06-03 Zone Labs, Inc. System and Methodology for Policy Enforcement
JP3983035B2 (ja) * 2001-11-19 2007-09-26 富士通株式会社 ユーザ端末認証プログラム
US20030233580A1 (en) * 2002-05-29 2003-12-18 Keeler James D. Authorization and authentication of user access to a distributed network communication system with roaming features
US7565537B2 (en) * 2002-06-10 2009-07-21 Microsoft Corporation Secure key exchange with mutual authentication
US7313687B2 (en) * 2003-01-10 2007-12-25 Microsoft Corporation Establishing a secure context at an electronic communications end-point

Also Published As

Publication number Publication date
EP1487170A3 (de) 2005-03-30
KR100548354B1 (ko) 2006-02-02
KR20040107888A (ko) 2004-12-23
EP1487170B1 (de) 2006-08-02
CN1574741A (zh) 2005-02-02
DE602004001717D1 (de) 2006-09-14
US20050021957A1 (en) 2005-01-27
JP2005004769A (ja) 2005-01-06
EP1487170A2 (de) 2004-12-15
ATE335346T1 (de) 2006-08-15

Similar Documents

Publication Publication Date Title
DE602004001717T2 (de) Authentisierungsmethode in einem Draht/drahtlos-Kommunikationssystem mit Auszeichnungssprache
DE60027971T2 (de) Einmalige Anmeldung in einem Netzwerksystem, das mehrere gesondert steuerbare Ressourcen mit begrenztem Zugang enthält
DE60308692T2 (de) Verfahren und system für benutzerbestimmte authentifizierung und einmalige anmeldung in einer föderalisierten umgebung
DE60314871T2 (de) Verfahren zur authentifizierung eines anwenders bei einem zugang zu einem dienst eines diensteanbieters
DE60206634T2 (de) Verfahren und System zur Authentifizierung von Benutzern in einem Telekommunikationssystem
DE60307482T2 (de) Authentifizierung zwischen einem zellularen Mobilendgerät und einem kurzreichweitigen Zugangspunkt
DE69830726T2 (de) Verfahren zum betrieb eines systems von authentifizierungsservern sowie ein solches system
DE60114986T2 (de) Verfahren zur herausgabe einer elektronischen identität
DE60220780T2 (de) Fernauthentifizierung von fingerabdrücken über ein unsicheres netzwerk
DE60208614T2 (de) Verfahren und Vorrichtung zur Bereitstellung einer Liste von öffentlichen Schlüsseln in einem Public-Key-System
DE19722424C1 (de) Verfahren zum Sichern eines Zugreifens auf ein fernab gelegenes System
DE60124425T2 (de) Verfahren zum einleiten von vertraulichkeit
DE10392208T5 (de) Mechanismus zum Unterstützten drahtgebundener und drahtloser Verfahren für eine client- und serverseitige Authentifizierung
WO2011006895A1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3125492A1 (de) Verfahren und system zum erzeugen eines sicheren kommunikationskanals für endgeräte
DE10212620A1 (de) Sichere Benutzer- und Datenauthentisierung über ein Kommunikationsnetzwerk
DE10124111A1 (de) System und Verfahren für verteilte Gruppenverwaltung
EP2966605A1 (de) Verfahren und System zur Authentifizierung eines Benutzers
WO2010112368A2 (de) Verfahren zum lesen von attributen aus einem id-token über eine mobilfunkverbindung
EP0995288B1 (de) Verfahren und vorrichtung zur gegenseitigen authentisierung von komponenten in einem netz mit dem challenge-response-verfahren
WO2009140953A1 (de) Verfahren, authentikationsserver und diensteserver zum authentifizieren eines client
DE102018202176A1 (de) Master-Slave-System zur Kommunikation über eine Bluetooth-Low-Energy-Verbindung
DE602004012103T2 (de) Verfahren zum verteilen von passwörtern
EP3432539B1 (de) Verfahren zum aufbau eines kommunikationskanals zwischen einer servereinrichtung und einer clienteinrichtung
EP1468520B1 (de) Verfahren zur datenverkehrssicherung in einer mobilen netzumgebung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition