PKI (Public Key Infrastruktur)

Präsentation zum Thema: "PKI (Public Key Infrastruktur)"—  Präsentation transkript:

1 PKI (Public Key Infrastruktur)
Stefan Conrad Thilo Mende Christian Weitendorf

2 Warum das Ganze? Elementare Begriffsklärung
Teil 1 - Die Einführung Warum das Ganze? Elementare Begriffsklärung

3 Was wollen wir ? Blahblubb Unterschrift Blahblubb jk23xgrk40b
entspricht Papierdokument Elektronisches Dokument

4 Sicherheit im Datenverkehr
Sicherheit im Datenverkehr bedeutet Urheberschaft / Integrität empfangener und gesendeter Dokumente sicherstellen Vertraulichkeit der Inhalte sicherstellen Beide Anforderungen sind unabhängig und können getrennt angewendet werden.

5 Papierdokument Setzt sich aus Inhalt und beglaubigter Unterschrift
zusammen. Die Unterschrift soll bestätigen: Urheberschaft des Dokumentes Integrität des Dokumentes Die Vertraulichkeit wird im Normalfall durch die Art Der Versendung definiert.

6 Elektronisches Dokument
Besteht hauptsächlich aus seinem Inhalt. Zur Sicherstellung der Urheberschaft und der Integrität Sind weitere Mechanismen erfoderlich digitale Signatur Vertraulichkeit wird erlangt durch Verschlüsselung vor der Übertragung oder Übertragung auf vertraulichem Kanal

7 Begriff: digitale Signatur
Eindeutige Zuordnung eines Dokumentes zu einem bestimmten Benutzer Garantiert Integrität des Dokumentes Ähnliches Verfahren wie asymmetrische Verschlüsselung (Private- und Public-Key) Garantiert Authentizität des signierten Dokumentes

8 Signatur (1)

9 Signatur (2)

10 Signatur (3)

11 Lücken des Beispiels Woher hat Bob den public-Key von Alice?
Kann Bob sicher sein, dass der public-Key wirklich zu Alice gehört? Public-Key Verteilung muss gewisse Anforder- ungen erfüllen

12 Anforderung an Verteilung
Authentizität des Public Keys muss sichergestellt sein Verifizierbar durch Empfänger z.B. PGP-Verifizierung durch Benutzer anhand eines Fingerprints

13 Begriff: Zertifikat Bindung zwischen Benutzer und einem Schlüssel
(Elektronische Beglaubigung) Schlüssel A gehört Benutzer B, keine Aussage über Vertrauenswürdigkeit von B Aber WER zertifiziert WEN ???? ...

14 Möglichkeiten der Verteilung
Persönlicher Kontakt schlecht skalierbar auf große Benutzergrupen Sicherer Kanal (Standleitung, ...) nicht immer verfügbar Vertrauenswürdiger Dritter am praktikabelsten „Zertifikate von Benutzern“

15 Zertifikate von Benutzern (1)
Gegenseitige Zertifizierung von Benutzern (z.B. PGP) Auf Key-Signing-Parties werden Informationen (Finger- prints) ausgetauscht / Identitäten überprüft Unpraktikabel bei verstreuten Benutzergruppen Keine festen Vertrauenspfade (Wem muss ich vertrauen ?)

16 Zertifikate von Benutzern (2)
Qualität der Zertifikate unklar, da nicht alle Benutzer bekannt / unterschiedliche Zertifizierungsregeln Gültigkeit eines Zertifikates gegeben? (PGP) Widerruf von Schlüsseln / Zertifikaten problematisch Keine festen Regeln für die Verteilung der Zertifikate

17 Zertifikate von Instanzen (1)
Übergeordnete Zertifizierungsinstanzen Verteilung von Zertifikaten über unsicheren Kanal möglich (Signatur um Public-Key) Prinzipiell vertrauen müssen der Zertifizierungsinstanz nur die Benutzer, nicht der Zertifikatsnehmer Feste Vertrauenspfade Meist allgemein anerkanntes Zertifikatsformat (X.509)

18 Zertifikate von Instanzen (2)
Zertifizierungsinstanzen zertifiziert von „Policy Certification Authorities“ PCA legen Zertifizierungsrichtlinien (Policy) fest, die Vorgaben enthalten zur Überprüfung der Identität Policy ist öffentlich, überprüfbar für jeden Benutzer

19 Signatur „die Zweite“ (1)

20 Signatur „die Zweite“ (2)
Instanz

21 Signatur „die Zweite“ (3)

22 Signatur „die Zweite“ (4)
Instanz

23 Widerruf von Zertifikaten (1)
Z.B. Zertifizierungsschlüssel einer CA bei unkorrekter Identitätsprüfung Nur Zertifizierer kann ein Zertifikat widerrufen Verteilung widerrufener Zertifikate über „Certificate Revocation List“ Über unsichere Kannäle möglich, da von CA genau wie Zertifikate digital signiert

24 Widerruf von Zertifikaten (2)
Aktualität der CRL muss sichergestellt sein Einführung des „Online Revocation Checking“

25 Zertifizierungsinstanzen & Infrastrukturen
Teil 2 - Die Vertiefung Zertifizierungsinstanzen & Infrastrukturen

26 Merkmale einer Zertifizierungsinstanz
Operiert nach festgelegten öffentlichen Regeln (Policy) Verpflichtet Policy einzuhalten ( u.a. gesetzlich) Vertrauenswürdigkeit wichtigstes Kapital Garantiert Richtigkeit der ausgestellten Zertifikate

27 Dienstleistungen einer „Certification Authority“ (CA)
Identitätsprüfung (Registrierung) Zertifizierung Bereitstellung und Verteilung von Zertifikaten Sperrmanagement für zurückgerufene und abgelaufene Zertifikate Ggf. Verlängerung abgelaufener Zertifikate (Rezertifizierung)

28 Registrierung & Zertifizierung
Überprüfung der CA angegebenen Daten Minimal: proof of possession Kann von CA ausgelagert sein Überprüfung vor Antragstellung Überprüfung im Auftrag der CA Zertifizierung : Verschlüsselung mit privatem Schlüssel

29 Veröffentlichung der Zertifikate und CRL´s
Durch CA selbst oder dritte i.a. der CA Verzeichnisdienste / Post-Abonnement Online Abfrage (OCSP) Bei Verteilung durch Dritte : Schwerpunkt kann auf Performance statt Sicherheit gelegt werden Vertrauen ausschließlich durch Signatur der CA

30 Trustcenter Alle Dienstleistungen einer CA
Weitergehende Dienste werden angeboten: Erzeugung eines Schlüsselpaares Sichere Verwahrung des privaten Schlüssel des Users Archivierung abgelaufener Schlüssel Benötigt deutlich mehr Vertrauen vom User als reine CA

31 Problem der Skalierbarkeit
Persönliche Identifikation bei Registrierung notwendig -> nähe zum Nutzer vs. Sicherungsmaßnahmen für CA sehr aufwendig -> zentrale Zertifizierung Lösung : Infrastrukturen aufbauen

32 Einzelne CA (1) Zertifikate werden nur an User vergeben
User akzeptieren nur Zertifikate und CRL von der eigenen CA akzeptiert

33 Einzelne CA (2) Vorteile: Nachteile:
Einfachheit (keine Vertrauenspfade, direkte Verifizierung) Nachteile: Nur für kleine User-Gruppen geeignet Single Point of Failure Bei kompromitierung der CA müssen alle Zertifikate neu ausgestellt werden

34 Basic Trust Lists (1) Einfachste Erweiterung der „Einzelnen CA“
Keine Vertrauensverhältnisse zwischen CA´s User hat Trust List mit CA´s dessen Zertifikaten er vertraut

35 Basic Trust Lists (2) Vorteile: Nachteile:
Keine Vertrauenspfade, nur einfache Zertifikate Erweiterbarkeit durch Erweiterung der TrustList Nachteile: Erweiterung der Trustlist sollte genau überlegt sein Problem bei Kompromittierung einer CA Problem bei Kompromittierung einer CA: Wie soll eine User, der dieser CA vertraut davon erfahren, wenn er kein Zertifikat-Nehmer dieser CA ist, sondern sie nur auf seiner Trust List hat ? Und dann ungerechtfertigterweise weiterhin vertraut...

36 Zertifizierungshierarchien (1)
Alle User vertrauen der Root CA Alle CA´s (bis auf Root-CA) haben genau eine übergeordnete CA CA verteilt Zertifikate an untergeordnete CA oder direkt an User

37 Zertifizierungshierarchien (2)
Vorteile : Vertrauenspfade sind einfach zu konstruieren, Einfache Wiedereinbindung ausgefallener CAs Nachteile : Bei Kompromittierung der Root CA Totalausfall der Infrastruktur

38 Vertrauensnetz (1) Auch „Web of Trust“ genannt
CA sind direkt miteinander verbunden (peer-to-peer) CA zertifizieren sich gegenseitig Jeder User vertraut zumindest seiner CA

39 Vertrauensnetz (2) Vorteile: Nachteile:
Neue CA´s können leicht aufgenommen werden Robust gegen Ausfall und Kompromittierung Nachteile: Aufwendige Vertrauenspfad-Bildung Zertifikate sind komplizierter, da sie jeweils noch Informationen über die ausstellende CA enthalten muß, denn im WoT sind keine allgemeinen Informationen über die einzelnen CA vorhanden

40 Hybrid PKI Architekturen
Bisherige PKI: PKI für ein Unternehmen oder eine Nutzergruppe Hybrid Architekturen: Verbinden PKI-Strukturen untereinander

41 Extended Trust List Erweiterung der Trust List auf Vertrauenpfade länger als 1 Pro PKI muß nur noch ein Point of Trust gesetzt werden Erhält sowohl Vor- als auch Nachteile der Trust List Komplexe Vertrauenpfad-Bildung Basic Trust Lists Vorteile: Erweiterbarkeit durch Erweiterung der TrustList Nachteile: Erweiterung der Trustlist sollte genau überlegt sein Problem bei Kompromittierung einer CA

42 Cross-Zertifizierung
Peer-to-peer Verbindung zwischen jeweils einer CA der PKI Jeder User hat genau einen Trust Point Vertrauenspfad-bildung : Da es vorher nicht bekannt ist, was für einen aufbau die Cross-Zertifizierte PKI hat, müssen mechanismen für jede art von PKI vorhanden sein Für Cross-Zertifizierung von n Unternehmen sind (n²-n)/2 peer-to-peer Verbindungen und n²-n Zertifikate notwendig => 8 Unternehmen – 28 Verbindungen – 56 Zertifikate

43 Cross-Zertifizierung
Nicht der User, sondern Administrator entscheidet, ob andere PKI vertrauenswürdig ist Pfadbildung komplex Nur für kleine Anzahl an PKI geeignet

44 Bridge CA Bridge CA vergibt Zertifikate an CA´s – nicht an einzelne User Bridge ist nicht Trust Point sondern immer nur Zwischenstation bei Pfadbildung

45 Bridge CA Pfadbildung einfacher als bei Cross-Zertifizierung
Auch für größere Anzahl an PKI noch überschaubar

46 Zertifikate Praktische Beispiele
Teil 3 - Die Ausführung Zertifikate Praktische Beispiele

47 X.509-Zertifikate version v3 serialNumber 12 signature
md5withRSAEncryption issuer CN=UniHH_FBI Issuing CA validity notBefore: subject CN=webmail.infor... subjectPublicKeyInfo RSAEncryption/ extensions SubjectAlternativeName... signatureAlgorithm signatureValue 39:37: Zertifikat des Webmail-Servers, ausgestellt von der CA des Informatikums

48 X.509-Zertifikate (2) Das Standart-Format für Zertifikate
CCITT Empfehlung zur Authentifizierung in X.500 Verzeichnissen (1988) Codiert in ASN.1/DER Heutzutage fast nur noch X.509v3, mit dieser Version wurden Erweiterungen eingeführt In RFC 2459 werden von der IETF für den Einsatz im internet benötigte Erweiterungen definiert Jede Erweiterung kann als kritisch markiert werden CCITT= comite consultatif Internationale de Telegraphique et Telefonique DER=Distinguished Encoding Rules Kritische Erweiterung: wenn sie nicht geparst wird muss das Zertifikat verworfen werden

49 ASN.1-Types Object identifiers (OIDs): eindeutige Objekte
RSA: Directory String: zur Speicherung von Text PrintableString TeletextString BMPString UTF8/UniversalString Distinguished Names: hierarchischen Namensräume X.500 OID werden vergeben, man darf sich keine aussuchen Teletextstring: T.61 characterset, superset von printable BMP: basicMultiplane 16Bit UTF8 multibyteCoded

50 Tamper-Evident Envelope
SignatureAlgorithm ASN.1 OID des Algorithmus SignatureValue Berechnete Signatur des ASN.1/DER codierten Zertifikates wird als bit-string gespeichert Signature Algorithm alle parameter müssen NULL sein

51 Basic Certificate Content
SerialNumber signature issuer validity notBefore notAfter subject SubjectPublicKeyInfo Issuer DN of CA SubjectPublicKeyInfo enhält Algorithmenangaben und Public Key Es gibt Parameter-Vererbung, Issuer und Subject haben bei keinen Optionen die gleichen optionen

52 Extensions SubjectType Extensions CA oder Benutzer
Pfadlängenbeschränkung Name Extensions Alternative Names Name Constraints Key Attributes Key Usage Private Key Validity Key Identifier Pfadlängenbeschränkeung sollte nur für cas vergeben werden AlternativeNames bei CA mail-adresse, bei ipsec-routern ip-adresse, sonst dns-namen Name-Constraints: schließen gewisse Pfade/unterbäume aus key-Usage : nur signieren/verschlüßeln... Bis wann ist der PrivateKey gültig KeyIdentifier wenn eine Person mehrere Schlüssel hat

53 Extensions (2) PolicyInformation Certificate Policies
Policy Mapping Policy Constraints Additional Information CRL Distribution Points Authority Information Access Subject Directory Information Welche Polcy gilt, wo bekommt man mehr infos. PolicyMapping Wie passt Policy 1 von CA A zu Policy 2 von CA B Ist PolicyMapping erlaubt? Wenn ja wie oft? Wo gibt es CRLs Wo gibt es weitere Infos von der CA SubjectDirectoryInfo kann jedes X.500-Attrib enthalten

54 Empfehlungen für X.509 X.500 oder DNS als Distinguished Names
max. 3, für CAs 5 Jahre Gültigkeit KeyUsageExtensions als „critical“ markieren Policies als non-critical aufnehmen Alternative Names und SubjectInformationAccess ins Zertifikat aufnehmen

55 Speicherung der Zertifikate
Verzeichnisdienste( X.500/LDAP) FTP HTTP Eine neuere Überlegung ist die Verteilung der Schlüssel mit Hilfe von DNS Meist X.500 mit Ldap-Zugriff Ftp: ftp.foo.org/id48.cert http ist ziemlich problematisch DNS später

56 Probleme Durch die Komplexität können leicht Inkompatibilitäten entstehen Probleme bei Namensvergleichen durch unterschiedliche Codierungen dadurch sind einige Extensions unbrauchbar fehlende Timestamps beim Signieren Viele Zertifikate werden für zu lange Zeiträume ausgestellt Wenn jeder seinen eignenen Standart schafft entstehen neue Probleme

57 Gesetzliche Vorschriften
Signaturgestz von 1997 Eu-Richtlinie Signaturgesetz (SigG) von 2000 Signaturverordnung Gesetz zur Anpassung der Formvorschriften (2001)

58 Signaturgesetz von 1997 Erstes Gesetz dieser Art weltweit
sehr strenge Anforderungen an CAs Haftungsfragen, Gültigkeit und die Gleichstellung der digitalen Signatur mit der Unterschrift wurden nicht behandelt CAs brauchten Genehmigung der RegTP Auslöser für die Entwicklung der EU-Richtlinie Eine CA einzurichten kostete 10MioDM Nach 2 Jahren nur 2 CAs

59 EU-Richtlinie verbindliche gemeinsame Richtlinie für alle EU-Staaten
soll für steigende Akzeptanz der digitalen Signatur und die Öffnung des Binnenmarktes für CAs sorgen CAs brauchen keine Genehmigung mehr, dafür werden Haftungsregelungen eingeführt Es werden keine technischen Details sondern nur Begriffe und Eigenschaften definiert Durch kompromisse ziemlich komplex

60 Signaturgesetz (2001) setzt die EU-Richtlinie um
unterscheidet (entprechend der EU-Vorgabe) zwischen elektronische Signatur fortgeschrittene elektronische Signatur qualifizierten Signatur definiert allgemeine Regelungen für CAs, es gibt: angezeigte Zertifizierungsdienste akkreditierte Zertifiezierungsdienste Elektronische Signatur: eingescannte Unterschrift fortges.. PublicKey z.b. PGP qualifizierte Signatur ist mit qualifiziertem Zertifikat erstellt, welches von einer CA ausgestellt wurde, noch besser ist qualifiezierte Sig. mit Zert. von akkred. Zert.A

61 Signaturverordnung Enthält Anforderungen an CAs. Folgende Themen werden behandelt: Sicherheitskonzept Identitätsprüfung Inhalt der Zertifikate Speicherung und Sperrung Einstellung der Tätigkeit Umgang mit ausländischen CAs Akkreditiert ist härter, die sicherheit wird wirklich überprüft, kostet auch mehr Speicherung der Daten 30 Jahre, die Zertifikate dürfen bei Einstellung nicht gesperrt werden

62 Anpassung der Formvorschriften
regelt Änderungen u.a anderem im BGB die bisherige Schriftform wird mit der elektronischen Form gleichgestellt, somit kann fast alles auch digital Unterschrieben werden Ausnahmen sind unter anderem Kündigung des Arbeitsverhältnises, die Bürgschaft und die Eheschließung vor Gericht werden qualifizierten Signaturen grundsätzlich als Beweis akzeptiert Der Beweis kann aber angefochten werden

63 DNSSEC Erweiterung des DNS-Protokolls, voll abwärtskompatibel
es werden 3 neue Record-Types eingeführt: „Key“ enthält den Public-Key für die Zone „Sig“ zu jedem Reord existiert eine Signatur, gespeichert unter dem sig-record NXT enthält die für einen Host nicht definierten Records DNS ist unsicher, deshlab erweiterungen

64 DNSSEC (2) Der eigene Zonen-Schlüssel kann von der Parent-Zone signiert werden. So entsteht eine Chain-of-Trust bis zu den Root-Servern, deren Public-Keys bekannt sein müssen DNSSEC ist in RFC 2535 definiert und mit BIND Version 9 erstmals implementiert nur die Antworten eine Servers sind signiert, es findet weder Verschüsselung noch Client-Authentifizierung statt Hilft nur gegen DNSSpoofing

65 DNSSEC-Eintrag 1H IN KEY x (AQPFsXW3GQe5z4nvqG+V6tw3LdjDhzPXRBlI+Nky26gpZlbX LMJJnJsAjaSOw y0p7Cwkb8FyL 8QGGqrOtuDTILfr ) ; 1H IN SIG KEY ( XzX2P+5+af3e84KhA54u5QdslLVaqLzA8541ApW90gV8kDK3 qIfq2KV4J+pCHsFqPV9DH CI/zJsDH/WG4OkCcg== )

66 Fallbeispiel Gesundheitswesen
1992 wurde die Einführung eines Digitalen Abrechnungssystems vorgeschrieben Aufgrund der persönlichen Daten ist eine besondere Sicherung der nötig §301 SGB regelt den Inhalt der zu übertragenen Daten Eine Vereinbarung zwischen den Krankenkassen und den Krankenhäusern regelt den genauen Ablauf der gesicherten Übertragung, dabei orientiert man sich an den Vorgaben des BSI Erstmals gesetzlich vorgeschriebene PKI

67 Fallbeispiel (2) Die Daten werden mit DES-CBC verschlüsselt
Der DES-Schlüssel wird mit MD5 gehasht und anschließend mit RSA-768bit verschlüsselt Es werden X.509v1 Zertifikate benutzt. Diese werden in einer DB mit X.500-Namensgebung gespeichert, der Abgleich erfolgt mit LDAP

68 Fallbeispiel (3) 4 Verbände bilden zusammen das PCA, diese stellt Sicherheits und Zertifizierungsrichtlinien auf Die CAs werden von der PCA zertifiziert und bieten Trustcenter-Dienste an momentan existieren ca Zertifikate stark steigende Nachfrage in den letzten Jahren nachfrage au grund des internets gestiegen, vorher X.400+FTAM, sehr teuer Zertifikat costet unter 100€

69 Probleme Durch Einsatz von PEM können keine Binärdaten übertragen werden, außerdem gab es anfangs Inkompatibilitäten Auch in der neuesten Fortschreibung werden die Algorithmen nicht an die Vorgaben des BSI angepasst, vom Einsatz von DES und MD5 wird abgeraten, bei RSA werden 1536 empfohlen SEHR konservativ scheinbar, steht im wiederspruuch zu SigG+SigV

70 Fragen?