DE102014212895A1 - Verfahren zur performanten, feingranularen und nachweisbaren Autorisierung - Google Patents

Verfahren zur performanten, feingranularen und nachweisbaren Autorisierung Download PDF

Info

Publication number
DE102014212895A1
DE102014212895A1 DE102014212895.1A DE102014212895A DE102014212895A1 DE 102014212895 A1 DE102014212895 A1 DE 102014212895A1 DE 102014212895 A DE102014212895 A DE 102014212895A DE 102014212895 A1 DE102014212895 A1 DE 102014212895A1
Authority
DE
Germany
Prior art keywords
hash
value
service provider
user
service
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.)
Withdrawn
Application number
DE102014212895.1A
Other languages
English (en)
Inventor
Jens-Uwe Busser
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.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE102014212895.1A priority Critical patent/DE102014212895A1/de
Priority to PCT/EP2015/060344 priority patent/WO2016000861A1/de
Publication of DE102014212895A1 publication Critical patent/DE102014212895A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—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 cryptographic hash functions
    • 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/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G06Q20/145—Payments according to the detected use or quantity
    • 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/22—Payment schemes or models
    • G06Q20/29—Payment schemes or models characterised by micropayments
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F15/00—Coin-freed apparatus with meter-controlled dispensing of liquid, gas or electricity
    • G07F15/12—Coin-freed apparatus with meter-controlled dispensing of liquid, gas or electricity in which metering is on a time basis
    • 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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/20—Information technology specific aspects, e.g. CAD, simulation, modelling, system security

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Beschrieben wird ein Verfahren zur Autorisierung für die Nutzung eines volumenabhängigen Dienstes, mit folgenden Verfahrensschritten: – Erzeugung (11) einer Zufallszahl (H0), welche anfänglich nur einem Anwender (1) bekannt ist, – N-maliges Hashen, ausgehend von der Zufallszahl (H0), so dass folgende Hashkette gilt: H1 = Hash(H0); H2 = Hash(H1); ...; HN = Hash(HN-1), und – Anmeldung eines Anwenders (1) mittels einer digital signierten Struktur S, welche den letzten Wert der Hashkette HN im Klartext enthält, bei einem Dienstleister (2), – Bestätigung (14, 15, 16, 17) jeder erhaltenen k-ten Teilleistung oder Autorisieren jeder angefragten k-ten Teilleistung mittels Senden des (N – k)-ten Wertes HN-k der Hashkette vom Anwender (1) an den Dienstleister (2) nach respektive vor der Erbringung dieser Teilleistung, – Prüfung (22, 24, 26, 28) der Gültigkeit des erhaltenen Wertes HN-k durch den Dienstleister (2) als neuer Teil der Hashkette HN-k bis HN mittels Hashen des erhaltenen Wertes und Vergleich der Übereinstimmung des Hashwertes mit dem zuvor erhaltenen Wert HN-(k-1) beziehungsweise mit HN aus Struktur S im Falle des ersten erhaltenen Wertes, – Bereitstellung der nächsten Teilleistung respektive Freigabe der angefragten Teilleistung durch den Dienstleister (2) bei Korrektheit des erhaltenen Wertes, ansonsten Abbruch des Verfahrens. Anwendung: Zugangskontrolle, Vorauszahlungsverfahren, Dienstleistungsabrechnungen.

Description

  • Die Erfindung betrifft die Abrechnung volumenabhängiger Dienste, bei denen ein Dienst oder eine Ware bezogen wird und die Abrechnung elektronisch erfolgt.
  • Die Nutzung vieler volumenabhängiger Dienste wird mittlerweile bereits rein elektronisch abgerechnet. Beispielsweise wird im Telekommunikationsbereich, bei Internetangeboten, usw. Auch für zukünftige Dienste wie das Laden vollelektrischer Fahrzeuge "eCar", Elektroauto, oder das Nutzen von "Cloud"-Anwendungen, wie Speicherung von Daten oder Benutzung von Anwendungen im Internet, werden sich solche Lösungen erwartungsgemäß durchsetzen.
  • "Cloud-Computing" umschreibt beispielsweise den Ansatz, abstrahierte IT-Infrastrukturen über ein Netzwerk zur Verfügung zu stellen. Die Spannweite der im Rahmen von "Cloud-Computing" angebotenen Dienstleistungen umfasst das gesamte Spektrum der Informationstechnik und beinhaltet unter anderem Infrastruktur, Plattformen und Software.
  • Der Kunde bezahlt dabei mit einer elektronischen ersten Unterschrift, einer ersten digitalen Signatur. Diese kann er bei der Anmeldung erstellen, um seine Identität und seine Berechtigung zur Nutzung des Dienstes nachzuweisen. Allerdings steht dann meist noch nicht fest, in welchem Umfang er den Dienst in Anspruch nehmen wird, d.h. wie lange er telefonieren wird, welche Menge an elektrischer Energie das "eCar" aufnehmen wird oder wie viele Operationen er von "Cloud"-Anwendungen durchführen lassen will, usw. Daher ist es notwendig, aus Gründen der Nachweisbarkeit nach Beendigung der Nutzung eines Dienstes vom Kunden noch eine zweite digitale Signatur zu verlangen, mit der er die Nutzung des Dienstes und vor allem den Umfang dieser Nutzung bestätigt.
  • Bricht beispielsweise die Verbindung ab, so kann eine zweite Signatur nicht mehr erzeugt werden. Der Dienstanbieter hat dann keine nachweisbare Bestätigung für die Dienstnutzung und ein beanspruchtes Dienstvolumen. Daher könnte es für einen Kunden vorteilhaft sein, die Verbindung insbesondere kurz vor der Beendigung der Dienstnutzung zu unterbrechen und den Umfang der Nutzung zu bestreiten.
  • Bisher protokolliert beispielsweise im Telekommunikationsbereich lediglich der Anbieter die Nutzung seiner Dienste durch einen Kunde und sendet eine monatliche Rechnung. Diese auf entsprechenden Abrechnungsservern gespeicherten Daten des Anbieters wurden bisher im Streitfall von deutschen Gerichten in der Regel anerkannt. Bestritt der Kunde die Richtigkeit der in Rechnung gestellten Leistungen, so musste er den expliziten Nachweis für die Fehlerhaftigkeit erbringen.
  • Beim Tanken auf Kreditkarte oder Girokarte behält der Tankautomat die Karte ein, bis der Tankvorgang durchgeführt ist und bucht anschließend den festgestellten Betrag ab. Oder es wird bereits vor Beginn des Tankvorgangs ein bestimmter Betrag auf einem Kreditkartenkonto reserviert. Bis zu diesem Betrag kann dann getankt werden. Der Tankautomat bucht einen geringeren Betrag ab, wenn weniger getankt wurde.
  • Der Erfindung liegt die die Aufgabe zugrunde, ein Verfahren zur sicheren und performanten Abrechnung bei einem volumenabhängigen Dienst zu beschreiben.
  • Die Lösung dieser Aufgabe geschieht durch die Merkmalskombination eines unabhängig formulierten Anspruches. Vorteilhafte Ausgestaltungen können den Unteransprüchen entnommen werden.
  • Eine triviale Lösung wäre die Erstellung jeweils einer neuen Signatur basierend auf asymmetrischer Kryptographie, wie beispielsweise RSA oder elliptische Kurven, durch den Kunden direkt vor oder nach Erbringung einer bestimmten Teilleistung, z.B. für jede Gesprächseinheit beim Telefonieren oder für jede geladene Kilowattstunde kWh beim eCar. Dies erfordert jedoch sehr viel Rechenaufwand.
  • Es wird zur leistungsstarken, gut auflösenden und sicher ausführbaren Autorisierung bei der Nutzung volumenabhängiger Dienste eine Eingabemenge zur Abrechnung eines Dienstes oder einer Ware in N annähernd gleiche Teilmengen aufgeteilt, im Folgenden Teilleistungen genannt, und die Teilleistungen werden dem Dienstleister durch Zusenden eines neuen Wertes einer Hashkette bestätigt. Der Dienstleister kann die erhaltenen Hashwerte als Nachweis dafür verwenden, dass er die Teilleistungen gegenüber dem Anwender erbracht hat.
  • Eine Hashfunktion, auch Streuwertfunktion genannt, ist eine Abbildung, die eine beliebig große Eingabemenge auf eine kleinere Zielmenge, die Hashwerte, abbildet. Dabei kann die Eingabemenge auch Elemente mit unterschiedlichen Längen enthalten. Die Elemente der Zielmenge haben dagegen eine gleichbleibende Länge.
  • Für das hier vorgeschlagene Verfahren sind sichere kryptographische Hashverfahren, das heißt zumindest schwach kollisionsresistente Einwegfunktionen mit ausreichend großer Zielmenge, zu verwenden. Empfehlungen für kryptographisch sichere Hashfunktionen geben beispielsweise das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) und das US-amerikanische National Institute of Standards and Technology (NIST): Derzeit als sicher angesehene Hash-Verfahren sind beispielsweise SHA-256, SHA-512 und Whirlpool; die Hash-Verfahren MD-4, MD-5, SHA-0 oder auch SHA-1 gelten dagegen nicht mehr als sicher.
  • Es wird ein Verfahren mit folgenden Schritten vorgeschlagen:
    Die Hashwerte werden vorab vom Anwender berechnet, als eine durchgehende Kette, ausgehend von einem zufällig gewählten Wert H0, welcher nur dem Anwender bekannt ist; diese Zufallszahl kann mit üblichen kryptographischen Verfahren für Zufallszahlen oder Pseudozufallszahlen erzeugt werden und sollte mindestens die gleiche Länge wie das Hash-Verfahren haben. Jeder Hashwert Hi der Hashkette ist dabei der Hash des vorhergehenden Wertes Hi-1, also H1 = Hash(H0), H2 = Hash(H1), ..., Hi = Hash(Hi-1), ..., HN = Hash(HN-1).
  • Die Zufallszahl H0 sowie die Hashwerte H1 bis HN-1, d.h. alle außer HN, werden vorerst geheim gehalten. Der letzte Hashwert HN ist als Klartext zusammen mit anderen Daten in einer mit asymmetrischer Kryptographie signierten Struktur S enthalten, die auch als Anfrage des Anwenders beim Dienstleister verwendet werden kann.
  • Die signierte Struktur S enthält dabei vorzugsweise die folgenden Daten:
    • – Eindeutige Bezeichnung des Anwenders / Kunden
    • – Eindeutige Bezeichnung des Dienstleisters
    • – Eventuell eindeutige Bezeichnung eines bestimmten Gerätes des Dienstleisters
    • – Eventuell eindeutige Bezeichnung eines Abrechnungsunternehmens
    • – Gültigkeitszeitraum
    • – Ankerwert der Hashkette in Form des letzten Hashwerts HN im Klartext
    • – Maximalzahl N der möglichen Dienstleistungs- oder Abrechnungseinheiten, Teilmengen, Teilleistungen, durchzuführenden Operationen, etc.
    • – Dienstleistung oder Abrechnungsbetrag pro Einheit, wie Teilmenge bzw. pro Hashwert.
  • Der Dienstleister beginnt nun mit der Erbringung von Teilleistungen. Direkt nach der Erbringung der k-ten Teilleistung wird diese vom Anwender durch Senden des Wertes HN-k an den Dienstleister bestätigt. Für jede erhaltene Teilleistung teilt der Anwender dem Dienstleister also einen solchen Hashwert in umgekehrter Reihenfolge wie bei der Berechnung mit, also zuerst HN-1, dann HN-2, ..., zuletzt HN-k nachdem insgesamt k Teilleistungen abgerufen wurden. Werden alle N Teilleistungen abgerufen bei (k = N), so ist der zuletzt mitgeteilte Wert die Zufallszahl H0.
  • Der Dienstleister prüft bei jedem erhaltenen Wert HN-k, ob dessen Hashwert Hash(HN-k) gleich dem erhaltenen Wert für die vorherige Teillieferung (k – 1) – bzw. für den ersten Wert (k = 1) gleich HN aus Struktur S – ist: Hash(HN-k) = HN-(k-1)?
  • Falls ja, wurde die dem Dienstleister bekannte Hashkette von HN-(k-1) zu HN erfolgreich um ein weiteres Element HN-k verlängert, und die Diensterbringung wird fortgesetzt. Ansonsten meldet der Dienstleister einen Fehler, bittet um Zusendung des korrekten Wertes und/oder bricht die Diensterbringung ab.
  • Der Dienstleister speichert zumindest den zuletzt erhaltenen Wert HN-k, der zusammen mit der Struktur S für die Abrechnung benötigt wird. Die anderen Hashwerte müssen nicht explizit gespeichert werden, da sie aus dem gespeicherten Wert durch mehrfaches Hashen leicht berechnet werden können.
  • Eine zweite digitale Signatur durch den Anwender nach Beendigung der Diensterbringung ist nicht notwendig. Zur Abrechnung reicht der Dienstleister die Struktur S sowie den zuletzt erhaltenen Wert HN-k bei der Abrechnungsstelle, wie Bank, Clearingstelle, etc., ein. Diese Abrechnungsstelle verifiziert durch wiederholtes Hashen die Hashkette von HN-k bis HN, und bestimmt damit auch k als Länge der Hashkette von HN-k bis HN. Anschließend erhält der Dienstleister die vereinbarte Vergütung für k Teilleistungen gutgeschrieben. Führt maximal N-faches Hashen, ausgehend vom erhaltenen Wert HN-k, nicht auf den Wert HN in der Struktur S, so wird eine Gutschrift abgelehnt. Die Struktur S ist vorzugsweise nur eine begrenzte Zeit gültig, während der sie abgerechnet werden kann; eine bereits abgerechnete Struktur S sowie die Anzahl k der bereits abgerechneten Teilleistungen muss bis zum Ende dieses Zeitraums von der Abrechnungsstelle gespeichert werden, um eine mehrfache Abrechnung durch den Dienstleister zu verhindern.
  • Die Diensterbringung kann auch nach einer beliebigen Anzahl k1 < N Teilleistungen unterbrochen und später mit k2 weiteren Teilleistungen fortgesetzt werden (k2 ≤ N – k1), solange der Gültigkeitszeitraum der signierten Struktur S nicht abgelaufen ist. Wurden zu einer Struktur S bereits k1 Teilleistungen abgerechnet und meldet der Dienstleister der Abrechnungsstelle einen weiteren, anderen Wert H* = HN-(k2+k1), so bestimmt die Abrechnungsstelle nun wieder durch wiederholtes Hashen die Länge (k2 + k1) der neuen Hashkette. Ist diese neue Hashkette länger als die bereits abgerechnete Hashkette, so wurden vom Dienstleister (k2 – k1) neue Teilleistungen erbracht, die nun zusätzlich noch abgerechnet werden können.
  • Der Dienstleister kann den Startwert H0 sowie die zurückliegenden Hashwerte H1 bis HN-k-1 nicht berechnen, da die Hashfunktion als Einwegfunktion nicht umkehrbar ist. Daher kann er nicht mehr Teilleistungen abrechnen, als er erbracht hat.
  • Da er auch die ihm bekannten Hashwerte HN-k bis HN-1 nicht selbst berechnen konnte, kann er damit nachweisen, dass er sie vom Anwender für die Erbringung von k Teilleistungen der in der signierten Struktur S beschriebenen Leistung erhalten hat.
  • Vorteil gegenüber herkömmlichen Verfahren, bei denen nur die Beauftragung und/oder Erbringung einer Gesamtleistung mit einer Signatur basierend auf asymmetrischer Kryptographie bestätigt wird, ist die detaillierte Nachweisbarkeit von erbrachten Teilleistungen auch bei unvorhergesehenem Verbindungsabbruch. Teilleistungen könnten zwar auch mit Signaturen bestätigt werden, allerdings sind diese Verfahren im Vergleich zu einer Hashberechnung sehr rechenaufwändig (ca. 1000-fach) und erfordern daher eine deutliche höhere Rechenkapazität, oder können bei leistungsschwachen Komponenten zu unerwünschten zeitlichen Unterbrechungen in der Leistungserbringung führen.
  • Das Verfahren kann auch vorteilhaft auf einem Gerät eingesetzt werden, welches keine (Pseudo-)Zufallszahlen erstellen und / oder keine Signaturen berechnen kann: die Zufallszahl H0, die Hashkette H1 bis HN und die Signatur der Struktur S werden dann auf einem anderen, leistungsfähigeren Gerät des Anwenders berechnet und auf dem Gerät des Anwenders nur gespeichert und bei Verwendung übertragen.
  • Im Folgenden werden anhand der begleitenden, schematischen, die Erfindung nicht einschränkenden, 1 und 2 Ausführungsbeispiele beschrieben:
  • 1 zeigt ein Ablaufdiagramm einer Ausführung der Erfindung,
  • 2 zeigt ein Ablaufdiagramm bei dem der jeweilige Hashwert 14, 15, 16, 17 vor der Erbringung der Teilleistung 21, 23, 25, 27 gesendet wird.
  • Die 1 zeigt das Ablaufdiagramm einer Ausführung mit einem Anwender 1, der in einem ersten Schritt 11 zunächst eine Zufallszahl H0 erzeugt und in einem zweiten Schritt 12 die zugehörige Hashkette berechnet. Während der Anmeldung 13 erzeugt der Anwender 1 eine signierte Datenstruktur S, welche neben anderen Daten den letzten Wert der Hashkette HN enthält, und sendet diese Struktur S an den Dienstleister 2. Dieser Dienstleister 2 erbringt dann Teilleistungen 21, 23, 25, 27 seines Dienstes, die vom Anwender 1 mit entsprechenden Werten 14, 15, 16, 17 aus der Hashkette bestätigt werden. Der Dienstleister 2 prüft die erhaltenen Werte in den Schritten 22, 24, 26, 28. Zur Abrechnung 31 sendet der Dienstleister 2 die Struktur S sowie den zuletzt erhaltenen Hashwert HN-k an die Abrechnungsstelle 3.
  • 2 zeigt ein Ablaufdiagramm, bei dem der jeweilige Hashwert 14, 15, 16, 17 vor der Erbringung der Teilleistung 21, 23, 25, 27 gesendet wird, wie es beispielsweise bei Autorisierungsverfahren gut anwendbar ist.
  • Weitere Ausführungsbeispiele:
  • In einem Ausführungsbeispiel erzeugt der Anwender die Zufallszahl H0, die Hashkette H1 bis HN, sowie die mit seinem privaten Schlüssel signierte Struktur S. Die Abrechnung mittels Struktur S und Hashwert HN-k erfolgt nach der Lieferung von k Teillieferungen. Skizziert in 1.
  • In einer alternativen Ausführung ist es auch möglich, dass der Anwender zuerst jeweils einen neuen Hashwert sendet und erst anschließend die zugehörige Teilleistung erbracht wird, siehe 2. Diese Ausgestaltung ist insbesondere bei Verfahren zur Zugangskontrolle vorteilhaft.
  • Alternativ können die Zufallszahl H0, die Hashkette H1 bis HN und die Struktur S auch von einem Dritten erstellt und dem Anwender zur Verwendung zur Verfügung gestellt werden. Damit sind auch Vorauszahlungsverfahren "Prepaid", sowie die Ausstellung von Autorisierungs-Tokens möglich.
  • Aus Gründen der Performanz kann es vorteilhaft sein, nicht nach jeder Teilleistung einen neuen Wert der Hashkette zu senden, sondern nur nach einer bestimmten Anzahl von Teilleistungen oder nach einer bestimmten Zeit einen jeweils neuen Wert zu senden, der die Erbringung dieser Teilleistungen bestätigt.
  • Um zu verhindern, dass ein Anwender mit der gleichen Struktur S Dienstleistungen an verschiedenen Dienstleistungsterminals des Dienstleisters mehrfach Leistungen erbringen lässt, ist es vorteilhaft, dass die Dienstleistungsterminals miteinander verbunden sind und Informationen über bereits verwendete Strukturen S und erhaltene Werte und Hashketten austauschen.
  • Alternativ kann auch jede Struktur S eine eindeutige Bezeichnung eines Dienstleistungsterminals enthalten, welches als einziges zur Annahme dieser Struktur berechtigt ist; ein Datenabgleich mit anderen Dienstleistungsterminals ist dann nicht notwendig.
  • Die Erfindung ist vorteilhaft einsetzbar insbesondere in den folgenden Anwendungsfällen:
    • – Beim Aufladen von eCars
    • – Smart Metering und Prepaid-Abrechnung von elektrischer Energie, Wasser, Gas, ...
    • – Micro-Payment, beispielsweise für Internet-Dienste oder aufladbare Geldkarten für Automaten
    • – Autorisierung von Dienstanfragen in Cloud-Anwendungen
    • – Zutritts- und Zugangsmanagement
    • – elektronische Fahrkarten, aufladbare Bezahlkarten
    • – Sonderleistungen in Unterhaltungseinrichtungen; wie Schwimmbad, Freizeitpark usw.

Claims (13)

  1. Verfahren zur Autorisierung für die Nutzung eines volumenabhängigen Dienstes, mit folgenden Verfahrensschritten: – Erzeugung (11) einer Zufallszahl (H0), welche anfänglich nur einem Anwender (1) bekannt ist, – N-maliges Hashen, ausgehend von der Zufallszahl (H0), so dass folgende Hashkette gilt: H1 = Hash(H0); H2 = Hash(H1); ...; HN = Hash(HN-1), und – Anmeldung eines Anwenders (1) mittels einer digital signierten Struktur S, welche den letzten Wert der Hashkette HN im Klartext enthält, bei einem Dienstleister (2), – Bestätigung (14, 15, 16, 17) jeder erhaltenen k-ten Teilleistung oder Autorisieren jeder angefragten k-ten Teilleistung mittels Senden des (N – k)-ten Wertes HN-k der Hashkette vom Anwender (1) an den Dienstleister (2) nach respektive vor der Erbringung dieser Teilleistung, – Prüfung (22, 24, 26, 28) der Gültigkeit des erhaltenen Wertes HN-k durch den Dienstleister (2) als neuer Teil der Hashkette HN-k bis HN mittels Hashen des erhaltenen Wertes und Vergleich der Übereinstimmung des Hashwertes mit dem zuvor erhaltenen Wert HN-(k-1) beziehungsweise mit HN aus Struktur S im Falle des ersten erhaltenen Wertes, – Bereitstellung der nächsten Teilleistung respektive Freigabe der angefragten Teilleistung durch den Dienstleister (2) bei Korrektheit des erhaltenen Wertes, ansonsten Abbruch des Verfahrens.
  2. Verfahren nach Anspruch 1, wobei die Zufallszahl H0 sowie die Hashwerte H1 bis HN-1, ohne HN, vorerst geheim gehalten werden und der letzte Hashwert HN als Klartext zusammen mit anderen Daten in einer mit asymmetrischer Kryptographie signierten Struktur S enthalten ist,
  3. Verfahren nach einem der Ansprüche 1–2, wobei, die signierte Struktur S nur begrenzt gültig ist.
  4. Verfahren nach einem der Ansprüche 1–3, wobei, – der Anwender (1) keine Hashwerte mehr sendet, sobald ein Dienstleister (2) die Versorgung stoppt, und / oder – der Dienstleister (2) die Leistungserbringung unterbricht, wenn der Anwender (1) keine Hashwerte mehr sendet oder wenn die Hashwerte fehlerhaft sind, indem Hash(Hk) ungleich dem zuvor erhaltenen Wert Hk+1 ist, wobei der Dienstleister genau die (N – k) Teillieferungen abrechnen kann, deren korrekte Hashwerte Hk, Hk+1, ..., HN-1 er erhalten hat.
  5. Verfahren nach einem der Ansprüche 1–4, wobei der Anwender (1) durch Senden von mehreren Hashwerten oder Senden eines Hashwertes mit niedrigerem Index mehrere Teilleistungen oder eine größere Teilleistung auf einmal bestätigt oder anfordert.
  6. Verfahren nach einem der Ansprüche 1–5, wobei die Abrechnungsstelle (3) nach Erhalt einer neuen Abrechnung (31) durch den Dienstleister (2) die bereits aus früheren Abrechnungen bekannte Hashkette berücksichtigt und bei der Feststellung der abzurechnenden Dienstleistungsmenge nur die jeweilige Verlängerung der Hashkette zusätzlich gutschreibt.
  7. Verfahren nach einem der Ansprüche 1–6, wobei die Datenstruktur S eine eindeutige Kennzeichnung eines Terminals des Dienstleisters (2) enthält und nur von diesem Terminal akzeptiert wird.
  8. Verfahren nach einem der Ansprüche 1–7, wobei die Erzeugung der Zufallszahl H0, die Berechnung der Hashkette und / oder die digitale Signatur in einem ersten, leistungsfähigen Gerät durchgeführt und dann auf ein zweites, leistungsschwaches Gerät des Anwenders übertragen werden.
  9. Verfahren nach einem der Ansprüche 1–8, wobei die Zufallszahl H0, die Hashkette und die digitale Signatur durch einen Dritten erstellt und dem Anwender (1) zur Verfügung gestellt werden.
  10. Verfahren nach Anspruch 9, wobei der Dritte gleich der Dienstanbieter (2) ist.
  11. Verfahren nach einem der Ansprüche 1–10, wobei ein kryptographisch sicheres Hashverfahren eingesetzt wird, welches zumindest eine schwach kollisionsresistente Einwegfunktion darstellt, mit einer ausreichend großen Zielmenge.
  12. Verfahren nach einem der Ansprüche 1–11, wobei als Zufallszahl eine mit einem kryptographisch sicheren Verfahren berechnete Pseudozufallszahl eingesetzt wird.
  13. Verwendung eines Verfahrens entsprechend einem der Ansprüche 1 bis 12, zum Einsatz in wenigstens einem Anwendungsfall aus der folgenden Gruppe: – Verfahren zum Aufladen von ‚eCars‘, – Verfahren zum ‚Smart Metering‘ und zur ‚Prepaid-Abrechnung‘ von elektrischer Energie, Wasser, Gas etc., – Verfahren zum ‚Mikro-Payment‘, für Dienste im Internet, – Verfahren zur Autorisierung von Dienstanfragen in ‚Cloud‘-Anwendungen, – Zutritts- und Zugangsmanagement, – Verfahren zum Betrieb elektronischer Fahrkarten oder zum Betrieb aufladbarer Bezahlkarten, – Verfahren zum Abrechnen von Sonderleistungen in Unterhaltungseinrichtungen; wie Schwimmbad, Freizeitpark oder Ähnliches.
DE102014212895.1A 2014-07-03 2014-07-03 Verfahren zur performanten, feingranularen und nachweisbaren Autorisierung Withdrawn DE102014212895A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102014212895.1A DE102014212895A1 (de) 2014-07-03 2014-07-03 Verfahren zur performanten, feingranularen und nachweisbaren Autorisierung
PCT/EP2015/060344 WO2016000861A1 (de) 2014-07-03 2015-05-11 Verfahren zur performanten, feingranularen und nachweisbaren autorisierung

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102014212895.1A DE102014212895A1 (de) 2014-07-03 2014-07-03 Verfahren zur performanten, feingranularen und nachweisbaren Autorisierung

Publications (1)

Publication Number Publication Date
DE102014212895A1 true DE102014212895A1 (de) 2016-01-07

Family

ID=53268775

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102014212895.1A Withdrawn DE102014212895A1 (de) 2014-07-03 2014-07-03 Verfahren zur performanten, feingranularen und nachweisbaren Autorisierung

Country Status (2)

Country Link
DE (1) DE102014212895A1 (de)
WO (1) WO2016000861A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070279227A1 (en) * 2006-02-03 2007-12-06 Ari Juels Authentication Methods and Apparatus Utilizing Hash Chains

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998043211A1 (en) * 1997-03-26 1998-10-01 British Telecommunications Public Limited Company Transaction system
JP4307564B2 (ja) * 1997-03-26 2009-08-05 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー トランザクションシステム
DE102010040688A1 (de) * 2010-09-14 2012-03-15 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Authentisieren von Multicast-Nachrichten
DE102011081036A1 (de) * 2011-08-16 2013-02-21 Siemens Aktiengesellschaft Verfahren zum Aussenden von Nachrichten mit Integritätsschutz

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070279227A1 (en) * 2006-02-03 2007-12-06 Ari Juels Authentication Methods and Apparatus Utilizing Hash Chains

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Digitale Rechteverwaltung - Wikipedia. Mit Stand vom 20. Mai 2014URL: http://de.wikipedia.org/w/index.php?title=Digitale_Rechteverwaltung&oldid=130574465 *
Digitale Rechteverwaltung – Wikipedia. Mit Stand vom 20. Mai 2014URL: http://de.wikipedia.org/w/index.php?title=Digitale_Rechteverwaltung&oldid=130574465

Also Published As

Publication number Publication date
WO2016000861A1 (de) 2016-01-07

Similar Documents

Publication Publication Date Title
DE69830902T2 (de) Zweiweg-authentifizierung-protokoll
WO2019038137A1 (de) Indirekte transaktionsvorgänge auf basis einer blockchainarchitektur
DE102016206916A1 (de) Elektronisches Verfahren zur kryptographisch gesicherten Überweisung eines Betrags einer Kryptowährung
DE112010004426T5 (de) Nicht verknüpfbare Übertragung ohne Gedächtnis mit Preisangaben und wiederaufladbaren Geldbörsen
DE112011100182T5 (de) Transaktionsprüfung für Datensicherheitsvorrichtungen
DE102012005427A1 (de) Verfahren und System zur gesicherten Kommunikation zwischen einen RFID-Tag und einem Lesegerät
EP2904574A1 (de) Verfahren, vorrichtung und dienstleistungsmittel zur authentifizierung eines kunden für eine durch ein dienstleistungsmittel zu erbringende dienstleistung
EP2755846A1 (de) Verfahren und vorrichtung zur zuordnung eines von einer ladestation erfassten messwertes zu einer transaktion
DE102009037968A1 (de) Verfahren und Vorrichtung zur Identifizierung eines Elektrofahrzeugs gegenüber einer Abrechnungszentrale
DE102012206341A1 (de) Gemeinsame Verschlüsselung von Daten
DE102009038645A1 (de) Verfahren und tragbarer Datenträger zum Übertragen eines geldwerten Betrages in Form eines elektronischen Datensatzes zwischen einer ersten nichtzentralen Instanz und einer zweiten nichtzentralen Instanz
DE102012202731A1 (de) Computerimplementiertes Bezahlverfahren
DE10392788T5 (de) Nichtablehnung von Dienstvereinbarungen
WO2017008939A1 (de) Verfahren und vorrichtung zur authentifizierung eines dienstnutzers für eine zu erbringende dienstleistung
EP3899844A1 (de) Verfahren zum erzeugen einer blinden signatur
EP3971021A1 (de) Ladestation für elektrofahrzeuge mit einer manipulationsgeschützten bezahlvorrichtung
EP3671602B1 (de) Verfahren zum direkten austausch eines münzdatensatzes zwischen sicherheitselementen
DE102020207619A1 (de) Verfahren und Vorrichtung zur Bereitstellung einer Ressource
DE102005008610A1 (de) Verfahren zum Bezahlen in Rechnernetzen
DE102014212895A1 (de) Verfahren zur performanten, feingranularen und nachweisbaren Autorisierung
WO2023036458A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
DE102014014109A1 (de) Transaktionsverfahren
EP3899845A1 (de) Verfahren zum erhalten einer blinden signatur
WO2003012701A2 (de) Verfahren zum bezug einer über ein datennetz angebotenen leistung
EP2696319B1 (de) Verfahren zur Freigabe einer Transaktion

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0009320000

Ipc: G06F0021100000

R163 Identified publications notified
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee