DE102014222300A1

DE102014222300A1 - Verfahren zur überprüfung eines vertrauensstatus eines zertifikats oder schlüssels

Info

Publication number: DE102014222300A1
Application number: DE102014222300.8A
Authority: DE
Inventors: Beat Peter Bruegger
Original assignee: Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Current assignee: Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority date: 2014-10-31
Filing date: 2014-10-31
Publication date: 2016-05-04
Anticipated expiration: 2034-11-01
Also published as: DE102014222300B4

Abstract

Ausführungsbeispiele der vorliegenden Erfindung schaffen ein Verfahren zur Überprüfung eines Vertrauensstatus eines Zertifikats oder Schlüssels. Das Verfahren umfasst einen Schritt des Ermittelns eines Hashwerts für das Zertifikat oder den Schlüssel, einen Schritt des Ermittelns eines Host Labels aus dem Zertifikat oder Schlüssel, einen Schritt des Abfragens eines DNS Resource Records unter Verwendung des Host Labels, wobei der DNS Resource Record einen Soll-Hashwert des Zertifikats oder Schlüssels aufweist, und einen Schritt des Vergleichens des Hashwerts des Zertifikats oder Schlüssels mit dem Soll-Haschwert, um den Vertrauensstatus des Zertifikats oder Schlüssels zu überprüfen.

Description

Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf ein Verfahren zur Überprüfung eines Vertrauensstatus eines Zertifikats oder Schlüssels. Manche Ausführungsbeispiele beziehen sich auf eine DNS basierte (DNS = Domain Name System) generische globale Vertrauensinfrastruktur (engl. trust infrastructure).
In vielen Anwendungsgebieten erhalten Anwendungen Artefakte, dessen Vertrauenswürdigkeit bestimmt werden muss. Typische Beispiele für solche Artefakte sind Zertifikate und/oder öffentliche Schlüssel.
Im Folgenden werden derartige Anwendungsgebiete beispielhaft und nicht abschließend aufgelistet:

– Ein Auswerter (engl. verifier) erhält ein digital signiertes Dokument und soll bestimmen, ob dem Signierer bzw. Unterzeichner getraut werden kann (z. B. ob die Signatur qualifiziert, also rechtsgültig ist).
– Ein Auswerter authentisiert einen Benutzer aufgrund eines X.509 Zertifikats, welches in einem TLS Handshake (TLS = Transport Layer Security, dt. Transportschicht Sicherheit) präsentiert wurde, und soll entscheiden, auf welcher Sicherheitsstufe dem Benutzer vertraut werden kann.
– Das Zugangskontrollsystem eines Dienstanbieters (engl. service provider) erhält eine SAML (SAML = Security Assertion Markup Language, dt. ein XML-Framework zum Austausch von Authentifizierungs- und Autorisierungsinformationen) Erklärung (oder Behauptung, oder Aussage) (engl. Assertion), welche von einem externen Identitätenbereitsteller (engl. identity provider) signiert ist, und soll bestimmen, ob ein Benutzer Zugriff zu einer angeforderten Ressource bekommen soll (z. B. basierend auf einem Vertrauenskreis (engl. circle of trust), der entscheidet, welche Identitätenbereitsteller vertrauenswürdig sind).
– Ein Softwaresystem erhält eine Software (z. B. eine Applikation, eine Anwendung oder eine kleine Anwendung (engl. applet)), welche von einem Dritten signiert ist, und soll entscheiden, ob diese Software auf dem System ausgeführt werden darf.
– Ein Authentisierungsgerät identifiziert sich selbst mit einem Beglaubigungs- bzw. Bescheinigungszertifikat (engl. attestation certificate) gegenüber einem Auswerter bzw. Verifizierer, der bestimmen soll, auf welcher Sicherheitsstufe dem Authentisierungsgerät vertraut werden kann.

Typischerweise wird bei der Vertrauensauswertung eine Vertrauensrichtlinie (engl. trust policy) verwendet, die die genauen Konditionen für das Vertrauen festlegt.
Die häufigste Lösung für dieses Problem ist die Verwendung von Listen von vertrauenswürdigen Artefakten.
Beispielsweise veröffentlicht die europäische Kommission mit Delegation an Mitgliedsstaaten Listen von qualifizierten Zertifikaten. Diese Listen sind signiert und standardisiert (ETSI TSL, European Telecommunications Standards Institute Trust Service Lists).
Der Auswerter bzw. Verifizierer bewertet dann die Vertrauenswürdigkeit eines Artefakts indem er eine oder mehrere Listen herunterlädt, diese verifiziert (z. B. über deren digitale Signatur relativ zu einem bekannten Vertrauensanker (engl.: trust anchor)), die Listen parst, um dann die Artefakte in einen lokalen Speicher abzulegen. Einzelne Artefakte können dann durch Abfrage des lokalen Speichers bewertet werden.
Diese Lösung verlangt einen großen Aufwand vom Auswerter bzw. Verifizierer. Dies umso mehr, da in der Realität mehrere Listen von verschiedenen Quellen verwaltet werden und diese Vertrauenslisten bzw. Vertrauensstatuslisten verfallen, synchronisiert und aktualisiert werden müssen. Ein fehlender Standard für diesen Prozess verhindert die Verfügbarkeit einer einfachen Implementierung.
Darüber hinaus trägt der Auswerter eine signifikante Verantwortung für die Gesamtsicherheit der Vertraulichkeitsbeurteilung, da er die Vertrauensanker sicher bereitstellen und den lokalen Vertrauensspeicher gegen Angriffe schützen soll.
Alternativ zur Verwendung von Listen ist es auch möglich, Technologien wie z. B. LDAP (LDAP = Light Weight Directory Access Protocol, dt. Leichtgewichtiges Verzeichniszugriffsprotokoll) oder DBMS (DBMS = Database Management System, dt. Datenbank-Verwaltungssystem) zur Veröffentlichung vertrauenswürdiger Artefakte zu verwenden. Dies vermindert den nötigen Aufwand von Auswertern, da diese somit auf einen lokalen Speicher verzichten können. Diese Lösungen sind aber nur für relativ kleine und kontrollierte Anwendungssituationen in einem geschützten Netzwerk geeignet.
Ferner kann alternativ der Aufwand der Auswerfer bzw. Verifizierer vermindert werden, indem ein externer Auswerter, z. B. eine Validierungsstelle (engl. validation authority), verwendet wird, an die die Verwaltung eines lokalen listenbasierten Speichers ausgelagert wird. Diese Lösung ist aber typisch auf eine einzige Vertrauensregelung (engl.: trust scheme) beschränkt und kann nicht weltweit beliebige Vertrauensregelungen oder personalisierte Anforderungen, wie lokale weiße Listen (engl. whitelists) oder schwarze Listen (engl. blacklists) abdecken.
Der vorliegenden Erfindung liegt somit die Aufgabe zugrunde, ein Konzept zu schaffen, welches eine effizientere Auswertung von Artefakten ermöglicht.
Diese Aufgabe wird durch die unabhängigen Patentansprüche gelöst. Vorteilhafte Weiterbildungen finden sich in den abhängigen Patentansprüchen.
Ausführungsbeispiele der vorliegenden Erfindung schaffen ein Verfahren zur Überprüfung eines Vertrauensstatus eines Zertifikats oder Schlüssels. Das Verfahren umfasst einen Schritt des Ermittelns eines Hashwerts für das Zertifikat oder den Schlüssel, einen Schritt des Ermittelns eines Host Labels aus dem Zertifikat oder Schlüssel, einen Schritt des Abfragens eines DNS Resource Records unter Verwendung des Host Labels, wobei der DNS Resource Record einen Soll-Hashwert des Zertifikats oder Schlüssels aufweist, und einen Schritt des Vergleichens des Hashwerts des Zertifikats oder Schlüssels mit dem Soll-Haschwert, um den Vertrauensstatus des Zertifikats oder Schlüssels zu überprüfen.
Der vorliegenden Erfindung liegt der Gedanke zugrunde, dass der Vertrauensstatus eines Zertifikats oder Schlüssels überprüft werden kann, indem ein aus dem Zertifikat oder Schlüssel ermittelter Hashwert mit einem Soll-Hashwert verglichen wird, der in einem DNS Resource Record enthalten ist, wobei der DNS Resource Record unter Verwendung eines Host Labels abgerufen wird, so dass bei dem Abrufen des DNS Resource Records nur der gewünschte DNS Ressource Record abgerufen wird, wodurch unnötiger Aufwand in der Verarbeitung und/oder Auswertung von (langen) Listen, die eine Vielzahl von DNS Resource Records enthalten, entfällt.
Ausführungsbeispiele der vorliegenden Erfindung werden bezugnehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
1 ein Flussdiagramm eines Verfahrens zur Überprüfung eines Vertrauensstatus eines Zertifikats oder Schlüssels, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
2 eine schematische Ansicht eines Ausführungsbeispiels bei dem der Vertrauensstatus einer digitalen Signatur eines signierten Dokuments überprüft wird;
3 eine schematische Ansicht eines Ausführungsbeispiels bei dem der Vertrauensstatus einer SAML Erklärung überprüft wird;
4 eine schematische Ansicht eines Ausführungsbeispiels bei dem der Vertrauensstatus einer digitale Signatur einer signierten Software überprüft wird;
5 eine schematische Ansicht eines Ausführungsbeispiels bei dem ein Vertrauensstatus eines mit einem Attestationszertifikat signierten öffentlichen Schlüssels überprüft wird; und
6 eine schematische Ansicht eines Ausführungsbeispiels bei dem ein Vertrauensstatus eines Artefakts überprüft wird.
In der nachfolgenden Beschreibung der Ausführungsbeispiele der vorliegenden Erfindung werden in den Figuren gleiche oder gleichwirkende Elemente mit dem gleichen Bezugszeichen versehen, so dass deren Beschreibung in den unterschiedlichen Ausführungsbeispielen untereinander austauschbar ist.
1 zeigt ein Flussdiagramm eines Verfahrens 100 zur Überprüfung eines Vertrauensstatus eines Zertifikats oder Schlüssels, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Das Verfahren 100 umfasst einen Schritt 102 des Ermittelns eines Hashwerts für das Zertifikat oder den Schlüssel, einen Schritt 104 des Ermittelns eines Host Labels aus dem Zertifikat oder Schlüssel, einen Schritt 106 des Abfragens eines DNS Resource Records unter Verwendung des Host Labels, wobei der DNS Resource Record einen Soll-Hashwert des Zertifikats oder Schlüssels aufweist, und einen Schritt 108 des Vergleichens des Hashwerts des Zertifikats oder Schlüssels mit dem Soll-Haschwert, um den Vertrauensstatus des Zertifikats oder Schlüssels zu überprüfen.
Bei Ausführungsbeispielen kann der DNS Resource Record ein DNS TLSA Resource Record sein (TLSA = Name (und keine Abkürzung) des Resource Record Typs, der in der RFC 6698 definiert ist; RFC = Request For Comment, dt. Anfrage für ein Kommentar; RFCs sind offizielle Dokumente der Internet Engineering Task Force (IETF) die regeln, wie das Internet aufgebaut und betrieben wird; Einige der RFCs sind Internet Standards, was an der Kategorie des RFCs, z. B. „informatorisch” (engl. informational), „experimentell” (engl. experimental), „bewährte derzeitige Methode” (engl. best current practice), „Standardweg” (engl. standards track), oder „historisch” (engl. historic), erkannt werden kann; Im Falle von „Standardweg” (engl. standards track), wird basierend auf dem Status des RFC zwischen „vorgeschlagener Standard (engl. proposed standard), entworfener Standard (engl. draft standard) und Internetstandard (engl. internet standard) unterschieden). Natürlich kann anstatt des DNS TLSA Resource Records auch ein anderer geeigneter DNS Resource Record für den Hashwert verwendet werden.
Bei Ausführungsbeispielen kann das Abfragen des DNS (TLSA) Resource Records unter Verwendung einer Kombination aus dem Host Label und einer Subdomain erfolgen. Dabei kann bei dem Abfragen des DNS (TLSA) Resource Records der Host Label der Subdomain vorangestellt werden (z. B. HostLabel.Subdomain), so dass die Kombination von Host Label und Subdomain ein FQDN (FQDN = Fully Qualified Domain Name, dt. vollqualifizierter Domainname) repräsentiert.
Ein Host Label kann der erste Label von links (engl. left-most) in einem FQDN sein. Dieser kann einem Blatt in dem baumförmigen Domain-Namensraum entsprechen und den DNS Resource Records zugeordnet werden. Der Begriff impliziert nicht zwangsläufig, dass der Domainname einem wirklicher Host (Server) entspricht, noch dass für diesem Domain-Namen A oder AAAA Resource Records zugeordnet werden müssen.
Eine Subdomain kann sich hierin auf eine Serie von Labels beziehen, welche zusammen mit einem links zugefügten Host Label einen FQDN bildet. Eine Subdomain kann beispielsweise eine Serie von zumindest drei oder vier Labels umfassen.
Ausführungsbeispiele der vorliegenden Erfindung verwenden das existierende Domain Name System (DNS) als Basis für eine globale, generische (d. h. für arbiträre Anwendungsgebiete) Vertrauensinfrastruktur (engl. trust infrastructure).
Dabei können einzelne oder alle Aspekte des existierenden DNS verwendet werden, einschließlich der von der IETF (IETF = Internet Engineering Task Force, dt. Internettechnik-Arbeitsgruppe) erlassen technischen Standards, der politischen Vereinbarungen über die Steuerung bzw. Führung des DNS, der existierenden Softwarekomponenten (insbesondere DNS-Server und DNS-Auflöser (engl. DNS resolver)), der existierende Vertrauenswurzel (engl. trust root) des DNS (mit der Sicherheitserweiterung DNSSEC (DNSSEC = DNS Security Extensions, dt. DNS Sicherheitserweiterungen), und, am wichtigsten, der existierenden globalen, hochverfügbaren (engl. highly available), sicheren, und effizienten Infrastruktur des DNS.
Die technischen Standards, die Ausführungsbeispiele der vorliegenden Erfindung verwenden, sind die RFCs (RFC = Request For Comments, d. h. ein technisches Dokument der IETF) bezüglich des DNS, DNSSEC und DANE (DANE = DNS-based Authentication of Named Entities, dt. DNS basierte Authentisierung von benannten Entitäten), im letzteren Fall vor allem der neue DNS TLSA Resource Record.
Ausführungsbeispiele der vorliegenden Erfindung schaffen mehrere Methoden:

– Eine Methode für sogenannte Vertrauensschemastellen (engl. trust scheme authorities (TSA)), um Listen von vertrauenswürdigen Artefakten (engl. artifacts) im DNS zu publizieren.
– Eine Methode für Verifizierer bzw. Auswerter, um über das DNS abzufragen, ob ein gegebenes Artefakt in einer gegebenen Liste enthalten ist.
– Methoden für Artefakt-Ausgeber, um dem Verifizierer bzw. Auswerter zu kommunizieren, in welcher Liste das Artefakt enthalten ist. Eine Methode zur Schaffung von Indizes von komplexen Vertrauensschemata bzw. Vertrauensstatusmodellen (engl. trust schemes).
– Eine auf Mengenlehre und Logik basierende Strategiesprache (engl. policy language), in der Verifizierer bzw. Auswerter die minimalen Bedingungen ausdrücken können, die ein Artefakt relativ zu der publizierten Listen erfüllen muss um als Vertrauenswürdig eingestuft zu werden. Dies beinhaltet Kombinationen von weißen und schwarzen Listen (engl. whitelists and blacklists). Mit anderen Worten, eine Sprache basierend auf Mengenlehre und Logik zur Formulierung einer Vertrauensstrategie bzw. Vertrauensmethode (engl. trust policy), welche mehrere Listen gegebenenfalls von mehreren TSAs kombiniert und von einem Algorithmus für eine Vertrauenswürdigkeitsentscheidung angewendet werden kann.

Eine Vertrauensschemastelle (oder Vertrauensregelungsstelle, oder Vertrauensstatusstelle, oder Vertrauensrichtlinienstelle) (engl. trust scheme authority) ist eine Stelle (oder Autorität, oder Organisation), die Vertrauenslisten (engl. trust lists) ausstellt.
Ein Vertrauensschema (oder Vertrauensstatus, oder Vertrauensstatusmodell, Vertrauensrichtlinie) (engl. trust scheme) umfasst die Prozedur, die durch eine Vertrauensschemastelle definiert wird und zur Definition einer einzelnen oder Familie von Vertrauenslisten (oder Vertrauensstatuslisten oder vertrauenswürdige Listen) führt. Dies umfasst die Regelung, die die technischen und organisatorischen Anforderungen für die Mitgliedschaft in einer Vertrauensliste vorgibt. Ferner umfasst dies die Aufsicht durch eine Vertrauensschemastelle, die überprüft oder verifiziert, dass die Anwender bzw. Benutzer tatsächlich die Regelungen erfüllen. Des Weiteren umfasst dies organisatorische und kommerzielle Verfahren zur Anfrage und Aufnahme der Mitgliedschaft in einer Vertrauensliste.
Im Folgenden wird die Veröffentlichung bzw. Publikation von Vertrauenslisten (engl. trust lists) beschrieben.
Mit anderen Worten, um Listen publizieren (oder veröffentlichen) zu können, können sich sogenannte Vertrauensschemastellen (engl. trust scheme authorities, TSA) vorerst im DNS registrieren, um eine Basis-Domain zu erhalten. Darin können diese dann Subdomains definieren, in denen die Listen publiziert werden können. Die folgenden Beispiele zeigen eine von mehreren Möglichkeiten. Die europäische Kommission, Besitzer der Domain ec.eu, könnte z. B. die Subdomain qualified.tsa.ec.eu für die Publikation von Listen relativ zum Vertrauensschema (engl. trust scheme) der qualifizierten Zertifikate verwenden. Ähnlich könnte der Bundesverband deutscher Banken mit der Basis-Domain bankenverband.de die Subdomain interbanking.tsa.bankverband.de zur Publikation der Zertifikate für einen vertraulichen Kreis (engl. circle of trust) von Banken verwenden.
Bei Ausführungsbeispielen kann die Subdomain, unter welcher der DNS (TLSA) Resource Record abgefragt wird eine Ausprägung des Vertrauensstatus anzeigen. Dabei können unterschiedliche Ausprägungen des Vertrauensstatus durch unterschiedliche Subdomains angezeigt werden. Beispielsweise können unterschiedliche Ausprägungen unterschiedliche Vertrauenswürdigkeitsstufen sein.
Mit anderen Worten, in Abhängigkeit von den Charakteristiken des Vertrauensschemas (engl. trust scheme) können weitere Subdomains kreiert bzw. erstellt werden. Beispielsweise kann im Falle einer Delegation jede delegierte Liste in einer eigenen Subdomain abgebildet werden. Beispielsweise kann die europäische Kommission die Bestimmung von qualifizierten Zertifikaten an Mitgliedsstaaten delegieren. Dafür könnten dann Domains wie it.qualified.tsa.ec.eu und de.qualified.tsa.ec.eu geschaffen werden. Die normalen DNS-Methoden können dann verwendet werden, um die Autorität über diese Subdomains an die Mitgliedsstaaten zu delegieren.
Ein weiteres Beispiel, bei dem zusätzliche Subdomains verwendet werden können, ist die Unterscheidung von unterschiedlichen Vertrauenswürdigkeitsstufen (engl. levels of trust). Beispielsweise könnte der Bundesverband deutscher Banken Subdomains wie
level1andabove.interbanking.tsa.bankverband.de;
level2andabove.interbanking.tsa.bankverband.de;
level3.interbanking.tsa.bankverband.de definieren;
schaffen, um die verschiedenen Sicherheitsstufen von OTP-Generatoren (OTP = One Time Passwort, d. h. ein generiertes Passwort das nur einmal verwendet wird) ihrer Mitglieder zu beschreiben. Diese Subdomains können dann mit Zertifikaten von Identitätenbereitstellern (engl. identity providers) aufgefüllt werden, die diese OTP-Generatoren authentisieren.
Wenn die Struktur der Domains einmal bestimmt ist, können die Subdomains mit Artefakten, wie z. B. Zertifikaten oder öffentlichen Schlüsseln, aufgefüllt werden. Dazu kann das Artefakt auf einen gültigen Host Label abgebildet werden. Eine von mehreren möglichen Abbildungen ist wie folgt:
Unter dem resultierenden Host Label kann zumindest ein TLSA Resource Record definiert werden, der zur Validierung des Artefakts verwendet werden kann. Auch andere oder zusätzliche Arten von Resource Records können für zusätzliche Informationen des Artefakts verwendet werden. Beispielsweise können maschinenlesbare TXT Resource Records mit zusätzlichen Information für qualifizierte Zertifikate für die Bewertung von archivierten Signaturen verwendet werden.
Im Folgenden wird die Abfrage von Vertrauenslisten bzw. Vertrauensstatuslisten (engl. trust lists) beschrieben.
Dabei kann das nachfolgende Verfahren verwendet werden, um zu verifizieren, ob ein gegebenes bzw. bestimmtes Artefakt in einer gegebenen bzw. bestimmten Liste enthalten ist:

– Die Liste wird in eine DNS Domain abgebildet.
– Das Artefakt wird in einem Host Label abgebildet.
– Ein Standard validierender DNS Auflöser (engl. DNS resolver) kann verwendet werden, um den Host in der DNS Domäne abzufragen. Dies resultiert entweder in der Meldung der Abwesenheit des Hosts in der Domain (dies ist eine Funktion des DNSSEC) oder einem oder mehreren Resource Records mit zumindest einem TLSA Resource Record.
– Der TLSA Resource Record kann verwendet werden, um den Vertrauensstatus des Artefakts zu verifizieren bzw. zu beurteilen.

Optional können weitere Resource Records für eine weitere Verifizierung bzw. Beurteilung des Artefakts verwendet werden.
Das Resultat der Abfrage von Vertrauenslisten bzw. Vertrauensstatuslisten ist die Sicherheit bzw. Gewissheit, ob das Artefakt in der Vertrauensliste bzw. Vertrauensstatusliste enthalten ist oder nicht. Die vollständige Abfragekette des DNSSEC, die bei der DNS Vertrauenswurzel (engl. DNS trust root) startet und mit dem eigentlichen Abfrageergebnis endet, kann als Quittung der Vertrauensentscheidung aufgezeichnet (engl. logged) werden.
Im Folgenden wird die Vertrauensmethode (engl. trust policy) beschrieben.
Bei Ausführungsbeispielen kann bei dem Abfragen des DNS (TLSA) Resource Records für einen Host Label eine Mehrzahl von DNS Resource Records bei unterschiedlichen Subdomains abgefragt werden.
Mit anderen Worten, während das obige Verfahren genutzt werden kann, um zu bestimmen, ob ein Artefakt in einer einzelnen Liste enthalten ist, verwenden Auswerter bzw. Verifizierer in der Regel eine Vertrauensrichtlinie (oder Vertrauensmethode, oder Vertrauensstrategie) (engl. trust policy), die mehrere Listen möglicherweise unterschiedlicher TSAs referenziert. Dies wird im Folgenden anhand eines einfachen Beispiels verdeutlicht.
Hier sind ”trusted”, ”employees”, ”qualified-white.tsa.ec.eu”, ”legalSign-white.tsa.gov”, und ”badGuys” DNS basierte, lokale, oder virtuelle Listen. Diese Listen können zum Beispiel mit Mengenoperatoren (z. B. Vereinigung, Schnitt, Differenz) kombiniert werden. Dabei können einige der Listen weiße Listen (engl. whitelists) und andere der Listen schwarze Listen (engl. blacklists) sein. Natürlich kann die Vertrauensrichtlinie (engl. trust policy) auch (viel) komplexer sein, beispielsweise könnte die Vertrauensentscheidung davon abhängen, ob ein Zugriff während üblicher Arbeitszeiten erfolgt.
Vertrauenswürdigkeitsentscheidungen können durch Auswerter bzw. Verifizierer relativ zu solchen Vertrauensrichtlinien (engl. trust policies) getätigt werden, die durch einen Algorithmus interpretiert und dann in eine Reihe von individuellen, oben beschriebenen Abfragen übersetzt werden. Mit anderen Worten, Auswerter tätigen ihre Vertrauenswürdigkeitsentscheidung basierend auf solchen Vertrauensrichtlinien (engl. trust policies), indem sie einen Algorithmus anwenden, der die Vertrauensrichtlinie in eine Sequenz von einzelnen DNS Abfragen übersetzt.
Im Folgenden werden Indizes von komplexen Vertrauensschemata (engl. trust schemes) beschrieben.
Bei komplexen Vertrauensschemata (engl. trust schemes) mit vielen Subdomains kann es schwierig werden zu ermitteln in welcher Subdomain ein Artefakt gelistet wird. Um dies zu vereinfachen können TSAs eine Index-Domain definieren. Im Beispiel der qualifizierten Zertifikate wäre dies dann index.qualified.tsa.ec.eu. Diese Subdomain enthält dann die Host Labels aller Subdomains mit einem CNAME Resource Record, der den entsprechenden Host Label in der richtigen Subdomain anzeigt.
Im Folgenden werden Verweise auf Vertrauenslisten bzw. Vertrauensstatuslisten durch Artefakt-Ausgeber beschrieben.
Bei Ausführungsbeispielen kann das Verfahren 100 ferner Ermitteln eines Host Labels und/oder einer Sub-Domain, unter welchen der DNS Resource Record abzufragen ist, aus dem Zertifikat aufweisen, wobei bei dem Abfragen des DNS Resource Records der DNS Resource Record bei einer Kombination aus dem ermittelten Host Label und der ermittelten Subdomain abgefragt wird.
Mit anderen Worten, um die Effizienz der obigen Verfahrens noch weiter zu erhöhen können Artefakt-Ausgeber Verweise auf Listen, die das Artefakt enthalten, in das Artefakt selbst einbauen. Dies wird hierin Vertrauensmitgliedschaftsanspruch oder Vertrauenszugehörigkeitsbehauptung (engl. trust membership claim) genannt. Beispiele dafür sind Verweise in Feldern wie „Herausgeber-Alternativ-Name” (engl. issuer alt name) oder „Inhaber-Alternativ-Name” (engl. subject alt name) in Zertifikaten, zusätzlichen XML-Elementen in SAML Erklärungen (engl. assertions), oder maschinenlesbaren Dateien in standardisierten URLs auf der Internetseite des Artefakt-Ausgebers.
Im Folgenden werden allgemeine Eigenschaften von Ausführungsbeispielen beschrieben.
Ausführungsbeispiele verwenden die existierenden Registrierungsbehörden des DNS, um eine weltweit eindeutige Vergabe von Namen von Vertrauensschemata (engl. trust schemes) und einzelnen Listen sicherzustellen. Die existierenden Registrierungs- und Delegationsmechanismen des DNS garantieren, dass die in den Listen veröffentlichen Daten von den rechtmäßigen TSAs stammen. Ferner ersetzten Ausführungsbeispiele die in herkömmlichen Lösungen erforderlichen unzähligen Vertrauensanker (engl. trust anchor) durch die Vertrauenswurzel (engl. trust root) des DNS.
Im Folgenden werden Anwendungsbeispiele des oben beschriebenen Verfahrens 100 beschrieben.
2 zeigt eine schematische Ansicht eines Ausführungsbeispiels bei dem ein Vertrauensstatus eines elektronischen Artefakts 120 überprüft wird. In 2 ist das elektronische Artefakt 120 eine digitale Signatur, beispielsweise eines signierten Dokuments.
Hier entscheidet eine Vertrauensschemastelle (engl. trust scheme authority (TSA)) 122, welche Zertifizierungsstellen (engl. certification authorities (CA)) 124 vertrauenswürdig sind (z. B. qualifiziert). Dies wird typischerweise über Regulierung und Überwachung erreicht. Vertrauenswürdige Zertifizierungsstellen (CA) 124 werden dann von der Vertrauensschemastelle (TSA) 122 zertifiziert, indem die CA-Zertifikate in DNS-basierte Listen eingetragen werden, beispielsweise bei einem DNS Server 126.
Die Zertifizierungsstelle (CA) 124 gibt mit dem CA-Zertifikat signierte End-Zertifikate an Personen 128 aus. Personen 128 verwenden diese dann, um Dokumente zu signieren. Das Artefakt 120 umfasst dann das signierte Dokument und sowohl das End- als auch das CA-Zertifikat. Optional kann die Zertifizierungsstelle (CA) 124 in einem der Zertifikate angeben, unter welchem Host Label und in welcher Domain das CA-Zertifikat gelistet ist.
Der Auswerter bzw. Verifizierer 130 erhält das Artefakt 120, entnimmt das CA-Zertifikat und benutzt es zusammen mit seiner Vertrauensrichtlinie (engl. trust policy) 132 als Eingabe (engl. input) des Auswertungsalgorithmus. Die Vertrauensrichtlinie (engl. trust policy) 132 referenziert die Domainnamen mehrerer Listen von möglicherwiese verschiedenen Vertrauensschemastellen (TSAs) 122. Der Auswertungsalgorithmus tätigt dann eine Serie von DNS-Abfragen unter Verwendung eines validierenden DNS Auflösers (engl. DNS resolver) 134.
3 zeigt eine schematische Ansicht eines Ausführungsbeispiels bei dem ein Vertrauensstatus eines elektronischen Artefakts 120 überprüft wird. In 3 ist das elektronische Artefakt 120 eine SAML Erklärung bzw. Behauptung. Mit anderen Worten, 3 zeigt ein Beispiel vom föderierten Identitätsmanagement. Hier entscheidet eine Vertrauensschemastelle (engl. trust scheme authority (TSA)) 122, welche Identitätenbereitsteller (engl. Identity providers (IdPs)) 136 oder Artefaktausgeber 136 vertrauenswürdig sind (was einen Vertrauenskreis (engl. circle of trust) definiert). Dies wird typischerweise über Regulierung und Überwachung erreicht. Vertrauenswürdige Identitätenbereitsteller (IdPs) 136 werden dann von der Vertrauensschemastelle (TSA) 122 zertifiziert, indem die IdP-Zertifikate in DNS-basierte Listen eingetragen werden, beispielsweise auf einem DNS Server 126.
Der Identitätenbereitsteller (IdP) 136 gibt dann SAML Erklärungen bzw. Behauptungen aus, welche er mit seinem Zertifikat signiert. Das Artefakt 120 umfasst dann die SAML Erklärung bzw. Behauptung und das IdP-Zertifikat. Optional kann der Identitätenbereitsteller (IdP) 136 in der Erklärung bzw. Behauptung (engl. assertion) angeben, unter welchem Host Label und in welcher Domain das IdP-Zertifikat gelistet ist.
Der Auswerter bzw. Verifizierer 130 erhält das Artefakt 120, entnimmt das IdP-Zertifikat und benutzt es zusammen mit seiner Vertrauensrichtlinie (engl. trust policy) als Eingabe (engl. input) des Auswertungsalgorithmus. Die Vertrauensrichtlinie (engl. trust policy) 132 referenziert die Domainnamen mehrerer Listen von möglicherwiese verschiedenen Vertrauensschemastellen (TSAs) 122. Der Auswertungsalgorithmus tätigt dann eine Serie von DNS-Abfragen unter Verwendung eines validierenden DNS Auflösers 134.
4 zeigt eine schematische Ansicht eines Ausführungsbeispiels bei dem ein Vertrauensstatus eines elektronischen Artefakts 120 überprüft wird. In 4 ist das elektronische Artefakt 120 eine digitale Signatur, beispielsweise einer signierten Software.
Hier entscheidet eine Vertrauensschemastelle (engl. trust scheme authority (TSA)) 122, welche Softwarehersteller (Artefaktausgeber) 136 vertrauenswürdig sind. Dies wird typischerweise über Regulierung und Überwachung erreicht. Vertrauenswürdige Softwarehersteller 136 werden dann von der Vertrauensschemastelle (TSA) 122 zertifiziert, indem ihr Software-Zertifikat in DNS-basierte Listen eingetragen wird, beispielsweise auf einem DNS Server 126.
Der Softwarehersteller 136 gibt dann Software aus, welche er mit seinem Zertifikat signiert. Das Artefakt 120 umfasst dann aus die signierten Software inklusive dem Hersteller-Zertifikat. Optional kann der Softwarehersteller 136 in seinem Zertifikat angeben, unter welchem Host Label und in welcher Domain das Hersteller-Zertifikat gelistet ist.
Der Auswerter oder Verifizierer 130 erhält das Artefakt 120, entnimmt das Hersteller-Zertifikat und benutzt es zusammen mit seiner Vertrauensrichtlinie (engl. trust policy) als Eingabe (engl. input) des Auswertungsalgorithmus. Die Vertrauensrichtlinie referenziert die Domainnamen mehrerer Listen von möglicherwiese verschiedenen Vertrauensschemastellen (TSAs) 122. Der Auswertungsalgorithmus tätigt dann eine Serie von DNS-Abfragen unter Verwendung eines validierenden DNS Auflösers 130.
5 zeigt eine schematische Ansicht eines Ausführungsbeispiels bei dem ein Vertrauensstatus eines elektronischen Artefakts 120 überprüft wird. In 5 ist das elektronische Artefakt 120 ein von einem Attestatszertifikat signierten öffentlicher Schlüssel. Mit anderen Worten, 5 zeigt ein Beispiel von Authentisierungsgeräten.
Hier entscheidet eine Vertrauensschemastelle (engl. trust scheme authority (TSA)) 122, welches Gerät 140 auf welcher Stufe vertrauenswürdig ist. Dies wird typischerweise über Regulierung und Überwachung erreicht. Vertrauenswürdige Geräte 140 werden dann von der Vertrauensschemastelle (TSA) 122 zertifiziert, indem ihr Attestierungszertifikat in DNS-basierte Listen eingetragen werden, beispielsweise auf einem DNS Server 126.
Der Hersteller 142 produziert Authentisierungsgeräte 140, so dass diese ein Attestierungszertifikat mit passendem, gut geschützten privatem Schlüssel enthalten. Das Gerät 140 generiert dann zufällige Schlüsselpaare für eine Authentisierung und kann öffentliche Authentisierungsschlüssel mit dem Attestierungszertifikat signieren, um zu beweisen, dass der Authentisierungsschlüssel von diesem Gerät 140 herrührt. Das Artefakt 120 umfasst dann den signierten Authentisierungsschlüssel und das Attestierungszertifikat. Optional kann der Hersteller 142 im Attestierungszertifikat angeben, unter welchem Host Label und in welcher Domain dieses gelistet ist.
Der Auswerter bzw. Verifizierer 130 erhält das Artefakt 120, entnimmt das Attestierungszertifikat und benutzt es zusammen mit seiner Vertrauensrichtlinie (engl. trust policy) 132 als Eingabe (engl. input) für den Auswertungsalgorithmus. Die Vertrauensrichtlinie 132 referenziert die Domainnamen mehrerer Listen von möglicherwiese verschiedenen Vertrauensschemastellen (TSAs) 122. Der Auswertungsalgorithmus tätigt dann eine Serie von DNS-Abfragen unter Verwendung eines validierenden DNS Auflösers 130.
Ausführungsbeispiele der vorliegenden Erfindung ermöglichen es das existierende Domain Name System und dessen Infrastruktur für eine globale und generische (d. h. für arbiträre Anwendungsgebiete) Vertrauensinfrastruktur zu verwenden.
Ausführungsbeispiele haben den Vorteil, dass der Standardmechanismus, mit dem Vertrauensschemastellen (TSA) Listen von vertrauenswürdigen Artefakten publizieren können, die Erstellung der herkömmlichen Listen ersetzen oder zumindest komplementieren kann. Dadurch wird das Problem der unterschiedlichen Auslegung der gegenwärtigen komplexen Standards für Vertrauenslisten und die damit verbundenen Interoperabilitätsprobleme gelöst (z. B. bei TSLs für qualifizierte Zertifikate).
Ferner haben Ausführungsbeispiele den Vorteil, dass Auswerter bzw. Verifizierer entlastet werden können indem sie beispielsweise keine aufwändigen lokalen Speicher erstellen müssen und nicht für die Sicherheit der Bereitstellung vieler Vertrauensanker verantwortlich sind. Diese Vereinfachung trifft auch dann zu, wenn lokale Abweichungen von Standard Vertrauensschemata (engl. trust schemes) nötig sind, z. B. durch die Definition von zusätzlichen lokalen weißen und schwarzen Listen.
Darüber hinaus haben Ausführungsbeispiele den Vorteil, dass die Verwendung einer einzigen generischen und globalen Infrastruktur einen Skaleneffekt (engl. economy of scale) ermöglicht, welcher die Einführung beliebiger vertrauensrelevanter Technologien und Systeme drastisch erleichtert.
Des Weiteren haben Ausführungsbeispiele den Vorteil, dass die Wiederverwendung von politischen Vereinbarungen, von Führung bzw. Regierung (engl. governance), von Registrierungsbehörden, von globaler Infrastruktur, und von ausgereifter Software die Realisierung eine operativen globalen und generischen Vertrauensinfrastruktur mit vertretbarem Aufwand und in begrenzten Zeitrahmen ermöglicht.
Bei Ausführungsbeispielen können zur Ermittlung des Host Labels, neben dem Zertifikat oder Schlüssel, noch weitere Datenelemente berücksichtigt werden. Beispielsweise kann bei einer anonymen Beglaubigung (engl. attestation) ein signiertes Datenelement eine Vertrauensstufe angeben, das in der Ermittlung des Host Labels berücksichtigt werden muss.
Bei Ausführungsbeispielen können die Subdomain optional weitere Resource Records zugewiesen werden. Beispielsweise könnte eine Subdomain in einem TXT Resource Record angeben, wo eine alternative ETSI TSL gefunden werden kann oder Hinweise über die Semantik der Subdomain enthalten, z. B. ob es sich um eine weiße oder schwarze Liste handelt.
Bei Ausführungsbeispielen können zusätzlich zum TLSA Resource Record auch andere Resource Records dem Host Label zugewiesen werden und zur Bestimmung des Vertrauensstatus verwendet werden. Beispielsweise könnte ein TXT Resource Record einen Vertrauenslevel (engl. assurance level) angeben oder für die Validierung von archivierten Signaturen Information über die historische Gültigkeitsperiode des Zertifikats enthalten.
Bei Ausführungsbeispielen können die Subdomain und möglicherweise der Host Label für ein Zertifikat oder Schlüssel mit andern Methoden bereitgestellt werden. Anders als beim Vertrauensmitgliedschaftsanspruch (engl. trust membership claim), bei dem beispielsweise ein Zertifikatausgeber im Zertifikat selbst (z. B. in den Feldern „Inhaberalternativname” (engl. subject alt name) oder „Ausgeberalternativname” (engl. issuer alternative name)) Host Label und Subdomain des Zertifikats angeben kann, ist es beispielsweise auch möglich, dass ein Zertifikat- oder Schlüsselausgeber die Subdomain auf einer Webseite angibt.
Bei Ausführungsbeispielen kann eine Organisation teilweise die Definition des Vertrauensstatus an eine andere Organisationen delegieren indem die Organisation über DNS üblichen Methoden die Verwaltung von Subdomains an Dritte delegiert.
Bei Ausführungsbeispielen können die Host Labels in Zusammenhang mit der Bestimmung des Vertrauensstatus über mehrere Subdomains verteilt werden, um Unterschiede im Vertrauensstatus auszudrücken. Beispielsweise können verschiedene Subdomains genutzt werden, um verschiedene Vertrauenslevel bzw. Vertrauensstufen auszudrücken.
Bei Ausführungsbeispielen kann eine speziell eingerichtete Subdomain Host Labels enthält, welchen CNAME Resource Records zugewiesen werden, zum Zweck der effizienten Bestimmung der Basis-Domain, in welcher der TLSA Resource Record eines Host Labels gefunden werden kann.
Bei Ausführungsbeispielen wird nur der Hashwert (engl. digest) des Zertifikats oder Schlüssels über das DNS publiziert bzw. veröffentlicht. Bei Ausführungsbeispielen erhält ein Auswerter bzw. Verifizierer also nicht das Zertifikat oder den Schlüssel vom DNS sondern nur den Hashwert. Also statt das Zertifikat vom DNS zu erhalten, hat der Verifizierer ein Zertifikat von einer anderen Quelle erhalten und verifiziert nur durch den Hashwert, ob dieses Zertifikat in der Liste des DNS Domainbetreibers ist. Mit anderen Worten, bei Ausführungsbeispielen hat der Verifizierer schon ein Zertifikat erhalten und kontrolliert nur über den Hashwert, ob es in einer im DNS publizierten Liste enthalten ist. Das Resultat der DNS Abfrage ist dabei nur der Hashwert (DNS TLSA Resource Record) und nicht das Zertifikat (DNS CERT Resource Record). Bei Ausführungsbeispielen dient der TLSA Resource Record dazu, ein Zertifikat oder Schlüssel eindeutig zu verifizieren. Hierzu können mehrere Methoden verwendet werden, wie z. B. verschiedene Digests/Hashalgorithmen.
Im Folgenden werden Ausführungsbeispiele der vorliegenden Erfindung beschrieben, die sich auf eine Vertrauensinfrastruktur (engl. trust infrastructure) auf der Basis von DNSSEC beziehen.
Die Handhabung von Trust- bzw. Vertrauen-Fragen ist für eine Vielzahl digitaler Systeme, einschließlich Systemen, die sich mit elektronischer Signatur, Authentifizierung oder dem Signieren von Anwendungen beschäftigen, von zentraler Bedeutung. Der übliche Ansatz bei der Vertrauenshandhabung ist die Verwendung möglicherweise signierter Vertrauenslisten und Vertrauensspeicher, die vertrauenswürdige Ausgeber aufzählen. Dieser Ansatz lasst sich nicht gut skalieren und ist so ungeeignet für die Implementierung größerer Vertrauensinfrastruktur, wie beispielsweise zur Unterstützung einer regionalen Authentifizierungsinfrastruktur, die eine große Auswahl von Diensten ermöglicht.
Ausführungsbeispiele der vorliegenden Erfindung verwenden das DNS (Domain Name System, dt. Domain-Name-System) mit Sicherheitserweiterung (DNSSEC) als Basis für die Erzeugung einer global skalierbaren und flexiblen Vertrauensinfrastruktur. Im Gegensatz zu Vertrauenslisten oder Vertrauensspeichern stellt es außerdem einen Träger für die wirksame und sichere Verbreitung von Vertrauensinformationen unter Teilhabern bereit.
Vertrauensentscheidungen sind bei der Identitäts- und Zugriffshandhabung entscheidend. Während der Begriff „Trust” bzw. „Vertrauen” überladen ist, bezieht er sich hierin auf die Entscheidung, ob eine bestimmte Aussage (engl. assertion) einen Zugriff auf eine Ressource rechtfertigt oder ob dieser mit einer Fehlernachricht zurückgewiesen werden muss.
Obwohl die Details dessen, wie Vertrauen zu handhaben ist, ein zentrales Thema sind, sind sie oft aus dem Rahmen von Standards und Systemen ausgeschlossen. Dies ist beispielsweise in [S. Cantor, „TrustManagement", Shibboleth, 25-Jan-2010; https://wiki.shibboleth.net/confluence/display/SHIB2/TrustManagement] für den Fall des SAML 2.0-Standards und das Shibboleth-System dokumentiert. Stattdessen sind letztendlich die Benutzer der Technologie dafür verantwortlich, wie sie eine Vertrauenshandhabung tatsächlich implementieren.
Die häufigsten Ansätze zur Vertrauenshandhabung sind lokale Vertrauensspeicher und Vertrauenslisten. Insbesondere für größere Systeme stellen sie für die auf sie vertrauenden Parteien, die Vertrauensdaten (beispielsweise Zertifikate oder Vertrauenslisten) sicher bereitstellen müssen, diese aktualisiert halten müssen, und für einzelne Vertrauensentscheidungen abfragen müssen, eine große Last dar.
Um diese Probleme zu überwinden, verwenden Ausführungsbeispiele der vorliegenden Erfindung das DNS, das sehr gut skaliert, die Last darauf vertrauende Parteien lindert und sehr effiziente Abfragen zum Unterstützen einzelner Vertrauensentscheidungen ermöglicht.
Während der vorgeschlagene Ansatz in vielen Bereichen anwendbar ist, ist die nachfolgende Beschreibung zur Vereinfachung auf den Anwendungsfall einer förderierten Authentifizierung bezogen. Insbesondere empfängt eine darauf vertrauende Partei eine Aussage von einem Identitätsbereitsteller (engl. identity provider) und muss bestimmen, ob diese Aussage vertrauenswürdig ist.
Das STORK-Projekt [Körting Stephan and Diana Ombelli, „Mapping Security Services to authentication levels – Reflecting an STORK QAA levels", 2011] ist ein Beispiel dafür, wie Ausgeber von Identitäten zur Authentifizierung in verschiedenen Vertrauensschemata (Ebene 1 bis 4) gehandhabt werden können, die bestimmt wurden durch nationale Vertrauensschemaautoritäten.
Zunächst werden die Nachteile von Vertrauenslisten erläutert, die für eine Vertrauenshandhabung im großen Rahmen momentan die häufigste Lösung sind. Dann werden neuere Technologien auf DNS-Basis beschrieben.
Ausführungsbeispiele der vorliegenden Erfindung konzentrieren sich auf eine global skalierbare Vertrauensinfrastruktur, die eine offene Anzahl von Vertrauensschemata von beliebigen Ausgebern unterstützt. Auf sie vertrauende Parteien nutzen Vertrauensschemata, um individuelle Vertrauensentscheidungen zu treffen.
Die häufigste Lösung für dieses Problem sind signierte Vertrauenslisten (engl. trust service lists (TSL)) [„ETSI TS 102 231 V3.1.2 (2009–12) Electronic Signatures and Infrastructures (ESI); Provision of harmonized Trust-service status information" ETSI, Dec-2009].
Eines der bekanntesten Beispiele sind qualifizierte Zertifikate, die durch die europäische Kommission verwaltet werden, in Unterstützung einer rechtlich bindenden Signatur [Martens, Tarvi, Keskel, Maili, Hühnlein, Detlef, Özmü, Eray, Ituarte, Nuria und Rath, Christof, „D43.2 – Trust Service-Requirements Analysis" FutureID, http://futureid.eu/data/deliverables/year1/Public/FutureID_D43.02_WP43_v0.7_Requirem ents%20analysis.pdf, 11-Dec-2013]. Die TSL der Kommission beinhaltet Zeiger, die die Ausgabe nationaler TSLs an Mitgliedsstaaten delegieren, die Daten akkreditierter Ausgeber von qualifizierten Zertifikaten beinhalten. Dieses einzelne Vertrauensschema wird so durch mehrere TSLs implementiert.
Bei Verwendung von TSLs muss eine auf sie vertrauende Partei die europäische und alle nationalen TSLs lokalisieren und herunterladen und aktualisiert halten. Für einzelne Vertrauensentscheidungen ist ein wirksamer Mechanismus zum Abfragen der Daten, die in den verschiedenen TSLs beinhaltet sind, erforderlich.
Wenn angenommen wird, dass in einem Kontext eine auf sie vertrauende Partei eine erhebliche Anzahl von Vertrauensschemata handhaben muss, brauchen auf sie vertrauende Parteien auch einen sicheren Mechanismus zum Lokalisieren der authentischen TSLs der verschiedenen Ausgeber.
Ausführungsbeispiele lindern die Last der vertrauenden Parteien wie folgt. Ausgeber von TSLs veröffentlichen ihre Daten über DNS. Einzelne Entscheidungen können so auf einer hocheffizienten einzelnen DNS-Abfrage basieren. Die auf sie vertrauenden Parteien werden um die Handhabung von Updates erleichtert. Außerdem wird der Domainname verwendet, um die erwünschten Vertrauensdaten sicher zu lokalisieren, was so die Bereitstellung von Vertrauensankern stark vereinfacht. Das DNS stellt außerdem native Mechanismen zum Delegieren bereit.
Die hierin vorgeschlagene Vertrauensinfrastruktur verwendet den TLSA Resource Record von DANE (DANE = DNS-based Authentication of Named Entities, dt. DNS-basierte Authentifizierung genannter Entitäten, RFC 6698), die auch das DNS mit seiner Sicherheitserweiterung verwendet, aber ohne die Verwendung der obigen Host Labels und zur Unterstützung von Web Browsern welche Trust bzw. Vertrauen in TLS-Server-Zertifikaten handhaben müssen.
Im Folgenden wird beschrieben, wie das DNS zur Vertrauenshandhabung in Aussagen (engl. assertions) verwendet wird.
6 zeigt die drei Teilhaber- und Systemkomponenten. IdPs (Identity Providers, dt. Identitätsbereitsteller) 136 und eine darauf vertrauende Partei sind aus der föderierten Identitätshandhabung bekannt. Die Vertrauensschemaautorität (engl. trust scheme authority) 122 bewertet IdPs 136 und veröffentlicht, welche IdPs 136 sich als vertrauenswürdig herausgestellt haben. Zu diesem Zweck betreiben sie einen DNS-Server 126; darauf vertrauende Parteien 130 verwenden einen DNS-Auflöser 134.
In 6 empfängt eine darauf vertrauende Partei 130 eine Aussage 120 von dem Identitätsbereitsteller 136. Die darauf vertrauende Partei 130 kann diese Aussage basierend auf ihrem Ausgeber-Zertifikat und einer Vertrauensrichtlinie (engl. trust policy) validieren. Die Vertrauensrichtlinie bestimmt die Vertrauensschemata, zu denen ein akzeptabler IdP 136 gehören kann. Ob ein bestimmter IdP 136 zu einem bestimmten Schema gehört, wird über eine DNS-Abfrage festgestellt, bei der das Schema einer DNS-Domain entspricht, und ein Ausgeber einem Host. Wenn der IdP 136 in dem Schema beinhaltet ist, gibt die Abfrage einen Hashwert des Ausgeber-Zertifikats zurück.
Im Folgenden wird die Veröffentlichung von Sätzen von Zertifikaten durch Vertrauensschemaautoritäten beschrieben.
Dieser Absatz beschreibt, wie Vertrauensschemaautoritäten (engl. trust scheme authorities; TSAs) das DNS zur Veröffentlichung von Sätzen von IdP-Zertifikaten verwenden.
Eine Vertrauensschemaautorität wird durch ihren Domainnamen eindeutig identifiziert. Die Vertrauensschemaautorität der Europäischen Kommission beispielsweise könnte tsa.ec.eu verwenden. Eine Vertrauensschemaautorität kann mehrere Vertrauensschemata handhaben. Jedes Schema ist durch einen Unterbereich (Subdomain) dargestellt. Die Europäische Kommission kann beispielsweise ein Schema zu Authentifizierung unter auth.tsa.ec.eu handhaben. Wahlweise kann ein Vertrauensschema in mehrere Unterschemata unterteilt sein, wie z. B. level1.auth.tsa.ec.eu bis level4.auth.tsa.ec.eu.
Es ist üblich, dass eine Vertrauensschemaautorität die Autorität an geografische oder andere Arten von Unterautoritäten delegiert. Wieder kann dies unter Verwendung üblicher Mechanismen, die durch das DNS bereitgestellt werden, mit der Hilfe von Subdomains ausgedrückt werden: at.level1.auth.tsa.ec.eu, uk.level4.auth.tsa.ec.eu, usw.
Sobald alle nötigen Schemata und Unterschemata definiert sind, können die entstehenden Subdomains mit IdP-Zertifikaten bestückt werden. Zur Verwendung des DNS als Verbreitungsträger können so Zertifikate auf Host Label abgebildet werden.
Es gibt mehrere Optionen dafür, wie Zertifikate auf DNS Host Label abgebildet werden können. Für eine beispielhafte Prototyp-Implementierung der Vertrauensinfrastruktur kann z. B. der Basis32-codierte Auszug des Zertifikats betrachtet werden. Ein Beispiel für ein Host Label ist PX2NO4LVPA4WHCBLYXHIKRWVRE.at.level4.auth.tsa.ec.eu.
Im Folgenden wird die Validierung elektronischer Artefakte beschrieben.
Eine darauf vertrauende Partei, die ein elektronisches Artefakt empfängt, muss verifizieren, ob ihr Zertifikat durch die Vertrauensrichtlinie erlaubt ist. Der Vertrauenszugehörigkeitsanspruch (engl. trust membership claim), die durch den Ausgeber bereitgestellt wird, unterstützt eine effiziente Validierung des Artefakts in zwei Schritten:

– Verifizieren, dass die geforderte Zugehörigkeit die Richtlinie (engl. policy) erfüllt,
– Validieren der geforderten Zugehörigkeit relativ zu einem lokal definierten Satz, oder entfernt, mit einer Vertrauensschemaautorität.

In dem Fall, in dem der Satz durch eine Vertrauensschemaautorität definiert ist, bietet das DNS mit DNSSEC-Erweiterung alle nötigen Mechanismen zum sicheren Validieren einer Zugehörigkeit. Das DNSSEC macht es möglich. Daten über eine Satzzugehörigkeit sicher zu übertragen, und zwar in dem Sinn, dass die darauf vertrauende Partei verifizieren kann, dass die Informationen durch die Vertrauensschemaautorität bereitgestellt wurden, die den entsprechenden Domainnamen steuert, und dass die Daten beim Übergang nicht manipuliert wurden. Das DNSSEC ermöglicht außerdem, dass eine Vertrauensschemaautorität die Abwesenheit eines Zertifikats bei einem ihrer Sätze geltend machen kann.
Es ist bewiesen, dass das DNS mit seinen Delegierungs- und Cachespeicherungsmechanismen diese Arten von Abfragen in einer global skalierbaren Weise löst.
Darauf vertrauende Parteien benötigen eine Sprache auf hoher Ebene, um auszudrücken, welchen Ausgebern elektronische Artefakte sie vertrauen. Ein Schlüsselelement zum Erreichen einer hohen Ebene an Ausdruckskraft besteht darin, benannte Sätze von Zertifikaten zu verwenden, und nicht einzelne Zertifikate aufzuzählen. Dies liefert eine einfache, jedoch ausdrucksstarke Sprache zum Ausdruck der Vertrauensrichtlinie. Ein Beispiel für eine Vertrauensrichtlinie könnte folgendermaßen aussehen:
Im Folgenden werden die Vertrauenszugehörigkeitsforderungen durch Ausgeber beschrieben.
Zur Unterstützung einer effizienten Verifizierung elektronischer Artefakte sollte ihr Ausgeber Mechanismen verwenden, die darauf vertrauenden Parteien anzeigen, dass sie in einem bestimmten Vertrauensschema durch eine bestimmte Autorität zertifiziert wurden. Dies wird hierin Vertrauenszugehörigkeit genannt.
Im besten Fall ist die Subdomain der Vertrauensschemaautorität bereits in dem Zertifikat beinhaltet oder der öffentliche Schlüssel ist direkt in der Aussage aufgelistet. Abhängig von der Aussage könnte dies unterschiedlich erzielt werden. Die Felder „Inhaberalternativname” (engl. subject alt name) oder „Ausgeberalternativname” (engl. issuer alt name) in einem Zertifikat könnten verwendet werden, um die jeweiligen Informationen anzugeben (z. B. issuerAltName: PX2NO4IVPA4WHCBLYXHIKRWVRE.it.qualified-white.tsa.ec.eu). In SAML-Aussagen könnten die gleichen Informationen in eines der verfügbaren Felder eingefügt werden. Die Vertrauenszugehörigkeitsforderungen könnten sich auch in einer spezifischen Domain des Webservers des Ausgebers befinden. Dies kann jedoch an einem standardisierten Ort relativ zu der Domain des Ausgebers sein (beispielsweise www.someissuer.de/tsa-meta.txt).
Bei Ausführungsbeispielen können die Vertrauenszugehörigkeitsansprüche nicht sicherheitsrelevant, und deshalb nicht signiert sein, da Vertrauenszugehörigkeitsansprüche durch die darauf vertrauenden Parteien verifiziert werden.
Ausführungsbeispiele der vorliegenden Erfindung beschreiben einen Ansatz auf DNS-Basis zum Handhaben einer global skalierbaren Vertrauensinfrastruktur. Er betrifft den Anwendungsbereich, der momentan durch Vertrauenslisten (TSLs) abgedeckt ist, und fügt einen Träger zum effizienten Abfragen und zur Validierung einzelner Elemente derartiger Listen hinzu, wobei so der Bedarf nach dem Betrieb eines lokalen Zwischenspeichers von Daten mit einer möglicherweise größeren Anzahl derartiger Listen und die Komplexität dessen, einen derartigen Zwischenspeicher aktualisiert zu halten, vermieden werden. Zur Ermöglichung eines Einsatzes im großen Rahmen nutzt die vorgeschlagene Infrastruktur die existierende globale Namensregistrierung, die durch das DNS bereitgestellt wird, und die existierenden DNSSEC-Vertrauensanker.
Ausführungsbeispiele der vorliegenden Erfindung nutzen das DNS. Viele RFCs der IETF beschreiben das DNS, wie z. B. die RFCs „Domain Names – Concepts and Facilities” und ”Domain Names – Implementation and Specification”. RFCs, die das DNSSEC beschreiben, sind RFC 4033 "DNS Security Introduction and Requirements", RFC 4034 "Resource Records for the DNS Security Extensions" und RFC 4035 "Protocol Modifications for the DNS Security Extensions". Ein RFC für DANE ist das RFC 6698 "The DNS-Based Authentication of Named Entities (DANE). Transport Layer Security (TLS) Protocol: TLSA”.
Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar. Einige oder alle der Verfahrensschritte können durch einen Hardware-Apparat (oder unter Verwendung eine Hardware-Apparats), wie zum Beispiel einen Mikroprozessor, einen programmierbaren Computer oder eine elektronische Schaltung. Bei einigen Ausführungsbeispielen können einige oder mehrere der wichtigsten Verfahrensschritte durch einen solchen Apparat ausgeführt werden.
Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einem programmierbaren Computersystem derart zusammenwirken können oder zusammenwirken, dass das jeweilige Verfahren durchgeführt wird. Deshalb kann das digitale Speichermedium computerlesbar sein.
Manche Ausführungsbeispiele gemäß der Erfindung umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird.
Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Computerprogrammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahin gehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer abläuft.
Der Programmcode kann beispielsweise auch auf einem maschinenlesbaren Träger gespeichert sein.
Andere Ausführungsbeispiele umfassen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren, wobei das Computerprogramm auf einem maschinenlesbaren Träger gespeichert ist. Mit anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens somit ein Computerprogramm, das einen Programmcode zum Durchführen eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm auf einem Computer abläuft.
Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Verfahren ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
Ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen, der bzw. die das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom oder die Sequenz von Signalen kann bzw. können beispielsweise dahin gehend konfiguriert sein, über eine Datenkommunikationsverbindung, beispielsweise über das Internet, transferiert zu werden.
Ein weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die dahin gehend konfiguriert oder angepasst ist, eines der hierin beschriebenen Verfahren durchzuführen.
Ein weiteres Ausführungsbeispiel umfasst einen Computer, auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren installiert ist.
Ein weiteres Ausführungsbeispiel gemäß der Erfindung umfasst eine Vorrichtung oder ein System, die bzw. das ausgelegt ist, um ein Computerprogramm zur Durchführung zumindest eines der hierin beschriebenen Verfahren zu einem Empfänger zu übertragen. Die Übertragung kann beispielsweise elektronisch oder optisch erfolgen. Der Empfänger kann beispielsweise ein Computer, ein Mobilgerät, ein Speichergerät oder eine ähnliche Vorrichtung sein. Die Vorrichtung oder das System kann beispielsweise einen Datei-Server zur Übertragung des Computerprogramms zu dem Empfänger umfassen.
Bei manchen Ausführungsbeispielen kann ein programmierbares Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray, ein FPGA) dazu verwendet werden, manche oder alle Funktionalitäten der hierin beschriebenen Verfahren durchzuführen. Bei manchen Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray mit einem Mikroprozessor zusammenwirken, um eines der hierin beschriebenen Verfahren durchzuführen. Allgemein werden die Verfahren bei einigen Ausführungsbeispielen seitens einer beliebigen Hardwarevorrichtung durchgeführt. Diese kann eine universell einsetzbare Hardware wie ein Computerprozessor (CPU) sein oder für das Verfahren spezifische Hardware, wie beispielsweise ein ASIC.
Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.
Die Forschungsarbeiten, die zu diesen Ergebnissen geführt haben, wurden gemäß der Finanzhilfevereinbarung Nr. 318424 im Zuge des Siebten Rahmenprogramms der Europäischen Union (RP7/2007–2013) gefördert.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

ETSI TSL, European Telecommunications Standards Institute Trust Service Lists [0006]
RFC 6698 [0025]
S. Cantor, „TrustManagement”, Shibboleth, 25-Jan-2010; https://wiki.shibboleth.net/confluence/display/SHIB2/TrustManagement [0091]
SAML 2.0-Standards [0091]
Körting Stephan and Diana Ombelli, „Mapping Security Services to authentication levels – Reflecting an STORK QAA levels”, 2011 [0095]
„ETSI TS 102 231 V3.1.2 (2009–12) Electronic Signatures and Infrastructures (ESI); Provision of harmonized Trust-service status information” ETSI, Dec-2009 [0098]
Martens, Tarvi, Keskel, Maili, Hühnlein, Detlef, Özmü, Eray, Ituarte, Nuria und Rath, Christof, „D43.2 – Trust Service-Requirements Analysis” FutureID, http://futureid.eu/data/deliverables/year1/Public/FutureID_D43.02_WP43_v0.7_Requirem ents%20analysis.pdf, 11-Dec-2013 [0099]
RFC 6698 [0103]
RFC 4033 ”DNS Security Introduction and Requirements” [0123]
RFC 4034 ”Resource Records for the DNS Security Extensions” [0123]
RFC 4035 ”Protocol Modifications for the DNS Security Extensions” [0123]
RFC 6698 ”The DNS-Based Authentication of Named Entities (DANE) [0123]
Finanzhilfevereinbarung Nr. 318424 im Zuge des Siebten Rahmenprogramms der Europäischen Union (RP7/2007–2013) [0137]

Claims

Verfahren (100) zur Überprüfung eines Vertrauensstatus eines Zertifikats oder Schlüssels, wobei das Verfahren folgende Schritte aufweist: Ermitteln (102) eines Hashwerts für das Zertifikat oder den Schlüssel; Ermitteln (104) eines Host Labels aus dem Zertifikat oder Schlüssel; Abfragen (106) eines DNS Resource Records unter Verwendung des Host Labels, wobei der DNS Resource Record einen Soll-Hashwert des Zertifikats oder Schlüssels aufweist; und Vergleichen (108) des Hashwerts des Zertifikats oder Schlüssels mit dem Soll-Haschwert, um den Vertrauensstatus des Zertifikats oder Schlüssels zu überprüfen.
Verfahren (100) nach Anspruch 1, wobei DNS Resource Record ein TLSA Resource Record ist.
Verfahren (100) nach Anspruch 1 oder 2, wobei das Abfragen (106) des DNS Resource Records unter Verwendung einer Kombination aus dem Host Label und einer Subdomain erfolgt.
Verfahren (100) nach Anspruch 3, wobei bei dem Abfragen (106) des DNS Resource Records der Host Label der Subdomain vorangestellt wird.
Verfahren (100) nach Anspruch 4, wobei die Kombination aus Host Label und Subdomain folgende Syntax aufweist: HostLabel.Subdomain wobei die Kombination von HostLabel und Subdomain einen FQDN repräsentiert.
Verfahren (100) nach einem der Ansprüche 2 bis 5, wobei mehrere Host Label in derselben Subdomain enthalten sind und jedem Host Label mindestens ein Resource Record zugewiesen ist.
Verfahren (100) nach einem der Ansprüche 1 bis 6, wobei bei dem Abfragen (106) des DNS Resource Records der DNS Resource Record bei einer Kombination aus einem vorgegebenen Host Label und einer vorgegebenen Subdomain abgefragt wird.
Verfahren (100) nach einem der Ansprüche 1 bis 6, wobei das Verfahren (100) ferner folgende Schritte aufweist: Ermitteln eines Host Labels und einer Sub-Domain, unter welchen der DNS Resource Record abzufragen ist, aus dem Zertifikat; wobei bei dem Abfragen (106) des DNS Resource Records der DNS Resource Record bei einer Kombination aus dem ermittelten Host Label und der ermittelten Subdomain abgefragt wird.
Verfahren (100) nach einem der Ansprüche 1 bis 7, wobei bei dem Abfragen (106) des DNS Resource Records für einen Host Label eine Mehrzahl von DNS Resource Records bei unterschiedlichen Subdomains abgefragt werden.
Verfahren (100) nach einem der Ansprüche 1 bis 8, wobei eine Subdomain, unter welcher der DNS Resource Record abgefragt wird eine Ausprägung des Vertrauensstatus anzeigt.
Verfahren (100) nach Anspruch 10, wobei unterschiedliche Ausprägungen des Vertrauensstatus durch unterschiedliche Subdomains angezeigt werden.
Verfahren (100) nach einem der Ansprüche 1 bis 7 und 9 bis 11, wobei der DNS Resource Record und das Zertifikat oder der Schlüssel von unterschiedlichen Einrichtungen oder Personen bereitgestellt werden.
Verfahren (100) nach einem der Ansprüche 1 bis 12, wobei zur Ermittlung des Host Labels, neben dem Zertifikat oder Schlüssel, noch weitere Datenelemente berücksichtigt werden.
Verfahren (100) nach einem der Ansprüche 1 bis 13, wobei der Subdomain und/oder dem Host Label weitere Resource Records zugewiesen sind.
Verfahren (100) nach einem der Ansprüche 1 bis 14, wobei zusätzlich zu dem DNS Resource Record zumindest ein weiteres DNS Resource Record, das dem Host Label zugewiesen ist, zur Bestimmung des Vertrauensstatus verwendet wird, wobei das DNS Resource Record und der zumindest eine weitere DNS Resource Record unterschiedlich sind.
Verfahren (100) nach einem der Ansprüche 1 bis 15, wobei die Subdomain und der Host Label für ein Zertifikat oder Schlüssel mit andern Methoden bereitgestellt werden.
Verfahren (100) nach einem der Ansprüche 1 bis 16, wobei eine Organisation teilweise die Definition des Vertrauensstatus an andere Organisationen delegiert, indem es über DNS üblichen Methoden die Verwaltung von Subdomains an Dritte delegiert.
Verfahren (100) nach einem der Ansprüche 1 bis 17, wobei eine Subdomain Host Labels enthält, welchen CNAME Resource Records zugewiesen sind, um eine effiziente Bestimmung der Subdomain, in der der Resource Record zur Bestimmung des Vertrauensstatus des selben Host Labels gelistet ist, zu ermöglichen.
Verfahren nach einem der Ansprüche 1 bis 18, wobei das Vertrauen in die DNS Resource Records über die DNSSEC-üblichen Vertrauenskette von Signaturen vom DNS Rootzonenschlüssel abgeleitet wird.
Computerprogramm zur Durchführung eines Verfahrens gemäß einem der Ansprüche 1 bis 19.