Public-Key-Infrastrukturen

Transkript

1 TECHNISCHE UNIVERSITÄT DARMSTADT FACHGEBIET THEORETISCHE INFORMATIK PROF. DR. J. BUCHMANN DR. J. BRAUN Aufgabe 1: Smartcards zur 7. Übung zur Vorlesung Public-Key-Infrastrukturen Sommersemester 2016 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. a) Zunächst muss der Hashwert h(m) der Nachricht m berechnet werden. Dies erledigt der PC. Anschließend wird der Hashwert h(m) an den Kartenleser gesendet. b) Sobald der Kartenleser den Hashwert erhalten hat, sendet er ihn weiter an die Smartcard. Diese signiert ihn dann. Wir bezeichnen die Signatur der Nachricht mit h (m). Der Signaturvorgang findet immer auf der Karte statt, da aus Sicherheitsgründen der private Schlüssel die Karte nicht verlassen darf. c) Zuletzt wird die Signatur über den Kartenleser zum PC zurückgesendet. Dieser hängt ihn an die an und sendet diese als Ganzes ab. 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! Für die auf der Karte befindlichen Schlüsselpaare K Enc für Verschlüsselung, 1

2 K Auth für Authentisierung und K Sig für Dokumentsignaturen sollte Folgendes gelten: K Sig K Enc K Auth : Für die Authentisierung ist es wichtig, dass der Signaturschlüssel nur einer, nämlich der berechtigten, Person zur Verfügung steht. Das kann im Widerspruch zu einem Keybackup stehen, und zwar dann, wenn das Backup eine Dienstleistung einer dritten Partei ist. Abgesehen davon braucht man für Signaturschlüssel kein Backup. Es geht nichts verloren, wenn der Schlüssel nicht mehr benutzt werden kann. Verifiziert werden kann noch, da der öffentliche Verifikationsschlüssel weiterhin existiert. Bei Verschlüsselungsschlüsseln gilt das nicht. Gehen sie verloren, kann man die verschlüsselten Daten nicht mehr lesen. Der wesentliche Unterschied liegt darin, dass man bei der Entschlüsselung den privaten Schlüssel immer nach der Public-Key Operation verwendet. K Sig K Auth : Beide Schlüssel werden für Signaturen eingesetzt. Der Unterschied liegt jedoch in der Art der Signaturanwendung. Bei der Authentisierung unterschreibt man unter Umständen Nachrichten, von denen man nicht weiß, wie sie entstanden sind. Man hat zunächst keine Garantie, dass man dabei nicht den Hashwert eines Dokuments signiert, welches man gar nicht kennt. Würde man für die Authentisierung den gleichen Schlüssel verwenden, mit dem man auch verbindliche Signaturen leistet, könnte das ein Angreifer (in dem Fall der Server, bei dem man sich authentisiert) ausnutzen. Umgekehrt möchte man auch den PKI-Teilnehmern nicht die Möglichkeit geben, verbindliche Signaturen abzustreiten. Sie könnten im Zweifelsfall immer sagen, dass sie die Signatur nicht selbst geleistet haben, sondern ihnen diese bei einer Authentisierung untergeschoben wurde. 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. a) Zertifikat 1: Jun 2 09:43: Jun 1 22:00: Zertifikat 2: Jun 2 09:43: Apr 25 08:55: (weil eine Revokation zu diesem Zeitpunkt stattgefunden hat) Zertifikat 3: Apr 25 09:00: Apr 25 11:52: (weil eine Revokation zu diesem Zeitpunkt stattgefunden hat) Zertifikat 4: Dec 1 08:59: Dec 1 08:59: Zertifikat 5: Dec 1 09:34: Dec 1 08:59: (weil das Zertifikat der Master CA ausgelaufen ist) b) Die Gültigkeitszeiträume müssen nicht übereinstimmen. Man könnte denselben Schlüssel in einem neuen Zertifikat noch einmal benutzen (wenn das alte ausgelaufen ist). Das ist sogar in Zertifikaten 2 und 3 der Fall. Der Schlüssel bleibt gültig, aber das Zertifikat nicht (wegen Namensänderung). 2

3 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 (SHA-2withRSA) 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 (SHA-2withRSA) 3

4 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 (SHA-2withRSA) 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 (SHA-2withRSA) 4

5 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 (SHA-2withRSA) Aufgabe 4: CRLs kombinieren CRL A ThisUpdate: Apr 25 11:58: GMT NextUpdate: May 25 11:58: 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 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) 5

6 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, } a) Der Benutzer hat vollständige Revokationsinformation: b) Der Benutzer hat vollständige Revokationsinformation: c) Der Benutzer hat keine vollständige Revokationsinformation: F 2 fehlt. Aufgabe 5: Neues Modell F F 5 (3) F F 10 (4) F F 15 (5) F F 14 (6) 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: 1 Verfügbar unter 6

7 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. 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, : Aut(A, X,, 0 ), Trust(A, X,, 1 ), Valid A, Cert(X, Y,, 2 ), t Aut(A, Y,, 2 ) (7) 7

8 X, Y, t 0 1, : Aut(A, X,, 0 ), Trust(A, X,, 1 ), Valid A, Tran(X, Y,, 2 ), t Trust(A, Y,, 2 ) (8) a) 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. PKI-System Maurers Modell erweitertes Modell ermöglichendes neues Merkmal mehrere Formate Revokation Autorisierung Delegierung Zeitverhalten Tabelle 1: Vergleichstabelle 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 )} 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. b) i) Aut(A, X,, 0 ), Trust(A, X,, 1 ), Valid A, Cert(X, Y,, 2 ), t Aut(A, Y,, 2 ) Aut(A, X,, 0 ), Trust(A, X,, 1 ), Valid A, Tran(X, Y,, 2 ), t Trust(A, Y,, 2 ) Aut(A, Y,, 2 ), Trust(A, Y,, 2 ), Valid A, Cert(Y, Z,, 2 ), t Aut(A, Z,, 2 ) Aut(A, Z,, 2 ), Trust(A, Z,, 2 ), Valid A, Tran(Z, B,, 2 ), t Trust(A, B,, 2 ) ii) Für 2. 8

9 a) PKI-System Maurers Modell erweitertes Modell ermöglichendes neues Merkmal mehrere Formate nein ja Properties Revokation nein ja Zeit Autorisierung nein ja Properties Delegierung teilweise ja Domänen Zeitverhalten nein ja Zeit Tabelle 2: Vergleichstabelle c) Aut(B, X,, ), Trust(B, X,, ), Valid B, Cert(X, A,, ), t Aut(B, A,, ) Aut(B, X,, ), Trust(B, X,, ), Valid B, Tran(X, A,, ), t Trust(B, A,, ) Aut(B, A,, ), Trust(B, A,, ), Valid B, Cert(A, C,, ), t Aut(B, C,, ) Aut(B, A,, ), Trust(B, A,, ) Kein Trust Transfer Tran(A, Y,, ) vorhanden, weswegen kein Trust(B, Y,, ) abgeleitet werden kann. d) Aut(C, B,, ), Trust(C, B,, ), Valid C, Cert(B, A,, ), t Aut(C, A,, ) Aut(C, B,, ), Trust(C, B,, ), Valid C, Tran(B, A,, ), t Trust(C, A,, ) Aut(C, A,, ), Trust(C, A,, ), Valid C, Cert(A, X,, ), t Aut(C, X,, ) Aut(C, A,, ), Trust(C, A,, ), Valid C, Tran(A, X,, ), t Trust(C, X,, ) Aut(C, X,, ), Trust(C, X,, ), Valid C, Cert(X, Y,, ), t Aut(C, Y,, ) 9