专利汇可以提供VERFAHREN ZUM LESEN VON ATTRIBUTEN AUS EINEM ID-TOKEN专利检索,专利查询,专利分析的服务。并且Die Erfindung betrifft ein Verfahren zum Lesen von Attributen aus einem ID-Token (106), der einem Nutzer (102) zugeordnet ist. Das Verfahren beinhaltet:
- Senden einer Dienstanforderung (103) von dem Nutzer-Computersystem (100) an ein Dienst-Computersystem (150);
- Senden einer ersten Attributspezifikation (105) von dem Dienst-Computersystem an das ID-Provider-Modul;
- gegenseitige Authentifizierung des ID-Provider-Moduls und des ID-Tokens;
- Schreiben der ersten Attributspezifikation (105) in einen geschützten Speicherbereich des ID-Tokens;
- Senden von einem oder mehreren Klassenidentifikatoren (702) an ein Attribut-Provider-Verzeichnis-Computersystem (199), wobei das Attribut-Provider-Verzeichnis-Computersystem weder zum Lesen der ersten Attributspezifikation von dem ID-Token noch zum Schreiben von Attributen auf das ID-Token berechtigt ist;
- Empfang von ein oder mehreren Identifikatoren (704) durch das Nutzer-Computersystem (100), wobei jeder der Identifikatoren (704) ein Attribut-Provider-Computersystem (172, 1722, 1723, 173, 174) identifiziert, welches dazu ausgebildet ist, nutzerbezogene Attribute der durch den Klassenidentifikator identifizierten Attributklasse bereitzustellen;,下面是VERFAHREN ZUM LESEN VON ATTRIBUTEN AUS EINEM ID-TOKEN专利的具体信息内容。
Die Erfindung betrifft ein Verfahren zum Lesen von Attributen aus einem ID-Token, einen ID-Token und ein Computersystem.
Aus dem Stand der Technik sind verschiedene Verfahren zur Verwaltung der so genannten digitalen Identität eines Benutzers bekannt:
Bei OPENID handelt es sich dagegen um ein Server-basiertes System. Ein so genannter Identity-Server speichert eine Datenbank mit den digitalen Identitäten der registrierten Nutzer. Nachteilig ist hieran unter anderem ein mangelhafter Datenschutz, da die digitalen Identitäten der Nutzer zentral gespeichert werden und das Nutzerverhalten aufgezeichnet werden kann.
Aus
Aus
Der Erfindung liegt demgegenüber die Aufgabe zugrunde, ein verbessertes Verfahren zum Lesen von Attributen aus einem ID-Token zu schaffen einen entsprechenden ID-Token, ein entsprechendes Attribut-Provider-Computersystem, ein entsprechendes Nutzer-Computersystem und Computersystem.
Die der Erfindung zugrunde liegenden Aufgaben werden jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen angegeben. Ausführungsformen der Erfindung sind frei miteinander kombinierbar sofern sie sich nicht gegenseitig ausschließen.
Unter einem "ID-Token" wird hier insbesondere ein tragbares elektronisches Gerät verstanden, welches zumindest einen geschützten elektronischen Datenspeicher zur Speicherung der Attribute und eine Kommunikations-Schnittstelle zum Auslesen der Attribute aufweist. Der Speicherbereich ist geschützt, um zu verhindern, dass das in dem Speicherbereich gespeicherte Attribut in unerlaubter Weise verändert oder ohne die dafür erforderliche Berechtigung ausgelesen wird. Mit anderen Worten kann auf den Speicherbereich nur dann zugegriffen werden, wenn eine hierzu erforderliche Zugriffberechtigung gegeben ist.
Insbesondere kann es sich bei dem ID-Token um einen USB-Stick handeln oder ein Dokument, insbesondere ein Wert- oder Sicherheitsdokument. Unter einem "Dokument" werden erfindungsgemäß papierbasierte und/oder kunststoffbasierte Dokumente verstanden, wie zum Beispiel elektronische Ausweisdokumente, insbesondere Reisepässe, Personalausweise, Visa sowie Führerscheine, Fahrzeugscheine, Fahrzeugbriefe, Firmenausweise, Gesundheitskarten oder andere ID-Dokumente sowie auch Chipkarten, Zahlungsmittel, insbesondere Banknoten, Bankkarten und Kreditkarten, Frachtbriefe oder sonstige Berechtigungsnachweise, in die ein Datenspeicher zur Speicherung des zumindest einen Attributs integriert ist.
Bei dem ID-Token kann es sich um einen Hardwaretoken handeln oder um einen Softtoken, wenn dieser kryptografisch an einen Hardwaretoken, das heißt beispielsweise an ein sogenanntes Secure Element, gebunden ist.
Insbesondere kann ein solcher kryptografisch an ein Secure Element gebundener Softtoken gemäß
Unter einem "ID-Provider-Modul" wird hier ein Programmlogik-Modul verstanden, welches dazu ausgebildet ist, Attribute aus dem ID-Token eines Nutzers auszulesen und eine Attributspezifikation in den ID-Token zu schreiben. Das ID-Provider-Modul kann z.B. als Softwarekomponente oder Computersystem ausgebildet sein. Das ID-Provider-Modul kann z.B. als ID-Provider-Computersystem ausgebildet sein welches vorzugsweise in einem sogenannten Trustcenter betrieben wird, um ein möglichst hohes Maß an Sicherheit zu schaffen. In manchen Ausführungsformen gehören das ID-Provider-Modul und das Dienst-Computersystem zur gleichen IT-Infrastruktur, z.B. zum gleichen Intranet einer Firma. Es ist sogar möglich, dass das ID-Provider-Modul auf dem Dienst-Computersystem installiert und ausgeführt wird, sodass es sich in diesem Fall bei dem ID-Provider-Modul und dem Dienst-Computersystem, bzw. dem auf diesem betriebenen elektronischen Dienst in diesem Fall dann um funktional unterschiedliche, miteinander interoperierende Module handelt. Ein ID-Provider-Modul verfügt z.B. über spezifische Berechtigungsnachweise, z.B. Zertifikate oder kryptographische Schlüssel oder dergleichen, die dem ID-Provider-Modul einen Zugriff auf bestimmte ausgewählte Speicherbereiche eines ID-Tokens erlauben.
Unter einem "Attribut-Provider-Computersystem" wird hier ein Computersystem verstanden, welches dazu ausgebildet ist, Attribute auf Antrage bereitzustellen. Insbesondere kann die Bereitstellung attributklassenspezifisch und/oder spezifisch für einen bestimmten Nutzer eines ID-Tokens erfolgen. Vorzugsweise ist ein Attribut-Provider-Computersystem dazu ausgebildet, eine Attributspezifikation aus dem ID-Token eines Nutzers auszulesen und Attribute in den ID-Token zu schreiben.
Unter einem "Attribut-Provider-Verzeichnis-Computersystem" wird hier ein Computersystem verstanden, welches dazu ausgebildet ist, für bestimmte Klassen von Attributen ein oder mehrere Attribut-Provider-Computersysteme zu identifizieren, welche in der Lage sind, Attribute dieser Klassen vollständig oder zumindest teilweise bereitzustellen. Nach manchen Ausführungsformen können neben der Identität der Attribut-Provider-Computersysteme selbst auch noch weitere Informationen wie z.B. eine Kontaktadresse, Leistungsdaten, historische Verfügbarkeitsdaten bezüglich der jeweiligen Attribut-Provider-Computersysteme identifiziert und an das anfragende System kommuniziert werden.
Bei den Attributklassen kann es sich um (beliebig) vordefinierte Gruppen von Attributen handeln. Die Klassen können disjunkt oder überlappend sein. Beispiele für verschiedene Attributklassen sind: Adressdaten eines Nutzers; medizinische Daten eines Nutzers; Bankdaten eines Nutzers; Informationen, die über die Kreditwürdigkeit eines Nutzers Auskunft geben; und andere.
Unter einem "Attribut" werden hier insbesondere Daten verstanden, die den Nutzer des ID-Tokens oder den ID-Token selbst betreffen, insbesondere Personalisierungsdaten, wie zum Beispiel persönliche Daten des Nutzers, eine Gültigkeitsdauer oder den Herausgeber des ID-Tokens oder eine Zahlungsinformation, wie zum Beispiel Kreditkartendaten oder andere Daten für ein elektronisches Bezahlsystem.
Unter einer "Attributspezifikation" wird hier eine Beschreibung von denjenigen Attributen verstanden, die zum Beispiel von einem Dienst-Computersystem zur Erbringung eines Dienstes benötigt werden. Die Attribute können über Feldnamen von Datenfeldern identifiziert werden, in denen die jeweiligen Attributwerte gespeichert sind, und/oder über ein semantisches Netz, d.h. eine Konvention, wie Attribute systemübergreifend bezeichnet werden.
Unter einem "Dienst-Computersystem" wird hier ein Computersystem verstanden, welches über eine Netzwerk-Schnittstelle zur Verbindung mit dem Netzwerk verfügt, sodass mithilfe eines Internetbrowsers oder eines anderen Anwendungsprogramms auf von dem Dienst-Computersystem gespeicherte oder generierte Internetseiten zugegriffen werden kann. Insbesondere kann es sich bei dem Dienst-Computersystem um einen Internetserver zur Verfügungstellung einer eCommerce- oder eGovernment-Anwendung handeln, insbesondere einen Onlineshop oder einen Behördenserver.
Unter einem "Nutzer-Computersystem" wird hier ein Computersystem verstanden, auf welches der Nutzer Zugriff hat. Hierbei kann es sich zum Beispiel um einen Personal Computer (PC), ein Tablet PC oder ein Mobilfunkgerät, insbesondere ein Smartphone, mit einem üblichen Internetbrowser, wie zum Beispiel Microsoft Internet Explorer, Safari, Google Chrome, Firefox oder einem anderen Anwendungsprogramm zum Zugriff auf das Dienst-Computersystem handeln. Das Nutzer-Computersystem hat eine Schnittstelle zur Verbindung mit dem Netzwerk, wobei es sich bei dem Netzwerk um ein privates oder öffentliches Netzwerk handeln kann, insbesondere das Internet. Je nach Ausführungsform kann diese Verbindung auch über ein Mobilfunknetz hergestellt werden.
Unter einem "Lesegerät" wird hier ein elektronisches Gerät verstanden, welches einen Lesezugriff und auch einen Schreibzugriff auf den ID-Token ermöglicht, insbesondere ein sogenanntes Chipkartenterminal. Das Lesegerät kann einen integralen Bestandteil des Nutzer-Computersystems bilden oder als separate Komponente ausgeführt sein, beispielsweise als Peripheriegerät des Nutzer-Computersystems. Insbesondere kann es sich bei dem Lesegerät um ein sogenanntes Klasse 1, 2 oder 3 Chipkartenlesegerät handeln.
Unter einem "nichtflüchtigen elektronischen Speicher" wird hier ein Speicher zur Speicherung von Daten, insbesondere von Attributen, verstanden, der auch als Non-Volatile Memory (NVM) bezeichnet wird. Insbesondere kann es sich hierbei um ein EEPROM, beispielsweise ein Flash-EEPROM, kurz als Flash bezeichnet, handeln.
Unter einem "geschützten Speicherbereich" wird hier ein Bereich eines elektronischen Speichers verstanden, auf den ein Zugriff, das heißt ein Lesezugriff oder ein Schreibzugriff, von einem mit dem Speicher gekoppelten Prozessor nur dann ermöglicht wird, wenn eine hierzu erforderliche Bedingung erfüllt ist. Hierbei kann es sich zum Beispiel um eine kryptografische Bedingung, insbesondere eine erfolgreiche Authentisierung und/oder eine erfolgreiche Berechtigungsprüfung, handeln.
Unter einem "Prozessor" wird hier eine Logikschaltung verstanden, die zur Ausführung von Programminstruktionen dient. Die Logikschaltung kann auf einem oder mehreren diskreten Bauelementen implementiert sein, insbesondere auf einem Chip.
Unter einem "Zertifikat" wird hier ein digitales Zertifikat verstanden, welches auch als Public-Key-Zertifikat bezeichnet wird. Bei einem Zertifikat handelt es sich um strukturierte Daten, die dazu dienen, einen öffentlichen Schlüssel eines asymmetrischen Kryptosystems einer Identität, wie zum Beispiel einer Person oder einer Vorrichtung, zuzuordnen. Alternativ sind auch Zertifikate basierend auf zero-knowledge Kryptosystemen möglich. Beispielsweise kann das Zertifikat dem Standard X.509 oder einem anderen Standard entsprechen. Beispielsweise handelt es sich bei dem Zertifikat um ein Card Verifiable Certificate (CVC).
In dem Zertifikat kann spezifiziert sein, für welches Attribut oder welche Attribute des Nutzers, die in dem geschützten Speicherbereich des ID-Tokens gespeichert sind, das ID-Provider-Modul bzw. das Attribut-Provider-Computersystem zur Durchführung des Lesezugriffs berechtigt ist. Ferner können auch die jeweiligen Schreibrechte für Attributspezifikationen oder Attribute in einem Zertifikat definiert sein. Ein solches Zertifikat wird auch als Berechtigungszertifikat bezeichnet.
Unter einer "Session" wird hier eine temporäre Kommunikationsverbindung, das heißt eine sog. "Communication Session", insbesondere eine Internet-Session verstanden, die sich gemäß OSI-Schichtmodell auf die Transportschicht ("transport layer") oder die Anwendungsschicht ("application layer") beziehen kann. Insbesondere kann es sich bei einer Session um eine http-Session oder um eine https-Session handeln, wobei bei letzterer der Transportlayer durch eine symmetrische Verschlüsselung geschützt ist.
Unter einem "gesicherten", "geschützten" oder "sicheren" "Übertragungskanal" wird hier ein Übertragungskanal verstanden, der kryptografisch abgesichert ist, um ein Ausspähen und/oder eine Manipulation der Übertragung zu verhindern, wobei hierzu ein sogenanntes Secure-Messaging-Verfahren eingesetzt werden kann. Beispielsweise kann ein geschützter Übertragungskanal zwischen einem ID-Token, z.B. einem Chip, und einem entfernten Computer (z.B. Dienst-Computersystem, Attribut-Providersystem) oder einem lokalen Computer (z.B. Nutzer-Computersystem) aufgebaut werden, z.B. mittels eines PACE Protokolls. Geschützte Verbindungen zwischen Computersystemen können z.B. mittels SSL/TLS aufgebaut werden.
Unter einem "lokalen" geschützten Übertragungskanal wird hier ein gesicherter Übertragungskanal verstanden, der zwischen dem ID-Token und dem Nutzer-Computersystem über das Lesegerät aufgebaut wird, wobei insbesondere die Verbindung zwischen dem ID-Token und dem Lesegerät kontaktbehaftet oder kontaktlos ausgebildet sein kann, letzteres insbesondere gemäß einem NFC- oder RFID-Standard.
Unter Ende-zu-Ende-Verschlüsselung wird hier eine Verschlüsselung übertragener Daten über alle Übertragungsstationen hinweg verstanden. Die zu übertragenden Daten werden auf Senderseite ver- und erst beim Empfänger wieder entschlüsselt. Zwischenstationen können die übertragenen Inhalte nicht entschlüsseln.
In einem Aspekt betrifft die Erfindung ein Verfahren zum Lesen von Attributen aus einem ID-Token, der einem Nutzer zugeordnet ist. Der ID-Token weist einen nichtflüchtigen elektronischen Speicher mit einem geschützten Speicherbereich auf, in dem Attribute gespeichert sind. Ein Zugriff auf den geschützten Speicherbereich ist nur über einen Prozessor des ID-Tokens möglich. Der ID-Token weist eine Kommunikationsschnittstelle zur Kommunikation mit einem Lesegerät eines Nutzer-Computersystems auf. Das Verfahren umfasst folgende Schritte:
Dieses Verfahren kann aus mehreren Gründen vorteilhaft sein:
In einem weiteren vorteilhaften Aspekt wird ein komplexes Kommunikationsprotokoll, das den Datenaustausch zwischen einem ID-Provider-Modul, einem ID-Token und zumindest einem Attribut-Provider-Computersystem auch für ID-Token ermöglicht, bereitgestellt, welches auch durchführbar ist, wenn das ID-Token aufgrund sicherheitstechnischer Beschränkungen oder aufgrund von Beschränkter Rechenleistung der Token-Hardware nicht zur Durchführung eines komplexen Protokolls in der Lage wäre. Die Verarbeitung der Trigger- und Bestätigungssignale, die Initialisierung gegenseitiger Authentifizierungsschritte und Lese- und Schreibzugriffe durch das Attribut-Provider-Computersystem wird von einem - in der Regel hinreichend leistungsfähigen - Nutzer-Computersystem durchgeführt, nicht von dem ID-Token, welches im Besitzt der zu schützenden Daten (Attributspezifikation und später auch der angefragten Attribute) ist. Somit wird ein Verfahren zum Auslesen von Attributen mit einer vorteilhaften Aufgabenteilung bereitgestellt, bei welchem das Nutzer-Computersystem sich für die Koordination der beteiligten Kommunikationspartner (ID-Token, Dienst-Computersystem, ggf. auch Attribut-Provider-Verzeichnis-Computersystem, ein oder mehrere Attribut-Provider-Computersysteme, ID-Provider-Modul) kümmert, wohingegen auf die sensiblen Daten (Attributspezifikationen und Attribute) möglichst immer nur derjenige Kommunikationspartner lesend oder schreibend Zugriff hat, der diese ohnehin schon kennt oder der notwendigerweise in diese Einblick erhalten muss um dem Dienst die angefragten Attribute bereitzustellen. Letzterer Effekt wird an späterer Stelle bei der Beschreibung einzelner Ausführungsformen noch im Detail erläutert.
In einem weiteren Aspekt muss das Nutzer-Computersystem bzw. der ID-Token somit nicht für jede mögliche Attributspezifikation eines Dienstes einen geeigneten Attribut-Provider kennen oder diesen interaktiv vom Nutzer erfragen, der die benötigte Information in der Regel auch nicht besitzen dürfte, da nicht davon auszugehen ist, dass ein Nutzer von SmartCards den Anbietermarkt von Attribut-Providern gut kennt. Somit wird ein vollautomatisches und flexibles Verfahren zum Lesen von Attributen aus einem ID-Token unter Einbeziehung eines oder mehrerer geeigneter, automatisch ermittelter Attribut-Provider-Computersysteme bereitgestellt.
Nach Ausführungsformen erfolgt nach erfolgreicher gegenseitiger Authentifizierung von ID-Provider-Modul und ID-Token ein Aufbau eines ersten geschützten Übertragungskanals mit Ende-zu-Ende-Verschlüsselung zwischen dem ID-Token und dem ID-Provider-Modul über das Netzwerk.
Nach manchen Ausführungsformen wird die Ermittlung der Klassenidentifikatoren durch das Dienst-Computersystem oder durch das ID-Provider-Modul durchgeführt. Die ermittelten Klassenidentifikatoren werden von dem die Ermittlung durchführenden Computersystem an das Nutzer-Computersystem weitergeleitet. So kann das Dienst-Computersystem die Klassenidentifikatoren beispielsweise direkt oder indirekt über das ID-Provider-Modul an das Nutzer-Computersystem kommunizieren. Das Nutzer-Computersystem sendet die übermittelten Klassenidentifikatoren an das Attribut-Provider-Verzeichnis-Computersystem und empfängt in Antwort darauf die Identifikatoren von dem Dienst-Computersystem. Die Adresse des Attribut-Provider-Verzeichnis-Computersystems kann z.B. in dem Nutzer-Computersystem gespeichert und nutzereditierbar sein. Dies kann vorteilhaft sein, da dem Nutzer so die Möglichkeit gegeben wird, einen anderen Attribut-Provider-Verzeichnisdienst auszuwählen.
Nach alternativen Ausführungsformen erfolgt die Ermittlung der Klassenidentifikatoren ebenfalls durch das Dienst-Computersystem oder durch das ID-Provider-Modul. Anstatt die Klassenidentifikatoren jedoch an das Nutzer-Computersystem zu übermitteln, sendet das die Klassenidentifikatoren ermittelnde Computersystem die ermittelten Klassenidentifikatoren an das Attribut-Provider-Verzeichnis-Computersystem, empfängt in Antwort darauf die Identifikatoren der Attribut-Provider-Computersystem von dem Attribut-Provider-Verzeichnis-Computersystem, und übermittelt die ermittelten Identifikatoren (anstatt der Klassenidentifikatoren) an das Nutzer-Computersystem. Dies kann vorteilhaft sein, da das Nutzer-Computersystem somit von der Aufgabe entlastet wird, eine aktuelle Kontaktadresse des Attribut-Provider-Verzeichnis-Computersystems vorzuhalten.
Die Ermittlung der Klassenidentifikatoren durch das Dienst- oder das ID-Provider-Modul kann z.B. durch Analyse der empfangenen ersten Attributspezifikation und Abgleich mit einer vordefinierten Taxonomie der Attributklassen erfolgen.
Nach Ausführungsformen ist ein Applikationsprogramm, das auf dem Nutzer-Computersystem installiert ist, verantwortlich für die Koordination des Aufbaus gesicherter Übertragungskanäle zwischen dem ID-Token und den jeweiligen Attribut-Provider-Computersystemen und dem ID-Provider-Modul, z.B. mittels Protokollumsetzung. Vorzugsweise hat das Nutzer-Computersystem und die auf diesem installierten Applikationsprogramme keinen Zugriff auf die in dem ID-Token gespeicherten ersten und weiteren Attributspezifikationen und hat auch bei der Übertragung einer Attributspezifikation von dem ID-Provider-Modul und/oder bei der Übertragung einer dynamisch ermittelten Attributspezifikation von den einzelnen Attribut-Provider-Computersystemen an das ID-Provider-Modul keinen lesenden oder schreibenden Zugriff auf die Attributspezifikationen, da die Übertragung der Attributspezifikationen jeweils in einem gesicherten Kanal erfolgt. Der geschützte Übertragungskanal kann z.B. als Ende-zu-Ende Übertragungskanal zwischen ID-Token und Attribut-Provider-Computersystem oder als Ende-zu-Ende Übertragungskanal zwischen ID-Token und ID-Provider-Modul ausgebildet sein.
Das Nutzer-Computersystem kann zwar die Wahl des aktuellen Übertragungskanals allein oder in Zusammenarbeit mit dem ID-Token bestimmen, die in dem Kanal übertragenen Daten (Attributspezifikationen und Attribute) sind jedoch vor dem Zugriff durch das Nutzer-Computersystem geschützt. Dies kann die Sicherheit der übertragenen Daten erheblich erhöhen, da auch ein unberechtigter Dritter, der sich Zugang zu dem Nutzer-Computersystem verschafft hat, die übertragenen Attribute und Attributspezifikationen nicht mitlesen kann.
Erfindungsgemäß wird somit auch ermöglicht, dass ein passives ID-Token, welches über einen schwachen Prozessor und eine reduzierte Programmlogik verfügt, dennoch mit einer Vielzahl von dynamisch ermittelten Attribut-Provider-Computersystemen Daten austauschen kann, ohne dass die vom Dienst angefragte Attributspezifikation bzw. die entsprechenden Attribute automatisch allen beteiligten Attribut-Provider-Computersystemen oder dem Nutzer-Computersystem bekannt werden: die Koordination des Datenaustausches zwischen Attribut-Provider-Computersystem und dem ID-Token wird von dem Nutzer-Computersystem durchgeführt, welches allerdings keinen Lese- oder Schreibzugriff auf die übertragenen Attribute oder Attributspezifikation(en) besitzt.
Nach Ausführungsformen verwendet das Nutzer-Computersystem in Antwort auf den Empfang der Identifikatoren einen der empfangenen Identifikatoren, hier als "zweiten Identifikator" bezeichnet, um eine Adresse eines zweiten der Attribut-Provider-Computersysteme zu identifizieren. Das Nutzer-Computersystem sendet ein zweites Triggersignal an die identifizierte Adresse des zweiten Attribut-Provider-Computersystems. Das zweite Triggersignal enthält die zweite Attributspezifikation nicht und auch keine Teile dieser Attributspezifikation oder irgendeiner anderen in dem ID-Token gespeicherten Attributspezifikation.
Dies kann vorteilhaft sein, da es somit nicht erforderlich ist, dass das Nutzer-Computersystem selbst die zweite Attributspezifikation oder Teile davon zu kommunizieren. Vielmehr liest das jeweilige Attribut-Provider-Computersystem die Attributspezifikation über einen geschützten Übertragungskanal aus dem ID-Token aus. Der Aufbau des gesicherten Kanals und das Auslesen erfolgen vorzugsweise nach gegenseitiger Authentifizierung des ID-Tokens und des Attribut-Provider-Computersystems.
Die Adresse des ID-Tokens, die in dem Trigger-Signal enthalten ist, kann z.B. die IP-Adresse des Nutzer-Computersystems, die Adresse des von diesem verwendeten Smartcard-Readers und ggf. ein Slot sein. Damit kann der Attribut-Provider den ID-Token finden. Optional kann die Adresse zudem eine ID eines logischen Kanals des ID-Tokens beinhalten. Der ID-Token entscheidet über den Zugriff auf der Basis der Rechte (nachgewiesen z.B. über Berechtigungszertifikate), die der Attribut-Provider beim Verbindungsaufbau vorweisen kann. Der jeweilige geschützte Kanal zwischen ID-Token und Attribut-Provider-Computersystem wird vorzugsweise vom jeweiligen Attribut-Provider-Computersystem aufgebaut bzw. der Aufbau initialisiert.
In Antwort auf Empfang des zweiten Triggersignals initialisiert das zweite Attribut-Provider-Computersystem unter Verwendung der Adresse des ID-Tokens eine gegenseitige Authentifizierung des zweiten Attribut-Provider-Computersystems und des ID-Tokens. Nach gegenseitiger Authentifizierung des zweiten Attribut-Provider-Computersystems und des ID-Tokens, führt das zweite Attribut-Provider-Computersystem einen Lesezugriff auf den geschützten Speicherbereich des ID-Tokens zum Auslesen und/oder Generieren einer dritten Attributspezifikation durch. Die dritte Attributspezifikation spezifiziert eine Menge derjenigen Attribute der ersten Attributspezifikation, welcher der Attributklasse angehören, zu deren Bereitstellung das zweite Attribut-Provider-Computersystem ausgebildet ist.
In einer beispielhaften Ausführungsform ist es möglich, dass das Dienst-Computersystem oder das ID-Provider-Modul die erste Attributspezifikation entsprechend der darin enthaltenen Attributklassen automatisch in mehrere klassenspezifische Teilspezifikationen aufteilt, die ggf. an das ID-Provider-Modul übermittelt werden und von diesem in dem ID-Token gespeichert werden. Die Speicherung kann z.B. zusammen mit der Speicherung der ersten Attributspezifikation erfolgen, oder die erste Attributspezifikation kann von vorneherein in Form mehrerer Teilspezifikationen (also einer zweiten, dritten, vierten, usw. Attributspezifikation) in dem ID-Token gespeichert werden. In diesem Fall muss die für ein Attribut-Provider-Computersystem relevante Teilspezifikation (für das zweite Attribut-Provider-Computersystem also die dritte Attributspezifikation) nur noch ausgelesen werden.
In einer anderen beispielhaften Ausführungsform wird die zweite Attributspezifikation (und analog auch die dritte und weitere Attributspezifikationen) erst beim oder nach dem Lesezugriff auf das ID-Token durch das jeweilige Attribut-Provider-Computersystem generiert. Die Generierung kann z.B. so erfolgen, dass zunächst die zweite Attributspezifikation gelesen wird und innerhalb dieser selektiv die Attribute durch das zweite Attribut-Provider-Computersystem ermittelt werden, die zu der Klasse von Attributen gehören, die das zweite Attribut-Provider-Computersystem bereitstellen kann. Die Generierung kann z.B. auch so erfolgen, dass zunächst die zweite Attributspezifikation gelesen wird und innerhalb dieser selektiv die Attribute durch das zweite Attribut-Provider-Computersystem ermittelt werden, die zu der Klasse von Attributen gehören, die das zweite Attribut-Provider-Computersystem bereitstellen kann und für die bisher noch von keinem zuvor angefragten Attribut-Provider-Computersystem ein entsprechendes Attribut ermittelt werden konnte. Es ist z.B. möglich, dass mehrere Attribut-Provider-Computersysteme, die dieselben Klasse(n) von Attributen bereitstellen, sequentiell so lange angefragt werden bis alle in einer bestimmten Attributspezifikation spezifizierten Attribute bereitgestellt wurden. Beispielsweise kann bei einer solchen sequentiellen Bereitstellung diejenige Teilmenge der Attributspezifikation, die bisher von keinem angefragten Attribut-Provider-Computersystem bereitgestellt werden konnte, die Teil-Attributspezifikation darstellen, für welche das im nächsten Schritt angefragte Attribut-Provider-Computersystem die darin spezifizierten Attribute ermitteln soll.
Die zweite Attributspezifikation kann je nach Ausführungsform in analoger Weise direkt vom ID-Token gelesen oder als Teilmenge der ersten Attributspezifikation durch das erste Attribut-Provider-Computersystem generiert werden.
In manchen Ausführungsvarianten kann dann die so generierte dritte Attributspezifikation auf das Token geschrieben werden falls das AP2 über entsprechende Schreibrechte verfügt.
Nach Ausführungsformen umfasst das Verfahren ferner:
Nach Ausführungsformen umfasst das Verfahren ferner:
Dies kann vorteilhaft sein, da in dem Fall, dass das ID-Token bereits einige Attribute gespeichert hat, diese nicht noch einmal von einem Attribut-Provider-Computersystem angefragt werden müssen. Somit kann das Verfahren beschleunigt und die zu übertragende Datenmenge reduziert werden.
Nach Ausführungsformen ist das Attribut-Provider-Verzeichnis-Computersystem (APV) dazu ausgebildet, mehrere erste Attribut-Provider-Computersysteme in Antwort auf einen Empfang des ersten Klassenidentifikators zu identifizieren. Das Nutzer-Computersystem empfängt für jedes der mehreren identifizierten ersten Attribut-Provider-Computersysteme einen ersten Identifikator, der das jeweilige erste Attribut-Provider-Computersystem identifiziert.
Das Senden des ersten Triggersignals erfolgt selektiv an dasjenige der identifizierten ersten Attribut-Provider-Computersysteme, welches hinsichtlich eines der folgenden Kriterien einen höheren Wert als die anderen identifizierten ersten Attribut-Provider-Computersysteme aufweist:
In analoger weise kann das Attribut-Provider-Verzeichnis-Computersystem auch mehrere zweite Attribut-Provider-Computersysteme identifizieren, die alle im Prinzip in der Lage sind, alle oder einige der Attribute einer bestimmten Attributklasse bereitzustellen. Das Nutzer-Computersystem empfängt für jedes der mehreren identifizierten zweiten Attribut-Provider-Computersysteme einen zweiten Identifikator, der das jeweilige zweite Attribut-Provider-Computersystem identifiziert. Das Senden des zweiten Triggersignals erfolgt selektiv an dasjenige der identifizierten zweiten Attribut-Provider-Computersysteme, welches hinsichtlich eines der zuvor genannten Kriterien (Vertrauensniveau, verfügbare Ressourcen, etc.) einen höheren Wert als die anderen identifizierten zweiten Attribut-Provider-Computersysteme aufweist.
Dies kann vorteilhaft sein, da die benötigte Zeit zur Bereitstellung sämtlicher Attribute, die der Dienst benötigt, dadurch deutlich verringert werden kann. Außerdem können Belastungsspitzen einzelner Attribut-Provider-Computersysteme vermieden oder reduziert werden, die erforderliche Vertrauenswürdigkeit der Attribute kann spezifisch an die Bedürfnisse eines bestimmten Dienstes angepasst werden und auch eine automatische Berücksichtigung der bisherigen Zuverlässigkeit oder Antwortzeit von angefragten Attribut-Provider-Computersystemen ist möglich.
Nach Ausführungsformen kann jedes der identifizierten ersten Attribut-Provider-Computersysteme lediglich einen Teil der in der zweiten Attributspezifikation spezifizierten Attribute bereitstellen. Das Nutzer-Computersystem veranlasst in mehreren Iterationen jeweils eines der identifizierten ersten Attribut-Provider-Computersysteme dazu, möglichst viele der in der zweiten Attributspezifikation spezifizierten Attribute bereitzustellen und in dem ID-Token zu speichern. Die zeitliche Rangfolge dieser Veranlassung kann z.B. entsprechend der oben genannten Auswahlkriterien erfolgen, sodass z.B. dasjenige Attribut-Provider-Computersystem mit der geringsten Auslastung, höchsten bisherigen Zuverlässigkeit und/oder dem höchsten Vertrauensniveau bezüglich der bereitgestellten Attribute vorrangig zur Bereitstellung von Attributen veranlasst werden. Das Nutzer-Computersystem veranlasst zudem jeweils eines der identifizierten ersten Attribut-Provider-Computersysteme dazu, für die nächste Iteration eine neue Version der zweiten Attributspezifikation in dem ID-Token zu speichern, wobei die neue Version selektiv nur noch diejenigen Attribute der ursprünglichen zweiten Attributspezifikation beinhaltet, die in keiner der bisher durchgeführten Iterationen bereitgestellt wurden. Beispielsweise können die Iterationen bei Erfüllung einer Abbruchbedingung auch automatisch beendet werden. Die Abbruchbedingung kann z.B. die Bereitstellung sämtlicher in der zweiten (bzw. der jeweils aktuellen) Attributspezifikation spezifizierten Attribute, Zeitüberschreitung oder Überschreitung einer Maximalzahl an Iterationen bzw. kontaktierten Attribut-Provider-Computersystemen bestehen.
Auch die Bereitstellung der in der dritten Attributspezifikation spezifizierten Attribute kann in analoger Weise iterativ mithilfe mehrerer zweiten Attribut-Provider-Computersystemen erfolgen.
Beispielsweise kann der Lesezugriff auf die erste Attributspezifikation selektiv nur durch das erste Attribut-Provider-Computersystem möglich sein, sofern dieses über die entsprechenden Leserechte bezüglich des geschützten Speicherbereichs des Tokens hat, wobei die Leserechte auch spezifisch für die Attributspezifikationen bezüglich bestimmter Attributklassen definiert sein können. Beispielsweise kann das erste Attribut-Provider-Computersystem ein Leserecht bezüglich der ersten Attributspezifikation haben, nicht jedoch bezüglich einer zweiten Attributspezifikation, sofern diese sich überhaupt schon in dem Speicher des ID-Tokens befindet.
Die Identifikation und Einbeziehung mehrerer erster und/oder zweiter Attribut-Provider-Computersysteme kann mehrere Vorteile beinhalten: zum einen wird dadurch die Ausfallsicherheit erhöht, falls z.B. eines der Attribut-Provider-Systeme aus technischen oder anderen Gründen aktuell nicht verfügbar ist, die Attribute aber von einem anderen Attribut-Provider-Computersystem bezogen werden können. Eine parallele Anforderung von Attributen bei mehreren Attribut-Provider-Computersystemen gleichzeitig hat den Vorteil, dass die Geschwindigkeit der Attributermittlung erhöht werden kann, insbesondere, wenn die jeweils angeforderten Attributmengen disjunkt sind. Eine sequentielle, iterative Anforderung von Attributen bei mehreren Attribut-Provider-Computersystemen so lange, bis alle Attribute einer bestimmten Klasse oder alle in der ersten Attributspezifikation spezifizierten Attribute ermittelt und in dem ID-Token gespeichert sind, kann vorteilhaft sein, da durch Einbeziehung einer Vielzahl von Attribut-Provider-Computersystemen eine sehr breite Palette an Attributen bereitgestellt werden kann. Dies dient auch dem Datenschutz, denn es ist nun möglich, dass einzelne Attribut-Provider nur einen sehr kleinen Ausschnitt der Attribute einer Person kennen. Beispielsweise verfügt ein Attribut-Provider-Computersystem einer Bank nur über kontobezogene Attribute, dasjenige eines Arztes des Nutzers nur über gesundheitsbezogene Attribute und ein Autoverleih nur über Attribute bezüglich Wohnort, Alter und das Vorliegen einer Fahrerlaubnis für den Nutzer. Es ist also nicht erforderlich, all diese Attribute zentral zu speichern, um dennoch Dienste anfordern zu können, die Auskunft bezüglich einer Vielzahl von Attributen unterschiedlicher Klassen verlangen (Anbieter von Leasing-Verträgen wertvoller Fahrzeugen könnten z.B. Attribute sowohl bezüglich der Fahrerlaubnis als auch bezüglich der Kreditwürdigkeit bzw. Finanzkraft einer Person verlangen).
Nach Ausführungsformen umfasst das Verfahren eine Generierung des ersten Triggersignals, z.B. durch das Nutzer-Computersystem. Die Generierung des Trigger-Signals umfasst:
Beispielsweise kann das erste Attribut-Provider-Computersystem die URL in dem Request nutzen, um sich gegenüber dem in der URL spezifizierten ID-Token zu authentifizieren und nach erfolgreicher Authentifizierung die zweite Attributspezifikation aus dem ID-Token auszulesen oder durch Lesezugriff auf die erste Attributspezifikation und optional auf weitere Daten (z.B. bereits auf dem ID-Token gespeicherte Attribute oder Attribut-Metadaten) die zweite Attributspezifikation lesen oder generieren. Die URL kann genutzt werden um das Nutzer-CS zu finden, das mit einem ID-Token verbunden ist, mit welchem ein geschützter Übertragungskanal zwischen dem ersten Attribut-Provider-Computersystem und dem ID-Token aufgebaut werden kann. Dieser geschützte Übertragungskanal kann sodann dafür verwendet werden um darüber die für die zweite Attributspezifikation ermittelte Attributmenge auf dem ID-Token zu speichern.
Nach Ausführungsformen überträgt das erste Attribut-Provider-Computersystem eine erste Signaturanfrage an das ID-Token um eine digitale Signatur der zweiten Attributspezifikation zu erzeugen. Die Übertragung erfolgt über einen geschützten Datenübertragungskanal. Das ID-Token erzeugt die digitale Signatur der zweiten Attributspezifikation. Vorzugsweise handelt es sich hierbei um eine pseudonyme Signatur, was den Vorteil beinhaltet, dass die Karte nicht identifizierbar ist.
Nach manchen Ausführungsformen prüft das ID-Token, ob das erste Attribut-Provider Computersystem berechtigt ist, eine Signatur anzufordern und/oder berechtigt ist, die Durchführung der Signaturfunktion durch den Prozessor des Tokens zu triggern, und signiert die zweite (bzw. die angefragte) Attributspezifikation nur bei Vorliegen einer entsprechenden Berechtigung.
Das ID-Token übermittelt die erzeugte digitale Signatur, vorzugsweise über einen geschützten Übertragungskanal, an das erste Attribut-Provider-Computersystem. Das erste Attribut-Provider-Computersystem prüft die Signatur mit einem öffentlichen Signaturprüfschlüssel. Die Ermittlung der ersten Menge Attribute gemäß der zweiten Attributspezifikation durch das erste Attribut-Provider-Computersystem und die Speicherung der ersten Menge Attribute in dem ID-Token erfolgt nur, wenn die Prüfung ergibt, dass die digitale Signatur valide ist.
Dies kann vorteilhaft sein, wenn das Attribut-Provider-Computersystem zur Erstellung der Attribute oder für spätere Nachweise der korrekten Attributerstellung gegenüber Dritten nachweisen muss, dass wirklich eine Anfrage eines ID-Tokens vorliegt oder vorgelegen hat. Damit wird der Situation vorgebeugt, dass ein Attribut-Provider-Computersysteme unberechtigterweise Daten in Form von Attributen sammelt, die nicht von ID-Tokens erfragt wurden. Da allerdings bei diesem Vorgehen die Anonymität der Attribute leidet, wird dieses Verfahren vorzugsweise nur dann eingesetzt, wenn der Schutz vor unberechtigten Anfragen bezüglich nutzerspezifischer Attribute wichtiger ist als völlige Anonymität der Attribute.
In analoger weise kann das zweite Attribut-Provider-Computersystem eine zweite Signaturanfrage an den ID-Token übertragen um eine digitale Signatur der dritten Attributspezifikation zu erzeugen. Nach manchen Ausführungsformen prüft das ID-Token, ob das zweite Attribut-Provider Computersystem berechtigt ist, eine Signatur anzufordern und/oder berechtigt ist, die Durchführung der Signaturfunktion durch den Prozessor des Tokens zu triggern, und signiert die dritte (bzw. die angefragte) Attributspezifikation nur bei Vorliegen einer entsprechenden Berechtigung.
Das ID-Token übermittelt die erzeugte digitale Signatur an das zweite Attribut-Provider-Computersystem. Das zweite Attribut-Provider-Computersystem prüft die Signatur mit einem öffentlichen Signaturprüfschlüssel. Die Ermittlung der zweiten Menge Attribute gemäß der dritten Attributspezifikation durch das zweite Attribut-Provider-Computersystem und die Speicherung der zweiten Menge Attribute in dem ID-Token erfolgt nur, wenn die Prüfung ergibt, dass die digitale Signatur valide ist.
Nach manchen Ausführungsformen ist in dem geschützten Speicherbereich des ID-Tokens für jedes der Attribut-Provider-Computersysteme ein eigener privater Signierschlüssel gespeichert, der einem der Attribut-Provider-Computersysteme zugeordnet ist. Jedes der Attribut-Provider-Computersysteme hat Zugriff auf einen öffentlichen Signaturprüfschlüssel, welcher mit dem privaten Signierschlüssel, der dem Attributprovider-Computersystem zugeordnet ist, ein asymmetrisches kryptographisches Schlüsselpaar ausbildet. Der öffentliche Signaturprüfschlüssel ist dazu ausgebildet, eine von dem korrespondierenden privaten Signierschlüssel generierte digitale Signatur auf deren Validität hin zu überprüfen.
Nach Ausführungsformen ist die Kommunikationsschnittstelle des ID-Token zur drahtlosen Kommunikation und zur drahtlosen Einkopplung von Energie in den ID-Token durch das Lesegerät ausgebildet, um den ID-Token mit der für seinen Betrieb erforderlichen elektrischen Energie zu versorgen. Der ID-Token weist einen flüchtigen elektronischen Speicher auf, in dem die zweite und dritte Attributspezifikation gespeichert werden, sodass die zweiten Attributspezifikationen aus dem flüchtigen elektronischen Speicher gelöscht werden, wenn der ID-Token aus der Reichweite des Lesegeräts entfernt wird. Nach Ausführungsformen werden sämtliche im Zuge einer Dienstanforderung von dem Dienst bezüglich des Nutzers generierten (ersten, zweiten, dritten, etc.) Attributspezifikationen ausschließlich in dem flüchtigen Speicher des ID-Token gespeichert.
Ein neuer Protokollablauf ist in diesem Fall zu starten falls das Token vor Bereitstellung aller angeforderten Attribute aus der Reichweite des Lesegeräts entfernt wird. Hierdurch wird vermieden, dass sich der ID-Token in einem undefinierten Zustand befindet, wenn zum Beispiel das Token nach Speicherung der zweiten Attributspezifikation aus der Reichweite des Lesegeräts entfernt wird, um eventuelle Missbrauchsmöglichkeiten hierdurch zu unterbinden.
Die aufgrund des Schreibzugriffs der ersten und zweiten Attribut-Provider-Computersysteme in dem ID-Token gespeicherten ersten und zweiten Mengen der Attribute werden in dem nichtflüchtigen elektronischen Speicher gespeichert, sodass auf diese durch einen nachfolgenden weiteren Lesezugriff aufgrund einer weiteren Dienstanforderung zugegriffen werden kann.
Alternativ dazu werden die zweiten und dritten Attributspezifikationen und die erste und zweite Menge der Attribute in dem nicht-flüchtigen Speicher gespeichert. Wird die zweite Attributspezifikation in den nicht-flüchtigen elektronischen Speicher geschrieben, bleibt auch nach Entfernung des ID-Tokens aus der Reichweite des Lesegeräts die zweite Attributspezifikation im Speicher erhalten.
Nach Ausführungsformen erstellt das ID-Token Signaturen über Attributspezifikationen nur dann, wenn der Nutzer dieser Signatur durch eine PIN-Eingabe zugestimmt hat. In diesem Fall fordert das Lesegerät oder das Nutzer-Computersystem den Nutzer zur Eingabe einer Signatur-PIN für die Freischaltung einer Signaturfunktion des ID-Tokens für die Erzeugung einer digitalen Signatur der zweiten Attributspezifikation und/oder dritten Attributspezifikation auf.
Nach Ausführungsformen erfolgt die Aufforderung zur Eingabe einer Signatur-PIN aufgrund einer ersten Anfrage zur PIN-Eingabe, die das erste Attribut-Provider-Computersystem an den ID-Token (über den geschützten Übertragungskanal) übertragen hat.
In analoger weise kann gemäß manchen Ausführungsformen der Erfindung das zweite Attribut-Provider-Computersystem eine zweite Anfrage zur PIN-Eingabe an das ID-Token übertragen.
Nach Ausführungsformen umfasst das Verfahren ferner einen Aufbau einer ersten Session zwischen dem Nutzer-Computersystem und dem ersten Attribut-Provider-Computersystem. Diese erste Session wird z.B. für die Übertragung des ersten Triggers (beinhaltend die Adressdaten des ID-Tokens) vom Nutzer-Computersystem an das erste Attribut-Provider-Computersystem verwendet. In analoger Weise kann das Verfahren ferner einen Aufbau einer zweiten Session zwischen dem Nutzer-Computersystem und dem zweiten Attribut-Provider-Computersystem beinhalten. Diese zweite Session wird z.B. für die Übertragung des zweiten Triggers (beinhaltend die Adressdaten des ID-Tokens) vom Nutzer-Computersystem an das zweite Attribut-Provider-Computersystem verwendet.
Die Übermittlung der Trigger zur Übertragung der Token-Adressdaten an die jeweiligen Attribut-Provider-Computersysteme kann z.B. parallel erfolgen, was die Geschwindigkeit des Verfahrens erhöht. In analoger Weise kann das Auslesen (oder Generieren) der zweiten und dritten Attributspezifikation durch das erste und zweite Attribut-Provider-Computersystem parallel erfolgen. Dies kann insbesondere dann vorteilhaft sein, wenn die zweite und dritte Attributspezifikation disjunkte Attributmengen spezifizieren.
Die Übermittlung der Trigger (und/oder das Auslesen bzw. Generieren der zweiten und dritten Attributspezifikation) kann in anderen Ausführungsformen jedoch auch sequenziell erfolgen, was insbesondere dann von Vorteil sein kann, wenn die dritte (bzw. zuletzt erstellte) Attributspezifikation nur noch diejenigen Attribute spezifiziert, die in der zweiten (bzw. der im vorhergehenden Auslesezyklus erstellten) Attributspezifikation spezifiziert sind aber von dem ersten Attribut-Provider-Computersystem (bzw. allen zuvor angefragten Attribut-Provider-Computersystemen) nicht bereitgestellt werden konnten. Dies ermöglicht ggf. ein automatisches Beenden der sequentiellen Bereitstellung von Attributen durch die Attribut-Provider-Computersysteme, sobald alle in der ersten Attributspezifikation spezifizierten Attribute auf dem ID-Token gespeichert wurden.
Beispielsweise empfängt das erste Attribut-Provider-Computersystem ein erstes Bestätigungssignal, z.B. über den geschützten Übertragungskanal zwischen dem ersten Attribut-Provider-Computersystem und dem Nutzer-Computersystem im Kontext der ersten Session. Das erste Bestätigungssignal signalisiert das Einverständnis des Nutzers mit der Weiterleitung der signierten oder unsignierten zweiten Attributspezifikation an das erste Attribut-Provider-Computersystem. Zusätzlich oder alternativ dazu empfängt das zweite Attribut-Provider-Computersystem (z.B. über den geschützten Übertragungskanal zwischen dem zweiten Attribut-Provider-Computersystem und dem Nutzer-Computersystem im Kontext der zweiten Session) ein zweites Bestätigungssignal, welches das Einverständnis des Nutzers mit der Weiterleitung der signierten oder unsignierten dritten Attributspezifikation an das zweite Attribut-Provider-Computersystem signalisiert.
Dies kann vorteilhaft sein, da der Benutzer für jede einzelne der Attributspezifikationen bzw. für jedes der ermittelten Attribut-Provider-Computersysteme individuell entscheiden kann, ob die Attributspezifikation wirklich an das aktuell ermittelte Attribut-Provider-Computersystem weitergeleitet werden soll. Dies erhöht den Datenschutz, da bereits eine Attributspezifikation, z.B. eine Spezifikation, dass eine Schufa-Auskunft eingeholt werden soll, eine sehr sensible Information darstellen kann, auch wenn das Attribut selbst (also das Ergebnis der Schufa-Auskunft) gar nicht übertragen wird.
Nach Ausführungsformen wird das Auslesen der zweiten Attributspezifikation durch das erste Attribut-Provider-Computersystem durch die Durchführung eines von zwei Verfahren a) oder b) ermöglicht.
Dies hat den Vorteil, dass das Attribut-Provider-Computersystem die jeweils relevante Attributspezifikation sofort aus dem ID-Token auslesen kann. Dies kann das Verfahren beschleunigen, insbesondere falls die maximal mögliche Lesegeschwindigkeit von auf dem ID-Token gespeicherten Daten oder die Prozessorkapazität des Attribut-Provider-Computersystems gering ist.
Dies kann insbesondere dann vorteilhaft sein, wenn die Attributmengen verschiedener Attributklassen überlappend sind und/oder wenn das Verfahren iterativ unter Einbeziehung mehrerer Attribut-Provider-Computersysteme für die gleiche Attributklasse erfolgt. Um hier eine Doppel-Bereitstellung von Attributen zu vermeiden, kann es vorteilhaft zu sein, diejenigen Attribute zu ermitteln, die nicht bereits von zuvor angefragten Attribut-Provider-Computersystemen bereitgestellt werden konnten.
Optional kann in beiden Verfahren a) und b) zusätzlich die Speicherung der zweiten Attributspezifikation in dem geschützten Speicherbereich des ID-Tokens erfolgen. Falls die in der zweiten Attributspezifikation spezifizierten Attribute in einem iterativen Verfahren durch mehrere erste Attribut-Provider-Computersysteme ermittelt werden, wird in jeder Iteration eine neue Version der zweiten Attributspezifikation, die selektiv diejenigen Attribute der vorhergehenden Version der zweiten Attributspezifikation beinhaltet, die nicht ermittelt wurden, in dem ID-Token gespeichert.
Die Authentifizierung des ID-Provider-Moduls gegenüber dem ID-Token kann z.B. mithilfe eines Berechtigungszertifikats des ID-Provider-Moduls erfolgen. In dem Berechtigungszertifikat können Leserechte des ID-Provider-Moduls zum Lesen von Attributen aus dem ID-Token spezifiziert sein. Der ID-Token führt für die Lesezugriffe des ID-Provider-Moduls eine Prüfung der Leseberechtigung des ID-Provider-Moduls mithilfe des Berechtigungszertifikats durch.
Zusätzlich können in dem Berechtigungszertifikat Schreibrechte des ID-Provider-Moduls zum Schreiben der ersten, zweiten und/oder dritten Attributspezifikation in dem ID-Token spezifiziert sein. Der ID-Token führt für Schreibzugriffe des ID-Provider-Moduls eine Prüfung der Schreibberechtigung des ID-Provider-Moduls mithilfe des Berechtigungszertifikats durch.
Dies kann vorteilhaft sein, da somit sichergestellt werden kann, dass nur vertrauenswürdige und berechtigte ID-Provider-Module schreibend auf den Speicher zugreifen darf um diejenigen Attribute zu spezifizieren, die letztlich an den Dienst kommuniziert werden.
Nach Ausführungsformen erfolgt die Authentifizierung des ersten Attribut-Provider-Computersystems gegenüber dem ID-Token mithilfe eines Berechtigungszertifikats des ersten Attribut-Provider-Computersystems. In dem Berechtigungszertifikat sind Leserechte des ersten Attribut-Provider-Computersystems zum Lesen der ersten und/oder zweiten Attributspezifikation aus dem ID-Token spezifiziert. Der ID-Token führt für den Lesezugriff des ersten Attribut-Provider-Computersystems eine Prüfung der Leseberechtigung des ersten Attribut-Provider-Computersystems mithilfe des Berechtigungszertifikats durch.
In dem Berechtigungszertifikat sind auch Schreibrechte des ersten Attribut-Provider-Computersystems zum Schreiben der ersten Menge der Attribute in dem ID-Token spezifiziert. Der ID-Token führt für den Schreibzugriff des ID ersten Attribut-Provider-Computersystems eine Prüfung der Schreibberechtigung des ersten Attribut-Provider-Computersystems mithilfe des Berechtigungszertifikats durch.
In manchen Ausführungsformen hat das erste Attribut-Provider-Computersystem Leserechte zum Lesen der ersten Attributspezifikation, um daraus die zweite Attributspezifikation (also eine Spezifikation derjenigen Attribute, die es selbst bereitstellen kann oder zu einer bestimmten Attributklasse gehören) und/oder einer dritten Attributspezifikation (z.B. eine Spezifikation aller noch fehlenden und von dem ersten Attribut-Provider-Computersystem nicht bereitstellbaren Attribute) zu generieren und Schreibrechte zum Schreiben der zweiten und ggf. weiterer Attributspezifikationen in dem geschützten Speicherbereich des ID-Tokens. Es hat auch Rechte zum Schreiben von Attributen die in der zweiten Attributspezifikation spezifiziert sind, hat aber z.B. keine Rechte zum Lesen von anderen in dem ID-Token gespeicherten Attributen.
In manchen Ausführungsformen besitzt kein Attribut-Provider-Computersystem Rechte zum Lesen von nutzerbezogenen Attributen aus dem ID-Token. Es kann lediglich (manche oder alle) Attributspezifikationen lesen und die selbst bereitgestellten Attribute in den ID-Token schreiben. Dies kann den Datenschutz erhöhen. In anderen Ausführungsformen haben Attribut-Provider-Computersysteme durchaus Leserechte für auf dem ID-Token gespeicherte Attribute, z.B. um noch nicht ermittelte Attribute einer Attributspezifikation identifizieren zu können.
Die Prüfung von Lese- und Schreibrechten kann z.B. attributklassenspezifisch erfolgen. Jeder ermittelten Attributklasse kann z.B. ein Bereich, auch "Sektor" genannt, auf dem geschützten Speicherbereich des ID-Tokens zugewiesen sein. Das Berechtigungszertifikat kann das Attribut-Provider-Computersystem beispielsweise selektiv zum Schreiben von Attributen einer bestimmten Attributklasse auf einen bestimmten, attributklassenspezifischen Sektor des Speicherbereichs des ID-Tokens berechtigen, wohingegen die Attributspezifikationen in einem anderen Sektor gespeichert werden, auf welchen alle Attribut-Provider-Computersysteme lesend zugreifen können. Alternativ dazu können beispielsweise auch klassenspezifische Attributspezifikationen selektiv auf einem der klassenspezifischen Sektoren gespeichert sein, sodass Attribut-Provider-Computersysteme nur die Attributspezifikationen einsehen und lesen können, die zu einer bestimmten Attributklasse gehören, die von diesem Attribut-Provider-Computersystem auch bereitgestellt werden kann. Dies hat den Vorteil des erhöhten Datenschutzes.
Nach Ausführungsformen enthält der geschützte Speicherbereich des ID-Token mehrere Unterbereiche. Jeder der Unterbereich ist einer der Attributklassen spezifisch zugeordnet. Der ID-Token ermöglicht einen lesenden und/oder schreibenden Zugriff des ersten Attribut-Provider-Computersystems auf einen der Unterbereiche nur dann, wenn das Berechtigungszertifikat des ersten Attribut-Provider-Computersystems einen Nachweis einer Lese- und/oder Schreibberechtigung für diesen Unterbereich beinhaltet. Das Berechtigungszertifikat des ersten Attribut-Provider-Computersystems räumt dem ersten Attribut-Provider-Computersystem eine Berechtigung zum Lesen und/oder Schreiben nur auf denjenigen der Unterbereiche ein, welchem diejenige Attributklasse zugewiesen ist, zu deren Bereitstellung der erste Attribut-Provider ausgebildet ist. Der ID-Token ermöglicht einen schreibenden Zugriff des ersten Attribut-Provider-Computersystems auf den einen Speicherbereich zur Speicherung der ersten Attributmenge nur dann, wenn das Berechtigungszertifikat des ersten Attribut-Provider-Computersystems einen Nachweis einer Schreibberechtigung für diesen Speicherbereich beinhaltet.
Das Berechtigungszertifikat wird beispielsweise von einem (ersten oder zweiten) Attribut-Provider-Computersystem an das ID-Token übermittelt, z.B. im Zuge der Authentifizierung des Attribut-Provider-Computersystems gegenüber dem ID-Token. Das Berechtigungszertifikat kann als CVC Zertifikat (card verifiable certificate) ausgebildet sein. Das Attribut-Provider-Computersystem kann nach Ausführungsformen auf alle Speicherbereiche zugreifen um "seine" (z.B. die zweite oder dritte) Attributspezifikation zu lesen, es kann aber nur auf "seinen" Sektor schreiben um neue Versionen der Attributspezifikation und/oder die ermittelten Attribute zu schreiben.
Nach anderen Ausführungsformen besitzt das Attribut-Provider-Computersystem keine Leserechte auf die Attribut-Spezifikationen anderer Attribut-Provider-Computersysteme.
Nach Ausführungsformen werden vor der Speicherung von Attributen in dem ID-Token die zu schreibenden Attribute auf einem Display des ID-Tokens, des Lesegeräts oder des Nutzer-Computersystems angezeigt. Die zu schreibenden Attribute werden vorzugsweise erst nach Eingabe einer Bestätigung durch den Nutzer durch Betätigung eines Bedienelements des ID-Tokens, des Lesegeräts bzw. des Nutzer-Computersystems in den nichtflüchtigen elektronischen Speicher geschrieben werden. Das Bedienelement kann z.B. ein mechanischer Schalter oder ein auswählbares graphisches Element einer graphischen Benutzerschnittstelle, z.B. ein Button oder Link, sein.
Bei dem ID-Token kann es sich z.B. um ein Wert- oder Sicherheitsdokument handelt, insbesondere ein Ausweisdokument, das heißt ein ID-Dokument, insbesondere einen elektronischen Personalausweis, Reisepass, Führerschein,
Firmenausweis oder ein Zahlungsmittel, wie zum Beispiel eine Banknote, eine Kreditkarte oder einen sonstigen Berechtigungsnachweis, wie zum Beispiel eine Eintrittskarte, einen Frachtbrief oder ein Visum, insbesondere eine Chipkarte, insbesondere mit RFID- und/oder NFC-Schnittstelle.
Nach Ausführungsformen wird die erste Attributspezifikation von dem ID-Provider-Modul an das ID-Token über einen ersten geschützten Übertragungskanal übertragen. Die erste Attributmenge und/oder die zweite Attributspezifikation werden zwischen dem ersten Attribut-Provider-Computersystem und dem ID-Token über einen zweiten geschützten Übertragungskanal kommuniziert. Die zweite Attributmenge und/oder die dritte Attributspezifikation werden zwischen dem zweiten Attribut-Provider-Computersystem und dem ID-Token über einen dritten geschützten Übertragungskanal kommuniziert. Das Nutzer-Computersystem die Kommunikation zwischen dem ID-Token und dem ID-Provider-Modul, dem ersten und den zweiten Attribut-Provider-Computersystem koordiniert. Dies kann z.B. dadurch erfolgen, dass das Nutzer-Computersystem anhand der Bestätigungssignale feststellt, ob und wann ein aktuell angefragtes Attribut-Provider-Computersystem alle von diesem angefragten Attribute erfolgreich auf dem ID-Token gespeichert hat. In diesem Fall kann der geschützte Übertragungskanal zu diesem Attribut-Provider-Computersystem geschlossen oder inaktiv gesetzt werden und eine gegenseitige Authentifizierung eines weiteren Attribut-Provider-Computersystems mit dem ID-Token sowie im Anschluss daran ein Aufbau eines geschützten Übertragungskanals zwischen dem weiteren Attribut-Provider-Computersystem und dem ID-Token initialisiert werden. Daten, die über den ersten, zweiten oder dritten geschützten Übertragungskanal übertragen werden, sind hierbei vor dem Zugriff des Nutzer-Computersystems geschützt.
In einem weiteren Aspekt betrifft die Erfindung ein ID-Token. Der ID-Token kann einem Nutzer zugeordnet sein. Der ID-Token weist einen elektronischen Speicher mit einem geschützten Speicherbereich auf, in dem Attribute gespeichert sind, wobei ein Zugriff auf den geschützten Speicherbereich nur über einen Prozessor des ID-Tokens möglich ist. Der ID-Token weist eine Kommunikationsschnittstelle zur Kommunikation mit einem Lesegerät eines Nutzer-Computersystems auf, wobei das Nutzer-Computersystem an ein ID-Provider-Modul über ein Netzwerk gekoppelt ist. Wobei der ID-Token zur Durchführung der folgenden Schritte konfiguriert ist:
Die Verwendung eines Attribut-Provider-Computersystem-spezifischen Berechtigungszertifikats kann vorteilhaft sein, da eine Vielzahl von Attributen über ein vereinheitlichtes Verfahren bereitgestellt werden können, die nicht durch einen einzigen Attributprovider zentral vorgehalten werden müssen, sondern vielmehr von einer Vielzahl unterschiedlicher Attribut-Provider unabhängig voneinander verwaltet und bereitgestellt werden können. Dies reduziert die Probleme, die bei der Verwendung eines einzelnen zentralen Attribut-Provider-Systems häufig auftreten, nämlich das Problem, dass die zentral gespeicherten Attribute oftmals veraltet sind, weil die Übermittlung aktualisierter Attribute (Änderungen der Kreditwürdigkeit, der Wohnadresse, der Erlaubnis zum Führen eines Fahrzeugs etc.) oftmals nur zeitverzögert, unvollständig oder aus Datenschutzgründen überhaupt nicht von behördlichen Zweigstellen oder privaten Stellen an einen zentralen Server übermittelt werden. Erfindungsgemäß wird gar nicht erst der Versuch gemacht, alle Attribute eines Nutzers, die für Dienste möglicherweise relevant sind, zentral zu speichern. Vielmehr wird ein einheitliches Verfahren bereitgestellt, dass die Bereitstellung dezentral und verteilt gespeicherter Attribute an einen Dienst ermöglicht, und das in einer möglichst effizienten Weise, die dem Nutzer möglichst hohen Schutz bezüglich der Anonymität seiner Daten bzw. bezüglich des angefragten Dienstes bietet.
Nach Ausführungsformen ist der ID-Token dazu ausgebildet, sich mit einer Vielzahl von Attribut-Provider-Computersystemen, die jeweils zur Bereitstellung von Attributen einer bestimmten Attributklasse ausgebildet sind, gegenseitig zu authentifizieren. Der ID-Token empfängt hierbei von dem sich authentifizierenden Attribut-Provider-Computersystemen ein Attribut-Provider-Computersystemen-spezifisches Berechtigungszertifikat. Der ID-Token ist dazu konfiguriert, einen Lesezugriff zum Lesen einer Attributspezifikation von dem geschützten Speicherbereich und/oder einen Schreibzugriff zum Schreiben von Attributen in den geschützten Speicherbereich nur dann zu erlauben, falls das Berechtigungszertifikat diesen Lese- und /oder Schreibzugriff erlaubt.
Vorzugsweise ist die Kommunikationsschnittstelle des ID-Token zur drahtlosen Kommunikation und zur drahtlosen Einkopplung von Energie in den ID-Token durch das Lesegerät ausgebildet, um den ID-Token mit der für seinen Betrieb erforderlichen elektrischen Energie zu versorgen. Der ID-Token weist einen flüchtigen elektronischen Speicher auf.
Der ID-Token ist so konfiguriert, dass die zweite Attributspezifikation in dem flüchtigen elektronischen Speicher gespeichert wird, sodass die zweite Attributspezifikation aus dem flüchtigen elektronischen Speicher gelöscht wird, wenn der ID-Token aus der Reichweite des Lesegeräts entfernt wird. Die aufgrund des Schreibzugriffs des ersten Attribut-Provider-Computersystems in dem ID-Token gespeicherten Attribute werden in dem nichtflüchtigen elektronischen Speicher gespeichert, sodass auf diese durch einen nachfolgenden weiteren ersten Lesezugriff aufgrund einer weiteren Dienstanforderung zugegriffen werden kann.
In einem weiteren Aspekt betrifft die Erfindung ein Attribut-Provider-Computersystem mit einer Netzwerk-Schnittstelle (138) zum Zugriff auf einen ID-Token über ein Netzwerk. Das Attribut-Provider-Computersystem ist zur Durchführung der folgenden Schritte konfiguriert:
Das Attribut-Provider-Computersystem kann ferner zur Durchführung der folgenden Schritte konfiguriert sein:
Nach Ausführungsformen besitzt das Attribut-Provider-Computersystem ein Berechtigungszertifikat zur Authentifizierung gegenüber dem ID-Token. In dem Berechtigungszertifikat sind Rechte des Attribut-Provider-Computersystems zum Lesen der zweiten Attributspezifikation aus dem ID-Token und zum Schreiben von Attributen in den ID-Token spezifiziert.
In einem weiteren Aspekt betrifft die Erfindung ein Nutzer-Computersystem, das mit einem ID-Provider-Modul und mit einem Dienst-Computersystem über ein Netzwerk verbunden ist. Das Nutzer-Computersystem beinhaltet ein Lesegerät zum Zugriff auf einen geschützten Speicherbereich eines ID-Tokens. Ein Zugriff auf den geschützten Speicherbereich ist nur über einen Prozessor des ID-Tokens möglich. Der ID-Token weist eine Kommunikationsschnittstelle zur Kommunikation mit dem Lesegerät auf. Das ID-Token ist dazu konfiguriert, einen ersten geschützten Übertragungskanal mit dem ID-Provider-Modul auszubilden. Das Nutzer-Computersystem ist zur Durchführung der folgenden Schritte ausgebildet:
Nach Ausführungsformen ist der ID-Token frei von einer software- oder hardwarebasierten Programmlogik, die dazu ausgebildet ist, in Abhängigkeit vom Inhalt des geschützten Speicherbereiches den Aufbau neuer oder die Aktivierung bestehender Kommunikationskanäle zu dem Nutzer-Computersystem, dem ID-Provider-Modul, dem APV-Computersystem und/oder einem AP-Computersystem zu initiieren. Dennoch können auch diese ID-Token verwendet werden, da die Protokollumsetzung wie beschrieben durch die Interaktion anderer Komponenten (Nutzer-CS, Dienst-CS, AP, APV ermöglicht wird).
In einem weiteren Aspekt betrifft die Erfindung ein Computersystem mit einem ID-Token gemäß einer der hier beschriebenen Ausführungsformen, mit einem ersten und einem zweiten Attribut-Provider-Computersystem gemäß einer der hier beschriebenen Ausführungsformen, mit einem Nutzer-Computersystem gemäß einer der hier beschriebenen Ausführungsformen und mit einem ID-Provider-Modul.
Im Weiteren werden Ausführungsformen der Erfindung mit Bezugnahme auf die Zeichnungen näher erläutert. Es zeigen:
Elemente der nachfolgenden Ausführungsformen, die einander gleichen oder einander entsprechen, sind jeweils mit identischen Bezugszeichen gekennzeichnet.
Die
Das Nutzer-Computersystem 100 hat zumindest einen Prozessor 110 zur Ausführung von Programminstruktionen 112 sowie eine Netzwerk-Schnittstelle 114 zur Kommunikation über ein Netzwerk 116. Bei dem Netzwerk kann es sich um ein Computernetzwerk, wie zum Beispiel das Internet, handeln.
Der ID-Token 106 hat einen elektronischen Speicher 118 mit geschützten Speicherbereichen 120, 122 und 124. Der geschützte Speicherbereich 120 dient zur Speicherung eines Referenzwerts, der für die Authentifizierung des Nutzers 102 gegenüber dem ID-Token 106 benötigt wird. Bei diesem Referenzwert handelt es sich beispielsweise um eine Kennung, insbesondere eine so genannte Personal Identification Number (PIN), oder um Referenzdaten für ein biometrisches Merkmal des Nutzers 102, welches für die Authentifizierung des Nutzers gegenüber dem ID-Token 106 verwendet werden kann.
Der geschützte Bereich 122 dient z.B. zur Speicherung eines privaten Schlüssels und der geschützte Speicherbereich 124 dient z.B. zur Speicherung von Attributen, zum Beispiel des Nutzers 102, wie zum Beispiel dessen Name, Wohnort, Geburtsdatum, Geschlecht, und/oder von Attributen, die den ID-Token selbst betreffen, wie zum Beispiel die Institution, die den ID-Token erstellt oder ausgegeben hat, die Gültigkeitsdauer des ID-Tokens, einen Identifikator des ID-Tokens, wie zum Beispiel eine Passnummer oder eine Kreditkartennummer. Die Adressdaten des Nutzers können beispielsweise einer anderen Attributklasse angehören als die Attribute, die den ID-Token näher spezifizieren.
Der elektronische Speicher 118 kann ferner einen Speicherbereich 126 zur Speicherung eines Zertifikats aufweisen. Das Zertifikat beinhaltet einen öffentlichen Schlüssel, der dem in dem geschützten Speicherbereich 122 gespeicherten privaten Schlüssel zugeordnet ist. Das Zertifikat kann nach einem Public Key Infrastruktur (PKI) Standard erstellt worden sein, beispielsweise nach dem X.509 Standard.
Das Zertifikat muss nicht zwangsläufig in dem elektronischen Speicher 118 des ID-Tokens 106 gespeichert sein. Alternativ oder zusätzlich kann das Zertifikat auch in einem öffentlichen Verzeichnisserver gespeichert sein.
Der ID-Token 106 hat einen Prozessor 128. Der Prozessor 128 dient zur Ausführung von Programminstruktionen 130, 132 und 134. Die Programminstruktionen 130 dienen zur Nutzerauthentifizierung, d.h. zur Authentifizierung des Nutzers 102 gegenüber dem ID-Token.
Bei einer Ausführungsform mit PIN gibt der Nutzer 102 seine PIN zu seiner Authentifizierung ein, beispielsweise in das Nutzer-Computersystem 100. Durch Ausführung der Programminstruktionen 130 wird dann auf den geschützten Speicherbereich 120 zugegriffen, um die eingegebene PIN mit dem dort gespeicherten Referenzwert der PIN zu vergleichen. Für den Fall, dass die eingegebene PIN mit dem Referenzwert der PIN übereinstimmt, gilt der Nutzer 102 als authentifiziert.
Alternativ wird ein biometrisches Merkmal des Nutzers 102 erfasst. Beispielsweise hat der ID-Token 106 hierzu einen Fingerabdrucksensor oder ein Fingerabdrucksensor ist an das Nutzer-Computersystem 100 angeschlossen. Die von dem Nutzer 102 erfassten biometrischen Daten werden durch Ausführung der Programminstruktionen 130 bei dieser Ausführungsform mit den in dem geschützten Speicherbereich 120 gespeicherten biometrischen Referenzdaten verglichen. Bei hinreichender Übereinstimmung der von dem Nutzer 102 erfassten biometrischen Daten mit den biometrischen Referenzdaten gilt der Nutzer 102 als authentifiziert.
Die Programminstruktionen 134 dienen zur Ausführung der den ID-Token 106 betreffenden Schritte eines kryptographischen Protokolls zur Authentifizierung eines ID-Provider-Moduls 136 gegenüber dem ID-Token 106. Bei dem kryptographischen Protokoll kann es sich um ein Challenge-Response-Protokoll basierend auf einem symmetrischen Schlüssel oder einem asymmetrischen Schlüsselpaar handeln.
Beispielsweise wird durch das kryptographische Protokoll ein Extended Access Control-Verfahren implementiert, wie es für maschinenlesbare Reisedokumente (machine-readable travel documents - MRTD) von der internationalen Luftfahrtbehörde (ICAO) spezifiziert ist. Durch erfolgreiche Ausführung des kryptographischen Protokolls authentifiziert sich das ID-Provider-Modul 136 gegenüber dem ID-Token und weist dadurch seine Leseberechtigung zum Lesen der in dem geschützten Speicherbereich 124 gespeicherten Attribute nach. Die Authentifizierung kann auch gegenseitig sein, d.h. auch der ID-Token 106 muss sich dann gegenüber dem ID-Provider-Modul 136 nach demselben oder einem anderen kryptographischen Protokoll authentifizieren.
Die Programminstruktionen 132 dienen zur Ende-zu-Ende-Verschlüsselung von zwischen dem ID-Token 106 und dem ID-Provider-Modul 136 übertragenen Daten, zumindest aber der von dem ID-Provider-Modul 136 aus dem geschützten Speicherbereich 124 ausgelesenen Attribute. Für die Ende-zu-Ende-Verschlüsselung kann ein symmetrischer Schlüssel verwendet werden, der beispielsweise anlässlich der Ausführung des kryptographischen Protokolls zwischen dem ID-Token 106 und dem ID-Provider-Modul 136 vereinbart wird.
Alternativ zu der in der
Das ID-Provider-Modul 136 hat eine Netzwerk-Schnittstelle 138 zur Kommunikation über das Netzwerk 116. Das ID-Provider-Modul 136 hat ferner einen Speicher 140, in dem ein privater Schlüssel 142 des ID-Provider-Moduls 136 sowie das entsprechende Zertifikat 144 gespeichert ist. Auch bei diesem Zertifikat kann es sich beispielsweise um ein Zertifikat nach einem PKI-Standard, wie zum Beispiel X.509 handeln.
Das ID-Provider-Modul 136 hat ferner zumindest einen Prozessor 145 zur Ausführung von Programminstruktionen 146 und 148. Durch Ausführung der Programminstruktionen 146 werden die das ID-Provider-Modul 136 betreffende Schritte des kryptographischen Protokolls ausgeführt. Insgesamt wird also das kryptographische Protokoll durch Ausführung der Programminstruktionen 134 durch den Prozessor 128 des ID-Tokens 106 sowie durch Ausführung der Programminstruktionen 146 durch den Prozessor 145 des ID-Provider-Moduls 136 implementiert.
Die Programminstruktionen 148 dienen zur Implementierung der Ende-zu-Ende-Verschlüsselung auf Seiten des ID-Provider-Moduls 136, beispielsweise basierend auf dem symmetrischen Schlüssel, der anlässlich der Ausführung des kryptographischen Protokolls zwischen dem ID-Token 106 und dem ID-Provider-Modul 136 vereinbart worden ist. Prinzipiell kann jedes an sich vor bekannte Verfahren zur Vereinbarung des symmetrischen Schlüssels für die Ende-zu-Ende-Verschlüsselung verwendet werden, wie zum Beispiel ein Diffie-Hellman-Schlüsselaustausch.
Das ID-Provider-Modul 136 befindet sich vorzugsweise in einer besonders geschützten Umgebung, insbesondere in einem so genannten Trust-Center, sodass das ID-Provider-Modul 136 in Kombination mit der Notwendigkeit der Authentifizierung des Nutzers 102 gegenüber dem ID-Token 106 den Vertrauensanker für die Authentizität der aus dem ID-Token 106 ausgelesenen Attribute bildet.
Ein Dienst-Computersystem 150 kann zur Entgegennahme einer Bestellung oder eines Auftrags für eine Dienstleistung oder ein Produkt, insbesondere eine Online-Dienstleistung, ausgebildet sein. Beispielsweise kann der Nutzer 102 online über das Netzwerk 116 ein Konto bei einer Bank eröffnen oder eine andere Finanz- oder Bankdienstleistung in Anspruch nehmen. Das Dienst-Computersystem 150 kann auch als Online-Warenhaus ausgebildet sein, sodass der Benutzer 102 beispielsweise online ein Mobiltelefon oder dergleichen erwerben kann. Ferner kann das Dienst-Computersystem 150 auch zur Lieferung von digitalen Inhalten ausgebildet sein, beispielsweise für den Download von Musik- und/oder Videodaten oder als Behördenserver für eine eGovernment Anwendung.
Das Dienst-Computersystem 150 hat hierzu eine Netzwerk-Schnittstelle 152 zur Verbindung mit dem Netzwerk 116. Ferner hat das Dienst-Computersystem 150 zumindest einen Prozessor 154 zur Ausführung von Programminstruktionen 156. Durch Ausführung der Programminstruktionen 156 werden beispielsweise dynamische HTML-Seiten generiert, über die der Nutzer 102 seinen Auftrag oder seine Bestellung eingeben kann.
Je nach der Art des beauftragten oder bestellten Produkts oder der Dienstleistung muss das Dienst-Computersystem 150 Attribute des Nutzers 102 und/oder dessen ID-Token 106 anhand eines oder mehrerer vorgegebener Kriterien überprüfen. Nur wenn diese Prüfung bestanden wird, wird die Bestellung oder der Auftrag des Nutzers 102 entgegengenommen und/oder ausgeführt.
Beispielsweise ist es für die Eröffnung eines Bankkontos oder den Kauf eines Mobiltelefons mit einem dazugehörigen Vertrag erforderlich, dass der Nutzer 102 seine Identität gegenüber dem Dienst-Computersystem 150 offenbart, und dass diese Identität überprüft wird. Im Stand der Technik muss der Nutzer 102 hierzu beispielsweise seinen Personalausweis vorlegen. Dieser Vorgang wird durch das Auslesen der digitalen Identität des Nutzers 102 aus seinem ID-Token 106 ersetzt.
Je nach Anwendungsfall können für die Erbringung des Dienstes weitere Attribute erforderlich sein, die in dem ID-Token zunächst nicht vorhanden sind. Hierzu kann das in der
Zur Inanspruchnahme eines von dem Dienst-Computersystem 150 zur Verfügung gestellten Dienstes wird beispielsweise wie folgt vorgegangen:
Um den oben genannten geschützten Übertragungskanal vom Dienst-Computersystem zum ID-Token aufzubauen, können mehrere Schritte notwendig sein. So kann das Nutzer-Computersystem 100 den Nutzer 102 dazu auffordern, sich gegenüber dem ID-Token 106 zu authentifizieren. Hierzu gibt der Nutzer 102 seine PIN zum Beispiel über das Lesegerät 101 oder eine Tastatur des Nutzer-Computersystems 100 ein. Zur Verifikation der PIN wird zwischen dem Nutzer-Computersystem 100, das heißt dessen Lesegerät 101, und dem ID-Token 106 ein lokaler gesicherter Übertragungskanal SM[PACE] aufgebaut, beispielsweise mithilfe eines Diffie-Hellman Schlüsselaustausches, insbesondere nach dem vom Bundesamt für Sicherheit in der Informationsverarbeitung (BSI) spezifizierten PACE-Protokoll. Über das Nutzer-Computersystem 100 baut der ID-Provider-Modul 136 einen geschützten Übertragungskanal SM[CA]#1 über das Netzwerk 116 auf, über den sich das ID-Provider-Modul 136 gegenüber dem ID-Token 106 authentifiziert, und zwar unter Verwendung des Zertifikats 144.
Bei dem ID-Provider-Modul des Dienst-CS kann es sich um eine integrale Komponente des Dienst-Computersystems oder eine externe Komponente handeln die mit dem Dienst-CS interoperabel ist. Nach Ausführungsformen verwendet jedes der Attribut-Provider-Computersysteme ebenfalls jeweils ein ID-Provider-Modul (das als interne oder externe Komponente des Attribut-Provider-Computersystems ausgebildet sein kann), zum Datenaustausch mit dem ID-Token. Dabei verwenden die Attribut-Provider-Computersysteme jeweils andere ID-Provider-Module als das Dienst-CS um den Datenschutz der ausgetauschten Attribute und Attributspezifikationen zu gewährleisten.
Gemäß einer Ausführungsform ist der geschützte Speicher des ID-Tokens in verschiedene Sektoren untergliedert, wobei jeder Sektor einer bestimmten Attributklasse zugeordnet ist und wobei die Lese-und Schreibrechte für die einzelnen Attribut-Provider-Computersysteme auf einzelne Sektoren beschränkt sind. Vorzugsweise speichert das ID-Provider-Modul die zweite AR1, dritte AR2 und vierte AR3 Attributspezifikation selektiv jeweils in einem Sektor, welcher der gleichen Klasse zugeordnet ist wie die jeweilige Attributspezifikation. Ein Attribut-Provider-Computersystem, das Attribute einer bestimmten Attributklasse bereitstellt, kann in diesem Fall vorzugsweise nur auf die Attributspezifikation(en) zugreifen, die in dem Sektor des Speichers des ID-Tokens gespeichert sind, welcher der gleichen Attributklasse zugewiesen ist.
Die Kommunikation zwischen dem Nutzer-Computersystem 100 und dem ID-Token 106 erfolgt vorzugsweise über den lokalen Übertragungskanal SM[PACE]. Die Kommunikation zwischen dem ID-Token und dem ID-Provider-Modul 136 erfolgt über einen ersten geschützten Übertragungskanal SM[CA]#1. Die Kommunikation zwischen dem ID-Token und jeweils einem der Attribut-Provider-Computersysteme 172, 173, 174 erfolgt jeweils über einen entsprechenden zweiten SM[CA]#2, dritten SM[CA]#3 und vierten SM[CA]#4 geschützten Übertragungskanal.
In manchen Ausführungsformen ist es möglich, dass das Nutzer-Computersystem nach Erhalt eines Bestätigung-Signals von einem der Attribut-Provider-Computersysteme zunächst den ersten geschützten Übertragungskanal SM[CA]#1 aktiviert, um dem ID-Provider-Modul 136 ein sofortiges Auslesen der von diesem einen Attribut-Provider-Computersysteme ermittelten Attribute zur Übertragung an das Dienst-Computersystem zu ermöglichen. Nach einem erfolgreichen auslesen einer Teilmenge A1, A2, A3 der Attribute sendet das ID-Provider-Modul jeweils ein Umschaltbindesignal an das Nutzer-Computersystem. Daraufhin initialisiert das Nutzer-Computersystem die gegenseitige Authentifizierung von ID-Token und einem der Attribut-Provider-Computersysteme, die bisher noch nicht angefragt wurden. Nach erfolgreicher gegenseitiger Authentifizierung wird für dieses Attribut-Provider-Computersystem ein geschützter Übertragungskanal SM[CA]#2, SM[CA]#3 SM[CA]#4 aufgebaut wie zuvor beschrieben. Dieser geschützte Übertragungskanal wird zum aktiven Kanal, der erste sichere SM[CA]#1 zu dem ID-Provider-Modul wird dadurch zu einem inaktiven Übertragungskanal. Ein inaktiver Übertragungskanal ist ein Kanal, für welchen eine Sitzung und eine gesicherte, zum Beispiel verschlüsselte Verbindung aufrechterhalten wird, obwohl dieser Kanal nicht aktuell zur Datenübertragung genutzt wird. Ein aktiver Kanal ist ein Kanal, der aktuell für die Datenübertragung genutzt wird. Der Übertragungskanal kann also durch ein Umschaltkommando sehr schnell und ressourcenschonend wieder aktiviert werden, ohne dass neue Sitzungsschlüssel ausgehandelt werden müssen. Bei diesem sequenziellen bereitstellen von Attributmengen A1, A2, A3 und dem sofortigen auslesen dieser Attributmengen unmittelbar nach deren Bereitstellung durch das ID-Provider-Modul aktiviert und deaktiviert das Nutzer-Computersystem den ersten sicheren Kanal zu dem ID-Provider-Modul in Abhängigkeit vom Empfang von Umschaltsignalen von dem ID-Provider-Modul und in Abhängigkeit vom Empfang von Bestätigungs-Signalen S1, S2, S3 von den jeweiligen Attribut-Provider-Computersystemen. Dies beschleunigt das Verfahren, da keine neuen Sitzungsschlüssel zur Etablierung des ersten geschützten Übertragungskanals zwischen IT-Token und ID-Provider-Modul ausgehandelt werden müssen, was insbesondere angesichts der begrenzten Prozessorleistung vieler ID-Token von großem Vorteil sein kann.
In manchen Ausführungsformen generiert das erste Attribut-Provider-Computersystem 172 eine Signaturanfrage zur Erzeugung einer digitalen Signatur der zweiten Attributspezifikation AR1 und sendet diese Signaturanfrage an das Nutzer-Computersystem 100. Dies kann über die bestehende sichere Verbindung SM[CA]#2 erfolgen. Zusätzlich kann das erste Attribut-Provider-Computersystem optional zuvor bei dem Nutzer über das Nutzer-Computersystem anfragen, ob der Nutzer 102 die Signaturanforderung genehmigt. Falls dies der Fall ist, erfolgt neben der Versendung der Signaturanfrage von dem ersten Attribut-Provider-Computersystem 172 an den ID-Token das Nutzer-Computersystem 100 nach einer Zustimmung zur Signatur.
Das Nutzer-Computersystem 100 leitet die Signaturanfrage des ersten Attribut-Provider-Computersystems über den lokalen geschützten Übertragungskanal, auf welchen der ID-Token 106 zuvor aufgrund des zweiten Umschaltkommandos umgeschaltet hatte, weiter, sodass der ID-Token 106 anschließend die digitale Signatur der dritten Attributspezifikation 178 erzeugt, und zwar durch Ausführung von Programminstruktionen 135 durch den Prozessor 128 des ID-Tokens 106, welcher einen Generator zur Erzeugung digitalen Signaturen bilden, wobei dies unter Verwendung zum Beispiel des privaten Schlüssels 122 erfolgt. Optional wird zuvor von dem Nutzer 102 die Signatur-PIN abgefragt, um die Ausführung der Programminstruktionen 135 freizuschalten. Dies kann zum Beispiel über eine Nutzerschnittstelle, wie zum Beispiel eine Tastatur des Nutzer-Computersystems 100 oder des Lesegeräts 101 erfolgen. Zur Freischaltung der Ausführung der Programminstruktionen 135 prüft der ID-Token 106, ob die von dem Nutzer 102 eingegebene Kennung mit dem in dem Speicher 118 gespeicherten Referenzwert für die Signatur-PIN (SPIN), der in dem geschützten Speicherbereich 121 gespeichert ist, übereinstimmt.
Der ID-Token 106 sendet die signierte zweite Attributspezifikation an das erste Attribut-Provider-Computersystem 172. Das erste Attribut-Provider-Computersystem 172 prüft die Validität der Signatur und ermittelt die darin spezifizierten Attribute nur dann, wenn die Prüfung ergibt, dass die Signatur valide ist.
In analoger Weise können auch die weiteren Attribut-Provider-Computersysteme eine Signatur der jeweils gelesenen Attributspezifikationen erfordern.
Das ID-Provider-Modul 136 verfügt nach einer erfolgreichen Durchführung der oben genannten Verfahrensschritte in seinem Speicher 140 über sämtliche der Attribute, die mit der ersten Attributspezifikation 105 angefordert worden sind. Das ID-Provider-Modul 136 generiert daraufhin eine Nachricht 180, die diese Attribute beinhaltet, signiert diese Nachricht und sendet sie über das Netzwerk 116 an das Dienst-Computersystem 150, wobei dies über das Nutzer-Computersystem 100 erfolgen kann. Das Dienst-Computersystem 150 kann dann gegebenenfalls mithilfe der in der Nachricht 180 beinhalteten Attribute den mit der Dienstanforderung 103 angeforderten Dienst erbringen. Alternativ dazu kann die Nachricht auch über einen System-Bus eines Dienst-Computersystems übermittelt werden, z.B. falls das ID-Provider-Modul integraler Bestandteil des Dienst-Computersystems ist.
Die Attribut-Provider-Computersysteme 172, 173 ... können analog zu dem ID-Provider-Modul 136 aufgebaut sein, das heißt sie verfügen jeweils über eine Netzwerk-Schnittstelle 138, einen Prozessor 145 zur Ausführung von Programminstruktionen 146, 148 und einen Speicher 140, in dem ein Zertifikat und ein privater Schlüssel gespeichert sind. Bei dem Zertifikat handelt es sich vorzugsweise um ein Berechtigungszertifikat, in dem jeweils eine Berechtigung für Lese- und Schreibzugriffe auf den ID-Token 106 spezifiziert ist.
Nach einer Ausführungsform der Erfindung werden die Attribute der Mengen 176 und 179 erst dann in dem Speicher 118 gespeichert, nachdem diese der Nutzer 102 zur Kenntnis nehmen konnte. Hierzu werden diese Attribute auf einem Display 181 angezeigt, welches zum Beispiel zu dem Lesegerät 101 gehört. Ferner kann beispielsweise auf dem Lesegerät 101 ein Bedienelement 182 vorhanden sein, über welches der Nutzer 102 eine Eingabe tätigen muss, um die Speicherung der in den Antworten 176 bzw. 179 beinhalteten Attribute in dem Speicher 118 zu genehmigen. Hierdurch erhält der Nutzer 102 eine Kontrollmöglichkeit bezüglich der möglicherweise seine Person betreffenden zusätzlichen Attribute in dem Speicher 118.
Das Nutzer-Computersystem bzw. die auf diesem installierte Middleware (MW) empfängt eine Liste von Klassenidentifikatoren 702 von dem Dienst-Computersystem 150. Beispielsweise können die Klassenidentifikatoren 702 in dem Dienst-Computersystem bereits gespeichert vorliegen und bei Anfrage eines entsprechenden Dienstes automatisch bereitgestellt werden. Es ist auch möglich, dass das Dienst-Computersystem 150 die erste Attributspezifikation AR, die ebenfalls vom Dienst-Computersystem bereitgestellt wird, zur Laufzeit analysiert und die Klassenidentifikatoren 702 als Analyseergebnis in Antwort auf eine Dienstanfrage 103 an das Nutzer-Computersystem zurückgibt. Alternativ dazu (hier nicht dargestellt) ist es auch möglich, dass das Dienst-Computersystem die erste Attributspezifikation 105 an das ID-Provider-Modul 136 übermittelt und dass das ID-Provider-Computer-System die erste Attributspezifikation 105 analysiert, um die Klassenidentifikatoren 702 dynamisch zu ermitteln. In diesem Fall überträgt das ID-Provider-Modul die Klassenidentifikatoren 702 an das Nutzer-Computersystem.
Nach Erhalt der Klassenidentifikatoren 702 für ein oder mehrere Klassen von Attributen sendet das Nutzer-Computersystem 100 die Klassenidentifikatoren 702 an ein Attribut-Provider-Verzeichnis-Computersystem (APV-CS) 199. Die Adresse des APV-CS 199 kann zum Beispiel in dem Nutzer-Computersystem vorgespeichert vorliegen. Das Senden der Klassenidentifikatoren kann über ein Netzwerk 116, zum Beispiel das Internet, erfolgen. Das APV-CS ermittelt, wie bereits beschrieben wurde, entsprechende Identifikatoren 704 von Attribut-Provider-Computersystemen 172, 173, 174, 1722, 1723, die dazu ausgebildet sind, die Attribute der in der Liste 702 spezifizierten Klassen bezüglich des Nutzers 102 bereitzustellen. Nach Erhalt der Liste 704 von Identifikatoren initiiert das Nutzer-Computersystem 100 mittels mehrerer Triggersignale T1, T2, T3, vorzugsweise in sequenzieller Reihenfolge, eine gegenseitige Authentifizierung der identifizierten Attribut-Provider-Computersysteme mit dem ID-Token 106, sodass jeweils zwischen dem ID-Token und dem betreffenden Attribut-Provider-Computersystem ein gesicherter Übertragungskanal SM[CA]#2, SM[CA]#3, SM[CA]#4 ausgebildet wird. Über diesen gesicherten Kanal werden diejenigen Teile AR1, AR2, AR3 der ersten Attributspezifikation, sofern sie bereits auf dem ID-Token vorliegen, von dem Attribut-Provider-Computersystem ausgelesen, für welches das betreffende Attribut-Provider-Computersystem die notwendigen Leserechte aufweist. Typischerweise besitzt ein Attribut-Provider-Computersystem nur Leserechte bezüglich bestimmter Sektoren des geschützten Speichers des ID-Tokens 106, in welchem selektiv diejenigen Teile der ersten Attributspezifikation gespeichert sind, die eine Attributklasse betreffen, die das berechtigte Attribut-Provider-Computersystem auch bereitstellen kann. Alternativ dazu ist es jedoch auch möglich, dass die einzelnen Attribut-Provider-Computersysteme auf die gesamte erste Attributspezifikation in dem ID-Token lesend zugreifen dürfen um dynamisch eine Attribut-Teilspezifikation zu erstellen, die selektiv nur Attribute derjenigen Klasse spezifiziert, die von diesem Attribut-Provider-Computersystem auch bereitgestellt werden können. Beispielsweise könnte in diesem Fall also das Attribut-Provider-Computersystem 172 die erste Attributspezifikation 105 analysieren um die zweite Attributspezifikation AR1 aus dieser zu extrahieren, wobei AR 1 nur diejenigen Attribute spezifiziert, die einer Klasse angehören, die von dem Attribut-Provider-Computersystem 172 bereitgestellt werden kann.
Die erste Attributspezifikation gelangt dadurch in den geschützten Speicher des ID-Tokens 106, dass das Dienst-Computersystem 150 die erste Attributspezifikation an das ID-Provider-Modul 136 weiterleitet. Dieses speichert die erste Attributspezifikation über den ersten geschützten Übertragungskanal SM[CA]#1 in den geschützten Speicher des ID-Tokens. Nach manchen Ausführungsformen kann das ID-Provider-Modul zusätzlich oder alternativ dazu auch Teilmengen der ersten Attributspezifikation über den ersten geschützten Übertragungskanal in dem ID-Token speichern, zum Beispiel eine zweite Attributspezifikation AR 1, eine dritte Attributspezifikation AR2 oder eine vierte Attributspezifikation AR3. Diese spezifizieren jeweils nur Attribute einer bestimmten Attributklasse. Da das Nutzer-Computersystem 100 die in den gesicherten Kanälen übertragenen Daten nicht lesen oder verändern kann, hat es keine Kenntnis davon, welche Attribute von dem Dienst angefordert wurden oder gar von den Attributen selbst. In einem besonders vorteilhaften Aspekt wird also ein Verfahren bereitgestellt, in welchem die Koordination der Kommunikation mit einer Vielzahl von Attributprovidern technisch getrennt wird von der Übermittlung der sensiblen Daten selbst. Auch für den Fall, dass das Nutzer-Computersystem durch Viren oder trojanische Pferde kompromittiert wird, ist die Sicherheit der übertragenen Daten dennoch gewährleistet, da das Nutzer-Computersystem die über die geschützten Übertragungskanäle kommunizierten Daten nicht einsehen kann.
In Ausführungsformen, in welchen die Attribut-Provider-Computersysteme lesend nur auf die erste, zweite und oder dritte Attributspezifikation zugreifen darf, nicht jedoch auf die bereits in dem ID-Token gespeicherten Attribute, sind die personenbezogenen Attribute also vom Zugriff der Attributprovider geschützt. Ein Attribut Provider-für Adressdaten kennt zwar die Adressdaten eines bestimmten Nutzers, kann jedoch nicht die gesundheitsbezogenen oder Bankkonto-bezogenen Attribute dieses Nutzers aus dem ID-Token lesen. Nur der Dienst empfängt gegebenenfalls alle angeforderten Attribute in ihrer Gesamtheit.
In Ausführungsformen, in welchem ein Attribut-Provider die für ihn relevante Attributspezifikation dynamisch generiert, erhält das Attribut-Provider-Computersystem vorzugsweise Leserechte bezüglich Attributspezifikationen, die auf Attribute einer bestimmten Klasse, die der Attributprovider bereitstellen kann, beschränkt sind. Somit kann der Attributprovider dynamisch ermitteln, welche Attribute einer Klasse noch bereitgestellt werden müssen, kann dies jedoch nicht für Attribute tun, die einer anderen Klasse angehören.
Die Attribut-Provider-Computersysteme 172, 163, 104 und 70, 1722, 1723 haben Schreibrechte zum Schreiben der von ihnen jeweils bereitgestellten Attribute in dem geschützten Speicherbereich des IT Tokens 106. Die Schreibrechte können auch sektorenspezifisch vergeben sein.
In manchen Ausführungsformen haben die Attribut-Provider-Computersysteme darüber hinaus Schreibberechtigung im Hinblick auf Attributspezifikationen, die in dem ID-Token gespeichert sind. Dies kann insbesondere bei iterativer Bereitstellung von Attributen vorteilhaft sein, wenn bei jeder Iteration eine bestimmte Attributspezifikation durch eine neue Version ersetzt wird, die nur noch diejenigen Attribute spezifiziert, die bisher noch nicht bereitgestellt werden konnten.
Das APV-Computersystem 199 hat weder Lese-noch Schreibrechte bezüglich der Attributspezifikationen und der Attribute des ID-Tokens.
Vorzugsweise hat auch das Nutzer-Computersystem 100 weder Lese-noch Schreibrechte bezüglich der Attributspezifikationen und der Attribute des ID-Tokens.
Zusätzlich zu dem ersten Attribut-Provider-Computersystem 172, welches Attribute einer bestimmten Klasse, zum Beispiel Adressdaten, bereitstellen kann, umfasst das verteilte System noch weitere Attribut-Provider-Computersysteme 1723, 1722, die ebenfalls dazu ausgebildet sind, Attribute der gleichen Klasse bereitzustellen wie das erste Attribut-Provider-Computersystem 172. Falls beispielsweise das Attribut-Provider-Computersystem 172 nicht dazu in der Lage ist, sämtliche in der zweiten Attributspezifikation AR1 spezifizierten Attribute bereitzustellen, generiert das Attribut-Provider-Computersystem 172 eine neue Version der zweiten Attributspezifikation AR1' welche nur noch diejenigen Attribute der ursprünglichen zweiten Attributspezifikation AR1 spezifiziert, welche nicht durch das Attribut-Provider-Computersystem 172 bereitgestellt werden konnten. Das Nutzer-Computersystem 100 bzw. die darauf installierte Middleware (MW) koordiniert daraufhin die Bereitstellung der noch fehlenden Attribute dieser Attributklasse durch die zusätzlichen Attribut-Provider-Computersysteme 1722 und, ggf. auch 1723. Bei jeder Iteration wird die aktuelle Version der zweiten Attributspezifikation, wie sie in dem ID-Token 106 gespeichert ist, durch eine noch aktuellere Version ersetzt, die nur noch eine Teilmenge der in der Vorversion spezifizierten Attribute spezifiziert, die noch nicht bereitgestellt werden konnten.
Alternativ dazu (hier nicht dargestellt) ist es auch möglich, dass das Dienst-Computersystem 150 die Liste 702 der Klassenidentifikatoren gespeichert hat oder dynamisch ermittelt und die Liste 702 an das APV-CS 199 sendet. Das Dienst-Computersystem erhält in Antwort darauf die Liste 704 der Identifikatoren und leitet diese an das Nutzer-Computersystem 100 weiter. Somit stellt entweder das ID-Provider-Modul oder das Dienst-Computersystem dem Nutzer-Computersystem die Liste 704 der Identifikatoren bereit, sodass das Nutzer -Computersystem 100 dadurch in die Lage versetzt ist, die Kommunikation zwischen ID-Token 106 und den einzelnen Attribut Providersystemen zu koordinieren.
Die
In Schritt 302 sendet das Nutzer-Computersystem 100 eine Dienstanforderung 103 eines Nutzers 102 über ein Netzwerk 116 an ein Dienst-Computersystem 150, das mit einem ID-Provider-Modul 136 gekoppelt ist. Hierzu gibt der Nutzer beispielsweise eine URL in einen Internetbrowser seines Nutzer-Computersystems ein, um eine sogenannte Internetsession mit dem Dienst-Computersystem aufzubauen. Bei dem Dienst-Computersystem kann es sich zum Beispiel um einen Onlineshop oder ein anderes eCommerce-Portal oder einen Behördenserver, der eine eGovernment-Anwendung zur Verfügung stellt, handeln. Bei der Dienstanforderung des Nutzers kann es sich um die Übertragung einer Kaufentscheidung des Nutzers handeln, die der Nutzer zum Beispiel durch Anklicken eines virtuellen Bedienelements auf der Webseite des Dienst-Computersystems, wie zum Beispiel "Kaufen" oder "buy now" eingibt, wobei diese Dienstanforderung zum Beispiel als http-Request oder https-Request über die Internetsession an das Dienst-Computersystem übertragen werden kann. Bei einer eGovernment-Anwendung kann es sich analog dazu bei der Dienstanforderung um die Übertragung einer Anforderung des Nutzers eines behördlichen Vorgangs, wie zum Beispiel die Ausstellung einer Meldebescheinigung, die Anmeldung eines Kraftfahrzeugs oder die Meldung einer Wohnortänderung oder dergleichen handeln.
Das Dienst-Computersystem benötigt für die Erbringung des mit der Dienstanforderung angeforderten Dienstes Attribute des Nutzers und -je nach Anwendungsfall - auch Attribute des ID-Tokens selbst. Diese können vom Dienst-Computersystem in einer ersten Attributspezifikation 105 ("AR") spezifiziert sein. Beispielsweise kann die erste Attributspezifikation die Attribute Name, Geburtsdatum, Anschrift des Nutzers, Kontonummer des Nutzers, Kreditwürdigkeit des Nutzers sowie Gültigkeitsdauer des ID-Token beinhalten. Die Attribute gemäß dieser ersten Attributspezifikation benötigt das Dienst-Computersystem also zur Erbringung des Dienstes für den Nutzer.
In Antwort auf den Empfang der Dienstanforderung sendet das Dienstcomputersystem 150 in Schritt 304 die erste Attributspezifikation 105 an das ID-Provider-Modul 136. Die erste Attributspezifikation spezifiziert diejenigen Attribute, die das Dienst-Computersystem zur Erbringung des angeforderten Dienstes benötigt. Die Übertragung kann über das Netzwerk erfolgen. Alternativ ist das ID-Provider-Modul ein integraler Bestandteil des Dienst-Computersystems, sodass das Senden der ersten Attributspezifikation zum Beispiel über einen internen Datenbus oder eine LAN-Verbindung erfolgt.
In einem weiteren Schritt (nicht dargestellt) authentifiziert sich der Nutzer 102 gegenüber dem ID-Token. Hierzu gibt der Nutzer eine geheime Kennung, wie zum Beispiel die sogenannte Personal Identification Number (PIN) ein. Dies kann je nach Ausführungsform unmittelbar durch Eingabe in den ID-Token erfolgen, durch Eingabe in das Lesegerät oder durch Eingabe in das Nutzer-Computersystem. Vorzugsweise erfolgt die Authentifizierung des Nutzers gegenüber dem ID-Token mittels einer "Fernüberprüfung", worunter hier jedes Verfahren verstanden wird, bei dem die zu überprüfende Kennung nicht in den ID-Token unmittelbar eingegeben wird, um sie mit der dort gespeicherten Kennung zu vergleichen, sondern bei dem die Überprüfung mittels eines das Lesegerät und den ID-Token involvierenden Protokolls erfolgt, bei dem die Kennung, die in das Lesegerät eingegeben wird, nicht an den ID-Token übertragen werden muss. Entsprechende Protokolle sind an sich aus dem Stand der Technik bekannt, wie zum Beispiel Strong Password Only Authentication Key Exchange (SPEKE), Diffie-Hellman Encripted Key Exchange (DH-EKE), Bellovin-Merritt Protokoll oder Password Authenticated Connection Establishment (PACE). Das SPEKE-Protokoll ist beispielsweise bekannt aus www.jablon.org/speke97.html,
Das ID-Provider-Modul und das ID-Token authentifizieren sich in Schritt 306 gegenseitig. Das ID-Provider-Modul authentifiziert sich gegenüber dem ID-Token beispielsweise über das Netzwerk 116 und weist vorzugsweise auch seine Berechtigung für einen Lesezugriff oder Schreibzugriff nach, indem es beispielsweise sein Berechtigungszertifikat über das Netzwerk an den ID-Token überträgt. Auch der ID-Token authentifiziert sich gegenüber dem ID-Provider-Modul, das heißt, es erfolgt sowohl die sogenannte Terminal Authentication (TA) des ID-Provider-Moduls gegenüber dem ID-Token und die Chip Authentication (CA) des ID-Tokens, das heißt des in dem ID-Token beinhalteten Chips mit dem Prozessor, gegenüber dem ID-Provider-Modul. Die TA und die CA können gemäß BSI TR-03110 durchgeführt werden.
Hierbei kann ein erster gesicherter Übertragungskanal SM[CA]#1 nach einem Secure-Messaging-Verfahren aufgebaut werden, indem bei der TA und/oder der CA ein Session Key zwischen dem ID-Token und dem ID-Provider-Modul für eine Ende-zu-Ende-Verschlüsselung vereinbart wird, wobei der lokale geschützte Übertragungskanal bestehen bleibt.
Nach erfolgreicher gegenseitiger Authentifizierung führt das ID-Provider-Modul in Schritt 308 einen Schreibzugriff auf den ID-Token zum Schreiben der ersten Attributspezifikation 105 in einem geschützten Speicherbereich des ID-Tokens durch. Dabei kann bei Speicherung der AR im nicht-flüchtigen Speicher des ID-Tokens eine aus vorherigen Protokollsitzungen gespeicherte Attributspezifikation ersetzt werden. Das ID-Provider-Modul erzeugt dann ein erstes Umschaltkommando. Das erste Umschaltkommando wird von dem ID-Provider-Modul an den ID-Token über den ersten geschützten Übertragungskanal gesendet. Das Umschaltkommando bewirkt eine Umschaltung von dem ersten geschützten Übertragungskanal SM[CA]#1 auf den lokalen geschützten Übertragungskanal SM[PACE].
Das ID-Provider-Modul führt in manchen Ausführungsformen zunächst einen ersten Lesezugriff aus, um Attribute gemäß der ersten Attributspezifikation aus dem ID-Token auszulesen, soweit diese dort bereits gespeichert vorliegen. Anstatt der ersten Attributspezifikation AR wird in diesem Fall nur eine Teilmenge AR' in dem ID-Token gespeichert, die nur diejenigen Attribute der ersten Attributspezifikation spezifiziert, die nicht bereits auf dem ID-Token gespeichert vorlagen.
Beispielsweise sind in dem ID-Token lediglich der Name, das Geburtsdatum, die Anschrift des Nutzers sowie die Gültigkeitsdauer des ID-Tokens gespeichert, nicht aber die Kontonummer und die Kreditwürdigkeit des Nutzers. In diesem Fall beinhaltet also die neue Version der ersten Attributspezifikation nur die Kontonummer und die Kreditwürdigkeit des Nutzers, da diese nicht in dem ID-Token gespeichert sind. Zusätzlich zu der ersten Attributspezifikation kann das ID-Provider-Modul zweite, dritte und vierte Attributspezifikationen in dem ID-Token speichern, die jeweils Teilmengen der ersten Attributspezifikation darstellen und selektiv nur Attribute einer bestimmten Attributklasse spezifizieren, wobei die Klassen disjunkt oder überlappend sein können.
In Schritt 310 sendet das ID-Provider-Modul, das Dienst-Computersystem oder das Nutzer-Computersystem Klassenidentifikatoren 702 an ein Attribut-Provider-Verzeichnis-Computersystem 199. Da es sich bei den Klassenidentifikatoren nicht um sensible Daten handelt, können diese verschlüsselt oder unverschlüsselt über das Netzwerk 116 gesendet werden.
In Schritt 312 ermittelt das APV-Computersystem 199 Identifikatoren 704 von Attribut-Provider-Computersystemen 172, 173, 174, die dazu in der Lage sind, die in der ersten Attributspezifikation spezifizierten Attribute, deren Klassenidentifikatoren in der Liste 702 enthalten waren, bereitzustellen.
In Schritt 314 übermittelt das APV-CS 199 die Identifikatoren 704 an das Nutzer-Computersystem. Dies kann auf direktem Wege geschehen oder indirekt dadurch, dass das APV-CS die Identifikatoren 704 zunächst an das ID-Provider-Modul oder Dienst-Computersystem, von welchem auch die Klassenidentifikatoren 702 empfangen wurden, sendet. Das ID-Provider-Modul oder Dienst-Computersystem leitet in einem darauf folgenden Schritt die Identifikatoren 704 an das Nutzer-Computersystem weiter.
Das Nutzer-Computersystem empfängt in Schritt 316 also die Identifikatoren 704 auf direktem oder indirektem Wege von dem APV-CS. Jeder der Identifikatoren identifiziert ein Attribut-Provider-Computersystem 172, 1722, 1723, 173, 174, welches dazu ausgebildet ist, nutzerbezogene Attribute der durch den Klassenidentifikator identifizierten Attributklasse bereitzustellen.
Das Nutzer-Computersystem verwendet die empfangenen Identifikatoren 704 um die Adressen der jeweiligen Attribut-Provider-Computersysteme zu identifizieren. In Schritt 318 sendet das Nutzer-Computersystem ein erstes Triggersignal T1 an die identifizierte Adresse eines ersten Attribut-Provider Computersystems 172. Das erste Triggersignal beinhaltet keinerlei Information bezüglich der vom Dienst angeforderten Attribute und beinhaltet somit weder die erste Attributspezifikation noch Teile derselben. Somit ist die Vertraulichkeit der angeforderten Attribute und auch die Art des angeforderten Dienstes gewährleistet falls das Triggersignal von unberechtigten Dritten abgefangen werden sollte. Das Triggersignal T1 beinhaltet jedoch eine Adresse #106 des ID-Tokens 106, zum Beispiel eine URL in Kombination mit einer Portnummer, die es dem ersten Attribut-Provider-Computersystem ermöglicht, mit dem ID-Token in Kontakt zu treten und eine gegenseitige Authentifizierung einzuleiten. Das Attribut-Provider-Computersystem authentifiziert sich gegenüber dem ID-Token über das Netzwerk. Dies kann analog zu der Authentifizierung des ID-Provider-Moduls gegenüber dem ID-Token erfolgen, nämlich mit einer sogenannten TA und einer CA. Hierbei kann ein zweiter gesicherter Übertragungskanal SM[CA]#2 mit Ende-zu-Ende-Verschlüsselung zwischen dem ID-Token und dem ersten Attribut-Provider-Computersystem aufgebaut werden, wobei der erste geschützte Übertragungskanal bestehen bleibt.
Nach einer erfolgreichen gegenseitigen Authentifizierung zwischen dem ersten Attribut-Provider-Computersystem 172 und dem ID-Token 106 in Schritt 320 wird ein gesicherter Übertragungskanal SM[CA]#2 zwischen den beiden Kommunikationspartnern mittels Ende-zu-Ende-Verschlüsselung aufgebaut. Vorzugsweise bleibt dabei der erste geschützte Übertragungskanal SM[CA]#1 bestehen. Im Zuge der gegenseitigen Authentifizierung wird vorzugsweise sowohl eine Terminal-Authentifikation (TA) als auch eine Chip Authentifikation (CA) durchgeführt. Das erste Attribut-Provider-Computersystem liest in Schritt 322 eine zweite Attributspezifikation aus dem ID-Token über den geschützten Übertragungskanal SM[CA]#2 aus oder generiert die zweite Attributspezifikation dynamisch unter Berücksichtigung der in der ersten Attributspezifikation spezifizierten Attribute. Die zweite Attributspezifikation AR1 spezifiziert diejenige Menge von Attributen, welche einer Attributklasse angehören, zu deren Bereitstellung das erste Attribut-Provider-Computersystem 172 ausgebildet ist. Auf diese Weise wird an das erste Attribut-Provider-Computersystem kommuniziert, welche Attribute von dem ersten Attribut-Provider-Computersystem bereitgestellt werden sollen.
In Schritt 324 ermittelt das erste Attribut-Provider-Computersystem 172, zum Beispiel durch Zugriff auf Datenbanken oder externe Dienste, die in der zweiten Attributspezifikation spezifizierten Attribute und schreibt diese Attribute, auch als "erste Attributmenge A1" bezeichnet, in Schritt 326 auf einen geschützten Speicherbereich des IT Tokens 106. Die geschriebenen Attribute werden hierbei über den zweiten geschützten Übertragungskanal SM[CA]#2 an das ID-Token übertragen und sind damit vor unberechtigten Zugriff Dritter und auch vor dem Zugriff des Nutzer-Computersystems geschützt. Außerdem kann das erste Attribut-Provider-Computersystem den zweiten geschützten Übertragungskanal dazu nutzen, die zweite Attributspezifikation zu löschen oder, falls nicht alle der darin spezifizierten Attribute ermittelt werden konnten, die zweite Attributspezifikation durch eine neue Version zu ersetzen, die nur noch die nicht ermittelten Attribute der vorigen Version der zweiten Attributspezifikation spezifiziert.
Außerdem sendet das erste Attribut-Provider-Computersystem 172 in Schritt 328 ein Bestätigungssignal S1 welches angibt, ob sämtliche in der zweiten Attributspezifikation spezifizierten Attribute erfolgreich ermittelt und in dem ID-Token gespeichert werden konnten. Optional kann das Bestätigungssignal auch eine Fehlermeldung enthalten, falls bei der Ermittlung oder beim Schreiben der Attribute ein Fehler auftrat.
Falls das erste Bestätigungssignal angibt, dass alle in der zweiten Attributspezifikation AR1 spezifizierten Attribute erfolgreich in dem ID-Token 106 gespeichert wurden, sendet das Nutzer-Computersystem ein zweites Triggersignal T2 an ein zweites Attribut-Provider-Computersystem 173, sodass dieses einen dritten geschützten Übertragungskanal SM[CA]#3 aufbauen, die dritte Attributspezifikation AR2 nach gegenseitiger Authentifizierung mittels CA und TA aus dem ID-Token über den Kanal SM[CA]#3 auslesen, die darin spezifizierten Attribute bereitstellen und in dem ID-Token unter Verwendung des gesicherten Kanals SM[CA]#3 speichern kann. Die Schritte 318-328 von
Das Nutzercomputersystem stellt anhand der empfangenen Bestätigungssignale S1 und anhand der empfangenen Liste 704 fest, dass alle kontaktierten Attribut-Provider-Computersysteme erfolgreich ihre jeweiligen Attribute in dem ID-Token gespeichert haben. Daraufhin veranlasst das Nutzer-Computersystem den ID-Provider-Modul, den gesicherten ersten Übertragungskanal SM[CA]#1 zwischen dem ID-Token und dem ID-Provider-Modul wiederherzustellen und die in dem ID-Token gespeicherten Attribute in Schritt 330 über den ersten geschützten Übertragungskanal SM[CA]#1 auszulesen.
Das Umschalten auf den geschützten ersten Übertragungskanal SM[CA]#1 kann z.B. so erfolgen, dass das ID-Token nach dem Schreibzugriff eines Attribut-Provider-Computersystems automatisch auf den lokalen gesicherten Kanal SM[PACE] "zurückfällt". Das Nutzer-Computersystem schaltet nach Erhalt eines Bestätigungssignals von dem zuletzt schreibenden Attribut-Provider-Computersystem auf den gesicherten ersten Übertragungskanal SM[CA]#1 um, indem es ein Umschaltkommando UK über den lokalen Übertragungskanal SM[PACE] an den ID-Token sendet, und den ID-Token dadurch veranlasst, von dem lokalen gesicherten Übertragungskanal auf den ersten gesicherten Übertragungskanal umzuschalten. Das ID-Token ist bei den Umschaltvorgängen also passiv.
In einem weiteren Schritt 332 leitet das ID-Provider-Modul die ausgelesenen Attribute A1, A2, A3, ..., an das Dienst-Computersystem weiter.
Das Dienstcomputersystem verfügt somit über sämtliche angeforderten Attribute. Obwohl eine Vielzahl von Attribut-Provider-Computersystemen involviert waren, musste das Dienst-Computersystem sich nicht um die komplexe Koordination der Datenübertragung kann man und musste auch dem Nutzer-Computersystem, welches sich darum kümmert, keine sensiblen Daten übermitteln.
Mögliche vorteilhafte Ausführungsformen umfassen die folgenden Merkmalskombinationen:
wobei das die Klassenidentifikatoren ermittelnde Computersystem die ermittelten Klassenidentifikatoren an das Attribut-Provider-Verzeichnis-Computersystem sendet und die Identifikatoren von dem Attribut-Provider-Verzeichnis-Computersystem empfängt;
wobei Verfahren a) umfasst:
wobei Verfahren b) umfasst:
Firmenausweis oder ein Zahlungsmittel, wie zum Beispiel eine Banknote, eine Kreditkarte oder einen sonstigen Berechtigungsnachweis, wie zum Beispiel eine Eintrittskarte, einen Frachtbrief oder ein Visum, insbesondere eine Chipkarte, insbesondere mit RFID- und/oder NFC-Schnittstelle.
wobei die erste Attributspezifikation von dem ID-Provider-Modul an das ID-Token über einen ersten geschützten Übertragungskanal übertragen wird;
wobei die erste Attributmenge und/oder die zweite Attributspezifikation zwischen dem ersten Attribut-Provider-Computersystem und dem ID-Token über einen zweiten geschützten Übertragungskanal kommuniziert wird;
wobei die zweite Attributmenge und/oder die dritte Attributspezifikation zwischen dem zweiten Attribut-Provider-Computersystem und dem ID-Token über einen dritten geschützten Übertragungskanal kommuniziert wird; wobei das Nutzer-Computersystem die Kommunikation zwischen dem ID-Token und dem ID-Provider-Modul, dem ersten und den zweiten Attribut-Provider-Computersystem koordiniert; und
wobei Daten, die über den ersten, zweiten oder dritten geschützten Übertragungskanal übertragen werden, vor dem Zugriff des Nutzer-Computersystems geschützt sind.
标题 | 发布/更新时间 | 阅读量 |
---|---|---|
一种多路安全元件集群板卡 | 2020-05-08 | 949 |
金融记录管理系统 | 2020-05-08 | 1042 |
一种应急救援的智能头盔 | 2020-05-08 | 255 |
一种热轧板坯堆放自动控制方法 | 2020-05-11 | 315 |
一种构建列存储数据库的方法和系统 | 2020-05-11 | 973 |
项目加速的自动评估 | 2020-05-08 | 462 |
一种任务处理方法、装置及计算机系统 | 2020-05-08 | 689 |
低排放静态控氧生物强化腐殖化堆肥的方法 | 2020-05-08 | 863 |
太赫兹波衰减全反射成像的分辨率补偿装置 | 2020-05-08 | 396 |
一种混合动力系统的硬件在环测试系统 | 2020-05-08 | 478 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。
专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。