Literatur. ISM SS Teil 18/PKI-2

Transkript

1 Literatur [18-1] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [18-2] Verifikation digitaler Signaturen BS/Lehre/Sem98_99/T11/index.html [18-3] Das OpenSSL Handbuch [18-4] Z1 Globale Trustpoint Zertifikat-Suchmaschine [18-5] OpenCA Guide for Versions [18-6] Aurand, Andreas: Sicherheit in Cisco- und Windows Netzwerken. Addison-Wesley,

2 Begriffe Teilnehmerzertifikat = User certificate = Zertifikat, das etwas von einem Teilnehmer, der keine ausstellende Funktion hat, beglaubigt. CA-Zertifikat = Zertifikat einer CA, das etwas über sich selbst oder etwas von einer anderen CA beglaubigt Das angesprochene "etwas" ist meistens der öffentliche Schlüssel, können aber auch zusätzliche Attribute oder eine Autorisierungsinformation sein. 3 Erweiterungen von X.509v3 I X.509 definiert eine Syntax, mit der beliebige Erweiterungen definiert werden können. Vorteil: Große Flexibilität, Nachteil: Inkompatibilität Jede Erweiterung ist entweder kritisch (critical) oder unkritisch (noncritical): Kennt ein Prüfer des Zertifikats eine als kritisch gekennzeichnete Erweiterung nicht, gilt für ihn das Zertifikat als ungültig, auch wenn es (sonst) in Ordnung ist. Unbekannte unkritische Erweiterungen können akzeptiert werden. Dies wird in Profilen festgelegt. 4

3 Erweiterungen von X.509v3 II Jede Erweiterung besteht aus Bezeichner der Erweiterung in Form eines Objekt-Identifikators (OID, siehe dazu: Kennzeichnung, ob kritisch oder nicht, und dem Wert der Erweiterung wurden einige allgemein geltende Erweiterungen definiert, um Inkompatibilitäten zu reduzieren. 5 Festgelegte Erweiterungen (Auszug) Feld Bezeichnung des CA- Schlüssels Erläuterung Falls die CA mehrere Schlüssel gleichzeitig verwendet, wird hier die Schlüssel-ID angegeben, dessen Schlüssel verwendet wurde Bezeichnung des Inhaber- Schlüssels Verwendungszweck Geltungsdauer des privaten Schlüssels Certificate Policy Policy-Mapping Zusätzlicher Inhabername Zusätzlicher CA-Name Angabe von Zwecken Zeitliche Beschränkung unabhängig von der Gültigkeit des Zertifikats OID auf eine Policy [Nur bei CA-Zertifikaten] Erklärung einer CA die Policy einer anderen anzuerkennen Name in beliebiger Form Name in beliebiger Form 6

4 Verwendungszwecke Zweck Verschlüsselung von Daten Verschlüsselung von Schlüsseln Unterschreiben von Rückruflisten Unterschreiben von Dokumenten Unterschreiben von Zertifikaten Deffie-Hellmann-Schlüsselvereinbarung 7 Unterstützte Namensformate X.509v3 Format Internet -Adresse Internet-Domain-Name (DNS) X Adresse X.500 Name EDI-Parteiname URI (Web, Uniform Resource Information) Internet IP-Adresse URI-Erläuterungen: RFC 2396, RFC 1738, RFC 1808, auch RFC

5 Beispiele I Telekom Zertifikat 9 Beispiele II - Sperrliste 10

6 Sperrvorgang Gründe für das Sperren (Beispiele): Kompromittierung der CA (Privater Schlüssel) Kompromittierung des Inhabersystems (Privater Schlüssel) Inhaber hat eine anderen Status, z. B. verlässt er die Firma, für die er das Zertifikat benötigt Initiator für das Sperren: Aussteller (CA) hat den Verdacht der Kompromittierung Inhaber hat den Verdacht der Kompromittierung Sperrarten Endgültiges Sperren: das Zertifikat ist ungültig Temporäres Sperren: Sperren kann später aufgehoben werden 11 Certificate Revocation List (CRL) 12

7 Erweiterungen - Sperreintrag (Gründe) Grund unspecified KeyCompromise AffiliatedChanged Superseded CessationOfOperation CerificateHold Erläuterung Kein Grund angegeben Unsicherer privater Schlüssel Änderungen des Personenstatus oder Objekts Ein neues Zertifikat existiert Zertifikat wird für den ursprünglichen Zweck nicht benötigt Temporäre Sperrung (Suspendierung) Wenn der Gebrauch von Schlüsseln für bestimmte Zeiträume gesperrt werden soll, z. B. während des Urlaubs eines Mitarbeiters, dann kann dafür die temporäre Sperrung benutzt werden. Dies ist aber problematisch, u.a. weil damit die Abwesenheit einer Person (weltweit) veröffentlicht wird. 13 Erweiterungen - Sperrliste Eintrag KeyIdentifier AlternativeName CRLNumber Delta CRL-Indicator DistributionPoint Bedeutung Kennung des benutzten CA-Schlüssels Weiterer Name der CA Nummer dieser Liste - wird jeweils um 1 erhöht Nummer der vorhergehenden Liste, auf die Bezug genommen wird Ortsangabe des Servers sowie weitere Angaben Dies sind Erweiterungen, die für die gesamte Sperrliste gelten. KeyIdentifier und AlternativeName haben dieselbe Bedeutung wie bei den Zertifikaten. 14

8 Verteilen von Sperrlisten I Komplette Sperrliste (basic CRL): Vorteil: Volle Information, Nachteil: Sehr lang Teilsperrlisten (Partitioned CRL): Liste wird anhand der Seriennummer auf mehrere Listen aufgeteilt In den Zertifikaten wird über eine Erweiterung der Ort der Teilliste, die für dieses Zertifikat zuständig ist, angegeben. CRL Distribution Point = CDP = Angabe der Server mit der Sperrliste, z. B. URL Delta-Sperrlisten (delta CRL): Es werden nur die Sperreinträge aufgeführt, die sich seit der letzten vollständigen CRL-Ausgabe geändert haben. Delta- Sperrlisten lassen sich mit Teilsperrlisten kombinieren. 15 Verteilen von Sperrlisten II Indirekte Sperrlisten: Sperrlisten werden von den CA an eine vertrauenswürdige dritte Partei geliefert, die Sperreinträge auch von anderen CA zusammengefasst anbietet. Für die ganze CRL wird das Indirect-CRL-Attribut (Issuing Distribution Point) auf True gesetzt. In jedem Sperreintrag wird Certificate Issuer-Attribut mit der Angabe der ausstellenden CA gesetzt. Als Sonderform der indirekten Sperrlisten können die Certificate Revocation Trees angesehen werden. 16

9 Certificate Revocation Tree I Certificate Revocation Tree = CRT = Sperrbaum Idee: Obwohl nur ein Teilbereich der Sperrliste herunter geladen wird, kann die Echtheit dieses Teils geprüft werden. Bei den anderen Verfahren muss immer die gesamte Sperrliste herunter geladen werden, um die Signatur am Ende zu prüfen. Entwickelt von Paul Kocher basierend auf einer Idee von R. Merkle. Siehe dazu: 17 Certificate Revocation Tree II 1. Alle Sperreinträge erhalten einen eindeutige ID, die aus der ID der ausstellenden CA und Nummer des Zertifikats besteht. Damit können in einem CR-Baum auch Sperrinformationen verschiedener CAs abgelegt werden. 2. Die Sperreinträge werden nach dieser ID aufsteigend sortiert. 3. Bereiche mit direkt aufsteigenden Sperreinträgen werden zusammen gefasst. 4. Hashcodes der Bereiche beginnend mit der untersten Ebene werden erstellt: Hashcodes zweier benachbarter Bereiche werden zusammengesetzt und ein neuer Hashcode über diesen Block gebildet. Dieser ist der nächst höhere Knoten im CRT. Dies wird rekursiv auf die Hashcodes der nächst höheren Ebenen angewendet. 5. Der Hashcode der Wurzel wird vom Aussteller des CRT unterschrieben. 18

10 Certificate Revocation Tree III 19 Certificate Revocation Tree IV Im CRT werden die Hashcodes so generiert, dass zwei Blöcke bzw. Hashcodes der nächst niedrigeren Ebene von einem Hashcode gesichert werden. Bei einer ungeraden Anzahl von Blöcken bzw. Hashcodes wird ein Hash über ein einziges Element gemacht. Die einzelnen Hashcodes sind so organisiert, dass sie einzeln herunter geladen werden können. Der Baum wird auch Merkle Authentification Tree genannt. Siehe dazu: Das Verfahren ist patentiert: 20

11 Prüfung eines Sperreintrags Ausgehend von einem Eintrag müssen nur die Hashcodes der benachbarten Zweige der betreffenden Ebene einzeln herunter geladen werden, so dass der Hashcode der nächsten Ebene bestimmt und geprüft werden kann. Daher kann mit einem Teil der gesamten Liste bearbeitet werden. Beispiel: Eintrag 9 soll geprüft werden: Die schraffiert eingerahmten Haschcodes werden herunter geladen und beginnend vom Eintrag 9 von der Ebene E1 bis zur Ebene E6 werden die Codes berechnet und geprüft. 21 Vertrauensmodelle - Teil 2 Im ersten Teil wurden Vertrauensmodelle zwischen den Teilnehmern (Identitäten) behandelt. Nun werden die Vertrauensmodelle zwischen Ausstellern behandelt. Hier gibt es auch drei Modelle: Hierarchisches Modell (certificate hierarchies) Vermaschtes Modell (cross-certification models) Mischung aus den beiden genannten Modellen 22

12 Hierarchisches CA-Vertrauensmodell I U <<V>> U Wurzel-CA V V <<W>> V <<Y>> Verzeichnisse W <<X>> W Y Y <<Z>> X Z CA "A B" = "A beglaubigt B" 23 Hierarchisches CA-Vertrauensmodell II Es gibt eine einzige CA, die sich selbst beglaubigt, d.h. sich selbst ein Zertifikat über den eigenen öffentlichen Schlüssel ausstellt. Wurzel-CA = Root CA = Root Authority = CA, die von keiner Identität seinen öffentlichen Schlüssel beglaubigt bekommt und in der Hierarchie die Wurzel bildet. Beziehung zwischen den Knoten der Hierarchie ist die gerichtete "A beglaubigt B"-Relation, die durch Ausstellen eines Zertifikats realisiert wird. Verfahren der Prüfung von Zertifikaten Phase 1: Vom Blatt beginnend wird Zertifikat für Zertifikat ein Pfad zur Wurzel-CA im Form einer Kette aufgebaut. Phase 2: Von der Wurzel-CA ausgehend werden die Signaturen geprüft. Dies setzt eine gegenseitige Zertifizierung voraus. 24

13 Hierarchisches CA-Vertrauensmodell III Damit das Verfahren funktioniert, muss jeder Knoten (CA) sein eigenes Zertifikat dem Teilnehmer mitteilen, das gilt auch für die Teilnehmer selbst. So trivial das klingt - es gibt dazu zwei Verfahren: Push-Modell: Die ausstellende CA liefert die gesamte Kette von Zertifikaten dem Inhaber, der diese Kette den anderen Teilnehmern, die sich von seinem öffentlichen Schlüssel überzeugen wollen, überträgt. Pull-Modell: Der prüfende Teilnehmer erhält nur das einen öffentlichen Schlüssel beglaubigende Zertifikat und muss sich selbst um alle andere Zertifikate auf dem Pfad bemühen. 25 Hierarchisches CA-Vertrauensmodell IV Der Eintrag der ausstellenden CA in einem Zertifikat bildet dann die Rückwärts-Referenz. Zertifizierungspfad = Trust path = Verweiskette bestehend aus Zertifikaten zwischen einem Startzertifikat und letztendlich der Vertrauensbasis. D.h. der Pfad muss nicht immer bei der Wurzel-CA enden. Zertifizierungskette = certificate chain = Zertifizierungspfad In der Praxis sind derartige Hierarchien nur in geschlossenen Umgebungen, z. B. in Firmennetzen, sinnvoll. Weltweit ist dieser Ansatz nicht praktikabel. Darüber hinaus haben CAs in der Nähe der Wurzel hohe Sicherheitsrisiken, da bei Kompromittierung ihres Schlüssels (fast) alle Zertifikate kompromittiert sind. 26

14 Zertifizierungspfad (Hierarchisch) 27 Kreuzzertifizierung I Cross-certification = Gleich berechtigte CAs beglaubigen gegenseitig ihren öffentlichen Schlüssel u.u. unter bestimmten Bedingungen und verlängern damit die Zertifizierungspfade. Die Schwierigkeit liegt hier in den Bedingungen, die sich auf Anerkennen fremder Policies Ablehnen fremder Policies Namensbeschränkungen Maximale Pfadlänge beziehen. Policy-Mapping = Verfahren der gegenseitigen Anerkennung von Policies, wobei Einschränkungen möglich (und sinnvoll) sind 28

15 Kreuzzertifizierung II Da Domänen in der Regel auch die Wirkungsbereiche einer PKI sind, realisiert dann die Kreuzzertifizierung die Interaktion zwischen PKIs verschiedener Unternehmen oder Organisationen. 29 Kreuzzertifizierung III Da bei einer Kreuzzertifizierung auch die Grenzen von PKIs überschritten werden, gelten besondere Bedingungen: Jede Policy muss bei der Anerkennung geprüft sein und entsprechend dem Ergebnis akzeptiert oder abgelehnt werden (Policy-Mapping). Beschränkungen der Entfernung zwischen den betroffenen CAs können sinnvoll sein, Namensbeschränkungen genauso. Natürlich müssen die Formate passen. (es gibt drei inkompatible Formate bei PKIs) Der Zugriff auf Zertifikate wird nach dem Pull-Verfahren ablaufen, d.h. alle Teilnehmer müssen selbst alle erforderlichen Zertifikate anfordern. 30

16 Zertifizierungspfad (Cross certification) 31 Maschenmodelle I Durch mehrfache Kreuzzertifizierungen entsteht zwischen den CAs ein "Web of Trust" mit der Schwierigkeit, dass bei der Kreuzzertifizierung zwischen U und V nicht die Konsequenz klar ist, wenn später V sich mit W verbindet und wenn U W nicht akzeptiert, denn bei der Kreuzzertifizierung zwischen V und W wird U nicht gefragt. 32

17 Maschenmodelle II Das Verkürzen der Pfadlängen steigert immer das Vertrauen, d.h. je kürzer der Pfad, desto besser. Aber: Jeder mit jedem zu zertifizieren ist aufgrund der vielen Kombinationen nur bei geringen Anzahlen möglich. 33 Maschenmodelle III In vermaschten Umgebungen sollte möglichst der kürzeste Pfad, der den Richtlinien des Teilnehmers entspricht, gewählt werden. Doch wie lässt sich dieser in einer dynamisch sich ändernden Umgebung finden? 34

18 Maschenmodelle IV Es kann vorkommen, dass für verschiedene Zertifizierungspfade am Ende unterschiedliche Policies gelten. Dies passiert immer dann, wenn ein Pfad über einen "liberalen" und ein anderer über einen "strengen" Bereich von CAs führt. Dies schafft eine juristische Unklarheit, die vielleicht so gelöst werden kann, dass der Pfad nach einer Prüfung mit den resultierenden Policies vermerkt wird. Dieselbe Situation liegt vor, wenn eine CA ihre Policies ändert und alle kreuzzertifizierten CAs dies akzeptieren; dann kann es vorkommen, dass dann ein Teilnehmer einem fremden Zertifikat nicht mehr traut, weil es seinen Anforderungen an die Policies nicht mehr entspricht. 35 Geschlossene Gruppe I Das Problem der unklaren Policies entschärft sich bei geschlossenen Gruppen, die sich auf bestimmte Policies geeinigt haben. 36

19 Geschlossene Gruppe II Wenn mehrere CAs in den Policies übereinstimmen und sich auch gegenseitig vertrauen, können sie eine (geschlossene) Gruppe bilden. In diesen Fällen ist eine Policy Authority (PA) sinnvoll, die für das Prüfen und Weiterentwickeln der für die Gruppe gültigen Policies zuständig ist. Es müssen nur die Schnittstellen nach außen, d.h. Zertifizierungen von CAs außerhalb der Gruppe geprüft werden. Beispiele: Produktionsbetrieb und Zulieferbetriebe, die in einem Extranet zusammen geschlossen sind Internationaler Konzern 37 Mischformen I (Hybride Modelle) 38

20 Mischformen II Grundelement größerer Strukturen ist die Hierarchie. Die Wurzel-CAs mit den selbst signierten Zertifikaten zertifizieren die anderen Wurzel-CAs entsprechend einer gleichmäßigen Struktur: Ring Flache Hierarchie (nur noch eine Stufe) Vollständige Vermaschung Wenn allen Wurzel-CAs vertraut wird, verkürzen sich die Zertifizierungspfade. 39 Mischformen III Gegenseitige Zertifizierungen können auch innerhalb einer Hierarchie durchgeführt werden; diese Optimierungen könnten zwischen beliebigen Knoten durchgeführt werden. 40

21 Nach dieser Anstrengung etwas Entspannung... 41