DE60129951T2 - Verfahren zur transaktionensermächtigung - Google Patents

Verfahren zur transaktionensermächtigung Download PDF

Info

Publication number
DE60129951T2
DE60129951T2 DE60129951T DE60129951T DE60129951T2 DE 60129951 T2 DE60129951 T2 DE 60129951T2 DE 60129951 T DE60129951 T DE 60129951T DE 60129951 T DE60129951 T DE 60129951T DE 60129951 T2 DE60129951 T2 DE 60129951T2
Authority
DE
Germany
Prior art keywords
authorization
message
identifier
request
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE60129951T
Other languages
English (en)
Other versions
DE60129951D1 (de
Inventor
Marko Schuba
Konrad Wrona
Guido Zavagli
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
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of DE60129951D1 publication Critical patent/DE60129951D1/de
Publication of DE60129951T2 publication Critical patent/DE60129951T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827Use of message hashing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Payment protocols; Details thereof using an alias or single-use codes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce

Description

  • TECHNISCHES GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft ein Verfahren gemäß dem Oberbegriff von Anspruch 1. Geräte und Softwaremodule, welche die Erfindung verkörpern, werden ebenfalls beschrieben.
  • STAND DER TECHNIK
  • Digitale Signaturen werden gewöhnlich in Sicherheitsprotokollen und Protokollen des elektronischen Handels verwendet, um für eine Authentifizierung von beteiligten Entitäten und eine Transaktionsautorisierung zu sorgen. Aus Gründen der Effizienz und Sicherheit werden digitale Signaturen normalerweise auf einen Hash von zu signierenden Daten angewendet, anstatt auf die Daten selbst. Ein Hash ist ein eindeutiges Ergebnis, welches mittels einer Funktion aus Eingangsdaten erzeugt wird und welches eine feste Größe hat, unabhängig von der Menge von Eingangsdaten. Vorzugsweise verursachen minimale Änderungen in den Eingangsdaten maximale Änderungen in dem Hash, und die Wahrscheinlichkeit möglicher Ergebnisse ist vorzugsweise für einen beliebigen Eingang gleich.
  • Eine Autorisierung ist oft für Proxy-basierte Dienste notwendig, die von einem drahtlosen Teilnehmergerät verwendet werden, z.B. einem WAP-(Wireless Application Protocol) Telefon. Ein Beispiel eines solchen Dienstes ist eine sichere Kreditkartenzahlung unter Verwendung des Secure Electronic Transaction Protokolls. Gemäß dem Stand der Technik kann die Autorisierung unter Verwendung der Funktion signText() durchgeführt werden, die in der WML (Wireless Markup Language) Script Crypto Library definiert ist (Wireless Application Forum, Ltd, 1999). Die Funktion fordert dazu auf, dass ein Teilnehmer eine Textzeichenkette digital signiert. Die Zeichenkette wird dem Teilnehmer angezeigt, welcher wählen kann, entweder den Inhalt zu genehmigen oder ihn abzulehnen. Die letztere Alternative führt im Allgemeinen zum Abbruch der Ausführung der Funktion. Falls der Teilnehmer den Inhalt genehmigt, wird die Zeichenkette signiert und zu der die Autorisierung anfordernden Entität zurückgesendet, z.B. einem Programm, das auf einem Teilnehmergerät in einem Kommunikationssystem ausgeführt wird. Die Funktion signText() zielt auf Daten ab, welche einem Teilnehmer angezeigt werden können, da die Spezifikation fordert, dass das Teilnehmergerät die Zeichenkette anzeigen muss, für welche die Autorisierung angefordert wird. Diese Prozedur hat den Vorteil, dass der Teilnehmer in der Lage ist, den Inhalt zu prüfen, welcher signiert wird.
  • Es ist jedoch oft notwendig, große Mengen von Daten zu dem Teilnehmergerät zu übertragen, was insbesondere bei drahtlosen Verbindungen mit einer niedrigen Datenübertragungsrate nachteilig ist. Ferner ist es manchmal unmöglich, dem Teilnehmer irgendeinen oder einen sinnvollen Text anzuzeigen, welcher ihn in die Lage versetzt, eine bewusste Autorisierung vorzunehmen. Oft werden Proxy-basierte Mobilanwendungen verwendet, um Interoperabilität zwischen WAP-Geräten und üblichen Internetdiensten und -protokollen zu gewährleisten. Bei Proxy-basierten Anwendungen wird der größte Teil der Transaktionsverarbeitungs-Last durch einen Festnetzknoten ausgeführt, und die Beteiligung des mobilen Endgeräts wird auf die kritischste Funktionalität minimiert, insbesondere Vorgänge der digitalen Signatur. In diesem Falle entsteht normalerweise eine Notwendigkeit des Signierens eines binären Wertes, wenn eine Signaturanforderung von dem Festnetzknoten an den Teilnehmer gesendet wird. Ein binärer Inhalt der Zeichenkette in einer Autorisierungsanforderung ist für den Teilnehmer offensichtlich bedeutungsleer oder kann sogar für eine Anzeige auf einem WAP-Endgerät ungeeignet sein.
  • Das Patent US 5,671,279 beschreibt ein elektronisches Zahlungssystem für Kunden, Händler und Banken, um Kreditkartenzahlungen über Festnetze wie das Internet durchzuführen. In diesem System werden Autorisierungsanforderungen und -antworten zwischen Kunde und Händler ausgetauscht. Es werden digitale Signaturen verwendet, um den Absender einer Nachricht zu authentifizieren. Um eine Transaktion zu identifizieren, wird eine eindeutige Transaktionsnummer in die Anforderung und die Antwort eingefügt. Hashes von Originalnachrichten, die mit dem Empfangszeitpunkt verkettet sind, werden für Quittungen verwendet. Das Verfahren ist jedoch für ein Festnetz vorgesehen, in welchem große Mengen an Daten zu dem Teilnehmer übertragen werden. Daher ist es nicht für ein Kommunikationssystem anwendbar, das nur Übertragungen mit niedrigen Datenraten ermöglicht. Das Problem eines sinnlosen Inhalts tritt nicht auf, da der gesamte für die Autorisierung vorgesehene Inhalt zu dem Teilnehmer übertragen wird.
  • Das Patent US 5,878,141 betrifft ein elektronisches Einkaufssystem, in welchem ein Käufer eine Anforderung empfängt, eine Kauftransaktion zu autorisieren, und den Kauf autorisiert. Für die Autorisierung wird eine Signatur verwendet, wobei diese Signatur in einer entfernten Verarbeitungseinheit und nicht in dem Teilnehmergerät angewendet wird, wodurch das Verfahren nur in einem System mit einer entsprechenden entfernten Verarbeitungseinheit anwendbar ist. Zur Authentifizierung von Nachrichten zwischen der entfernten Verarbeitungseinheit und dem Teilnehmergerät können Signaturen auf einen Hash der Nachricht angewendet werden. Auch in diesem Falle ist das Verfahren für ein Festnetz vorgesehen, in welchem große Mengen an Daten zu dem Teilnehmer übertragen werden, und nicht an ein System mit niedrigen Übertragungsgeschwindigkeiten angepasst. Das Problem eines sinnlosen Inhalts tritt ebenfalls nicht auf, da der gesamte für die Autorisierung vorgesehene Inhalt zu dem Teilnehmer übertragen werden kann.
  • KURZDARSTELLUNG UND BESCHREIBUNG DER ERFINDUNG
  • Es ist eine Aufgabe der vorliegenden Erfindung, die obigen Nachteile zu umgehen und ein Autorisierungsverfahren bereitzustellen, welches eine bewusste Signatur von binären Daten durch einen Teilnehmer ermöglicht. Es ist eine weitere Aufgabe, ein Verfahren bereitzustellen, welches die Möglichkeit bietet, die Menge von Daten zu reduzieren, die für eine bewusste Autorisierung erforderlich ist.
  • Gemäß der Erfindung wird das in Anspruch 1 beschriebene Verfahren durchgeführt. Ferner wird die Erfindung durch Geräte und Programmmodule verkörpert, wie sie in den Ansprüchen 14, 17 und 25 beschrieben sind. Vorteilhafte Ausführungsformen sind in den abhängigen Ansprüchen beschrieben.
  • Bei dem vorgeschlagenen Verfahren empfängt ein Teilnehmergerät eine Autorisierungsanforderung mit einer Kennung einer Transaktion und antwortet auf die Anforderung mit einer Autorisierungsantwort. Die Autorisierungsanforderung entspricht einem Inhalt, welcher zu autorisieren ist, z.B. einer Transaktion. Eine zu bevorzugende Kennung wird auf eine eindeutige Weise durch den Inhalt bestimmt und kann aus ihm berechnet werden. Im Allgemeinen ist die Kennung ein binärer Datenwert, welcher für einen Teilnehmer unverständlich ist. Daher wird eine Meldung für die Autorisierungsanforderung von dem Absender der Anforderung oder von dem Teilnehmergerät bestimmt, d.h. bevor die Anforderung gesendet wird oder nachdem sie empfangen wird. Bei einer einfachen Ausführungsform des Verfahrens kann die Meldung eine Nachricht sein, dass eine Bestätigung von empfangenen Daten angefordert wird, d.h. dieselbe Meldung kann für alle Anforderungen verwendet werden, optional ergänzt durch die Kennung des Absenders. Die Meldung wird von dem Teilnehmergerät angezeigt, z.B. auf dem Bildschirm eines Mobiltele fons. Stattdessen oder zusätzlich ist eine Ausgabe der Meldung auf eine andere Weise möglich, zum Beispiel durch ein akustisches oder Vibrationssignal, um die Meldung hervorzuheben oder um Autorisierungen durch blinde Teilnehmer zu ermöglichen.
  • Der Teilnehmer nimmt eine Eingabe in das Teilnehmergerät vor, um die Autorisierungsanforderung zu genehmigen oder abzulehnen, zum Beispiel unter Verwendung einer Tastatur des. Geräts oder durch eine mündliche Eingabe, falls das Teilnehmergerät eine Sprachverarbeitungseinheit umfasst. Im Falle einer genehmigenden Eingabe des Teilnehmers wird ein Signieren der Kennung durch eine Signierfunktion durchgeführt, im Allgemeinen unter Verwendung eines entsprechenden digitalen Schlüssels des Benutzers. Eine Autorisierungsantwort entsprechend der Genehmigung oder Ablehnung wird von dem Teilnehmergerät zu dem Absender der Autorisierungsanforderung gesendet. Eine genehmigende Antwort umfasst die signierte Kennung, um sowohl sicherzustellen, dass die Signatur von dem Teilnehmergerät durchgeführt wurde, als auch, dass die Autorisierungsantwort dem Inhalt entspricht, für welchen die Autorisierungsanforderung gesendet wurde.
  • Das vorgeschlagene Verfahren hat den Vorteil, dass der Teilnehmer nur Anforderungen mit einem verständlichen Inhalt signiert. Die Menge an Daten, die zu dem Teilnehmergerät übertragen wird, kann verringert werden, da sich der angezeigte Text im Allgemeinen von dem zu genehmigenden Inhalt unterscheidet. Vorzugsweise hat die Kennung eine feste Länge, um die Behandlung der Autorisierungsanforderung und -antwort zu vereinfachen. Die Sicherheit des Verfahrens ist durch die Signatur des Absenders der Autorisierungsantwort sichergestellt, sogar wenn eine Verbindung zum Empfänger der Antwort nicht als sicher eingestuft ist. Das Signieren eines zufälligen binären Wertes bietet außerdem die Möglichkeit einer Authentifizierung und eines Schutzes gegen Wiederholungsangriffe (Replay-Angriffe), bei welchen eine Signatur von einem Dritten abgefangen und an eine weitere Nachricht angehängt wird. Eine entsprechende Signierungsfunktionalität ist vorzugsweise ein untrennbarer Bestandteil einer beliebigen Kryptographie-Anwendungsprogrammschnittstelle und wird durch das vorgeschlagene Verfahren bereitgestellt.
  • Bei einer bevorzugten Ausführungsform der Erfindung ist die Kennung ein Hashwert des Inhalts, welcher zu autorisieren ist. Auf diese Weise hat die Kennung eine vorteilhafte feste Länge. Ein Hashwert ist insbesondere empfindlich gegenüber kleinen Änderungen im Inhalt, so dass typische Abänderungen zu einem betrügerischen Zweck, wie das Ändern einer einzelnen oder einiger Ziffern in einem Vertrag, ausgeschlossen werden können. Ein Hashwert mit einer vergleichsweise geringen Länge, z.B. in der Größenordnung von etwa 50 bis zu einigen Hundert Bits, liefert für die meisten Zwecke eine ausreichend klare Anzeige des zu genehmigenden Inhalts.
  • Es wird vorgeschlagen, dass eine Prüfung durchgeführt wird, ob die Autorisierungsanforderung eine Zeichenkette umfasst und die Meldung die erkannte Zeichenkette oder andernfalls eine Standardzeichenkette ist. Die Zeichenkette enthält vorzugsweise einen kurzen Text, welcher den zu autorisierenden Inhalt für den Teilnehmer auf eine klare Weise kennzeichnet. Sie kann zum Beispiel einen Referenztext umfassen, der den zu autorisierenden Inhalt beschreibt, oder einen kurzen Verweis auf den Inhalt als Ganzes, wie etwa eine Dokumentnummer oder eine Vertragsnummer. Für Bestellungen und Einkäufe sind eine kurze Beschreibung und die Anzahl von gewählten Artikeln, der Betrag für jeden Artikel und der zu zahlende Gesamtbetrag geeignete Elemente der Zeichenkette. Eine Standardzeichenkette ist vorzugsweise eine allgemeine Information, dass eine Transaktion autorisiert werden soll, optional mit einem Warnhinweis, dass eine Genehmigung einen Abschluss eines Vertrages darstellt. Es ist möglich, dass das Teilnehmergerät einen gespeicherten Satz mit verschiedenen Standardzeichenketten aufweist, welche entsprechend Parametern in der Autorisierungsanforderung angezeigt werden.
  • Die Autorisierungsantwort enthält vorzugsweise die angezeigte Zeichenkette, d.h. die mit der Autorisierungsanforderung gesendete Zeichenkette oder die Standardzeichenkette. Zu diesem Zweck kann die Autorisierungsanforderung einen Parameter umfassen, welcher anzeigt, ob der Absender erwartet, dass die Antwort durch die angezeigte Zeichenkette ergänzt wird. Optional kann die angezeigte Zeichenkette in eine beliebige Autorisierungsantwort eingefügt werden. Ein Speichern der angezeigten Zeichenkette liefert dem Empfänger der Autorisierungsantwort einen Nachweis der Meldung, falls zu einem späteren Zeitpunkt Rechtsstreite betreffs der Autorisierungsprozedur entstehen.
  • Es wird vorgeschlagen, dass eine Prüfung durchgeführt wird, ob eine Verbindung als sicher eingestuft ist, und die Meldung ein Ergebnis der Prüfung umfasst oder entsprechend der Prüfung gewählt wird. Auf diese Weise empfängt der Teilnehmer eine Information, ob die Autorisierungsanforderung aus einer sicheren Quelle empfangen wurde. Eine sichere Verbindung ist zum Beispiel eine durchgehende drahtlose Transport Layer Security Verbindung gemäß dem WAP Protokollstapel.
  • Eine vorteilhafte Autorisierungsanforderung umfasst eine Signatur des Absenders. In diesem Falle wird eine Prüfung der Absendersignatur in dem Teilnehmergerät durchgeführt, welches ein für diesen Zweck geeignetes Verarbeitungssystem und vorzugsweise einen Speicher mit entsprechenden Authentifizierungsinformationen aufweist. Die Meldung kann das Ergebnis der Prüfung umfassen oder entsprechend dem Ergebnis gewählt werden. Es wird vorgeschlagen, dass die Autorisierungsprozedur abgebrochen wird, wenn weder die Verbin dung sicher ist noch eine Signatur des Absenders in der Anforderung enthalten ist, oder wenn eine Signatur ungültig ist.
  • Es wird für eine Autorisierungsanforderung oder eine Autorisierungsantwort vorgeschlagen, dass eine Verkettung der Kennung und mindestens eines weiteren Parameters signiert wird. Insbesondere kann die dem Teilnehmer angezeigte Meldung in den signierten Inhalt als eine Bestätigung eingefügt werden. Ein Signieren der Verkettung gewährleistet eine sichere Authentifizierung aller verketteten Parameter mit geringen Anforderungen betreffs des Rechenaufwands und stellt sicher, dass die verketteten Parameter in einer einzigen Prozedur signiert wurden.
  • Vorzugsweise hängt eine Signatur von einem Parameter ab, welcher sich in aufeinander folgenden Nachrichten ändert, um einen Wiederholungsangriff (Replay-Angriff) zu vermeiden. Zu diesem Zweck kann der signierte Inhalt zum Beispiel einen Zeitstempel, einen zufälligen Wert oder einen Zähler umfassen. Der variable Parameter wird vorzugsweise in die Nachricht mit der Signatur eingefügt, um die Authentifizierung durch den Empfänger zu ermöglichen. Es ist möglich, dass die Signatur von mehr als einem variablen Parameter abhängt, z.B. falls eine Hash-Funktion einen zufälligen Wert in dem Hash enthält, welcher dann vor der Signatur mit einem Zeitstempel zu verketten ist.
  • Das Verfahren ist insbesondere für eine Autorisierungsanforderung geeignet, welche von einem ersten Server nach dem Empfang einer oder mehrerer Nachrichten von einer weiteren Entität, z.B. einem weiteren Server oder einem anderen Gerät oder einer anderen Anwendung, gesendet wird. Der erste Server ist zum Beispiel ein Mobilserver zum Anpassen von Nachrichten und Nachrichtenübermittlungs-Folgen zwischen einer weiteren Entität in einem Festnetz, z.B. dem Internet, und einem drahtlosen Teilnehmergerät. Der Mobil server verarbeitet und beantwortet Nachrichten von der weiteren Entität in dem Festnetz, um die Menge an Daten zu verringern, die über drahtlose Verbindungen zu dem Teilnehmergerät gesendet werden. Die weitere Entität kann zum Beispiel Transaktionen für einen Händler verarbeiten, der Waren oder Leistungen anbietet, welche zu bezahlen sind. In diesem Falle wird die Autorisierungsprozedur verwendet, um die Zahlung durchzuführen.
  • Eine vorteilhafte Nachricht von der weiteren Entität umfasst die Meldung, z.B. eine kurze Referenz-Zeichenkette für den Inhalt, welcher zu genehmigen ist, oder einen Parameter, der die Meldung bestimmt. Auf diese Weise wird eine mehrdeutige Bestimmung der Meldung durch den Server vermieden, und ein Diensteanbieter hat eine verbesserte Möglichkeit der Steuerung der Informationen, die von dem Teilnehmergerät angezeigt werden.
  • Im Allgemeinen umfassen eine oder mehrere Nachrichten von der weiteren Entität den zu genehmigenden Inhalt, aus welchem die Kennung bestimmt wird, z.B. den Text eines Vertrags, aus welchem der Server einen Hashwert berechnet. Vorzugsweise leitet der Server eine genehmigte Kennung an die weitere Entität weiter, als Nachweis, dass die Autorisierung von dem Teilnehmergerät durchgeführt wurde.
  • Vorzugsweise speichert der Server die Meldung oder leitet sie zu der weiteren Entität weiter. Auf diese Weise kann ein Nachweis gespeichert werden, welche Meldung dem Teilnehmer angezeigt wurde. Die Meldung kann gespeichert oder weitergeleitet werden, nachdem sie für eine Einfügung in die Autorisierungsanforderung bestimmt wurde, oder nach einer Extraktion aus der Autorisierungsantwort.
  • Ein Server zum Verarbeiten von Autorisierungsprozeduren in einem Kommunikationssystem weist eine Schnittstelle auf, um Nachrichten mit einem Teilnehmergerät des Kommunikations systems auszutauschen. Im Allgemeinen werden Nachrichten von weiteren Geräten in dem Kommunikationssystem weitergesendet, z.B. Routern, welche die Nachrichten weiterleiten, oder Funkbasisstationen, die eine drahtlose Verbindung zu dem Teilnehmergerät bereitstellen. Der Server weist ein Verarbeitungssystem mit einer Einheit auf, um eine Autorisierungsanforderung für einen Inhalt, welcher autorisiert werden soll, an das Teilnehmergerät zu senden und eine Autorisierungsantwort von dem Teilnehmergerät zu empfangen. Vorzugsweise ist die Einheit ein Softwareprogramm.
  • In einem Server gemäß der Erfindung bestimmt das Verarbeitungssystem eine Kennung für den Inhalt und fügt die Kennung in die Autorisierungsanforderung ein. Vorzugsweise ist die Kennung ein Hashwert, der aus dem Inhalt, welcher autorisiert werden soll, berechnet wird. Ferner bestimmt das Verarbeitungssystem eine Meldung für den Inhalt und fügt die Meldung ebenfalls in die Autorisierungsanforderung ein. Der Server prüft die Autorisierungsantwort hinsichtlich der von dem Teilnehmergerät signierten Kennung, d.h. hinsichtlich einer Genehmigung der Anforderung. Der Server kann beliebige Schritte von den oben beschriebenen Verfahren ausführen, welche den Server betreffen.
  • Ein vorteilhafter Server umfasst eine Schnittstelle, um Nachrichten von einer weiteren Entität über das Kommunikationssystem zu empfangen, z.B. von einem weiteren Server. In diesem Falle ist das Verarbeitungssystem in der Lage, den zu autorisierenden Inhalt aus einer Nachricht zu extrahieren, die von der weiteren Netzentität empfangen wurde, und eine Antwort an die weitere Netzentität zu senden. Die Antwort wird durch die Autorisierungsantwort bestimmt, d.h. die Antwort zeigt der weiteren Entität an, ob die Autorisierung genehmigt oder abgelehnt wird.
  • Ein Teilnehmergerät für ein Kommunikationssystem, zum Beispiel ein Mobiltelefon in einem Mobilkommunikationssys tem, weist eine Übertragungseinheit auf, um Nachrichten zu empfangen und zu senden. Die Nachrichten umfassen zum Beispiel Signalisierungsnachrichten zum Steuern von Verbindungen und Nutznachrichten, um Daten oder Sprache und insbesondere Autorisierungsanforderungen und Autorisierungsantworten zu übertragen. Einheiten des Teilnehmergerätes verarbeiten Eingaben eines Teilnehmers, welche zum Beispiel mittels einer Tastatur vorgenommen werden, und führen Ausgaben an den Teilnehmer durch, z.B. mit einem Display. Ferner können Parameter durch eine entsprechende Einheit des Geräts mit einem digitalen Schlüssel des Teilnehmers signiert werden. Die Einheiten können Hardwarebestandteile umfassen, z.B. einen Sender-Empfänger in der Übertragungseinheit, Schaltungen zur Steuerung eines Displays in der Ausgabeeinheit und Schaltungen zur Steuerung einer Tastatur in der Eingabeeinheit. Die Einheiten können auch Softwarecode beinhalten, welcher in einem Verarbeitungssystem des Teilnehmergeräts ausgeführt wird. Insbesondere wird die Signiereinheit im Allgemeinen durch eine Softwarefunktion implementiert sein.
  • Das Verarbeitungssystem führt eine Betriebssoftware aus, welche die besagten Einheiten steuert. Es in der Lage, eine Autorisierungsanforderung mit einer Kennung einer Transaktion zu verarbeiten und die Anforderung mit einer Autorisierungsantwort zu beantworten. Die Kennung ist vorzugsweise ein Hashwert eines Inhalts, welcher autorisiert werden soll. Das Verarbeitungssystem enthält eine Einheit, die vorzugsweise als Softwarecode ausgeführt ist, um eine Meldung für die Anforderung zu bestimmen, um die Ausgabe der Meldung durch die Ausgabeeinheit auszulösen und um auf eine Genehmigung der Anforderung durch den Teilnehmer zu warten, die über die Eingabeeinheit empfangen wird. Entsprechend der Genehmigung löst das Verarbeitungssystem das Senden einer Autorisierungsantwort durch die Übertragungseinheit aus. In einer genehmigenden Autorisierungsantwort fügt das Verarbeitungssystem die signierte Kennung ein, welche von der Signiereinheit bestimmt wird. Zu diesem Zweck kann ein digitaler Schlüssel in einem Speicher des Teilnehmergeräts gespeichert sein. Für einen Fachmann ist klar, dass alle beschriebenen Schritte, die von dem Verarbeitungssystem ausgeführt werden, durch Softwarecode ausgeführt werden können, der in den Verarbeitungsschaltungen ausgeführt wird.
  • Bei einem bevorzugten Teilnehmergerät führt das Verarbeitungssystem eine Prüfung durch, ob die Autorisierungsanforderung eine Textzeichenkette umfasst, und die wählt erkannte Zeichenkette als Meldung oder andernfalls eine Standardzeichenkette.
  • Es wird vorgeschlagen, dass das Verarbeitungssystem die angezeigte Meldung in die Autorisierungsantwort einfügt.
  • Vorteilhafterweise führt das Verarbeitungssystem eine Prüfung durch, ob eine Verbindung als sicher eingestuft ist. Zu diesem Zweck können Parameter, die definieren, ob eine Verbindung sicher ist, in einem Speicher des Teilnehmergeräts gespeichert werden und mit den entsprechenden Parametern einer vorliegenden Verbindung verglichen werden. Das Verarbeitungssystem fügt das Ergebnis der Prüfung in die Meldung ein oder wählt die Meldung entsprechend der Prüfung.
  • Um die Sicherheit einer Transaktion zu erhöhen, prüft ein bevorzugtes Teilnehmergerät, ob die Autorisierungsanforderung eine Signatur des Absenders umfasst. Das Teilnehmergerät führt eine Prüfung der Absendersignatur durch. Es wird vorgeschlagen, dass das Verarbeitungssystem das Ergebnis der Prüfung in die Meldung einfügt oder die Meldung entsprechend der Prüfung wählt.
  • Bei einem vorteilhaften Teilnehmergerät signiert das Verarbeitungssystem eine Verkettung der Kennung und mindestens eines weiteren Parameters.
  • Vorzugsweise fügt das Verarbeitungssystem einen Parameter, welcher sich in aufeinander folgenden Autorisierungsanforderungen oder Autorisierungsantworten ändert, in einen signierten Inhalt ein, z.B. einen Hashwert, der optional mit weiteren Parametern verkettet ist.
  • Eine Computerprogrammeinheit zum Empfangen einer Autorisierungsanforderung mit einer Kennung einer Transaktion und Antworten auf die Anforderung mit einer Autorisierungsantwort kann auf einem Datenträger gespeichert sein oder kann direkt in einem Verarbeitungssystem eines Teilnehmergeräts ausführbar sein. Insbesondere können Teile einer Programmeinheit gemäß der Erfindung durch eine Softwarefunktion verkörpert sein, welche von der Autorisierungsanforderung aufgerufen wird. Die Einheit umfasst Code für einen Empfang der Autorisierungsanforderung, d.h. für eine Erkennung, dass eine Autorisierungsanforderung empfangen wurde, und eine Extraktion von Parametern aus der Anforderung, insbesondere einer Kennung für die Autorisierungsanforderung. Die Einheit bestimmt eine Meldung für die Autorisierungsanforderung, zum Beispiel durch Extrahieren einer Textzeichenkette aus der Autorisierungsanforderung oder durch Wählen derselben aus einem Speicher entsprechend Parametern in der Anforderung. Die Einheit löst eine Ausgabe der Meldung aus, welche im Allgemeinen durch eine Ausgabeeinheit erfolgt. Wenn eine Eingabe empfangen wird, welche die Autorisierungsanforderung genehmigt oder ablehnt, bestimmt die Programmeinheit die Autorisierungsantwort entsprechend der Eingabe. Für eine Genehmigung wird ein Signieren der Kennung ausgelöst und von der Programmeinheit oder von einer weiteren Einheit durchgeführt. Die signierte Kennung wird in eine genehmigende Autorisierungsantwort eingefügt.
  • Die obigen und weitere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung werden in der nachfolgenden ausführlichen Beschreibung bevorzugter Ausführungsformen, die durch die beigefügten Zeichnungen veranschaulicht wird, noch deutlicher ersichtlich.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 zeigt eine Transaktionsautorisierung gemäß der Erfindung unter Verwendung eines signierten Hashwertes.
  • 2 zeigt eine weitere Transaktionsautorisierung gemäß der Erfindung.
  • 3 zeigt eine Transaktion gemäß der Erfindung, an der verschiedene Entitäten beteiligt sind.
  • 4 zeigt ein Teilnehmergerät gemäß der Erfindung.
  • 5 zeigt ein Flussdiagramm eines in einem Server ausgeführten Prozesses gemäß der Erfindung.
  • AUSFÜHRLICHE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
  • 1 zeigt ein Beispiel einer Autorisierungsprozedur in dem vorgeschlagenen Verfahren zwischen einem Teilnehmergerät (User Equipment) UE, z.B. einem WAP-Endgerät, und einem Server MS, z.B. einem WAP-Server. Über ein Kommunikationssystem kann der Server MS im Allgemeinen mit anderen Entitäten verbunden werden, zum Beispiel weiteren Servern oder Anwendungsprogrammen. Ein Programm, das in dem Verarbeitungssystem des Teilnehmergeräts UE ausgeführt wird, sendet eine Dienstanforderung an den Server MS, welcher den angeforderten Dienst verarbeitet. Während dieser Prozedur kann der Server MS Nachrichten mit anderen Entitäten in dem Kommunikationssystem austauschen. Der Server MS erzeugt eine binäre Kennung H, welche mit einer Autorisierungsan forderung an das Teilnehmergerät UE zur Genehmigung, d.h. zum Signieren gesendet wird. Im Allgemeinen ist die binäre Kennung H ein Hash einer Nachricht, die von einer weiteren Entität an den Server gesendet wurde.
  • Wie in 2 dargestellt, kann der Server MS auch eine Textzeichenkette T erzeugen, welche in die Autorisierungsanforderung eingefügt wird und von dem Teilnehmergerät angezeigt wird. Die Textzeichenkette ist ein Kommentar für den Teilnehmer, der den Inhalt kennzeichnet, welcher signiert werden soll, und kann alle "gehashten" Daten oder einen Teil derselben umfassen, z.B. einen zu zahlenden Betrag, eine Dokumentnummer, den Titel eines Vertrags oder eine Liste von bestellten Artikeln. Um eine Validierung der Beziehung zwischen der Zeichenkette T und der Kennung H durch das Teilnehmergerät UE zu ermöglichen, wird vorzugsweise eine Verkettung der Kennung H und der Zeichenkette T von dem Server MS signiert, d.h. ein Parameter SO (sk, H||T) wird in die Autorisierungsanforderung eingefügt, wobei SO die Signierfunktion bezeichnet, sk der Signaturschlüssel des Servers MS und || das Verkettungssymbol ist. Die Textzeichenkette und die Signatur des Servers sind optionale Parameter der Autorisierungsanforderung. Ferner kann die Autorisierungsanforderung einen Parameter "Quittung" umfassen, welcher vorzugsweise ein Boolescher Wert ist und welcher angibt, ob eine Quittung des Teilnehmers von dem Server MS in der Antwort erwartet wird.
  • Nach Empfang der Autorisierungsanforderung prüft das Teilnehmergerät UE die Anzahl enthaltener Argumente. Falls nur ein Argument vorhanden ist, d.h. nur die obligatorische binäre Kennung H, wie in 1 dargestellt, zeigt das Teilnehmergerät UE dem Teilnehmer eine Nachricht an, dass ein zu signierender binärer Wert empfangen wurde, und bittet um eine Bestätigung. Der Teilnehmer kann entweder einwilligen oder es ablehnen, den Signaturprozess durchzuführen. Um die Sicherheit zu erhöhen, wird die Version mit einem einzigen Parameter der Autorisierungsanforderung von einem vorteilhaften Teilnehmergerät UE nur im Falle einer sicheren Verbindung akzeptiert.
  • Im Falle einer Autorisierungsanforderung mit zwei oder mehr Argumenten ist ein Argument vorzugsweise eine Signatur des Servers MS. Das Teilnehmergerät UE überprüft die Serversignatur SO (sk, ...), wobei sk einen Signaturschlüssel des Servers bezeichnet. Ein weiteres Argument ist vorzugsweise eine Textzeichenkette T, welche von dem Teilnehmergerät UE zusätzlich zu dem Ergebnis der Signaturüberprüfung angezeigt wird. Der Teilnehmer wird aufgefordert, den Signaturprozess zu akzeptieren oder abzulehnen, zum Beispiel durch Drücken einer Taste JA oder einer Taste NEIN auf einer Tastatur des Teilnehmergeräts UE oder durch Aussprechen eines entsprechenden Befehls, falls das Teilnehmergerät eine Sprachverarbeitungseinheit aufweist. Optional können die Argumente der Autorisierungsanforderung, z.B. ein Tripel H, T, SO (sk, H||T), in einem Speicher des Teilnehmergeräts UE für eine zukünftige Verwendung gespeichert werden.
  • Die Autorisierungsantwort von dem Teilnehmergerät UE umfasst die binäre Kennung H, die von dem Teilnehmergerät UE signiert wurde, d.h. SO (ck, H), wobei ck ein Autorisierungsschlüssel des Teilnehmergeräts UE ist. Der Wert SO (ck, H) stellt sicher, dass die Autorisierungsanforderung von dem Teilnehmergerät signiert wurde, und kennzeichnet klar den signierten Inhalt. Optional kann eine signierte Quittung, die eine Verkettung des Wertes, welcher zu signieren ist, und der anzuzeigenden Textzeichenkette enthält, durch den Server angefordert werden, z.B. durch den Parameter "Quittung" in 2. Ein Speichern der Quittungen durch den Server dient als Absicherung für den Fall einer Nichtanerkennung des signierten Transaktionsinhalts durch den Teilnehmer im Falle späterer Streitigkeiten über den signierten Inhalt. Die Quittung liefert einen Nachweis, dass der Teilnehmer über den Inhalt der signierten Daten informiert war.
  • Um eine Autorisierung von Transaktionen durch ein Teilnehmergerät UE zu verbessern, welches in der Lage ist, sowohl das beschriebene Verfahren als auch das Wireless Application Protocol zu verwenden, wird eine neue WMLScript Crypto Library Funktion vorgeschlagen, welche unten mit "signData()" bezeichnet ist. Alternativ dazu ist es auch denkbar, eine existierende Funktion für diesen Zweck anzupassen, doch vorzugsweise wird aus Gründen der Klarheit die neue Funktion zu dem WML hinzugefügt. Die Funktion signData() ist anwendungsunabhängig und kann von jedem WAP sicheren Anwendungsschichtprotokoll verwendet werden. Die Tabelle zeigt eine vorteilhafte Funktionsspezifikation, welche verwendet werden kann, um einen Hashwert zu signieren. In diesem Falle ist die Autorisierungsanforderung ein Aufruf der Funktion signData() in dem Client, d.h. dem Teilnehmergerät UE.
    WMLScript: a) signData(H); b) signData(H, T, SO(sk, H||T), Quittung)
    Parameter: H, T, sk, Quittung, SO (sk, H||T )
    Ausgabe: Falls Quittung=FALSE: Der von dem Teilnehmergerät signierte binäre Wert: SO (ck, H) Falls Quittung=TRUE: Der von einem Teilnehmergerät signierte binäre Wert: SO (ck, H) und eine Quittung: SO (ck, H||T)
    Zugehöriges Ereignis: Teilnehmergerät zeigt an: entweder: die Zeichenkette T und ein Ergebnis der Überprüfung von SO (sk, H||T), oder eine Nachricht, die informiert, dass die Kennung H von einem Server nicht authentifiziert wird. Der Teilnehmer muss jeden Signiervorgang bestätigen oder ablehnen.
  • In der Tabelle bezeichnet H binäre Daten, die zu signieren sind (z.B. einen Hashwert). SO (sk, H||T) sind die verketteten Werte von H und T, die von einem Server signiert wurden. Eine Textzeichenkette T wird dem Teilnehmer optional angezeigt. Der Parameter sk ist ein Authentifizierungsschlüssel für den Server MS, ck ist ein Schlüssel für das Teilnehmergerät UE.
  • Da eine Autorisierungsanforderung, z.B. ein Funktionsaufruf signData(), von einem beliebigen Server oder einer beliebigen Anwendung ausgelöst werden kann, ist ihr Ursprung einem Teilnehmer nicht immer bekannt. Um eine falsche Verwendung der Anforderung zu vermeiden, wird eine Autorisierungsantwort mittels der nicht authentifizierten Version der Funktion signData() vorzugsweise nur im Falle einer durchgehenden sicheren Verbindung zwischen einem WAP-Endgerät und einem WAP-Server ausgeführt, z.B. einer WTLS/SSL (Wireless Transport Layer Security/Secure Sockets Layer) Verbindung oder einer durchgehenden WTLS-Verbindung. Andernfalls wird die Funktion abgebrochen, ohne eine Antwort zu senden.
  • Sofern keine Vertraulichkeit erforderlich ist, kann die authentifizierte Funktion signData() ohne WTLS verwendet werden, falls die Signatur von einem zuverlässigen Server als gültig bestimmt wird.
  • Digitale Signaturen des Hashwertes gewährleisten eine wechselseitige Authentifizierung zwischen einem WAP-Teilnehmergerät und einem WAP-Server.
  • Vorzugsweise wird in der Autorisierungsanforderung und der Autorisierungsantwort ein Mechanismus bereitgestellt, um Wiederholungsangriffe zu vermeiden. Zum Beispiel wird ein zeitabhängiger Parameter CLK zu den Eingangsparametern für die Signierfunktion SO addiert. Bei Verwendung einer Funktion signData ist eine vorteilhafte Menge von Parametern daher (H, T, CLK, SO (sk, H||T||CLK)). Um eine Überprüfung der Signatur durch das Teilnehmergerät UE bzw. den Server MS zu ermöglichen, wird der Parameter CLK in die Autorisierungsanforderung oder -antwort eingefügt. Da der Wert SO (... , CLK) im Allgemeinen für jede Transaktion ein anderer ist, kann ein Wiederholungsangriff ausgeschlossen werden.
  • Die vorgeschlagene Autorisierungsprozedur kann auf vorteilhafte Weise auch für eine Authentifizierung des Teilnehmergeräts verwendet werden, indem die Autorisierungsanforderung verwendet wird, um die Authentifizierung zu genehmigen.
  • In 3 ist ein beispielhafter Transaktionsfluss für eine sichere Zahlung dargestellt. In dem Beispiel ist das Teilnehmergerät UE ein WAP-Terminal, z.B. ein Mobiltelefon, während der Server ein Secure Electronic Transaktion Mobilserver MS ist. Ein weiterer Server FS wird von einem Händler oder Lieferanten betrieben, mit dem der Teilnehmer des Geräts UE eine Transaktion durchführen möchte. Der weitere Server FS unterstützt ebenfalls das Secure Electronic Transaction Protokoll. Der Mobilserver MS und der weitere Server FS sind über das Internet verbunden.
  • Wenn ein Teilnehmer zum Beispiel ein Flugticket mit einer Kreditkarte kaufen möchte, startet er eine Browseranwendung auf seinem Teilnehmergerät, sucht die WAP-Site eines Reisebüros auf und tauscht Nachrichten aus, um einen Flug, ein Datum und einen Sitzplatz zu wählen. Der Teilnehmer wählt ein Protokoll für den Kauf, z.B. das Secure Electronic Transaction Protokoll, und sendet eine Dienstanforderung mit den gewählten Elementen an den Mobilserver MS. Optional enthält die Anforderung weitere Informationen, z.B. einen gewählten Händler, falls mehrere Händler den weiteren Server FS gemeinsam nutzen. Der Mobilserver MS löst die Zahlungstransaktion mit dem weiteren Server FS durch eine Zahlungsauslösungsanforderung aus, welche die vom Teilnehmer gewählten Elemente weiterleitet. Der weitere Server antwortet mit einer Zahlungsauslösungs-Antwortnachricht, welche Authentifizierungszertifikate des Lieferanten und einen Inhalt, welcher von dem Teilnehmer autorisiert werden soll, im Allgemeinen einen Vertrag oder einen Teil eines Vertrags wie etwa einen Betrag für einen Kauf, umfasst. In dem Beispiel umfasst der Inhalt vorzugsweise den gewählten Flug, Datum und Sitzplatz, zusammen mit dem Betrag für das Ticket.
  • Der Mobilserver MS prüft die Gültigkeit der Zertifikate und berechnet einen Hash des von dem weiteren Server FS empfangenen Inhalts, der zu autorisieren ist. Falls der Inhalt einen Text umfasst, welcher für den Teilnehmer verständlich ist, wählt der Mobilserver vorzugsweise eine Zeichenkette, welche die Transaktion angibt, z.B. bestellte Artikel und einen Betrag für einen Kauf, oder die Überschrift eines Vertrags. Der Mobilserver MS sendet den Hash des Inhalts und vorzugsweise die Textzeichenkette zu dem Teilnehmerge rät UE. Zu diesem Zweck kann eine Autorisierungsanforderung mit einem Aufruf der Funktion signText() verwendet werden, wenn das Teilnehmergerät UE ein WAP-Endgerät ist.
  • In dem Beispiel wird ein mit PI-TBS bezeichneter Mehrfach-Hash verwendet. Der Mehrfach-Hash umfasst mindestens einen ersten Hashwert, der aus einer ersten Gruppe von Parametern bestimmt wird, z.B. den bestellten Artikeln und einem Betrag für den Kauf, und einen zweiten Hashwert, der aus einer zweiten Gruppe von Parametern bestimmt wird, z.B. dem Betrag für den Kauf und einer Kreditkartennummer oder einer anderen Kontoinformation. Parameter können Bestandteile von zwei oder mehr Gruppen sein. Der Wert PI-TBS ist ein weiterer Hash, der aus den Hashwerten für die Parametergruppen bestimmt wird. Demzufolge können Inhalte für unterschiedliche Empfänger, z.B. den Händler, der eine Bestellung empfängt, und die Bank mit einem Konto für den Teilnehmer, in einer einzigen Transaktion autorisiert werden, während ein Empfänger nur auf diejenigen Parameter zugreifen kann, welche er benötigt.
  • Falls die Autorisierungsanforderung mittels einer Signatur des Mobilservers MS authentifiziert ist, überprüft das Teilnehmergerät UE die Signatur und zeigt dem Teilnehmer den Inhalt einer empfangenen Textzeichenkette an, oder andernfalls eine Standardzeichenkette. Im Falle einer nicht authentifizierten Autorisierungsanforderung prüft ein bevorzugtes Teilnehmergerät UE, ob die verwendete Verbindung als sicher eingestuft ist oder nicht. Zum Beispiel prüft ein WAP-Endgerät den Status der WTLS-Verbindung. Falls die Verbindung nicht als sicher eingestuft ist, wird die Autorisierungsanforderung abgelehnt, und dem Teilnehmer wird eine entsprechende Information angezeigt. Falls eine sichere Verbindung verwendet wird, wird vorzugsweise dem Teilnehmer eine Information angezeigt, dass nicht authentifizierte Daten zum Signieren empfangen wurden.
  • Das Teilnehmergerät UE fordert den Teilnehmer auf, den Signiervorgang zu genehmigen oder abzulehnen, und überträgt seine Antwort in einer Autorisierungsantwort zu dem Mobilserver. Falls der Teilnehmer das Signieren ablehnt oder nicht innerhalb eines vorgegebenen Zeitintervalls eine Antwort eingibt oder eine ungültige Antwort eingibt, wird die Prozedur vorzugsweise abgebrochen, und es wird eine entsprechende Antwort an den Mobilserver MS gesendet. Falls der Teilnehmer das Signieren genehmigt, signiert das Teilnehmergerät UE den Hash mit seinem privaten Schlüssel ck und sendet ihn zurück zu dem Mobilserver MS.
  • Der Mobilserver MS fügt die Antwort des Teilnehmers, insbesondere den signierten Hash SO (ck, PI-TBS), in eine Zahlungsanforderungsnachricht ein und sendet sie zu dem weiteren Server FS. In dem Beispiel ist die Zahlungsanforderungsnachricht eine Secure Electronic Transaction Zahlungsanforderung. Der weitere Server kann die Zahlungsanforderung entsprechend gespeicherten Bedingungen entweder annehmen oder zurückweisen, insbesondere wenn der Teilnehmer ein Stammkunde ist und ein Konto hat. Stattdessen kann der weitere Server auch seinerseits einen Dialog einleiten, z.B. mit einem dritten Server BS einer Bank mit einem in der Zahlungsanforderung angegebenen Konto, um zu erkennen, ob die Zahlungsanforderung akzeptabel ist, bevor eine Zahlungsantwort gesendet wird. Bei dem Mehrfach-Hash PI-TBS kann der erste Hash von der ersten Parametergruppe in dem weiteren Server FS ausgewertet werden, während der zweite Hash von der zweiten Parametergruppe zu dem dritten Server BS zur Auswertung weitergeleitet werden kann. In der Zahlungsantwort benachrichtigt der weitere Server FS den Mobilserver, ob er die Zahlungsanforderung angenommen hat. Nach dem Empfang der Zahlungsantwort von dem weiteren Server FS leitet der Mobilserver MS das Zahlungsergebnis, d.h. die Parameter aus der Zahlungsantwort, welche die Bestätigung oder Zurückweisung des Transaktionsinhalts durch den weiteren Server FS angeben, an das Teilnehmerge rät UE weiter. Zu diesem Zweck wird eine Dienstantwort-Nachricht verwendet, mit welcher die Transaktion bei dem Teilnehmergerät UE endet.
  • 4 zeigt ein Teilnehmergerät zur Abwicklung von Autorisierungsprozeduren. Das Teilnehmergerät ist zum Beispiel ein Mobiltelefon oder ein anderes Endgerät, z.B. ein persönlicher digitaler Assistent oder ein Laptop. Es umfasst eine Eingabeeinheit IU mit einer Tastatur und entsprechenden Steuerschaltungen und eine Ausgabeeinheit OU mit einem Display und entsprechenden Steuerschaltungen. Eine Übertragungseinheit TU mit einem Sender-Empfänger ermöglicht drahtlose Verbindungen über eine Antenne ANT zu einem Kommunikationssystem. Alle Einheiten werden von einem Verarbeitungssystem PS gesteuert, welches auf einen Speicher MEM zugreifen kann. Die Einheiten können Softwarecode enthalten, welcher in dem Verarbeitungssystem PS ausgeführt wird, und können Hardware und Software gemeinsam nutzen, z.B. wenn die Tastatur auf einem Berührungsbildschirm angezeigt wird.
  • Wenn eine Betriebssoftware OS, die in dem Verarbeitungssystem PS ausgeführt wird, über die Übertragungseinheit TU eine Autorisierungsanforderung empfängt, wird eine Softwareeinheit zur Verarbeitung der Autorisierungsanforderung gestartet. Eine bevorzugte Softwareeinheit ist die Funktion signData(). Die Funktion signData() extrahiert Parameter aus der Anforderung, insbesondere eine Kennung H, die einer Transaktion entspricht, und eine Textzeichenkette T. Die Funktion signData() bestimmt eine Meldung für die Anforderung, d.h. die Textzeichenkette T oder eine im Speicher MEM gespeicherte Standardzeichenkette, falls die Autorisierungsanforderung keine Textzeichenkette T enthält. Die Funktion signData() löst dann eine Ausgabe der Meldung durch die Ausgabeeinheit OU aus und wartet auf eine Genehmigung der Anforderung durch den Teilnehmer, welche über die Eingabeeinheit IU empfangen wird. Falls die Eingabe die Autorisierung genehmigt, löst die Funktion signData() ein Signieren der Kennung H aus, welches im Allgemeinen von einer separaten Signiereinheit SU vorgenommen wird, die in dem Verarbeitungssystem ausgeführt wird. Entsprechend der Genehmigung bestimmt die Funktion signData() eine Autorisierungsantwort und löst das Senden der Antwort durch die Übertragungseinheit TU aus. Die Autorisierungsantwort enthält die signierte Kennung SO (ck, H).
  • Ein Flussdiagramm eines Prozesses zur Autorisierung in einem Server gemäß der Erfindung ist in 5 dargestellt. In einem Anfangsschritt 2 erkennt der Server, dass eine Autorisierung notwendig ist. Zum Beispiel kann der Server eine Nachricht, die eine Autorisierung anfordert, von einer anderen Entität in einem Kommunikationssystem empfangen, oder eine auf dem Server ausgeführte Anwendung erfordert eine Autorisierung. Parameter, die für eine Autorisierungsanforderung notwendig sind, werden durch eine Prozedur 4 bestimmt. Als Kennung H wird aus dem Inhalt, welcher zu autorisieren ist, ein Hashwert berechnet. Ferner wird eine Meldung T für die Anzeige für einen Teilnehmer bestimmt, und eine Signatur der verketteten Kennung H und Meldung T durch einen digitalen Schlüssel sk des Servers wird mit einer Signierfunktion SO ausgeführt.
  • Die Parameter werden in eine Autorisierungsanforderung eingefügt, welche in Schritt 6 zu einem Teilnehmergerät zur Genehmigung gesendet wird, und es wird auf den Empfang 8 einer Autorisierungsantwort gewartet. Die Autorisierungsantwort wird von dem Server in einer Prozedur 10 verarbeitet, wobei eine Prüfung durchgeführt wird, ob sie eine Signatur der Kennung H mittels eines Schlüssels ck des Teilnehmergeräts mit derselben oder einer weiteren Signierfunktion SO' enthält. Wenn die Autorisierung durch eine Nachricht von einer weiteren Entität ausgelöst wurde, kann der Wert SO'(ck, H) zur Auswertung weitergeleitet werden, oder die Genehmigung oder Ablehnung kann der weiteren Entität nach Prüfung der Gültigkeit des Wertes SO'(ck, H) bestätigt werden.
  • Durch die obigen Ausführungsformen werden die Aufgaben der Erfindung ausgezeichnet gelöst. Es ist jedoch klar, dass von Fachleuten Abänderungen vorgenommen werden können, ohne den Rahmen der Erfindung zu verlassen, welcher nur durch die Ansprüche begrenzt ist.

Claims (26)

  1. Verfahren zur Autorisierung von Transaktionen, wobei ein Teilnehmergerät (UE) eine Autorisierungsanforderung (6) für einen Inhalt, welcher autorisiert werden soll, mit einer Kennung (H) einer Transaktion empfängt und wobei das Teilnehmergerät (UE) auf die Anforderung mit einer Autorisierungsantwort (8) antwortet, wobei das Verfahren die folgenden Schritte umfasst: Berechnen der Kennung (H) aus dem Inhalt, Übertragen der Autorisierungsanforderung (6) mit der Kennung (H) zu dem Teilnehmergerät (UE), Empfang der Autorisierungsanforderung (6), Bestimmen einer Meldung für die Autorisierungsanforderung (6), Ausgabe der Meldung durch das Teilnehmergerät (UE), Warten auf eine Eingabe, um die Autorisierungsanforderung (6) zu genehmigen oder abzulehnen, Signieren der Kennung (H) mittels einer Signierfunktion, Senden der Autorisierungsantwort (8) entsprechend der Eingabe, wobei eine genehmigende Autorisierungsantwort (8) die signierte Kennung (H) umfasst.
  2. Verfahren nach Anspruch 1, wobei die Kennung (H) ein Hashwert ist.
  3. Verfahren nach Anspruch 1 oder 2, wobei eine Prüfung durchgeführt wird, ob die Autorisierungsanforderung (6) eine Zeichenkette (T) umfasst und die Meldung die erkannte Zeichenkette (T) oder andernfalls eine Standardzeichenkette ist.
  4. Verfahren nach einem der vorhergehenden Ansprüche, wobei die angezeigte Meldung in der Autorisierungsantwort (8) enthalten ist.
  5. Verfahren nach einem der vorhergehenden Ansprüche, wobei eine Prüfung durchgeführt wird, ob eine Verbindung als sicher eingestuft ist, und die Meldung ein Ergebnis der Prüfung umfasst oder entsprechend der Prüfung gewählt wird.
  6. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Autorisierungsanforderung (6) eine Signatur des Absenders umfasst und eine Prüfung der Absendersignatur durchgeführt wird.
  7. Verfahren nach Anspruch 6, wobei die Meldung ein Ergebnis der Prüfung umfasst oder entsprechend der Prüfung gewählt wird.
  8. Verfahren nach einem der vorhergehenden Ansprüche, wobei eine Verkettung der Kennung (H) und mindestens eines weiteren Parameters signiert wird.
  9. Verfahren nach einem der vorhergehenden Ansprüche, wobei eine Signatur von einem Parameter abhängt, welcher sich in aufeinander folgenden Autorisierungsanforderungen oder Autorisierungsantworten ändert.
  10. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Autorisierungsanforderung (6) von einem Server (MS) nach dem Empfang einer Nachricht von einer weiteren Entität gesendet wird.
  11. Verfahren nach Anspruch 10, wobei die Nachricht die Meldung oder einen die Meldung bestimmenden Parameter umfasst.
  12. Verfahren nach Anspruch 10 oder 11, wobei der Server (MS) eine Genehmigung der Kennung (H) an die weitere Entität weiterleitet.
  13. Verfahren nach einem der Ansprüche 10 bis 12, wobei der Server (MS) die Meldung speichert oder sie zu der weiteren Entität weiterleitet.
  14. Server zum Verarbeiten von Autorisierungsprozeduren in einem Kommunikationssystem mit einer Schnittstelle, um Nachrichten mit einem Teilnehmergerät des Kommunikationssystems auszutauschen, wobei der Server ein Verarbeitungssystem aufweist, das in der Lage ist, eine Autorisierungsanforderung (6) für einen Inhalt, welcher autorisiert werden soll, an das Teilnehmergerät zu senden und eine Autorisierungsantwort (8) von dem Teilnehmergerät zu empfangen, dadurch gekennzeichnet, dass das Verarbeitungssystem ferner in der Lage ist, eine Kennung (H) aus dem Inhalt zu berechnen und die Kennung (H) in die Autorisierungsanforderung (6) einzufügen, das Verarbeitungssystem ferner in der Lage ist, eine Meldung für den Inhalt zu bestimmen und die Meldung in die Autorisierungsanforderung (6) einzufügen, und der Server (MS) in der Lage ist, die Autorisierungsantwort (8) hinsichtlich der von dem Teilnehmergerät (UE) signierten Kennung (H) zu prüfen.
  15. Server nach Anspruch 14, wobei der Server (MS) eine Schnittstelle umfasst, um Nachrichten von einer weiteren Entität zu empfangen, und das Verarbeitungssystem in der Lage ist, den Inhalt zur Autorisierung aus einer Nachricht zu extrahieren, die von der weiteren Netzentität empfangen wurde, und eine Antwort an die weitere Netzentität zu senden, wobei die Antwort durch die Autorisierungsantwort bestimmt wird.
  16. Server nach einem der Ansprüche 14 oder 15, wobei der Server (MS) in der Lage ist, mindestens einen Schritt eines Verfahrens nach einem der Ansprüche 1 bis 13 auszuführen.
  17. Teilnehmergerät für ein Kommunikationssystem, speziell für ein Mobilkommunikationssystem, mit einer Übertragungseinheit, um Nachrichten zu empfangen und zu senden, wobei die Nachrichten Autorisierungsanforderungen für einen Inhalt, welcher autorisiert werden soll, und Autorisierungsantworten umfassen, einer Einheit, um Eingaben eines Teilnehmers zu verarbeiten, einer Einheit, um eine Ausgabe an den Teilnehmer durchzuführen, einer Einheit, um Parameter zu signieren, und einem diese Einheiten steuernden Verarbeitungssystem (PS), welches in der Lage ist, eine Autorisierungsanforderung (6) mit einer Kennung (H) einer Transaktion zu verarbeiten, wobei die Kennung (H) aus dem Inhalt berechnet wird, und auf die Anforderung mit einer Autorisierungsantwort zu antworten, wobei das Verarbeitungssystem (PS) eine Einheit enthält, um eine Meldung für die Anforderung zu bestimmen, um die Ausgabe der Meldung durch die Ausgabeeinheit (OU) auszulösen, um auf eine Genehmigung der Anforderung durch den Teilnehmer zu warten, um das Signieren der Kennung (H) mittels einer Signierfunktion auszulösen und um das Senden einer Autorisierungsantwort (8) mit der signierten Kennung (H) durch die Übertragungseinheit (TU) auszulösen.
  18. Teilnehmergerät nach Anspruch 17, wobei das Verarbeitungssystem (PS) in der Lage ist, eine Prüfung durchzuführen, ob die Autorisierungsanforderung (6) eine Zeichenkette (T) umfasst, und die erkannte Zeichenkette (T) als Meldung zu wählen oder andernfalls eine Standardzeichenkette.
  19. Teilnehmergerät nach Anspruch 17 oder 18, wobei das Verarbeitungssystem (PS) die angezeigte Meldung in die Autorisierungsantwort einfügt.
  20. Teilnehmergerät nach einem der Ansprüche 17 bis 19, wobei das Verarbeitungssystem (PS) in der Lage ist, eine Prüfung durchzuführen, ob eine Verbindung als sicher eingestuft ist, und das Ergebnis der Prüfung in die Meldung einzufügen oder die Meldung entsprechend der Prüfung zu wählen.
  21. Teilnehmergerät nach einem der Ansprüche 17 bis 20, wobei die Autorisierungsanforderung (6) eine Signatur des Absenders umfasst und das Verarbeitungssystem (PS) eine Prüfung der Absendersignatur durchführt.
  22. Teilnehmergerät nach Anspruch 21, wobei das Verarbeitungssystem (PS) in der Lage ist, das Ergebnis der Prüfung in die Meldung einzufügen oder die Meldung entsprechend der Prüfung zu wählen.
  23. Teilnehmergerät nach einem der Ansprüche 17 bis 22, wobei das Verarbeitungssystem (PS) in der Lage ist, eine Verkettung der Kennung (H) und mindestens eines weiteren Parameters zu signieren.
  24. Teilnehmergerät nach einem der Ansprüche 17 bis 23, wobei das Verarbeitungssystem (PS) einen Parameter, welcher sich in aufeinander folgenden Autorisierungsanforderungen (6) oder Autorisierungsantworten (8) ändert, in einen signierten Inhalt einfügt.
  25. Computerprogramm zum Empfangen einer Autorisierungsanforderung (6) für einen Inhalt, welcher autorisiert werden soll, mit einer Kennung einer Transaktion und Antworten auf die Anforderung mit einer Autorisie rungsantwort, wobei das Programm Code zum Ausführen der folgenden Schritte umfasst: Empfang der Autorisierungsanforderung mit der Kennung (H), welche aus dem Inhalt berechnet wird, Bestimmen einer Meldung für die Autorisierungsanforderung (6), Auslösen der Ausgabe der Meldung, Warten auf eine Eingabe, welche die Autorisierungsanforderung genehmigt oder ablehnt, Auslösen des Signierens der Kennung (H) mittels einer Signierfunktion, Bestimmen der Autorisierungsantwort (8) entsprechend der Eingabe, wobei eine genehmigende Autorisierungsantwort (8) die signierte Kennung (H) umfasst.
  26. Computerprogramm nach Anspruch 25, wobei das Programm mindestens einen Schritt eines Verfahrens nach einem der Ansprüche 2 bis 9 ausführt.
DE60129951T 2000-05-08 2001-04-19 Verfahren zur transaktionensermächtigung Expired - Fee Related DE60129951T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP00109713A EP1154609A1 (de) 2000-05-08 2000-05-08 Verfahren für Transaktionsermächtigung
EP00109713 2000-05-08
PCT/EP2001/004422 WO2001086909A1 (en) 2000-05-08 2001-04-19 Method for the authorization of transactions

Publications (2)

Publication Number Publication Date
DE60129951D1 DE60129951D1 (de) 2007-09-27
DE60129951T2 true DE60129951T2 (de) 2008-05-08

Family

ID=8168647

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60129951T Expired - Fee Related DE60129951T2 (de) 2000-05-08 2001-04-19 Verfahren zur transaktionensermächtigung

Country Status (6)

Country Link
US (1) US20020032661A1 (de)
EP (2) EP1154609A1 (de)
AT (1) ATE370594T1 (de)
AU (1) AU2001262209A1 (de)
DE (1) DE60129951T2 (de)
WO (1) WO2001086909A1 (de)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020103801A1 (en) * 2001-01-31 2002-08-01 Lyons Martha L. Centralized clearinghouse for community identity information
EP1241857A1 (de) * 2001-03-15 2002-09-18 Nokia Corporation Verfahren zum Zugreifen auf Datei gespeichtern in einem Mobielendgerät mit Internet Protokol Unterstützung
US7729776B2 (en) * 2001-12-19 2010-06-01 Cardiac Pacemakers, Inc. Implantable medical device with two or more telemetry systems
US6985773B2 (en) 2002-02-07 2006-01-10 Cardiac Pacemakers, Inc. Methods and apparatuses for implantable medical device telemetry power management
US8364747B2 (en) * 2002-12-17 2013-01-29 International Business Machines Corporation Client/server request handling
US7155290B2 (en) * 2003-06-23 2006-12-26 Cardiac Pacemakers, Inc. Secure long-range telemetry for implantable medical device
US7761374B2 (en) 2003-08-18 2010-07-20 Visa International Service Association Method and system for generating a dynamic verification value
US7740168B2 (en) 2003-08-18 2010-06-22 Visa U.S.A. Inc. Method and system for generating a dynamic verification value
US7228182B2 (en) * 2004-03-15 2007-06-05 Cardiac Pacemakers, Inc. Cryptographic authentication for telemetry with an implantable medical device
WO2005099817A1 (en) 2004-04-07 2005-10-27 Cardiac Pacemakers, Inc. Rf wake-up of implantable medical device
US7890180B2 (en) * 2004-08-09 2011-02-15 Cardiac Pacemakers, Inc. Secure remote access for an implantable medical device
US7828204B2 (en) * 2006-02-01 2010-11-09 Mastercard International Incorporated Techniques for authorization of usage of a payment device
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US8014756B1 (en) * 2007-02-28 2011-09-06 Intuit Inc. Mobile authorization service
US9185123B2 (en) 2008-02-12 2015-11-10 Finsphere Corporation System and method for mobile identity protection for online user authentication
US20110208601A1 (en) * 2010-02-19 2011-08-25 Finshpere Corporation System and method for financial transaction authentication using travel information
US20080263644A1 (en) * 2007-04-23 2008-10-23 Doron Grinstein Federated authorization for distributed computing
US20090103730A1 (en) * 2007-10-19 2009-04-23 Mastercard International Incorporated Apparatus and method for using a device conforming to a payment standard for access control and/or secure data storage
US9098851B2 (en) * 2008-02-14 2015-08-04 Mastercard International Incorporated Method and apparatus for simplifying the handling of complex payment transactions
US8341084B2 (en) 2009-06-08 2012-12-25 Mastercard International Incorporated Method, apparatus, and computer program product for topping up prepaid payment cards for offline use
US20100115276A1 (en) * 2008-10-31 2010-05-06 Apple Inc. System and method for derivating deterministic binary values
EP2336985A1 (de) * 2009-12-03 2011-06-22 Nxp B.V. Verbessertes Authentifizierungssystem
US20160277412A1 (en) * 2010-11-17 2016-09-22 Invysta Technology Group Methodology for identifying local/mobile client computing devices using a network based database containing records of hashed distinctive hardware, software, and user provided biometric makers for authorization of electronic transactions and right of entry to secure locations
US10692081B2 (en) 2010-12-31 2020-06-23 Mastercard International Incorporated Local management of payment transactions
US9280792B2 (en) * 2012-10-12 2016-03-08 Empire Technology Development Llc Notarization based on currency transactions
US8955075B2 (en) * 2012-12-23 2015-02-10 Mcafee Inc Hardware-based device authentication
KR101321721B1 (ko) * 2013-03-20 2013-10-28 주식회사 시큐브 적법한 인증 메시지 확인 시스템 및 방법
US11641513B2 (en) * 2017-08-18 2023-05-02 Roku, Inc. Message processing using a client-side control group
US20190197539A1 (en) * 2017-12-27 2019-06-27 Hyundai Card Co., Ltd. Method of providing service for setting condition of card use, card company server and user terminal

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5878141A (en) * 1995-08-25 1999-03-02 Microsoft Corporation Computerized purchasing system and method for mediating purchase transactions over an interactive network
FR2740291B1 (fr) * 1995-10-20 1997-12-12 Sagem Radiotelephone a double fonction, notamment de transaction financiere et procede d'etablissement d'une communication entre le radiotelephone et le reseau radiotelephonique
US5671279A (en) * 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system
US6742125B1 (en) * 1996-11-13 2004-05-25 Lucent Technologies Inc. Distributed protocol for secure communication of commercial transactions and decentralized network employing the protocol
US6317729B1 (en) * 1997-04-08 2001-11-13 Linda J. Camp Method for certifying delivery of secure electronic transactions
US5903878A (en) * 1997-08-20 1999-05-11 Talati; Kirit K. Method and apparatus for electronic commerce
US6047268A (en) * 1997-11-04 2000-04-04 A.T.&T. Corporation Method and apparatus for billing for transactions conducted over the internet
US6850916B1 (en) * 1998-04-27 2005-02-01 Esignx Corporation Portable electronic charge and authorization devices and methods therefor

Also Published As

Publication number Publication date
EP1281265A1 (de) 2003-02-05
ATE370594T1 (de) 2007-09-15
AU2001262209A1 (en) 2001-11-20
EP1154609A1 (de) 2001-11-14
DE60129951D1 (de) 2007-09-27
US20020032661A1 (en) 2002-03-14
EP1281265B1 (de) 2007-08-15
WO2001086909A1 (en) 2001-11-15

Similar Documents

Publication Publication Date Title
DE60129951T2 (de) Verfahren zur transaktionensermächtigung
DE60318470T2 (de) Verfahren zum gewähren von zugriff auf eine einrichtung aufgrund einer verknüpfung eines ersten charakteristikums einer ersten vorrichtung und eines zweiten charakteristikums einer zweiten vorrichtung
DE60131534T2 (de) Umfassender Authentifizierungsmechanismus
DE60007883T2 (de) Verfahren und vorrichtung zum durchführen von elektronischen transaktionen
DE60314871T2 (de) Verfahren zur authentifizierung eines anwenders bei einem zugang zu einem dienst eines diensteanbieters
DE60106569T2 (de) vERFAHREN ZUR DURCHFÜHRUNG EINER ONLINE FINANZTRANSAKTION DURCH EINEN BENUTZER
EP1264490B1 (de) Verfahren zum festellen der authentizität der identität eines dienste-nutzers und vorrichtung zum durchführen des verfahrens
EP2735129B1 (de) Verfahren zum absichern einer transaktion
WO2011131715A1 (de) Verfahren zum lesen eines attributs aus einem id-token
EP2174281A2 (de) Virtuelle prepaid- oder kreditkarte und verfahren und system zur bereitstellung einer solchen und zum elektronischen zahlungsverkehr
DE102008035391A1 (de) Verfahren zur Authentifizierung
EP2417550A1 (de) Verfahren zur durchführung einer applikation mit hilfe eines tragbaren datenträgers
DE60209809T2 (de) Verfahren zur digitalen unterschrift
DE10296626T5 (de) Verfahren zur unleugbaren Verwendung kryptographischer Signaturen in kleinen Einrichtungen
DE60024697T2 (de) Vorrichtung und Verfahren für anonymen Zugang zum Internet
EP3005651A2 (de) Verfahren zur adressierung, authentifizierung und sicheren datenspeicherung in rechnersystemen
EP2879073B1 (de) Elektronisches transaktionsverfahren und computersystem
EP2783320A1 (de) Verfahren zum authentisieren einer person an einer serverinstanz
EP3244362B1 (de) Verfahren zur durchführung von transaktionen
EP4053771A1 (de) Ableitung eines tokens mittels eines transaktions-bezogenen einmalschlüssels
AT411947B (de) System für die sichere durchführung von transaktionen zwischen informationsverarbeitenden anlagen
EP1183847B1 (de) Verfahren zur gesicherten übermittlung von geschützten daten
EP1047028A1 (de) Kommunikationssytem und Verfahren zur effizienten Durchführung von elektronischen Transaktionen in mobilen Kommunikationsnetzen
EP1274971A2 (de) Verfahren zur sicheren bezahlung von lieferungen und leistungen in offenen netzwerken
DE102005044953A1 (de) Tragbare Verschlüsselungsvorrichtung für Finanz-Transferaktionen und Verfahren unter deren Verwendung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee