Public-Key-Infrastrukturen

Transkript

1 TECHNISCHE UNIVERSITÄT DARMSTADT FACHGEBIET THEORETISCHE INFORMATIK PROF. DR. J. BUCHMANN DR. J. BRAUN Aufgabe 1: Authority Key Identifier Lösungsvorschlag zur 12. Übung zur Vorlesung Public-Key-Infrastrukturen Sommersemester 2016 Wieso werden die Werte von AKIE und SKIE im Gültigkeitsprüfalgorithmus von RFC5280 nicht verwendet? Begründen Sie Ihre Antwort. Sie werden nicht benutzt, weil sie keine Informationen mitbringen. Sie werden benutzt bei der Konstruktion des Pfades, nicht aber beim Validieren des Pfades. Weiterhin stehen die Schlüssel bereits im Zertifikat. Aufgabe 2: Prüfung von Zertifikatsketten nach RFC5280 Welche Basic-Felder oder Erweiterungen eines Zertifikats sind beteiligt, um den Wert von den verschiedenen Parametern festzustellen oder zu beeinflussen? Füllen Sie die Werte der Tabelle 1 aus. Parameter Feld oder Erweiterung valid_policy_tree Certificate Policies, Policy Mappings, Policy Constraints permitted_subtrees Name Constraints excluded_subtrees Name Constraints explicit_policy Policy Constraints inhibit_any_policy Inhibit Any-Policy policy_mapping Policy Mappings working_public_key_algorithm Subject Public Key Info working_public_key Subject Public Key Info working_public_key_parameters Subject Public Key Info working_issuer_name Subject max_path_length Basic Constraints keycertsignbit Key Usage Tabelle 1: Parameter des Algorithmus. Aufgabe 3: Prüfung von Zertifikatsketten nach RFC Policies a) Alice konstruiert die folgenden drei Zertifizierungspfade: 1

2 Uni Uni Uni, Silver Require explicit policy: 0, Silver Require explicit policy: 0 Require explicit policy: 0 HRZ HRZ HRZ Chipcard, Silver Inhibit any-policy Chipcard, Silver Inhibit any-policy RBG Carl (a) Policy: any-policy Employee, Blue Employee Diana Diana (b) (c) Welcher Pfad ist gültig und welcher ungültig (Alice akzeptiert jede Policy als Startpolicy)? (a) Pfad (a) ist ungültig. Das erste Zertifikat in der Reihe verlangt, dass die untergeordneten Zertifikate eine explicit-policy beinhalten. Das zweite Zertifikat aber hat keine certificate policy extension. (b) Pfad (b) ist ungültig. Das zweite Zertifikat verbietet die Benutzung von any-policy. Das dritte Zertifikat aber beinhaltet den any-policy Identifier ( ). (c) Pfad (c) ist gültig. Das erste Zertifikat verlangt eine explicit-policy. Alle Zertifikate beinhalten diesen Identifier. Das zweite Zertifikat verbietet die Benutzung von any-policy und die Zertifikate, die folgen, beinhalten den any-policy Identifier nicht. Des Weiteren gibt es ein durchgehende Policy (Gold), die von Alice akzeptiert wird. b) Alice konstruiert jetzt die folgenden vier Zertifizierungspfade: 2

3 Uni Uni Uni Uni Map: Gold to Blue Map: Gold to Blue Map: Gold to Silver Policy: Red Map: Red to Blue HRZ HRZ HRZ HRZ Policy: Blue Map: Blue to Cyan Policy: Blue Map: Blue to Silver Policy: Silver, Red Map: Red to Rogue Policy: Blue Map: Blue to Gold Chipcard Chipcard Chipcard Chipcard Policy: Cyan Carl (a) Policy: Silver, Red Student Policy: Red Policy: Silver, Rogue Map: Rogue to Red Student Carl (d) Diana Diana (b) (c) Alice akzeptiert nur die Policy Gold. Welcher Pfad ist gültig und welcher ungültig? (a) Pfad (a) ist gültig. Das Zertifikat von Carl ist nach der Policy Cyan erstellt worden und der Zertifizierungspfad enthält ein Mapping von Gold nach Cyan. (b) Pfad (b) ist ungültig. Das Zertifikat von Diana ist nach der Policy Red erstellt worden, aber der Zertifizierungspfad enthält kein Mapping von Gold nach Red. (c) Pfad (c) ist ungültig. Das Zertifikat von Diana ist nach der Gold policy erstellt worden, aber Gold wird nach Silver gemappt. Falls das Zertifikat von Diana nach der Policy Silver erstellt worden wäre, wäre der Pfad gültig. (d) Pfad (d) ist ungültig. Das Zertifikat von Carl ist nach der Policy Gold erstellt worden, aber der Zertifizierungspfad fängt mit einer anderen Policy als Gold an und es gibt kein Mapping von Gold auf eine andere Farbe, welche einen gültigen Zertifizierungspfad ergeben würde. Aufgabe 4: Vereinfachte Policybearbeitung Zeichnen Sie die valid_policy_trees für die nachfolgenden Zertifizierungspfade. Hierbei soll man sich am Vorgehen des in der Vorlesung besprochenen Algorithmus orientieren. Gehen Sie davon aus, dass Zertifikat i der Vorgänger von Zertifikat i + 1 im 3

4 Zertifizierungspfad ist. Klammern Sie zusätzlich jeden Knoten ein, der aus dem Baum gelöscht wird, und schreiben Sie daneben, in welchem Schritt dies geschieht, z.b. ( ) 2. Zertifizierungspfad #1: Policy: Zert #1 gold, blue, green Zert #2 Policy: ANY Zert #3 Policy: blue Zertifizierungspfad #2: Policy: Zert #1 gold, blue, green Zert #2 Policy: gold, blue Zert #3 Policy: red, green Zertifizierungspfad #3: Policy: Zert #1 gold, blue, green Zert #2 Policy: gold, ANY Zert #3 Policy: red, green Zertifizierungspfad #4: Zert #1 Policy: gold, ANY Zert #2 Policy: red, ANY Zert #3 Policy: ANY, blue Zertifizierungspfad #5: Policy: Pol. Map.: Zert #1 gold, blue, green gold blue green red Zert #2 Policy: blue, gold Pol. Map.: blue red blue green Zert #3 Policy: green Zertifizierungspfad #6: Policy: Pol. Map.: Zert #1 gold, blue, green gold blue gold gold Zert #2 Policy: blue, gold Pol. Map.: blue red blue green Zert #3 Policy: ANY Pol. Map.: ANY red Zertifizierungspfad #7: Policy: Pol. Map.: Zert #1 gold, blue, green gold ANY Zert #2 Policy: blue, gold Pol. Map.: blue yellow blue red Zert #3 Policy: ANY 4

5 Lösungsvorschlag (a) Zertifizierungspfad #1 (b) Zertifizierungspfad #2 Abbildung 1 5

6 (a) Zertifizierungspfad #3 (b) Zertifizierungspfad #4 Abbildung 2 6

7 (a) Zertifizierungspfad #5 (b) Zertifizierungspfad #6 Abbildung 3: Das dritte Zertifikat im Zertifizierungspfad #6 ist zwar ungültig (weil es ein Mapping von ANY auf eine konkrete Policy gibt - siehe Schritt (a) im Algorithmus), aber der Algorithmus bricht nicht ab bzw. gibt den aufgezeigten Zertifizierungspfad zurück. Der Grund dafür ist, dass die oben genannten Policy-Mapping-Überprüfung im sog. Prepare for -Schritt passiert, dieser aber für das letzte Zertifikat nicht aufgerufen wird. Abbildung 4: Zertifizierungspfad #7. Der Zertifizierungspfad #7 ist ungültig, weil es ein Mapping von einer konkreten Policy auf ANY gibt (siehe Schritt (a) im Algorithmus). 7

8 Aufgabe 5: Prüfung von Zertifikatsketten nach RFC5280 Benutzen Sie für Ihre Antworten den RFC 5280, den Sie entweder unter txt oder auf der PKI-Homepage finden. In dieser Aufgabe geht es um die Prüfung von Zertifikatsketten nach dem im RFC5280 angegebenen Algorithmus. Den Algorithmus finden Sie auf den Seiten 71 89, die Definition der verwendeten Extensions auf den Seiten Aus Platzgründen sind nicht alle Inhalte der Zertifikate abgedruckt. Gehen Sie davon aus, dass die Signaturen der Zertifikate tatsächlich mit dem zugehörigen -Zertifikat verifiziert werden können. Weiterhin müssen Sie folgende Variablen nicht weiter beachten: NameConstraints, PermittedSubtrees und ExcludedSubtrees. Ein Flussdiagramm des Algorithmus ist hier zu finden: Documents/Lehre/SS16/PKI/CertPathValidationRFC5280.pdf In den Aufgabenteilen c), d) und e) sollen Sie diesen Algorithmus nachvollziehen. Verwenden Sie dabei folgende Initialisierung: a) certification path Pfad gemäß Aufgabenstellung b) current date/time Jul GMT c) user-initial-policy-set nicht angegeben d) trust anchor information entsprechende Angaben zu Zertifikat A e) initial-policy-mapping-inhibit false f) initial-explicit-policy true g) initial-any-policy-inhibit false Gehen Sie bei der Bearbeitung dieser drei Aufgaben wie folgt vor. Verwenden Sie Root 1 als Vertrauensanker: Geben Sie die Länge der Zertifikatskette n an. Stellen Sie den Zustand des Algorithmus während der Prüfung tabellarisch dar: Tragen Sie senkrecht die Zustandsvariablen und waagerecht die Zählvariable i (Iterationen des Algorithmus) ein. Der Startzustand nach der Initialisierung ist i = 1. Zeichnen Sie den valid_policy_tree (die entsprechende Variable muss nicht in der Tabelle sein). Es reicht ein Baum pro Aufgabe. Notieren Sie dazu zu jeder Ebene im Baum das passende i. Falls Sie im Baum Knoten löschen müssen, klammern Sie diese ein und ergänzen die aktuelle Belegung von i, damit klar ist, wann der Knoten gelöscht wurde. Gehen Sie davon aus, dass keines der angegebenen Zertifikate gesperrt ist. Falls die Prüfung erfolgreich ist, geben Sie das Ergebnis gemäß RFC5280, an. Falls die Prüfung nicht erfolgreich ist, geben Sie die Stelle an, an der die Prüfung gescheitert ist. Hinweis: Im Algorithmus wird das keycertsignbit erwähnt. Das entspricht dem Eintrag Certificate Sign in der Extension X509v3 Key Usage. Die für die Bearbeitung der Aufgabe notwendigen Zertifikaten finden Sie unterhalb der Aufgabenstellung. a) Erstellen Sie einen Baum, der die Zertifizierungshierarchie wiedergibt! 8

9 b) Geben Sie die längsten nach RFC 5280 gültigen Zertifikatsketten an, die zur Prüfung der öffentlichen Schlüssel von Alice, Bob und Carl verwendet werden können! c) Prüfen Sie die Zertifikatskette für Alice nach dem im RFC5280 angegebenen Algorithmus. d) Prüfen Sie die Zertifikatskette für Bob... e) Prüfen Sie die Zertifikatskette für Carl... f) In den Zertifikaten C und E ist eine Policy Constraints Extension enthalten. Was wird damit erzwungen? 9

10 Zertifikat A Serial No.: 1 C=DE, CN=Root 1 NotBefore: Jan 1 00:00: GMT NotAfter: Dec 31 23:59: GMT C=DE, CN=Root 1 Public Key: key-0x450bfe09 Basic Constraints: critical : TRUE pathlen=2 Certificate Sign, CRL Sign gold, silver Policy Mappings: not critical gold copper silver green silver yellow verifiable with 0x450BFE09 (SHA-2withRSA) Zertifikat B Serial No.: 2 C=DE, CN=Root 1 NotBefore: Feb 1 00:00: GMT NotAfter: Dec 31 23:59: GMT C=DE, CN=2 Public Key: key-0x7183a0ff Basic Constraints: critical : TRUE pathlen=1 Certificate Sign, CRL Sign copper Policy Mappings: not critical copper blue verifiable with 0x450BFE09 (SHA-2withRSA) Zertifikat C Serial No.: 3 C=DE, CN=Root 1 NotBefore: Jan 2 00:00: GMT NotAfter: Dec 31 23:59: GMT C=DE, CN=Root 2 Public Key: key-0x84fcbe09 Basic Constraints: critical : TRUE pathlen=1 Certificate Sign, CRL Sign green,yellow Policy Constraints: not critical reqexplpol: 1 inhibpolmap: 1 verifiable with 0x450BFE09 (SHA-2withRSA) Zertifikat D Serial No.: 1 C=DE, CN=2 NotBefore: Feb 1 00:00: GMT NotAfter: Dec 31 23:59: GMT C=DE, CN=7 Public Key: key-0xccdd0088 Basic Constraints: critical : TRUE pathlen=0 Certificate Sign, CRL Sign copper verifiable with 0x7183A0FF (SHA-2withRSA) 10

11 Zertifikat E Serial No.: 35 C=DE, CN=Root 2 NotBefore: Jan 1 00:00: GMT NotAfter: Dec 31 23:59: GMT C=DE, CN=Root 2 Public Key: key-0x84fcbe09 Basic Constraints: critical : TRUE pathlen=1 Certificate Sign, CRL Sign green,yellow Policy Mappings: not critical green red yellow magenta yellow white Policy Constraints: not critical reqexplpol: 0 inhibpolmap: 0 verifiable with 0x84FCBE09 (SHA-2withRSA) Zertifikat F Serial No.: 9 C=DE, CN=Root 2 NotBefore: Feb 1 00:00: GMT NotAfter: Dec 31 23:59: GMT C=DE, CN=4 Public Key: key-0xbcb08645 Basic Constraints: critical : TRUE pathlen=0 Certificate Sign, CRL Sign white,red,magenta Policy Mappings: not critical white black verifiable with 0x84FCBE09 (SHA-2withRSA) Zertifikat G Serial No.: 10 C=DE, CN=7 NotBefore: Mar 1 00:00: GMT NotAfter: Dec 31 23:59: GMT C=DE, CN=Alice Public Key: key-0x770032ee Digital Signature, Encryption copper verifiable with 0xCCDD0088 (SHA-2withRSA) Zertifikat H Serial No.: 25 C=DE, CN=4 NotBefore: Feb 1 00:00: GMT NotAfter: Dec 31 23:59: GMT C=DE, CN=Bob Public Key: key-0xabde2465 Digital Signature, Encryption black verifiable with 0xBCB08645 (SHA-2withRSA) Zertifikat I Serial No.: 26 C=DE, CN=4 NotBefore: Feb 1 00:00: GMT NotAfter: Dec 31 23:59: GMT C=DE, CN=Carl Public Key: key-0x1bb44406 Certificate Sign, CRL Sign magenta verifiable with 0xBCB08645 (SHA-2withRSA) 11

12 Lösungsvorschlag A Root 1 C Root 2 E B F 2 4 D H I 7 Bob Carl G a) Alice b) Alice: B, D, G Bob: C, E, F, H Carl: C, E, F, I c) Eingabe in den Algorithmus: Inputs: a certification path B, D, G (n=3) b Current Date/Time Jul c user_initial_policy_set {Any} d trust anchor information SDN: C=DE,CN=Root 1 Alg: Sha-2WithRSA Key: 0x450BFE09 e initial-policy-mapping-inhibit false f initial-explicit-policy true g initial-any-policy-inhibit false 12

13 Änderung des Zustands, während der Algorithmus läuft: Zustandsvariablen: Schritt i = 1 i = 2 a valid_policy_tree Siehe Grafik "Valid Policy Tree" b permitted_subtrees * * c excluded_subtrees none none d explicit_policy 0 0 e inhibit_any_policy 4 3 f policy_mapping 4 3 g working_public_key_algorithm SHA-2withRSA SHA-2withRSA h working_public_key 0x450BFE09 0x7183A0FF i working_public_key_parameters j working_issuer_name C=DE, CN=Root 1 2 k max_path_length 3 1 Valid Policy Tree: In der Iteration i = 3 kann in den Schritten (d) (1) und (2) kein Policy-Knoten am Baum angehängt werden. Das führt dazu, dass in (3) alle Knoten des valid_policy_tree gelöscht werden, er wird NULL. Der Algorithmus wird deshalb in (f) beendet. d) Eingabe in den Algorithmus: Inputs: a certification path C, E, F, H (n=4) b Current Date/Time Jul c user_initial_policy_set {Any} d trust anchor information SDN: C=DE,CN=Root 1 Alg: Sha-2WithRSA Key: 0x450BFE09 e initial-policy-mapping-inhibit false f initial-explicit-policy true g initial-any-policy-inhibit false 13

14 Änderung des Zustands, während der Algorithmus läuft: Zustandsvariablen: Schritt: i = 1 i = 2 i = 3 i = 4 a valid_policy_tree Siehe Grafik "Valid Policy Tree" b permitted_subtrees c excluded_subtrees d explicit_policy e inhibit_any_policy f policy_mapping g working_public_key_algorithm SHA-2withRSA SHA-2withRSA SHA-2withRSA SHA-2withRSA h working_public_key 0x450BFE09 0x84FCBE09 0x84FCBE09 0xBCB08645 i working_public_key_parameters j working_issuer_name Root1 Root 2 Root 2 4 k max_path_length In der Iteration i = 3 hat die Variable policy_mapping den Wert 0. Deshalb wird der Knoten mit der Policy white aus dem Baum gelöscht. In der Iteration i = 4 kann deshalb in den Schritten (d) (1) und (2) kein Policy- Knoten am Baum angehängt werden. Das führt dazu, dass in (3) alle Knoten der Variablen valid_policy_tree gelöscht werden, er wird NULL. Der Algorithmus wird deshalb in (f) beendet. Valid Policy Tree: 14

15 e) Die Prüfung von Carls Zertifikat läuft im Wesentlichen gleich ab. Der Unterschied ergibt sich in Schritt 4. Die Initialisierung erfolgt wie bei der Prüfung von Bobs Zertifikat mit der Ausnahme, dass der Zertifizierungspfad C, E, F, H lautet. Die Pfadlänge n ist ebenfalls 4. Valid Policy Tree: Das Ergebnis der Prüfung ist gültig. Der resultierende valid_policy_tree ist der gezeigte, da user-initial-policy-set die Any-Policy beinhaltet. Public Key und Parameter entsprechen den Werten in der Spalte 5 der Zustandstabelle. 15

16 Änderung des Zustands, während der Algorithmus läuft: Zustandsvariablen: Schritt: i = 1 i = 2 i = 3 i = 4 (wrap-up) a valid_policy_tree Siehe Grafik "Valid Policy Tree" b permitted_subtrees c excluded_subtrees d explicit_policy e inhibit_any_policy f policy_mapping g working_public_key_algorithm SHA-2withRSA SHA-2withRSA SHA-2withRSA SHA-2withRSA SHA-2withRSA h working_public_key 0x450BFE09 0x84FCBE092 0x84FCBE09 0xBCB x1BB44406 i working_public_key_parameters j working_issuer_name Root1 Root 2 Root 2 4 k max_path_length f) Mit der Policy Constraints Extension kann man zwei Dinge bewirken: 1) requireexplicitpolicy: Ab einer bestimmten Position in der Zertifikatskette müssen die Policies explizit benannt sein, d.h. der Prüf-Algorithmus scheitert, wenn irgendwann der valid_policy_tree zu NULL wird. Das trifft auch zu, wenn der valid_policy_tree vorher zu NULL geworden ist. In diesem Fall wird also in Zertifikat E erzwungen, dass ab dem nächsten Zertifikat in der Kette die gültigen Policies explizit angegeben sein müssen. Die entsprechende Angabe in Zertifikat C hat in diesem Fall keine Wirkung, da sie in E sowieso gesetzt wird. 2) inhibitpolicymapping: Ab einer bestimmten Position in der Kette dürfen keine Policies mehr auf andere abgebildet werden (bei Zertifikat E ab dem nächsten Zertifikat). Die Forderung ist sogar noch stärker! (vgl. RFC5280, (b) (1) bzw. (2)) Ist eine Policy in einem Mapping enthalten und Mapping nicht erlaubt, verschwindet sie ganz aus dem valid_policy_tree in der aktuellen Stufe. Eine kann also erzwingen (sie stellt ja die Zertifikate der nächsten Stufe aus), dass bestimmte Policies abgebildet werden müssen, und gleichzeitig verbieten, dass Mapping erlaubt ist. Das erscheint zunächst unsinnig. De facto bedeutet das, dass die abgebildeten Policies auf der nächsten Stufe nicht zu einer gültigen Prüfung beitragen können. Sie werden nämlich aus dem valid_policy_tree gelöscht. Die Policies, die auf diese Weise aus dem valid_policy_tree entfernt werden, können auch später nicht mehr ins Spiel kommen, da Mapping nicht erlaubt ist. Man kann auch nicht einfach die Policy-Prüfung sein lassen, da Policies ja explizit gefordert werden. Dennoch gibt es einen Fall, in dem die Policies zum Tragen kommen. Wenn man der Initialisierung des Algorithmus folgt, werden nämlich die Zertifikate, die als Vertrauensanker dienen, nicht interpretiert. Es finden lediglich der Subject- Name und der PublicKey (mit Parametern) Eingang in den Algorithmus. Wählt man im Beispiel also Zertifikat E als Vertrauensanker, so ist auch die Prüfung von Bob erfolgreich, weil inhibitpolicymapping nicht zum Tragen kommt. Effektiv verhindert also das Zertifikat E, dass die Policy white (aus Zertifikat F) zu einer gültigen Prüfung führt, wenn der Vertrauensanker oberhalb von E liegt. 16