pki (public key infrastruktur)
DESCRIPTION
PKI (Public Key Infrastruktur). Stefan Conrad Thilo Mende Christian Weitendorf. Teil 1 - Die Einführung. Warum das Ganze? Elementare Begriffsklärung. Was wollen wir ?. Blahblubb Unterschrift. Blahblubb jk23xgrk40b. entspricht. Papierdokument. Elektronisches Dokument. - PowerPoint PPT PresentationTRANSCRIPT
PKI (Public Key Infrastruktur)
Stefan Conrad
Thilo Mende
Christian Weitendorf
Teil 1 - Die Einführung
Warum das Ganze?
Elementare Begriffsklärung
Was wollen wir ?
Blahblubb
Unterschrift
Blahblubb
jk23xgrk40b
Papierdokument Elektronisches Dokument
entspricht
Sicherheit im Datenverkehr
Sicherheit im Datenverkehr bedeutet
• Urheberschaft / Integrität empfangener undgesendeter Dokumente sicherstellen
• Vertraulichkeit der Inhalte sicherstellen
Beide Anforderungen sind unabhängig und könnengetrennt angewendet werden.
Papierdokument
Setzt sich aus Inhalt und beglaubigter Unterschriftzusammen. Die Unterschrift soll bestätigen:
• Urheberschaft des Dokumentes• Integrität des Dokumentes
Die Vertraulichkeit wird im Normalfall durch die ArtDer Versendung definiert.
Elektronisches Dokument
Besteht hauptsächlich aus seinem Inhalt.
Zur Sicherstellung der Urheberschaft und der IntegritätSind weitere Mechanismen erfoderlich
digitale Signatur
Vertraulichkeit wird erlangt durch
• Verschlüsselung vor der Übertragung oder• Übertragung auf vertraulichem Kanal
• Eindeutige Zuordnung eines Dokumentes zu einembestimmten Benutzer
• Garantiert Integrität des Dokumentes
• Ähnliches Verfahren wie asymmetrischeVerschlüsselung (Private- und Public-Key)
• Garantiert Authentizität des signierten Dokumentes
Begriff: digitale Signatur
Signatur (1)
Signatur (2)
Signatur (3)
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
• Authentizität des Public Keys muss sichergestelltsein
• Verifizierbar durch Empfängerz.B. PGP-Verifizierung durch Benutzer anhandeines Fingerprints
Anforderung an Verteilung
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 ???? ...
• Persönlicher Kontaktschlecht skalierbar auf große Benutzergrupen
• Sicherer Kanal (Standleitung, ...)nicht immer verfügbar
• Vertrauenswürdiger Dritteram praktikabelsten
Möglichkeiten der Verteilung
„Zertifikate vonBenutzern“
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 ?)
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
Zertifikate von Instanzen (1)
• Übergeordnete Zertifizierungsinstanzen
• Verteilung von Zertifikaten über unsicheren Kanalmöglich (Signatur um Public-Key)
• Prinzipiell vertrauen müssen der Zertifizierungsinstanznur die Benutzer, nicht der Zertifikatsnehmer
• Feste Vertrauenspfade
• Meist allgemein anerkanntes Zertifikatsformat (X.509)
Zertifikate von Instanzen (2)
• Zertifizierungsinstanzen zertifiziert von„Policy Certification Authorities“
• PCA legen Zertifizierungsrichtlinien (Policy) fest, dieVorgaben enthalten zur Überprüfung der Identität
• Policy ist öffentlich, überprüfbar für jeden Benutzer
Signatur „die Zweite“ (1)
Signatur „die Zweite“ (2)
Instanz
Signatur „die Zweite“ (3)
Signatur „die Zweite“ (4)
Instanz
Widerruf von Zertifikaten (1)
• Z.B. Zertifizierungsschlüssel einer CA bei unkorrekterIdentitätsprüfung
• Nur Zertifizierer kann ein Zertifikat widerrufen
• Verteilung widerrufener Zertifikate über „CertificateRevocation List“
• Über unsichere Kannäle möglich, da von CA genauwie Zertifikate digital signiert
Widerruf von Zertifikaten (2)
• Aktualität der CRL muss sichergestellt sein
• Einführung des „Online Revocation Checking“
Teil 2 - Die Vertiefung
Zertifizierungsinstanzen &
Infrastrukturen
Merkmale einer Zertifizierungsinstanz Operiert nach festgelegten öffentlichen
Regeln (Policy) Verpflichtet Policy einzuhalten ( u.a.
gesetzlich) Vertrauenswürdigkeit wichtigstes Kapital Garantiert Richtigkeit der ausgestellten
Zertifikate
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)
Registrierung & Zertifizierung Registrierung :
Ü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
Veröffentlichung der Zertifikate und CRL´s Durch CA selbst oder dritte i.a. der CA
Verzeichnisdienste E-mail / Post-Abonnement Online Abfrage (OCSP)
Bei Verteilung durch Dritte : Schwerpunkt kann auf Performance statt Sicherheit gelegt
werden Vertrauen ausschließlich durch Signatur der CA
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
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
Einzelne CA (1)
Zertifikate werden nur an User vergeben User akzeptieren nur Zertifikate und CRL von
der eigenen CA akzeptiert
Einzelne CA (2)
Vorteile: Einfachheit (keine Vertrauenspfade, direkte
Verifizierung)
Nachteile: Nur für kleine User-Gruppen geeignet Single Point of Failure
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
Basic Trust Lists (2) Vorteile:
Keine Vertrauenspfade, nur einfache Zertifikate
Erweiterbarkeit durch Erweiterung der TrustList
Nachteile: Erweiterung der Trustlist sollte genau
überlegt sein Problem bei Kompromittierung einer CA
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
Zertifizierungshierarchien (2)
Vorteile : Vertrauenspfade sind einfach zu konstruieren, Einfache Wiedereinbindung ausgefallener CAs
Nachteile : Bei Kompromittierung der Root CA Totalausfall
der Infrastruktur
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
Vertrauensnetz (2)
Vorteile: Neue CA´s können leicht aufgenommen
werden Robust gegen Ausfall und Kompromittierung
Nachteile: Aufwendige Vertrauenspfad-Bildung
Hybrid PKI Architekturen Bisherige PKI:
PKI für ein Unternehmen oder eine Nutzergruppe
Hybrid Architekturen: Verbinden PKI-Strukturen untereinander
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
Cross-Zertifizierung Peer-to-peer
Verbindung zwischen jeweils einer CA der PKI
Jeder User hat genau einen Trust Point
Cross-Zertifizierung
Nicht der User, sondern Administrator entscheidet, ob andere PKI vertrauenswürdig ist
Pfadbildung komplex Nur für kleine Anzahl an PKI
geeignet
Bridge CA Bridge CA vergibt
Zertifikate an CA´s – nicht an einzelne User
Bridge ist nicht Trust Point sondern immer nur Zwischenstation bei Pfadbildung
Bridge CA Pfadbildung
einfacher als bei Cross-Zertifizierung
Auch für größere Anzahl an PKI noch überschaubar
Teil 3 - Die Ausführung
Zertifikate
Praktische Beispiele
X.509-Zertifikate
version v3
serialNumber 12
signature md5withRSAEncryption
issuer CN=UniHH_FBI Issuing CA
validity notBefore: 13.08.2002...
subject CN=webmail.infor...
subjectPublicKeyInfo
RSAEncryption/1024...
extensions SubjectAlternativeName...
signatureAlgorithm md5withRSAEncryption
signatureValue 39:37:
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
ASN.1-Types• Object identifiers (OIDs): eindeutige Objekte • RSA: 1.2.840.113549.1.1.1
Directory String: zur Speicherung von Text• PrintableString• TeletextString• BMPString• UTF8/UniversalString
Distinguished Names: hierarchischen Namensräume• X.500
Tamper-Evident Envelope• SignatureAlgorithm• ASN.1 OID des Algorithmus
• SignatureValue• Berechnete Signatur des ASN.1/DER
codierten Zertifikates• wird als bit-string gespeichert
Basic Certificate Content• SerialNumber• signature• issuer• validity• notBefore• notAfter
• subject• SubjectPublicKeyInfo
Extensions• SubjectType Extensions• CA oder Benutzer• Pfadlängenbeschränkung
• Name Extensions• Alternative Names• Name Constraints
• Key Attributes• Key Usage• Private Key Validity• Key Identifier
Extensions (2)• PolicyInformation• Certificate Policies• Policy Information• Policy Mapping• Policy Constraints
• Additional Information• CRL Distribution Points• Authority Information Access• Subject Directory Information
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
Speicherung der Zertifikate• Verzeichnisdienste( X.500/LDAP)• FTP• HTTP• E-Mail• Eine neuere Überlegung ist die Verteilung der
Schlüssel mit Hilfe von DNS
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
Gesetzliche Vorschriften
• Signaturgestz von 1997
• Eu-Richtlinie
• Signaturgesetz (SigG) von 2000
• Signaturverordnung
• Gesetz zur Anpassung der Formvorschriften (2001)
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
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
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
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
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
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
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
DNSSEC-Eintrag1H IN KEY 0x0100 3 1 (AQPFsXW3GQe5z4nvqG+V6tw3LdjDhzPXRBlI+Nky26gpZlbX LMJJnJsAjaSOw y0p7Cwkb8FyL 8QGGqrOtuDTILfr ) ;
1H IN SIG KEY 1 2 3600 20030207121434 20030108121434 8375 @ ( XzX2P+5+af3e84KhA54u5QdslLVaqLzA8541ApW90gV8kDK3 qIfq2KV4J+pCHsFqPV9DH
CI/zJsDH/WG4OkCcg== )
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
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
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. 7000 Zertifikate• stark steigende Nachfrage in den letzten
Jahren
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
Fragen?