Public-Key-Infrastrukturen

Transkript

1 TECHNISCHE UNIVERSITÄT DARMSTADT FACHGEBIET THEORETISCHE INFORMATIK PROF. DR. J. BUCHMANN J. BRAUN 7. Übung zur Vorlesung Public-Key-Infrastrukturen Sommersemester 2012 Aufgabe 1: Smartcards Wir betrachten folgendes Szenario: Sie wollen auf Ihrem PC eine verschicken und diese zur Wahrung der Authentizität digital signieren. Zur Erstellung der Signatur verwenden Sie eine Smartcard mit einem geeigneten Signaturschlüssel und ein Kartenlesegerät (Class 3) mit eingebauter Tastatur und einem Display (2*12 Zeichen). Sie erstellen also zunächst die in Ihrem Mailclient und setzen dann den Signiervorgang in Gang. Skizzieren Sie den Verlauf der Signaturerstellung! Insbesondere soll daraus hervorgehen, welche Daten wo errechnet werden, wohin sie übertragen werden und in welcher Reihenfolge dies geschieht. Aufgabe 2: Smartcards (2) Die Smartcard E4 NetKey der Firma Telesec wird, wie in den Folien beschrieben, mit drei Schlüsselpaaren ausgeliefert. Dabei ist je eines für die Erlangung der Schutzziele Authentizität (z.b. Zugriff auf eine Webseite via SSL mit Clientauthentifizierung), Nicht-Abstreitbarkeit (z.b. Signatur eines Kaufvertrages) und Vertraulichkeit (z.b. verschlüsselte ) gedacht. Warum ist das sinnvoll? Überlegen Sie sich dafür, wie und wann die privaten Schlüssel jeweils eingesetzt werden! Aufgabe 3: Gültigkeitszeitraum Benutzen Sie für Ihre Antworten auch die Spezifikationen der Zertifikate und Sperrlisten im RFC Diese finden Sie unter oder auf der PKI-Homepage. a) Nennen Sie die Gültigkeitszeiträume der unten angegebenen Zertifikate. b) Müssen diese mit den Gültigkeitszeiträumen der Schlüssel übereinstimmen? Bewerten Sie dabei die keyusage-extension sowie die Informationen der CRL. 1

2 Zertifikat 1 Serial No.: 2593 Jun 2 09:43: GMT Jun 1 22:00: GMT CN=Bob, OU=CDC, OU=FB Informatik, O=TU Darmstadt, C=DE key-0x4599ab34 Subject Alternative Name: bob@cdc.informatik.tu-darmstadt.de Digital Signature Subject Key Identifier: keyidentifier:99:13:d5:fd:90:31:7b:56:7f:bd Authority Key Identifier: keyidentifier:0b:f8:2b:b7:b5:88:c8:03:7e:eb authoritycertcn=master CA, OU=FB Informatik, O=TU Darmstadt, C=DE authoritycertserialnumber:03 verifiable with 0xC37C64C0 (SHA1withRSA) Zertifikat 2 Serial No.: 2594 Jun 2 09:43: GMT Jun 1 22:00: GMT CN=Alice, OU=CDC, OU=FB Informatik, O=TU Darmstadt, C=DE key-0x7773b534 Subject Alternative Name: alice@cdc.informatik.tu-darmstadt.de Encryption Subject Key Identifier: keyidentifier:a2:f4:67:23:28:c2:c8:64:a8:45 Authority Key Identifier: keyidentifier:0b:f8:2b:b7:b5:88:c8:03:7e:eb authoritycertcn=master CA, OU=FB Informatik, O=TU Darmstadt, C=DE authoritycertserialnumber:03 verifiable with 0xC37C64C0 (SHA1withRSA) 2

3 Zertifikat 3 Serial No.: 2595 Apr 25 09:00: GMT Apr 25 09:00: GMT CN=Alice s New Name, OU=CDC, OU=FB Informatik, O=TU Darmstadt, C=DE key-0x7773b534 Subject Alternative Name: alice.new.name@cdc.informatik.tu-darmstadt.de Encryption Subject Key Identifier: keyidentifier:a2:f4:67:23:28:c2:c8:64:a8:45 Authority Key Identifier: keyidentifier:0b:f8:2b:b7:b5:88:c8:03:7e:eb authoritycertcn=master CA, OU=FB Informatik, O=TU Darmstadt, C=DE authoritycertserialnumber:03 verifiable with 0xC37C64C0 (SHA1withRSA) Zertifikat 4 Serial No.: 1 CN=Master CA, OU=FB Informatik, O=TU Darmstadt, C=DE Dec 1 08:59: GMT Dec 1 08:59: GMT CN=Master CA, OU=FB Informatik, O=TU Darmstadt, C=DE key-0xa0906e89 Basic Constraints: CA: TRUE pathlen=1 Digital Signature, Certificate Sign, CRL Sign Subject Key Identifier: keyidentifier:54:23:aa:12:ab:cd:4e:5f:3a:11 Authority Key Identifier: keyidentifier:54:23:aa:12:ab:cd:4e:5f:3a:11 authoritycertcn=master CA, OU=FB Informatik, O=TU Darmstadt, C=DE authoritycertserialnumber:01 verifiable with 0xA0906E89 (SHA1withRSA) 3

4 Zertifikat 5 Serial No.: 3 CN=Master CA, OU=FB Informatik, O=TU Darmstadt, C=DE Dec 1 09:34: GMT Dec 1 09:34: GMT key-0xc37c64c0 Basic Constraints: CA: TRUE pathlen=0 Digital Signature, Certificate Sign, CRL Sign Subject Key Identifier: keyidentifier:0b:f8:2b:b7:b5:88:c8:03:7e:eb Authority Key Identifier: keyidentifier:54:23:aa:12:ab:cd:4e:5f:3a:11 authoritycertcn=master CA, OU=FB Informatik, O=TU Darmstadt, C=DE authoritycertserialnumber:01 verifiable with 0xA0906E89 (SHA1withRSA) CRL A ThisUpdate: Apr 25 11:53: GMT NextUpdate: May 25 11:53: GMT Revoked Certificates: Serial Nr.: 2594 Revocation Date: Apr 25 08:55: GMT Reason: Affiliation Changed Serial Nr.: 2595 Revocation Date: Apr 25 11:52: GMT Reason: keycompromise X509v2 CRL Extensions: CRLNumber: non- 500 verifiable with 0xC37C64C0 Aufgabe 4: CRLs kombinieren Folgende Notation wird in dieser Übung benutzt: F 12 ist die Full-CRL mit der CRLNumber ist die -CRL mit der CRLNumber 45 und hat als Basis-CRL die CRL mit der CRLNumber 30. Bei der Bearbeitung von Full-CRLs oder -CRLs gelten folgende Regeln: F x + y w F y (wenn x w und y x) (1) F x + F y F x F y x y x < y (2) 4

5 Beantworten Sie mit Hilfe dieser Regeln, ob ein Benutzer vollständige Revokationsinformationen für den Zeitpunkt thisupdate der Full-CRL #14 hat. Falls nein, fügen Sie genau eine CRL (ausgenommen F 14 ) ein, damit das möglich ist. a) {F 1, 5 1, 10 5, 12 10, } b) {F 1, 5 1, F 5, F 12, } c) {F 1, 5 2, 10 5, 14 12, } Aufgabe 5: Neues Modell In einer vorherigen Übung wurde ein formales Modell (Modell von Maurer) für ein Web of Trust vorgestellt. Zur Erinnerung: Dieses Modell bietet die Möglichkeit, sich der Authentizität des öffentlichen Schlüssels eines Kommunikationspartners zu versichern. Dies geschieht, indem eine Person selbst schon andere authentische Schlüssel kennt, Personen als vertrauenswürdig ansieht oder Zertifikate und Empfehlungen zu Hilfe nimmt. Dieses Modell reicht nicht aus, um reale Gegebenheiten bzw. Systeme aus der Praxis zu modellieren. Es ist zwar simpel und flexibel, erfährt aber Grenzen in seiner Anwendbarkeit. Denn gewisse Aspekte, die uns in der Realität begegnen, lassen sich mit dem Modell von Maurer nicht darstellen. Wir diskutieren kurz die Eigenschaften dieses Modells und deren Begrenzungen: Es legt großen Wert auf die Authentizität eines öffentlichen Schlüssels. Allerdings ist die Verbindlichkeit zwischen öffentlichem Schlüssel und den Informationen im Zertifikat von großer Bedeutung. Ohne die Zeit als Dimension können die zeitlichen Veränderungen in der PKI (Auslauf von Glauben/Zertifikaten, Revokationen) nicht im Modell abgebildet werden. Die Delegierung von einzelnen Attributen des Zertifikats ist nicht möglich. Entweder wird alles (per Recommendation) weitergegeben oder nichts. In der Praxis kann es aber durchaus sinnvoll sein, nur bestimmte Eigenschaften (Properties) weiterzugeben. Die Verifikation liegt außerhalb der Betrachtung. Durch Ableitungsregeln werden falsche Schlussfolgerungen ermöglicht, wenn ein Zertifikat nicht mehr gültig ist. Wegen der oben genannten Nachteile halten es die Autoren von Modeling Public Key Infrastructure in the RealWorld 1 für zweckmäßig, das Modell zu erweitern, und führen ein neues Konzept ein, welches den Anforderungen realer PKI-Systeme besser gerecht wird. Folgende Elemente sind im Rahmen der Erweiterung des Modells hinzugekommen: Die Authentizität des öffentlichen Schlüssels wird verallgemeinert, um die Verbindlichkeit zwischen öffentlichem Schlüssel und den Zertifikatseigenschaften zu erfassen. Die Zeit wird als Merkmal hinzugefügt, um Revokation und Auslauf modellieren zu können. Hierzu werden zwei Konzepte vorgestellt. Die Lebensdauer (lifespan) einer Aussage (statement) s ist gegeben durch ein Intervall, das vom Zeitpunkt t j bis zum Zeitpunkt t k reicht, also = [t j, t k ]. Zum Zeitpunkt t > t k ist s abgelaufen und in Berechnungen nicht mehr benutzbar. s ist aktiv zum Zeitpunkt t nur dann, wenn t gilt. 1 Verfügbar unter 5

6 Die Domäne (domain) wird benutzt, um eine Menge von Properties anzugeben, die eine zertifikatausstellende Einheit einem Subjekt zuweisen darf. Properties können etwa Attribute des Zertifikats sein, die in den Erweiterungen stehen. Als typisches Beispiel sei die KeyUsage-Extension genannt. Die Domäne ist also alles, für das eine CA bürgen darf. Die Benutzung von Recommendations wird durch das Trust Transfer-Konzept ersetzt, damit eine Teilmenge der Zertifikationseigenschaften weitergegeben werden kann. Validity Templates werden eingeführt, um formatspezifische Definitionen der Gültigkeit einer Aussage zu erfassen. Im erweiterten Modell gibt es somit folgende Schreibweisen für Aussagen über den Kenntnisstand: a) Authentizität der Verbindlichkeit / Authenticity of binding Aut(A, X,, ) bezeichnet den Glauben von A, dass die Einheit X die in enthaltenen Properties während des Intervalls besitzt. b) Vertrauen / Trust Trust(A, X,, ) kennzeichnet den Glauben von A, dass die Einheit X vertrauenswürdig ist bezüglich der Ausstellung von Zertifikaten über die Domäne während des Intervalls. c) Zertifikate / Certificates Cert(X, Y,, ) bedeutet, dass X ein Zertifikat für Y ausgestellt hat, welches die Verbindlichkeit zwischen dem öffentlichen Schlüssel von Y und der Menge von Properties im Intervall sicherstellt. d) Übertragungen von Vertrauen / Trust Transfers Tran(X, Y,, ) besagt, dass Y einen Vertrauensübertrag von X erhalten hat, so dass eine Verbindlichkeit zwischen dem öffentlichen Schlüssel von Y und der Menge von Properties im Intervall besteht. e) Zertifikatsgültigkeitsschablonen / Certificate Validity Templates Valid A, C, t bezeichnet den Glauben von A, dass das Zertifikat C zur Auswertungszeit t gültig ist. f) Übertragungsgültigkeitsschablonen / Transfer Validity Templates Valid A, T, t bezeichnet den Glauben von A, dass die Vertrauensübertragung T zur Auswertungszeit t gültig ist. Eine Aussage ist in diesem erweiterten Modell nur dann gültig, wenn sie entweder in View A enthalten ist oder aus View A abgeleitet werden kann. Die Ableitungsregeln müssen angepasst werden, um diese neuen Elemente nutzen zu können. X, Y, t 0 1, : X, Y, t 0 1, : Aut(A, X,, 0 ), Trust(A, X,, 1 ), Valid A, Cert(X, Y,, 2 ), t Aut(A, Y,, 2 ) (3) Aut(A, X,, 0 ), Trust(A, X,, 1 ), Valid A, Tran(X, Y,, 2 ), t Trust(A, Y,, 2 ) (4) a) i) Warum ist eine Erweiterung des formalen Modells für ein Web of Trust notwendig? ii) Welche Merkmale sind im erweiterten Modell hinzugekommen? Ergänzen Sie die Vergleichstabelle in Tabelle 1, um die Unterschiede zwischen dem ursprünglichen und neuen Modell anhand der zusätzlichen Komponenten deutlich zu machen. b) Gegeben sei folgende Sicht View A = {Aut(A, X,, 0 ), Cert(X, Y,, 2 ), Cert(Y, Z,, 2 ), Tran(X, Y,, 2 ), Tran(Z, B,, 2 ), Trust(A, Z,, 2 ), Trust(A, X,, 1 )} 6

7 PKI-System Maurers Modell erweitertes Modell ermöglichendes neues Merkmal mehrere Formate Revokation Autorisierung Delegierung Zeitverhalten Tabelle 1: Vergleichstabelle von A mit 0 1 und. i) Zeigen Sie, warum A sich sicher sein kann, dass B vertrauenswürdig ist. ii) Für welchen Zeitraum ist B für A vertrauenswürdig? c) Sei View B gegeben als View B = {Aut(B, X,, ), Aut(A, Y,, ), Cert(X, A,, ), Cert(A, C,, ), Tran(X, A,, ), Tran(C, B,, ), Trust(A, Y,, ), Trust(B, C,, ), Trust(B, X,, )}. Entscheiden Sie, ob B gegenüber Y Vertrauen aufbringt. d) Gegeben sei View C = {Aut(C, B,, ), Cert(A, X,, ), Cert(B, A,, ), Cert(X, Y,, ), Tran(A, X,, ), Tran(B, A,, ), Trust(C, B,, )}. Prüfen Sie, ob C davon ausgehen kann, dass Y zum Zeitpunkt t über die in enthaltenen Eigenschaften verfügt. 7