DE60024319T2 - Vereinter einloggungsprozess - Google Patents

Vereinter einloggungsprozess Download PDF

Info

Publication number
DE60024319T2
DE60024319T2 DE2000624319 DE60024319T DE60024319T2 DE 60024319 T2 DE60024319 T2 DE 60024319T2 DE 2000624319 DE2000624319 DE 2000624319 DE 60024319 T DE60024319 T DE 60024319T DE 60024319 T2 DE60024319 T2 DE 60024319T2
Authority
DE
Germany
Prior art keywords
secret
authenticator
user
authentication
mobile device
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.)
Expired - Lifetime
Application number
DE2000624319
Other languages
English (en)
Other versions
DE60024319D1 (de
Inventor
Azim Ferchichi
Eric Lauper
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.)
Swisscom AG
Original Assignee
Swisscom Mobile AG
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 Swisscom Mobile AG filed Critical Swisscom Mobile AG
Application granted granted Critical
Publication of DE60024319D1 publication Critical patent/DE60024319D1/de
Publication of DE60024319T2 publication Critical patent/DE60024319T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • 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
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • 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/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/082—Access security using revocation of authorisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H04W8/265—Network addressing or numbering for mobility support for initial activation of new user
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)
  • Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)
  • Information Transfer Between Computers (AREA)
  • Analysing Materials By The Use Of Radiation (AREA)
  • Saccharide Compounds (AREA)
  • Crystals, And After-Treatments Of Crystals (AREA)

Description

  • Die Erfindung bezieht sich auf ein vereintes Einloggungsverfahren und auf eine Chipkarte, die für das benannte vereinte Einloggungsverfahren verwendet wird.
  • 1 – Stand der Technik
  • Wenn Benutzer einen Fernzugriff auf ein Firmennetzwerk oder ein privates LAN tätigen, müssen verschiedene Schichten aufgebaut werden. Allgemein gesprochen, benötigt jede Schicht eine Authentifizierung. Für jede Authentifizierung müssen die Benutzer unter Umständen Geheimnisse, zum Beispiel einen PIN, ein Passwort, ein Passphrase oder biometrische Daten eingeben. Dies führt zu zwei Problemen. An je mehr Geheimnisse die Benutzer erinnern müssen, desto mehr besteht die Tendenz, einfache Geheimnisse auszuwählen und desto mehr tendieren die Benutzer dazu, diese aufzuschreiben. Zusätzlich tendieren die Benutzer dazu, diese zu vergessen, was die Managementkosten erhöht.
  • Es ist ein Ziel der Erfindung, nur ein Geheimnis zu verwenden, das für alle Authentifizierungen dient.
  • Vereinte Einloggungsprozesse wurden bereits vorgeschlagen für Benutzer, die sich an verschiedenen Maschinen einloggen wollen, wobei jede Maschine ihr eigenes Betriebssystem und ihren eigenen Typ der Authentifizierung hat. Dieser Typ von bekannten vereinten Einloggungsprozessen funktioniert nur dann, wenn alle notwendigen Kommunikationsschichten bereits aufgebaut wurden. Es wird allgemein angenommen, dass es Maschinen in einem Firmennetzwerk sind, die mit TCP/IP als grundlegende Kommunikationsschichten funktionieren.
  • Ein anderes Ziel der Erfindung ist es, einen vereinten Einloggungsprozess mit einer Authentifizierung zu schaffen, welcher nicht an ein Maschinenlogin gebunden ist, sondern an die Konstruktion von Schichten. Das bedeutet, dass jedes Mal, wenn eine neue Schicht aufgebaut werden muss, eine neue Authentifizierung des Benutzers oder seiner/ihrer Maschine erforderlich sein kann.
  • Ein anderes Ziel der Erfindung ist es, einen vereinten Einloggungsprozess zu schaffen, der verwendet werden kann, um eine Kommunikation über verschiedene Kommunikationsschichten von verschiedenen Netzwerkprotokollen aufzubauen.
  • Bekannte vereinte Einloggungssysteme basieren auf zentralen Servern, auf welchen die Benutzer ihr erstes Log-on machen. Diese Herangehensweise ist nicht anwendbar, wenn der Benutzer keine erforderlichen Kommunikationsschichten hat, um den zentralen Authentifizierungsserver zu kontaktieren. Ein anderes Problem besteht darin, dass wir nicht notwendigerweise für jede benötigte Authentifizierung mit derselben Firma verhandeln, und ein zentraler Server für alle zu politischen und Vertrauensproblemen führen kann.
  • WO 98 32301 beschreibt zum Beispiel ein solches Verfahren und eine entsprechende Vorrichtung, um einem kabellosen Host eines öffentlichen Mobilfunknetzes (PLMN) den Zugriff zu einem privaten Datenkommunikationsnetzwerk zuzulassen, wobei das Authentifizierungsverfahren des kabellosen Hosts, der Zugang zu einem privaten Datenkommunikationsnetzwerk fordert, in der Infrastruktur des öffentlichen Mobilfunknetzes durchführt wird. Wenn der kabellose Host als ein autorisierter Host identifiziert ist, wird automatisch ein „Wireless Host Identifier" (WHI), welcher an verschiedenen Stellen gespeichert werden kann, von dem öffentlichen Mobilfunknetz zu dem privaten Netzwerk gesendet, welcher dann Zugriff zu diesem kabellosen Host gewährt. Die Entscheidung Zugriff auf das private Netzwerk zu gewähren wird dann auf der Basis eines Identifizierungsmerkmals durchgeführt, welches von dem PLMN geliefert wird, nachdem das Authentifizierungsverfahren von demselben MPLN durchgeführt wurde. Das Verfahren erfordert daher eine starke Vertrauensvereinbarung zwischen dem Betreiber des privaten Netzwerkes und dem Betreiber des MPLN, weil das einzige Authentifizierungsverfahren vom Letzteren durchgeführt wird. Wenn eine solche Vereinbarung nicht existiert, kann eine zusätzliche Authentifizierung des kabellosen Hosts von dem Betreiber des privaten Netzwerkes verlangt werden, welche dann wiederum bedeuten würde, dass der Benutzer die Identifizierungsmerkmale oder Geheimnisse von Hand eingeben müsste, wenn der dazu aufgefordert wird.
  • Ein weiterer Nachteil des Verfahrens, welches in WO 98 32301 beschrieben ist, ist, dass der Betreiber des MPLN den WHI hat und damit alle Authentifizierungsinformationen weiss, um auf das private Netz zuzugreifen. Er kann damit auf alle Daten in dem privaten Netzwerk zugreifen, auf welche normalerweise nur von einem registrierten Benutzer zugegriffen werden kann. Der Fachmann wird einfach verstehen, dass ein solches geringes Niveau von Sicherheit für die meisten privaten Netzwerkbetreiber, besonders für Banken, etc. nicht akzeptabel ist.
  • Es ist ein weiteres Ziel der Erfindung, einen vereinten Einloggungsprozess zu schaffen, welcher ein höheres Sicherheitsniveau als die aus dem Stand der Technik bekannten vereinten Einloggungsprozesse schafft.
  • 2 – Darstellung der Erfindung
  • Gemäss einem Ausführungsbeispiel der vorliegenden Erfindung, werden diese Probleme gelöst mit einem Verfahren, welches die Verfahrensschritte aufweist, die in Anspruch 1 beansprucht werden.
  • Spezieller werden die Probleme gelöst durch ein Verfahren zum einzigen Einloggen, um einen mobilen Benutzer einen Fernzugang zu einem Fernort in einem Firmennetzwerk durch ein öffentliches Mobilfunknetz und durch das Internet mit einem mobilen Gerät zu erlauben, wobei eine Chipkarte benutzt wird, wobei das Verfahren die folgenden Schritte umfasst:
    • (a) Senden eines ersten Authentikators zu dem besagten öffentlichen Mobilenfunknetz,
    • (b) Verifizierung in dem besagten öffentlichen Mobilfunknetz des besagten ersten Authentikators, der von dem mobilen Gerät gesendet wird,
    • (c) wenn der besagte erste Authentikator von dem gesagten öffentlichen Mobilfunknetz akzeptiert wird, wird die Kommunikationsschicht zwischen dem besagten mobilen Gerät und dem besagten öffentlichen Mobilfunknetz vervollständigt,
    • (d) Senden eines zweiten Authentikators über besagtes öffentliches Mobilfunknetz zu einem Internet Service Provider,
    • (e) Verifizierung des besagten zweiten Authentikators, welcher von dem besagten mobilen Gerät gesendet wurde, in dem besagten Internet Service Provider,
    • (f) wenn der besagte zweite Authentikator von dem besagten Internet Service Provider akzeptiert wird, wird die Kommunikationsschicht zwischen dem besagten mobilen Gerät und dem Internet vervollständigt,
    • (g) Senden eines Dritten Authentikators über das öffentliche Mobilfunknetz und das Internet zu besagten Firmennetzwerk,
    • (h) Verifizierung des besagten dritten Authentikators, welcher von dem besagten mobilen Gerät gesendet wurde, in besagten Firmennetzwerk,
    • (i) wenn der besagte dritte Authentikator von dem besagten Netzwerk akzeptiert wird, wird die Kommunikationsschicht zwischen dem besagten mobilen Gerät und dem besagten Fernort vervollständigt,
    dadurch gekennzeichnet, dass besagte erste, zweite und dritte Authentikatoren von der Chipkarte zu einem Single Sign-On Software-Modul auf der Seite des Benutzers geliefert werden, welches sie dann zu dem öffentlichen Mobilfunknetz, zu dem Internet Service Provider oder zu besagtem Firmennetzwerkes sendet.
  • Gemäss der vorliegenden Erfindung wird jeder Schritt des vereinten Einloggungsprozesses auf der Klientenseite ausgeführt, vorzugsweise in einer Chipkarte.
  • Dieser Prozess ist vorteilhaft dadurch, dass er keine bereits bestehenden Authentifizierungsmechanismen, die eingerichtet sind, schwächt. Zusätzlich verbessert der Gebrauch einer Chipkarte die Gesamtsicherheit. Es wird kein zentraler vereinten Einloggungsserver benötigt.
  • Ein mobiles Gerät, welches Chipkarten für sicheren Datentransfer zwischen einem mobilen Computer und einem Kommunikationsnetzwerk verwendet, ist beispielsweise in US 5778071 beschrieben. Das mobile Gerät, welches in dem Dokument beschrieben wird, und die Information, welche in der Chipkarte enthalten ist, wird jedoch verwendet, um Daten, die gesendet werden, zu verschlüsseln und um empfangene Daten zu authentifizieren. Es wird nicht für einen vereinten Einloggungsprozess verwendet. Mit anderen Worten hilft die Vorrichtung, die in US 5778071 beschrieben wird, nicht, um aufeinander folgende Kommunikationsschichten zwischen einem mobilen Computer und einem mobilen Netzwerk zu vervollständigen.
  • Gemäss einem anderen Aspekt der Erfindung, wird von dem Benutzer ein und nur einziges Passwort (oder PIN oder biometrische Daten oder irgendein anderes Geheimnis) durch den Benutzer, zum Beispiel einen mobilen Benutzer eingegeben, um mit einem Fernzugang auf ein Firmennetzwerk zuzugreifen, unbeachtet der Nummer von Authentifizierungen, welche durchgeführt werden müssen und ungeachtet der Nummer von Kommunikationsschichten, die aufgebaut werden müssen.
  • Das erfindungsgemässe Verfahren erlaubt eine transparente Schichtkonstruktion und eine transparente Benutzer- oder Maschinenauthentifizierung von jeder Schicht. Schichten können im Fall eines unabsichtlichen Kommunikationsunterbruches transparent rekonstruiert werden.
  • Kurze Beschreibung der Figuren
  • 1 zeigt das allgemeine Konzept des erfindungsgemässen Verfahrens.
  • 2 illustriert die Definition eines Authentificators in einem Authentifizierungsschema.
  • 3 illustriert einen Hash-Authentifizierungsmechanismus.
  • 4 illustriert einen kryptographischen Authentifizierungsmechanismus ohne Schlüsselschutz.
  • 5 illustriert einen symmetrischen kryptographischen Authentifizierungsmechanismus mit schwachem Schlüsselschutz.
  • 6 illustriert einen symmetrischen kryptographischen Authentifizierungsmechanismus mit starkem Schlüsselschutz.
  • 7 illustriert einen asymmetrischen kryptographischen Authentifizierungsmechanismus mit starkem Schlüsselschutz.
  • 8 illustriert ein Authentifizierungsverfahren für einen permanenten Authentifizierungsmechanismus mit einem Geheimnis.
  • 9 illustriert ein Authentifizierungsverfahren für einen Authentifizierungsmechanismus mit einem Hash-Passwort.
  • 10 illustriert ein Authentifizierungsverfahren für einen symmetrischen Authentifizierungsmechanismus ohne Schlüsselschutz oder mit schwachem Schlüsselschutz.
  • 11 illustriert ein Authentifizierungsverfahren für einen symmetrischen Authentifizierungsmechanismus mit starkem Schlüsselschutz.
  • 12 illustriert ein Authentifizierungsverfahren für einen asymmetrischen Authentifizierungsmechanismus.
  • 13 illustriert die Interaktion zwischen den verwendeten Komponenten, die für einen vereinten Einloggungsprozess verwendet werden.
  • 14 zeigt den Datenfluss, welcher die Verfahrenschritte, die ausgeführt werden, um den Aufbau der Schichten in einem Ausführungsbeispiel des erfindungsgemässen Verfahrens auszuführen.
  • 15 illustriert ein System, welches ein GSM Netzwerk, ein PPP Teil, ein IPSEC Teil und ein NT Teil enthält, in welchem das erfindungsgemässe Verfahren verwendet werden kann.
  • 16 zeigt, wie die Schichten in dem System der 15 konstruiert werden.
  • 16a illustriert die Schichtkonstruktion gemäss dem erfindungsgemässen Verfahren.
  • 17 illustriert den GSM Authentifizierungsmechanismus.
  • 18 illustriert den Authentifizierungsmechanismus für einen PAP Zweiwege-Handschlag.
  • 19 illustriert den Authentifizierungsmechanismus für PAP, welcher eine Chipkarte integriert.
  • 20 illustriert den Authentifizierungsmechanismus für CHAP, welcher eine Chipkarte integriert.
  • 21 illustriert den Authentifizierungsmechanismus für EAP, welcher OTP mit integrierter Chipkarte verwendet.
  • 22 illustriert den Meldungsaustausch während IKE (Internet Key Exchange) Hauptmode.
  • 23 illustriert den Meldungsaustausch während IPSEC Schnellmode.
  • 24 illustriert den Authentifizierungsmechanismus für NT.
  • 25 illustriert die Verfahrensschritte eines geheimen Synchronisationsverfahrens, welche ausgeführt werden, wenn ein Austausch von Geheimnissen von dem Betriebssystem verlangt wurde.
  • 26 illustriert die Verfahrensschritte eines geheimen Synchronisationsverfahrens, welche ausgeführt werden, wenn ein Austausch von Geheimnissen von dem Benutzer verlangt wurde.
  • 1 zeigt ein Schema, welches das allgemeine Konzept der Erfindung illustriert. Die Referenznummer 13 zeigt ein Modul zum einzigen Einloggen, welches Hardware- und Softwareteile enthalten kann. Das Modul zum einzigen Einloggen kann als Softwaremodul realisiert werden, welches auf einem Mikroprozessor in einem mobilen Gerät eines Benutzers 10 betrieben wird. Es enthält ein Chipkarteninterface, um es über ein API-Interface mit einer Chipkarte 17 zu verbinden. Referenzzeichen 22, 23, ..., 2i, ... 27 zeigen übereinander gelegte Schichten von einem Telekommunikationsprotokollstapel.
  • Alle Verfahrensschritte sind durch das Modul zum einzigen Einloggen 13 initiiert. Wenn der Benutzer einen Fernzugriff auf sein Firmennetzwerk beantragt, startet das Modul zum einzigen Einloggen 13 das Benutzerinterface (Pfeil 11), um dem Benutzer nach seinem Loginnamen und seinem Geheimnis zu fragen. Dieser Schritt kann das Darstellen einer Dialogbox auf einem graphischen Benutzerinterface auf dem Display des Benutzerinterfaces, eine Sprachmeldung, etc., enthalten. Der Benutzer 10 gibt dann sein Loginnamen und sein Passwort ein (Pfeil 12). Die Geheimnisse können ein Passwort, eine Passphrase, biometrische Benutzerdaten, etc. enthalten.
  • Der Loginname und die eingegebenen Geheimnisse werden dann in dem Modul zum einzigen Einloggen 13 geprüft und mit Namen und Geheimnissen, die in einem geschützten Bereich des Moduls 13 (nicht dargestellt) gespeichert sind, verglichen, um die Autorisierung des Benutzers zu überprüfen. Wenn der Test fehlschlägt, kann der Benutzer beantragen, es noch einmal zu versuchen, bis eine vorgegebene maximale Anzahl von Versuchen erreicht wurde. Andernfalls ist die Chipkarte 17 aktiviert (Pfeil 15), um die benötigte Logininformation (Pfeil 16) zu empfangen, die benötigt wird, um die Kommunikationsschichten 22–27 (Pfeile 18–21) erfolgreich zu beenden.
  • 3 – Allgemeine theoretische Beschreibung
  • Wir werden nun einige Definitionen und theoretische Konzepte einführen, die in den folgenden Sektionen benötigt werden.
  • 3.1 – Klassifikationen von Authentisierungsmechanismen
  • 3.1.1 Definition
  • 2 zeigt einen Sender 30 und einen Empfänger 36. Der Empfänger 36 lässt den Sender nur auf den beantragten Service zugreifen, wenn ein Authentikator 37, der von dem Sender empfangen wurde, verifiziert werden kann. Der Authentikator 33, der von dem Sender gesendet wurde, wird durch den Gebrauch von Verfahrensmittel 34 von einem Geheimnis 31, welches durch den Benutzer eingegeben wurde, z.B. ein Passwort, eine Passphrase, ein PIN oder biometrische Daten, und von anderen Daten 32, wie Benutzer ID, die Zeit, etc, weiterverarbeitet. Der Authentikator ist definiert als Rohdaten, welche von dem Empfänger 36 in einem Authentikationsschema empfangen werden, und welche verwendet werden, um die Identität des Senders 30 zu verifizieren. Der Authentikator wird zwischen dem Sender und dem Empfänger (Pfeil 35) über den Kommunikationskanal gesendet und in einem Verifizierungsprozess 39 von dem Empfänger 36 verifiziert, um ein Authentikationsergebnis 38 zu liefern.
  • Der Verifikationsprozess 39 und der Empfänger 36 können verschiedene Arten von Authentikatoren 37 verwenden:
  • 3.1.3 – Klartextauthentikatoren
  • In dieser Kategorie wird keine Weiterverarbeitung vorgenommen, um das Geheimnis 31, welches von dem Benutzer 10 eingegeben wurde, in nicht-lesbare Form zu transformieren. Das impliziert, das wir das Geheimnis, welches von dem Benutzer eingegeben wurde, durch das Lesen des Authentikators direkt lesen können.
  • 3.1.3.1 – Permanentes Geheimnis (Mechanismus AUTH1)
  • In einem ersten Fall von Klartextauthentifizierungsmechanismen, welche als Mechanismus AUTH1 bezeichnet werden, dient dasselbe Geheimnis 31, welches in dem Authentikator enthalten ist, dazu, um viele Authentifizierungen durchzuführen. Ein typisches Beispiel ist ein Fernlogin auf den meisten UNIX Maschinen. Der Benutzer tippt immer dasselbe Passwort ein und das Passwort wird als Klartext zu der Maschine gesendet. Diese Art von Authentifizierung ist die schwächste.
  • 3.1.3.2 – Eine-Zeit Geheimnis (Mechanismus AUTH2)
  • In einem zweiten Fall (AUTH2) wird ein neues Geheimnis 31 von dem Benutzer 10 jedes Mal eingegeben, wenn eine neue Authentifizierung benötigt wird. Der Benutzer kann zum Beispiel mit einer Liste von Passworten oder PINs ausgestattet sein, welche geheim gehalten werden muss. Der Empfänger 36 muss also dieselbe Liste haben. Bei jeder neuen Authentifizierung, nimmt der Benutzer ein neues Passwort von der Liste und sendet es in Klartext dem Empfänger zur Verifikation.
  • Ein anderes Beispiel ist das so genannte SecureID-Authentifizierungverfahren. In diesem Fall ist der Benutzer 10 mit einem Token ausgestattet, welcher jede Minute eine neue geheime Nummer anzeigt. Bei jeder Authentifizierung gibt der Benutzer die neu angezeigte Nummer an.
  • Dieser Typ von Authentifizierung gibt Schutz gegen Wiederholungsattacken. Es soll jedoch derart implementiert werden, dass es nicht möglich sein soll, das nächste Passwort oder PIN zu erraten, selbst wenn ein Hacker alle vorgängigen besitzt.
  • 3.1.4 – Kryptographische Authentikatoren
  • In dieser Kategorie wird das Geheimnis 31, welches von dem Benutzer 10 eingegeben wurde, in eine nicht-lesbare Form konvertiert, wobei eine kyprographische Funktion verwendet wird.
  • 3.1.5 – Hashed Passwort (Mechanismus AUTH3)
  • Diese Kategorie von kryptographischen Authentifizierungsmechanismen ist in der 3 dargestellt. In diesem Fall, wird eine in eine Richtung ausgerichtete Hashfunktion 51 verwendet, um das Geheimnis 50 zusammen mit anderen Daten, so wie Schutz vor Wiederholungsattacken, der Benutzer-ID, einer Sequenznummer oder einer zufälligen Nummer in einen verschlüsselten Authentikator 52 umzuwandeln.
  • Die Hashfunktion ist ein Algorithmus, welcher einen variablen Längeninput aufnimmt und einen Ausgang von einer bestimmten Länge produziert. Eine Hashfunktion wird als eine sichere Umformungsfunktion bezeichnet, wenn sie folgende Eigenschaften aufweist: der Ausgang ist eine Kette von Zeichen bestimmter Länge, selbst wenn der Eingang eine Kette von Zeichen variabler Länge ist; sie müssen eine in eine Richtung ausgerichtete Funktion sein, es ist zum Beispiel bei einem bestimmten Ausgang nicht möglich, den Eingang zu erraten; sie müssen kollisionsfrei sein, d.h. es ist schwer, zwei Eingänge zu generieren, die denselben Ausgang ergeben. Diese Funktionen werden allgemein als in eine Richtung ausgerichtete Funktionen bezeichnet. Beispiel für diese Funktionen sind: Snefru, N-Hash, MD4 (Message Digest 4), MD 5 (Message Digest 5), MD 2 (Message Digest 2), SHA (Secure Hash Algorithm), Ripe-MD, Haval, etc.
  • In diesen Arten von Mechanismen wird das Passwort als Eingang allgemein mit anderen Informationen, etc. verbunden.
  • 3.1.5.1 Symmetrische Algorithmen
  • 3.1.5.1.1 Symmetrische Algorithmen ohne Schlüsselschutz (Mechanismus AUTH4)
  • Dieser Fall ist in der 4 dargestellt. In diesem Fall wird eine kryptographische Funktion 62 mit einem Schlüssel 61 verwendet, um die Daten 60, welche das Benutzergeheimnis und einen Schutz vor Wiederholungsattacken, wie eine Benutzer-ID, eine Sequenznummer oder eine zufällige Nummer, enthalten, in einen verschlüsselten Authentikator 63 umzuwandeln.
  • In diesem Szenario wird der Schlüssel 61, welcher durch die kryptographische Funktion 62 verwendet wird, nur auf der Ebene des Betriebssystems geschützt. Mit anderen Worten bedeutet dies, dass der geheime Schlüssel auf der Disk in Klartext gespeichert ist und der Zugang dazu wird nur von einer Zugangkontrolle des Betriebssystems geschützt. Einige Beispiele von symmetrischen kryptographischen Funktionen sind: DES, Triple DES, IDEA, REDOC, MMB, etc.
  • 3.1.5.1.2 – Symmetrische Algorithmen mit schwachem Schlüsselschutz (Mechanismus AUTH5)
  • Dieser Fall ist in 5 dargestellt. In diesem Fall muss ein Geheimnis 64 von dem Benutzer eingegeben werden, um Zugriff zu einer Anwendung (Pfeil 65) oder einer Software 66 zu bekommen, mit welcher einige Daten, wie Schutz gegen Wiederholungsattacken, die Benutzer-ID, eine Sequenznummer oder eine zufällige Nummer durch eine symmetrische kryptographische Funktion 63 unter Verwendung eines geheimen Schlüssels 68 verschlüsselt werden kann. Diese Funktion 63 berechnet einen verschlüsselten Authentikator 70.
  • Dies gibt einen schwachen Schutz, weil auf den geheimen Schlüssel 68 immer noch auf dem Niveau des Betriebssystems zugegriffen werden kann, da dieser auf der Disk in Klartext gespeichert ist.
  • 3.1.5.1.3 – Symmetrische Algorithmen mit starkem Schlüsselschutz (Mechanismus AUTH6)
  • Dieser Fall ist in 6 dargestellt. In diesem Szenario ist der geheime Schlüssel 92 unter der Verwendung einer sicheren Transformationsfunktion 91 direkt von dem Geheimnis 90 (PIN/Passwort) abgeleitet, das von dem Benutzer eingegeben wird. Dieser Schlüssel wird von einer symmetrischen kryptographischen Funktion 94 verwendet, um den verschlüsselten Authentikator 95 von der Information 93 des Schutzes gegen Wiederholungsattacken zu berechnen. Deshalb wird der geheime Schlüssel 92 niemals auf der Harddisk des Klienten gespeichert. Diese sichere Umwandlung ist eine in eine Richtung aufgerichtete Hashfunktion, die oben beschrieben wurde, und die dieselben Merkmale aufweist.
  • 3.1.5.2 Asymmetrische Algorithmen
  • 3.1.5.2.1 Asymmetrische Algorithmen ohne Schlüsselschutz (Mechanismus AUTH7)
  • Dieses Szenario ist dasselbe, wie dasjenige, welches in §3.1.5.1.1 in Verbindung mit einem symmetrischen Algorithmus ohne Schlüsselschutz beschrieben wurde, ausser dass der geheime Schlüssel durch einen privaten Schlüssel ersetzt werden muss.
  • Beispiele eines asymmetrischen Algorithmus enthalten RSA (Rivest Shamir Adleman), ECC (Elliptic Curve Cypto-system), El-Gamala, DAS, ESIGN, etc.
  • 3.1.5.2.2 Asymmetrische Algorithmen mit schwachem Schlüsselschutz (Mechanismus AUTH8)
  • Dieses Szenario ist dasselbe, wie dasjenige, welches in §3.1.5.1.2 in Verbindung mit einem symmetrischen Algorithmus mit schwachen Schlüsselschutz beschrieben wurde, ausser dass der geheime Schlüssel durch einen privaten Schlüssel ersetzt werden muss.
  • 3.1.5.2.3 – Asymmetrische Algorithmen mit starken Schlüsselschutz (Mechanismus AUTH9)
  • Dieser Fall ist in 7 dargestellt. In diesem Szenario ist der private Schlüssel 105, welcher durch die asymmetrische kryptographische Funktion 107 verwendet wird, um den Authentikator 108 von der Information 106 zu berechnen, selbst geschützt. Er ist in einer verschlüsselten Form auf der Harddisk des Klienten gespeichert. Um ihn zu entschlüsseln, muss ein Passwort/PIN 100 eingegeben werden. Ein geheimer Schlüssel 102 wird mit einer sicheren Transformationsfunktion 101 von dem Passwort 100 abgeleitet; dieser sichere Schlüssel 102 wird durch das symmetrische Entschlüsselungsmodul 103 verwendet, um den privaten Schlüssel 104 zu entschlüsseln. Die sichere Transformationsfunktion ist eine in eine Richtung ausgerichtete Hashfunktion.
  • 3.2 – Integration von Authentifikationsmechanismen mit der Chipkarte
  • 3.2.1 – Authentifizierungsdaten und Authentifizierungsfunktionen
  • Wir werden nun für jeden Typ von Authentifizierung, der oben beschrieben wurde, beschreiben, welche Authentifizierungsdaten auf der Chipkarte 17 der Erfindung gespeichert werden, und welche Authentifizierungsfunktionen in das Modul 13 zum einzigen Einloggen implementiert werden müssen.
  • Die meiste Zeit funktionieren die Mechanismen des Typs AUTH2 mit externen und allein stehenden Geräten (entweder ein Token, der ein PIN/Passwort darstellt oder ein Stück Papier, auf welches der PIN/das Passwort niedergeschrieben wird) und es ist oft unerwünscht, diese auf einer Chipkarte zu implementieren. Auf diesem Grund werden diese Typen von Mechanismen in diesem Dokument nicht weiter beschrieben.
  • 3.2.2 – Authentifikationsmechanismen, die eine Chipkarte verwenden
  • Die 8 zeigt den Authentifizierungsvorgang für die Authentifizierung des Typs AUTH1 (Klartextauthentifizierung). In diesem Fall dient die Chipkarte 17 gerade als ein sicherer Aufbewahrungsort für die Authentifikatoren. Wenn das Modul zum einzigen Einloggen ein Login bei einem Authentifikationsserver 110 vom Typ AUTH1 (Pfeil 113) beantragt, beantwortet letzterer dies dadurch, dass er einen Authentikator, gewöhnlich ein PIN oder ein Passwort (Pfeil 114), beantragt. Das Modul 13 zum einzigen Einloggen beantragt diesen Authentikator vom der Chipkarte (Pfeil 111). Wenn sich die letztere in einem aktiven Status befindet, sendet sie den Authentikator zu dem Modul 13 (Pfeil 112), möglicherweise mit anderen Daten. Dieser Authentikator wird mit anderen Daten zu dem Server 110 übertragen (Pfeil 115); wenn der Authentikator verifiziert ist, sendet er die Authentifizierungsergebnisse zu dem Modul 13 zum einzigen Einloggen (Pfeil 116).
  • Die 9 zeigt den Authentifizierungsvorgang für die Authentifizierung des Typs AUTH3 (kryptographischer Authentikator). In diesem Fall wird die Chipkarte 17 verwendet, um das Geheimnis sicher zu speichern und den Hashwert, der aus dem gespeicherten Geheimnis abgeleitet wird, zu berechnen. Wenn das Modul zum einzigen Einloggen ein Login bei einem Authentifikationsserver 127 vom Typ AUTH3 (Pfeil 122) beantragt, beantwortet letzterer dies dadurch, dass er einen Authentikator, gewöhnlich ein Hashwert eines PINs oder eines Passworts (Pfeil 123), beantragt. Das Modul 13 zum einzigen Einloggen beantragt diesen Authentikator vom der Chipkarte (Pfeil 120). Wenn sich die letztere in einem aktiven Status befindet, berechnet sie den Authentikator von dem Benutzerpasswort und möglicherweise von anderen Daten und sendet ihn zu dem Modul 13 (Pfeil 121), welches diesen zu dem Server 127 sendet (Pfeil 124); wenn der Authentikator verifiziert ist, sendet der Server 127 die Authentifizierungsergebnisse zu dem Modul 13 zum einzigen Einloggen (Pfeil 125).
  • Die 10 zeigt den Authentifizierungsvorgang für die Authentifizierung des Typs AUTH4 (symmetrischer Algorithmus ohne Schlüsselschutz) und AUTH5 (symmetrischer Algorithmus mit schwachem Schlüsselschutz). In diesem Fall speichert die Chipkarte 17 den geheimen Schlüssel auf sichere Weise.
  • Wenn das Modul 13 zum einzigen Einloggen ein Login bei einem Authentifikationsserver 136 vom Typ AUTH4 oder AUTH5 (Pfeil 132) beantragt, beantwortet letzterer dies dadurch, dass er einen Authentikator (Pfeil 133) beantragt. Das Modul 13 zum einzigen Einloggen sendet die Information zur Authentifizierung zur Chipkarte (Pfeil 130). Wenn sich die letztere in einem aktiven Status befindet, verschlüsselt sie die Daten durch den Gebrauch eines symmetrischen Algorithmus' mit dem geheimen Schlüssel, um den Authentikator herzustellen, welcher zum Modul zum einzigen Einloggen gesendet wird (Pfeil 131), welches ihn zum Authentifikationsserver 136 zur Verifizierung weiterleitet (Pfeil 134); wenn der Authentikator verifiziert ist, sendet der Server 136 die Authentifizierungsergebnisse zu dem Modul 13 zum einzigen Einloggen (Pfeil 135).
  • 11 zeigt den Authentifizierungsvorgang für die Authentifizierung des Typs AUTH6 (symmetrischer Algorithmus mit starkem Schlüsselschutz). In diesem Fall speichert die Chipkarte 17 das Passwort auf sichere Weise.
  • Wenn das Modul 13 zum einzigen Einloggen ein Login bei einem Authentifikationsserver 140 vom Typ AUTH6 (Pfeil 143) beantragt, beantwortet letzterer dies dadurch, dass er einen Authentikator (Pfeil 144) beantragt. Das Modul 13 zum einzigen Einloggen beantragt den Authentikator (Pfeil 141). Die Chipkarte 17 leitet erst den geheimen Schlüssel durch die Anwendung einer sicheren Hashfunktion auf das Geheimnis (Passwort/PIN) ab. Es verschlüsselt dann die Daten mit dem geheimen Schlüssel, der vorher abgeleitet wurde, durch den Gebrauch einer symmetrischen kryptographischen Funktion scf und gibt den Authentikator zum Modul zum einzigen Einloggen heraus (Pfeil 142), welches ihn zum Authentifikationsserver 140 zur Verifizierung weiterleitet (Pfeil 145); wenn der Authentikator verifiziert ist, sendet der Server 140 die Authentifizierungsergebnisse zu dem Modul 13 zum einzigen Einloggen (Pfeil 146).
  • Die 12 zeigt den Authentifizierungsvorgang für die Authentifizierung des Typs AUTH7 (asymmetrischer Algorithmus ohne Schlüsselschutz), AUTH8 (asymmetrischer Algorithmus mit schwachem Schlüsselschutz) und AUTH9 (symmetrischer Algorithmus mit starkem Schlüsselschutz). In diesem Fall speichert die Chipkarte den privaten Schlüssel, welcher dazu dient, die Daten asymmetrisch zu entschlüsseln, um den Authentikator herzustellen.
  • Wenn das Modul 13 zum einzigen Einloggen ein Login bei einem Authentifikationsserver 150 vom Typ AUTH7, AUTH8 oder AUTH9 (Pfeil 153) beantragt, beantwortet letzterer dies dadurch, dass er einen Authentikator (Pfeil 154) beantragt. Das Modul 13 zum einzigen Einloggen beantragt den Authentikator (Pfeil 151). Die Chipkarte 17 verschlüsselt die Daten mit dem privaten Schlüssel durch die Anwendung einer sicheren Transformationsfunktion stf und/oder einer symmetrischen kryptographischen Funktion scf und sendet den Authentikator zu dem Modul zum einzigen Einloggen (Pfeil 152), welches ihn zum Authentifikationsserver zur Verifizierung weiterleitet (Pfeil 155); wenn der Authentikator verifiziert ist, sendet der Server 150 die Authentifizierungsergebnisse zu dem Modul 13 zum einzigen Einloggen (Pfeil 156).
  • Die unten dargestellte Tabelle 1 fasst die Chipkartenspeicherung und die Verarbeitungsfunktion für jede Art von Authentisierungsmechanismus zusammen:
  • Figure 00160001
  • Die oben dargestellte Tabelle zeigt eine eins-zu-eins Zuordnung von existierenden Mechanismen in der Chipkarte 17. Dank den Eigenschaften der Chipkarte kann der Mechanismus AUTH9 jedoch optimiert oder vereinfacht werden, ohne diese Authentisierungsmechanismen zu schwächen.
  • Die Chipkarte, welche verwendet wird, ist vorzugsweise eine sichere Chipkarte. Es hat vorzugsweise die Eigenschaft, dass sie manipulationssicher ist, d.h. sie muss allen bekannten Arten von Hardwareattacken widerstehen.
  • Zusätzlich ist die Software, die in der Chipkarte gespeichert ist, gewöhnlich aus zwei Teilen zusammengesetzt: eine gespeichert in einem ROM, allgemein als Betriebssystem (OS) bezeichnet, und die andere in einem EEPROM gespeichert, allgemein als Anwendung bezeichnet. Das OS und die Anwendung, die in der Chipkarte gespeichert sind, sind so klein und beschränkt, dass es möglich ist zu garantieren, dass einige ausgewählte Daten niemals ausgelesen werden.
  • Während es mit einem Computer (und besonders mit einem Laptop) allgemein unmöglich ist sicherzustellen, dass die Sicherheit, die durch das OS bereitgestellt wird, nicht umgangen wird und dass die sicheren Daten nicht durch eine unauthorisierte Person ausgelesen werden, können wir bei einer Chipkarte annehmen, dass das Sicherheitssystem nicht umgangen wird.
  • Basierend auf der oben gemachten Annahme besteht kein Bedürfnis, den privaten Schlüssel von AUTH9 in einer verschlüsselten Form in dem Speicher der Chipkarte zu speichern.
  • Deshalb kann AUTH9 vereinfacht werden und wird dasselbe wie AUTH8, ohne das Sicherheitsniveau zu reduzieren.
  • Wenn wir uns auf die Tabelle 1 beziehen, sind ausser in AUTH3 und AUTH6 alle Geheimnisse (PIN/Passwort) in der Berechnung des Authentikators nicht direkt involviert, sondern sind nur dazu da, den Zugriff auf die Berechnung des Authentikators zu schützen. Anstelle von einem Geheimnis für jedes System können wir ein Geheimnis auf jeder Chipkartenebene definieren, welches den Zugriff auf alle Arten von Authentikatorenberechnungen schützt. Das Geheimnis, welches verwendet wird, um Zugang zu der Chipkarte zu erlangen, wird Kartenaktivierungsgeheimnis oder Kartenaktivierungs-PIN/Passwort genannt.
  • 3.3 – Gesamtverfahren
  • Wir werden nun mit der 13 beschreiben, wie der erfindungsgemässe vereinte Einloggungsprozess funktioniert. Der Benutzer 10 wird durch das Modul 13 zum einzigen Einloggen am Anfang aufgefordert, einen Loginnamen und ein Geheimnis (PIN/Passwort) auf einem graphischen Benutzerinterface 160 einzugeben. Dieses Geheimnis wird verwendet, um die Chipkarte 17 zu aktivieren, und damit wird die Chipkarte fähig sein, alle Authentifizierungen, die später für jede Schicht benötigt werden, abzuwickeln. Ein externes Interface 161 leitet die Authentifizierungsanfragen von zahlreichen Authentifizierungsservern 162 bis 169 an das Modul 13 zum einzigen Einloggen weiter und sendet den erhaltenen Authentikator von der Chipkarte 17 zu diesen Servern.
  • Die Authentifizierungen werden nur durchgeführt, wenn sich die Chip-Karte 17 im aktiven Status befindet. Um in einem solchen Status zu sein, sind zwei Bedingungen obligatorisch: die Chip-Karte muss zuerst eingeschaltet werden; dann muss das korrekte Aktivierungsgeheimnis gegeben werden. Wenn die Chip-Karte ausgeschaltet ist (d.h. von ihrem Lesegerät entfernt wurde), kehrt sie automatisch in den inaktiven Status zurück. Deshalb wird eine gestohlene Karte unbrauchbar für einen Hacker.
  • 14 zeigt einen Ablauf der Verfahrensschritte für das erfindungsgemässe einzige Einloggverfahren zur Mehrschichtauthentifizierung unter Verwendung der Chipkarte.
  • Nachdem Booten der Maschine startet das graphische Benutzerinterface (Schritt 170) und fordert den Benutzer 10 auf, seinen Loginnamen und sein Geheimnis einzugeben. Der Benutzer kann wählen, das einige Einloggen nicht durchzuführen und tippt Abbrechen, d.h. wenn die Maschine in einem alleinstehenden Mode (Schritt 171) verwendet wird. In diesem Fall gibt es kein Fernlogin (Schritt 172).
  • Wenn der Benutzer 10 sich entscheidet den Loginnamen und das Geheimnis (Schritt 177) einzugeben, übermittelt das Modul zum einzigen Einloggen diese während Schritt 178 an die Chipkarte 17 zur Verifizierung. Wenn die Chipkarte angeschaltet ist, verifiziert sie diese Daten während Schritt 179. Wenn die Logininformation, die angeboten wurde, falsch ist, erhöht die Chipkarte einen internen Zähler (Schritt 180). Wenn der Wert grösser als ein Schwellenwert ist (Test 173), dann blockiert die Karte sich selbst, um unbrauchbar zu werden (Schritt 174) und sendet das Loginergebnis zu dem Modul 13 zum einzigen Einloggen zurück (Schritt 175). Das Login ist fehlgeschlagen (Schritt 176).
  • Der Authentikator, der für die Authentifikation des Benutzers 10 verwendet wird, kann biometrische Parameter, z.B. Fingerabdrücke, Irismuster, Retinamuster, Sprachparameter, Gesichtparameter, etc. verwenden.
  • Der Schwellenwert kann zum Beispiel auf 3 gesetzt werden, was dem Benutzer erlaubt, dreimal ein Login zu versuchen. Dieser Mechanismus ist in der Karte implementiert, um einem Hacker davon abzuhalten, eine Gewaltattacke auf die Karte anzuwenden, d.h. alle möglichen Kombinationen des Geheimnisses auszuprobieren, bis er den richtigen Treffen landet. Der Zähler wird natürlich auf 0 zurückgesetzt, jedes Mal, wenn der Benutzer 10 sein richtiges Geheimnis eingibt, sofern die Karte nicht bereits blockiert ist.
  • Wenn die Login-information korrekt ist, setzt sich die Karte 17 selbst in einen aktiven Status (Schritt 181) und bestätigt das Modul zum einzigen Einloggen (Schritt 182). Das letztere kann anfangen, die verschiedenen Kommunikationsschichten (Schritt 183 bis 184) aufzubauen. Beginnend von der untersten Schicht, prüft es während dem Schritt 185, ob eine Authentifizierung für den Aufbau einer Kommunikation erforderlich ist. Wenn keine Authentifizierung erforderlich ist, werden die Kommunikationsschichten automatisch während des Schritts 186 aufgebaut.
  • Wenn eine Authentifizierung benötigt wird, dann sendet der Authentisierungsfernserver die notwendigen Daten (wenn benötigt) zu dem Modul 13 zum einzigen Einloggen. Das Modul zum einzigen Einloggen übermittelt diese Daten zu der Chipkarte 17. Diese Chipkarte schickt den Authentikator zum Modul zum einzigen Einloggen zurück (Schritt 188). Der Authentikator wird dann zu dem Authentisierungsfernserver zur Verifizierung (Schritt 190) übermittelt. Der Authentisierungsserver kann die Authentisierung selbst übernehmen oder delegiert die Verifizierung des korrespondierenden Authentikators zu einem dritten Gerät (nicht dargestellt). Wenn der Authentikator nicht gültig ist, kann die Authentifizierung eine gewisse Anzahl von Versuchen unter Verwendung des Zählers a wiederholt werden und, wenn dies dann immer noch falsch ist (Test 191), entweder durch den Fernserver oder durch das Modul zum einzigen Einloggen (Schritt 192) gestoppt werden. Wenn der Authentifizierung korrekt ist, wird das Set-up für die Kommunikationsschicht vervollständigt (Schritt 186). Das Modul 13 zum einzigen Einloggen fährt so mit allen Schichten Li fort, bis alle imax Schichten vervollständigt sind (Schritt 193).
  • 3.4 – Transparente Schichtkonstruktion
  • Wenn aus irgendeinem Grund eine Kommunikationsschicht die Verbindung verliert, soll das Modul 13 zum einzigen Einloggen in der Lage sein, die Schicht ohne Benutzerintervention wieder aufzubauen. In diesem Fall verifiziert das Modul 13 zum einzigen Einloggen vorzugsweise, ob die Chipkarte 17 immer noch vorhanden ist und sich in einem aktiven Status befindet. Dann muss diese einen neuen Authentikator zu dem Authentifizierungsserver senden. Der Authentifizierungsvorgang geht dann weiter, wie oben beschrieben.
  • 4 – Ausführungsbeispiel mit GSM, PPP, IPSEC und NT
  • 4.1 Ein neu erschienener Fernzugriffservice
  • Wir werden nun ein Ausführungsbeispiel des erfindungsgemässen Verfahrens detaillierter beschreiben, in welchem eine Kommunikation zwischen dem Klienten 10 und einem Fernserver durch GSM (Global System for Mobile), PPP (Point To Point Protocol), IPSEC (Internet Protokol Security) und Windows NT (New Technology; Markenzeichen der Microsoft Corp.) aufgebaut wird.
  • Neue Terminals mit höheren Datengeschwindigkeiten (43.2 kbits/s und höher), welche für Mobiltelefone dienen, kommen auf den Markt. Sie enthalten ein GSM-Telefon, eine GSM SIM-Karte und unterstützen HSCSD (High Speed Circuit Switched Data), GPRS (General Packet Radio Service), EDGE (Enhanced Data for GSM Evolution) und/oder UMTS (Universal Mobile Telekommunications System) zur Hochgeschwindigkeitskommunikation. Diese Terminals können in einen Slot eines Laptops als PC-Karte des Typs II oder des Typs III eingesteckt werden oder sind in einem Mobiltelefon oder einem Persönlichen Digitalen Assistenten (PDA) integriert.
  • Diese Terminals erlauben einen schnellen Zugriff zu Fernorten, ohne Festtelefonnetzwerke zu verwenden. An deren Stelle wird ein GSM-Netzwerk bis zum ersten ISDN (Integrated Services Digital Network)- oder PSTN (Public switched Telephone network)-Router verwendet. Fernzugriffe stellen jedoch andere Sicherheitsrisiken dar, da sie ungeschützte oder öffentliche Netzwerke durchqueren können. IPSEC ist ein Sicherheitsprotokoll auf der Ebene des IP (Internet Protocol), welches ein gutes Sicherheitsniveau von dem Laptop zum Eintrittpunkt des Fernnetzwerkes (allgemein spricht man von Gateway) erlaubt. Wenn die mobilen Benutzer schlussendlich versuchen, sich zu seinem Firmennetzwerk zu verbinden, ist es wahrscheinlich, dass sie versuchen werden, sich in ihre NT-Domain einzuloggen.
  • Für einen solchen Fernzugriff sind viele Schichten nacheinander aufzubauen und jede dieser Schichten benötigt eine Authentifizierung des mobilen Benutzers oder der Maschine, die für den Benutzer handelt. Wir werden danach sehen, wie diese verschiedenen Authentifizierungen mit nur einer Loginaktion von dem mobilen Benutzer unter Verwendung der Chipkarte durchgeführt werden können.
  • 4.2 Schichtkonstruktion
  • Diese Situation ist in der 15 illustriert. Eine Vielzahl von mobilen Benutzern 207, 209 verwenden mobile Geräte, wie Laptops, einen persönlichen digitalen Assistenten oder ein Mobiltelefon, um auf Datenfiles und Anwendungen in einem fernen NT Server 214 ihres eigenen Firmennetzwerks 213 zuzugreifen. Diese Kommunikation wird durch eine Basisstation 206 bzw. 208 eines GSM Netzwerkes 205 und das Internet durch einen Internetserviceprovider 203 unter Verwendung eines Routers 204 etabliert. Der NT Server 214 ist durch ein Firmen-LAN 213, einen Routen 212, ein IPSEC-Gateway 211, ein Firewall und einen anderen Internetserviceprovider 202 mit dem Internet 201 verbunden. Andere Router 215 können an das Firmennetzwerk 213 angeschlossen werden, um Zugriff zu anderen Netzwerken und Unternetzwerken bereitzustellen. Andere Internetserviceprovider 200 stellen den Zugriff auf das Internet 201 bereit.
  • 16 illustriert den Schichtaufbau in diesem speziellen Ausführungsbeispiel der Erfindung. Elemente und Verfahrensschritte äquivalent zu denen, die bereits in Verbindung mit 1 beschrieben wurden, werden mit denselben Bezugszeichen beschrieben und werden nicht noch einmal beschrieben. Das Modul 13 zum einzigen Einloggen wird hier als Teil einer Middleware 210, z.B. eines mobilen Geräts, eines Laptops, eines Palmtops, etc. gezeigt. Der Benutzer 10 kann auf einen Fernserver zugreifen, in dem mindestens die folgenden aufeinander folgenden Netzwerkschichten aufgebaut werden:
    • • eine GSM Schicht 215, welche eine GSM Authentifizierung 211 benötigt,
    • • eine PPP Schicht 216, welche ein PPP Login mit einer CHAP-Authentifizierung 212 benötigt,
    • • eine IPSEC-Schicht 217, welche eine IPSEC-Authentifizierung 213 benötigt,
    • • eine NT Schicht, welche ein NT Login 214 benötigt.
  • Wir werden nun die Konstruktion von diesen vier Schichten beschreiben.
  • 4.2.1 – GSM
  • Die GSM Schicht 215 sorgt für drei Sicherheitsservices: Identifizierung der Teilnehmerauthentifizierung, Vertraulichkeit der Benutzer- und Datensignale und die Vertraulichkeit der Teilnehmeridentität.
  • Der erste Service wird verwendet, um die Identität des mobilen Teilnehmers (MS) zu etablieren, wenn er versucht, auf das GSM Netzwerk zuzugreifen. Die Authentifizierung wird von dem Festnetz 231 (17) initiiert, welches ein Challenge 234 (zufällige Nummer) an das Mobiltelefon 230 sendet. Dieser Challenge wird zu der Chip-Karte 17 weitergeleitet, die in diesem Zusammenhang auch SIM (Subscriber Identity Module)-Karte genannt wird, welche die Antwort 233 durch Anwendung der in einer Richtung angewendete A3 Hashfunktion auf die zufällige Nummer, die mit einem geheimen Schlüssel, der in der SIM-Karte gespeichert ist und mit der Benutzeridentifikation empfangen wurde, berechnet. Diese Antwort wird an das Netzwerk (Pfeil 235) weitergeleitet, welche sie verifiziert und den Erfolg oder den Misserfolg bestätigt (Pfeil 235).
  • Der geheime Schlüssel 17, welcher benötigt wird, um den Hashwert zu berechnen, wird nur von der Chip-Karte und einem Authentifizierungszentrum, welches als Heimatnetzwerk des Teilnehmers dient, geteilt. Der Ausgang des Hashwertes, welche von der SIM-Karte 17 berechnet wird, wird zu dem Festnetz 231 weitergeleitet, wo es mit einem vorausberechneten Wert verglichen wird. Wenn die beiden Hashwerte übereinstimmen, hat sich der Benutzer (mobiler Teilnehmer) authentifiziert und es ist dem Anruf erlaubt, weiter fortzufahren. Wenn die beiden Werte verschieden sind, dann wird der Zugriff verweigert. Wenn die Karte nicht in den aktiven Status gesetzt wurde (d.h. wenn der korrekte PIN eingegeben wurde), kann diese Authentifizierung nicht geschehen.
  • 4.2.2 PPP
  • Die nächste Schicht benutzt das Punkt-zu-Punkt-Protokoll (PPP), welches ein Standartverfahren bereitstellt, um Mehrfachprotokolldatagramme über Punkt-zu-Punkt-Verbindungen zu transportieren. Mit verschiedenen PPP Authentifizierungsverfahren sind möglich:
    • • PAP (password authentication protocol), welche das Klartextpasswort verwendet,
    • • CHAP, welche eine in eine Richtung ausgerichtete MD5-Funktion verwendet,
    • • EAP, welche eine in einer Richtung ausgerichtete Hashfunktion oder OTP verwendet,
    • • SecureID
  • 4.2.2.1 – PAP
  • Das PAP (password authentication protocol), welches in der 18 illustriert ist, stellt ein einfaches Verfahren für einen Benutzer 253 zur Verfügung, um seine Identität durch die Verwendung eines in zwei Richtungen ausgerichteten Handschlags mit dem Fernserver 256 zu etablieren. Dies wird nur durch einen initialen Verbindungsaufbau geschehen.
  • Nachdem die Phase des Verbindungsaufbaus beendet ist, wird wiederholt eine ID/ein Paar von Passworten durch den Klienten an den Authentifizierungsserver gesendet, bis die Authentifizierung bestätigt ist (Pfeil 255) oder bis die Verbindung beendet ist.
  • PAP ist kein starkes Authentifizierungsverfahren. Passworte werden in Klartext über das Netzwerk gesendet und es gibt keinen Schutz vor Wiederholungen oder wiederholten Versuchen und Fehlerattacken. Der Benutzer 253 kontrolliert die Frequenz und das Timing der Versuche.
  • Das Authentifizierungsverfahren ist von Typ AUTH1, wie es oben definiert wurde. Um PAP mit einer Chip-Karte 17 zu integrieren, sollten die ID und das Passwort in einem EEPROM der Chip-Karte gespeichert werden. Wenn das Modul 13 eine PPP-Verbindung mit dem Fernserver 260 (19) anfängt, muss es einen Antrag zum Empfangen einer ID/eines Passworts zur Chip-Karte senden (Pfeil 261) und leitet die Antwort 262 als eine 'Authentifizierungsantrags'-Meldung 263 weiter. Der Fernserver 260 antwortet mit einer Authentifizierungsmeldung oder einer negativen Authentifizierungsmeldung 264.
  • 4.2.2.2 – CHAP
  • CHAP (Challenge-Handshake Authentication Protocol) ist ein anderes weit verwendetes Authentifizierungsverfahren, welches durch PPP verwendet wird. CHAP wird verwendet, um periodisch die Identität von dem Benutzer unter Verwendung eines 3-Wege Handschlags zu überprüfen. Dies geschieht nach initialem Verbindungsaufbau und kann jederzeit wiederholt werden, nachdem die Verbindung aufgebaut wurde.
  • Die Integration von CHAP mit einer Chip-Karte 17 ist in 20 dargestellt. Nachdem die Phase des Verbindungsaufbaus abgeschlossen ist, sendet der Authentifizierungsserver 275 eine Challengemeldung 272 zu dem Modul 13 des Benutzers zum einzigen Einloggen, welche sie zur Chipkarte 17 (Pfeil 270) weiterleitet.
  • Die letztere berechnet unter Verwendung des MD5-Algorihmus' einen Hashwert. Dieser MD5-Algorithmus wird als Eingang die ID (gespeichert in der Chipkarte), die mit das Passwort (gespeichert in der Chipkarte) und mit dem Challenge (vom Server herausgegeben) verbunden ist, verwenden. Das Ergebnis 271 wird an das Modul 13 zum einzigen Einloggen gesendet, welche es zu dem Server 275 weiterleitet. Der Server überprüft die Antwort gegenüber seiner eigenen Berechnung von dem erwarteten Hashwert. Wenn die Werte übereinstimmen, wird die Authentifizierung bestätigt (Pfeil 274); andernfalls wird die Verbindung beendet.
  • CHAP sorgt durch den Gebrauch von steigend wechselnden Identifizierungsmerkmalen und einem variablen Challengewert für Schutz gegenüber Wiederholungsattacken. Der Authentifizierungsserver kontrolliert die Frequenz und das Timing der Challengewerte.
  • Das Authentifizierungsverfahren ist von Typ AUTH3, wie oben beschrieben.
  • 4.2.2.3 – EAP
  • Das PPP Extensible Authentication Protocol (EAP) ist ein allgemeines Protokoll für die PPP Authentifizierung, welche Mehrfachauthentifizierungsmechanismen unterstützt. Nach der Phase des Verbindungsaufbaus sendet der Authentifizierungsserver einem oder mehrere Anträge an den Benutzer. In diesen Anträgen fragt der Server nach dem Typ der Authentifizierung, welcher er wünscht (MD5, OTP- One time passwort-, etc.). Der Benutzer kann entweder den vorgeschlagenen Typen der Authentifizierung mit einem Antwortpacket, welches die Authentifizierungsantwort enthält, bestätigen oder den vorgeschlagenen Typen der Authentifizierung verweigern. Der Server muss einen anderen Mechanismus vorschlagen, bis einer passt. Die MD5 Authentifizierung, welche in EAP vorgeschlagen wird, ist äquivalent mit einer CHAP Authentifizierung, so dass seine Integration mit einer Chipkarte dieselbe ist als für CHAP. In dem OTP Authentifizierungsmechanismus wird auch eine in eine Richtung ausgerichtete Hashfunktion verwendet, aber sie wird mehrfach angewendet. Zusätzlich haben wir in OTP die Möglichkeit, zwischen mindestens drei Hashalgorithmen, MD4, MD5 und SHA1, auszuwählen. Trotzdem ist dieses Authentifizierungsverfahren von Typ AUTH3, wie es weiter oben definiert wurde, und seine Integration mit einer Chipkarte wird dem definierten Prinzip folgen.
  • Nach dem Verbindungsaufbau beantragt der Authentifizierungsserver 280 (21) eine Authentifizierung, in welcher der Typ spezifiziert wird (Pfeil 283). Wenn MD5 beantragt wird, ist das Prinzip dasselbe, wie es für CHAP beschrieben wurde. Wenn OTP beantragt wird, sendet der Authentifizierungsserver in diesem Antrag den benötigten Algorithmus und das Saatgut (eine Art von zufälligen Nummern). Das Modul 13 zum einzigen Einloggen des Benutzers sendet das Saatgut und den Typ des Algorithmus' zu der Chip-Karte 17 (Pfeil 281). Die Chip-Karte 17 nimmt die OTP Passphrase, welche in seinem EEPROM gespeichert ist, verbindet sie mit dem empfangenen Saatgut, und leitet sie durch den ausgesuchten Hashalgorithmus. Der erste Ausgang wird dann n Male durch den Hashalgorithmus geleitet. Der schlussendliche Ausgang 282 wird dann zu dem Modul zum einzigen Einloggen gesendet, welche das Ergebnis durch eine PPP EAP Antwortmeldung 284 zu dem Authentifizierungsserver 280 weiterleitet. Das Ergebnis wird durch den Authentifizierungsserver geprüft, welche eine PPP EAP Erfolgs- oder Fehlermeldung 285 sendet.
  • 4.2.3 – IPSEC
  • 4.2.3.1 IPSEC grundlegende Beschreibung
  • Die IPSEC Schicht 216 verwendet das IPSEC Protokoll, welches entworfen wurde, um einen sicheren Kanal zwischen Partnern auf IP Ebene zu bereitzustellen. Authentifizierung, Integrität, Vertraulichkeit und Schlüsselaustausch werden bereitgestellt.
  • Ein IPSEC Paket hat folgende Struktur:
    AH|ESP
    wobei AH eine Authentifizierungskopfzeile und ESP eine gekaspelte Sicherheitsnutzlast ist.
  • AH stellt dank einer digitalen Unterschrift über eine Sequenznummer verbindungslose Integrität, originale Datenauthentifizierung, welche symmetrische kryptographische Algorithmen verwendet, und einen Wiederholungsschutz bereit.
  • ESP stellt Datenprivatsphäre (oder Vertraulichkeit) durch die Verwendung von symmetrischen kryptographischen Algorithmen und AH Sicherheitsservices bereit.
  • Für den Schlüsselaustausch verwendet IPSEC IKE (Internet Key Exchange). Es beschreibt einen Rahmen, in welchem IPSEC Verbindungen die Authentifizierung, Verschlüsselung und Schlüsselmanagementinformation verhandeln können.
  • IKE ist in zwei Phasen geteilt: den Hauptmode und den Schnellmode. Im Hauptmode, welcher in der 22 dargestellt ist, ist eine IKE Sicherheitsvereinigung (IKE SA) definiert. Es enthält alle notwendigen Informationen für zwei Einheiten, um gesicherte Meldungen auszutauschen. Im Schnellmode wird ein IPSEC SA von dem IKE SA abgeleitet, um die Schlüssel für den Gebrauch mit einem AH oder einem ESP zu verhandeln.
  • Der erste Meldungsaustausch ist die Verhandlung von Parametern. Der Initiator 290 schlägt verschiedene Algorithmen für die Verschlüsselung und die Authentifizierung vor, ein Zeitlimit und andere Parameter (Pfeil 292). Der Antworter 291 muss eine Option für jeden Parameter auswählen und seine Antwort 293 weiterleiten.
  • In der zweiten Meldung werden Austauschzeichenfolgen und Diffie-Hellman öffentliche Schlüssel übermittelt. Die Zeichenfolgen sind zufällige Nummern, eine (294) generiert von dem Initiator and die andere (295) von dem Antworter. Die Besonderheit von Diffie-Hellman ist, dass beide Parteien einen geheimen Schlüssel nur durch den Austausch von DH öffentlichen Schlüsseln berechnen können, weil:
    DH = DH_Public_I exp (DH_Privat_R) = DH_Public_R exp (DH_Private_I)
  • Der berechnete DH öffentliche Schlüssel wird verwendet, um den dritten Meldungsaustausch zu verschlüsseln. Diese Meldungen 296, 297 enthalten eine Unterschrift, die mit dem öffentlichen Schlüssel von jedem Partner und einer Identifikationsnutzlast getätigt wurde. Die Unterschrift wird über einen Hashwert angewendet. Der Hashwert ist eine Funktion von den Zeichenfolgen, des Diffie-Hellman öffentlichen Schlüssels, der Verhandlungsparameter, der Identifikation des Initiators (oder des Antworters) und der Identifikationsnutzlast.
    Hash_I = fct {nonce_I; nonce_R; DHpublic_I; DHpublic_R; parameter_I; ID_I, etc.}
    Sign_I = sign (Hash_I)Kpriv_I
  • Durch Überprüfen der Unterschrift kann der Antworter über die Identität des Initiators sicher sein, und kann sicher sein, dass die zwei vorherigen Meldungen wirklich von dem vorherigen Initiator gesendet wurden. Andersrum kann der Initiator dasselbe von dem Antworter überprüfen.
  • Zusätzlich zu den ausgetauschten Meldungen und der oben beschriebenen Berechnung werden drei geheime Schlüssel berechnet. Die werden für den nächsten Mode, der Schnellmode genannt wird, verwendet. Diese Schlüssel sind:
    Skey_d: Secret key verwendet, um zukünftige Schlüssel abzuleiten
    Skey_a: Secret key verwendet, um Meldungen, die in dem Schnellmode ausgetauscht werden, zu authentifizieren
    Skey_e: Secret key verwendet, um Meldungen, die in dem Schnellmode ausgetauscht werden, zu verschlüsseln
  • In dem Schnellmode, der in 23 dargestellt ist, werden während den Schritten 312 und 313 zufällige Nummern zwischen dem Initiator 310 und dem Antworter 311 ausgetauscht. Diese Nummern werden verwendet, um neue Schlüssel zu generieren, welche verwendet werden, um ESP zu verschlüsseln und die AH Kopfzeile des IPSEC Pakete zu unterschreiben.
  • Die Authentifizierung im IKE Hauptmode kann durch verschiedene Algorithmen ausgeführt werden. In der ausgetauschten Meldung, die in der 22 gezeigt ist, haben wir nur einen Typen von Authentifizierung illustriert. Unter den möglichen Authentifizierungsverfahren schlägt IKE ein vorher gemeinsam benutztes Geheimnis, welches einen symmetrischen Algorithmus verwendet, DSS Unterschriften, RSA Unterschriften, Verschlüsselung mit RSA und revidierte Verschlüsselung mit RSA vor. Je nach dem, ob wir eine Authentifizierung oder eine andere verwenden, werden sich die ausgetauschten Meldungen leicht unterscheiden, während das Prinzip dasselbe bleibt.
  • 4.2.3.2 Tätigkeiten, die in der Chipkarte vollzogen werden
  • Eine beträchtliche Anzahl von Schlüsseln wird in dem IPSEC Protokoll erzeugt. Zusätzlich werden viele Verschlüsselungs-, Entschlüsselungs- und Unterschriftsvorgänge getätigt. Nur sehr leistungsfähige und teure Chipkarten können alle diese Operationen durchführen. Den meisten billigen Chipkarten mangelt es an Speicherplatz und Rechenleistung.
  • Deshalb müssen wir sorgfältig auswählen, welche Operationen durch die Chip-Karte 17 durchgeführt werden müssen.
  • Der kritischste Schlüssel ist derjenige, welcher verwendet wird, um die Unterschrift in dem dritten Meldungsaustausch 296, 297 des Hauptmodes durchzuführen. Dieser Schlüssel wird nicht nur verwendet, um die Identität des Initiators 290/des Antworters 291 zu überprüfen, sondern er dient auch dazu, den ersten DH Schlüssel und die Zeichenfolge 294, 295 von welchen der ganze Rest des Schlüsselsmaterials abgeleitet wird, zu authentifizieren. In dem Fall eines Laptop als Initiator 290, wenn dieser Schlüssel offen gelegt wird, wird jede Kommunikation mit einem Gateway, der diesen Laptop akzeptiert, ebenfalls offen gelegt und schlimmer noch, jeglicher Zugriff, der auf den Laptop erlaubt wird, wird auch einem Hacker erlaubt.
  • Die Chipkarte 17 soll mindestens diese Unterschriftsoperationen durchführen (wenn die Unterschriften zur Authentifizierung verwendet werden; wenn andere Authentifikationsvorgänge verwendet werden, sollen äquivalente Operationen auch durch die Chipkarte 17 durchgeführt werden).
  • Für andere Operationen ist es eine Abwägung zwischen Sicherheit und Leistungsfähigkeit (beides Rechenleistung und Speicherplatz) Wir können uns zum Beispiel vorstellen den DH Schlüssel des Hauptmodes in der Chipkarte zu generieren; Es ist auch möglich, dass der gesamte Hauptmode in der Chipkarte (DH Schlüssel, Hashberechnungen und Unterschriften über den Hash) durchgeführt werden.
  • Ein anderer Punkt, der nicht in IKE erwähnt wurde, sondern der in den meisten IPSEC Implementationen vorhanden ist, ist das Zertifikat. Jedes Mal benutzen, wenn wir ein öffentliches Schlüsselsystem benutzen, müssen wir zusammen mit dem öffentlichen Schlüssel ein Zertifikat bereitstellen. Dieses Zertifikat wird von einem vertrauensvollen Dritten, die CA (Certification Authority) genannt wird, generiert. Das Zertifikat ist in den Tat eine Unterschrift durch die CA über die öffentlichen Schlüssel des Initiators und des Antworters. Es zertifiziert, dass dieser öffentliche Schlüssel wirklich zu dem Initiator/dem Antworter gehört. Das Zertifikat kann in der Chipkarte oder in einem zentralen Server (z.B. in einem X.500 Verzeichnis) gespeichert werden.
  • 4.2.4 – Windows NT Schicht
  • Das SMB Protokoll wird verwendet, um auf die Windows NT Schicht 218 auf einem Fernort zuzugreifen und eine Sitzungsauthentifizierung erscheint, um die Zugriffskontrolle zu garantieren. Der verwendete Dialekt wird zwischen dem Klienten und dem Server verhandelt. Drei Möglichkeiten können erscheinen:
    • • Klartext-Sitzungsauthentifizierung
    • • LanMan Challenge/Antwort-Sitzungsauthentifizierung
    • • NTLM Challenge/Antwort-Sitzungsauthentifizierung
  • Klartext-Sitzungsauthentifizierung besteht in dem einfachen Senden des NT Passwortes in Klartext zu dem Authentifizierungsserver, der PDC (Primary Domain Controller) genannt wird. Diese Authentifizierung wird mit älteren Lan Manager und SMB Servern verwendet und sollten, wenn immer es möglich ist, vermieden werden.
  • LanMan Challenge/Antwort-Sitzungsauthentifizierung verschlüsselt das Challenge, welcher durch das PDC gesendet wird, unter Verwendung eines Schlüssels, der von dem NT Passwort abgeleitet wird. Der Schlüssel wird LM Hash genannt und wird weiter unten erläutert.
  • NTLM Challenge/Antwort-Sitzungsauthentifizierung verschlüsselt den Challenge, welcher durch den PDC gesendet wird, unter Verwendung eines anderen Schlüssels, der von dem NT Passwort abgeleitet wird. Der Schlüssel wird weiter unten erläutert.
  • Für beide, LanMan und NTLM Authentifizierung, verschlüsselt der Klient den Challenge drei Mal unter Verwendung von DES Algorithmen, wobei jede Verschlüsselung einen verschiedenen Abschnitt der Schlüssel (LM hash oder MD4-NT hash) als Quellenmaterial für die DES Schlüssel verwendet. Der verschlüsselte Text wird zu dem PDC zurückgesendet, welcher dann dasselbe Verschlüsselungsverfahren unter Verwendung seiner eigenen Kopie von dem Hash des Passwortes des Benutzers von der SAM (Security Account Manager) Datenbank durchführt. Wenn der Klient und der Server dieselben Ergebnisse erhalten, wird der Benutzer authentifiziert.
  • 4.2.4.1 – LM Hash in Windows NT
  • Der Lan Manager Hash (LM Hash) wird verwendet, um mit älteren Versionen von Microsoft Netzwerksoftware kompatibel zu sein. Es kann in dem SAM des Primary Domain Controller's PDC gefunden werden und eine Variante wird zur Fernauthentifizierungszwecken auf das Netzwerk gesendet. Zu beachten ist dabei, dass es nun möglich ist, zu vermeiden, dass der LM Hash in einem reinem NT Umfeld auf das Netzwerk gesendet wird (d.h. keine Win 95 Systeme oder andere Hinterlassenschaften).
  • Der LM Hash wird durch die Begrenzung des Passwortes des Benutzers zu 14 Zeichen generiert, wobei es mit Nullen aufgefüllt wird, wenn es kürzer ist, alle Zeichen zu ASCII Grossbuchstaben umgewandelt werden, alle 14 Zeichen in zwei 7 Byteblocks aufgeteilt werden, jeder 7 Byteblock zu einem paritätischen 8 Byte DES Schlüssel ausgeweitet wird und mit jedem der zwei Schlüssel eine bekannte Zeichenfolge DES ECB verschlüsselt wird und die Ergebnisse verbunden werden.
  • 4.2.4.2 – MD4-NT hash in Windows NT
  • Der MD4-NT Hash (oft auch NT Hash genannt) wird durch die Aufnahme von bis zu 128 Zeichen (in der Praxis ist das NT Passwort durch das GUI auf 14 Zeichen beschränkt) des Benutzerpasswortes erzeugt, dieses wird in einen Unicode umgewandelt (ein Zeichenset von zwei Bytes, welches oft in NT verwendet wird) und der MD4 Hash der Zeichenkette, welche den so genannten „NT Passwort Hash" produziert, wird verwendet; sie werden in der SAM Datenbank gespeichert.
  • 4.2.4.3 Integration mit Chipkarte
  • Die Klartext NT Passwort Authentifizierung ist vom Typ Auth1.
  • Die NTLM und LanMan Authentifizierung sind beide vom Typ Auth6, auch wenn der LM Hash keine reine Hashfunktion verwendet.
  • 24 illustriert einen Austauschdialog für eine NT Authentifizierung, die mit einer Chipkarte 17 durchgeführt wird. Während der Verhandlungen wird der Typ der NT Authentifizierung durch das Modul zum einzigen Einloggen auf der Klientenseite abgefragt (Pfeil 334). Wenn verschlüsselte Passwörter verwendet werden, sendet der Primary Domain Controller 13 einen Challenge zu dem Module zum einzigen Einloggen (Pfeil 335). Dieser Challenge wird zu der Chipkarte 17 weitergeleitet (Pfeil 331), welche ihn verschlüsselt, wobei ein LM Hash oder ein NT Hash als Schlüssel verwendet wird. Diese Hash werden von dem NT Klartextpasswort, welches in dem EEPROM der Chipkarte gespeichert ist, unter Verwendung von Transformationsfunktionen abgeleitet. Die Chipkarte antwortet mit einem Klartextpasswort (Pfeil 332) oder mit einem verschlüsselten Passwort (Pfeil 333), welches durch das Modul 13 zum einzigen Einloggen zu dem PDC weitergeleitet wird (Pfeil 336). Der Primary Domain Controller überprüft das Passwort und antwortet mit einem Erfolgs- oder Fehlermeldungspaket (Pfeil 337).
  • 4.2.4.4 Einfache Integration für NT
  • In den vorhergehenden Paragraphen haben wir gesehen, wie die NT Authentifizierung mit einer Chipkarte dem allgemeinen Prinzip folgend, wie es oben beschrieben wurde, integriert wird. Aus verschiedenen Gründen könnte eine einfachere Integration vernünftig sein. Erstens benötigt die NT Authentifizierung, wie oben beschrieben, eine Veränderung des Betriebssystems. Das könnte nicht einfach und nicht zu empfehlen sein. Zusätzlich könnte die NT Authentifizierung zu viel Platz in dem Chipkartenspeicher benötigen. Schlussendlich ist der Authentifizierungsmechanismus von Windows 2000 anders als der von NT. Das Update von Windows 2000 und der folgenden Betriebssysteme ist leichter auf einem Computer durchzuführen als auf einer Chipkarte.
  • Daher ist es mindestens in einer ersten Phase empfohlen, die NT Authentifizierung auf einem Laptop zu halten und nur das NT Passwort auf der Chipkarte zu speichern. In diesem Fall dient die Chipkarte nur als sicherer Speicherort für das NT Passwort und jedes Mal, wenn eine NT Authentifizierung benötigt wird, gibt die Chipkarte das NT Passwort durch das Modul zum einzigen Einloggen zu dem OS (Win NT oder Win95), vorausgesetzt, dass sich die Chipkarte in einem aktiven Status befindet (d.h. eingeschaltet und ein korrekter Aktivierungs-PIN/Passwort wurde eingegeben).
  • 4.3 Zusammenfassung einer Chipkartenintegration mit GSM, PPP, IPSEC, NT
  • 16a illustriert, wie eine Verbindung zwischen einem Laptop 2 und einem Fernort 28 durch die aufeinander folgende Konstruktion der kumuliert übereinander gelegten Netzwerkschichten etabliert werden kann. Der Laptop etabliert zuerst eine GSM Verbindung mit einem Internetserviceprovider 12 mit einem mobilen Gerät 4 unter Verwendung einer SIM-Karte 40, eines öffentlichen Mobilfunknetz 6, eines Heimatregisters 8 in dem PLMN und eines Routers 10, welcher mit dem HLR verbunden ist. Die nächste PPP-Schicht wird konstruiert durch die Authentifizierung des Benutzers 2 in dem ISP, was durch das Internet 14 oder einem Firewall 16 Zugriff auf das Firmennetzwerk des Benutzers erlaubt. Wenn der Benutzer diesem Firewall authentifiziert werden kann, könnte die nächste IPSEC Schicht konstruiert werden, so dass der Benutzer auf den angeforderten Domain in dem Server 26 zugreifen kann. Eine Domainauthentifizierung wird in diesem Server durchgeführt, um die letzte Protokollschicht aufzubauen, welche dem Benutzer erlaubt, auf die angeforderten Dateien in dem Fernserver 28 zuzugreifen.
  • Die Tabelle unten fasst die Chipkartenintegration mit GSM, PPP, IPSEC und NT zusammen:
  • Figure 00330001
  • Diese Tabelle fasst zusammen, was in einer Chipkarte implementiert werden sollte, um die Authentifizierungen für die verschiedenen involvierten Schichten, nämlich GSM, PPP, IPSEC und NT, zu realisieren. Schlüssel und Passworte sollten in dem EEPROM der Chipkarte gespeichert werden. Für verschiedene kryptographische Algorithmen kann man folgenden Richtlinien folgen: symmetrische Algorithmen sollten in einem ROM kodiert werden; für asymmetrische Algorithmen sollte ein fest zugeordneter kryptographischer Koprozessor in der Chipkarte vorhanden sein.
  • Es ist daher offensichtlich, dass bevor irgendeine Authentifizierung stattfinden kann, die Chipkarte in einem aktiven Status sein sollte, d.h. der Benutzer sollte das richtige Geheimnis eingeben (PIN/Passwort/biometrische Daten).
  • GSM Chipkarten (genannt SIM-Karten) existieren bereits. Die korrespondierende SIM Software wird wieder verwendet, da sie in der Chipkarte vorhanden ist, die in dem System zum einzigen Einloggen integriert ist.
  • Wie bereits beschrieben, haben wir Telefonkartengeräte, die SIM Karten integrieren, und die in einen PC Steckplatz als Standard-PC-Karte gesteckt werden kann. Es wird empfohlen, dasselbe Telefonkartengerät zu verwenden, um darin anstelle der SIM Karte die Chipkarte zum einzigen Einloggen einzusetzen.
  • 4.4 – Direkte interner Zugriff und Kompatibilität mit Fernzugriff
  • In dem vorhergehenden Paragraph haben wir gesehen, wie ein einziges Login für die Authentifizierung von jeder betroffenen Schicht (GSM, PPP, IPSEC, NT) implementiert wird.
  • Wir werden nun die Verbesserungen, zu dem was vorher präsentiert wurde, erklären.
  • 4.4.1 – Problembeschreibung
  • In den beschriebenen Fernzugriffsservice berücksichtigen wir mobile Benutzer mit einem Laptop, die auf ihr Firmennetzwerk aus der Ferne zugreifen. Es ist aber wahrscheinlich, dass sie ihren Laptop auch verwenden, wenn sie in ihrem Büro sind. Mit der wachsenden Anzahl von Dockstationen können Benutzer leicht ihren Laptop als ihren normalen Bürocomputer, der direkt mit ihrem internen Firmennetzwerk verbunden ist, verwenden. In dieser Situation gibt es kein Bedürfnis mehr, ein Telefonkartengerät zu haben, und die Benutzer müssen sich nur in ihr NT Domain einloggen. Um dies zu tun werden sie ihr NT Passwort verwenden müssen. Es ist jedoch in der gegebenen Beschreibung gesagt, dass der Benutzer nur das Geheimnis, welches die Chipkarte aktiviert, erinnern muss, und dann alle Authentifizierungen fortgeführt werden. In diesem Fall, in dem die Benutzer auch ihren Laptop direkt als interne Maschine verwenden wollen (nur NT Login), müssen sie ein zweites Geheimnis, nämlich das NT Passwort, zusätzlich zum Chipkartengeheimnis erinnern.
  • In dem System zum einzigen Einloggen wollen wir mehr als ein Geheimnis, welches zu erinnern ist, vermeiden.
  • Die einfache Lösung ist, das NT Passwort zu dem Passwort zu machen, welches die Chipkarte aktiviert. Deshalb kann dasselbe Geheimnis für beide Zugänge, den Fernzugang zum einzigen Einloggen und als Login für das NT Domain, verwendet werden.
  • Unglücklicherweise tauchen mit einer solchen Lösung andere Anliegen auf. Wenn die Benutzer ihr NT Passwort austauschen, wenn sie direkt zu ihrem internen Netzwerk verbunden sind, kann dieses neue Passwort nicht zur selben Zeit in der Chipkarte upgedated werden (weil das Kartentelefongerät, welches die Chipkarte enthält, nicht in den PC Steckplatz eingesteckt ist). Das nächste Mal, wenn die Benutzer sich auf ihr Netzwerk aus der Ferne einloggen wollen, wird das NT Passwort, welches in dem DC gespeichert ist, mit dem NT Passwort, welches in der Chipkarte gespeichert ist, desynchronisiert. Ein geschütztes Mechnanismus soll implementiert werden, um die Geheimnissynchronisation zu versichern.
  • 4.4.2 Lösung: Geheimnissynchronisation
  • Das Prinzip für die Geheimnissynchronisation ist das folgende:
    Wenn ein Benutzer direkt mit dem internen Netzwerk verbunden ist, werden das alte und das neue NT Passwort (Geheimnisse) verbunden und mit dem öffentlichen Synchronisationsschlüssel, welcher in dem PC gespeichert ist, verschlüsselt. Das nächste Mal, wenn sich der Benutzer von der Ferne aus einloggt, werden die zwei verschlüsselten Geheimnisse zu der Chipkarte 17 übermittelt, welche sie unter Verwendung des korrespondierenden privaten Synchronisationsschlüssels der Chipkarte entschlüsselt. Danach wird das alte Geheimnis mit demjenigen, welches in der Chipkarte gespeichert ist, verglichen und das neue wird mit demjenigen, welches von dem Benutzer eingegeben wurde, verglichen. Wenn beide Ergebnisse korrekt sind, dann wird das Geheimnis in der Chipkarte upgedated und der Aufbau der Schichten kann normal fortgeführt werden.
  • Die Vorgehensweise für die Geheimnissynchronisation ist in der 25 und in der 26 dargestellt und wird detailliert hiernach erläutert.
  • Nach dem Aufstarten 350 startet das Modul 13 zum einzigen Einloggen des Laptops das Login GUI (351). Das Modul zum einzigen Einloggen detektiert, dass keine Chipkarte vorhanden ist (362) (d.h. dass das Kartentelefongerät nicht in dem PC Steckplatz eingesteckt ist) und bereitet sich selbst für die Geheimnissynchronisation vor. Wenn der Benutzer sein/ihr NT Geheimnis eintippt (352), behält das Modul zum einzigen Einloggen das NT Geheimnis in dem RAM des Laptops (361). Parallel dazu fährt das normale NT Domain Login fort (353). Wenn das NT Domain Geheimnis, welches vorher von dem Benutzer eingegeben wurde, nicht korrekt ist (Test 354), löscht das Modul zum einzigen Einloggen das gespeicherte Geheimnis in dem RAM (362) und startet noch einmal bei 351. Zu beachten ist dabei, dass die Anzahl der möglichen Versuche für NT Geheimnisse allgemein von der Passwortpolitik bestimmt wird. Wenn das von dem Benutzer eingegebene Passwort korrekt ist, d.h. die NT Domain Authentifizierung erfolgreich ist, dann kann der Benutzer beantragen, sein/ihr Geheimnis zu ändern (Test 355). Zu beachten ist, dass dieser Antrag zum automatischen Antrag des Geheimnisaustauschs allgemein in der Passwortpolitik definiert ist. Wenn kein Antrag auf einen Geheimnisaustausch benötigt wird, wird das NT Geheimnis, welches in dem RAM vorhanden ist, von diesem Speicher gelöscht (363). Anderenfalls muss der Benutzer sein neues Geheimnis (356) eingeben. Das Modul zum einzigen Einloggen fängt dieses neue Geheimnis ab und verbindet es mit dem alten, vorher in dem RAM gehaltenen (365). Diese beiden Geheimnisse werden dann mit einem öffentlichen Schlüssel (365) verschlüsselt. Dieser öffentliche Schlüssel wird weiter als öffentlicher Synchronisationsschlüssel bezeichnet.
  • Das Synchronisationsschlüsselpaar ist ein Paar von kryptographischen Schlüsseln, welche in einem asymmetrischen Verschlüsselungsalgorithmus verwendet werden. Beispiele von asymmetrischen Verschlüsselungsalgorithmen enthalten RSA, ECC, etc. Der private Synchronisationsschlüssel soll nur in einem EEPROM der Chipkarte gespeichert werden und es soll niemals möglich sein, ihn auszulesen. Eine Kopie von dem öffentlichen Synchronisationsschlüssel sollte auf der Harddisk des Laptops gespeichert werden. Es ist zu empfehlen, eine ausreichend grosse Schlüssellänge zu haben. Wenn zum Beispiel RSA verwendet wird, ist es sehr zu empfehlen, eine Länge von mindestens 1024 Bits zu haben. Für andere Algorithmen sollen vergleichbare Stärken verwendet werden.
  • Wenn die zwei verbundenen NT Geheimnisse verschlüsselt sind, können optionale Felder zu den Geheimnissen hinzugefügt werden. Informationen wie Datum und Zeit können eingefügt werden; eine Sequenznummer und/oder eine zufällige Nummer können ebenfalls eingebettet werden. Diese Parameter können die Sicherheit erhöhen, in dem Sinne, dass sie die in der Zeit einzigartige geheime Verschlüsselung wiedergeben. Obwohl Wiederholungsattacken schwierig zu realisieren sind und es unwahrscheinlich ist, dass sie Erfolg haben, verhindern solche Massnahmen diese Attacken.
  • Das verschlüsselte Ergebnis wird zuerst in dem RAM des Laptops gespeichert (366). Wenn aus irgendeinem Grund (Test 358) das NT Geheimnisaustauschverfahren (359) fehlschlägt, wird das RAM gelöscht, andernfalls wird das Ergebnis (2 verschlüsselte Passwörter) in einer Datei auf der Harddisk des Laptops gespeichert (367). Geeignete Mittel sollten angewendet werden, um minimale Zugangserlaubnisse zu dieser Datei zu setzen. Schlussendlich kann ein optionaler desychronisierter Statusflag (Schritt 367) gesetzt werden, um der Chipkarte weiter anzuzeigen, dass die zwei Geheimnisse desychronisiert wurden.
  • Es muss beachtet werden, dass wir in dem ganzen oben beschriebenen Prozess angenommen haben, dass der NT Domain Geheimnisaustausch von dem Betriebssystem beantragt wurde. Es ist offensichtlich, dass der Geheimnisaustausch vom Benutzer initiiert werden kann, ausser dass das Modul zum einzigen Einloggen die zwei Passwörter zur selben Zeit aufnimmt (weil Benutzer wieder ihr altes Geheimnis zusätzlich zum neuen eingeben müssen, wenn sie eine Änderung machen wollen).
  • Der zweite Teil der Geheimnissynchronisierung wird realisiert, wenn der Benutzer seinen/ihren Laptop in einem Fernzugang mit der Chipkarte verwendet. Dieses Verfahren ist in 26 beschrieben und die Details werden hiernach erläutert.
  • Nachdem der Computer komplett hochgefahren wurde (380), startet das Modul zum einzigen Einloggen das graphische Benutzerinterface (381), damit sich der Benutzer einloggen kann. Der Benutzer gibt in seinem/ihren NT Domain das Geheimnis und den Namen (382) ein. In der Zwischenzeit detektiert das Modul zum einzigen Einloggen die Anwesenheit der SIM Karte in dem Computersteckplatz (383). Das Modul zum einzigen Einloggen überprüft dann den desynchronisierten Status (384). Wenn keine Desynchronisation vorhanden ist, bedeutet dies, dass das das NT Geheimnis, welches in der Chipkarte gespeichert ist, und der Hash von dem gespeicherten NT Geheimnis, gespeichert in dem Betriebssystem, übereinstimmen. In diesem Fall kann die Authentifizierung und der Schichtaufbau fortfahren (385), wie oben beschrieben.
  • Wenn wir einen desynchronisierten Status haben, startet das Modul zum einzigen Einloggen, um die Geheimnisse zu re-synchronisieren. Es sendet an die Chipkarte die verschlüsselte Information, welche die zwei Geheimnisse plus die optionale Information (386) enthält. Es leitet zu der Chipkarte auch das gerade eingetippte Geheimnis des Benutzers (387) weiter. Die Chipkarte entschlüsselt die Information (388) unter Verwendung seines privaten Synchronisationsschlüssels, der in dem EEPROM gespeichert ist. Die Chipkarte kann dann das alte (391) und das neue Geheimnis (389) als auch die optionale Information (393) extrahieren. Drei Bedingungen sollten erfüllt sein, um mit der Synchronisation fortzufahren: das alte NT Geheimnis, welches aus den verschlüsselten Daten extrahiert wurde, muss dasselbe sein, wie das vorher in der Chipkarte gespeicherte (Test 392); das neue NT Geheimnis, welches aus den verschlüsselten Daten extrahiert wurde, muss dasselbe sein, wie das gerade von dem Benutzer eingetippte (Test 390), schliesslich müssen die optionalen Felder korrekt sein (Test 394). Wenn wir zum Beispiel eine Sequenznummer in den optionalen Feldern haben, muss die Sequenznummer, die aus den verschlüsselten Daten extrahiert wurde, grösser sein als die vorher in der Chipkarte gespeicherte. Wenn und nur wenn alle diese Bedingungen erfüllt sind, dann kann die Chipkarte das Geheimnis in seinem EEPROM mit dem neuen (395) updaten. Zusätzlich müssen auch die optionalen Felder upgedated werden. Wenn eine der oben genannten Bedingungen nicht erfüllt wird, dann soll die Synchronisation aufhören, d.h. dass kein Geheimnisupdate erscheinen soll. Zusätzlich sollten die Chipkarte und das Modul zum einzigen Einloggen nicht mit dem Schichtaufbau und der korrespondierenden Authentifizierung fortfahren, wie sie weiter oben beschrieben wurde.
  • Anderenfalls informiert die Chip-Karte das Modul zum einzigen Einloggen, dass das Geheimnis erfolgreich upgedated wurde. Das Modul zum einzigen Einloggen löscht die Datei mit den verschlüsselten Daten (die zwei Geheimnisse und die optionalen Felder), und setzt seinen Desynchronisationsstatus (396) zurück. Schliesslich können die Authentifizierung und die Konstruktion der Schichten, wie oben beschrieben wurde, durchgeführt werden (397).
  • Der Fachmann wird erkennen, dass das Verfahren zur Synchronisation verwendet werden kann, um irgendwelche Geheimnise zwischen irgendeinem Paar oder Fernorten in einem Telekommunikationsnetzwerk zu synchronisieren, unabhängig von dem beschriebenen Verfahren zum einzigen Einloggen.
  • 4.5 Transparente Schichtkonstruktion
  • Es ist wahrscheinlich, dass GSM Kommunikation abgeschnitten werden kann. Das Modul zum einzigen Einloggen sollte die Schicht ohne Benutzerintervention wieder aufbauen können, vorausgesetzt, dass der Benutzer das Terminal, welches die Chip-Karte enthält, nicht vom dem PC Steckplatz entfernt hat.

Claims (27)

  1. Verfahren zum einzigen Einloggen, um einen mobilen Benutzer einen Fernzugang zu einem Fernort (10, 207, 209) in einem Firmennetzwerk durch ein öffentliches Mobilfunknetz (6) und durch das Internet (201) mit einem mobilen Gerät (22, 24, 210) zu erlauben, wobei eine Chipkarte (17) benutzt wird, wobei das Verfahren die folgenden Schritte umfasst: (j) Senden eines ersten Authentikators zu dem besagten öffentlichen Mobilfunknetz (6), (k) Verifizierung in dem besagten öffentlichen Mobilfunknetz (6) des besagten ersten Authentikators, der von dem mobilen Gerät (22, 24, 210) gesendet wird, (l) wenn der besagte erste Authentikator von dem gesagten öffentlichen Mobilfunknetz (6) akzeptiert wird, wird die Kommunikationsschicht zwischen dem besagten mobilen Gerät (22, 24, 210) und dem besagten öffentlichen Mobilfunknetz (6) vervollständigt, (m) Senden eines zweiten Authentikators über besagtes öffentliches Mobilfunknetz (6) zu einem Internet Service Provider (12), (n) Verifizierung des besagten zweiten Authentikators, welcher von dem besagten mobilen Gerät (22, 24, 210) gesendet wurde, in dem besagten Internet Service Provider (12), (o) wenn der besagte zweite Authentikator von dem besagten Internet Service Provider (12) akzeptiert wird, wird die Kommunikationsschicht zwischen dem besagten mobilen Gerät (22, 24, 210) und dem Internet vervollständigt, (p) Senden eines Dritten Authentikators über das öffentliche Mobilfunknetz (6) und das Internet (201) zu besagten Firmennetzwerk, (q) Verifizierung des besagten dritten Authentikators, welcher von dem besagten mobilen Gerät (22, 24, 210) gesendet wurde, in besagten Firmennetzwerk, (r) wenn der besagte dritte Authentikator von dem besagten Netzwerk akzeptiert wird, wird die Kommunikationsschicht zwischen dem besagten mobilen Gerät (22, 24, 210) und dem besagten Fernort (10, 207, 209) vervollständigt, dadurch gekennzeichnet, dass besagte erste, zweite und dritte Authentikatoren von der Chipkarte (17) zu einem Single Sign-On Software- Modul (13) auf der Seite des Benutzers geliefert werden, welches sie dann zu dem öffentlichen Mobilfunknetz (6), zu dem Internet Service Provider (12) oder zu einem Firewall (210, 16) des besagten Firmennetzwerkes sendet.
  2. Verfahren zum einzigen Einloggen gemäss Anspruch 1, in dem das besagte öffentliche Mobilfunknetz (6) und/oder der besagte Internetservice Provider (12) und/oder besagtes Firmennetzwerk die Überprüfung von dem korrespondierenden Authentikator zu einem dritten Gerät delegiert.
  3. Verfahren zum einzigen Einloggen gemäss einem der Ansprüche 1 oder 2, in dem das besagte Single Sign-On Software-Modul (13) anfänglich dem besagten Benutzer (10, 207, 209) in einer Meldung auffordert, sein Geheimnis einzugeben, und in welchem der besagte erste Authentikator nur gesendet wird, wenn das Geheimnis, welches von dem Benutzer eingegeben wurde, korrekt ist.
  4. Verfahren zum einzigen Einloggen gemäss Anspruch 3, in dem das besagte Geheimnis in der besagten Chipkarte (17) verifiziert wird.
  5. Verfahren zum einzigen Einloggen gemäss Anspruch 4, in dem das besagte Geheimnis dasselbe ist, wie das Geheimnis, welches zur Domain-Authentifizierung in dem besagten Fernort verlangt wird.
  6. Verfahren zum einzigen Einloggen gemäss Anspruch 1, in dem das besagte mobile Gerät (22, 24, 210) ein zellulares Telefongerät (24) umfasst.
  7. Verfahren zum einzigen Einloggen gemäss Anspruch 6, in dem die besagte Chipkarte (17) eine SIM-Karte ist.
  8. Verfahren zum einzigen Einloggen gemäss einem der Ansprüche 6 oder 7, in dem die besagte Chipkarte (17) eine WIM-Karte ist.
  9. Verfahren zum einzigen Einloggen gemäss einem der vorangegangenen Ansprüche, in dem mindestens einer der besagten ersten, zweiten und dritten Authentikatoren in der besagten Chipkarte (17) gespeichert ist.
  10. Verfahren zum einzigen Einloggen gemäss einem der vorangegangenen Ansprüche, in dem mindestens einer der besagten ersten, zweiten und dritten Authentikatoren in der besagten Chipkarte (17) berechnet wird.
  11. Verfahren zum einzigen Einloggen gemäss dem vorangegangenen Anspruch, in dem mindestens einer der besagten ersten, zweiten und dritten Authentikatoren in der besagten Chipkarte (17) unter Verwendung einer kryptographischen Funktion mit mindestens einem Schlüssel berechnet wird.
  12. Verfahren zum einzigen Einloggen gemäss dem vorangegangenen Anspruch, in dem die besagte kryptographische Funktion einen symmetrischen Algorithmus verwendet.
  13. Verfahren zum einzigen Einloggen gemäss dem Anspruch 11, in dem die besagte kryptographische Funktion einen asymmetrischen Algorithmus verwendet.
  14. Verfahren zum einzigen Einloggen gemäss einem der Ansprüche 11 bis 13, in dem der besagte mindestens eine Schlüssel in der besagten Chipkarte (17) gespeichert wird.
  15. Verfahren zum einzigen Einloggen gemäss einem der vorangegangenen Ansprüche, weiter umfassend die Schritte Senden des besagten dritten Authentikators zu einem IPSEC Gateways, Überprüfen der Identität des besagten Benutzers (10, 207, 209) mit dem besagten dritten Authentikator, welcher von dem mobilen Gerät (22, 24, 210) gesendet wurde, in dem besagten IPSEC Gateways, wenn der besagte dritte Authentikator von dem besagten IPSEC Gateway akzeptiert wird, wird dem mobilen Gerät (22, 24, 210) Zugang zu dem Fernort (10, 207, 209) gewährt.
  16. Verfahren zum einzigen Einloggen gemäss einem der vorangegangenen Ansprüche, in dem mindestens einer der besagten ersten, zweiten und dritten Authentikatoren von dem besagten Fernort verwendet wird, um die Identität des besagten Benutzers (10, 207, 209) zu verifizieren und ihm Zugang zu einen Fernfirmennetzwerk zu gewähren.
  17. Verfahren zum einzigen Einloggen gemäss einem der vorangegangenen Ansprüche, weiter umfassend die Schritte Ersetzen eines Geheimnisses, welches verlangt wird, um den besagten Fernort Zugang zu erhalten, mit einem neuen Geheimnis in dem besagten Fernort, Verbindung und Verschlüsseln des alten und neuen Geheimnisses mit einem öffentlichen Synchronisationsschlüssel des besagten mobilen Geräts (22, 24, 210) in dem besagten Fernort, Eingabe des neuen Geheimnisses in das besagte mobile Gerät (22, 24, 210), Übermitteln der verbundenen und verschlüsselten alten und neuen Geheimnisse zu dem besagten mobilen Geräts (22, 24, 210), Entschlüsseln des besagten alten und neuen Geheimnisses mit einem privaten Synchronisationsschlüssel des besagten mobilen Geräts (22, 24, 210), welcher zu dem öffentlichen Synchronisationsschlüssel korrespondiert, Vergleichen des besagten alten entschlüsselten Geheimnisses mit dem Geheimnis, welches in dem besagten mobilen Gerät (22, 24, 210) gespeichert ist, und Vergleichen des neuen entschlüsselten Geheimnisses mit dem besagten Geheimnis, welches in das besagte mobile Gerät (22, 24, 210) eingegeben wurde, wenn beide Vergleiche positiv sind, Ersetzen des Geheimnisses, welches in dem mobilen Gerät (22, 24, 210) gespeichert ist, mit dem besagten entschlüsselten neuen Geheimnis, anderenfalls Verweigern des Ersetzens des Geheimnisses.
  18. Chipkarte (17) zum Gebrauch in einem Verfahren zum einzigen Einloggen gemäss einem der Ansprüche 1 bis 17, besagte Chipkarte (17) ist derart angepasst, um einen Benutzer (10, 207, 209) eines mobilen Geräts (22, 24, 210) zu authentifizieren, um einen Fernzugang zu einem Fernort in einem Firmennetzwerk durch ein öffentliches mobiles Netzwerk (6) und durch das Internet (201) zu gewähren, besagte Chipkarte (17) ist gekennzeichnet durch Verfahrensmittel, um eine Vielzahl von verschiedenen Algorithmen oder Funktionen zur Berechnung und/oder Auslieferung eines ersten Authentifikators, um den besagten Benutzer (10, 207, 209) in dem besagten öffentlichen Mobilfunknetz (6) zu authentifizieren, eines zweiten Authentifikators, um den besagten Benutzer (10, 207, 209) bei einem Internet Service Provider zu authentifizieren und eines dritten Authentifikators, um den besagten Benutzer (10, 207, 209) bei besagtem Firmennetzwerk zu authentifizieren, wobei eine Vielzahl von verschiedenen Authentifizierungsmechanismen verwendet werden.
  19. Chipkarte (17) gemäss Anspruch 18, in der das besagte Mobile Gerät (22, 24, 210) ein zellulares Telefongerät (24) umfasst.
  20. Chipkarte (17) gemäss Anspruch 19, in der die besagte Chipkarte (17) eine SIM-Karte ist.
  21. Chipkarte (17) gemäss einem der Ansprüche 18 bis 20, in der mindestens einer der besagten ersten, zweiten und dritten Authentikatoren in der besagten Chipkarte (17) gespeichert ist.
  22. Chipkarte (17) gemäss einem der Ansprüche 18 bis 21, in der mindestens einer der besagten ersten, zweiten und dritten Authentikatoren in der besagten Chipkarte (17) berechnet wird.
  23. Chipkarte (17) gemäss dem vorhergegangen Anspruch, in der mindestens einer der besagten ersten, zweiten und dritten Authentikatoren in der besagten Chipkarte (17) unter Verwendung einer kryptographischen Funktion mit mindestens einem Schlüssel berechnet wird.
  24. Chipkarte (17) gemäss dem vorhergegangen Anspruch, in der der besagte mindestens eine Schlüssel in der besagten Chipkarte (17) gespeichert wird.
  25. Chipkarte (17) gemäss einem der Ansprüche 18 bis 24, in der besagter dritte Authentikator von einem IPSEC Gateway zur Verifizierung der Identität des besagten Benutzers (10, 207, 209) verwendet werden und ihm Zugang zu einem Firmennetzwerk gewähren kann.
  26. Chipkarte (17) gemäss einem der Ansprüche 18 bis 25, weiter umfassend einen Authentikator, der von dem Fernort in einem Firmennetzwerk verwendet werden kann, um die Identität des Benutzers (10, 207, 209) zu verifizieren und ihm Zugang zu einem Ferndomain zu gewähren.
  27. Chipkarte (17) gemäss einem der Ansprüche 18 bis 26, weiter umfassend einen privaten Synchronisationsschlüssel, um ein altes und ein neues Geheimnis, welches mit einem korrespondierenden öffentlichen Schlüssel verschlüsselt wurde, zu entschlüsseln, Vergleichsmittel, um besagtes altes verschlüsseltes Geheimnis mit dem Geheimnis, welches in dem mobilen Gerät (22, 24, 210) gespeichert ist, und um besagtes verschlüsseltes neues Geheimnis mit einem neuen Geheimnis, welches in das besagte mobile Gerät (22, 24, 210) eingegeben wurde, zu vergleichen, Mittel, um das in dem mobile Gerät (22, 24, 210) gespeicherte Geheimnis mit dem besagten verschlüsselten neuen Geheimnis zu ersetzen, wenn beide Vergleiche positiv sind.
DE2000624319 2000-02-08 2000-08-16 Vereinter einloggungsprozess Expired - Lifetime DE60024319T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US18109000P 2000-02-08 2000-02-08
US181090P 2000-02-08
PCT/CH2000/000438 WO2001060013A1 (en) 2000-02-08 2000-08-16 Single sign-on process

Publications (2)

Publication Number Publication Date
DE60024319D1 DE60024319D1 (de) 2005-12-29
DE60024319T2 true DE60024319T2 (de) 2006-08-03

Family

ID=22662861

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2000624319 Expired - Lifetime DE60024319T2 (de) 2000-02-08 2000-08-16 Vereinter einloggungsprozess

Country Status (6)

Country Link
US (3) US7058180B2 (de)
EP (1) EP1254547B1 (de)
AT (1) ATE311063T1 (de)
AU (1) AU2000264222A1 (de)
DE (1) DE60024319T2 (de)
WO (1) WO2001060013A1 (de)

Families Citing this family (166)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE311063T1 (de) * 2000-02-08 2005-12-15 Swisscom Mobile Ag Vereinter einloggungsprozess
US6996718B1 (en) * 2000-04-21 2006-02-07 At&T Corp. System and method for providing access to multiple user accounts via a common password
FR2810481B1 (fr) * 2000-06-20 2003-04-04 Gemplus Card Int Controle d'acces a un moyen de traitement de donnees
FI20002899A0 (fi) * 2000-12-29 2000-12-29 Nokia Corp Järjestely informaation kommunikoimiseksi
US7509322B2 (en) 2001-01-11 2009-03-24 F5 Networks, Inc. Aggregated lock management for locking aggregated files in a switched file system
US20040133606A1 (en) 2003-01-02 2004-07-08 Z-Force Communications, Inc. Directory aggregation for files distributed over a plurality of servers in a switched file system
US20020095573A1 (en) * 2001-01-16 2002-07-18 O'brien William G. Method and apparatus for authenticated dial-up access to command controllable equipment
US20020194501A1 (en) * 2001-02-25 2002-12-19 Storymail, Inc. System and method for conducting a secure interactive communication session
US7243370B2 (en) * 2001-06-14 2007-07-10 Microsoft Corporation Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication
US7389412B2 (en) * 2001-08-10 2008-06-17 Interactive Technology Limited Of Hk System and method for secure network roaming
US7111323B1 (en) * 2001-08-31 2006-09-19 Oracle International Corporation Method and apparatus to facilitate a global timeout in a distributed computing environment
US7249261B2 (en) 2001-10-16 2007-07-24 Activcard Ireland Limited Method for securely supporting password change
US7000109B2 (en) * 2001-11-21 2006-02-14 Intel Corporation Method and apparatus for unlocking a computer system hard drive
US7221935B2 (en) 2002-02-28 2007-05-22 Telefonaktiebolaget Lm Ericsson (Publ) System, method and apparatus for federated single sign-on services
US7240366B2 (en) * 2002-05-17 2007-07-03 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
KR101001223B1 (ko) 2002-05-29 2010-12-15 소니 가부시키가이샤 정보 처리 시스템 및 방법, 정보 제공 시스템 및 방법, 정보 처리 장치 및 방법, 인형, 오브젝트, 프로그램 격납 매체 및 프로그램
TW588243B (en) * 2002-07-31 2004-05-21 Trek 2000 Int Ltd System and method for authentication
CN100432979C (zh) * 2002-08-05 2008-11-12 台均实业股份有限公司 跨网络统一用户注册信息的方法
US7600118B2 (en) * 2002-09-27 2009-10-06 Intel Corporation Method and apparatus for augmenting authentication in a cryptographic system
DE10249801B3 (de) * 2002-10-24 2004-05-06 Giesecke & Devrient Gmbh Verfahren zum Ausführen einer gesicherten elektronischen Transaktion unter Verwendung eines tragbaren Datenträgers
US7315946B1 (en) 2003-04-14 2008-01-01 Aol Llc Out-of-band tokens for rights access
US7647277B1 (en) 2002-10-25 2010-01-12 Time Warner Inc. Regulating access to content using a multitiered rule base
US7373658B1 (en) * 2002-10-25 2008-05-13 Aol Llc Electronic loose-leaf remote control for enabling access to content from a media player
JP4676703B2 (ja) * 2003-03-20 2011-04-27 株式会社リコー ユーザ認証装置、ユーザ認証方法、ユーザ認証プログラム及び記録媒体
US8676249B2 (en) * 2003-05-19 2014-03-18 Tahnk Wireless Co., Llc Apparatus and method for increased security of wireless transactions
US9959544B2 (en) * 2003-05-22 2018-05-01 International Business Machines Corporation Updating an application on a smart card and displaying an advertisement
US20040267870A1 (en) * 2003-06-26 2004-12-30 Rozmus John Michael Method of single sign-on emphasizing privacy and minimal user maintenance
CN1601958B (zh) * 2003-09-26 2010-05-12 北京三星通信技术研究有限公司 基于cave算法的hrpd网络接入认证方法
US7930412B2 (en) * 2003-09-30 2011-04-19 Bce Inc. System and method for secure access
US20050096048A1 (en) * 2003-10-30 2005-05-05 Cellco Partnership Optimized network employing seamless and single sign on capabilities for users accessing data applications on different networks
US7631344B2 (en) * 2003-11-04 2009-12-08 Alcatel Lucent Distributed authentication framework stack
US7546357B2 (en) * 2004-01-07 2009-06-09 Microsoft Corporation Configuring network settings using portable storage media
US7606918B2 (en) * 2004-04-27 2009-10-20 Microsoft Corporation Account creation via a mobile device
ATE388570T1 (de) * 2004-05-19 2008-03-15 Alcatel Lucent Verfahren zur bereitstellung eines signierungsschlüssels zur digitalen signierung, überprüfung oder verschlüsselung von daten
EP1601154A1 (de) * 2004-05-28 2005-11-30 Sap Ag Kundenauthentifizierung mittels eines Challenge-Anbieters
US7194763B2 (en) * 2004-08-02 2007-03-20 Cisco Technology, Inc. Method and apparatus for determining authentication capabilities
US7698734B2 (en) * 2004-08-23 2010-04-13 International Business Machines Corporation Single sign-on (SSO) for non-SSO-compliant applications
US20060059341A1 (en) * 2004-09-14 2006-03-16 Dharmadhikari Abhay A Apparatus and method capable of network access
EP1638264A1 (de) * 2004-09-15 2006-03-22 Axalto S.A. USB Adapter für drahtloses Netz mit Smartcard
US7721328B2 (en) * 2004-10-01 2010-05-18 Salesforce.Com Inc. Application identity design
US7941671B2 (en) * 2004-10-14 2011-05-10 Oracle International Corporation Method and apparatus for accommodating multiple verifier types with limited storage space
CN101076807B (zh) * 2004-10-15 2014-09-03 弗里塞恩公司 一次性密码验证的方法和系统
CA2571814C (en) * 2004-12-30 2012-06-19 Bce Inc. System and method for secure access
US7885970B2 (en) 2005-01-20 2011-02-08 F5 Networks, Inc. Scalable system for partitioning and accessing metadata over multiple servers
DE102005004902A1 (de) * 2005-02-02 2006-08-10 Utimaco Safeware Ag Verfahren zur Anmeldung eines Nutzers an einem Computersystem
US7958347B1 (en) * 2005-02-04 2011-06-07 F5 Networks, Inc. Methods and apparatus for implementing authentication
CN101218559A (zh) * 2005-05-06 2008-07-09 弗里塞恩公司 令牌共享系统和方法
WO2006126969A1 (en) * 2005-05-24 2006-11-30 Encentuate Pte Ltd User authentication using personal objects
US9621666B2 (en) 2005-05-26 2017-04-11 Citrix Systems, Inc. Systems and methods for enhanced delta compression
US8397287B2 (en) 2006-08-21 2013-03-12 Citrix Systems, Inc. Method and system for authorizing a level of access of a client to a virtual private network connection, based on a client-side attribute
US9407608B2 (en) 2005-05-26 2016-08-02 Citrix Systems, Inc. Systems and methods for enhanced client side policy
US9692725B2 (en) 2005-05-26 2017-06-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
US8943304B2 (en) 2006-08-03 2015-01-27 Citrix Systems, Inc. Systems and methods for using an HTTP-aware client agent
DE602005015328D1 (de) 2005-10-04 2009-08-20 Swisscom Ag Verfahren zur Anpassung der Sicherheitseinstellungen einer Kommunikationsstation und Kommunikationsstation
KR100729105B1 (ko) * 2005-10-14 2007-06-14 포스데이타 주식회사 비 유에스아이엠 단말기에서의 이에이피-에이케이에이 인증처리 장치 및 방법
US8286002B2 (en) * 2005-12-02 2012-10-09 Alcatel Lucent Method and apparatus for providing secure remote access to enterprise networks
US8378786B2 (en) * 2006-02-03 2013-02-19 Emc Corporation Security provision in standards-compliant RFID systems
WO2007094165A1 (ja) 2006-02-15 2007-08-23 Nec Corporation 本人確認システムおよびプログラム、並びに、本人確認方法
US8417746B1 (en) 2006-04-03 2013-04-09 F5 Networks, Inc. File system management with enhanced searchability
CN100365641C (zh) * 2006-04-11 2008-01-30 北京飞天诚信科技有限公司 利用一次性密码保护计算机登录的方法
US9258124B2 (en) 2006-04-21 2016-02-09 Symantec Corporation Time and event based one time password
US8413229B2 (en) * 2006-08-21 2013-04-02 Citrix Systems, Inc. Method and appliance for authenticating, by an appliance, a client to access a virtual private network connection, based on an attribute of a client-side certificate
JP4174535B2 (ja) * 2006-08-22 2008-11-05 Ｎｅｃインフロンティア株式会社 無線端末を認証する認証システム及び認証方法
US8719709B2 (en) * 2006-08-25 2014-05-06 Sandisk Technologies Inc. Method for interfacing with a memory card to access a program instruction
US8042155B1 (en) * 2006-09-29 2011-10-18 Netapp, Inc. System and method for generating a single use password based on a challenge/response protocol
US7945776B1 (en) * 2006-09-29 2011-05-17 Emc Corporation Securing a passphrase
US8763110B2 (en) * 2006-11-14 2014-06-24 Sandisk Technologies Inc. Apparatuses for binding content to a separate memory device
US8533272B2 (en) * 2007-01-30 2013-09-10 Alcatel Lucent Method and apparatus for notification and delivery of messages to mobile PC users
US8345871B2 (en) * 2007-03-15 2013-01-01 Palo Alto Research Center Incorporated Fast authentication over slow channels
US8572716B2 (en) 2007-04-23 2013-10-29 Microsoft Corporation Integrating operating systems with content offered by web based entities
US8315214B2 (en) * 2007-05-18 2012-11-20 Research In Motion Limited Method and system for discontinuous reception de-synchronization detection
WO2008147973A2 (en) 2007-05-25 2008-12-04 Attune Systems, Inc. Remote file virtualization in a switched file system
US20080320566A1 (en) * 2007-06-25 2008-12-25 Microsoft Corporation Device provisioning and domain join emulation over non-secured networks
US8196191B2 (en) * 2007-08-17 2012-06-05 Norman James M Coordinating credentials across disparate credential stores
US8863246B2 (en) * 2007-08-31 2014-10-14 Apple Inc. Searching and replacing credentials in a disparate credential store environment
US20090077638A1 (en) * 2007-09-17 2009-03-19 Novell, Inc. Setting and synching preferred credentials in a disparate credential store environment
US8548953B2 (en) 2007-11-12 2013-10-01 F5 Networks, Inc. File deduplication using storage tiers
US20090138876A1 (en) * 2007-11-22 2009-05-28 Hsuan-Yeh Chang Method and system for delivering application packages based on user demands
US8352785B1 (en) 2007-12-13 2013-01-08 F5 Networks, Inc. Methods for generating a unified virtual snapshot and systems thereof
US20090199277A1 (en) * 2008-01-31 2009-08-06 Norman James M Credential arrangement in single-sign-on environment
US20090217367A1 (en) * 2008-02-25 2009-08-27 Norman James M Sso in volatile session or shared environment
US8631237B2 (en) * 2008-04-25 2014-01-14 Microsoft Corporation Simplified login for mobile devices
US20110107239A1 (en) * 2008-05-01 2011-05-05 Uri Adoni Device, system and method of interactive game
GB2460275B (en) * 2008-05-23 2012-12-19 Exacttrak Ltd A Communications and Security Device
US7522723B1 (en) * 2008-05-29 2009-04-21 Cheman Shaik Password self encryption method and system and encryption by keys generated from personal secret information
US20090319598A1 (en) * 2008-06-20 2009-12-24 Michael Mittel Remote command execution from mobile devices brokered by a centralized system
US8549582B1 (en) 2008-07-11 2013-10-01 F5 Networks, Inc. Methods for handling a multi-protocol content name and systems thereof
US8286171B2 (en) 2008-07-21 2012-10-09 Workshare Technology, Inc. Methods and systems to fingerprint textual information using word runs
US8416933B2 (en) * 2008-10-30 2013-04-09 International Business Machines Corporation Trusted environment for communication between parties
US9092636B2 (en) 2008-11-18 2015-07-28 Workshare Technology, Inc. Methods and systems for exact data match filtering
US20100205448A1 (en) * 2009-02-11 2010-08-12 Tolga Tarhan Devices, systems and methods for secure verification of user identity
CN102349061B (zh) * 2009-03-12 2014-04-16 惠普开发有限公司 用于对用户进行认证的方法和系统
DE102009021011A1 (de) * 2009-05-13 2010-11-18 Siemens Aktiengesellschaft Elektronischer Schlüssel zur Authentifizierung
US8750824B2 (en) * 2009-10-30 2014-06-10 International Business Machines Corporation Global mobility infrastructure for user devices
US8280351B1 (en) 2010-02-04 2012-10-02 Cellco Partnership Automatic device authentication and account identification without user input when application is started on mobile station
US9195500B1 (en) 2010-02-09 2015-11-24 F5 Networks, Inc. Methods for seamless storage importing and devices thereof
US8850562B2 (en) * 2010-02-22 2014-09-30 Microsoft Corporation Authorization logic in memory constrained security device
US8412928B1 (en) * 2010-03-31 2013-04-02 Emc Corporation One-time password authentication employing local testing of candidate passwords from one-time password server
US8677451B1 (en) 2010-06-22 2014-03-18 Cellco Partnership Enabling seamless access to a domain of an enterprise
US8347100B1 (en) 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US9286298B1 (en) 2010-10-14 2016-03-15 F5 Networks, Inc. Methods for enhancing management of backup data sets and devices thereof
US11030163B2 (en) 2011-11-29 2021-06-08 Workshare, Ltd. System for tracking and displaying changes in a set of related electronic documents
US10025759B2 (en) 2010-11-29 2018-07-17 Workshare Technology, Inc. Methods and systems for monitoring documents exchanged over email applications
US10783326B2 (en) 2013-03-14 2020-09-22 Workshare, Ltd. System for tracking changes in a collaborative document editing environment
GB2488766A (en) * 2011-03-04 2012-09-12 Intercede Ltd Securely transferring data to a mobile device
US10963584B2 (en) 2011-06-08 2021-03-30 Workshare Ltd. Method and system for collaborative editing of a remotely stored document
US10880359B2 (en) 2011-12-21 2020-12-29 Workshare, Ltd. System and method for cross platform document sharing
US9170990B2 (en) 2013-03-14 2015-10-27 Workshare Limited Method and system for document retrieval with selective document comparison
US10574729B2 (en) 2011-06-08 2020-02-25 Workshare Ltd. System and method for cross platform document sharing
US9613340B2 (en) 2011-06-14 2017-04-04 Workshare Ltd. Method and system for shared document approval
US8396836B1 (en) 2011-06-30 2013-03-12 F5 Networks, Inc. System for mitigating file virtualization storage import latency
DE112012003731T5 (de) * 2011-09-09 2014-08-07 Stoneware Inc. Verfahren und Vorrichtung zum Schlüssel-Sharing in Verbindung mit dem Remote Desktop Protocol
US8635684B2 (en) 2011-10-06 2014-01-21 Sap Ag Computer-implemented method for mobile authentication and corresponding computer system
US10263782B2 (en) * 2011-10-12 2019-04-16 Goldkey Corporation Soft-token authentication system
US8463850B1 (en) 2011-10-26 2013-06-11 F5 Networks, Inc. System and method of algorithmically generating a server side transaction identifier
US10742634B1 (en) 2011-12-27 2020-08-11 Majid Shahbazi Methods for single sign-on (SSO) using optical codes
US8819444B2 (en) 2011-12-27 2014-08-26 Majid Shahbazi Methods for single signon (SSO) using decentralized password and credential management
US9356924B1 (en) 2011-12-27 2016-05-31 Majid Shahbazi Systems, methods, and computer readable media for single sign-on (SSO) using optical codes
US9020912B1 (en) 2012-02-20 2015-04-28 F5 Networks, Inc. Methods for accessing data in a compressed file system and devices thereof
US9154568B2 (en) * 2012-03-20 2015-10-06 Facebook, Inc. Proxy bypass login for applications on mobile devices
US9672574B2 (en) 2012-03-20 2017-06-06 Facebook, Inc. Bypass login for applications on mobile devices
US9083703B2 (en) * 2012-03-29 2015-07-14 Lockheed Martin Corporation Mobile enterprise smartcard authentication
US8959335B2 (en) * 2012-04-17 2015-02-17 Gemalto Sa Secure password-based authentication for cloud computing services
NO335081B1 (no) * 2012-08-02 2014-09-08 Cypod Tech As Fremgangsmåte, system og anordning for smart tilgangskontroll for e-handelbetaling
US9449167B2 (en) * 2012-09-12 2016-09-20 Infosys Limited Method and system for securely accessing different services based on single sign on
US9519501B1 (en) 2012-09-30 2016-12-13 F5 Networks, Inc. Hardware assisted flow acceleration and L2 SMAC management in a heterogeneous distributed multi-tenant virtualized clustered system
US20150339474A1 (en) * 2012-12-24 2015-11-26 Cell Buddy Network Ltd. User authentication system
US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
US9554418B1 (en) 2013-02-28 2017-01-24 F5 Networks, Inc. Device for topology hiding of a visited network
US10200351B2 (en) * 2013-03-14 2019-02-05 Google Llc System for managing remote software applications
US10911492B2 (en) 2013-07-25 2021-02-02 Workshare Ltd. System and method for securing documents prior to transmission
CN103607284B (zh) * 2013-12-05 2017-04-19 李笑来 身份认证方法及设备、服务器
US9760704B2 (en) * 2014-05-23 2017-09-12 Blackberry Limited Security apparatus session sharing
US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
US10187483B2 (en) * 2014-08-12 2019-01-22 Facebook, Inc. Managing access to user information by applications operating in an online system environment
US10057240B2 (en) * 2014-08-25 2018-08-21 Sap Se Single sign-on to web applications from mobile devices
DE102014116883B4 (de) * 2014-11-18 2022-07-14 Schneider Electric Automation Gmbh Verfahren zum Zugreifen auf Funktionen eines Embedded-Geräts
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
US10133723B2 (en) 2014-12-29 2018-11-20 Workshare Ltd. System and method for determining document version geneology
US11182551B2 (en) 2014-12-29 2021-11-23 Workshare Ltd. System and method for determining document version geneology
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
US10685349B2 (en) * 2015-03-18 2020-06-16 Google Llc Confirming physical possession of plastic NFC cards with a mobile digital wallet application
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US9692745B2 (en) 2015-04-10 2017-06-27 Microsoft Technology Licensing, Llc Single sign-on without a broker application
US9736165B2 (en) 2015-05-29 2017-08-15 At&T Intellectual Property I, L.P. Centralized authentication for granting access to online services
US10509900B1 (en) 2015-08-06 2019-12-17 Majid Shahbazi Computer program products for user account management
US11763013B2 (en) 2015-08-07 2023-09-19 Workshare, Ltd. Transaction document management system and method
US10572654B2 (en) * 2016-01-11 2020-02-25 Vadim Zaver Method for a repeatable creation of a random file
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10771508B2 (en) 2016-01-19 2020-09-08 Nadejda Sarmova Systems and methods for establishing a virtual shared experience for media playback
US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
US10050963B2 (en) * 2016-03-29 2018-08-14 Microsoft Technology Licensing, Llc Securing remote authentication
US10097537B2 (en) 2016-04-07 2018-10-09 At&T Intellectual Property I, L.P. Cloud-based authentication keyboard
CN107809411B (zh) * 2016-09-09 2021-12-03 华为技术有限公司 移动网络的认证方法、终端设备、服务器和网络认证实体
US10412198B1 (en) 2016-10-27 2019-09-10 F5 Networks, Inc. Methods for improved transmission control protocol (TCP) performance visibility and devices thereof
US10567492B1 (en) 2017-05-11 2020-02-18 F5 Networks, Inc. Methods for load balancing in a federated identity environment and devices thereof
US10944568B2 (en) * 2017-10-06 2021-03-09 The Boeing Company Methods for constructing secure hash functions from bit-mixers
US10891372B1 (en) 2017-12-01 2021-01-12 Majid Shahbazi Systems, methods, and products for user account authentication and protection
US11223689B1 (en) 2018-01-05 2022-01-11 F5 Networks, Inc. Methods for multipath transmission control protocol (MPTCP) based session migration and devices thereof
US10833943B1 (en) 2018-03-01 2020-11-10 F5 Networks, Inc. Methods for service chaining and devices thereof
FR3085815B1 (fr) * 2018-07-11 2022-07-15 Ledger Gouvernance de securite du traitement d'une requete numerique
US11323432B2 (en) 2019-07-08 2022-05-03 Bank Of America Corporation Automatic login tool for simulated single sign-on
US11089005B2 (en) 2019-07-08 2021-08-10 Bank Of America Corporation Systems and methods for simulated single sign-on
US11115401B2 (en) 2019-07-08 2021-09-07 Bank Of America Corporation Administration portal for simulated single sign-on
EP3879422A1 (de) 2020-03-09 2021-09-15 Carrier Corporation Netzwerkkennung und authentifizierungsinformationserzeugung für gebäudeautomatisierungssystemsteuerungen
CN114363090B (zh) * 2022-03-02 2022-10-25 工业互联网创新中心（上海）有限公司 一种多应用系统的单点登录平台的实现方法及管理系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5153919A (en) * 1991-09-13 1992-10-06 At&T Bell Laboratories Service provision authentication protocol
US5778071A (en) * 1994-07-12 1998-07-07 Information Resource Engineering, Inc. Pocket encrypting and authenticating communications device
US5898780A (en) * 1996-05-21 1999-04-27 Gric Communications, Inc. Method and apparatus for authorizing remote internet access
US5983350A (en) * 1996-09-18 1999-11-09 Secure Computing Corporation Secure firewall supporting different levels of authentication based on address or encryption status
US6061346A (en) * 1997-01-17 2000-05-09 Telefonaktiebolaget Lm Ericsson (Publ) Secure access method, and associated apparatus, for accessing a private IP network
SE512335C2 (sv) 1998-05-12 2000-02-28 Sectra Communications Ab Mobil och/eller trådlös telefon
JP2000215172A (ja) * 1999-01-20 2000-08-04 Nec Corp 個人認証システム
ATE311063T1 (de) * 2000-02-08 2005-12-15 Swisscom Mobile Ag Vereinter einloggungsprozess
US6977917B2 (en) * 2000-03-10 2005-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for mapping an IP address to an MSISDN number within a service network
US7010582B1 (en) * 2000-06-26 2006-03-07 Entrust Limited Systems and methods providing interactions between multiple servers and an end use device
US7441043B1 (en) * 2002-12-31 2008-10-21 At&T Corp. System and method to support networking functions for mobile hosts that access multiple networks

Also Published As

Publication number Publication date
ATE311063T1 (de) 2005-12-15
US9148420B2 (en) 2015-09-29
US20150089618A1 (en) 2015-03-26
EP1254547A1 (de) 2002-11-06
US7058180B2 (en) 2006-06-06
US20060013393A1 (en) 2006-01-19
WO2001060013A1 (en) 2001-08-16
US8793779B2 (en) 2014-07-29
DE60024319D1 (de) 2005-12-29
EP1254547B1 (de) 2005-11-23
AU2000264222A1 (en) 2001-08-20
US20030012382A1 (en) 2003-01-16

Similar Documents

Publication Publication Date Title
DE60024319T2 (de) Vereinter einloggungsprozess
DE69433771T2 (de) Verfahren und Vorrichtung zur Geheimhaltung und Authentifizierung in einem mobilen drahtlosen Netz
DE60310968T2 (de) Sicherheits- und Privatsphärenverbesserungen für Sicherheitseinrichtungen
DE60029217T2 (de) Verfahren und vorrichtung zum initialisieren von sicheren verbindungen zwischen und nur zwischen zueinandergehörenden schnurlosen einrichtungen
DE69637505T2 (de) Verfahren zur Authentifizierung eines Teilnehmers in einer verteilten Client/Server Netzwerkumgebung
EP1400089B1 (de) Benutzerauthentisierung quer durch die Kommunikationssitzungen
Asokan et al. Man-in-the-middle in tunnelled authentication protocols
DE60200093T2 (de) Sichere Benutzerauthenifizierung über ein Kommunikationsnetzwerk
DE60302276T2 (de) Verfahren zur ferngesteuerten Änderung eines Kommunikationspasswortes
DE60036112T2 (de) Serverunterstützte wiedergewinnung eines starken geheimnisses aus einem schwachen geheimnis
DE60314402T2 (de) System und methode zum speichern sowie abrufen kryptographischer geheimnisse von unterschiedlichen kundenendgeräten in einem netzwerk
DE60314060T2 (de) Verfahren und Vorrichtung zur Schlüsselverwaltung für gesicherte Datenübertragung
EP2289222B1 (de) Verfahren, authentikationsserver und diensteserver zum authentifizieren eines client
DE112008001436T5 (de) Sichere Kommunikation
DE112006000618T5 (de) System und Verfahren zur Verteilung von Schlüsseln in einem drahtlosen Netzwerk
DE60203277T2 (de) Verfahren und system zur authentifizierung eines personal security device gegenüber mindestens einem fernrechnersystem
DE10212620A1 (de) Sichere Benutzer- und Datenauthentisierung über ein Kommunikationsnetzwerk
DE10392208T5 (de) Mechanismus zum Unterstützten drahtgebundener und drahtloser Verfahren für eine client- und serverseitige Authentifizierung
US20070266236A1 (en) Secure network and method of operation
CN101714918A (zh) 一种登录vpn的安全系统以及登录vpn的安全方法
DE102009051383A1 (de) Verfahren und Vorrichtung zum sicheren Übertragen von Daten
DE602004012103T2 (de) Verfahren zum verteilen von passwörtern
DE102017210721A1 (de) Verfahren und Kommunikationssystem zum effizienten Aufbau einer sicheren Datenverbindung zwischen einem Client-Rechner und einem Server-Rechner
DE102017121648B3 (de) Verfahren zum anmelden eines benutzers an einem endgerät
DE60311328T2 (de) Verfahren und vorrichtung zur netzwerksicherheit

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: SWISSCOM AG, BERN, CH