DE102012106081A1 - Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten oder Dateien - Google Patents

Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten oder Dateien Download PDF

Info

Publication number
DE102012106081A1
DE102012106081A1 DE201210106081 DE102012106081A DE102012106081A1 DE 102012106081 A1 DE102012106081 A1 DE 102012106081A1 DE 201210106081 DE201210106081 DE 201210106081 DE 102012106081 A DE102012106081 A DE 102012106081A DE 102012106081 A1 DE102012106081 A1 DE 102012106081A1
Authority
DE
Germany
Prior art keywords
data
encrypted
tokey
user
parties
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE201210106081
Other languages
English (en)
Inventor
Anmelder Gleich
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to DE201210106081 priority Critical patent/DE102012106081A1/de
Publication of DE102012106081A1 publication Critical patent/DE102012106081A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung beschreibt ein Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten und Schlüsseln auf getrennten Systemen.

Description

  • Die Erfindung betrifft ein Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten oder Dateien und Schlüsseln auf getrennten Systemen und ein Computerprogrammprodukt zur Durschführung des Verfahrens.
  • Durch die rasante Zunahme Internet basierender Dienste in der jüngsten Vergangenheit, werden schon heute, und sicherlich auch in Zukunft deutlich mehr unserer Daten in digitaler Form verlangt. Immer mehr Aktionen, wie Einkaufen und Bezahlen, Mitgliedschaften oder Zugangsberechtigungen erfolgen via Internet und benötigen mehr oder weniger immer dieselben, personenbezogenen Daten, wie Name, Anschrift, Kreditkartendaten etc. Diese Systeme benötigen zudem immer eine Legitimation durch Login-Name und Passwort, wobei die Daten dezentral vorgehalten und „gepflegt“ werden müssen.
  • Die Aufgabe für den Einzelnen ist zum einen, diese Daten unterschiedlichsten Organisationen zur Verfügung zu stellen, und zu „pflegen“. Dies ist zum Teil recht müßig, und nicht selten springen die Anwender wegen des hohen Aufwands bei einer Kaufentscheidung kurz vor Zahlung ab. Zum anderen müssen sich die Nutzer unzählige Login-Namen und Passwörter zu merken. Der am häufigsten angeklickte Button ist „Passwort vergessen“. Es ist nachgewiesen, dass die Benutzer deshalb nur durchschnittlich 3 Passwörter verwenden, was wiederum ein ein großes Sicherheitsrisiko darstellt.
  • Um dem Anwender diesbezüglich entgegenzukommen, sind im Stand der Technik folgende Verfahren beschrieben:
    • 1. Automatische Vervollständigung von digitalen Formularen durch den Browser
    • 2. Einen Passworttresor, in welchem sich alle Passwörter befinden
    • 3. Mehr oder weniger umständliche Legitimierungsverfahren
  • Im Stand der Technik sind Programme beschrieben, die Passwörter oder Kennwörter eines Anwenders zentral speichern. Ein Anwender muss sich zahlreiche Passwörter merken, mit denen er Zugang zu einem gesicherten Bereich erhält. Gerade in dem digitalen Zeitalter, wo das Internet als zentraler Marktplatz angesehen wird, das zum Einkaufen und Verkaufen genutzt wird, ist es von entscheidender Bedeutung, dass der Anwender bzw. die Daten des Anwenders einen umfangreichen Schutz erhalten. Dies gilt spezielle für Online-Banking, mit dem der Anwender Geldgeschäfte vornimmt und ihm so der Gang zur Bank erspart bleibt.
  • Durch die steigende Anzahl der Erledigungen, die mithilfe des Internets durchgeführt werden können, steigt aber auch die Zahl der Betrugsfälle. Betrüger können durch das Internet zahlreiche Anwender erreichen und unterschiedliche Strategien verfolgen. Aus diesem Grund ist es entscheidend, dass der Anwender seine privaten Daten schützt und auch dafür Sorge trägt, dass die genutzten Programme ausreichend geschützt sind.
  • Die Programme, die Passwörter für einen Benutzer speichern, sind aus dem Problem entstanden, dass Anwender in ihrem System und auf vielen Internetseiten Benutzernamen mit sicheren Kennwörtern benötigen. Da es ein hohes Sicherheitsrisiko darstellt, für verschiedene Dienste gleiche Benutzernamen und Kennwörter zu nutzen (ein Angreifer hätte dann Zugriff auf alle Dienste), sollte der Anwender für jeden Dienst zumindest ein unterschiedliches Kennwort wählen. Es ist aber ebenfalls wichtig, dass das gewählte Passwort ausreichend sicher ist. Moderne Verschlüsselungsverfahren sind technisch so weit fortgeschritten, dass sie in der Praxis außer durch das Austesten aller möglichen Schlüssel – der sogenannten Brute-Force-Methode – meist nur durch einen Wörterbuchangriff geknackt werden können. Die Schwachstelle ist bei beiden Angriffen das vom Benutzer gewählte Passwort. Damit ein Passwort nicht unsicherer ist als die eigentliche Verschlüsselung (112 bis 128-Bit-Schlüssel bei gängigen Verfahren), ist für dieses theoretisch eine Folge von etwa 20 zufälligen Zeichen erforderlich. Falls das Passwort nicht aus zufälligen Zeichen besteht, sind sogar deutlich längere Zeichenfolgen nötig, um die gleiche Sicherheit zu erreichen.
  • Da die Länge der Passwörter, die zur Verschlüsselung verwendet werden können, softwareseitig oft begrenzt ist, sollte man immer Zeichenkombinationen wählen, die aus seltenen Wörtern und Wortstellungen, Phantasiewörtern oder fremdsprachigen Wörtern, Anfangsbuchstaben eines Satzes, Zahlen und/oder Sonderzeichen oder noch besser Kombinationen davon bestehen. Deren Bestandteile sollten für einen gut über die Person und ihre Interessen informierten Angreifer nicht vorhersehbar sein. Eine Alternative ist es, einen Passwortgenerator zu benutzen und sich das Passwort entweder gut einzuprägen oder an einem geheimen Ort zu notieren.
  • Weil die Anzahl der schwierig zu merkenden Kennwörter, da sie recht lang und wirr sind, mitunter zu groß und nicht mehr zuordnungsfähig wird, benutzt der Anwender eine Kennwortverwaltung. Besonders Systemadministratoren brauchen viele verschiedene und sehr starke Kennwörter, da diese immer noch das schwächste Glied der Kette zum Schutz eines Netzes darstellen.
  • Eine Kennwortverwaltung, auch Kennwortverwaltungsprogramm, Kenn- oder Passwortverwalter oder Passwortverwaltung (engl. Password Manager, Password Safe) genannt, ist ein Computerprogramm, mit dessen Hilfe ein Computer-Benutzer Kennwörter und Geheimzahlen verschlüsselt speichern und verwalten kann. Verfügbare Programme finden sich für viele Plattformen, z. B. für Windows, Linux, MacOS X, Pocket PC, Smart Device, Palm OS, U3. Auch alle gängigen Webbrowser verwalten und speichern Kennwörter. Beim Besuch der entsprechenden Website tragen sie dann Benutzername und Kennwort automatisch ein. Manche Webbrowser ermöglichen den zusätzlichen Schutz mit einem Hauptkennwort und speichern die Kennwörter verschlüsselt ab. In der Kennwortverwaltung kann der Anwender Benutzernamen, zugehörige Kennwörter und weitere Informationen ablegen und ordnen. Dabei ist diese Datenbank durch ein dementsprechend starkes Hauptkennwort gesichert und verschlüsselt. Der Anwender trägt Kennwort und Benutzername in die Datenbank ein und kopiert bei Bedarf die Zugangsdaten in die entsprechenden Anmeldefelder. Eine Automatisierung des gesamten Eingabevorgangs ist möglich. Integriert ist meist auch ein Kennwortgenerator, mit dem verschieden starke Kennwörter generiert werden können. Auf Grundlage der zufälligen Eingabe des Benutzers mit Maus oder Tastatur erstellt dieser Kennwörter mit beliebiger Länge und verschiedenen Zeichensätzen.
  • Die Sicherung einer Kennwortdatenbank gestaltet sich einfacher als die Sicherung einer Mischung aus speziellen Kennwortdateien des Browsers, anderen Programmdateien sowie Zetteln oder ungünstigenfalls ungeschützten Dateien auf dem Rechner, welche Kennwörter enthalten. Eine Kennwortverwaltung sammelt die Kennwörter zentral, so ist nur eine Datei für alle Kennwörter zu sichern. Exportiert werden kann die Datenbank meist als CSV-Datei, welche alle gängigen Kennwortverwaltungsprogramme und Texteditoren unterstützen. Auch der flexible XML-Export oder einfaches Ausdrucken ist möglich. Nachteil bei diesen Formaten ist, dass sie die Kennwörter unverschlüsselt speichern. So bleibt zur Sicherung nur die Speicherung im programmeigenen verschlüsselten Format. Die oben genannten Formate dienen dem Datenaustausch und der Datenverarbeitung. Die Kennwortverwaltung der Internetbrowser Mozilla Firefox, Google Chrome und Internet Explorer speichert die Passwörter unverschlüsselt. Mozilla Firefox verschlüsselt die Kennwörter optional mit einem so genannten Master-Passwort. Ohne Eingabe dieses Master-Passworts kann der Nutzer die gespeicherten Passwörter nicht nutzen. Das Hauptkennwort in Dateiform muss zusätzlich gesichert werden, um einem eventuellen Verlust des Trägermediums vorzubeugen. Manche Kennwortverwaltungen bieten die Möglichkeit zur automatischen Sicherung.
  • Ein Nachteil der bekannten Kennwortverwaltungsprogramme ist, dass Nutzer von Kennwortverwaltern von der benutzten Datenbank abhängig sind. Der Anwender benötigt möglichst dauerhaften Zugriff auf die Programme. Lokal gespeicherte Datenbanken können durch Beschädigung von Hard- und Software unzugänglich sein, so dass der Anwender keinen Zugriff auf die Kennwörter erhält. Unverschlüsselt gespeicherte Passwörter können von Datendieben einfach entwendet werden und stellen eine Sicherheitslücke dar. In modernen Webbrowsern ist der Schutz bislang unzulänglich.
  • Die im Stand der Technik beschriebenen Verfahren haben die Nachteile, dass sie nicht alltagstauglich undr unsicher sind. So können beispielsweise Passwörter, die von einem Browser gespeichert werden, auch dann vervollständigt werden, wenn eine andere Person den Browser benutzt. Vervollständigung erfolgt auch, wenn ein anderer an meinem Rechner sitzt. Auch die aufwendigen Ligitimierungsverfahren sind nicht sicher, da der Anwender immer ein Zusatzgerät nutzen muss, dass ggf. nicht immer zur Hand ist.
  • Aus diesen Gründen ist es die Aufgabe der Erfindung Verfahren zu entwickeln, was nicht die Nachteile oder Mängel des Standes der Technik aufweist und welches personenbezogene, persönliche Daten zentral verwaltet und legitimierten Organisationen in standardisierter Form Einzelfallbezogen zur Verfügung stellt.
  • Gelöst wird die Aufgabe durch den unabhängigen Anspruch. Bevorzugte Ausführungsformen finden sich in den Unteransprüchen.
  • Es war völlig überraschend, dass ein Verfahren bereitgestellt werden konnte, welches
    • • Daten so speichert, dass es nicht zu sogenannten „Datenpannen“ kommen kann, und tausende oder Millionen personenbezogene Daten „frei“ verfügbar werden,
    • • Daten nur nach fallbezogener, persönlicher Legitimation vertrauten Organisationen zur Verfügung gestellt werden,
    • • die eigene Identität garantiert wird und
    • • eine Trennung von Generation und Freigabe einer Transaktion (Vertretung/4-Augen-Prinzip) ermöglicht.
  • Die Erfindung betrifft ein Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten und Schlüsseln auf getrennten Systemen und zur Weitergabe der Daten an legitimierte Dritte, wobei sich Dritte mittels einer verschlüsselten und transaktionsbezogenen übertragener Autorisierungsanforderung durch den Anwender für einzelne Transaktionen, wie Registrierung, Login, Zugang, Zahlung oder dergleichen autorisieren lassen. Die Autorisierungsanforderung kann vorzugsweise fototechnisch und/oder visualisiert, mittels Barcodes, QR-Codes, Bluetooth, NFC oder sonstiger Übertragungstechnik übertragen werden.
  • Vorzugsweise sind die Daten 1024 Bit verschlüsselt. Der Zugangscode bzw. der Zugangsschlüssel zum Datenserver und Schlüsselserver sind bevorzugt unterschiedliche Hashwerte (SHA512) aus den Benutzerzugangsdaten und GeräteID (Geräteidentifikation). Diese Werte sind insbesondere nicht rückrechenbar. Das bedeutet, dass in keinem System ein Rückschluss auf die Daten bzw. den Schlüssel der Benutzer, bzw. auf den Benutzer generell möglich ist. Es ist zudem bevorzugt, dass selbst Mitarbeiter der Rechenzentren keine Möglichkeit dazu haben. Es kann jedoch auch bevorzugt sein, dass die Software auf dem Schlüsselserver durch Programmierer manipulierbar ist, indem sie eine Kopie der für die anfragende Organisation bestimmten Daten wegkopiert.
  • Es ist bevorzugt, dass die Daten SSL verschlüsselt sind. Vorteilhafterweise können personenbezogene Daten so gespeichert werden, dass sie nur durch das Zusammenspiel, mehrerer, voneinander unabhängiger Organisation wieder zusammengestellt werden können. Das heißt, es ist bevorzugt, dass in einer ersten Organisation die Daten verschlüsselt und in verschiedenen Blöcken gespeichert werden. In einer zweiten Organisation werden die Schlüssel hierfür verwaltet. Die erste Organisation wird im Sinne der Erfindung insbesondere als Organisation A und die zweite Organisation als Organisation B bezeichnet. Es ist bevorzugt, dass die Daten bzw. Datensätze von jeder der beteiligten Organisationen oder Systeme nur im Zusammenspiel mit allen Anderen zusammengestellt werden können. Vorteilhaft ist, wenn die Zusammenstellung der Daten auf einem elektronischen Endgerät mit Internetzugang, insbesondere einem Smartphone erfolgt.
  • Die Zuordnung der Daten zu Schlüsseln erfolgt durch eine, beim Anwender befindliche Software. Selbst beim Anwender werden keine Zugangsdaten gespeichert. Die Software ist vorzugsweise bei dem Anwender auf einem Endgerät gespeichert. Hierbei kann es sich um einen Computer, ein Smartphone, ein Tablet-PC oder sonstiges elektronisches Gerät sein, welches dem Anwender einen Zugang zum Internet ermöglicht. Die beteiligten Organisationen können privat, halbstaatlich oder staatlich sein.
  • Kein beteiligtes Subsystem liefert Daten auf Anforderung, sondern sendet Daten nach ihrer Freigabe nur an dezidierte und geprüfte Subsysteme.
  • Das Verfahren kann überraschenderweise vielfältig für unterschiedlilche Anwendungen eingesetzt werden, umfassen Eintritt zu Veranstaltungen, Verwaltung von Abonnements, wie z.B. Jahreskarten, PayTV, Homeshopping (dynamischer v-tokey wird auf dem Fernsehbildschirm dargestellt), Bestellung direkt ab Plakat mit statischem v-tokey, Ein/Auschecken von Leistungsangeboten, Überprüfungen oder Sicherheitszutritt.
  • Insbesondere betrifft die Erfindung ein System, welches ein bevorzugtes Verfahren ermöglicht. Das System umfasst notwendige elektronische Komponenten, die zur Durchführung des Verfahrens notwendig sind.
  • Des Weiteren umfasst die Erfindung ein Computerprogrammprodukt zur Durchführung eines Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten und Schlüsseln auf getrennten Systemen und zur Weitergabe der Daten an legitimierte Dritte, wobei sich Dritte mittels einer verschlüsselten und visualisierten transaktionsbezogenen, fototechnisch übertragener Autorisierungsanforderung durch den Anwender für einzelne Transaktionen, wie Registrierung, Login, Zugang, Zahlung oder dergleichen autorisieren lassen.
  • Außerdem betrifft die Erfindung ein personalisiertes Übermittlungsgerät zur Durchführung des Verfahrens, wobei mit dem Übermittlungsgerät eine sichere Autentifizierung via Internet hergestellt wird. Vorteilhaftersweise kann jedes Geräte verwendet werden, welches über Internet kommunizieren kann. Je personalisierbarer dieses Gerät ist, umso sicherer ist die eindeutige Identifizierung des Benutzers. Es ist auch bevorzugt, bei bestimmten Aktionen eine Art „Lichtbildausweis“ auf das Gerät bzw. auf den Bildschirm der anfragenden Organisation zu senden. Es ist insbesondere bevorzugt, dass Daten und Schlüssel absolut voneinander getrennt gespeichert werden und einzig eine Software beim Anwender, die unterschiedlichen Datenblöcke mit den richtigen Schlüssel zusammen bringen kann.
  • Die Erfindung betrifft zudem ein System umfassend ein elektronisches Gerät und ein Darstellungsmittel, insbesondere einen Monitor, wobei das Gerät einen Code, insbesondere einen QR-Code oder Barcode auf dem Monitor scannt oder fotographiert und eine Software oder Applikation auf dem Gerät diesen entschlüsselt und verarbeitet. Die Erstellung, bzw. Visualisierung des Codes, der im Sinne der Erfindung auch als tokey bezeichnet werden kann, erfolgt über eine Software, insbesondere eine tokeyServer – Software. Die Erfassung des tokey erfolgt über eine elektronische Bildaufzeichnung oder per Doppelklick. Die Entschlüsselung, Überprüfung, Vervollständigung sowie die Rücksendung erfolgt durch die tokeyClient – Software via Internet. Das System ist für verschiedene Sicherheitsstufen ausgelegt. Es reicht von der einfachen Registrierung im Web bis zur Zugangskontrolle via Gesichtserkennung durch eine Kamera. Hierbei werden die Daten komplett anonymisiert auf getrennten System gehalten. Für einen Vorgang werden 3+1 Komponenten benötigt, wobei keine Gefahr von Datenverlust bzw. Datenpannen besteht, da Informationen nicht in ihrer Gesamtheit vorliegen bzw. verfügbar sind.
  • Das System oder das Verfahren kann vielfältig angewendet werden. Auf allen möglichen WebSites muss man sich registrieren. Zu Vereinfachung ist auf der entsprechenden Website ein tokey zum einscannen oder anklicken. Die Registrierung erfolgt im Hintergrund. Login erfolgt insbesondere durch einscannen oder anklicken eines tokeys. Der Einlass nach dem Scannen eines tokeys erfolgt durch serverseitige Freischaltung des user tokeys. Bezahlen kann ebenfalls durch einscannen oder anklicken eines tokeys im Web erfolgen oder durch scannen eines tokeys auf einer Rechnung oder Quittung / Kassenbons. Weitere bevorzugte Anwendungen des Verfahrens umfassen Eintritt zu Veranstaltungen, Verwaltung von Abonnements, wie z.B. Jahreskarten, PayTV, Homeshopping (dynamischer v-tokey wird auf dem Fernsehbildschirm dargestellt, Bestellung direkt ab Plakat mit statischem v-tokey, Ein/Auschecken von Leistungsangeboten, Legitimationsprüfungen oder Verwahrung von besonders schützenswerten z.B. vertraulichen Dokumenten.
  • Im Folgenden soll die Erfindung anhand von Figuren und Beispielen erläutert werden, ohne jedoch hierauf beschränkt zu sein. Es zeigen:
  • 1 Beispiel eines bevorzugten Verfahrens
  • 2 Weiteres Beispiel eines bevorzugten Verfahrens
  • 3 Ablauf eines bevorzugten Verfahrens
  • 1 zeigt ein Beispiel eines bevorzugten Verfahrens. Hierbei kann sich eine Person an einem internetfähigen Gerät mit zwei Wörtern und/oder Phrasen anmelden, wobei die Anmeldung bei einem Daten- so wie einem Schlüsselserver erfolgt. Vorteilhafterweise werden die Wörter oder Phrasen nirgends gespeichert. Anschließend startet bevorzugt eine Applikation und/oder ein Scanmodus, so dass ein Tokey gescannt wird und durch ein Einverständnis der Person bestätigt wird.
  • 2 zeigt ein weiteres Beispiel eines bevorzugten Verfahrens. Ein Organisationsserver sendet eine Anfrage zur autorisierten Nutzung bestimmter Daten (z. B. für Logins, Registrierungen oder Ähnlichem) an den Schlüsselserver. Dort wird eine Schlüsselserver-Session für eine Autorisierungsanfrage geöffnet und vorbereitet. Der Schlüsselserver sendet daraufhin einen individuellen, einmaligen visual-tokey (z.B. QR-Code) an den Organisationsserver zurück. Der QR-Code wird auf der Seite der Organisation angezeigt und kann vom Nutzer durch eine mobile Kamera, welche insbesondere mit der tokey-App verbunden ist, gelesen werden. Der Schlüsselserver prüft welche Datenblöcke der Organisationsservers angefragt hat und schickt daraufhin eine Anfrage zur Autorisierung der Freigabe der Daten an den Nutzer. Nach Bestätigung des Nutzers wird die Information seines Einverständnisses an den persönlichen Datenserver weitergeleitet. Dieser gibt nun die benötigten, verschlüsselten Datenblöcke frei und sendet sie an den Schlüsselserver. Im Schlüsselserver werden die angefragten Datenblöcke mit dem persönlichen Schlüssel entschlüsselt, zu einem Datensatz zusammen gesetzt und mit einem speziellen Schlüssel für die Organisation verschlüsselt. Die verschlüsselten Datenblöcke werden dem Organisationsserver zugesendet und dort von dem Organisationsschlüssel entschlüsselt um für deren Zweck (Login, Registrierung und Ähnliches) verwendet werden zu können. Anschließend wird die gesamte Anfrage-Session, so wie die Daten bei der Organisation, gelöscht.
  • Bevorzugter Verfahrensablauf
  • Eine Organisation, z.B. der Anbieter eines Dienstes, registriert sich bei tokey.eu oder tokey.us. Auf der Basis seiner Serverdaten (domain oder ip + serviceurl) bekommt er einen eindeutigen Schlüssel erstellt. Der Benutzer lädt ein Programm, tokey.me, auf sein personifiziertes Gerät. Nach einer Registrierung bei tokey.me wird für sein Gerät eine tokeylD erstellt. Der tokey besteht aus dem Anbieterschlüssel, dem verschlüsseltem Anbieterformular incl. temporärer Daten wie Sessionid und dergleichen, der Sicherheitsstufe sowie der Ablaufzeit des tokeys. Hinterlegung seiner Daten auf seinem Gerät um z.B. Registrierungsformulare ausfüllen zu lassen. Diese tokeylD kann er auf seinem Gerät bewahren. Nun kann er Anbieter – tokeys mit Logindaten verwalten. Auch Zufallspasswörter können generieriert werden, sodass ohne tokey gar kein Zugang möglich ist. Er muss sich keine Zugangsdaten mehr merken. Beim Start von tokey.me werden zwei Phrasen verlangt.
  • Desweiteren werden Anbieter und dessen tokey bei tokey.eu oder tokey.us überprüft. Zusätzliche Legitimation pro Aktion durch PIN oder Bild/Gesichtserkennung für Hochsicherheitsaufgaben ab Onlinebanking bis zur Zugangskontrolle. Alle verschlüsselten Daten werden zusätzlich noch SSL verschlüsselt. tokey.me scannt statische wie individuelle, temporäre tokeys. tokey.me kann aber auch ohne scannen tokeys verwalten, in dem es sie lokal öffnet, wenn z.B. der tokey nicht gescannt werden kann, da er auf dem Gerät in einem Browser dargestellt wird.
  • Initialisierung
  • Eine Organisation wie beispielsweise eine Internetplatform wie "kaufen.de" beantragt bei einer weiteren Organisation, wie z. B. tokey.de die Teilnahme am Verfahren und erhält nach Prüfung eine ID, sowie einen Schlüssel für einen bestimmten WebService an einer bestimmten, eindeutigen IP.
  • Der Anwender O.Müller installiert auf seinem Computer oder seinem Smartphone eine Software oder Applikation (insbesondere tokey.me) und initialisiert seine Teilnahme durch die Eingabe von zwei Wörtern bzw. Phrasen.
  • Diese Informationen werden nicht gespeichert und müssen nach jedem Neustart der Applikation bzw. je nach Konfiguration und Sicherheitseinstellung täglich, nach Verlassen eines bestimmten geographischen Bereichs oder pro Transaktion eingegeben werden.
  • Aus diesen zwei Eingaben werden in Kombination mit der Geräte-ID und dem Zeitpunkt, zwei unterschiedliche, nicht rückrechenbare Schlüssel, die im Sinne der Erfindung tokeys genannt werden, generiert.
  • Auf dem Server A, insbesondere tokey.me wird mit dem einen tokey ein leerer Datensatz angelegt. Auf dem Server B, insbesondere tokey.de wird mit dem anderen tokey ein Datensatz mit einem zufällig generiertem Schlüssel angelegt. Es kann auch bevorzugt sein, dass mehrere Server A und B verwendet werden und insbesondere miteinander kommunizieren. Eine auf dem Endgerät installierte Software, die im Sinne der Erfindung auch als Applikation (Abkürzung: App) bezeichnet werden kann, kennt vorzugsweise die IP-Adresse der Server.
  • In einem Formular kann der Anwender nun frei entscheiden, welche Daten er verschlüsselt vorhalten lassen möchte. Diese Einstellungen können jederzeit geändert werden.
  • Die Daten werden in getrennten Blöcken, z.B. Name, Anschrift, pers. Daten und Zahlungsinformationen gespeichert und stehen auf diesem Server niemals in ihrer Gesamtheit zur Verfügung. Server A kann nicht wissen von wem die verschlüsselten Daten in seiner Datenbank sind. Server B hat nur Schlüssel aber keinerlei zugehörige Daten.
  • Nur die Anwender Applikation kann diese Datensätze sinnbringend zusammen führen, allerdings erst nach Aufforderung einer legitimierten Organisation. Das Verfahren kann deshalb auch als ein sogenanntes Drei-Plus-Eins-Verfahren bezeichnet werden.
  • Das Verfahren wird mit dem jeweiligen Stand der Identitätsfeststellung verknüpft, wie zum Beispiel einem Fingerabdruck, einer Gesichtserkennung oder ähnlichem.
  • Registrierung
  • Zum Bestellen von Waren benötigt eine Organisation, z. B. "kaufen.de" bestimmte Informationen, wie Name, Anschrift und Kreditkartendaten der Käufer. Hierfür kann der interessierte Anwender ein Formular ausfüllen oder aber einen v-tokey (visual tokey z.B. in Form eines QR-Codes oder eines Barcodes) mit seinem Smartfon einlesen und alles automatisch ausfüllen lassen. Woher kommt der v-tokey?
  • Kaufen.de hat auf seinem Formular einen externen Link integriert, welcher folgende Daten enthält:
    • • Ich bin kaufen.de
    • • Ich habe folgende SessionID (interne ID von kaufen.de für diese Transaktion)
    • • Ich benötige von dem, der dies einscannt Name, Anschrift und Kreditkarteninformation (Sicherheitscode wird nicht mitgeschickt)
    • • Ich warte mit dem Service kaufen.de/xy mit der IP 100.100.08.15 auf Antwort
  • Durch Abruf des Formulars und damit Aufrufs des Links wird in der Organisation B die Information verifiziert. Nach positiver Prüfung wird eine Session eröffnet, welche sich die Informationen und Anforderungen von kaufen.de merkt und ein v-tokey mit folgenden Informationen generiert:
    • • Ich bin tokey-Server B und habe einen Anforderung mit der Nummer 123456789 geöffnet
    • • Kaufen.de benötigt von Ihnen folgende Daten: Name, Anschrift und Kreditkarteninformation
  • Der Anwender startet die Software auf seinem Smartphone, z. B. eine tokey.me Applikation und scannt diesen v-tokey. Die Anwendung erfragt vom Anwender folgende Bestätigung:
  • "Kaufen.de benötigt von Ihnen folgende Daten: Name, Anschrift und Kreditkarteninformation.", "Bitte bestätigen Sie dies."
  • Die Applikation tokey.me meldet dem tokey-Server B insbesondere:
    Die Daten werden für die Session 123456789 werden gesendet, meine tokeyID ist „nmoihj/87t8g/&“
    BITTE WARTEN!
    Die Applikation tokey.me meldet dem tokey-Server A
    Meine tokey.me ID ist „jiouh87687 76t67“
    Bitte sende die Blöcke NAME, ANSCHIFT, KREDITKARTE zusammen mit der SessionID 123456789 an den tokey-Server B
    Server A sendet an Server B die freigegebenen Daten
    Server B entschlüsselt die Datenblöcke mit dem nur ihm bekannten Schlüssel zu einem Datensatz
    Server B verschlüsselt den Datensatz mit dem Schlüssel von kaufen.de an kaufen.de
    Kaufen.de entschlüsselt den Datensatz und verarbeitet ihn.
  • Login
  • Zum Bestellen von Waren benötigt die Organisation kaufen.de bestimmte Informationen, wie Name, Anschrift und Kreditkartendaten. Hierfür muss der Anwender sich einloggen, d.h. Name und Passwort eingaben oder aber einen v-tokey einscannen. Woher kommt der v-tokey?
  • Kaufen.de hat auf seinem Formular einen externen Link integriert, welcher folgende Daten enthält:
    • • Ich bin kaufen.de
    • • Ich habe folgende SessionID (interne ID von kaufen.de für diese Transaktion)
    • • Ich benötige von dem, der dies einscannt Login Name und Passwort
    • • Ich warte mit dem Service kaufen.de/xy mit der IP 100.100.08.15 auf Antwort
  • Durch Abruf des Formulars und damit Aufrufs des Links wird in der Organisation B die Information verifiziert. Nach positiver Prüfung wird eine Session eröffnet, welche sich die Informationen und Anforderungen von kaufen.de merkt und ein v-tokey mit folgenden Informationen generiert:
    • • Ich bin tokey-Server B und habe einen Anforderung mit der Nummer 123456789 geöffnet
    • • Kaufen.de [kaufen.de]benötigt von Ihnen folgende Daten: Login
  • Der Anwender startet seine tokey.me Applikation und scannt diesen v-tokey.
  • Je nach Sicherheitseinstellung wird der Anwender gefragt:
    Kaufen.de benötigt von Ihnen folgende Daten: Login
    Bitte bestätigen Sie dies.
  • Oder aber die weiter Verarbeitung der Anforderung geschieht automatisch.
  • Die Applikation tokey.me meldet dem tokey-Server B:
    Die Daten werden für die Session 123456789 werden gesendet, meine tokeyID ist „nmoihj/87t8g/&“
    BITTE WARTEN!
    Die Applikation tokey.me meldet dem tokey-Server A
    Meine tokey.me ID ist „jiouh87687 76t67“
    Bitte sende den Block LOGIN für [kaufen.de] zusammen mit der SessionID 123456789 an den tokey-Server B
    Server A sendet an Server B die freigegebenen Daten
    Server B entschlüsselt die Datenblöcke mit dem nur ihm bekannten Schlüssel zu einem Datensatz
    Server B verschlüsselt den Datensatz mit dem Schlüssel von kaufen.de an kaufen.de
    Kaufen.de entschlüsselt den Datensatz und verarbeitet ihn.
  • Beispiel: Bezahlung (selbsteröffnete Transaktion)
  • Nach Abschluss des Kaufes benötigt kaufen.de die Zahlungsfreigabe. Hierfür wird wieder um ein v-tokey zur Verfügung gestelltl
  • Kaufen.de hat auf seinem Formular einen externen Link integriert, welcher folgende Daten enthält:
    • • Ich bin kaufen.de
    • • Ich habe folgende SessionID (interne ID von kaufen.de für diese Transaktion)
    • • Ich benötige Zahlungsfreigabe für den Betrag 100 für „elekt. Kleinteile“
    • • Ich warte mit dem Service kaufen.de/xy mit der IP 100.100.08.15 auf Antwort
  • Durch Abruf des Formulars und damit Aufrufs des Links wird in der Organisation B die Information verifiziert. Nach positiver Prüfung wird eine vorhandene Session verarbeitet und ein v-tokey mit folgenden Informationen generiert:
    • • Ich bin tokey-Server B und habe einen Anforderung mit der Nummer 123456789 geöffnet bzw. beziehe mich auf die Anforderung 123456789
    • • Kaufen.de benötigt Freigabe für 100 €.
  • Der Anwender startet seine tokey.me Applikation und scannt diesen v-tokey.
  • Die Anwendung fragt den Anwender:
    Kaufen.de benötigt von Ihnen folgende Daten: Zahlungsfreigabe 100 Euro
    Bitte bestätigen Sie dies.
  • Die Applikation tokey.me meldet dem tokey-Server B:
    Zahlung für Session 123456789 wird freigegeben, meine tokeyID ist „nmoihj/87t8g/&“
    BITTE AUF SECURITYCODE WARTEN
    Die Applikation tokey.me meldet dem tokey-Server A
    Meine tokey.me ID ist „jiouh87687 76t67“
    Bitte sende SECURITYCODE zusammen mit der SessionID 123456789 an den tokey-Server B
    Server A sendet an Server B die freigegebenen Daten
    Server B entschlüsselt die Datenblöcke mit dem nur ihm bekannten Schlüssel zu einem Datensatz
    Server B verschlüsselt den Datensatz mit dem Schlüssel von kaufen.de an kaufen.de
    Kaufen.de entschlüsselt den Datensatz und verarbeitet ihn.
  • Bezahlung (fremderöffnete Transaktion)
  • Nach Abschluss eines Kaufes benötigt kaufen.de die Zahlungsinformationen und Zahlungsfreigabe. Hierfür wird wieder um ein v-tokey zur Verfügung gestelltl
  • Kaufen.de hat auf seinem Formular einen externen Link integriert, welcher folgende Daten enthält:
    • • Ich bin kaufen.de
    • • Ich habe folgende SessionID (interne ID von kaufen.de für diese Transaktion)
    • • Ich benötige Zahlungsinformationen und -freigabe für den Betrag 100 für „elekt. Kleinteile“
    • • Ich warte mit dem Service kaufen.de/xy mit der IP 100.100.08.15 auf Antwort
  • Durch Abruf des Formulars und damit Aufrufs des Links wird in der Organisation B die Information verifiziert. Nach positiver Prüfung wird eine Session eröffnet und ein v-tokey mit folgenden Informationen generiert:
    • • Ich bin tokey-Server B und habe einen Anforderung mit der Nummer 123456789 geöffnet
    • • Kaufen.de benötigt Kreditkarteninformationen und Freigabe für 100 €.
  • Zusammen mit dem v-tokey wird die SessionID 123456789 sowie ein Freigabecode 1234 in Worten ausgegeben.
  • Der Anwender startet seine tokey.me Applikation gibt in einem erweiterten Menu die Daten SessionID und FreigabeCode ein. Diese werden an tokey-Server B gesendet.
  • Die Anwendung fragt den Anwender:
    Kaufen.de benötigt von Ihnen folgende Daten: Zahlungsinformationen und -freigabe 100 Euro
    Bitte bestätigen Sie dies.
  • Die Applikation tokey.me meldet dem tokey-Server B:
    Zahlung für Session 123456789 wird frei gegeben, meine tokeyID ist „nmoihj/87t8g/&“
    BITTE WARTEN
    Die Applikation tokey.me meldet dem tokey-Server A
    Meine tokey.me ID ist „jiouh87687 76t67“
    Bitte sende KREDITKARTENINFORMATION zusammen mit der SessionID 123456789 und dem Freigabecode 1234 an den tokey-Server B
    Server A sendet an Server B die freigegebenen Daten
    Server B entschlüsselt die Datenblöcke mit dem nur ihm bekannten Schlüssel zu einem Datensatz
    Server B verschlüsselt den Datensatz mit dem Schlüssel von kaufen.de an kaufen.de
    Kaufen.de entschlüsselt den Datensatz und verarbeitet ihn.
  • Beispiel: Zugangskontrolle (statischer v-tokey)
  • Der Hauseigentümer meinHaus hat sich bei tokey.de angemeldet und für sein Haus Bahnhofstrasse 1 einen v-tokey beantragt
  • Dieser v-tokey enthält folgende Daten und wird am Hauseingang aufgeklebt:
    • • Ich bin meinhaus.de
    • • Ich habe folgende ObjektD (interne ID von meinHaus)
    • • Ich benötige folgende Daten: NAME
    • • Ich warte mit dem Service meinHaus.de/xy mit der IP 100.100.08.15 auf Antwort
  • Der Anwender startet seine tokey.me Applikation und scannt den v-tokey
  • Die Applikation tokey.me meldet dem tokey-Server B:
    Ich benötige Zugang für Objekt 123456789 von meinHaus, meine tokeyID ist „nmoihj/87t8g/&“
    BITTE AUF NAME WARTEN
    tokey-Server B sendet an Anwender zurück: Warte mit SessionID 123456789
    Die Applikation tokey.me meldet dem tokey-Server A
    Meine tokey.me ID ist „jiouh87687 76t67“
    Bitte sende NAME zusammen mit der SessionID 123456789 an den tokey-Server B
    Server A sendet an Server B die freigegebenen Daten
    Server B entschlüsselt die Datenblöcke mit dem nur ihm bekannten Schlüssel zu einem Datensatz
    Server B verschlüsselt den Datensatz mit dem Schlüssel von meinHaus.de an meinHaus.de
    meinHaus.de entschlüsselt den Datensatz, überprüft ihn mit internen Freigaberichtlinien und öffnet.

Claims (11)

  1. Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten und Schlüsseln auf getrennten Systemen und zur Weitergabe der Daten an legitimierte Dritte, wobei sich Dritte mittels einer verschlüsselten und transaktionsbezogenen übertragener Autorisierungsanforderung durch den Anwender für einzelne Transaktionen, wie Registrierung, Login, Zugang, Zahlung oder dergleichen autorisieren lassen.
  2. Verfahren nach Anspruch 1, wobei die personenbezogenen Daten so gespeichert werden, dass sie nur durch ein Zusammenspiel, mehrerer, voneinander unabhängiger Organisation auf Anforderung des Dateneigentümers wieder zusammengestellt werden können.
  3. Verfahren nach Anspruch 1 oder 2, wobei in einer ersten Organisation die Daten verschlüsselt und in verschiedenen Blöcken gespeichert werden.
  4. Verfahren nach einem oder mehreren der vorherigen Ansprüche, wobei in einer zweiten Organisation Schlüssel zur Entschlüsselung der Daten gespeichert und verwaltet werden.
  5. Verfahren nach einem oder mehreren der vorherigen Ansprüche, wobei eine Zuordnung der Daten zu Schlüsseln durch eine, beim Anwender befindliche Software erfolgt.
  6. Verfahren nach einem oder mehreren der vorherigen Ansprüche, wobei es mit einer Identitätsfeststellung verknüpft wird.
  7. Verfahren nach einem oder mehreren der vorherigen Ansprüche, wobei, die Identitätsfeststellung ausgewählt ist aus der Gruppe umfassend Fingerabdruck, Gesichtserkennung, biometrische Verfahren oder ähnlichem.
  8. Verfahren nach einem oder mehreren der vorherigen Ansprüche, wobei, die Daten SSL verschlüsselt sind.
  9. Verfahren nach einem oder mehreren der vorherigen Ansprüche, wobei das Verfahren insbesondere folgende Anwendungen betrifft Eintritt zu Veranstaltungen, Verwaltung von Abonnements, wie z.B. Jahreskarten, PayTV, Homeshopping (dynamischer v-tokey wird auf dem Fernsehbildschirm dargestellt, Bestellung direkt ab Plakat mit statischem v-tokey, Ein/Auschecken von Leistungsangeboten, Legitimationsprüfungen oder Verwahrung von besonders schützenswerten z.B. vertraulichen Dokumenten.
  10. Computerprogrammprodukt zur Durchführung eines Verfahren nach einem oder mehreren der vorherigen Ansprüche zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten und Schlüsseln auf getrennten Systemen und zur Weitergabe der Daten an legitimierte Dritte, wobei sich Dritte mittels einer verschlüsselten und visualisierten transaktionsbezogenen, fototechnisch übertragener Autorisierungsanforderung durch den Anwender für einzelne Transaktionen, wie Registrierung, Login, Zugang, Zahlung oder dergleichen autorisieren lassen.
  11. Personalisiertes Übermittlungsgerät zur Durchführung des Verfahrens nach den Ansprüchen 1 bis 9.
DE201210106081 2012-07-06 2012-07-06 Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten oder Dateien Ceased DE102012106081A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE201210106081 DE102012106081A1 (de) 2012-07-06 2012-07-06 Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten oder Dateien

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE201210106081 DE102012106081A1 (de) 2012-07-06 2012-07-06 Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten oder Dateien

Publications (1)

Publication Number Publication Date
DE102012106081A1 true DE102012106081A1 (de) 2014-01-09

Family

ID=49780599

Family Applications (1)

Application Number Title Priority Date Filing Date
DE201210106081 Ceased DE102012106081A1 (de) 2012-07-06 2012-07-06 Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten oder Dateien

Country Status (1)

Country Link
DE (1) DE102012106081A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014005589A1 (de) 2014-04-15 2014-09-25 Daimler Ag Verfahren zur anonymisierten Übertragung von kraftfahrzeugbezogenen Daten, Computerprogrammprodukt

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014005589A1 (de) 2014-04-15 2014-09-25 Daimler Ag Verfahren zur anonymisierten Übertragung von kraftfahrzeugbezogenen Daten, Computerprogrammprodukt

Similar Documents

Publication Publication Date Title
EP2585963B1 (de) Verfahren zur erzeugung eines zertifikats
DE602004012996T2 (de) Verfahren und vorrichtung zum authentifizieren von benutzern und websites
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
EP2533172B2 (de) Gesicherter Zugriff auf Daten in einem Gerät
DE102019122933A1 (de) Blockchain-basierter austausch digitaler daten
DE60211841T2 (de) Vorrichtung zur Aktualisierung und zum Entzug der Gültigkeit einer Marke in einer Infrastruktur mit öffentlichen Schlüsseln
DE102011082101B4 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
DE102011089580B3 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
EP2245573B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3033855B1 (de) Unterstützung einer entschlüsselung von verschlüsselten daten
DE112018003825T5 (de) Blockchain-berechtigungsprüfung mittels hard/soft-token-überprüfung
EP3031226B1 (de) Unterstützung der nutzung eines geheimen schlüssels
DE112012002741T5 (de) Identitäts- und Berechtigungsprüfungsverfahren für die Sicherheit einer Cloud-Datenverarbeitungsplattform
DE102016100494A1 (de) Sichere Identitätsauthentifizierung in einer elektronischen Transaktion
DE602004003566T2 (de) Verfahren und Vorrichtung zur Identifizierung einer authorisierten Person mittels nicht vorhersagbaren einmal benutzbaren Passwörtern
DE112020000752T5 (de) Sicherer Zugriff auf gespeicherte Datendateien unter Verwendung von Tokens, die in optischen Codes codiert sind
DE102011077218A1 (de) Zugriff auf in einer Cloud gespeicherte Daten
DE112018006031B4 (de) Authentifizieren einer zahlungskarte
DE202018102306U1 (de) Systeme zur persönlichen Identifizierung und Verifizierung
DE202015009601U1 (de) System zur persönlichen Identifizierung und Verifizierung
DE102011077512A1 (de) Verfahren zur sicheren Verarbeitung von in einem elektronischen Safe gespeicherten Daten
DE202015009562U1 (de) System zur persönlichen Identifizierung und Verifizierung
EP2631837B1 (de) Verfahren zur Erzeugung eines Pseudonyms mit Hilfe eines ID-Tokens
DE102014204812A1 (de) Attributwertspezifische Vertrauensniveaus
DE102012106081A1 (de) Verfahren zur verschlüsselten und anonymisierten Verwahrung und Verwaltung von personenbezogenen Daten oder Dateien

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0021000000

Ipc: G06F0021620000

R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final