DE102018121306A1 - Identitätsverifizierung unter Wahrung der Privatsphäre - Google Patents

Identitätsverifizierung unter Wahrung der Privatsphäre Download PDF

Info

Publication number
DE102018121306A1
DE102018121306A1 DE102018121306.9A DE102018121306A DE102018121306A1 DE 102018121306 A1 DE102018121306 A1 DE 102018121306A1 DE 102018121306 A DE102018121306 A DE 102018121306A DE 102018121306 A1 DE102018121306 A1 DE 102018121306A1
Authority
DE
Germany
Prior art keywords
requesting entity
plain text
entity
text message
hash value
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.)
Pending
Application number
DE102018121306.9A
Other languages
English (en)
Inventor
Stefano Schiavoni
Simon Morris
Phillips Benton
Tom Pritchard
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.)
Google LLC
Original Assignee
Google LLC
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 Google LLC filed Critical Google LLC
Publication of DE102018121306A1 publication Critical patent/DE102018121306A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/3215—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 a plurality of channels
    • 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
    • H04L9/3239—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 involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Aspekte der Technologie zum Implementieren eines Authentifizierungsprotokolls, das einem vertrauenswürdigen Anbieter ermöglicht, sich für eine anfordernde Entität zu verbürgen, wenn diese Entität die Verifizierung von einer authentifizierenden Entität sucht (Fig. 1). Dies erfolgt ohne Weitergabe vertraulicher oder anderer persönlicher Informationen der anfordernden Entität direkt an die authentifizierende Entität (Fig. 1). Stattdessen kann der vertrauenswürdige Anbieter spezifische Informationen über eine anfordernde Entität verwenden, wie z. B. Kontaktinformationen, die einen Identitätsdatensatz (404) bilden, und einen Hash des Datensatzes (408) generieren. Der Hash wird zu einer authentifizierenden Entität (410) gesendet, die ein sicheres Token an den vertrauenswürdigen Anbieter (508) zurücksendet. Das sichere Token und die Informationen des Identitätsdatensatzes werden verwendet, um eine Verifizierungs-URL (414) zu erstellen, die an die anfordernde Entität (416) gesendet wird. Die Verifizierungs-URL verlinkt, wenn sie angeklickt wird, zurück zur authentifizierenden Entität (Fig. 1), die die anfordernde Entität (512, 514) validiert. Dies ermöglicht die sofortige Identifizierung der anfordernden Entität, ohne dass die Parteien erweiterte kryptografische Operationen (516) durchführen müssen.

Description

  • HINTERGRUND
  • E-Commerce und andere webbasierte Aktivitäten beinhalten häufig eine Partei, die die Identität einer anderen Partei verifiziert. Die Verifizierung kann auf verschiedene Weise erfolgen. In einer Instanz kann eine Internet-Zertifizierungsstelle oder Zertifikatstelle ein digitales Zertifikat ausstellen, das Anmeldeinformationen enthält, die einer Person oder Firma bei Online-Transaktionen helfen. Diese Art der Herangehensweise kann jedoch erfordern, dass die verschiedenen Parteien erweiterte kryptografische Vorgänge durchführen. Sie kann außerdem die Speicherung sensibler Informationen erfordern, die über das hinaus gehen, was für die tägliche Arbeit nötig ist, oder sonst zusätzlichen Verwaltungs- oder Ressourcenaufwand beinhalten, der ineffizient oder aufwändig ist. Somit kann diese Art von Herangehensweise für bestimmte Parteien nicht durchführbar sein, ganz gleich, ob dies Einzelpersonen, Kleinunternehmen oder andere Entitäten sind.
  • KURZDARSTELLUNG
  • Die hierin beschriebenen Identitätsverifizierungstechniken sind einfach zu implementieren und bewahren trotzdem die Privatsphäre einer Partei (einer anfordernden Entität), die sich gegenüber einer anderen Partei (einer authentifizierenden Entität) identifizieren möchte. Die allgemeine Herangehensweise basiert auf den folgenden Faktoren. Erstens kann ein Vermittler (ein vertrauenswürdiger Anbieter/Trusted Provider) die anfordernde Entität (wie z. B. eine Person oder ein Unternehmen) bereits identifizieren, z. B. in Übereinstimmung mit einer bereits vorhandenen Beziehung. Zweitens kann der vertrauenswürdige Anbieter keine lesbaren Daten über die anfordernde Entität an die authentifizierende Entität weitergeben. Es kann rechtliche oder vertragliche Vereinbarungen geben, die eine solche Weitergabe von Informationen verhindern. Und drittens sollte der vertrauenswürdige Anbieter zur Unterstützung beim Verifizierungsprozess so wenig Arbeit wie möglich haben. Dies kann das Pflegen einer Tabellenkalkulation oder die Durchführung grundlegender Berechnungen beinhalten, jedoch nicht das Berechnen digitaler Signaturen oder das Speichern äußerst sensibler Informationen über die Firma.
  • Aspekte der unten beschriebenen Technologien ermöglichen es dem vertrauenswürdigen Anbieter, seine spezifischen Informationen über eine anfordernde Entität zu nutzen, um sofortige Identifizierung oder Authentifizierung dieser anfordernden Entität bei einer bestimmten authentifizierenden Entität zu ermöglichen. Der vertrauenswürdige Anbieter kann ein Business-to-Business (B2B)-Dienstleister sein, wie z. B. eine Bank oder ein Telekommunikationsunternehmen. Die spezifischen Informationen des vertrauenswürdigen Anbieters über eine bestimmte Person, einen Händler, eine Firma oder eine andere anfordernde Entität kann deren/dessen Adresse, Ansprechpartner und andere Identifizierungsdaten beinhalten, auf die er/es bei normalen Transaktionen mit dieser Firma angewiesen ist. Diese Informationen werden für die Weitergabe an eine bestimmte authentifizierende Entität auf eine bestimmte Weise gehasht. Die authentifizierende Entität generiert ein sicheres Token auf Basis der gehashten Informationen, die der vertrauenswürdige Anbieter verwendet, um einen Verifizierungslink zu erstellen. Die anfordernde Entität kann dann den Verifizierungslink verwenden, der sofortige Identifizierung der anfordernden Identität durch die authentifizierende Entität bereitstellt.
  • Gemäß Aspekten der Technologie beinhaltet ein Verfahren das Verarbeiten, durch eines oder mehrerer Prozessorgeräte, einer Nur-Text-Nachricht mithilfe einer Hash-Funktion, um einen Hash-Wert der Nur-Text-Nachricht zu generieren. Die Nur-Text-Nachricht beinhaltet Kontaktinformationen über eine anfordernde Entität. Das Verfahren beinhaltet außerdem das Senden, durch eine Kommunikationseinheit, des generierten Hash-Werts an ein zweites externes Gerät einer authentifizierenden Entität, und das Empfangen, durch die Kommunikationseinheit, eines sicheren Tokens von dem zweiten externen Gerät der authentifizierenden Entität in Reaktion auf das Senden des generierten Hash-Werts. Das Verfahren beinhaltet ferner das Erstellen, durch das eine oder die mehreren Verarbeitungsgeräte und in Reaktion auf das Empfangen des sicheren Tokens von dem zweiten externen Gerät der authentifizierenden Entität, einer Verifizierungsangabe auf Basis des sicheren Tokens und der Nur-Text-Nachricht. Das Verfahren beinhaltet außerdem das Senden, durch die Kommunikationseinheit, der Verifizierungsangabe an das erste externe Gerät der anfordernden Entität.
  • In einem Beispiel wird die Verarbeitung in Reaktion auf das Empfangen der Nur-Text-Nachricht von einem ersten externen Gerät einer anfordernden Entität durchgeführt, wobei die Nur-Text-Nachricht die Kontaktinformationen der anfordernden Entität umfasst. In einem anderen Beispiel umfasst die Nur-Text-Nachricht die Kontaktinformationen, die eine physische Adresse einer Firma oder Person beinhalten, die der anfordernden Entität zugeordnet ist. In einem weiteren Beispiel umfasst die Nur-Text-Nachricht eine Identität-Javascript Object Notification (JSON) der Kontaktinformationen.
  • In einer Alternative beinhaltet das Verfahren ferner das Hinzufügen eines Salt-Elements zur Nur-Text-Nachricht und Verarbeiten der Nur-Text-Nachricht mit dem vordefinierten Salt-Element mithilfe der Hash-Funktion. Hier umfasst das Senden der Verifizierungsangabe zu dem ersten externen Gerät der anfordernden Entität das Senden einer Verifizierungs-URL, die das sichere Token und die Informationen der Nur-Text-Nachricht enthält, an das erste externe Gerät.
  • Gemäß anderen Aspekten der Technologie wird ein Gerät bereitgestellt, das eine Kommunikationseinheit und einen oder mehrere Prozessoren umfasst. Der eine oder die mehreren Prozessoren sind konfiguriert, aus einem Speicher eine Nur-Text-Nachricht abzurufen, die Informationen einer anfordernden Entität enthält, die Nur-Text-Nachricht mithilfe einer Hash-Funktion zu verarbeiten, um einen Hash-Wert der Nur-Text-Nachricht zu generieren, und eine Verifizierungsangabe auf Basis der Nur-Text-Nachricht und eines sicheren Tokens, das von einem zweiten externen Gerät einer authentifizierenden Entität empfangen wurde, zu erstellen. Die Nur-Text-Nachricht beinhaltet Kontaktinformationen über die anfordernde Entität. Die Kommunikationseinheit ist ferner konfiguriert, die Verifizierungsangabe an ein erstes externes Gerät der anfordernden Entität in Reaktion auf das Empfangen des sicheren Tokens von dem zweiten externen Gerät der authentifizierenden Entität zu senden.
  • In einem Beispiel umfasst die Nur-Text-Nachricht die Kontaktinformationen der anfordernden Entität. In einem anderen Beispiel umfasst die Nur-Text-Nachricht die Kontaktinformationen, die eine physische Adresse einer Firma oder Person beinhalten, die der anfordernden Entität zugeordnet ist. In einem weiteren Beispiel umfasst die Nur-Text-Nachricht eine Identität-Javascript Object Notification (JSON) der Kontaktinformationen.
  • In einer Alternative sind der eine oder die mehreren Prozessoren konfiguriert, ein Salt-Element zur Nur-Text-Nachricht hinzuzufügen und die Nur-Text-Nachricht mit dem vordefinierten Salt-Element mithilfe der Hash-Funktion zu verarbeiten. Hier ist das Gerät in der Lage, die Verifizierungsangabe zu dem ersten externen Gerät der anfordernden Entität zu senden, indem es eine Verifizierungs-URL, die das sichere Token und die Informationen der Nur-Text-Nachricht enthält, an das erste externe Gerät sendet.
  • Gemäß weiteren Aspekten der Technologie wird ein Verfahren bereitgestellt. Das Verfahren beinhaltet, in Reaktion auf das Empfangen eines Hash-Werts von einem Computergerät eines vertrauenswürdigen Anbieters, das Speichern des Hash-Werts im Speicher. Der Hash-Wert entspricht den Nur-Text-Informationen, die einer anfordernden Entität zugeordnet sind. Die Nur-Text-Informationen beinhalten Kontaktinformationen über die anfordernde Entität. Das Verfahren beinhaltet außerdem das Generieren, durch eines oder mehrere Prozessorgeräte, eines sicheren Tokens, das einem Speicherort des Hash-Werts zugeordnet ist. In Reaktion auf das Empfangen einer Verifizierungsnachricht von einem ersten externen Gerät der anfordernden Entität, beinhaltet das Verfahren das Verarbeiten, durch das eine oder die mehreren Prozessorgeräte, der Verifizierungsnachricht mithilfe einer Hash-Funktion, um einen Hash-Wert zu generieren, das Abrufen des Hash-Werts, der im Speicher gespeichert ist, das Vergleichen eines generierten Hash-Werts mit dem Hash-Wert, der aus dem Speicher abgerufen wird, und das Vergleichen des generierten sicheren Tokens mit den Tokeninformationen in der Verifizierungsnachricht, um eine Identität der anfordernden Entität zu verifizieren.
  • In einem Beispiel umfasst das Generieren des sicheren Tokens, das dem Speicherort zugeordnet ist, das Generieren einer zufälligen Tokenzeichenfolge und das Aufzeichnen einer Zuordnung zwischen der zufälligen Tokenzeichenfolge und dem Speicherort. In einem anderen Beispiel ist die Länge der zufälligen Tokenzeichenfolge mindestens 16 Bit. In einem weiteren Beispiel beinhaltet das Verfahren ferner das Speichern des sicheren Tokens in einer Datenbank und das Zuordnen des sicheren Tokens zum gespeicherten Hash-Wert. In noch einem anderen Beispiel beinhaltet das Verfahren ferner das Vorausfüllen einer Anmeldevorlage mit Kontodaten der anfordernden Entität durch den einen oder die mehreren Prozessoren. Hier können die Kontodaten über einen Abfragezeichenfolgeparameter zur Identifizierung empfangen werden, der der anfordernden Entität zugeordnet ist.
  • Und gemäß anderen Aspekten der Technologie wird ein Gerät bereitgestellt, das eine Kommunikationseinheit und einen oder mehrere Prozessoren beinhaltet, die konfiguriert sind, ausgewählte Operationen durchzuführen. Insbesondere in Reaktion auf das Empfangen eines Hash-Werts von einem Computergerät eines vertrauenswürdigen Anbieters sind der eine oder die mehreren Prozessoren konfiguriert, den Hash-Wert im Speicher zu speichern. Der Hash-Wert entspricht den Nur-Text-Informationen, die einer anfordernden Entität zugeordnet sind. Die Nur-Text-Informationen beinhalten Kontaktinformationen über die anfordernde Entität. Der eine oder die mehreren Prozessoren sind außerdem konfiguriert, ein sicheres Token zu generieren, das einem Speicherort des Hash-Werts zugeordnet ist. In Reaktion auf das Empfangen einer Verifizierungsnachricht von einem ersten externen Gerät der anfordernden Entität sind der eine oder die mehreren Prozessoren konfiguriert, die Verifizierungsnachricht mithilfe einer Hash-Funktion zu verarbeiten, um einen Hash-Wert zu generieren, den Hash-Wert abzurufen, der im Speicher gespeichert ist, einen generierten Hash-Wert mit dem Hash-Wert zu vergleichen, der aus dem Speicher abgerufen wird, und das generierte sichere Token mit den Tokeninformationen in der Verifizierungsnachricht zu vergleichen, um eine Identität der anfordernden Entität zu verifizieren.
  • In einem Beispiel wird das sichere Token, das dem Speicherort zugeordnet ist, durch Generieren einer zufälligen Tokenzeichenfolge und Aufzeichnen einer Zuordnung zwischen der zufälligen Tokenzeichenfolge und dem Speicherort erstellt. In diesem Fall kann eine Länge der zufälligen Tokenzeichenfolge mindestens 16 Bit sein. In einem anderen Beispiel sind der eine oder die mehreren Prozessoren ferner konfiguriert, das sichere Token in einer Datenbank zu speichern und das sichere Token zum gespeicherten Hash-Wert zuzuordnen. In einem weiteren Beispiel sind der eine oder die mehreren Prozessoren außerdem konfiguriert, eine Anmeldevorlage mit Kontodaten der anfordernden Entität vorauszufüllen. In dieser Situation können die Kontodaten über einen Abfragezeichenfolgeparameter zur Identifizierung empfangen werden, der der anfordernden Entität zugeordnet ist.
  • Figurenliste
  • Diese Spezifikation wird von einer Reihe von Zeichnungen begleitet, die verschiedene Merkmale und Aspekte der Technologie veranschaulichen. In den Zeichnungen beziehen sich gleiche Bezugsnummern auf gleiche Elemente. Eine kurze Erörterung jeder Zeichnung wird nachfolgend bereitgestellt.
    • 1 veranschaulicht einen exemplarischen Prozess gemäß Aspekten der Offenbarung.
    • 2A ist eine exemplarische Anordnung eines vertrauenswürdigen Anbieters gemäß Aspekten der Offenbarung.
    • 2B ist eine exemplarische Anordnung einer authentifizierenden Entität gemäß Aspekten der Offenbarung.
    • 3 veranschaulicht ein exemplarisches Netzwerk gemäß Aspekten der Offenbarung.
    • 4 veranschaulicht einen exemplarischen Anfrageprozess gemäß Aspekten der Offenbarung.
    • 5 veranschaulicht einen exemplarischen Verifizierungsprozess gemäß Aspekten der Offenbarung.
  • Die folgende Beschreibung basiert auf Ausführungsformen der Ansprüche und sollte nicht so angesehen werden, dass sie die Ansprüche in Bezug auf alternative Ausführungsformen einschränkt, die hierin nicht ausdrücklich beschrieben sind.
  • AUSFÜHRLICHE BESCHREIBUNG
  • ÜBERBLICK
  • Das hierin erörterte Authentifizierungsprotokoll beinhaltet eine Interaktion zwischen einer anfordernden Entität, einem vertrauenswürdigen Anbieter und einer authentifizierenden Entität. Die anfordernde Entität ist darauf angewiesen, dass sich der vertrauenswürdige Anbieter bei der authentifizierenden Entität für die anfordernde Entität effektiv verbürgt, jedoch ohne vertrauliche oder andere persönliche Informationen der anfordernden Entität an die authentifizierende Entität direkt weiterzugeben. Diese Herangehensweise erfordert es nicht, dass eine der Entitäten erweiterte kryptografische Operationen durchführt oder sensible Informationen über das hinaus speichert, was normalerweise für die tägliche Arbeit nötig ist. Dies beschränkt Verwaltungs- oder Ressourcenaufwand auf ein Minimum, zum Beispiel über eine Tabellenkalkulation oder eine optimierte Datenbank. Dies macht es für Einzelpersonen, Kleinunternehmen und andere anfordernde Entitäten sowie vertrauenswürdige Anbieter, die als Schnittstelle zu autorisierenden Entitäten fungieren, attraktiv.
  • Ein Beispiel des authentifizierenden Protokolls ist in 1 veranschaulicht. Hier ist, wie nachstehend näher erörtert, ein Prozessablauf von einer anfordernden Entität zu einem vertrauenswürdigen Anbieter zu einer authentifizierenden Entität und anschließend zurück zu dem vertrauenswürdigen Anbieter und der anfordernden Entität dargestellt. Auf hoher Ebene ermöglicht das Protokoll einem vertrauenswürdigen Anbieter, Verifizierungscodes - bevorzugt Verifizierungs-URLs- zu generieren, ohne die persönlichen Daten der anfordernden Entität an die authentifizierende Entität weiterzugeben. Das Protokoll beinhaltet zum Beispiel, dass der vertrauenswürdige Anbieter einige Aufgaben und Interaktion mit der authentifizierenden Entität durchführt und dann in der Lage ist, die Verifizierungs-URL direkt an die anfordernde Entität zu liefern. Wenn jemand bei der anfordernden Entität die URL empfängt und darauf klickt, wird er automatisch bei der authentifizierenden Entität authentifiziert. Die authentifizierende Entität erhält somit Kenntnis des Vorhandenseins der anfordernden Entität zu dem Zeitpunkt, zu dem die anfordernde Entität den Link aktiviert, und nicht zuvor.
  • Insbesondere stellt, wie in 1 dargestellt, die anfordernde Entität dem vertrauenswürdigen Anbieter anfänglich bestimmte Informationen („Entitätsinformationen“) bereit. Dies kann bei der normalen Geschäftstätigkeit mit diesem vertrauenswürdigen Anbieter erfolgen. Eine Person oder Firma kann zum Beispiel ein Konto bei einer Bank eröffnen oder einen Dienst bei einem Telekommunikationsanbieter einrichten. Die Entitätsinformationen wären zum Beispiel Name und Adresse oder andere Kontaktinformationen über die anfordernde Entität. Die Entitätsinformationen werden vom vertrauenswürdigen Anbieter als Identitätsinformationen in einem Identitätsdatensatz gespeichert.
  • Als Beispiel können die Daten der anfordernden Entität („Entitätsinformationen“), die durch den vertrauenswürdigen Anbieter gespeichert werden, als eine Identität der anfordernden Entität bezeichnet werden. Die Identität kann typischerweise den Namen eines Ansprechpartners (z. B. Firmeninhaber) und eine physische Straßenadresse beinhalten, die der Firma oder einer anderen anfordernden Entität zugeordnet ist. Die Identitätsinformationen können vom vertrauenswürdigen Anbieter z. B. als Teil einer Tabellenkalkulation oder als Datensatz in einer Customer Relationship Management (CRM)-Datenbank gespeichert werden. Die Identitätsinformationen können als Nur-Text-Nachricht („Identitätsdatensatz“) im JavaScript Object Notation (JSON)-Format angeordnet sein.
  • Irgendwann kann die anfordernde Entität den vertrauenswürdigen Anbieter bitten, sich für diese Entität bei einer authentifizierenden Entität zu verbürgen. Dies kann zum Beispiel erfolgen, damit die anfordernde Entität auf Dienste zugreifen kann, die von der authentifizierenden Entität angeboten werden. Der vertrauenswürdige Anbieter erstellt einen sicheren Hash (Nachrichten-Hash) der Daten der anfordernden Entität (Identitätsdatensatz) bei der authentifizierenden Entität.
  • Insbesondere wird der Nachrichten-Hash durch den vertrauenswürdigen Anbieter an die authentifizierende Entität gesendet. Die authentifizierende Entität generiert ein sicheres Token, das zu dem vertrauenswürdigen Anbieter zurückgeschickt wird und als Nachrichtenbestätigung für den bereitgestellten Nachrichten-Hash fungiert. Der Nachrichten-Hash und das sichere Token werden durch die authentifizierende Entität für die spätere Verifizierung der relevanten anfordernden Entität gespeichert.
  • Sobald der vertrauenswürdige Anbieter die Bestätigung empfängt, verwendet er das sichere Token, um einen Verifizierungslink zu erstellen. Eine Verifizierungs-URL wird zum Beispiel beim vertrauenswürdigen Anbieter erstellt, damit sich die anfordernde Entität direkt bei der authentifizierenden Entität anmelden kann. Die URL wird sowohl auf Basis des sicheren Tokens, das von der anfordernden Entität empfangen wird, als auch der Identität, die durch den vertrauenswürdigen Anbieter gespeichert wird, erstellt.
  • Die Verifizierungs-URL wird dann an die anfordernde Entität gesendet. Wie in 1 dargestellt, wird, wenn die anfordernde Entität sich bei der authentifizierenden Entität anmelden oder sonst registrieren möchte, die Verifizierungs-URL angeklickt oder sonst aktiviert. Dies öffnet eine Verbindung zur Website der authentifizierenden Entität. An diesem Punkt erkennt die authentifizierende Entität, ob die Daten, die sie von der anfordernden Entität empfängt, zum selben Wert hashen, der durch den vertrauenswürdigen Anbieter bereitgestellt und durch die authentifizierende Entität im Speicher gespeichert wird. Angenommen, die Informationen sind korrekt, dann wird die anfordernde Entität umgehend bei der authentifizierenden Entität validiert.
  • EXEMPLARISCHE ANORDNUNG
  • 2A veranschaulicht eine exemplarische Konfiguration 200 eines vertrauenswürdigen Anbieters, die mit dem hierin offenbarten Authentifizierungsprotokoll eingesetzt werden kann. Wie dargestellt, beinhaltet die Konfiguration 200 ein Verarbeitungsmodul 202, das einen oder mehrere Computerprozessoren, wie z. B. eine zentrale Verarbeitungseinheit 204 und/oder Grafikprozessoren 206 sowie das Speichermodul 208 aufweist, das konfiguriert ist, Anweisungen 210 und Daten 212 zu speichern. Eine Datenbank 214 kann vom Speichermodul 208 getrennt sein oder nicht. Die Prozessoren können parallel betrieben werden oder nicht und sie können ASICs, Controller und andere Arten von Hardwareschaltungen beinhalten. Die Prozessoren sind konfiguriert, Informationen von einem Benutzer über ein Benutzeroberflächenmodul 216 zu empfangen und dem Benutzer Informationen auf einem Anzeigegerät des Anzeigemoduls 218 zu präsentieren, das eine Anzeigeschnittstelle aufweist.
  • Das Benutzeroberflächenmodul 216 kann Befehle von einem Benutzer über Benutzereingaben empfangen und diese für das Senden zu einem bestimmten Prozessor umwandeln. Die Benutzereingaben können eines oder mehrere von einem Touchscreen, einer Tastatur, einer Maus, einem Stylus, einem Mikrofon oder anderen Arten von Eingabegeräten beinhalten. Das Anzeigemodul 218 kann eine geeignete Schaltung enthalten, die das Anzeigegerät dazu bringt, dem Benutzer grafische und andere Informationen zu präsentieren. Als Beispiel können die grafischen Informationen durch den/die Grafikprozessor(en) 206 generiert werden, während die CPU 204 den gesamten Betrieb der Konfiguration 200 des vertrauenswürdigen Anbieters verwaltet.
  • Das Speichermodul 208 kann als ein oder mehrere von einem computerlesbaren Medium oder Medien, flüchtigen Speichereinheit oder -einheiten oder nicht flüchtigen Speichereinheit oder - einheiten implementiert sein. Das Speichermodul 208 kann zum Beispiel Flash-Speicher und/oder NVRAM beinhalten und kann als Festplatte oder Speicherkarte vorliegen. Alternativ kann das Speichermodul 208 auch DVD, CD-ROM, beschreibbare und schreibgeschützte Speicher beinhalten. Bei einer Implementierung ist ein Computerprogrammprodukt in einem Informationsträger physisch enthalten. Das Computerprogrammprodukt enthält Anweisungen, wie z. B. Anweisungen 210, die bei Ausführung durch einen oder mehrere Prozessoren ein oder mehrere Verfahren wie die hierin beschriebenen ausführen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium wie das Speichermodul 208. Auch wenn 2A den/die Prozessor(en), das Speichermodul und andere Elemente des Geräts 200 funktionell als innerhalb desselben Gesamtblocks veranschaulicht, können solche Komponenten innerhalb desselben physischen Gehäuses untergebracht sein oder nicht. Einige oder alle der Anweisungen können zum Beispiel auf einem Informationsträger gespeichert sein, der ein Wechselspeichermedium (z. B. optisches Laufwerk oder USB-Laufwerk) ist, und andere können innerhalb eines schreibgeschützten Computerchips gespeichert sein. Alternativ kann die Datenbank 214 Identitätsdatensätze in einer Anordnung speichern, die vom Rest der Anordnung 200 des vertrauenswürdigen Anbieters physisch getrennt ist.
  • Die Daten 212 können durch Prozessoren in Übereinstimmung mit den Anweisungen 210 abgerufen, gespeichert oder modifiziert werden. So können beispielsweise, obwohl der hierin beschriebene Gegenstand nicht durch eine beliebige bestimmte Datenstruktur beschränkt ist, die Daten in Computergeräteregistern in einer verwandten Datenbank als eine Tabelle gespeichert werden, die eine Vielzahl verschiedener Felder und Datensätze, XML-Dokumente oder unstrukturierten Dateien aufweisen. Die Daten 212 können zudem in einem beliebigen computerlesbaren Format formatiert sein.
  • Bei den Anweisungen 210 kann es sich um einen beliebigen Satz von Anweisungen zur direkten (wie z. B. Maschinencode) oder indirekten (wie Scripts) Ausführung durch den/die Prozessor(en) handeln. Die Anweisungen können beispielsweise in Form von Computergerätecode auf einem computergerätelesbaren Medium gespeichert werden. Diesbezüglich können die Begriffe „Anweisungen“ und „Programme“ hierin austauschbar verwendet werden. Die Anweisungen können in Objektcodeformat zur direkten Verarbeitung durch den/die Prozessor(en) oder in einer anderen Computergerätesprache, einschließlich Scripts oder Sammlungen von unabhängigen Quellcodemodulen, gespeichert sein, die auf Anforderung interpretiert oder vorab kompiliert werden. Funktionen, Verfahren und Routinen der Anweisungen werden nachfolgend ausführlicher erklärt.
  • Wie ebenfalls in 2A dargestellt, beinhaltet die Konfiguration 200 des vertrauenswürdigen Anbieters ein Kommunikationsmodul 220 für die Kommunikation mit anderen Geräten und Systemen, einschließlich anfordernden Entitäten und einer oder mehreren authentifizierenden Entitäten. Das Kommunikationsmodul 220 beinhaltet einen drahtlosen Sendeempfänger; alternativ kann das Modul einen drahtgebundenen Sendeempfänger oder beides beinhalten. Die Konfiguration 200 des vertrauenswürdigen Anbieters kann mit anderen Remote-Geräten über das Kommunikationsmodul 220 mithilfe verschiedener Kommunikationen und Protokolle kommunizieren, zum Beispiel Kurzstrecken-Kommunikationsprotokolle wie Nahfeldkommunikation, Bluetooth™, Bluetooth™ Low Energy (LE) oder anderen Ad-hoc-Netzwerken, dem Internet, Intranets, virtuellen privaten Netzwerken, Weitverkehrsnetzwerken, lokalen Netzwerken, privaten Netzwerken die Kommunikationsprotokolle verwenden, die für eines oder mehrere Unternehmen proprietär sind, Ethernet, WiFi und HTTP und Kombinationen der vorstehenden. Außerdem beinhaltet die Konfiguration 200 des vertrauenswürdigen Anbieters, wie dargestellt, ein Stromversorgungsmodul 222.
  • In einem Beispiel wendet der vertrauenswürdige Anbieter eine sichere Hashing-Funktion an, um die Identitätsinformationen der anfordernden Entität zu hashen. Wie zuvor erwähnt, kann der Identitätsdatensatz im JavaScript Object Notation (JSON)-Format sein. Der vertrauenswürdige Anbieter kann zum Beispiel die Identitätsdatensatz JSON in eine Zeichenfolge umwandeln, z. B. durch UTF-8-Codierung. Er kann diese dann optional Base-64 codieren. Diese Daten können dann der Hashing-Funktion bereitgestellt werden, zum Beispiel einer SHA-256 Hashing-Funktion. Das Ergebnis des Hashing-Prozesses ist ein Nachrichten-Hash. Bei dem Nachrichten-Hash handelt es sich um eine spezifische Darstellung der Daten, jedoch nicht um die Daten selbst. Zur zusätzlichen Sicherheit des vertrauenswürdigen Anbieters vor Reengineering des Hash können Zufallsdaten („Salt“) zum Identitätsdatensatz JSON hinzugefügt werden, bevor der Hashing-Prozess durchgeführt wird. Nur als Beispiel kann das Salt eines oder mehrere Byte Zufallsdaten beinhalten. Der vertrauenswürdige Anbieter kann dann den Nachrichten-Hash über eine HTTP POST-Anfrage oder andere Übertragung an die authentifizierende Entität weitergeben.
  • Eine exemplarische Konfiguration 250 der authentifizierenden Entität ist in 2B dargestellt. Diese Konfiguration ist ähnlich der Konfiguration 200 des vertrauenswürdigen Anbieters. Die Konfiguration 250 beinhaltet zum Beispiel ein Verarbeitungsmodul 252, das einen oder mehrere Computerprozessoren, wie z. B. eine zentrale Verarbeitungseinheit 254 und/oder Grafikprozessoren 256 sowie das Speichermodul 258 aufweist, das konfiguriert ist, Anweisungen 260 und Daten 262 zu speichern. Eine Datenbank 264 kann vom Speichermodul 208 getrennt sein oder nicht. Diese Datenbank ist so angeordnet, dass sie empfangene Nachrichten-Hashes und sichere Tokens, die durch die authentifizierende Entität empfangen werden, speichert.
  • Die Prozessoren können parallel betrieben werden oder nicht und sie können ASICs, Controller und andere Arten von Hardwareschaltungen beinhalten. Die Prozessoren sind konfiguriert, Informationen von einem Benutzer über ein Benutzeroberflächenmodul 266 zu empfangen und dem Benutzer Informationen auf einem Anzeigegerät des Anzeigemoduls 268 zu präsentieren, das eine Anzeigeschnittstelle aufweist. Die Prozessoren, das Speichermodul, das Benutzeroberflächenmodul und das Anzeigemodul werden auf dieselbe Weise betrieben wie zuvor für die Konfiguration 200 des vertrauenswürdigen Anbieters beschrieben. Und ähnlich der Datenbank 214 kann die Datenbank 264 Nachrichten-Hashes und sichere Tokens in einer Anordnung speichern, die vom Rest der Konfiguration 250 der authentifizierenden Entität getrennt angeordnet ist.
  • Wie ebenfalls in 2B dargestellt, beinhaltet die Konfiguration 250 der authentifizierenden Entität ein Kommunikationsmodul 270 für die Kommunikation mit anderen Geräten und Systemen, einschließlich anfordernden Entitäten und einem oder mehreren vertrauenswürdigen Anbietern. Das Kommunikationsmodul 270 kann eine äquivalente Anordnung wie die haben, die für das Kommunikationsmodul 220 beschrieben ist. Außerdem beinhaltet die Konfiguration 250 der authentifizierenden Entität, wie dargestellt, ein Stromversorgungsmodul 272.
  • Nach Empfangen des Nachrichten-Hash veranlasst die authentifizierende Entität mehrere Dinge. Erstens kann sie validieren, dass der vertrauenswürdige Anbieter selbst autorisiert ist, sich für die anfordernde Entität zu verbürgen. Falls die Validierung fehlschlägt, stoppt der Prozess und die anfordernde Entität muss einen formelleren und direkten Verifizierungsprozess bei der anfordernden Entität verwenden. Angenommen, die Validierung des vertrauenswürdigen Anbieters ist erfolgreich, dann erstellt die authentifizierende Entität das sichere Token, das als Empfang des Nachrichten-Hash dient. Das sichere Token sollte mit dem empfangenen Nachrichten-Hash nicht verbunden sein. Das sichere Token kann zum Beispiel eine zufällige Nonce (z. B. 16 Bytes oder mehr) sein. Die authentifizierende Entität speichert den Nachrichten-Hash und das sichere Token in der Datenbank 264 und sendet eine Kopie des sicheren Tokens an den vertrauenswürdigen Anbieter zurück. Somit ist zu sehen, dass der vertrauenswürdige Anbieter keine Klartext-Version des Identitätsdatensatz JSON an die authentifizierende Entität sendet und die authentifizierende Entität kann die Identitätsinformationen der anfordernden Entität nicht zurückentwickeln.
  • An diesem Punkt kann, sobald der vertrauenswürdige Anbieter über das sichere Token verfügt, der vertrauenswürdige Anbieter den Identitätsdatensatz und das sichere Token effektiv an die anfordernde Entität weitergeben. Dies kann zum Beispiel erfolgen, indem der vertrauenswürdige Anbieter eine Verifizierungs-URL für die anfordernde Entität auf Basis des Identitätsdatensatzes und des empfangenen sicheren Tokens generiert. In einem Beispiel beinhaltet die Verifizierungs-URL die in eine Zeichenfolge umgewandelte Version des Identitätsdatensatzes und das sichere Token, mit einem Zeiger zur Website der authentifizierenden Entität. Der vertrauenswürdige Anbieter kann das empfangene sichere Token in der Datenbank 214 speichern, zum Beispiel in Zuordnung zu dem verbundenen Identitätsdatensatz oder getrennt. Alternativ kann der vertrauenswürdige Anbieter das empfangene sichere Token nicht speichern, sobald die Verifizierungs-URL generiert wurde.
  • Nach Generierung wird die Verifizierungs-URL direkt vom vertrauenswürdigen Anbieter an die anfordernde Entität gesendet. Dies ermöglicht wiederum der Person oder dem Benutzer bei der anfordernden Entität, auf den Link zu klicken oder sonst die Verifizierung zu initiieren. Wenn die Verifizierungs-URL aktiviert ist, wird der Webbrowser der anfordernden Entität zur Website der authentifizierenden Entität geleitet, wo der Benutzer der anfordernden Entität sich selbst oder seine Firma durch die authentifizierende Entität automatisch verifizieren lassen kann.
  • Insbesondere validiert die authentifizierende Entität die Informationen, die über die Verifizierungs-URL empfangen werden, in Übereinstimmung mit dem Nachrichten-Hash, der vorher durch die authentifizierende Entität vom vertrauenswürdigen Anbieter empfangen wurde. Wenn die anfordernde Entität auf den Verifizierungs-URL-Link klickt, validiert die authentifizierende Entität die in eine Zeichenfolge umgewandelte Version der Identitätsinformationen und das sichere Token. Für das Letztere wird das sichere Token, das von der authentifizierenden Entität im Speicher gespeichert ist, mit dem empfangenen sicheren Token verglichen, um eine Übereinstimmung zu bestätigen. Für die Identitätsinformationen führt das System der authentifizierenden Entität einen Hash-Prozess durch und vergleicht das Ergebnis mit dem Nachrichten-Hash, der vorher von dem vertrauenswürdigen Anbieter empfangen wurde.
  • Die authentifizierende Entität kann einen Anmeldebildschirm mit den Firmendaten der Person vorausfüllen. Dies ist möglich, da die Daten in Nur-Text in einem Abfragezeichenfolgeparameter zur Identifizierung codiert sind, der den Daten der anfordernden Entität zugeordnet ist, in Übereinstimmung mit dem Nachrichten-Hash, der vorher von dem vertrauenswürdigen Anbieter empfangen wurde.
  • Die authentifizierende Entität kann außerdem verifizieren, dass die Identitätsinformationen etwas entsprechen, für das der vertrauenswürdige Anbieter das Recht hat, es bereitzustellen. Es kann zum Beispiel geografische oder andere Einschränkungen dazu geben, was der vertrauenswürdige Anbieter zertifizieren kann.
  • Sobald die Verifizierungen erfüllt sind, ermittelt die authentifizierende Entität, dass die Verifizierungs-URL legitim ist und von einem vertrauenswürdigen Anbieter generiert wurde, der von der authentifizierenden Entität autorisiert ist. Falls dies zutrifft, können die Daten der anfordernden Entität umgehend verifiziert werden. Somit ermöglicht es das System vertrauenswürdigen Anbietern, sich für die Identitäten ihrer Benutzer gegenüber einer authentifizierenden Entität zu verbürgen, und es ermöglicht eine sofortige Verifizierung der Benutzer durch die authentifizierende Entität, ohne dass sensible Informationen über diese oder ihre Firma ausgetauscht werden müssen.
  • 3 veranschaulicht eine exemplarische Anordnung, in der verschiedene Geräte 300 der anfordernden Entität, z. B. 3001 , 3002 , 3003 und 3004 , Inhalt oder andere Informationen von einem vertrauenswürdigen Anbieter 320 und einer authentifizierenden Entität 340 über das Kommunikationssystem 310 anfordern können. Die Geräte 300 der anfordernden Entität können einige oder alle der Komponenten beinhalten, die oben in Bezug auf die Konfiguration 200 des vertrauenswürdigen Anbieters und die Konfiguration 250 der authentifizierenden Entität erörtert wurden. Die Geräte der anfordernden Entität können Laptops (3001 ), Tablets (3002 ), Mobiltelefone oder PDAs (3003 ) oder Desktop-PCs (3004 ) beinhalten. Jedoch können andere Geräte der anfordernden Entität ebenfalls durch die anfordernde Entität, wie z. B. einer Einzelperson, einem Kleinunternehmen oder einen Konzern, eingesetzt werden. Alle solchen Geräte der anfordernden Entität können Informationen an einen vertrauenswürdigen Anbieter senden, Verifizierungs-URLs empfangen und Verifizierung von einer authentifizierenden Entität anfordern, wie in 1 dargestellt.
  • Wie dargestellt, kann sich der vertrauenswürdige Anbieter 320 über den Link 324 mit der Datenbank 322 verbinden. Der vertrauenswürdige Anbieter 320 und die Datenbank 322 entsprechen der Konfiguration 200 des vertrauenswürdigen Anbieters, wie oben in Bezug auf 2A beschrieben. Ähnlich kann sich die authentifizierende Entität über den Link 344 mit der Datenbank 342 verbinden. Die authentifizierende Entität 340 und die Datenbank 342 entsprechen, wie oben in Bezug auf 2B beschrieben, der Konfiguration 250 der authentifizierenden Entität. Auch wenn in 3 nur ein vertrauenswürdiger Anbieter 320 und nur eine authentifizierende Entität 340 dargestellt sind, können jedwede Anzahl von vertrauenswürdigen Anbietern und autorisierenden Entitäten enthalten sein.
  • EXEMPLARISCHE VERFAHREN
  • Ein exemplarisches Szenario des Betriebs des vertrauenswürdigen Anbieters ist in Verbindung mit Ablaufdiagramm 400 von 4 dargestellt. Hier beinhaltet der Prozess in Block 402 Authentifizierungsinformationen von der anfordernden Entität, zum Beispiel Name und Adresse oder andere Kontaktinformationen. Dies kann auf Basis der bereits vorhandenen Interaktion des vertrauenswürdigen Anbieters mit der anfordernden Entität erfolgen, zum Beispiel durch Bestätigen eines Kontaktnamens und einer Postadresse, an die Mitteilungen an die anfordernde Entität gesendet werden. Diese Informationen werden als ein Identitätsdatensatz in Block 404 gespeichert. Dies kann in einem JSON-Format oder einem anderen Format sein, je nach Konfiguration der Datenbank des vertrauenswürdigen Anbieters. Diese Vorgänge können zu einem Zeitpunkt erfolgen, wenn die anfordernde Entität ein Konto eröffnet oder sich sonst an den Diensten des vertrauenswürdigen Anbieters beteiligt.
  • Der vertrauenswürdige Anbieter kann eine Anfrage von der anfordernden Entität bei Block 406 empfangen. Dies beinhaltet eine Anfrage, dass der vertrauenswürdige Anbieter sich für die anfordernde Entität bei einer bestimmten authentifizierenden Entität verbürgt. Oder, alternativ, kann der vertrauenswürdige Anbieter prospektiv handeln. Auf Basis entweder einer Anfrage oder einer prospektiven Aktion generiert der vertrauenswürdige Anbieter einen Nachrichten-Hash des Identitätsdatensatzes bei Block 408. Herangehensweisen für die Durchführung durch den Prozessor des vertrauenswürdigen Anbieters werden weiter oben erörtert. Der Nachrichten-Hash wird zu der bestimmten authentifizierenden Entität bei Block 410 übertragen. Anschließend empfängt der vertrauenswürdige Anbieter in Reaktion ein sicheres Token bei Block 412. Das sichere Token, wie z. B. eine Nonce oder andere Informationen, stellt eine Bestätigung dar, dass die authentifizierende Entität den Nachrichten-Hash empfangen hat.
  • Sobald das sichere Token empfangen wird, erstellen der/die Prozessor(en) des vertrauenswürdigen Anbieters die Verifizierungs-URL mithilfe des sicheren Tokens und des gespeicherten Identitätsdatensatzes bei Block 414. Diese Informationen werden dann bei Block 416 an die anfordernde Entität übertragen. An diesem Punkt hat der vertrauenswürdige Anbieter seinen Teil des Verifizierungsprozesses abgeschlossen.
  • 5 veranschaulicht einen exemplarischen Prozess 500 für den Betrieb der authentifizierenden Entität. Bei Block 502 empfängt die authentifizierende Entität einen Nachrichten-Hash von einem vertrauenswürdigen Anbieter. Darauf basierend wird bei Block 504 ein sicheres Token von einem oder mehreren Prozessoren der authentifizierenden Entität generiert. Wie zuvor angegeben, kann das sichere Token eine zufällige Nonce sein. Anschließend werden bei Block 506 der empfangene Nachrichten-Hash und das generierte sichere Token im Speicher gespeichert, zum Beispiel in der Datenbank 264 von 2B (oder der gleichwertigen Datenbank 342 von 3). Das sichere Token wird in Block 508 zu dem vertrauenswürdigen Anbieter übertragen. Anschließend empfängt, wenn die anfordernde Entität die Verifizierungs-URL aktiviert (z. B. durch Anklicken), die authentifizierende Entität diese Informationen von der anfordernden Entität bei Block 510. An diesem Punkt führen die Prozessoren der anfordernden Entität eine Verifizierungsoperation bei Block 512 durch. Dies beinhaltet das Vergleichen der Informationen von der empfangenen Verifizierungs-URL mit dem gespeicherten Nachrichten-Hash sowie das Bestätigen, dass die Informationen des empfangenen sicheren Tokens von der Verifizierungs-URL mit dem sicheren Token übereinstimmen, das in der Datenbank der authentifizierenden Entität gespeichert ist. Block 514 untersucht, ob die Verifizierung erfolgreich ist. Falls dies zutrifft, wird bei Block 516 der anfordernden Entität Zugriff durch die authentifizierende Entität gewährt. Je nach Art der authentifizierenden Entität und Art der anfordernden Entität kann dies der anfordernden Entität ermöglichen, bestimmte Operationen durchzuführen, oder es ihr ermöglichen, ausgewählte Waren oder Dienste bereitzustellen. Wenn der Verifizierungsprozess fehlschlägt, wird der anfordernden Entität der Zugriff bei Block 518 verweigert.
  • Die in den Figuren dargestellte(n) und hierin beschriebene(n) Logik und Prozessabläufe sind nicht auf eine bestimmte Reihenfolge oder Sequenz beschränkt, es sei denn, dies ist ausdrücklich angegeben. Darüber hinaus können andere Schritte vorgesehen oder Schritte aus den beschriebenen Abläufen eliminiert werden und andere Komponenten zu den beschriebenen Systemen hinzugefügt oder aus denselben entfernt werden.
  • Obwohl Aspekte der hierin enthaltenen Technologie unter Bezugnahme auf bestimmte Ausführungsformen beschrieben wurden, versteht sich, dass diese Ausführungsformen lediglich die Grundsätze und Anwendungen der vorliegenden Technologie veranschaulichen. Es versteht sich daher, dass zahlreiche Modifizierungen an den veranschaulichenden Ausführungsformen vorgenommen werden können, und dass andere Anordnungen konzipiert werden können, ohne vom durch die beigefügten Patentansprüche definierten Sinn und Umfang der vorliegenden Technologie abzuweichen.

Claims (22)

  1. Verfahren, umfassend: Verarbeiten, durch eines oder mehrere Prozessorgeräte, einer Nur-Text-Nachricht mithilfe einer Hash-Funktion, um einen Hash-Wert der Nur-Text-Nachricht zu generieren, wobei die Nur-Text-Nachricht Kontaktinformationen über eine anfordernde Entität beinhaltet; Senden, durch eine Kommunikationseinheit, des generierten Hash-Werts an ein zweites externes Gerät einer authentifizierenden Entität; Empfangen, durch die Kommunikationseinheit, eines sicheren Tokens von dem zweiten externen Gerät der authentifizierenden Entität in Reaktion auf das Senden des generierten Hash-Werts; in Reaktion auf das Empfangen des sicheren Tokens von dem zweiten externen Gerät der authentifizierenden Entität, Erstellen, durch das eine oder die mehreren Verarbeitungsgeräte, einer Verifizierungsangabe auf Basis des sicheren Tokens und der Nur-Text-Nachricht; und Senden, durch die Kommunikationseinheit, der Verifizierungsangabe an das erste externe Gerät der anfordernden Entität.
  2. Verfahren nach Anspruch 1, wobei die Verarbeitung in Reaktion auf das Empfangen der Nur-Text-Nachricht von einem ersten externen Gerät einer anfordernden Entität durchgeführt wird, wobei die Nur-Text-Nachricht die Kontaktinformationen der anfordernden Entität umfasst.
  3. Verfahren nach Anspruch 1 oder 2, wobei die Nur-Text-Nachricht die Kontaktinformationen umfasst, die eine physische Adresse einer Firma oder Person beinhalten, das/die der anfordernden Entität zugeordnet ist.
  4. Verfahren nach einem der vorstehenden Ansprüche, wobei die Nur-Text-Nachricht eine Identität-Javascript Object Notation (JSON) der Kontaktinformationen umfasst.
  5. Verfahren nach einem der vorstehenden Ansprüche, wobei: das Verarbeiten der Nur-Text-Nachricht ferner das Hinzufügen eines Salt-Elements zur Nur-Text-Nachricht und Verarbeiten der Nur-Text-Nachricht mit dem vordefinierten Salt-Element mithilfe der Hash-Funktion umfasst; und das Senden der Verifizierungsangabe zu dem ersten externen Gerät der anfordernden Entität das Senden einer Verifizierungs-URL, die das sichere Token und die Informationen der Nur-Text-Nachricht enthält, an das erste externe Gerät umfasst.
  6. Gerät, umfassend: eine Kommunikationseinheit; und einen oder mehrere Prozessoren, die konfiguriert sind: von einem Speicher eine Nur-Text-Nachricht abzurufen, die Informationen einer anfordernden Entität enthält; die Nur-Text-Nachricht mithilfe einer Hash-Funktion zu verarbeiten, um einen Hash-Wert der Nur-Text-Nachricht zu generieren; und eine Verifizierungsangabe auf Basis der Nur-Text-Nachricht und eines sicheren Tokens zu erstellen, das von einem zweiten externen Gerät einer authentifizierenden Entität empfangen wird; wobei: die Nur-Text-Nachricht Kontaktinformationen über die anfordernde Entität beinhaltet; und die Kommunikationseinheit ferner konfiguriert ist, die Verifizierungsangabe an ein erstes externes Gerät der anfordernden Entität in Reaktion auf das Empfangen des sicheren Tokens von dem zweiten externen Gerät der authentifizierenden Entität zu senden.
  7. Gerät nach Anspruch 6, wobei die Nur-Text-Nachricht die Kontaktinformationen der anfordernden Entität umfasst.
  8. Gerät nach Anspruch 6 oder 7, wobei die Nur-Text-Nachricht die Kontaktinformationen umfasst, die eine physische Adresse einer Firma oder Person beinhalten, die der anfordernden Entität zugeordnet ist.
  9. Gerät nach einem der Ansprüche 6-8, wobei die Nur-Text-Nachricht eine Identität-Javascript Object Notation (JSON) der Kontaktinformationen umfasst.
  10. Gerät nach einem der Ansprüche 6-9, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind: ein Salt-Element zur Nur-Text-Nachricht hinzuzufügen und die Nur-Text-Nachricht mit dem vordefinierten Salt-Element mithilfe der Hash-Funktion zu verarbeiten; und die Verifizierungsangabe zu dem ersten externen Gerät der anfordernden Entität zu senden, indem eine Verifizierungs-URL, die das sichere Token und die Informationen der Nur-Text-Nachricht enthält, an das erste externe Gerät gesendet wird.
  11. Verfahren, umfassend: in Reaktion auf das Empfangen eines Hash-Werts von einem Computergerät eines vertrauenswürdigen Anbieters: Speichern des Hash-Werts im Speicher, wobei der Hash-Wert Nur-Text-Informationen entspricht, die der anfordernden Entität zugeordnet sind, wobei die Nur-Text-Informationen Kontaktinformationen über die anfordernde Entität beinhalten, und Generieren, durch ein oder mehrere Prozessorgeräte, eines sicheren Tokens, das einem Speicherort des Hash-Werts zugeordnet ist; und in Reaktion auf das Empfangen einer Verifizierungsnachricht von einem ersten externen Gerät der anfordernden Entität: Verarbeiten, durch das eine oder die mehreren Prozessorgeräte, der Verifizierungsnachricht mithilfe einer Hash-Funktion, um einen Hash-Wert zu erzeugen, Abrufen des Hash-Werts, der im Speicher gespeichert ist, Vergleichen eines generierten Hash-Werts mit dem Hash-Wert, der aus dem Speicher abgerufen wird, und Vergleichen des generierten sicheren Tokens mit Tokeninformationen in der Verifizierungsnachricht, um eine Identität der anfordernden Entität zu verifizieren.
  12. Verfahren nach Anspruch 11, wobei das Generieren des sicheren Tokens, das dem Speicherort zugeordnet ist, das Generieren einer zufälligen Tokenzeichenfolge und das Aufzeichnen einer Zuordnung zwischen der zufälligen Tokenzeichenfolge und dem Speicherort umfasst.
  13. Verfahren nach Anspruch 12, wobei eine Länge der zufälligen Tokenzeichenfolge mindestens 16 Bit ist.
  14. Verfahren nach einem der Ansprüche 11-13, ferner umfassend das Speichern des sicheren Tokens in einer Datenbank und das Zuordnen des sicheren Tokens zum gespeicherten Hash-Wert.
  15. Verfahren nach einem der Ansprüche 11-14, ferner umfassend das Vorausfüllen einer Anmeldevorlage mit Kontodaten der anfordernden Entität durch den einen oder die mehreren Prozessoren.
  16. Verfahren nach Anspruch 15, wobei die Kontodaten über einen Abfragezeichenfolgeparameter zur Identifizierung empfangen werden, der der anfordernden Entität zugeordnet ist.
  17. Gerät, umfassend: eine Kommunikationseinheit; und einen oder mehrere Prozessoren, die konfiguriert sind: in Reaktion auf das Empfangen eines Hash-Werts von einem Computergerät eines vertrauenswürdigen Anbieters: den Hash-Wert im Speicher zu speichern, wobei der Hash-Wert Nur-Text-Informationen entspricht, die der anfordernden Entität zugeordnet sind, wobei die Nur-Text-Informationen Kontaktinformationen über die anfordernde Entität beinhalten, und durch ein oder mehrere Prozessorgeräte ein sicheres Token zu generieren, das einem Speicherort des Hash-Werts zugeordnet ist; und in Reaktion auf das Empfangen einer Verifizierungsnachricht von einem ersten externen Gerät der anfordernden Entität: durch das eine oder die mehreren Prozessorgeräte die Verifizierungsnachricht mithilfe einer Hash-Funktion zu verarbeiten, um einen Hash-Wert zu erzeugen, den Hash-Wert, der im Speicher gespeichert ist, abzurufen, einen generierten Hash-Wert mit dem Hash-Wert, der aus dem Speicher abgerufen wird, zu vergleichen und das generierte sichere Token mit Tokeninformationen in der Verifizierungsnachricht zu vergleichen, um eine Identität der anfordernden Entität zu verifizieren.
  18. Gerät nach Anspruch 17, wobei das sichere Token, das dem Speicherort zugeordnet ist, durch Generieren einer zufälligen Tokenzeichenfolge und Aufzeichnen einer Zuordnung zwischen der zufälligen Tokenzeichenfolge und dem Speicherort erstellt wird.
  19. Gerät nach Anspruch 18, wobei eine Länge der zufälligen Tokenzeichenfolge mindestens 16 Bit ist.
  20. Gerät nach einem der Ansprüche 17-19, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind, das sichere Token in einer Datenbank zu speichern und das sichere Token zum gespeicherten Hash-Wert zuzuordnen.
  21. Gerät nach einem der Ansprüche 17-20, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind, eine Anmeldevorlage mit Kontodaten der anfordernden Entität vorauszufüllen.
  22. Gerät nach Anspruch 21, wobei die Kontodaten über einen Abfragezeichenfolgeparameter zur Identifizierung empfangen werden, der der anfordernden Entität zugeordnet ist.
DE102018121306.9A 2017-10-25 2018-08-31 Identitätsverifizierung unter Wahrung der Privatsphäre Pending DE102018121306A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
PCT/US2017/058185 WO2019083517A1 (en) 2017-10-25 2017-10-25 IDENTITY VERIFICATION PRESERVING CONFIDENTIALITY
IBPCT/US2017/058185 2017-10-25

Publications (1)

Publication Number Publication Date
DE102018121306A1 true DE102018121306A1 (de) 2019-04-25

Family

ID=60327381

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018121306.9A Pending DE102018121306A1 (de) 2017-10-25 2018-08-31 Identitätsverifizierung unter Wahrung der Privatsphäre

Country Status (6)

Country Link
US (1) US10764051B2 (de)
EP (1) EP3596642B1 (de)
DE (1) DE102018121306A1 (de)
FR (1) FR3072802A1 (de)
GB (1) GB2567932A (de)
WO (1) WO2019083517A1 (de)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9678773B1 (en) 2014-09-30 2017-06-13 Amazon Technologies, Inc. Low latency computational capacity provisioning
US9600312B2 (en) 2014-09-30 2017-03-21 Amazon Technologies, Inc. Threading as a service
US9146764B1 (en) 2014-09-30 2015-09-29 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US9413626B2 (en) 2014-12-05 2016-08-09 Amazon Technologies, Inc. Automatic management of resource sizing
US9588790B1 (en) 2015-02-04 2017-03-07 Amazon Technologies, Inc. Stateful virtual compute system
US9733967B2 (en) 2015-02-04 2017-08-15 Amazon Technologies, Inc. Security protocols for low latency execution of program code
US11132213B1 (en) 2016-03-30 2021-09-28 Amazon Technologies, Inc. Dependency-based process of pre-existing data sets at an on demand code execution environment
US10102040B2 (en) 2016-06-29 2018-10-16 Amazon Technologies, Inc Adjusting variable limit on concurrent code executions
CN108564688A (zh) * 2018-03-21 2018-09-21 阿里巴巴集团控股有限公司 身份验证的方法及装置和电子设备
US10853115B2 (en) 2018-06-25 2020-12-01 Amazon Technologies, Inc. Execution of auxiliary functions in an on-demand network code execution system
US11146569B1 (en) 2018-06-28 2021-10-12 Amazon Technologies, Inc. Escalation-resistant secure network services using request-scoped authentication information
US11099870B1 (en) 2018-07-25 2021-08-24 Amazon Technologies, Inc. Reducing execution times in an on-demand network code execution system using saved machine states
US11099917B2 (en) 2018-09-27 2021-08-24 Amazon Technologies, Inc. Efficient state maintenance for execution environments in an on-demand code execution system
US11243953B2 (en) 2018-09-27 2022-02-08 Amazon Technologies, Inc. Mapreduce implementation in an on-demand network code execution system and stream data processing system
US11943093B1 (en) 2018-11-20 2024-03-26 Amazon Technologies, Inc. Network connection recovery after virtual machine transition in an on-demand network code execution system
US11010188B1 (en) 2019-02-05 2021-05-18 Amazon Technologies, Inc. Simulated data object storage using on-demand computation of data objects
US11861386B1 (en) * 2019-03-22 2024-01-02 Amazon Technologies, Inc. Application gateways in an on-demand network code execution system
US11119809B1 (en) 2019-06-20 2021-09-14 Amazon Technologies, Inc. Virtualization-based transaction handling in an on-demand network code execution system
US11190609B2 (en) 2019-06-28 2021-11-30 Amazon Technologies, Inc. Connection pooling for scalable network services
US11159528B2 (en) 2019-06-28 2021-10-26 Amazon Technologies, Inc. Authentication to network-services using hosted authentication information
US11119826B2 (en) 2019-11-27 2021-09-14 Amazon Technologies, Inc. Serverless call distribution to implement spillover while avoiding cold starts
US11714682B1 (en) 2020-03-03 2023-08-01 Amazon Technologies, Inc. Reclaiming computing resources in an on-demand code execution system
US11165586B1 (en) * 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11593270B1 (en) 2020-11-25 2023-02-28 Amazon Technologies, Inc. Fast distributed caching using erasure coded object parts
US11550713B1 (en) 2020-11-25 2023-01-10 Amazon Technologies, Inc. Garbage collection in distributed systems using life cycled storage roots
US11388210B1 (en) 2021-06-30 2022-07-12 Amazon Technologies, Inc. Streaming analytics using a serverless compute system
US11968280B1 (en) 2021-11-24 2024-04-23 Amazon Technologies, Inc. Controlling ingestion of streaming data to serverless function executions
US12015603B2 (en) 2021-12-10 2024-06-18 Amazon Technologies, Inc. Multi-tenant mode for serverless code execution
WO2023154783A2 (en) * 2022-02-10 2023-08-17 Fall Guy Llc, Dba Fall Guy Consulting Privacy-preserving identity verification
CN117592124B (zh) * 2024-01-18 2024-05-07 中国科学院信息工程研究所 低开销抗泄漏与伪造的存证方法、装置、设备和存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7640578B2 (en) * 2002-07-08 2009-12-29 Accellion Inc. System and method for providing secure communication between computer systems
US8788836B1 (en) 2006-12-22 2014-07-22 Symantec Corporation Method and apparatus for providing identity claim validation
US8347093B1 (en) 2010-07-19 2013-01-01 Google Inc. Privacy preserving name verification
US9098678B2 (en) * 2011-09-15 2015-08-04 Verizon Patent And Licensing Inc. Streaming video authentication
US9847982B2 (en) * 2011-10-31 2017-12-19 Nokia Technologies Oy Method and apparatus for providing authentication using hashed personally identifiable information
US20150047003A1 (en) * 2013-08-07 2015-02-12 Sal Khan Verification authority and method therefor
US9971574B2 (en) * 2014-10-31 2018-05-15 Oracle International Corporation JSON stylesheet language transformation
US10114975B1 (en) * 2017-01-13 2018-10-30 Marklogic Corporation Apparatus and method for data redaction in a semi-structured document database
GB2561875A (en) 2017-04-26 2018-10-31 Sita Advanced Travel Solutions Ltd System and method for authenticating a non-transferrable access token

Also Published As

Publication number Publication date
EP3596642A1 (de) 2020-01-22
WO2019083517A1 (en) 2019-05-02
US20190363885A1 (en) 2019-11-28
US10764051B2 (en) 2020-09-01
GB2567932A (en) 2019-05-01
GB201813959D0 (en) 2018-10-10
FR3072802A1 (fr) 2019-04-26
EP3596642B1 (de) 2021-03-10

Similar Documents

Publication Publication Date Title
DE102018121306A1 (de) Identitätsverifizierung unter Wahrung der Privatsphäre
DE602004012996T2 (de) Verfahren und vorrichtung zum authentifizieren von benutzern und websites
US20190236598A1 (en) Systems, methods, and apparatuses for implementing machine learning models for smart contracts using distributed ledger technologies in a cloud based computing environment
DE102007033615B4 (de) Verfahren und Vorrichtung zum Umwandeln von Authentisierungs-Token zur Ermöglichung von Interaktionen zwischen Anwendungen
CN110569658B (zh) 基于区块链网络的用户信息处理方法、装置、电子设备及存储介质
CN105830388B (zh) 用于管理目录服务的身份池桥接
DE102011089580B3 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
DE102014113430A1 (de) Verteilte Datenspeicherung mittels Berechtigungstoken
DE102011082101A1 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
DE102008040416A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
US11983787B2 (en) Integration of workflow with digital ID
CN110096551A (zh) 基于区块链的信用数据存储方法、装置、设备及介质
CN106416125A (zh) 用于虚拟机实例的自动目录加入
CN107872455A (zh) 一种跨域单点登录系统及其方法
US20110208631A1 (en) System and method for mortgage application recording
CN112231284A (zh) 基于区块链的大数据共享系统、方法、装置和存储介质
CN106549909A (zh) 一种授权验证方法及设备
US20220318757A1 (en) System for verifying education and employment of a candidate via a blockchain network
US20150317463A1 (en) Active directory for user authentication in a historization system
CN110753045A (zh) 不同域之间单点登录的方法
CN112150113A (zh) 档案数据的借阅方法、装置和系统、资料数据的借阅方法
DE202015009601U1 (de) System zur persönlichen Identifizierung und Verifizierung
CN106657310B (zh) 表单的提交方法及装置
EP4254234A1 (de) Ausstellen eines digitalen credentials für eine entität
Bergers et al. Dwh-dim: a blockchain based decentralized integrity verification model for data warehouses

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: KILBURN & STRODE LLP, GB

Representative=s name: KILBURN & STRODE LLP, NL

R082 Change of representative

Representative=s name: KILBURN & STRODE LLP, NL

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