DE10392788T5 - Nichtablehnung von Dienstvereinbarungen - Google Patents

Nichtablehnung von Dienstvereinbarungen Download PDF

Info

Publication number
DE10392788T5
DE10392788T5 DE10392788T DE10392788T DE10392788T5 DE 10392788 T5 DE10392788 T5 DE 10392788T5 DE 10392788 T DE10392788 T DE 10392788T DE 10392788 T DE10392788 T DE 10392788T DE 10392788 T5 DE10392788 T5 DE 10392788T5
Authority
DE
Germany
Prior art keywords
service
user
service agreement
information
manager
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.)
Ceased
Application number
DE10392788T
Other languages
English (en)
Inventor
Rolf Blom
András Nehes
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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
Priority claimed from US10/278,362 external-priority patent/US7194765B2/en
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE10392788T5 publication Critical patent/DE10392788T5/de
Ceased 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/12—Applying verification of the received information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/04—Masking or blinding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Verfahren für eine Nichtablehnung einer Dienstvereinbarung zwischen einem Anwender und einem Service-Provider in einem Kommunikationssystem, wobei das Verfahren die folgenden Schritte aufweist:
– sicheres gemeinsames Nutzen eines geheimen Schlüssels zwischen einem Anwender-Endgerät und einem Dienstvereinbarungsmanager, wobei der Service-Provider eine Vertrauensbeziehung mit dem Dienstvereinbarungsmanager hat;
– Vorbereiten von Dienstvereinbarungsinformation;
– kryptographisches Verarbeiten basierend auf dem gemeinsam genutzten geheimen Schlüssel der Dienstvereinbarungsinformation, um anwendersignierte Dienstvereinbarungs-Verifizierungsinformation zu erzeugen; und
– Weiterleiten der anwendersignierten Verifizierungsinformation zum Service-Provider, um eine Verifizierung der Dienstvereinbarung basierend auf der Vertrauensbeziehung zwischen dem Service-Provider und dem Dienstvereinbarungsmanager zu ermöglichen.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Erfindung betrifft allgemein einen stabilen und sicheren elektronischen Handel bzw. e-Commerce in modernen Kommunikationssystemen, wie beispielsweise mobilen Kommunikationssystemen.
  • HINTERGRUND
  • Viele Kommunikationssysteme von heute, einschließlich mobiler Kommunikationssysteme, verwenden Authentifizierungs- und Verschlüsselungsprozeduren für den Zweck eines Verbesserns einer Systemsicherheit und -stabilität.
  • In mobilen Kommunikationssystemen authentifizieren sich beispielsweise Anwender in Richtung zum Netzwerk und/oder zu Dienstanbietern bzw. Service-Providern, um einen Zugriff auf Basis-Netzwerkdienste sowie andere Dienste zu erlangen, und die Authentifizierung dient auch als Basis zur Rechnungserstellung für den Anwender. Das Basis-Sicherheitsprotokoll von modernen Kommunikationssystemen enthält normalerweise eine Aufforderung/Antwort-Authentifizierungsprozedur, die am häufigsten auf einer Kryptographie mit einem geheimen Schlüssel basiert. Eine Aufforderung/Antwort-Authentifizierung ist im Stand der Technik wohlbekannt und es existieren mehrere Standards über eine Basis-Aufforderung/Antwort-Authentifizierung, wie z.B. für GSM-(Global System for Mobile Communications)- und UMTS- (Universal Mobile Telecommunications System)-Netzwerke.
  • Beim elektronischen Handel und insbesondere für kleine Bezahlungssysteme ist es für den Service-Provider wesentlich, dass er nachweisen kann, dass ein Anwender zugestimmt hat, für einen Dienst zu bezahlen (Anwender-Nichtablehnung von Dienstgebühren/Dienstvereinbarungen).
  • Bekannte Techniken für eine Nichtablehnung verwenden normalerweise digitale Signaturen, die auf Kryptographieschemen mit öffentlichem Schlüssel basieren, die von einem Standpunkt einer Berechnung aus teuer sind.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung überwindet diese und andere Nachteile der Anordnungen nach dem Stand der Technik.
  • Es ist eine allgemeine Aufgabe der vorliegenden Erfindung, einen effizienten und stabilen bzw. widerstandsfähigen Mechanismus für eine Nichtablehnung von Dienstvereinbarungen zwischen einem Service-Provider und einem Anwender in einem Kommunikationssystem zur Verfügung zu stellen.
  • Es ist eine Aufgabe der Erfindung, einen Mechanismus zur Verfügung zu stellen, der veranlasst, dass ein Service-Provider nachweisen oder verifizieren kann, dass der Anwender in der Tat eine gegebene Dienstvereinbarung akzeptiert hat.
  • Beispielsweise kann es für den Service-Provider interessant sein, dass er nachweisen kann, dass der Anwender einer Bezahlung für einen Dienst zugestimmt hat, einschließlich einer Verifizierung der akzeptierten Dienstgebühr.
  • Eine weitere Aufgabe der Erfindung besteht im Bereitstellen eines Mechanismus für eine verbesserte auf einer Aufforderung/Antwort basierende Authentifizierungs- und Schlüsselvereinbarung (AKA) in einem Kommunikationssystem.
  • Diese und andere Aufgaben werden durch die Erfindung erfüllt, wie sie durch die beigefügten Patentansprüche definiert ist.
  • Kurz gesagt enthält die Erfindung normalerweise eine dritte vertrauenswürdige Partei, nämlich einen so genannten Dienstvereinbarungsmanager. Die Erfindung basiert auf der Idee, dass der Dienstvereinbarungsmanager einen geheimen Schlüssel mit einem Anwender-Endgerät gemeinsam nutzt und dass der Service-Provider eine Vertrauensbeziehung mit dem Dienstvereinbarungsmanager hat. Das durch die Erfindung vorgeschlagene Nichtablehnungsschema basiert weiterhin auf einer Vorbereitung relevanter Dienstvereinbarungsinformation, einer kryptographischen Verarbeitung dieser Information basierend auf dem gemeinsam genutzten geheimen Schlüssel, um eine anwendersignierte Dienstvereinbarungs-Verifizierungsinformation zu erzeugen. Die anwendersignierte Verifizierungsinformation wird darauf folgend zum Service-Provider weitergeleitet, um eine Verifizierung der Dienstvereinbarung basierend auf der Vertrauensbeziehung zwischen dem Service-Provider und dem Dienstvereinbarungsmanager zu ermöglichen.
  • Der Dienstvereinbarungsmanager könnte irgendeine vertrauenswürdige Partei sein, die das Management einer Dienstvereinbarung zwischen einem Service-Provider und einem Anwender managt oder auf andere Weise daran teilnimmt, und kann beispielsweise auf der Netzwerkbetreiberseite in einem Kommunikationssystem implementiert sein.
  • Der Dienstvereinbarungsmanager kann sogar zwischen unterschiedlichen Knoten oder Parteien verteilt sein und kann beispielsweise einen Anwenderidentitätsvermittler bzw. -makler und einen Bezahlungsvermittler bzw. -makler, der zwischen dem Service-Provider und dem Identitätsvermittler angeordnet ist, enthalten. In diesem Fall kann eine Vertrauenskette zwischen dem Service-Provider, dem Bezahlungsvermittler und dem Identitätsvermittler aufgebaut werden, wo das Anwender-Endgerät typischerweise den geheimen Schlüssel mit dem Identitätsvermittler gemeinsam nutzt.
  • Die Vorbereitung von Dienstvereinbarungsinformation wird normalerweise durch den Service-Provider durchgeführt oder initialisiert, aber es sollte verstanden werden, dass diese Information durch irgendeine der beteiligten Parteien vorbereitet werden kann, solange sowohl der Anwender als auch der Service-Provider die Vereinbarung akzeptieren.
  • Die kryptographische Verarbeitung der Dienstvereinbarungsinformation wird normalerweise auf der Anwenderseite durchgeführt, kann aber in einigen Fällen auch den Dienstvereinbarungsmanager beteiligen. Vorzugsweise führt das Anwender-Endgerät die kryptographische Verarbeitung basierend auf einem Nichtablehnungsschlüssel durch, der lokal von dem gemeinsam genutzten geheimen Schlüssel abgeleitet ist, um die erforderliche Verifizierungsinformation zu erzeugen.
  • Die bloße Tatsache, dass der Service-Provider eine anwendersignierte Verifizierungsinformation empfängt und die Fähigkeit hat, diese Information zu speichern, kann Anwender von einem Ablehnen von Dienstvereinbarungen abhalten, in die sie eingetreten sind. Wenn es erwünscht oder auf andere Weise geeignet ist, kann eine aktuelle Verifizierung online oder offline durch den Dienstvereinbarungsmanager oder sogar direkt durch den Service-Provider durchgeführt werden.
  • Beispielsweise kann der Dienstvereinbarungsmanager erwartete Verifizierungsinformation wenigstens teilweise basierend auf der vorbereiteten Dienstvereinbarungsinformation und dem gemeinsam genutzten geheimen Schlüssel erzeugen, und wenn es erforderlich ist, verifizieren, dass anwendersignierte Verifizierungsinformation, die vom Service-Provider weitergeleitet wird, tatsächlich der erwarteten Verifizierungsinformation entspricht.
  • Angenehmerweise kann die anwendersignierte Verifizierungsinformation durch das Anwender-Endgerät in Reaktion bzw. in Antwort auf eine Aufforderung erzeugt werden, die von dem Dienstvereinbarungsmanager initiiert ist, oder basierend auf einem auf der Anwenderseite initiierten Ticket, und zwar in beiden Fällen in Kombination mit der gegebenen Dienstvereinbarungsinformation.
  • Alternativ wird jedoch die kryptographische Verarbeitung der Dienstvereinbarungsinformation sowohl auf der Seite des Dienstvereinbarungsmanagers als auch auf der Anwenderseite durchgeführt. In diesem Fall erzeugt der Dienstvereinbarungsmanager vorzugsweise eine kryptographische Darstellung der Dienstvereinbarungsinformation basierend auf dem gemeinsam genutzten geheimen Schlüssel und leitet diese Darstellung weiter zu dem Anwender-Endgerät (typischerweise über den Service-Provider), und dann wird die empfangene kryptographische Darstellung basierend auf dem gemeinsam genutzten geheimen Schlüssel auf der Anwenderseite verarbeitet, um eine geeignete Verifizierungsinformation zu erzeugen.
  • Beispielsweise kann die kryptographische Verarbeitung auf der Seite des Dienstvereinbarungsmanagers für eine auf einem Ticket basierende Lösung eine Verschlüsselung eines Tickets enthalten, das basierend auf der vorbereiteten Dienstvereinbarungsinformation erzeugt ist, und die Verarbeitung auf der Anwenderseite enthält dann allgemein eine Entschlüsselung des verschlüsselten Tickets.
  • Wie es verstanden werden sollte, kann die Dienstvereinbarungsinformation ein allgemeiner elektronischer Vertrag sein. Jedoch hat sich herausgestellt, dass die Erfindung insbesondere nützlich bei Anwendungen ist, bei welchen die Dienstvereinbarungsinformation Dienstgebühreninformation enthält und der Dienstvereinbarungsmanager als Bezahlungsprovider oder Rechnungserstellungs- bzw. Belastungszentrum im Auftrag des Service-Providers handelt.
  • Für eine allgemeine Vertragsunterzeichnung enthält ein speziell entworfenes Ausführungsbeispiel, das eine Offline-Verifizierung durch den Service-Provider zulässt, ein Maskieren von sowohl durch den Dienstvereinbarungsmanager erzeugter erwarteter Verifizierungsinformation als auch von anwendersignierter Verifizierungsinformation mittels lokaler Fälle derselben Maskierungsfunktion. Die basierend auf den gemeinsam genutzten geheimen Schlüssel und dem allgemeinen Vertrag erzeugte erwartete Verifizierungsinformation wird durch den Dienstvereinbarungsmanager maskiert und zum Service-Provider weitergeleitet. Die anwendersignierte Verifizierungsinformation wird von der Anwenderseite empfangen und durch den Service-Provider maskiert, um dadurch eine Verifizierung der Dienstvereinbarung auf der Seite des Service-Providers zuzulassen, indem die maskierte erwartete Verifizierungsinformation und die maskierte anwendersignierte Verifizierungsinformation verglichen werden.
  • Vorteilhaft erzeugt der Dienstvereinbarungsmanager die erwartete Dienstvereinbarungsverifizierungsinformation durch Anwenden einer kryptographischen Hash-Codierung des Vertrags als eine Zufallsaufforderung in einer normalen auf einer Aufforderung/Antwort basierenden Authentifizierungs- und Schlüsselvereinbarungsprozedur.
  • In einer Reihe von besonders nützlichen Ausführungsbeispielen ist eine Nichtablehnung von Dienstvereinbarungen mit einer auf einer Aufforderung/Antwort basierenden Authentifizierungs- und Schlüsselvereinbarungs-(AKA-)Prozedur für einen Netzwerkzugriff (z.B. GMS/UMTS AKA) unter Verwendung desselben gemeinsam genutzten geheimen Schlüssels integriert, der normalerweise für AKA verwendet wird. Dies bedeutet, dass eine existierende Infrastruktur wieder verwendet werden kann.
  • In deutlichem Gegensatz zu der Erfindung basieren Techniken nach dem Stand der Technik zum Bereitstellen einer Nichtablehnung von Dienstvereinbarungen auf kryptographischen Schemen mit öffentlichem Schlüssel direkt zwischen dem Service-Provider und dem Anwender-Endgerät unter Verwendung eines asymmetrischen Schlüsselpaars.
  • Obwohl es nicht nötig ist, hat es sich als vorteilhaft herausgestellt, ein Schlüsselgebungsmaterial für eine Nichtablehnung der Dienstvereinbarung von einem Schlüsselgebungsmaterial für eine normale AKA zu isolieren. Diesbezüglich kann das Schlüsselgebungsmaterial für eine Nichtablehnung selbst an einen spezifischen Bezahlungsvermittler gebunden sein, der mit einem Authentifizierungsmanager zusammenarbeitet, wo das Anwender-Endgerät den geheimen Schlüssel mit dem Authentifizierungsmanager gemeinsam nutzt.
  • Bei einem weiteren zugehörigen Aspekt der Erfindung wird das Basisprinzip des obigen Isolierungsmechanismus verwendet, um eine auf einer Aufforderung/Antwort basierende Authentifizierungs- und Schlüsselvereinbarung (AKA) zu verbessern. Kurz gesagt können normale AKA-Prozeduren durch Isolieren einer ersten Gruppe von AKA-Parametern für einen Zugriff auf ein durch einen Netzwerkbetreiber gemanagtes Netzwerk von einer zweiten Gruppe von AKA-Parametern für einen Zugriff auf Dienste durch einen Service-Provider mittels einer vorbestimmten Funktion, wie beispielsweise einer Pseudozufallsfunktion, unter Verwendung einer Darstellung von wenigstens einem Teil der ersten Gruppe von AKA-Parametern als Eingabe zum Erzeugen der zweiten Gruppe von AKA-Parametern verbessert werden. Dies hat den Vorteil, dass selbst dann, wenn ein Schlüsselgebungsmaterial für einen Dienstzugriff verloren oder gestohlen wird, es nicht für den grundsätzlichen Netzwerkzugriff verwendet werden kann.
  • Die Erfindung bietet die folgenden Vorteile:
    • • Eine effiziente und stabile Nichtablehnung von Dienstvereinbarungen in einem Kommunikationssystem.
    • • Ein Abhalten von Anwendern von einem Ablehnen von Dienstvereinbarungen, in die sie eingetreten sind.
    • • Ein Bereitstellen von neuen Geschäftsmöglichkeiten für Netzwerkbetreiber, um als vertrauenswürdige Dienstvereinbarungsmanager zu handeln. Beispielsweise können Betreiber eine natürliche Rolle bei dem Bezahlungsprozess erlangen.
    • • Effiziente Wege zum Erweitern von Basis-Aufforderung/Antwort-Prozeduren, wie beispielsweise UMTS/GSM AKA, was es möglich macht, Bezahlungsvereinbarungen mit einer Anwenderauthentifizierung zu verbinden.
    • • Eine einfache Migration mit existierender Infrastruktur.
    • • Eine einfache Implementierung, ohne dass man neue GSM- oder UMTS-Teilnehmeridentitätsmodule (SIMs) einführen muss. Endgeräte müssen irgendwie geändert werden, um neue Bezahlungsprotokolle unterzubringen.
  • Andere Vorteile, die durch die vorliegende Erfindung geboten werden, werden beim Lesen der nachfolgenden Beschreibung der Ausführungsbeispiele der Erfindung erkannt werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung, zusammen mit weiteren Aufgaben und Vorteilen von ihr, wird am besten unter Bezugnahme auf die folgende Beschreibung genommen zusammen mit den beigefügten Zeichnungen verstanden werden, wobei:
  • 1 eine schematische allgemeine Übersicht über die Basisteilnehmer und ihre wechselseitigen Beziehungen gemäß einem bevorzugten Ausführungsbeispiel der Erfindung ist;
  • 2 ein schematisches Signalaustauschdiagramm für eine Heimatauthentifizierung in einem mobilen Kommunikationssystem ist, wenn ein mobiler Anwender bzw. Mobilfunkanwender Gast in einem besuchten Netzwerk wird;
  • 3 ein schematisches Signalaustauschdiagramm für eine Authentifizierung mit delegierter Verifizierung auf die Weise ist, auf welche sie normalerweise heutzutage in zellularen Systemen implementiert ist;
  • 4 ein schematisches Diagramm ist, das die Gesamtstruktur und eine Basis für das vorgeschlagene allgemeine Schema für eine Nichtablehnung von Dienstvereinbarungen gemäß einem bevorzugten Ausführungsbeispiel der Erfindung darstellt;
  • 5 ein schematisches beispielhaftes Signalaustauschdiagramm für eine Nichtablehnung von Dienstvereinbarungen unter Verwendung eines bestimmten Nichtablehnungsschlüssels mit möglicher Offline-Verifizierung ist;
  • 6A ein schematisches beispielhaftes Signalaustauschdiagramm für eine Online-Verifizierung von Dienstvereinbarungen unter Verwendung eines bestimmten Nichtablehnungsschlüssels ist;
  • 6B ein schematisches beispielhaftes Signalaustauschdiagramm für eine Online-Verifizierung von Dienstvereinbarungen unter Verwendung eines existierenden AKA-Schlüssels als Nichtablehnungsschlüssel ist;
  • 7A ein schematisches beispielhaftes Signalaustauschdiagramm zum Bilden eines Nachweises einer Anwenderauthentifizierung mittels maskierter Authentifizierungsdaten in Kombination mit einer Offline-Verifizierung von Dienstvereinbarungen ist;
  • 7B ein schematisches beispielhaftes Signalaustauschdiagramm zum Bilden eines Nachweises einer Anwenderauthentifizierung mittels maskierter Authentifizierungsdaten in Kombination mit einer Online-Verifizierung von sowohl einer Authentifizierung als auch von Dienstvereinbarungen unter Verwendung von entweder einem bestimmten Schlüssel oder einem existierenden AKA-Schlüssel für eine Nichtablehnung der Dienstvereinbarungen ist;
  • 8A ein schematisches beispielhaftes Signalaustauschdiagramm für eine auf einem Ticket basierende Nichtablehnung mit möglicher Offline-Verifizierung ist;
  • 8B ein schematisches beispielhaftes Signalaustauschdiagramm für eine auf einem Ticket basierende Nichtablehnung mit Online-Verifizierung ist;
  • 9 ein schematisches beispielhaftes Signalaustauschdiagramm für eine auf einem Ticket basierende Nichtablehnung ist, wobei das Basisticket durch den Authentifizierungs/Bezahlungs-Manager im Auftrag des Anwenders vorbereitet wird;
  • 10 ein schematisches beispielhaftes Blockdiagramm für eine Vertragssignierung bzw. -unterzeichnung basierend auf der Einführung maskierter Verifizierungsdaten unter Zulassung einer Offline-Verifizierung durch den Service-Provider ist;
  • 11 ein schematisches beispielhaftes Signalaustauschdiagramm für die Vertragssignierungsimplementierung der 10 ist;
  • 12A ein schematisches beispielhaftes Signalaustauschdiagramm für eine AKA-integrierte Nichtablehnung von Dienstvereinbarungen basierend auf unterschiedlichen isolierten Schlüsselgebungsgruppen mit möglicher Offline-Verifizierung ist;
  • 12B ein schematisches beispielhaftes Signalaustauschdiagramm für eine AKA-integrierte Nichtablehnung von Dienstvereinbarungen basierend auf unterschiedlichen isolierten Schlüsselgebungsgruppen mit Online-Verifizierung ist;
  • 13 ein schematisches beispielhaftes Blockdiagramm in einer verteilten Implementierung, die einen Identitätsvermittler sowie einen Bezahlungsvermittler enthält, unter Verwendung einer gebildeten Vertrauenskette zwischen dem Identitätsvermittler, dem Bezahlungsvermittler und dem Service-Provider ist;
  • 14 ein schematisches beispielhaftes Signalaustauschdiagramm für eine Nichtablehnung von Dienstvereinbarungen in einem Szenario für ein Bezahlen im Nachhinein in dem in 13 gezeigten Aufbau ist;
  • 15 ein schematisches beispielhaftes Signalaustauschdiagramm für eine Nichtablehnung von Dienstvereinbarungen in einem Szenario für ein Bezahlen im Voraus in dem in 13 gezeigten Aufbau ist;
  • 16 ein schematisches Blockdiagramm ist, das ein Beispiel eines Dienstvereinbarungsmanagers gemäß einem bevorzugten Ausführungsbeispiel der Erfindung darstellt;
  • 17 ein schematisches Blockdiagramm ist, das ein Beispiel eines Service-Providers gemäß einem bevorzugten Ausführungsbeispiel der Erfindung darstellt; und
  • 18 ein schematisches Blockdiagramm ist, das ein Beispiel eines Anwender-Endgeräts gemäß einem bevorzugten Ausführungsbeispiel der Erfindung darstellt.
  • DETAILLIERTE BESCHREIBUNG VON AUSFÜHRUNGSBEISPIELEN DER ERFINDUNG
  • In allen Zeichnungen werden dieselben Bezugszeichen für entsprechende oder gleiche bzw. ähnliche Elemente verwendet werden.
  • Übersicht
  • Es kann hilfreich sein, durch Skizzieren der Basisteilnehmer und ihrer wechselseitigen Beziehungen in Bezug auf 1 zu beginnen, welche eine schematische allgemeine Übersicht über ein Kommunikationssystem gemäß der vorgeschlagenen Erfindung ist.
  • Die Basisteilnehmer enthalten einen Anwender 10, einen Service-Provider 20 und eine zusätzliche Partei, die allgemein Trust-Provider bzw. Vertrauenslieferant 30 genannt wird, welcher verschiedene Aufgaben im Auftrag des Service-Providers und/oder des Anwenders durchführen kann. Der Vertrauenslieferant 30 hat eine Vertrauensbeziehung zum Anwender (oder viel mehr mit einem geeignet konfigurierten Anwender-Endgerät) durch einen gemeinsam genutzten geheimen Schlüssel gebildet. Der Vertrauenslieferant 30 und der Service-Provider 20 können ein Abkommen haben, das als vertragsmäßige Vertrauensbeziehung manifestiert ist. Die Beziehung zwischen dem Anwender 10 und dem Service-Provider 20 wird normalerweise als induzierte Vertrauensbeziehung angesehen, welche dann gebildet wird, wenn die durch den Service-Provider angebotenen Dienste angefordert oder auf andere Weise initiiert werden.
  • Der Vertrauenslieferant kann beispielsweise einen Bezug zu einem Netzwerkbetreiber haben, mit welchem der Anwender eine Vertrauensbeziehung hat, die beispielsweise durch eine Teilnahme oder ein im Voraus bezahltes Konto gebildet ist. Diese eingerichtete Vertrauensbeziehung wird typischerweise in einer kryptographischen Beziehung durch einen gemeinsam genutzten geheimen Schlüssel (symmetrische Kryptographie) manifestiert, was beispielsweise eine Aufforderung/Antwort-Prozedur, wie beispielsweise die AKA-(Authentifizierungs- und Schlüsselvereinbarungs-)Prozedur für GSM/UMTS und/oder ähnliche Prozeduren ermöglicht. Der Netzwerkbetreiber kann eine Vereinbarung mit dem Service-Provider haben, welche Vereinbarung typischerweise durch eine ähnliche kryptographische Beziehung manifestiert ist. Der Service-Provider kann dann die Aufforderung/Antwort-Prozedur, wie beispielsweise GSM/UMTS AKA, für eine indirekte wechselseitige Authentifizierung mit den Endanwendern oder ihren Diensten verwenden.
  • Es ist bekannt, den Heimatbetreiber als Vertrauensbasis für eine Anwenderauthentifizierung zu verwenden, wenn ein Mobilfunkanwender Gast in einem anderen Netzwerk wird bzw. dorthin umschaltet, das durch einen so genannten besuchten Betreiber gemanagt wird, wie es schematisch durch die 2 und 3 dargestellt ist.
  • 2 ist ein schematisches Signalaustauschdiagramm für eine Anwenderauthentifizierung mit Online-Verifizierung durch den Heimatbetreiber in einem mobilen Kommunikationssystem, wenn ein mobiler Anwender in ein besuchtes Netzwerk umschaltet.
  • Die Basis-UMTS-AKA-Prozedur verwendet einen gemeinsam genutzten geheimen Schlüssel Ki, wie beispielsweise einen Teilnahmeschlüssel, der zu einer Anwender/Betreiber-Teilnahme gehört, oder einen daraus abgeleiteten Schlüssel, um eine Antwort auf eine Aufforderung sowie zwei Sessionschlüssel, nämlich einen für einen Vertrauensschutz (Ck) und einen für eine Integritätsschutz (Ik), des Verkehrs zwischen dem Anwender und dem gesuchten Betreiber zu erzeugen. Der Heimatbetreiber, oder spezifischer das HSS/AuC (Home Subscriber Server/Authentication Center = Heimatteilnehmerserver/Authentifizierungszentrum) und das HLR/AuC (HLR = Home Location Register = Heimatdatei) erzeugt eine Zufallsaufforderung (RAND(= random challenge)) zusammen mit einem Authentifizierungstoken (AUTN(= authentication token)), welche später durch den Anwender verwendet wird, um zu verifizieren, dass die Aufforderung frisch ist und durch den Heimatbetreiber erzeugt ist. Aus dieser Aufforderung werden die Antwort (RES/XRES) und die Schlüssel (Ck, Ik) unter Verwendung des gemeinsam genutzten geheimen Schlüssels berechnet. Bei GSM AKA wird kein Integritätsschlüssel oder Authentifizierungstoken erzeugt, aber die Basis-Aufforderung/Antwort-Prozedur ist dieselbe. Der gemeinsam genutzte geheime Schlüssel wird herkömmlich in einer SIM-Karte implementiert, die bei GSM-Mobilfunkeinheiten verwendet wird, oder einer UMTS-SIM-Karte (USIM), die bei UMTS-Mobilfunkeinheiten verwendet wird, und zwar in Abhängigkeit von einer AKA-Implementierung.
  • Unter Bezugnahme auf 2, die mehr oder weniger dem standardisierten erweiterbaren Authentifizierungsprotokoll (EAP) entspricht, wird nachfolgend eine Art zum Implementieren der erforderlichen Signalgabe zusammengefasst:
    In einer Anfangsphase sendet der Anwender einen Identifizierer zum besuchten Betreiber und leitet der besuchte Betreiber den Identifizierer weiter zum Heimatbetreiber. Basierend auf diesem Identifizierer gewinnt ein HSS/AuC oder ein Äquivalent auf der Seite des Heimatbetreibers den entsprechenden geheimen Schlüssel wieder, erzeugt ein Quintett (RAND, AUTN, Ck, Ik, XRES) und sendet:
  • 1. Aufforderung (RAND), Authentifizierungstoken (AUTN)
    • zum besuchten Betreiber. Diese Parameter werden durch den besuchten Betreiber zum Anwender weitergeleitet.
  • 2. Aufforderung (RAND), Authentifizierungstoken (AUTN)
  • Der Anwender prüft den AUTN, und wenn er OK ist, berechnet er die Antwort (RES), den Vertrauensschlüssel (Ck) und den Integritätsschlüssel (Ik). Die Antwort wird über den besuchten Betreiber zurück zum Heimatbetreiber gesendet.
  • 3. Antwort (RES)
  • 4. Antwort (RES)
  • Der Heimatbetreiber prüft, ob RES gleich der erwarteten Antwort (XRES) ist. Wenn dies der Fall ist, werden die Schlüssel sicher zum besuchten Betreiber transferiert.
  • 5. Integritäts- und Vertrauensschlüssel (Ik und Ck)
  • Der Heimatbetreiber sieht die RES vom Endanwender und kann verifizieren, dass der Endanwender über den besuchten Betreiber authentifiziert worden ist. Der Heimatbetreiber hat jedoch keinen Nachweis darüber, welche Dienstvereinbarung der Anwender akzeptiert hat.
  • Wenn die Signalgabe auf die Art implementiert wird, wie es heute in zellularen Systemen durchgeführt wird, dann wird der Heimatbetreiber nicht einmal irgendeinen Nachweis für eine Anwenderauthentifizierung haben. In diesem Fall wird die Signalgabe unter Bezugnahme auf 3 wie folgt sein:
  • 1. RAND, AUTN, Ik, Ck, XRES
  • 2. RAND, AUTN
  • Der Anwender prüft den AUTN, und wenn er OK ist, berechnet er die Antwort RES, den Vertrauensschlüssel Ck und den Integritätsschlüssel Ik.
  • 3. RES
  • Der besuchte Betreiber prüft, ob RES gleich XRES ist. Wenn dies der Fall ist, dann ist der Anwender authentifiziert.
  • Beispielhaftes allgemeines Schema für eine Nichtablehnung von Dienstvereinbarungen
  • 4 ist ein schematisches Diagramm, das die Gesamtstruktur und eine Basis für das vorgeschlagene allgemeine Schema für eine Nichtablehnung von Dienstvereinbarungen gemäß einem bevorzugten Ausführungsbeispiel der Erfindung darstellt.
  • Die Erfinder haben realisiert, dass es für einen Service-Provider wesentlich ist, nachweisen zu können, dass ein Anwender eine gegebene Dienstvereinbarung akzeptiert hat, und insbesondere, dass ein Anwender zugestimmt hat, für einen Dienst zu bezahlen, einschließlich einer Verifizierung der akzeptierten Dienstgebühr (Anwender-Nichtablehnung von Dienstvereinbarungen/Dienstgebühren). Dies ist insbesondere dann wichtig, wenn eine Anwenderauthentifizierung und Bezahlung/Belastung über/mit der Hilfe von einer dritten vertrauenswürdigen Partei, wie beispielsweise einem Netzwerkbetreiber oder einem Äquivalent durchgeführt wird.
  • Daher wird vorgeschlagen, dass der Vertrauenslieferant 30 als allgemeiner Dienstvereinbarungsmanager im Auftrag des Service-Providers und/oder des Anwenders für den Zweck einer Nichtablehnung einer Dienstvereinbarung zwischen dem Service-Provider und dem Anwender handelt. Das Nichtablehnungsschema gemäß einem bevorzugten Basisausführungsbeispiel der Erfindung weist eine Vorbereitung relevanter Dienstvereinbarungsinformation sowie eine kryptographische Verarbeitung der vorbereiteten Information basierend auf dem geheimen Schlüssel, der zwischen dem Dienstvereinbarungsmanager und einem Anwender-Endgerät gemeinsam genutzt wird, auf, um anwendersignierte Dienstvereinbarungs-Verifizierungsinformation zu erzeugen. Die anwendersignierte Verifizierungsinformation wird darauf folgend zum Service-Provider weitergeleitet, um eine Verifizierung der Dienstvereinbarung basierend auf der Vertrauensbeziehung zwischen dem Service-Provider und dem Dienstvereinbarungsmanager zu ermöglichen.
  • Die Vorbereitung von Dienstvereinbarungsinformation in einer geeigneten elektronischen Form (von einem elektronischen Vertrag = e-Vertrag) wird normalerweise durch den Service-Provider in einer Vertragsvorbereitungs/Initialisierungseinheit 22 durchgeführt oder wenigstens initialisiert, aber diese Information könnte durch irgendeine der beteiligten Parteien vorbereitet werden, solange sowohl der Anwender als auch der Service-Provider die Vereinbarung akzeptieren. Beispielsweise könnte der Dienstvereinbarungsmanager 30 optional die Dienstvereinbarungsinformation im Auftrag des Service-Providers 20 vorbereiten.
  • Die kryptographische Verarbeitung der Dienstvereinbarungsinformation wird normalerweise auf der Anwenderseite in einem manipulationssicheren Modul 12 im Anwender-Endgerät 10 durchgeführt. Vorzugsweise führt das Anwender-Endgerät 10 die kryptographische Verarbeitung in einer Kryptographiemaschine 14 basierend auf einem Nichtablehnungsschlüssel durch, der lokal von dem gemeinsam genutzten geheimen Schlüssel abgeleitet ist, um die erforderliche Verifizierungsinformation zu erzeugen. Bei einigen Implementierungen kann die kryptographische Verarbeitung jedoch durch sowohl das Anwender-Endgerät 10 in der Kryptographiemaschine 14 als auch den Dienstvereinbarungsmanager 30 in der Kryptographiemaschine 34 durchgeführt werden.
  • Die bloße Tatsache, dass die anwendersignierte Verifizierungsinformation vom Anwender-Endgerät 10 sicher zum Service-Provider 20 weitergeleitet ist, kann einen Ablehnungsabhalteeffekt haben. Vorzugsweise wird jedoch eine Verifizierung online oder offline durch den Dienstvereinbarungsmanager durchgeführt, oder alternativ sogar direkt durch den Service-Provider. Bei der Offline-Prozedur wird Verifizierungsinformation einschließlich wenigstens eines anwendersignierten Verifizierungsteils, und vorzugsweise auch der entsprechenden Aufforderung oder einer anderen Eingabe zusammen mit der Anwenderidentität, normalerweise bei einer Speicherstelle gespeichert, von welcher sie später durch den Service-Provider 20 wiedergewonnen werden kann und als Nachweis dafür präsentiert werden kann, dass der Anwender die Dienstvereinbarung akzeptiert hat. Bei der Online-Prozedur wird die Verifizierungsinformation normalerweise mehr oder weniger direkt vom Service-Provider 20 zum Dienstvereinbarungsmanager 30 weitergeleitet, um somit einen Online-Nachweis zu ermöglichen. Basierend auf der präsentierten Verifizierungsinformation kann der Dienstvereinbarungsmanager 30 dann eine relevante Berechnung (relevante Berechnungen) und/oder einen Vergleich (Vergleiche) durchführen, um in der Verifizierungseinheit 36 zu verifizieren, dass der Anwender die Dienstvereinbarung tatsächlich akzeptiert hat.
  • Der Dienstvereinbarungsmanager kann angenehmerweise einer Datenbank zugeordnet sein, die Information über eine Anwender-ID und einen zugehörigen geheimen Schlüssel Ki für eine Gruppe von Anwendern enthält. Dies ermöglicht dem Dienstvereinbarungsmanager einen Zugriff auf den relevanten geheimen Schlüssel für einen gegebenen Anwender basierend auf der entsprechenden Anwender-ID für verschiedene Zwecke zu erlangen, wie beispielsweise ein Erzeugen von Anwenderauthentifizierungsparametern, eine kryptographische Verarbeitung von Dienstvereinbarungsinformation und/oder eine Dienstvereinbarungsverifizierung.
  • Wie es später erklärt werden wird, könnte eine Verifizierung alternativ direkt durch den Service-Provider 20 in einer Verifizierungseinheit 26 durchgeführt werden.
  • Die Vertrauensbeziehung zwischen dem Service-Provider 20 und dem Dienstvereinbarungsmanager 30 sollte Garantien für den Service-Provider über gemachte Angaben oder durch den Dienstvereinbarungsmanager zur Verfügung gestellte Daten liefern. Da die gesendete Information (z.B. Dienstvereinbarungsinformation, Gebührendaten, Authentifizierungsparameter und/oder andere geeignete Information) allgemein als empfindlich angesehen wird und die Identität der kommunizierenden Parteien wesentlich für die oben angegebenen Garantien ist, sollte die Kommunikationsverbindung zwischen dem Service-Provider und dem Dienstvereinbarungsmanager sicher sein. Dies könnte durch z.B. ein Verwenden von TLS oder IPSec oder durch Verschlüsseln/Signieren von individuellen Nachrichten erreicht werden.
  • Beispiele einer AKA-integrierten Nichtablehnung/Verifizierung von Dienstvereinbarungen
  • Es kann nützlich sein durch in Beschreiben der Erfindung in Zusammenhang mit einer AKA-integrierten Nichtablehnung/Verifizierung von Dienstvereinbarungen zu beginnen.
  • In einer Reihe von bevorzugten Ausführungsbeispielen ist eine Nichtablehnung von Dienstvereinbarungen und insbesondere von Dienstgebühren mit einer auf einer Aufforderung/Antwort basierenden Authentifizierungs- und Schlüsselvereinbarung (AKA) für einen Netzwerkzugriff (z.B. GMS/UMTS AKA oder eine ähnliche Authentifizierung) unter Verwendung desselben gemeinsam genutzten geheimen Schlüssels, der normalerweise für AKA verwendet wird, integriert. Ein großer Vorteil bei einer AKA-integrierten Nichtablehnung besteht darin, dass eine existierende Infrastruktur wieder verwendet werden kann.
  • In diesem Zusammenhang ist normalerweise angenommen, dass der vertrauenswürdige Dienstvereinbarungsmanager als Authentifizierungs/Bezahlungs-Manager zum Authentifizieren des Anwenders, zum Autorisieren des Anwenders für einen Zugriff auf einen Dienst und/oder zum Bilden eines Nachweises, dass der Anwender den Bedingungen für eine Verwendung eines Dienstes zugestimmt hat, handelt. In einem typischen Szenario kann ein Netzwerkbetreiber den Authentifizierungs/Bezahlungs-Manager als Sicherheitssystem zum Einrichten einer sicheren und vertrauenswürdigen Kommunikation mit einem Anwender und einer Zugriffsstelle implementieren. Der Betreiber hat auch Vertrauensbeziehungen mit Service-Providern und kommuniziert mit diesen über sichere Verbindungen. In Antwort auf eine Anforderung für einen Dienstzugriff verwendet der Authentifizierungs/Bezahlungs-Manager einen geheimen Schlüssel (der allgemein mit Ki bezeichnet ist), der mit dem anfordernden Anwender gemeinsam genutzt wird, um bei Authentifizierungs-, Autorisierungs-, Nichtablehnungs- und/oder Bezahlungs- oder Buchungs- bzw. Belastungsprozeduren zu helfen.
  • In Bezug auf Dienstbelastungen bzw. Dienstgebühren kann dann die Anwenderzustimmung zum Zahlen für einen Dienst mit der UMTS/GSM AKA oder einer ähnlichen Authentifizierung verbunden sein. Dies sollte vorzugsweise auf eine solche Weise durchgeführt werden, dass der Service-Provider sicher sein kann, dass der Anwender die Dienstverarbeitung zu einer späteren Stufe nicht abstreiten kann.
  • 5 ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine Nichtablehnung von Dienstvereinbarungen unter Verwendung eines bestimmten Nichtablehnungsschlüssels mit möglicher Offline-Verifizierung. Bei diesem Beispiel ist das normale Aufforderung/Antwort-(AKA)-Schema mit der Ableitung eines zusätzlichen Sessionschlüssels erweitert, der nur zwischen dem Anwender und der Betreiberseite gemeinsam genutzt werden wird, sowie zusätzlicher Dienstvereinbarungsinformation.
  • Es soll ein Anwender betrachtet werden, der wünscht, auf einen durch einen Service-Provider angebotenen Dienst zuzugreifen. Der Anwender muss typischerweise authentifiziert werden, bevor der Dienst angeboten wird. Die Anwender-ID muss keinen öffentlichen Identifizierer haben, sondern sie sollte eine Abbildung auf einen zu einem Anwender gehörenden geheimen Schlüssel Ki zulassen, der ermöglichen kann, dass eine Belastung richtig durchgeführt wird, z.B. zum richtigen Konto. Beispielsweise könnte der Schlüssel Ki ein Teilnahmeschlüssel sein, wenn der Anwender eine Teilnahme bei einem Heimatbetreiber hat, oder ein kryptographischer Schlüssel, zu dem ein im Voraus bezahltes Konto gehört. Der Transfer der Anwender-ID wird allgemein durch gestrichelte Linien angezeigt, da dies als Initialisierungsphase angesehen werden könnte, und teilweise auch deshalb, weil dies wahrscheinlich ein Teil der Stapelverarbeitung von Authentifizierungsvektoren zwischen dem Service-Provider und dem Betreiber ist. Es ist normalerweise erforderlich, dass der Service-Provider Information vom Anwender empfängt, die dazu verwendet werden kann, die Identität des Authentifizierungs/Bezahlungs-Managers zu bestimmen, zu welchem der Anwender gehört; wie beispielsweise die Identität des Heimatbetreibers des Anwenders. Dies ermöglicht dem Service-Provider, die Anwender-ID bei einer Anforderung nach AKA-Parametern zum relevanten Authentifizierungs/Bezahlungs-Manager weiterzuleiten. Basierend auf der empfangenen Anwender-ID identifiziert der Authentifizierungs/Bezahlungs-Manager den geheimen Schlüssel Ki und erzeugt geeignete AKA-Parameter. Der Authentifizierungs/Bezahlungs-Manager erzeugt eine Zufallsaufforderung RAND und berechnet eine erwartete Antwort XRES basierend auf dem geheimen Schlüssel Ki und der Zufallsaufforderung RAND als Eingabe zu einer gegebenen Funktion g und erzeugt auch die gewöhnlichen Integritäts- und Vertrauensschlüssel Ik, Ck basierend auf Ki und RAND.
  • Der Anwender sollte auch zustimmen, für den Dienst zu bezahlen. Die Zustimmung sollte so sein, dass der Service-Provider später nachweisen kann, dass der Anwender wirklich zustimmte. Die Idee besteht hier darin, einen zusätzlichen Schlüssel, der mit Rk bezeichnet ist, für eine Nichtablehnung der Dienstvereinbarung zu der gleichen Zeit zu erzeugen, wie die Anwender-Authentifizierungs- und Schlüsselvereinbarung durchgeführt wird und Authentifizierungsparameter, wie beispielsweise RAND und XRES, sowie Integritäts- und Vertrauensschlüssel Ik, Ck erzeugt werden.
  • Ein beispielhafter Basis-Signalaustausch wird nachfolgend zusammengefasst:
  • 1. RAND, AUTN, Ik, Ck, XRES
  • Der Service-Provider erzeugt Dienstvereinbarungsinformation einschließlich eines oder mehrerer Informationselemente, wie beispielsweise eine Identifikation des Dienstes, Dienstgebühren, Zeit bzw. Dauer einer Gültigkeit, Service-Provider-Identifizierer, usw. Im Folgenden wird die Dienstvereinbarungsinformation durch einen Kostenparameter COST_UNIT beispielhaft dargestellt, der einen gegebenen Wert, nämlich die Kosten einer Diensteinheit, anzeigt. Der Kostenparameter kann, wenn es erwünscht ist, begleitet sein von einer ad-hoc-Meldung zum Randomisieren von ihm, einem Zeitstempel zum Anzeigen einer Dauer einer Gültigkeit, einem Dienstidentifizierer und einem Service-Provider-Identifizierer.
  • 2. RAND, AUTN, LOST_UNIT
  • Der Anwender prüft den AUTN, und wenn er OK ist, berechnet er die Antwort RES, den Vertrauensschlüssel Ck und den Integritätsschlüssel Ik wie bei dem standardmäßigen AKA-Schema. Zusätzlich dazu erzeugt das erweiterte AKA-Schema einen Nichtablehnungsschlüssel Rk, der auch auf dem gemeinsam genutzten geheimen Schlüssel Ki und RAND basiert. Der Rk wird dann dazu verwendet, einen MAC (Message Authentification Code = Nachrichtenauthentifizierungscode), den COST_MAC, über RAND und COST_UNIT zu berechnen. COST_MAC = MAC(Rk, RAND||COST_UNIT). Der COST_MAC wird zusammen mit RES, der Antwort zur Authentifizierung, zum Service-Provider zurückgebracht. Der Service-Provider darf den COST_MAC für das System nicht fälschen bzw. imitieren können, um das Ziel einer Nichtablehnung zu erreichen.
  • 3. RES, COST_MAC
  • Der Service-Provider prüft, dass RES mit XRES übereinstimmt. Der Service-Provider hält auch Verifizierungsinformation, wie beispielsweise die Anwender-ID, RAND, LOST_UNIT und COST_MAC, für einen späteren Nachweis der Anwenderzustimmung zurück.
  • Wenn es erwünscht oder erforderlich ist, kann der Service-Provider später die Verifizierungsinformation zu dem Authentifizierungs/Bezahlungs-Manager auf der Betreiberseite weiterleiten.
  • 4. COST_UNIT, COST_MAC, ANWENDER-ID, RAND
  • Der Authentifizierungs/Bezahlungs-Manager auf der Betreiberseite handelt dann als Verifizierer und prüft, dass COST_MAC gleich dem erweiterten XMAC=MAC(Rk, RAND||COST_UNIT) ist, um zu verifizieren, dass der Anwender die Dienstvereinbarung und die Dienstkosten akzeptiert hat.
  • Natürlich gibt es ein Risiko, dass der Anwender den COST_MAC fälscht. Dafür kann eine Strategie eines zufälligen Online-Testens des COST_MAC verwendet werden, um Anwender von solchen Aktionen abzuhalten.
  • Im Wesentlichen basiert dieser beispielhafte Ansatz auf einem Erweitern der Basis-AKA mit einem Nichtablehnungsschlüssel, der zwischen einem Betreiber und einem Anwender gemeinsam genutzt wird, der aber nicht zum Service-Provider verteilt wird. Dieser Nichtablehnungsschlüssel kann durch den Anwender zum "Signieren" von Nachrichten verwendet werden, welche der Betreiber verifizieren kann. Wie es oben beschrieben ist, besteht eine beispielhafte Lösung darin, MAC-Daten zusammen mit RAND unter Verwendung eines von RAND abgeleiteten Schlüssels zum Anwender zu senden und die Authentizität der Daten zu verifizieren.
  • Wie es verstanden werden sollte, ist es gleichermaßen möglich, zuerst die normale AKA-Signalgabe durchzuführen, die verifiziert, dass RES gleich XRES ist, und zwar bei dem Service-Provider, und später, wenn der Anwender einen Dienst über die gesicherte Verbindung zum Service-Provider anfordert, die Nichtablehnungssignalgabe durchzuführen. Dies bedeutet, dass der Service-Provider nach einer erfolgreichen Anwenderauthentifizierung den Kostenparameter COST_UNIT und zugehörige Information auf eine Dienstanforderung vom Anwender hin zum Anwender sendet. Der Anwender berechnet dann den COST_MAC und bringt den COST_MAC zum Service-Provider zurück, um eine Verifizierung der Dienstvereinbarung zu ermöglichen.
  • 6A ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine Online-Verifizierung von Dienstvereinbarungen unter Verwendung eines bestimmten Nichtablehnungsschlüssels. Dieses Beispiel enthält eine Online-Anwenderauthentifizierung und -verifizierung der Dienstvereinbarung.
  • Ein beispielhafter Basis-Signalaustausch ist nachfolgend zusammengefasst:
  • 1. RAND, AUTN
  • Der Service-Provider erzeugt die relevante Dienstvereinbarungsinformation wie beispielsweise einen Dienstkostenparameter COST_UNIT für einen Transfer zum Anwender.
  • 2. RAND, AUTN, COST_UNIT.
  • Der Anwender prüft den AUTN, und wenn er OK ist, berechnet er die Antwort RES, den Vertrauensschlüssel Ck, den Integritätsschlüssel Ik und den Nichtablehnungsschlüssel Rk. Der COST_MAC wird berechnet und zusammen mit RES, der Antwort zur Authentifizierung, zum Service-Provider zurückgebracht.
  • 3. RES, COST_MAC
  • Für eine Online-Authentifizierung leitet der Service-Provider RES weiter zur Betreiberseite. Die COST_UNIT- und COST_MAC-Information können gleichzeitig an RES angehängt werden.
  • 4. RES, LOST_UNIT, COST_MAC
  • Der Authentifizierungs/Bezahlungs-Manager prüft, ob RES gleich der erwarteten Antwort (XRES) ist, und dass COST_MAC gleich dem erwarteten XMAC ist. Wenn der Anwender ein im Voraus bezahltes Konto hat, kann der Manager auch prüfen, dass der Anwender einen ausreichenden Betrag auf seinem Konto hat. Wenn diese Bedingungen erfüllt sind, werden die Schlüssel zum Service-Provider gesendet.
  • 5. Ik, Ck
  • Wenn der Service-Provider die Schlüssel zum Schützen der Session zwischen einem Anwender und einem Service-Provider empfängt, zeigt dies auch an, dass die Dienstvereinbarung OK ist.
  • Alternativ dazu ist es, wie es zuvor unter Bezugnahme auf den Offline-Fall diskutiert ist, möglich, zuerst die normale AKA-Signalgabe durchzuführen, und später, wenn der Anwender über die gesicherte Verbindung zum Service-Provider einen Dienst anfordert, die Nichtablehnungssignalgabe durchzuführen. Dies bedeutet allgemein, dass RES verifiziert wird und die Schlüssel Ik, Ck zum Service-Provider gesendet werden und darauf folgend die spezielle Nichtablehnungssignalgabe durch den Service-Provider auf eine Dienstanforderung hin initiiert wird. Im Folgenden werden jedoch die AKA-integrierten Beispiele hauptsächlich mit integriertem AKA und einer Nichtablehnungssignalgabe beschrieben werden.
  • 6B ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine Online-Verifizierung von Dienstvereinbarungen unter Verwendung eines existierenden AKA-Schlüssels als Nichtablehnungsschlüssel. Wenn der Service-Provider immer eine Online-Verifizierung der Dienstverarbeitung durchführt, bevor die Schlüssel von der Betreiberseite gesendet werden, dann könnte der COST_MAC mit Ik als Nichtablehnungsschlüssel erzeugt werden, und es wäre nicht nötig, die AKA zu erweitern, um einen speziellen Nichtablehnungsschlüssel Rk zu erzeugen. Jedoch würde der Service-Provider nicht die Fähigkeit haben, einen Nachweis für die Dienstvereinbarung aufzuzeichnen und zu halten, wenn er den Schlüssel Ik später empfangen würde, um für einen Integritätsschutz der Session verwendet zu werden. Der Betreiber kann eine Hash-Codierung der Vereinbarung halten, so dass der Service-Provider Daten nicht rückwirkend ändern kann.
  • Nichtablehnung, kombiniert mit maskierten Authentifizierungsdaten
  • Wie es in den 7A und B dargestellt ist, kann die Anwenderauthentifizierung modifiziert werden, um einen Nachweis einer Identifizierung durch eine Einführung von maskierten Verifizierungsdaten zuzulassen, um dadurch einem Service-Provider zu ermöglichen, einen gültigen Beweis zu präsentieren, dass ein Anwender tatsächlich authentifiziert worden ist.
  • Die gesamte Authentifizierung basiert anfänglich auf einer Aufforderung/Antwort-Prozedur, in welcher der Authentifizierungs/Bezahlungs-Manager eine erwartete Antwort XRES erzeugt und der Anwender darauf folgend eine entsprechende Antwort RES erzeugt. Eine Grundidee besteht hier im Einführen einer Maskierungsfunktion f, die die erzeugte erwartete Antwort maskiert, und im Senden der maskierten erwarteten Antwort XRES' anstelle der anfänglichen erwarteten Antwort XRES zum Service-Provider. Der Anwender erzeugt und sendet eine entsprechende Anwenderantwort RES auf herkömmliche Weise und der Service-Provider empfängt somit eine maskierte erwartete Antwort XRES' von der Betreiberseite, sowie die gewöhnliche Anwenderantwort RES vom Anwender. Der Service-Provider berechnet dann eine maskierte Anwenderantwort RES' mittels eines Falls derselben Maskierungsfunktion, die auf der Betreiberseite verwendet wurde. Um den Anwender zu authentifizieren, verifiziert der Service-Provider einfach, dass die berechnete maskierte Anwenderantwort RES' der von der Betreiberseite empfangenen maskierten erwarteten Antwort XRES' entspricht. Die Maskierungsprozedur ermöglicht dem Service-Provider nachzuweisen, dass der Anwender richtig authentifiziert worden ist, und verhindert gleichzeitig auch Abfangangriffe und/oder macht sie unschädlich.
  • Der Service-Provider kann dann aufgefordert werden, Antwortwerte zu liefern, oder vorzugsweise Antwort/Aufforderungs-Paare, und/oder Dienstvereinbarungs-Verifizierungsinformation, um nachzuweisen, dass Anwender tatsächlich im Netzwerk vorhanden gewesen sind und/oder andere Dienste benutzt haben, bevor Bezahlungen transferiert werden.
  • Offensichtlich haben der Authentifizierungs/Bezahlungs-Manager und der Service-Provider eine Beziehung, die impliziert, dass die Maskierungsfunktion zwischen dem Authentifizierungs/Bezahlungs-Manager und dem Service-Provider ausgetauscht worden ist. Dies gilt auch für ähnliche Information und/oder Funktionen, die für die zwei Parteien gemeinsam sein müssen.
  • 7A ist ein schematisches beispielhaftes Signalaustauschdiagramm zum Bilden eines Nachweises einer Anwenderauthentifizierung mittels maskierter Authentifizierungsdaten in Kombination mit einer Offline-Verifizierung von Dienstvereinbarungen. Zusätzlich zu den gewöhnlichen AKA-Parametern erzeugt der Authentifizierungs/Bezahlungs-Manager eine maskierte erwartete Antwort XRES' als Funktion von XRES und eine optionale maskierende Zufallsaufforderung SALT. Beispielsweise kann die maskierende Zufallsaufforderung auf der Zufallsaufforderung RAND basieren oder als vollständig unabhängiger Zufallswert erzeugt sein. Darauf folgend werden die maskierte erwartete Antwort XRES' und die Zufallsaufforderung RAND möglicherweise zusammen mit der optionalen maskierenden Zufallsaufforderung SALT zum Service-Provider gesendet. Wenn eine Offline-Verifizierung der Dienstvereinbarung mit Rk verwendet wird, dann können Ik und Ck zusammen mit RAND, AUTN und XRES' verteilt werden.
  • Ein beispielhafter Basis-Signalaustausch ist nachfolgend zusammengefasst:
  • 1. RAND, AUTN, XRES', Ik, Ck [SALT]
  • 2. RAND, AUTN, COST_UNIT
  • 3. RES, COST_MAC
  • Der Service-Provider erzeugt dann RES' unter Verwendung eines Falls derselben Maskierungsfunktion f und derselben Zufallseingabe RAND/SALT und prüft, dass die maskierte Antwort RES' gleich der maskierten erwarteten Antwort XRES' ist. Der Service-Provider speichert vorzugsweise RES, RAND, ANWENDER-ID als Authentifizierungsnachweisinformation zusammen mit COST_UNIT, COST_MAC als Dienstvereinbarungs-Verifizierungsinformation bei einer geeigneten Stelle für eine spätere Wiedergewinnung, wenn es nötig ist, als Beweis für die Anwenderauthentifizierung und die Dienstvereinbarung. Wenn er durch den Authentifizierungs/Bezahlungs-Manager oder irgendeine andere zugehörige Partei aufgefordert wird, einen Nachweis für die Authentifizierung eines gegebenen Anwenders und die akzeptierte Dienstvereinbarung zur Verfügung zu stellen, kann der Service-Provider die Information zur Betreiberseite senden.
  • 4. RES, RAND, ANWENDER-ID, COST_UNIT, COST_MAC
  • Es sollte beachtet werden, dass Stapel einer randomisierten Dienstvereinbarungs-Verifizierungsinformation für eine Anzahl von Diensten, die durch den Service-Provider geliefert werden, offline ohne irgendeine erneute Authentifizierung transferiert werden kann.
  • Vorzugsweise gewinnt der Authentifizierungs/Bezahlungs-Manager dann den geheimen Schlüssel Ki verbunden mit dem gegebenen Anwender wieder und berechnet den erwarteten Antwortwert XRES basierend auf dem empfangenen RAND und dem geheimen Schlüssel Ki und vergleicht schließlich den empfangenen RES-Wert mit dem berechneten XRES-Wert, um zu verifizieren, ob der Anwender tatsächlich beim Service-Provider authentifiziert worden ist. Wenn der RES-Wert mit dem XRES-Wert übereinstimmt, wird die Nachweisinformation als gültig angesehen. Auf dieselbe Weise berechnet der Authentifizierungs/Bezahlungs-Manager die erwartete Dienstvereinbarungs-Verifizierungsinformation XMAC basierend auf dem Nichtablehnungsschlüssel Rk und RAND, COST_UNIT, die vom Service-Provider empfangen sind. Der Authentifizierungs/Bezahlungs-Manager vergleicht dann COST_MAC mit XMAC zum Verifizieren der Dienstvereinbarung.
  • Alternativ dazu sendet der Service-Provider einfach den RES-Wert und die Anwender-ID eines gegebenen Anwenders. In diesem Fall muss der Authentifizierungs/Bezahlungs-Manager typischerweise XRES-Werte (oder RAND-Werte, die eine Neuberechnung von entsprechenden XRES-Werten zulassen) für die Anwender speichern, so dass ein Vergleich zwischen RES und XRES durchgeführt werden kann.
  • Wenn die optionale Maskierungszufallsaufforderung SALT nicht explizit vom Authentifizierungs/Bezahlungs-Manager gesendet wurde, kann der Service-Provider sie vor einer Verifizierung oder Authentifizierung vorzugsweise basierend auf der Zufallsaufforderung RAND ableiten. Eine maskierte Anwenderantwort RES' wird dann durch den Service-Provider mittels der Anwenderantwort RES und der optionalen, empfangenen oder abgeleiteten, Maskierungszufallsaufforderung SALT als Eingabe zur Maskierungsfunktion f berechnet.
  • Wie es oben angegeben ist, ist die Maskierungszufallsaufforderung SALT optional und kann von der Authentifizierungsprozedur weggelassen werden. In einem solchen Fall wird keine Zufallsaufforderung SALT zur Maskierungsfunktion f zum Berechnen der maskierten erwarteten Antwort XRES' bzw. der maskierten Anwenderantwort RES' eingegeben. Jedoch ist zum Erhöhen der Sicherheit und insbesondere zum Abwenden von Angriffen vor einer Berechnung die Maskierungszufallsaufforderung SALT vorzugsweise als Maskierungsfunktionseingabe enthalten. Somit könnte die Maskierungszufallsaufforderung SALT als ein vollständiger Zufallswert durch den Authentifizierungs/Bezahlungs-Manager erzeugt und darauf folgend zusammen mit der maskierten erwarteten Antwort XRES' und der Zufallsaufforderung RAND zum Service-Provider gesendet werden. Jedoch könnte, um eine zusätzliche Signalgabe zwischen der Betreiberseite und dem Service-Provider zu vermeiden, die Maskierungszufallsaufforderung SALT alternativ von der Zufallsaufforderung RAND abgeleitet werden. In diesem Fall erzeugt der Authentifizierungs/Bezahlungs-Manager vorzugsweise die Maskierungszufallsaufforderung SALT durch eine Funktion h der Zufallsaufforderung RAND. Somit muss keine spezielle Maskierungszufallsaufforderung SALT zum Service-Provider gesendet werden, der statt dessen dieselbe Funktion h zum Erzeugen der Maskierungszufallsaufforderung SALT aus der Zufallsaufforderung RAND verwenden kann. Ein Beispiel für eine verwendbare maskierte Zufallsaufforderung SALT besteht einfach im Wiederverwenden der Zufallsaufforderung RAND als maskierte Zufallsaufforderung SALT, wobei h somit als eine Einheitsfunktion dargestellt ist.
  • Die Funktion h kann eine öffentliche Funktion sein, oder eine Funktion, die mit der Geschäftsvereinbarung zwischen dem Service-Provider und der legalen Partei (wie beispielsweise einem Heimatbetreiber) des Authentifizierungs/Bezahlungs-Managers verbunden ist und verteilt wird.
  • Die Maskierungsfunktion f, die einerseits durch den Authentifizierungs/Bezahlungs-Manager zum Erzeugen der maskierten erwarteten Antwort verwendet wird, und andererseits durch den Service-Provider zum Berechnen der maskierten Anwenderantwort, könnte eine Einwegefunktion und/oder eine Hash-Funktion sein. Vorzugsweise ist die Maskierungsfunktion eine kryptographische Hash-Funktion mit einer Einwegefunktionalität und Eigenschaften, die es unmöglich machen, zwei unterschiedliche Eingaben zu finden, die sich zu einem gemeinsamen Wert falten bzw. die durch eine Hash-Codierung zu einem gemeinsamen Wert kommen.
  • Die Maskierungsfunktion f kann eine öffentliche Funktion sein, oder eine private Funktion, die dem Authentifizierungs/Bezahlungs-Manager und dem Service- Provider bekannt ist. Im letzteren Fall könnte die private Maskierungsfunktion mit einer Geschäftsvereinbarung zwischen der legalen Partei, wie beispielsweise einem gegebenen Heimatbetreiber, des Authentifizierungs/Bezahlungs-Managers und dem Service-Provider verbunden sein. Wenn die legale Partei des Authentifizierungs/Bezahlungs-Managers, wie beispielsweise ein Heimatbetreiber, eine solche Geschäftsvereinbarung mit mehreren unterschiedlichen Service-Providern hat, kann eine entsprechende private Funktion durch den Betreiber für jeden Service-Provider verwendet werden, d.h. jede Betreiber/Provider-Vereinbarung wird in einer privaten Maskierungsfunktion manifestiert.
  • Um eine sanfte Migration in Bezug auf eine existierende Infrastruktur zuzulassen, wird der Service-Provider vorzugsweise diesbezüglich benachrichtigt, ob die Maskierungsfunktion verwendet worden ist oder nicht, wenn die verteilte erwartete Antwort berechnet wird. Somit wird das Protokoll zum Verteilen von Authentifizierungsparametern vorzugsweise mit einer solchen Indikation bzw. Anzeige erweitert. Gleichermaßen kann eine Anzeige in Bezug darauf, welche Maskierungsfunktion zu verwenden ist, im Protokoll enthalten sein, wenn eine Auswahl zwischen unterschiedlichen Maskierungsfunktionen vorhanden ist.
  • Wenn eine Online-Prozedur erwünscht ist, wie sie in 7B dargestellt ist, werden die Authentifizierungsnachweisinformation und die Dienstvereinbarungs-Verifizierungsinformation mehr oder weniger direkt vom Service-Provider zum Authentifizierungs/Bezahlungs-Manager weitergeleitet.
  • Ein beispielhafter Basis-Signalaustausch ist nachfolgend zusammengefasst:
  • 1. RAND, AUTN, XRES', [SALT]
  • 2. RAND, AUTN, COST_UNIT
  • 3. RES, COST_MAC
  • Der Service-Provider erzeugt RES' und prüft, dass die maskierte Antwort RES' gleich der maskierten erwarteten Antwort XRES' ist. Dann fährt die Signalgabe fort.
  • 4. RES, COST_UNIT, COST_MAC
  • Auf der Betreiberseite werden RES und COST_MAC jeweils mit XRES und XMAC verglichen. Wenn die Verifizierung erfolgreich ist, werden die Schlüssel sicher zum Service-Provider transferiert.
  • 5. Ik, Ck
  • Wie es zuvor diskutiert ist, ist es für eine Online-Verifizierung einer Dienstvereinbarung möglich, entweder einen bestimmten Nichtablehnungsschlüssel Rk oder den Integritätsschlüssel Ik als Nichtablehnungsschlüssel zum Berechnen der Parameter COST_MAC und XMAC zu verwenden.
  • Für mehr Informationen über die Maskierungsprozedur wird Bezug genommen auf unsere gleichzeitig anhängige US-Patentanmeldung mit der seriellen Nr. 10/278,362, eingereicht am 22. Oktober 2002, die hierin enthalten ist.
  • Beispielhafter ticketbasierender Ansatz
  • Im Folgenden werden wir einige Beispiele einer AKA-integrierten Nichtablehnung von Dienstvereinbarungen mit einem ticketbasierenden Ansatz beschreiben.
  • Ticketbasierende Bezahlungssysteme im Allgemeinen sind in der Literatur wohlbekannt, siehe beispielsweise das US-Patent Nr. 5,739,511.
  • Ein bestimmtes Ticketsystem basiert auf der Idee, dass ein Basisticket BASE TICKET für eine gegebene Anzahl N von Malen durch eine bekannte Hash-Funktion durch wiederholtes Hash-Codieren in ein START TICKET gebracht wird:
    START_TICKET = HASH(HASH( .. HASH(BASE_TICKET))),
    wobei das BASE_TICKET typischerweise TICKET N entspricht und das START_TICKET TICKET_0 entspricht. Die zahlende Partei erzeugt ein Vorabbild von START_TICKET oder dem letzten verwendeten TICKET. Die Partei, die die Bezahlung empfängt, kann dann prüfen, dass das Vor-Abbild durch eine Hash-Codierung zu diesem Ticket wird. Da die Tickets durch die Hash-Funktion oder eine andere geeignete Einwegefunktion wechselseitig aufeinander bezogen sind, kann das START_TICKET durch wiederholtes Anwenden der Funktion von irgendeinem weiteren Ticket erhalten werden. Dies bedeutet, dass eine Prüfung des Fortschreitens der Bezahlungstransaktion ohne die Notwendigkeit für ein wiederholtes Durchführen eines komplexen und zeitaufwändigen Verifizierungsprozesses erhalten werden kann. Die Anzahl von Malen, für welche die Hash-Funktion angewendet werden muss, um das Startticket zu erhalten, ist direkt auf die Anzahl von Tickets bezogen, die durch den Anwender des Dienstes verbraucht werden.
  • Eine Bedingung dafür, dass ein solches auf einem Ticket basierendes System sicher ist, besteht darin, dass das Basisticket nicht vorhersagbar ist. Das Basisticket kann somit durch eine Verkettung von irgendeiner Zufallseinheit bzw. Zufallsgröße und einer Hash-Codierung von anderen bekannten Informationselementen gebildet werden.
  • Gemäß der Erfindung kann das zuvor beschriebene Nichtablehnungsschema mit seinen Varianten auf eine derartige Weise erweitert werden, dass der Anwender ein START_TICKET und einen verschlüsselten Nichtablehnungs-MAC, der mit TICKET_MAC bezeichnet ist, von START_TICKET und COST_UNIT zurückbringen kann, um nicht ablehnbare Bezahlungen für mehrere Ereignisse/Dienste zu ermöglichen, ohne wiederholten Kontakt mit dem Betreiber zu haben oder eine neue Anwenderauthentifizierung durchzuführen.
  • Es gibt mehrere Varianten diesbezüglich, wie das START_TICKET erzeugt werden kann. Ein Hauptmerkmal wäre es, dass der Service-Provider zum Verifizieren fähig sein sollte, dass das START_TICKET ursprünglich ist und durch den authentifizierten Anwender oder im Auftrag von diesem ausgegeben wird.
  • Eine bestimmte Lösung für eine Ticketerzeugung besteht darin, dass der Anwender das BASE_TICKET erzeugt und das START_TICKET ableitet. Der Anwender verwendet dann einen Nichtablehnungsschlüssel, wie beispielsweise Rk und berechnet einen Nichtablehnungs-TICKET_MAC über das START_TICKET und die COST_UNIT und sendet das START_TICKET und den TICKET_MAC zum Service-Provider. Der Service-Provider speichert entweder die Verifizierungsinformation für eine optionale letztere Verifizierung in einer Offline-Prozedur oder sendet die Nachricht online zur Betreiberseite zur Verifizierung des TICKET_MAC zum Akzeptieren der Tickets.
  • 8A ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine auf einem Ticket basierende Nichtablehnung mit möglicher Offline-Verifizierung.
  • Ein grundsätzlicher beispielhafter Signalaustausch ist nachfolgend zusammengefasst:
  • 1. RAND, AUTN, Ik, Ck, XRES
  • Der Service-Provider erzeugt die relevante Dienstvereinbarungsinformation, die hier beispielhaft durch den Kostenparameter COST_UNIT dargestellt ist, und leitet vorzugsweise diese Information mit den nötigen AKA-Parametern zum Anwender weiter.
  • 2. RAND, AUTN, COST_UNIT
  • Der Anwender prüft den AUTN, und wenn er OK ist, berechnet er RES, die Schlüssel Ik, Ck und vorzugsweise auch Rk. Der Anwender erzeugt ein BASE_TICKET und leitet das START_TICKET durch wiederholtes Hash-Codieren für eine ausgewählte Anzahl von Malen ab. Rk wird dann zum Berechnen von TICKET_MAC über START_TICKET und COST_UNIT verwendet.
  • TICKET_MAC = MAC(Rk, START TICKET||COST_UNIT). Wenn eine explizite Randomisierung erwünscht ist, könnte TICKET_MAC alternativ als MAC (Rk, START_TICKET||COST_UNIT||RAND) berechnet werden. Der TICKET_MAC und das START_TICKET werden zusammen mit RES zum Service-Provider zurückgebracht.
  • 3. RES, START_TICKET, TICKET_MAC
  • Der Service-Provider hält Verifizierungsinformation, wie beispielsweise die Anwender-ID, RAND, COST_UNIT und COST_MAC für einen späteren Nachweis der Anwenderzustimmung zurück.
  • Wenn die Tickets durch den Anwender verbraucht werden, prüft der Service-Provider für jedes Ticket TICKET_i-1=HASH(TICKET_i) oder dass das START_TICKET durch wiederholtes Anwenden der Hash-Funktion erhalten werden kann.
  • Wenn es erwünscht oder angefordert ist, kann der Service-Provider später Verifizierungsinformation, wie beispielsweise COST_UNIT, START_TICKET, LAST_TICKET und TICKET_MAC, zum Authentifizierungs/Bezahlungs-Manager auf der Betreiberseite weiterleiten. Dies ermöglicht, dass der Authentifizierungs/Bezahlungs-Manager den TICKET_MAC verifiziert und die Anzahl von verbrauchten Tickets bestimmt, um den Anwender mit dem richtigen Betrag zu belasten.
  • 8B ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine auf einem Ticket basierende Nichtablehnung mit Online-Verifizierung. Dieses Beispiel enthält eine Online-Anwenderauthentifizierung und eine auf einem Ticket basierende Verifizierung der Dienstvereinbarung.
  • Ein grundsätzlicher beispielhafter Signalaustausch ist nachfolgend zusammengefasst:
  • 1. RAND, AUTN
  • Der Service-Provider erzeugt die relevante Dienstvereinbarungsinformation, wie beispielsweise einen Dienstkostenparameter COST_UNIT für einen Transfer zum Anwender.
  • 2. RAND, AUTN, COST_UNIT.
  • Der Anwender prüft den AUTN, und wenn er OK ist, berechnet er RES, die Schlüssel Ik, Ck und vorzugsweise auch Rk. Der Anwender erzeugt ein BASE_TICKET und leitet das START_TICKET ab, und dann wird ein TICKET_MAC berechnet. Der TICKET_MAC und das START_TICKET werden zusammen mit RES zum Service-Provider zurückgebracht.
  • 3. RES, START_TICKET, TICKET_MAC
  • Für eine Online-Authentifizierung und -Verifizierung leitet der Service-Provider RES zur Betreiberseite weiter. Die Information über COST_UNIT, START_TICKET und TICKET_MAC können gleichzeitig an RES angehängt werden.
  • 4. RES, COST_UNIT, START_TICKET, TICKET_MAC
  • Der Authentifizierungs/Bezahlungs-Manager prüft, ob RES gleich der erwarteten Antwort (XRES) ist, und dass TICKET_MAC gleich dem erwarteten XMAC ist. Wenn diese Bedingungen erfüllt sind, werden die Schlüssel zum Service-Provider gesendet.
  • 5. Ik, Ck
  • Der Anwender beginnt dann ein Verbrauchen von Tickets und der Service-Provider prüft die Tickets. Das letzte Ticket LAST_TICKET, das empfangen wird, wird schließlich vom Service-Provider zur Betreiberseite zur Verifizierung und darauf folgenden Handhabung der Bezahlung weitergeleitet.
  • 9 ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine auf einem Ticket basierende Nichtablehnung, wobei das Basisticket durch den Authentifizierungs/Bezahlungs-Manager im Auftrag des Anwenders vorbereitet wird. Bei diesem Beispiel erzeugt die Betreiberseite das BASE_TICKET basierend auf COST_UNIT-Information und anderen relevanten Daten, die vom Service-Provider empfangen sind (oder durch den Betreiber im Auftrag des Service-Providers vorbereitet sind), und leitet das START_TICKET ab. Der Betreiber verschlüsselt dann das BASE_TICKET mit einem Nichtablehnungsschlüssel, wie beispielsweise Rk, in ENC_TICKET = ENC(Rk, BASE_TICKET) und sendet es zusammen mit dem START_TICKET zum Service-Provider. Der Service-Provider leitet dann das ENC_TICKET, vorzugsweise zusammen mit RAND und AUTN, zum Anwender weiter, der das BASE_TICKET durch eine Entschlüsselung extrahieren kann. Der Anwender ist dann zum Ableiten des START_TICKET fähig und kann ein Verbrauchen von Tickets beginnen, wenn der Service-Provider einmal einen Zugriff auf die nötigen Sessionschlüssel Ik, Ck hat. Eine Nichtablehnung wird sichergestellt, da nur der Anwender das BASE_TICKET entschlüsseln und somit richtige Vorabbilder erzeugen kann.
  • Ein grundsätzlicher beispielhafter Signalaustausch für den Online-Fall ist nachfolgend zusammengefasst:
  • 1. RAND, AUTN, ENC_TICKET, START_TICKET
  • 2. RAND, AUTN, ENC_TICKET.
  • Der Anwender prüft den AUTN, und wenn er OK ist, berechnet er RES, die Schlüssel Ik, Ck und vorzugsweise auch Rk. Angenehmerweise regeneriert der Anwender das BASE_TICKET durch Entschlüsseln des ENC_TICKET unter Verwendung von Rk und leitet dann das START_TICKET ab. Der Anwender bringt RES zum Service-Provider zurück.
  • 3. RES
  • Für eine Online-Anwenderauthentifizierung leitet der Service-Provider RES zur Betreiberseite weiter.
  • 4. RES
  • Der Authentifizierungs/Bezahlungs-Manager prüft, ob RES gleich der erwarteten Antwort XRES ist, und sendet die Sessionschlüssel auf eine erfolgreiche Authentifizierung hin zum Service-Provider.
  • 5. Ik, Ck
  • Der Anwender beginnt dann ein Verbrauchen von Tickets und der Service-Provider prüft die Tickets. Das LAST_TICKET, das empfangen wird, wird schließlich vom Service-Provider zur Betreiberseite zur Verifizierung und darauf folgenden Handhabung der Bezahlung weitergeleitet.
  • Es sollte verstanden werden, dass die Ticketgebungsprozedur nicht in der Authentifizierungsstufe der gesamten Signalgabe enthalten sein muss, sondern später durchgeführt werden könnte.
  • Allgemeine Vertragsunterzeichnung bzw. -signierung
  • Wie es zuvor angezeigt ist, kann die Dienstvereinbarungsinformation ein allgemeiner elektronischer Vertrag sein. Für eine allgemeine Vertragssignierung enthält ein speziell entwickeltes Ausführungsbeispiel, das eine Offline-Verifizierung durch den Service-Provider zulässt, eine Maskierung von sowohl durch den Dienstvereinbarungsmanager erzeugter erwarteter Verifizierungsinformation als auch von anwendersignierter Verifizierungsinformation mittels lokaler Fälle derselben Maskierungsfunktion.
  • Die nachfolgende Lösung zum Signieren eines Vertrags, der verschiedene Dienstvereinbarungsinformationen enthält, hat Ähnlichkeiten mit dem auf einem Ticket basierenden System für Bezahlungen, das oben beschrieben ist, und macht in ihrer Basisform auch Verwendung von einem Maskierungsmechanismus, der ähnlich demjenigen ist, der für eine Nichtablehnung einer Anwenderauthentifizierung verwendet wird.
  • Die Lösung basiert auf der Annahme, dass der Anwender und ein allgemeiner Dienstvereinbarungsmanager ein gemeinsam genutztes Geheimnis haben. Wenn man sich etwas mehr auf den Bezahlungsteil der Gesamtprozedur konzentriert, wird der Dienstvereinbarungsmanager im Folgenden manchmal Bezahlungsprovider genannt. Wenn der Bezahlungsprovider ein zellularer GSM/UMTS-Betreiber ist, existiert ein solches gemeinsam genutztes Geheimnis, und es ist in dem (U)SIM auf der Anwenderseite gespeichert. Eine relativ generische Einstellung ist in 10 dargestellt.
  • Vorzugsweise bereitet der Service-Provider 20 oder der Bezahlungsprovider 30 den Vertrag vor, damit er durch den Anwender 10 signiert bzw. unterschrieben wird. Typischerweise wird der Vertrag dann sicher zu allen relevanten Parteien verteilt. Der Bezahlungsprovider 30 auf der Betreiberseite verwendet das gemeinsam genutzte Geheimnis in einer verschlüsselten Hash-Funktion zum Berechnen eines verschlüsselten Hash-Codes, der als Signatur MAC bezeichnet ist, des Vertrags. Die verschlüsselte Hash-Funktion kann entweder als wahrer verschlüsselter Hash-Code oder als Hash-Code, dem eine verschlüsselte Funktion folgt, durchgeführt werden. Eine bestimmte Lösung, die zu dem AKA- und dem (U)SIM-Fall passt, besteht in einer Hash-Codierung des Vertrags in eine Variable RAND_CONT entsprechend dem normalen RAND in der AKA-Prozedur und in einem Zuführen von diesem RAND CONT in die AKA-Prozedur und auf diese Weise im Erzeugen einer Signatur MAC entsprechend der normalen RES. Die Signatur MAC kann auch mit der Hilfe von einem der Schlüssel erzeugt werden, die aus der AKA-Prozedur herauskommen. Dieses nimmt normalerweise an, dass entweder eine richtige AUTN-Variable verfügbar ist oder dass der Sequenznummernprüfmechanismus gesperrt ist.
  • Die Signatur MAC wird dann durch eine (öffentliche) Maskierungsfunktion (dies bezieht sich auf eine Generalisierung bzw. Verallgemeinerung der zuvor beschriebenen Maskierungsfunktion f) geführt. Die Maskierungsfunktion ist eine kryptographische Hash-Funktion, d.h. es ist in der Praxis unmöglich, die Vorabbildung einer Ausgabe von der Funktion zu finden. Die maskierte Signatur MAC wird zu dem Service-Provider 20 gesendet, um durch ihn zum Verifizieren der Anwendersignierung des Vertrags verwendet zu werden.
  • Wenn der Anwender den Vertrag signiert, verwendet er auch das gemeinsam genutzte Geheimnis und berechnet die Signatur MAC mittels einer verschlüsselten Hash-Funktion. Der Anwender sendet die Signatur MAC zum Service-Provider, der die öffentliche Maskierungsfunktion kennt und somit die Signatur prüfen kann.
  • Zum Zuteilen einer einfachen Prozedur zum Anwender, um die Authentizität des Vertrags zu prüfen, könnte die maskierte Signatur MAC gleichzeitig mit dem Vertrag selbst zum Anwender gesendet werden. Der Vertrag kann auch andere Information enthalten, die in der vollständigen Bezahlungsprozedur verwendet wird, wie z.B. SALT, was in der öffentlichen Maskierungsfunktion verwendet wird.
  • Wenn die AKA-Prozedur verwendet wird, fasst sich die Vertragssignierungsidee zusammen, um RAND in der AKA-Prozedur ein HASH der Vertragsdaten sein zu lassen, die der Anwender signieren soll.
  • 11 ist ein schematisches beispielhaftes Signalaustauschdiagramm für die Vertragssignierungsimplementierung der 10, wenn eine AKA-Prozedur wieder verwendet wird.
  • Auf eine Dienstanfrage vom Anwender hin leitet der Service-Provider die empfangene ANWENDER-ID möglicherweise zusammen mit dem Vertrag CONT, wenn dieser durch den Service-Provider vorbereitet ist, zu dem Dienstvereinbarungsmanager weiter. Der Dienstvereinbarungsmanager kann einen RAND_CONT als Funktion y des Vertrags CONT erzeugen. Der Dienstvereinbarungsmanager berechnet dann eine erwartete Signatur MAC, die mit XMAC bezeichnet ist, basierend auf Ki und RAND_CONT:XMAC = g(Ki, RAND_CONT). Diese Signatur MAC wird dann durch eine allgemeine Maskierungsfunktion M in eine maskierte erwartete Signatur MAC, die mit XMAC' bezeichnet ist, unter optionaler Verwendung einer Zufallsmaskierungsaufforderung RAND/SALT als zusätzliche Eingabe zur Maskierungsfunktion maskiert.
  • 1. XMAC', RAND/SALT
  • Der Service-Provider leitet dann den Vertrag CONT zum Anwender weiter.
  • 2. CONT
  • Unter Verwendung eines Falls der Funktion y erzeugte Anwender RAND CONT, wenn dieser Parameter nicht von der Betreiberseite weitergeleitet wird, und berechnet auch die Anwendersignatur MAC basierend auf Ki und RAND CONT: MAC = g (Ki, RAND_CONT). Dieser MAC wird zum Service-Provider weitergeleitet.
  • 3. MAC
  • Der Service-Provider kann dann einen Fall der allgemeinen Maskierungsfunktion m zum Berechnen einer maskierten Anwendersignatur MAC, die mit MAC' bezeichnet ist, verwenden und schließlich den berechneten MAC' mit dem von der Betreiberseite empfangenen XMAC' vergleichen, um den Vertrag zu verifizieren. Vorzugsweise enthält der Service-Provider Verifizierungsinformation wie beispielsweise MAC, RAND_CONT/CONT und ANWENDER_ID, zurück. Wenn er durch den Dienstvereinbarungsmanager aufgefordert wird, oder eine Online-Prozedur mit dem Dienstvereinbarungsmanager erwünscht ist, kann der Service-Provider diese Verifizierungsinformation zum Dienstvereinbarungsmanager weiterleiten.
  • Der Dienstvereinbarungsmanager verifiziert dann, das s. MAC gleich XMAC ist, was bedeutet, dass die Dienstvereinbarung basierend auf dem Vertrag schließlich verifiziert ist und dass der Anwender wenigstens implizit authentifiziert ist.
  • Eine Neuheit der allgemeinen Vertragssignierungsprozedur besteht darin, dass sie eine Offline-Verifizierung durch den Service-Provider mittels einer Einführung von maskierten Verifizierungsdaten zulässt. Anders ausgedrückt kann die zwischen dem Service-Provider (SP) und dem Betreiber durchgeführte Vertragsvorbereitung bezüglich der Zeit von der zwischen dem Anwender und dem Service-Provider (SP) durchgeführten Vertragssignierung/verifizierung getrennt werden. Natürliche Anwendungen dieses Schemas enthalten Fälle, bei welchen eine Anzahl von Verträgen in einer SP/Betreiber-Session entweder für denselben Anwender mit unterschiedlichen Bedingungen (z.B. zu unterschiedlichen Zeiten oder auf unterschiedlichen Dienstebenen) vorbereitet werden, oder für mehrere Anwender mit gleichen Bedingungen (z.B, wenn ein Teilnahmeangebot geliefert wird).
  • Isolation von Schlüsselgebungsmaterial
  • Kehrt man wieder zu einer AKA-integrierten Nichtablehnung von Dienstvereinbarungen zurück, können bei einem weiteren Ansatz AKA-Daten als geheime Eingaben zu einer Pseudozufallsfunktion (PRF) zum Ableiten einer neuen Gruppe von AKA-Daten und/oder eines Nichtablehnungsschlüssels verwendet werden.
  • Anhand eines Beispiels können anstelle eines Durchführens einer direkten Erweiterung der AKA-Prozedur zum Erzeugen des zusätzlichen Schlüssels Rk die Schlüssel Ck und Ik als geheime Eingaben zu einer Pseudozufallsfunktion verwendet werden, die zum Ableiten neuer Vertrauens-(C'k)- und Integritäts-(I'k)-Schlüssel, eines Nichtablehnungsschlüssels (Rk) und einer neuen Antwort (RES') verwendet wird. C'k und I'k werden anstelle von Ck und Ik verwendet und verteilt. Auf diese Weise muss das ursprüngliche AKA-Schema, das normalerweise in einer Smart-Karte implementiert ist, nicht geändert werden.
  • Ein größerer Vorteil besteht darin, dass es möglich ist, Schlüsselgebungsmaterial für eine GSM/UMTS-Anwendung und Schlüsselgebungsmaterial, das für eine Anwenderauthentifizierung und eine Nichtablehnung verwendet wird, wenn auf Dienste zugegriffen wird, zu isolieren. Somit kann selbst dann, wenn Schlüsselgebungsmaterial für Dienste verloren oder gestohlen wird, es nicht zum Zugreifen auf die grundsätzlichen Kommunikationsdienste verwendet werden.
  • Eine Variante beim Verwenden des Isolationsschritts wäre ein Verwenden von ihm zum Erzeugen eines in einem vollständigen AKA-Schema verwendeten gemeinsam genutzten Geheimnisses.
  • Wenn wir ein Schlüsselgebungsmaterial im Allgemeinen durch K(i) bezeichnen, dann wird der Ableitungsschritt durch K(i+1) = PRF(K(i), SALT) bezeichnet, wobei PRF eine Pseudozufallsfunktion ist. SALT sollte Zufallsinformation enthalten und kann z.B. Information enthalten, die für einen Dienst und/oder einen Service-Provider eindeutig ist. Beispielsweise kann die PRF wie in dem sicheren Echtzeit-Transportprotokoll (SRTP) implementiert sein.
  • Obwohl K(i) typischerweise in Ausgangsdaten von einem Basis-AKA besteht, sollte es verstanden werden, dass andere Daten als Argument zur PRF-Funktion verwendet werden können. Zusätzlich kann die Anzahl von Eingabeargumenten und Ergebnisvariablen gemäß der bevorstehenden Anwendung variieren.
  • 12A ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine AKA-integrierte Nichtablehnung von Dienstvereinbarungen basierend auf unterschiedlichen isolierten Schlüsselgebungsgruppen mit möglicher Offline-Verifizierung.
  • Der Authentifizierungs/Bezahlungs-Manager erzeugt die gewöhnlichen AKA-Daten basierend auf dem geheimen Schlüssel Ki und einer Zufallsaufforderung RAND. Man lässt K(0) = [Ck, Ik, XRES)] sein. Der Authentifizierungs/Bezahlungs-Manager berechnet K(1) = [C'k, I'k, Rk, XRES'] = PRF(K(0), RAND/SALT). SALT kann gleich RAND kombiniert mit einer Service-Provider-ID, SP ID, sein.
  • 1. RAND, AUTN I'k, C'k, XRES', [SALT]
  • 2. RAND, AUTN, COST_UNIT [SALT]
  • Der Anwender prüft AUTN wie gewöhnlich. Er lässt dann AKA laufen, um K(0) = Ik, Ck, RES abzuleiten, und er wendet die PRF auf K(0) an, um K(1) = C'k, I'k, Rk und RES' abzuleiten. Der Anwender erzeugt auch den COST_MAC über RAND und COST_UNIT unter Verwendung von Rk.
  • 3. RES', COST_MAC
  • Der Service-Provider prüft, dass RES' mit XRES' übereinstimmt, die von der Betreiberseite empfangen wird, und speichert Verifizierungsinformation für eine spätere Wiedergewinnung, wenn es nötig ist. Wenn er aufgefordert wird oder auf seine eigene Initiative hin, kann der Service-Provider die Verifizierungsinformation zur Betreiberseite zur Verifizierung der Dienstvereinbarung weiterleiten.
  • 12B ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine AKA-integrierte Nichtablehnung von Dienstvereinbarungen basierend auf unterschiedlichen isolierten Schlüsselgebungsgruppen mit Online-Verifizierung.
  • 1. RAND, AUTN, XRES', [SALT]
  • 2. RAND, AUTN, COST_UNIT, [SALT]
  • Der Anwender prüft AUTN wie gewöhnlich und lässt dann AKA laufen, um K(0) = Ik, Ck, RES abzuleiten, und er wendet die PRF auf K(0) an, um K(1) = C'k, I'k, Rk und RES' abzuleiten. Der Anwender erzeugt auch den COST_MAC über RAND und COST_UNIT unter Verwendung von Rk.
  • 3. RES', COST_MAC
  • Der Service-Provider prüft, dass RES' mit der XRES' übereinstimmt, die von der Betreiberseite empfangen wird, und leitet die Verifizierungsinformation zur Betreiberseite zur Verifizierung der Dienstvereinbarung weiter.
  • 4. COST_UNIT, COST_MAC
  • Wenn COST_MAC mit XMAC übereinstimmt, werden die Sessionsschlüssel C'k, I'k zum Service-Provider zur Verwendung bei der Kommunikation zwischen dem Service-Provider und dem Anwender transferiert.
  • 5. C'k, I'k
  • Natürlich kann die oben beschriebene auf einem Ticket basierende Lösung auch auf einem von dem anfänglichen AKA-Parametern abgeleiteten Schlüsselgebungsmaterial basieren.
  • Es sollte verstanden werden, dass die Isolation des Schlüsselgebungsmaterials für einen normalen Netzwerkzugriff von einem Authentifizierungs- und Schlüsselgebungsmaterial für einen Zugriff auf Dienste, die durch den Service-Provider zur Verfügung gestellt werden, ein allgemeines allein stehendes Merkmal der Erfindung ist, welches nicht auf irgendeine Kombination mit einer Nichtablehnung von Dienstvereinbarungen beschränkt ist.
  • Bei der oben beschriebenen Prozedur ist für SALT angenommen, dass es auf der Betreiberseite sowie beim Anwender verfügbar ist. Wenn SALT gleich RAND ist, ist dies trivial richtig, aber dann, wenn andere Informationen, wie Zeitstempel oder SALT, welches unabhängig vom RAND-Wert ist, verwendet werden sollten, müssen diese Werte abgestimmt werden mit/gesendet werden zu dem Anwender. Ein besonders wichtiger Fall ist dann, wenn der Anwender die wahre SP_ID (Service-Provider-Identität) aus dem Zusammenhang nicht bestimmen kann, sondern sich auf empfangene Information verlassen muss und diese SP_ID dazu verwendet wird, Parameter für unterschiedliche Service-Provider zu isolieren. In diesem Fall könnte die Information in dem AUTN-Parameter in der standardmäßigen AKA-Prozedur transferiert werden, oder sie könnte in einer MAC-codierten Nachricht gesendet werden, wie es zum Signieren von Verträgen oben beschrieben ist, d.h. ein verschlüsselter MAC schützt die empfindlichen Parameter. Der für den verschlüsselten MAC verwendete Schlüssel sollte ein Schlüssel sein, der nur durch den Betreiber und den Anwender gemeinsam genutzt wird, z.B. Ik oder Rk.
  • Dies entspricht allgemein einem Erzeugen von dienstabhängigen AKA-Parametern aus der grundsätzlichen AKA-Prozedur.
  • Beispielhafte Anwendungen, die einen Bezahlungsvermittler enthalten
  • 13 ist ein schematisches beispielhaftes Blockdiagramm in einer verteilten Implementierung, die einen Identitätsvermittler sowie einen Bezahlungsvermittler enthält, unter Verwendung einer eingerichteten Vertrauenskette zwischen dem Identitätsvermittler, dem Bezahlungsvermittler und dem Service-Provider.
  • In dem zu beschreibenden Szenario führen wir einen zusätzlichen Teilnehmer ein, nämlich einen Bezahlungsvermittler 40. Der Aufbau der 13 enthält somit einen Anwender 10, einen Service-Provider 20, einen Authentifizierungsmanager 30, der ein Geheimnis mit dem Anwender gemeinsam nutzt, und einem Bezahlungsvermittler 40. Der Bezahlungsvermittler kann Beziehungen mit mehreren Betreibern/Authentifizierungsmanagern haben und vermittelt Anwenderauthentifizierungsinformation zwischen Betreibern und Service-Providern, hilft beim Verifizieren von Bezahlungen/bei einer Anwenderfähigkeit zum Bezahlen und handhabt Bezahlungs/Belastungs-Daten bzw. Bezahlungs/Rechnungserstellungs-Daten bzw. Bezahlungs/(Ab-)Buchungs-Daten. Der Bezahlungsvermittler kann die Rolle einer vertrauenswürdigen dritten Partei annehmen, die Anwenderdienstvereinbarungen verifizieren kann.
  • Bezahlungen können mit dem Betreiber verbunden sein, mit welchem der Anwender bereits eine Bezahlungsbeziehung haben kann, oder sie können mit einer unabhängigen Partei verbunden und über diese durchgeführt werden, oder durch den Bezahlungsvermittler selbst.
  • Wir führen auch das Konzept eines Anwenderidentitätsvermittlers ein, der normalerweise auf der Betreiberseite in Zusammenhang mit dem Authentifizierungsmanager angeordnet ist. Anwender können wünschen, unterschiedliche Identitäten für unterschiedliche Dienste zu verwenden. Der Identitätsvermittler bildet normalerweise Anwenderidentitäten für einen Dienstzugriff auf Anwenderidentitäten für Betreiber (d.h. IMSI) ab. Eine Identitätsvermittlung kann in mehreren Schritten stattfinden.
  • Die Beziehung zwischen der Anwenderdienst-ID und der Anwender-Id bei dem Betreiber muss zum Identitätsvermittler gegeben werden. Normalerweise wird der Betreiber, der den Identitätsvermittler betreibt, diese Paarung erzeugen. Aus Sicherheitsgründen ist es natürlich, dass die letzte Identitätsvermittlungsfunktion durch den Betreiber durchgeführt wird.
  • Die Dienst-ID kann mehrere Teile haben. Einzelne Teile können den Bezahlungsvermittler und den Identitätsvermittler anzeigen, die zu verwenden sind. Ein Anwender kann natürlich mehrere Bezahlungsvermittler für eine gegebene Betreiberidentität verwenden. Der Bezahlungsvermittler kann eine Aufzeichnung halten, die zeigt, welcher Betreiber einer gegebenen Anwenderdienst-Id zugeordnet ist, wenn diese Information nicht von der Anwenderdienst-Id abgeleitet werden kann.
  • Nachfolgend werden zwei Signalgabeschemen unter Bezugnahme auf das in 13 gezeigte Szenario beschrieben werden. Das erste Schema ist für einen Anwender mit einer Teilnahme mit einer Bezahlung im Nachhinein und das zweite Schema ist für im Voraus bezahlte Dienste.
  • Szenario für eine Bezahlung im Nachhinein
  • 14 ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine Nichtablehnung von Dienstvereinbarungen in einem Szenario für eine Bezahlung im Nachhinein in dem in 13 gezeigten Aufbau.
  • 1. Anwenderdienst-ID, einschließlich einer ID eines Bezahlungsvermittlers, einer ANWENDER_DIENST_ID, PB_ID
  • 2. ANWENDER_DIENST_ID, SP_ID.
  • Der Bezahlungsvermittler weiß, zu welchem Betreiber/Identitätsvermittler die Anwenderdienst-Id zugeordnet bzw. zugehörig ist.
  • 3. ANWENDER_DIENST_ID, SP_ID, PB_ID
  • Der Betreiber, der die Rolle eines Identitätsvermittlers annimmt, bildet die ANWENDER_DIENST_ID auf die betreiberinterne ID (IMSI) ab und gewinnt entsprechende AKA-Parameter RAND, AUTN und K(0)=[Ck, Ik, XRES] wieder. Der Betreiber leitet K(1) = [C'k, I'k, XRES'] = PRF(K(0), [RAND, PB_ID]) ab, wobei PB_ID die Bezahlungsvermittler-ID ist, RAND optional ist. Durch explizites Abhängigseinlassen von K(1) von PB_ID wird das Schlüsselgebungsmaterial an einen spezifischen Bezahlungsvermittler gebunden.
  • 4. RAND, AUTN, C'k, I'k, (SP_ID||PB_ID, verschlüsselter MAC (Ik, SP_ID||PB_ID)
  • Die Schlüssel C'k, I'k werden für eine sichere Kommunikation zwischen dem Bezahlungsvermittler und dem Anwender verwendet. Somit kann I'k als ein Nichtablehnungsschlüssel verwendet werden, z.B. dann, wenn COST_MAC berechnet wird, und C'k kann zum Ableiten von z.B. eines ENC_TICKET verwendet werden.
  • Der Bezahlungsvermittler leitet dann K(2) =[C''k, I''k, XRES''] = PRF[K(1), [RAND, SP_Id]) ab.
  • 5. RAND, AUTN, C''k, I''k, XRES'', (SP_ID||PB_ID, verschlüsselter MAC (Ik, SP_ID||PB_ID)
  • 6. RAND, AUTN, COST_UNIT, (SP_ID||PB_ID, verschlüsselter MAC (Ik, SP_ID||PB_ID)
  • Der Anwender prüft AUTN und berechnet K(0), K(1) und K(2) unter Verwendung des gemeinsam genutzten geheimen Schlüssels Ki, der empfangenen RAND und der Pseudozufallsfunktion(en).
  • 7. RES''
  • Der Service-Provider prüft RES'' und bestimmt die Anwender-Autorisierungsebene. Der Service-Provider initiiert nun die Verwendung einer sicheren Verbindung zum Anwender unter Verwendung von C''k und I''k.
  • Wenn ein Dienst, für welchen der Anwender zahlen muss, aufgerufen wird, sollte der Anwender einen COST_MAC senden.
  • 8. COST_MAC
  • 9. COST_UNIT, COST_MAC
  • Der Bezahlungsvermittler verifiziert den COST_MAC und initiiert eine Bezahlungsprozedur.
  • 10. OK
  • Szenario für ein Bezahlen im Voraus
  • 15 ist ein schematisches beispielhaftes Signalaustauschdiagramm für eine Nichtablehnung von Dienstvereinbarungen in einem Szenario für ein Bezahlen im Voraus in dem in 13 gezeigten Aufbau.
  • In diesem Fall stellen wir einen Fall dar, bei welchem der Anwender ein vorbezahltes Konto verwendet und durch den Bezahlungsvermittler erzeugte Tickets bekommt. Hier ist der erforderliche Transfer von Zusammenhangsinformation für die Ableitung von isolierten AKA-Parametern weggelassen.
  • 1. ANWENDER_DIENST_ID, PB_ID
  • 2. ANWENDER_DIENST_ID, COST_UNIT, SP_ID
  • Der Bezahlungsvermittler weiß, zu welchem Betreiber/Identitätsvermittler die ANWENDER_DIENST_ID gehört.
  • 3. ANWENDER_DIENST_ID, COST_UNIT, SP_ID, PB_ID
  • Der Betreiber bildet die ANWENDER_DIENST_ID auf die betreiberinterne ID (IMSI) ab und gewinnt entsprechende AKA-Parameter RAND, AUTN wieder und erzeugt K(0) = [Ck, Ik, XRES]. Der Betreiber leitet K(1) = [C'k, I'k, XRES'] _ PRF(K(0), [RAND, PB_ID]) ab, wobei PB_Id die Bezahlungsvermittler-Id ist, und RAND optional ist. Durch explizites Abhängigseinlassen von K(1) von PB_Id wird die XRES' und das Schlüsselgebungsmaterial an einen spezifischen Bezahlungsvermittler gebunden.
  • Der Betreiber prüft auch das vorbezahlte Konto des Anwenders. In Abhängigkeit von der verwendeten Politik reserviert der Betreiber eine Nummer, N#, von COST_UNITS auf dem Anwenderkonto und sendet N# zum Bezahlungsvermittler.
  • 4. RAND, AUTN, C'k, I'k, N#
  • Der Bezahlungsvermittler erzeugt ein BASE_TICKET und berechnet das START_TICKET und das ENC_TICKET unter Verwendung von C'k als Verschlüsselungsschlüssel. Das START_TICKET wird so erzeugt, dass es für irgendeine Zahl N'# ≤ N# von COST_UNITS gültig ist.
  • Der Bezahlungsvermittler leitet dann K(2) = [C''k, I''k, RES''] = PRF[K(1), [RAND, SP_Id]) ab.
  • 5. RAND, AUTN, C''k, I''k, XRES'', ENC_TICKET, START_TICKET
  • 6. RAND, AUTN, COST_UNIT, START_TICKET, ENC_TICKET
  • Der Anwender prüft AUTN und berechnet K(0), K(1) und K(2) unter Verwendung des gemeinsam genutzten geheimen Schlüssels Ki des empfangenen RAND und der Pseudozufallsfunktion(en).
  • 7. RES''
  • Der Service-Provider prüft RES" und initiiert die Verwendung einer sicheren Verbindung zum Anwender unter Verwendung von C''k und I''k.
  • Wenn ein Dienst, für welchen der Anwender zahlen muss, aufgerufen wird, sollte der Anwender ein TICKET zum Service-Provider senden. Um dazu fähig zu sein, dies durchzuführen, entschlüsselt der Anwender das ENC_TICKET und iteriert die HASH-Funktion, um die Anzahl von Tickets zu prüfen, die er hat, und um zu prüfen, dass das START_TICKET gültig ist.
  • Dann sendet er ein TICKET, sagen wir das TICKET_i.
  • 8. TICKET_i
  • Der Service-Provider prüft die empfangenen Tickets. Wenn die Session geschlossen wird, sendet der Service-Provider das empfangene letzte Ticket zum Bezahlungsvermittler.
  • 9. LAST_TICKET
  • Der Bezahlungsvermittler überprüft das empfangene Ticket und erzeugt eine Belastungsaufzeichnung, die zum Betreiber gesendet wird.
  • 10. BELASTUNGSAUFZEICHNUNG
  • Schließlich wird das Anwenderkonto entsprechend eingestellt.
  • Erneute Authentifizierung
  • Der Service-Provider kann aus unterschiedlichen Gründen wünschen, eine Möglichkeit zum erneuten Authentifizieren eines Anwenders zu haben. Eine Art zum Erreichen von diesem besteht im Iterieren der Erzeugung von K(n), d.h. dann, wenn die n-te Authentifizierung stattfindet, wird ein Schlüsselgebungsmaterial K(n+1) = PRF[K(n), [RAND, SP_ID]) verwendet. Dies bedeutet, dass der Service-Provider einen Zugriff auf einen Fall der Pseudozufallsfunktion PRF hat, um dazu fähig zu sein, die erforderlichen Authentifizierungsparameter und Sessionschlüssel zu erzeugen. Kurz gesagt erzeugt der Service-Provider neue Sessionschlüssel und eine erwartete Antwort der Größenordnung n+1 unter Verwendung der Pseudozufallsfunktion und wendet RAND zu dem Anwender bei einer Anfrage für eine erneute Authentifizierung. Der Anwender erzeugt dann die neuen Sessionschlüssel und eine Anwenderantwort in der Größenordnung n+1 unter Verwendung der Pseudozufallsfunktion und bringt die erzeugte Anwenderantwort der Größenordnung N+1 zum Service-Provider zurück. Der Service-Provider kann dann die empfangene Antwort verifizieren und ein Kommunizieren mit dem Anwender basierend auf den neuen Sessionschlüsseln beginnen.
  • Vorzugsweise wird n zu dem Anwender gesendet, was eine einfache Wiedergabeliste halten kann, um gegenüber Wiedergabeangriffen zu schützen.
  • Weiteres über Implementierungsaspekte
  • Die oben beschriebenen Schritte, Aktionen und Algorithmen können in Software/Hardware oder irgendeiner Kombination davon implementiert werden. Für Hardware-Implementierungen kann eine ASIC-(anwendungsspezifische integrierte Schaltung)-Technologie oder irgendeine andere herkömmliche Schaltungstechnologie verwendet werden. Obwohl aus Sicherheitsgründen eine spezielle fälschungsresistente Hardware bevorzugt sein kann, sind richtig geschützte Softwareimplementierungen oft angenehmer.
  • 16 ist ein schematisches Blockdiagramm, das ein Beispiel eines Dienstvereinbarungsmanagers gemäß einem bevorzugten Ausführungsbeispiel der Erfindung darstellt. Der Dienstvereinbarungsmanager 30 der 16 enthält grundsätzlich eine Kommunikationsschnittstelle 31 zu einer Verbindung für eine externe Kommunikation, eine Datenbank 32, eine Authentifizierungs- und Verschlüsselungseinheit 33, eine Verifizierungseinheit 36, eine optionale Ticketgebungsgeinheit 37 und eine Bezahlungs/Belastungseinheit 38. die Datenbank 32 enthält Informationen, wie beispielsweise Anwender-ID und zugehörige geheime Schlüssel-Ki-Information. Die Authentifizierungs- und Schlüsselgebungseinheit 33 ist zum Erzeugen der relevanten Authentifizierungs- und Schlüsselparameter betreibbar und kann auch die optionalen Maskierungs- und Pseudozufallsfunktionen halten, die bei verschiedenen Ausführungsbeispielen verwendet werden. Die Verifizierungseinheit 36 führt eine relevante Berechnung (relevante Berechnungen) und/oder einen Vergleich (Vergleiche) durch, um zu verifizieren, dass der Anwender eine gegebene Dienstvereinbarung akzeptiert hat. Die optionale Ticketgebungseinheit 37 kann relevante Tickets im Auftrag des Anwenders erzeugen und/oder eine Ticketverifizierung durchführen. Wie es der Name anzeigt, handhabt die Bezahlungseinheit 38 einen Transfer von Bezahlungen und stellt sicher, dass z.B. eine Belastung richtig durchgeführt wird, wie z.B. zum richtigen Konto.
  • 17 ist ein schematisches Blockdiagramm, das ein Beispiel eines Service-Providers gemäß einem bevorzugten Ausführungsbeispiel der Erfindung darstellt. Der Service-Provider 20 der 17 enthält grundsätzlich eine Kommunikationsschnittstelle 21 zu einer Verbindung für eine externe Kommunikation, eine Vertragsvorbereitungseinheit 22, eine optionale Authentifizierungseinheit 23, eine Einheit 25 für eine Informationsweiterleitung und/oder -speicherung und eine optionale Verifizierungseinheit 26. In der Vertragsvorbereitungseinheit 22 bereitet der Service-Provider typischerweise die relevante Dienstvereinbarungsinformation gemäß dem angeforderten Dienst und den aktuellen Bedingungen zur Verwendung des Dienstes vor. Alternativ dazu wird die Vertragsvorbereitung durch irgendeine andere Partei im Auftrag des Service-Providers durchgeführt, aber für gewöhnlich wird eine solche externe Vertragsvorbereitung auf irgendeine Weise vom Service-Provider initialisiert. Für eine maskierte Vertragssignierung und/oder eine Anwenderauthentifizierung kann der Service-Provider eine Verifizierung einer akzeptierten Dienstvereinbarung und/oder eine Anwenderauthentifizierung in der Verifizierungseinheit 26 und/oder der Authentifizierungseinheit 23 durchführen. Bei Offline-Prozeduren kann der Service-Provider wünschen, Verifizierungsinformation in der Einheit 25 für ein späteres Weiterleiten zu dem Dienstvereinbarungsmanager 30 oder einer anderen Partei, die durch den Dienstvereinbarungsmanager zugeordnet ist, zu speichern.
  • 18 ist ein schematisches Blockdiagramm, das ein Beispiel eines Anwender-Endgeräts eines bevorzugten Ausführungsbeispiels der Erfindung darstellt. Das Anwender-Endgerät 10 der 18 enthält grundsätzlich eine Kommunikationsschnittstelle 11 zu einer Verbindung für eine externe Kommunikation und ein fälschungsresistentes Modul 12. Das fälschungsresistente Modul 12, das einer entfernbar angeordneten SIM- oder USIM-Karte ähneln kann, enthält eine I/O-Einheit 101, eine AKA-Algorithmuseinheit 102, einen sicher implementierten (eingekapselten) gemeinsam genutzten geheimen Schlüssel Ki 103, eine kryptographische Verarbeitungseinheit 104 für solche Zwecke, wie beispielsweise eine MAC/Entschlüsselung, und eine optionale Ticketgebungseinheit 105 für eine auf Tickets basierende Nichtablehnung. Es kann sogar möglich sein, existierende (U)SIM-Karten durch Implementieren einer Funktionalität zu modifizieren, wie beispielsweise die kryptographische Verarbeitung und die Ticketgebung als Software in der (U)SIM-Anwendungs-Geräteumgebung der (U)SIM-Karten, und zwar mit einer geeigneten Schnittstelle zwischen der AKA-Einheit und der Anwendungsgeräteumgebung.
  • Die oben beschriebenen Ausführungsbeispiele sind lediglich als Beispiele angegeben, und es sollte verstanden werden, dass die vorliegende Erfindung nicht darauf beschränkt ist. Weitere Modifikationen, Änderungen und Verbesserungen, die die grundsätzlichen zugrunde liegenden Prinzipien behalten, die offenbart und hierin beansprucht sind, sind innerhalb des Schutzumfangs und Sinngehalts der Erfindung.
  • Zusammenfassung
  • Die Erfindung betrifft allgemein eine effiziente Nichtablehnung von Dienstvereinbarungen zwischen einem Anwender (10) und einem Service-Provider (20) in einem Kommunikationssystem. Eine zusätzliche vertrauenswürdige Partei (30), ein so genannter Dienstvereinbarungsmanager, wird eingeführt, und die Erfindung basiert auf der Idee, dass der Dienstvereinbarungsmanager (30) einen geheimen Schlüssel (Ki) mit einem Anwender-Endgerät (10) gemeinsam nutzt und dass der Service-Provider (20) eine Vertrauensbeziehung mit dem Dienstvereinbarungsmanager (30) hat. Das durch die Erfindung vorgeschlagene Nichtablehnungsschema basiert weiterhin auf einer Vorbereitung relevanter Dienstvereinbarungsinformation und einer kryptographischen Verarbeitung (14/34) dieser Information basierend auf dem gemeinsam genutzten geheimen Schlüssel (Ki), um anwendersignierte Dienstvereinbarungs-Verifizierungsinformation zu erzeugen. Die anwendersignierte Verifizierungsinformation wird darauf folgend zum Service-Provider (20) weitergeleitet, um eine Verifizierung (26/36) der Dienstvereinbarung basierend auf der Vertrauensbeziehung zwischen dem Service-Provider (20) und dem Dienstvereinbarungsmanager (30) zu ermöglichen.
    (4)

Claims (47)

  1. Verfahren für eine Nichtablehnung einer Dienstvereinbarung zwischen einem Anwender und einem Service-Provider in einem Kommunikationssystem, wobei das Verfahren die folgenden Schritte aufweist: – sicheres gemeinsames Nutzen eines geheimen Schlüssels zwischen einem Anwender-Endgerät und einem Dienstvereinbarungsmanager, wobei der Service-Provider eine Vertrauensbeziehung mit dem Dienstvereinbarungsmanager hat; – Vorbereiten von Dienstvereinbarungsinformation; – kryptographisches Verarbeiten basierend auf dem gemeinsam genutzten geheimen Schlüssel der Dienstvereinbarungsinformation, um anwendersignierte Dienstvereinbarungs-Verifizierungsinformation zu erzeugen; und – Weiterleiten der anwendersignierten Verifizierungsinformation zum Service-Provider, um eine Verifizierung der Dienstvereinbarung basierend auf der Vertrauensbeziehung zwischen dem Service-Provider und dem Dienstvereinbarungsmanager zu ermöglichen.
  2. Verfahren nach Anspruch 1, wobei der Schritt zum kryptographischen Verarbeiten der Dienstvereinbarungsinformation in dem Anwender-Endgerät sicher durchgeführt wird, um die anwendersignierte Verifizierungsinformation zu erzeugen.
  3. Verfahren nach Anspruch 1 oder 2, wobei der Schritt zum kryptographischen Verarbeiten der Dienstvereinbarungsinformation basierend auf einem Nichtablehnungsschlüssel durchgeführt wird, der lokal von dem gemeinsam genutzten geheimen Schlüssel abgeleitet wird.
  4. Verfahren nach Anspruch 2, das weiterhin die folgenden Schritte aufweist: – Erzeugen bei dem Dienstvereinbarungsmanager von erwarteter Verifizierungsinformation wenigstens teilweise basierend auf der Dienstvereinbarungsinformation und dem gemeinsam genutzten geheimen Schlüssel; und – bei dem Dienstvereinbarungsmanager Verifizieren, dass die anwendersignierte Verifizierungsinformation der erwarteten Verifizierungsinformation entspricht.
  5. Verfahren nach Anspruch 2, wobei die anwendersignierte Verifizierungsinformation in dem Anwender-Endgerät in Antwort auf eine von dem Dienstvereinbarungsmanager initiierte Zufallsaufforderung und die Dienstvereinbarungsinformation erzeugt wird.
  6. Verfahren nach Anspruch 2, wobei die anwendersignierte Verifizierungsinformation im Anwender-Endgerät basierend auf einem auf der Anwenderseite initialisierten Ticket und der Dienstvereinbarungsinformation erzeugt wird.
  7. Verfahren nach Anspruch 1, wobei der Schritt zum Vorbereiten von Dienstvereinbarungsinformation durch den Service-Provider initialisiert wird.
  8. Verfahren nach Anspruch 1, wobei der Schritt zum kryptographischen Verarbeiten der Dienstvereinbarungsinformation die folgenden Schritte aufweist: – der Dienstvereinbarungsmanager führt eine kryptographische Verarbeitung der Dienstvereinbarungsinformation basierend auf dem gemeinsam genutzten geheimen Schlüssel durch, um eine kryptographische Darstellung der Dienstvereinbarungsinformation zu erzeugen, wobei die kryptographische Darstellung zum Anwender weitergeleitet wird; und – das Anwender-Endgerät führt eine kryptographische Verarbeitung der kryptographischen Darstellung basierend auf dem gemeinsam genutzten geheimen Schlüssel durch, um die anwendersignierte Verifizierungsinformation zu erzeugen.
  9. Verfahren nach Anspruch 8, wobei der Schritt, dass der Dienstvereinbarungsmanager eine kryptographische Verarbeitung durchführt, die folgenden Schritte aufweist: – Erzeugen eines Tickets basierend auf der Dienstvereinbarungsinformation; und – Verschlüsseln des Tickets basierend auf einem Nichtablehnungsschlüssel, der lokal aus dem gemeinsam genutzten geheimen Schlüssel abgeleitet ist; und wobei der Schritt, dass das Anwender-Endgerät eine kryptographische Verarbeitung durchführt, den Schritt zum Entschlüsseln des verschlüsselten Tickets basierend auf dem Nichtablehnungsschlüssel aufweist, der lokal aus dem gemeinsam genutzten geheimen Schlüssel abgeleitet ist.
  10. Verfahren nach Anspruch 1, wobei die Dienstvereinbarungsinformation ein allgemeiner elektronischer Vertrag ist und wobei das Verfahren weiterhin die folgenden Schritte aufweist: – der Dienstvereinbarungsmanager erzeugt erwartete Dienstvereinbarungs-Verifizierungsinformation basierend auf dem gemeinsam genutzten geheimen Schlüssel und dem elektronischen Vertrag; – der Dienstvereinbarungsmanager maskiert die erwartete Verifizierungsinformation durch eine Maskierungsfunktion; – der Dienstvereinbarungsmanager leitet die maskierte erwartete Verifizierungsinformation zum Service-Provider weiter; – der Service-Provider maskiert die anwendersignierte Verifizierungsinformation durch einen Fall derselben Maskierungsfunktion, um maskierte anwendersignierte Verifizierungsinformation zu erzeugen; – der Service-Provider verifiziert, dass die maskierte anwendersignierte Verifizierungsinformation der von dem Dienstvereinbarungsmanager enthaltenen maskierten erwarteten Verifizierungsinformation entspricht.
  11. Verfahren nach Anspruch 10, wobei der Schritt, dass der Dienstvereinbarungsmanager erwartete Dienstvereinbarungs-Verifizierungsinformation erzeugt, den Schritt zum Anwenden einer Hash-Codierung des Vertrags als Zufallsaufforderung in einer normalen auf einer Aufforderung/Antwort basierenden Authentifizierungs- und Schlüsselvereinbarungsprozedur aufweist.
  12. Verfahren nach Anspruch 10, wobei die Maskierungsfunktion eine kryptographische Hash-Funktion ist.
  13. Verfahren nach Anspruch 1, wobei das Nichtablehnungsverfahren mit einer auf einer Aufforderung/Antwort basierenden Authentifizierungs- und Schlüsselvereinbarungs-(AKA-)Prozedur für einen Netzwerkzugriff integriert ist, wobei der gemeinsam genutzte geheime Schlüssel derselbe wie ein für AKA verwendeter geheimer Schlüssel ist.
  14. Verfahren nach Anspruch 13, wobei ein Schlüsselgebungsmaterial für eine Nichtablehnung der Dienstvereinbarung vom Schlüsselgebungsmaterial für die auf eine Aufforderung/Antwort basierende AKA-Prozedur isoliert ist.
  15. Verfahren nach Anspruch 14, wobei das Schlüsselgebungsmaterial für eine Nichtablehnung mittels einer Pseudozufallsfunktion basierend auf einem Schlüsselgebungsmaterial für AKA als Eingabe zu der Pseudozufallsfunktion erzeugt wird.
  16. Verfahren nach Anspruch 14, wobei das Schlüsselgebungsmaterial für eine Nichtablehnung an einen spezifischen Bezahlungsvermittler gebunden ist, der mit einem Authentifizierungsmanager zusammenarbeitet, wobei der Authentifizierungsmanager und das Anwender-Endgerät den geheimen Schlüssel gemeinsam nutzen.
  17. Verfahren nach Anspruch 14, wobei das Schlüsselgebungsmaterial für eine Nichtablehnung an den Service-Provider gebunden ist, um das Schlüsselgebungsmaterial von entsprechendem Schlüsselgebungsmaterial für einen anderen Service-Provider zu isolieren.
  18. Verfahren nach Anspruch 1, wobei die Dienstvereinbarungsinformation Dienstgebühreninformation enthält und der Dienstvereinbarungsmanager ein Bezahlungsprovider ist, der eine Bezahlung des Dienstes im Auftrag des Anwenders handhabt.
  19. Verfahren nach Anspruch 1, wobei der Dienstvereinbarungsmanager einen Anwenderidentitätsvermittler und einen Bezahlungsvermittler, der zwischen dem Service-Provider und dem Identitätsvermittler angeordnet ist, enthält und eine Vertrauenskette zwischen dem Service-Provider, dem Bezahlungsvermittler und dem Identitätsvermittler gebildet ist, wobei der Identitätsvermittler den geheimen Schlüssel mit dem Anwender-Endgerät gemeinsam nutzt.
  20. Verfahren nach Anspruch 19, das weiterhin den Schritt aufweist, dass der Bezahlungsvermittler die anwendersignierte Verifizierungsinformation basierend auf einem Nichtablehnungsschlüssel verifiziert, der vom Identitätsvermittler erhalten ist, abgeleitet basierend auf dem gemeinsam genutzten geheimen Schlüssel.
  21. System für eine Nichtablehnung einer Dienstvereinbarung zwischen einem Anwender und einem Service-Provider in einem Kommunikationssystem, wobei das System folgendes aufweist: – eine Einrichtung zum sicheren gemeinsamen Nutzen eines geheimen Schlüssels zwischen einem Anwender-Endgerät und einem Dienstvereinbarungsmanager, wobei der Service-Provider eine Vertrauensbeziehung mit dem Dienstvereinbarungsmanager hat; – eine Einrichtung zum Vorbereiten von Dienstvereinbarungsinformation; – eine Einrichtung zum kryptographischen Verarbeiten basierend auf dem gemeinsam genutzten geheimen Schlüssel der Dienstvereinbarungsinformation, um anwendersignierte Dienstvereinbarungs-Verifizierungsinformation zu erzeugen; und – eine Einrichtung zum Weiterleiten der anwendersignierten Verifizierungsinformation zum Service-Provider, um eine Verifizierung der Dienstvereinbarung basierend auf der Vertrauensbeziehung zwischen dem Service-Provider und dem Dienstvereinbarungsmanager zu ermöglichen.
  22. System nach Anspruch 21, wobei die Einrichtung zum kryptographischen Verarbeiten der Dienstvereinbarungsinformation sicher im Anwender-Endgerät implementiert ist.
  23. System nach Anspruch 21 oder 22, wobei die Einrichtung zum kryptographischen Verarbeiten der Dienstvereinbarungsinformation basierend auf einem Nichtablehnungsschlüssel arbeitet, der lokal von dem gemeinsam genutzten geheimen Schlüssel abgeleitet ist.
  24. System nach Anspruch 22, das weiterhin folgendes aufweist: – eine Einrichtung zum Erzeugen bei dem Dienstvereinbarungsmanager von erwartete Verifizierungsinformation wenigstens teilweise basierend auf der Dienstvereinbarungsinformation und dem gemeinsam genutzten geheimen Schlüssel; und – eine Einrichtung zum Verifizieren, dass die anwendersignierte Verifizierungsinformation der erwarteten Verifizierungsinformation entspricht, bei dem Dienstvereinbarungsmanager.
  25. System nach Anspruch 22, wobei die anwendersignierte Verifizierungsinformation in dem Anwender-Endgerät in Antwort auf eine Zufallsaufforderung, die von dem Dienstvereinbarungsmanager initiiert ist, und die Dienstvereinbarungsinformation erzeugt wird.
  26. System nach Anspruch 22, wobei die anwendersignierte Verifizierungsinformation im Anwender-Endgerät basierend auf einem auf der Anwenderseite initialisierten Ticket und der Dienstvereinbarungsinformation erzeugt wird.
  27. System nach Anspruch 21, wobei die Dienstvereinbarungsinformation durch den Service-Provider vorbereitet wird.
  28. System nach Anspruch 21, wobei die Einrichtung zum kryptographischen Verarbeiten der Dienstvereinbarungsinformation folgendes aufweist: – eine Einrichtung zum Durchführen bei dem Dienstvereinbarungsmanager einer kryptographischen Verarbeitung der Dienstvereinbarungsinformation basierend auf dem gemeinsam genutzten geheimen Schlüssel, um eine kryptographische Darstellung der Dienstvereinbarungsinformation zu erzeugen, wobei die kryptographische Darstellung zum Anwender weitergeleitet wird; und – eine Einrichtung zum Durchführen einer kryptographischen Verarbeitung der kryptographischen Darstellung basierend auf dem gemeinsam genutzten geheimen Schlüssel, um die anwendersignierte Verifizierungsinformation zu erzeugen, im Anwender-Endgerät.
  29. System nach Anspruch 28, wobei die Einrichtung zum Durchführen einer kryptographischen Verarbeitung bei dem Dienstvereinbarungsmanager folgendes aufweist: – eine Einrichtung zum Erzeugen eines Tickets basierend auf der Dienstvereinbarungsinformation; und – eine Einrichtung zum Verschlüsseln des Tickets basierend auf einem Nichtablehnungsschlüssel, der lokal von dem gemeinsam genutzten geheimen Schlüssel abgeleitet ist; und wobei die Einrichtung zum Durchführen einer kryptographischen Verarbeitung im Anwender-Endgerät eine Einrichtung zum Entschlüsseln des verschlüsselten Tickets basierend auf dem Nichtablehnungsschlüssel aufweist, der lokal von dem gemeinsam genutzten geheimen Schlüssel abgeleitet ist.
  30. System nach Anspruch 21, wobei die Dienstvereinbarungsinformation ein allgemeiner elektronischer Vertrag ist und wobei das System weiterhin folgendes aufweist: – eine Einrichtung zum Erzeugen von erwarteter Dienstvereinbarungs-Verifizierungsinformation basierend auf dem gemeinsam genutzten geheimen Schlüssel und dem elektronischen Vertrag bei dem Dienstvereinbarungsmanager; – eine Einrichtung zum Maskieren der erwarteten Verifizierungsinformation durch eine Maskierungsfunktion bei dem Dienstvereinbarungsmanager; – eine Einrichtung zum Weiterleiten der maskierten erwarteten Verifizierungsinformation zum Service-Provider bei dem Dienstvereinbarungsmanager; – eine Einrichtung zum Maskieren der anwendersignierten Verifizierungsinformation durch einen Fall derselben Maskierungsfunktion, um maskierte anwendersignierte Verifizierungsinformation zu erzeugen, bei dem Service-Provider; – eine Einrichtung zum Verifizieren, dass die maskierte anwendersignierte Verifizierungsinformation der von dem Dienstvereinbarungsmanager erhaltenen maskierten erwarteten Verifizierungsinformation entspricht, bei dem Service-Provider.
  31. System nach Anspruch 30, wobei die Einrichtung zum Erzeugen von erwarteter Dienstvereinbarungs-Verifizierungsinformation eine Einrichtung zum Anwenden einer kryptographischen Hash-Codierung des Vertrags als Zufallsaufforderung in einer normalen auf einer Aufforderung/Antwort basierenden Authentifizierungs- und Schlüsselvereinbarungsprozedur aufweist.
  32. System nach Anspruch 30, wobei die Maskierungsfunktion eine kryptographische Hash-Funktion ist.
  33. System nach Anspruch 21, wobei das Nichtablehnungssystem mit einem System für eine auf einer Aufforderung/Antwort basierende Authentifizierungs- und Schlüsselvereinbarung (AKA) für einen Netzwerkzugriff integriert ist, wobei der gemeinsam genutzte geheime Schlüssel derselbe wie ein für AKA verwendeter geheimer Schlüssel ist.
  34. System nach Anspruch 33, das weiterhin eine Einrichtung zum Isolieren von Schlüsselgebungsmaterial für eine Nichtablehnung der Dienstvereinbarung vom Schlüsselgebungsmaterial für die auf einer Aufforderung/Antwort basierende AKA aufweist.
  35. System nach Anspruch 34, wobei das Schlüsselgebungsmaterial für eine Nichtablehnung mittels einer Pseudozufallsfunktion basierend auf Schlüsselgebungsmaterial für AKA als Eingabe zu der Pseudozufallsfunktion erzeugt wird.
  36. System nach Anspruch 34, wobei das Schlüsselgebungsmaterial für eine Nichtablehnung an einen spezifischen Bezahlungsvermittler gebunden ist, der mit einem Authentifizierungsmanager zusammenarbeitet, wobei der Authentifizierungsmanager und das Anwender-Endgerät den geheimen Schlüssel gemeinsam nutzen.
  37. System nach Anspruch 34, wobei das Schlüsselgebungsmaterial für eine Nichtablehnung an den Service-Provider gebunden ist, um das Schlüsselgebungsmaterial von entsprechendem Schlüsselgebungsmaterial für einen anderen Service-Provider zu isolieren.
  38. System nach Anspruch 21, wobei die Dienstvereinbarungsinformation Dienstgebühreninformation enthält und der Dienstvereinbarungsmanager ein Bezahlungsprovider ist, der zum Handhaben einer Bezahlung des Dienstes im Auftrag des Anwenders betreibbar ist.
  39. System nach Anspruch 21, wobei der Dienstvereinbarungsmanager einen Anwenderidentitätsvermittler und einen Bezahlungsvermittler, der zwischen dem Service-Provider und dem Identitätsvermittler angeordnet ist, enthält und eine Vertrauenskette zwischen dem Service-Provider, dem Bezahlungsvermittler und dem Identitätsvermittler gebildet ist, wobei der Identitätsvermittler den geheimen Schlüssel mit dem Anwender-Endgerät gemeinsam nutzt.
  40. System nach Anspruch 39, das weiterhin eine Einrichtung zum Verifizieren bei dem Bezahlungsvermittler anwendersignierten Verifizierungsinformation basierend auf einem von dem Identitätsvermittler erhaltenen Nichtablehnungsschlüssel aufweist, abgeleitet basierend auf dem gemeinsam genutzten geheimen Schlüssel.
  41. Anwender-Endgerät, das folgendes aufweist: – eine Einrichtung zum sicheren Halten eines geheimen Schlüssels, der mit einem externen Dienstvereinbarungsmanager gemeinsam genutzt wird, wobei der Dienstvereinbarungsmanager eine Vertrauensbeziehung mit einem Service-Provider hat; – eine Einrichtung zum Empfangen von Information, die eine Dienstvereinbarung zwischen einem Anwender und dem Service-Provider darstellt; – eine Einrichtung zum sicheren Durchführen einer kryptographischen Verarbeitung der Dienstvereinbarung, die Information darstellt, basierend auf dem gemeinsam genutzten geheimen Schlüssel, um anwendersignierte Dienstvereinbarungs-Verifizierungsinformation zu erzeugen; – eine Einrichtung zum Weiterleiten der anwendersignierten Verifizierungsinformation zum Service-Provider, um eine Verifizierung der Dienstvereinbarung basierend auf der Vertrauensbeziehung zwischen dem Service-Provider und dem Dienstvereinbarungsmanager zu ermöglichen.
  42. Dienstvereinbarungsmanager zum Helfen bei einem Management einer Dienstvereinbarung zwischen einem Anwender und einem Service-Provider in einem Kommunikationssystem, wobei der Dienstvereinbarungsmanager folgendes aufweist: – eine Einrichtung zum sicheren Halten eines geheimen Schlüssels, der mit einem Anwender-Endgerät gemeinsam genutzt wird, wobei der Dienstvereinbarungsmanager eine Vertrauensbeziehung mit dem Service-Provider hat; – eine Einrichtung zum Empfangen von anwendersignierter Dienstvereinbarungs-Verifizierungsinformation die durch das Anwender-Endgerät erzeugt ist, basierend auf Information, die die Dienstvereinbarung darstellt und dem gemeinsam genutzten geheimen Schlüssel; – eine Einrichtung zum Verifizieren basierend auf dem gemeinsam genutzten geheimen Schlüssel der anwendersignierten Verifizierungsinformation, um dadurch eine Anwenderakzeptanz der Dienstvereinbarung zu bestätigen.
  43. Service-Provider zum Liefern eines Dienstes zu einem Anwender gemäß einer gegebenen Dienstvereinbarung zwischen dem Anwender und dem Service-Provider in einem Kommunikationssystem, wobei der Service-Provider folgendes aufweist: – eine Einrichtung zum Bilden einer Vertrauensbeziehung mit einem Dienstvereinbarungsmanager, wobei der Dienstvereinbarungsmanager einen geheimen Schlüssel mit einem Anwender-Endgerät gemeinsam nutzt; – eine Einrichtung zum Empfangen von dem Anwender-Endgerät von anwendersignierter Dienstvereinbarungs-Verifizierungsinformation, die wenigstens teilweise basierend auf Information, die die Dienstvereinbarung darstellt, und dem gemeinsam genutzten geheimen Schlüssel erzeugt ist; – eine Einrichtung zum Erzeugen von maskierter anwendersignierter Verifizierungsinformation durch eine Maskierungsfunktion; – eine Einrichtung zum Empfangen von erwarteter Verifizierungsinformation von dem Dienstvereinbarungsmanager, die durch einen Fall derselben Maskierungsfunktion maskiert ist, wobei die erwartete Verifizierungsinformation wenigstens teilweise basierend auf der Dienstvereinbarungsinformation und dem gemeinsam genutzten geheimen Schlüssel erzeugt ist; – eine Einrichtung zum Verifizieren, dass die maskierte anwendersignierte Verifizierungsinformation der maskierten erwarteten Verifizierungsinformation entspricht, um eine Anwenderakzeptanz der Dienstvereinbarung zu bestätigen.
  44. Verfahren für eine verbesserte auf einer Aufforderung/Antwort basierende Authentifizierungs- und Schlüsselvereinbarung (AKA) einschließlich eines Anwenders, eines Service-Providers und eines Netzwerkbetreibers mit einer Vertrauensbeziehung mit dem Service-Provider, wobei der Netzwerkbetreiber einen geheimen Schlüssel mit dem Anwender für eine wechselseitige Erzeugung von AKA-Parametern gemeinsam nutzt, wobei die Verbesserung durch Isolieren einer ersten Gruppe von AKA-Parametern für einen Zugriff auf ein Netzwerk, das durch den Netzwerkbetreiber gemanagt wird, von einer zweiten Gruppe von AKA-Parametern für einen Zugriff auf Dienste durch den Service-Provider mittels einer vorbestimmten Funktion unter Verwendung einer Darstellung von wenigstens einem Teil der ersten Gruppe von AKA-Parametern als Eingabe zum Erzeugen der zweiten Gruppe von AKA-Parametern definiert ist.
  45. Verfahren nach Anspruch 44, wobei die erste Gruppe von AKA-Parametern und die zweite Gruppe von AKA-Parametern auf der Seite des Netzwerkbetreibers sowie auf der Anwenderseite basierend auf dem gemeinsam genutzten geheimen Schlüssel und einer anfangs auf der Seite des Netzwerkbetreibers erzeugten Aufforderung erzeugt werden, und wobei die zweite Gruppe von AKA-Parametern vom Netzwerkbetreiber sicher zum Service-Provider transferiert werden.
  46. Verfahren nach Anspruch 45, wobei der Service-Provider eine weitere Gruppe von AKA-Parametern für Zwecke einer erneuten Authentifizierung mittels eines Falls der vorbestimmten Funktion unter Verwendung von wenigstens einem Teil der zweiten Gruppe von AKA-Parametern als Eingabe erzeugt.
  47. Verfahren nach Anspruch 44, wobei die vorbestimmte Funktion eine Pseudozufallsfunktion ist.
DE10392788T 2002-06-12 2003-06-04 Nichtablehnung von Dienstvereinbarungen Ceased DE10392788T5 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US10/278,362 2002-01-02
US38850302P 2002-06-12 2002-06-12
US60/388,503 2002-06-12
US10/278,362 US7194765B2 (en) 2002-06-12 2002-10-22 Challenge-response user authentication
US45529103P 2003-03-17 2003-03-17
US60/455,291 2003-03-17
PCT/SE2003/000934 WO2003107584A1 (en) 2002-01-02 2003-06-04 Non-repudiation of service agreements

Publications (1)

Publication Number Publication Date
DE10392788T5 true DE10392788T5 (de) 2005-05-25

Family

ID=29740732

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10392788T Ceased DE10392788T5 (de) 2002-06-12 2003-06-04 Nichtablehnung von Dienstvereinbarungen

Country Status (6)

Country Link
JP (1) JP4213664B2 (de)
CN (1) CN1659820A (de)
AU (1) AU2003238996A1 (de)
DE (1) DE10392788T5 (de)
GB (1) GB2403880B (de)
WO (1) WO2003107584A1 (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100563153C (zh) * 2004-04-07 2009-11-25 华为技术有限公司 一种在端到端无线加密通讯系统中用户登记鉴权的方法
KR100995423B1 (ko) 2005-01-28 2010-11-18 텔레폰악티에볼라겟엘엠에릭슨(펍) 통신 시스템에서 사용자 인증 및 권한 부여
US7877787B2 (en) * 2005-02-14 2011-01-25 Nokia Corporation Method and apparatus for optimal transfer of data in a wireless communications system
KR100755394B1 (ko) * 2006-03-07 2007-09-04 한국전자통신연구원 Ｕｍｔｓ와 무선랜간의 핸드오버 시 ｕｍｔｓ에서의 빠른재인증 방법
US9106409B2 (en) 2006-03-28 2015-08-11 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for handling keys used for encryption and integrity
ES2807532T3 (es) * 2006-03-28 2021-02-23 Ericsson Telefon Ab L M Un método y aparato para manejar claves para encriptación e integridad
EP2168085A2 (de) * 2007-06-20 2010-03-31 Mchek India Payment Systems PVT. LTD. Verfahren und system für sichere authentifikation
CN101436930A (zh) 2007-11-16 2009-05-20 华为技术有限公司 一种密钥分发的方法、系统和设备
CN100495964C (zh) * 2007-12-03 2009-06-03 西安西电捷通无线网络通信有限公司 一种轻型接入认证方法
WO2010128348A1 (en) * 2009-05-08 2010-11-11 Telefonaktiebolaget L M Ericsson (Publ) System and method of using a gaa/gba architecture as digital signature enabler
US9385862B2 (en) 2010-06-16 2016-07-05 Qualcomm Incorporated Method and apparatus for binding subscriber authentication and device authentication in communication systems
CN102296770B (zh) * 2011-06-07 2013-05-01 广州市致盛建筑材料有限公司 建筑装饰用三维人造石板的制造方法
FR3003979B1 (fr) * 2013-03-28 2015-04-24 Idcapt Procede d'authentification
KR101400736B1 (ko) 2013-10-16 2014-05-29 (주)씽크에이티 신뢰기관과의 연계를 통한 부인방지기능을 포함한 전화인증서 구현방법 및 시스템
EP3198581B1 (de) * 2015-03-31 2019-12-25 SZ DJI Technology Co., Ltd. Systeme und verfahren zur gegenseitigen uav-authentifizierung
WO2016154943A1 (en) 2015-03-31 2016-10-06 SZ DJI Technology Co., Ltd. Systems and methods for geo-fencing device communications
JP6423521B2 (ja) 2015-03-31 2018-11-14 エスゼット ディージェイアイ テクノロジー カンパニー リミテッドＳｚ Ｄｊｉ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．，Ｌｔｄ 無人航空機を制御するシステム
EP3485420A4 (de) * 2016-07-14 2020-04-29 Kumar, Srijan Client-server-basiertes system für kollusionsbeständige, verifizierbare und nachweisbar faire token-basierte spiele und dafür angewendete verfahren
JP6745403B2 (ja) * 2017-04-11 2020-08-26 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． ネットワーク認証方法、デバイス、およびシステム
US10869190B2 (en) * 2018-07-13 2020-12-15 Micron Technology, Inc. Secure vehicular services communication

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996007256A1 (fr) * 1994-08-30 1996-03-07 Kokusai Denshin Denwa Co., Ltd. Systeme de certification
US6199052B1 (en) * 1998-03-06 2001-03-06 Deloitte & Touche Usa Llp Secure electronic transactions using a trusted intermediary with archive and verification request services
AU7745100A (en) * 1999-10-01 2001-04-30 Ecomxml Inc. A method for prohibiting transacting parties from subsequently repudiating an executed transaction with trusted third party

Also Published As

Publication number Publication date
GB0424869D0 (en) 2004-12-15
CN1659820A (zh) 2005-08-24
AU2003238996A1 (en) 2003-12-31
JP2005529569A (ja) 2005-09-29
GB2403880A (en) 2005-01-12
JP4213664B2 (ja) 2009-01-21
GB2403880B (en) 2005-11-09
WO2003107584A1 (en) 2003-12-24

Similar Documents

Publication Publication Date Title
DE10392788T5 (de) Nichtablehnung von Dienstvereinbarungen
DE60114789T2 (de) Authentifizierung in einem paketdatennetz
DE102011118367B4 (de) Verfahren zur Authentisierung eines Telekommunikationsendgeräts umfassend ein Identitätsmodul an einer Servereinrichtung eines Telekommunikationsnetzes, Verwendung eines Identitätsmoduls, Identitätsmodul und Computerprogramm
DE60104411T2 (de) Verfahren zur übertragung einer zahlungsinformation zwischen einem endgerät und einer dritten vorrichtung
EP0472714B1 (de) Verfahren zur authentifizierung eines eine datenstation benutzenden anwenders
DE69830902T2 (de) Zweiweg-authentifizierung-protokoll
DE60310968T2 (de) Sicherheits- und Privatsphärenverbesserungen für Sicherheitseinrichtungen
DE69433771T2 (de) Verfahren und Vorrichtung zur Geheimhaltung und Authentifizierung in einem mobilen drahtlosen Netz
DE60114895T2 (de) System und verfahren zum laden einer temporären infrastruktur mit öffentlichen schlüsseln aus einer zellularen telekommunikationsauthentifizierungs- und abrechnungsinfrastruktur
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE602004012233T2 (de) Verfahren zur Bereitstellung eines Signierungsschlüssels zur digitalen Signierung, Überprüfung oder Verschlüsselung von Daten
EP1449324B1 (de) Nutzung eines public-key-schlüsselpaares im endgerät zur authentisierung und autorisierung des telekommunikations-teilnehmers gegenüber dem netzbetreiber und geschäftspartnern
DE69838003T2 (de) Verfahren zum etablieren des vertrauenswürdigkeitgrades eines teilnehmers während einer kommunikationsverbindung
DE69734757T2 (de) Inhaltübertragungskontrollverfahren mit Benutzerauthentifizierungsfunktionen
DE102007044905A1 (de) Verfahren und Vorrichtung zur Ermöglichung einer Dienstnutzung und Feststellung der Teilnehmeridentität in Kommunikationsnetzen mittels softwarebasierten Zugangsberechtigungsausweisen (vSIM)
EP1595420A1 (de) Verfahren zum bilden und verteilen kryptographischer schlüssel in einem mobilfunksystem und mobilfunksystem
DE10212620A1 (de) Sichere Benutzer- und Datenauthentisierung über ein Kommunikationsnetzwerk
DE112008002860T5 (de) Verfahren und Vorrichtung für das Bereitstellen einer sicheren Verknüpfung mit einer Benutzeridentität in einem System für digitale Rechteverwaltung
WO2002095637A2 (de) Verfahren zum erbringen von diensten in einem datenübertragungsnetz und zugehörige komponenten
DE10124427A1 (de) System und Verfahren für einen sicheren Vergleich eines gemeinsamen Geheimnisses von Kommunikationsgeräten
DE102017210721A1 (de) Verfahren und Kommunikationssystem zum effizienten Aufbau einer sicheren Datenverbindung zwischen einem Client-Rechner und einem Server-Rechner
DE602004012103T2 (de) Verfahren zum verteilen von passwörtern
DE60224391T2 (de) Sicherer Zugang zu einem Teilnehmermodul
EP3641369B1 (de) Absicherung einer p2p-kommunikation
DE60115672T2 (de) Sicherheitsarchitektur der internet-protokoll telefonie

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final

Effective date: 20130208