Digitale Schlüssel und Zertifikate auf dem Weg in die Praxis Theoretische Grundlagen und Erfahrungen aus konkreten Projekten Jürgen Hartmann, SEC, FIDUCIA IT AG & Christof Söhngen, SYRACOM AG | JBFOne 2008

Ziele dieses Vortrags Etablierung von Hintergrundwissen Anreize zum Einsatz der vorgestellten Technologien Anreize zur Nutzung der FIDUCIA PKI Lessons Learned aus den Web Service-Projekten Wissen Verbesserung der Sicherheit durch Kryptografie, Hemmschwellen senken, Vorurteile abbauen Zertifikate müssen verwaltet werden, das ist viel Arbeit schon getan Welche Fehler müssen Sie nicht mehr machen?

Agenda Theorie der digitalen Zertifikate FIDUCIA PKI Lessons Learned aus den Web Service-Projekten

Ziele der IT-Security Verfügbarkeit Vertraulichkeit Unveränderbarkeit Nicht blockierbarer Zugriff Vertraulichkeit Keine unbefugten Leser Unveränderbarkeit Keine unbefugten Schreiber Nicht-Abstreitbarkeit Nachweisbarer Urheber

Kryptografie Chiffre Chiffre Klartext Geheimtext Klartext

Kryptografie Chiffren ohne Schlüssel Klartext Geheimtext Klartext = feste geheime Rechenregel

Kryptografie Chiffren mit symmetrischen Schlüsseln Klartext Geheimtext Klartext = feste öffentliche Rechenregel = beliebiger geheimer Schlüssel

Kryptografie Chiffren mit asymmetrischen Schlüsseln Klartext Geheimtext Klartext = feste öffentliche Rechenregel = beliebiges Schlüsselpaar (geheim und öffentlich)

Kryptografie Verwendung von asymmetrischer Kryptografie Verschlüsselung n:1 Klartext Geheimtext Klartext Signatur 1:n Klartext Geheimtext Klartext

Kryptografie Verwendung von asymmetrischer Kryptografie Verschlüsselung n:1 Klartext Geheimtext Klartext Signatur 1:n + + + Klartext + Hash Klartext + v. Hash Klartext + Hash

Authentifizierung Identifikation Verifikation besondere Merkmale einmalig einzigartig gesicherte Identität Authentifizierung Beispiele: Name und Passwort Fingerabdruck Asymmetrisches Schlüsselpaar

Authentifizierung Problem: Verteilung der Schlüssel = Signatur Benutzer Anwendung Szenario: Ein Benutzer will sich bei einer Anwendung authentifizieren Er verwendet dazu die Signatur (asymmetrische Kryptografie) Wie kommt der öffentliche Schlüssel zur Anwendung?

Authentifizierung Problem: Verteilung der Schlüssel ? = Benutzer Man-In-The-Middle Anwendung Szenario: Unsicherer Transportweg bei der Verteilung des Schlüssels Man-In-The-Middle schleust sich mit eigenem Schlüsselpaar ein Er kann dadurch beliebig unter der Identität von X auftreten

Provisioning Schlüssel verwalten Sicherheit bedingt korrekte Zuordnung von privaten und öffentlichen Schlüsseln zu einer Identität Wie kann ich Schlüssel verteilen prüfen erneuern zurückziehen ? Also Sicherheit bedingt die nichtabstreitbare Zuordnung Schlüssel <-> Identitäten Wir müssen davon ausgehen, dass nicht immer gesicherte Transportwege zur Verfügung stehen oder einfach zu teuer sind Transport über potentiell unsichere Wege ermöglichen

Digitale Zertifikate Strukturierte Daten bestätigt durch eine Zertifizierungsstelle (CA) Aussteller Anfrage Prüfung Zertifikat Dritte Instanz einführen. Und jetzt sind wir beim Begriff „digitalen Zertifikate“ Zertifikat: Bestätigte Korrektheit der Daten durch einen vertrauenswürdigen Dritten Besitzer Anwendung

Digitale Zertifikate Technik und Formate Ein Zertifikat könnte so aussehen: Datenstruktur entsprechend X.509v3 Schlüssellänge: 2048 Bit Signaturalgorithmus: SHA1/RSA Zeitintervall für Gültigkeit: 10 Jahre X.509v3 Erweiterungen: CA: FALSE Key Usage: Digital Signature Key Encipherment Zertifikate sind strukturierte Daten durch CA singniert

Digitale Zertifikate Mehrstufige Hierarchie von Zertifizierungsstellen (CAs) Stamm-CA Certificate Revocation List (CRL) Selbst signiertes Zertifikat Zwischen-CAs Wir hatten Besitzer und Aussteller, aber wie prüfe ich den Aussteller? Vertrauenskette, das Ende ist Stamm-CA. Sie signiert ihr Zertifikat selbst. Verteilung der Zertifikate kann auf wenige Stamm-CAs zurück geführt werden. Zurückziehen von Schlüsseln war noch offen: CRL CA oder End-Zertifikat End-Zertifikate

Digitale Zertifikate Provisioning Erstellen: Besitzer erstellt den privaten Schlüssel - niemals weitergeben! Verteilen: Öffentlichen Schlüssel (CSR) von einer geeigneten CA signieren lassen und Zertifikat verschicken oder zum Herunterladen bereitstellen Prüfen: Die CA veröffentlicht ihren öffentlichen Schlüssel als Zertifikat und bei Bedarf Sperrinformationen für durch sie signierte Zertifikate Certificat Revocation List (CRL) Online Certificate Status Protokoll (OCSP) ! Erneuern: siehe „Verteilen“ Ein neuer privater Schlüssel ist oftmals nicht notwendig! Jetzt sind wir in der Lage effektiv mit Schlüsseln zu arbeiten Zurückziehen: siehe „Prüfen“

Digitale Zertifikate Reifegrad einer Public Key Infrastructure (PKI) Eine PKI stellt Technik und Prozesse zum Ausstellen und Verwalten von Zertifikaten über deren gesamten Lebenszyklus bereit Wer ist die Zielgruppe? Wie wird die PKI betrieben? OpenSource Software auf Entwickler-PC Trust Center für qualifizierte Signaturen Ist veröffentlicht, nach welchen Regeln Zertifikate ausgegeben werden? Sind über die veröffentlichten Kontaktdaten kompetente Ansprechpartner erreichbar? Wie werden Sperrinformationen veröffentlicht? Ist die Parametrisierung der Zertifikate praxisgerecht? Definition PKI Was will ich, was will ich bezahlen? Wenn ich ein Stammzertifikat einspiele sollte eine gewisse Hemmschwelle vorhanden sein

Digitale Zertifikate Vorteile gegenüber Passwörtern passwd Vorteile von Zertifikaten gegenüber Passwörtern Das „Geheimnis“ wird nicht geteilt Leicht archivierbare, nichtabstreitbare Transaktionen (Journal) Geringe Verwaltungsaufwände eine CA für beliebig viele Zertifikate lange Schlüssel ermöglichen lange Laufzeiten In „unsicheren Umgebungen“ einsetzbar

Agenda Theorie der digitalen Zertifikate FIDUCIA PKI Lessons Learned aus den Web Service-Projekten

FIDUCIA PKI Ziele Verbesserung der IT-Sicherheit bei gleichzeitiger Verringerung der Kosten Minimierung der Ausgaben für den Einkauf externer Zertifikate z. B. von VeriSign Verringerung der Betriebskosten durch die Verlängerung der Zertifikatslaufzeiten  Daraus ergibt sich eine besserer Durchdringung beim Einsatz von Kryptographie kosteneffizient flexibel dem jeweiligen Einsatzzweck angemessenes Sicherheits-Niveau Akzeptanz („Trust“) der PKI im FIDUCIA-Systemumfeld und bei Partnern

FIDUCIA PKI Konzeption Zertifikate für das FIDUICA Extranet Ausschließlich „Offline-CAs“ Einfacher und sicherer Schutz der Zertifizierungsstellen (CAs) Schnelles und flächendeckendes Sperren von Zertifikaten ist dennoch möglich (Arbeitsplätze und Server sind zentral verwaltet, Partner bekannt) Mehrstufige Zertifizierungsstellen-Hierarchie Lange Laufzeit der Zertifikate, große Schlüssellänge Keine Unterstützung von OCSP (RFC 2560) z. B. Stammzertifikat nicht von Software-Herstellern bei Auslieferung installieren lassen. Kein öffentliches TrustCenter Analog zur FIDUCIA PKI steht eine Test-PKI zur Verfügung

FIDUCIA PKI Implementierung Rechnen der Zertifikate mit OpenSSL auf offline Laptop (Ubuntu) Laufzeiten Stammzertifikats bis 2031 (4096 Bit Schlüssel) ausstellende CAs: 20 Jahre Endzertifikate: 10 Jahre Verteilen des Stamm-Zertifikats und Sperrlisten (CRLs) über FSV und Windows-Domänen Bereitstellung relevanter Zertifikate an (Verbund-)Partner durch das jeweilige Produkt-Management („technischer Produktmanager“) Verantwortung der CAs verteilt, z.B. SSL-Server-Zertifikate im Benutzerrechte-Management ITB2SM CodeSigning von MS Office Makros in PM SYT2AM

FIDUCIA PKI Implementierung: Passwortsicherheit Jeder private Schlüssel ist durch ein komplexes Passwort geschützt Ebene 0: 2 x 16 Zeichen (geteiltes Passwort) Ebene 1: 2 x 8 Zeichen (geteiltes Passwort) ab Ebene 2: 1 x 8 Zeichen Passwort und Schlüssel werden getrennt vorgehalten Passworte in Notes-DB über ACLs geschützt Ebene 0 und 1 in Tresoren, ab Ebene 2 spezifisch nach Anwendung Vertraulichkeit Zertifikatspassworte im Notes-Cluster und im versiegelten Umschlag bei der internen Revision der FIDUCIA (Bank-Tresor) Zertifikate Ebene 0 und 1 in getrennten Tresoren RZD und RZO Zertifikate ab Ebene 2 spezifisch nach Anwendung Verfügbarkeit Die Verantwortung für den Schutz der Vertraulichkeit und der Verfügbarkeit der Passwörter liegt beim Verantwortlichen für die jeweilige Zertifizierungsstelle!

FIDUCIA PKI Implementierung: Verteilung Das Stammzertifikat der FIDUCIA PKI ist über die Systems-Management-Verfahren installiert auf agree FCSI: Windows Zertifikatsspeicher Server/Arbeitsplätze und Zertifikatsspeicher Firefox Integration in den Java Keystore ist beauftragt. FIDUDOM: Windows Zertifikatsspeicher Server/Arbeitsplätze und Zertifikatsspeicher Firefox Integration in die Java Keystores V 1.6 und 1.5 sind im Rollout (1.4 wird nicht mehr unterstützt) AEW-Domäne: Windows Zertifikatsspeicher Server und Arbeitsplätze Integration in den Java Keystore ist beauftragt. ORGA-Domäne: Windows Zertifikatsspeicher Server und Arbeitsplätze Integration in den Java Keystore ist beauftragt. Die CAs der produktiven FIDUCIA-PKI signieren Zertifikate für RIAT und Produktion (gleiche signierende CA, aber unterschiedliche Zertifikate!) Analog steht eine FIDUCIA Test-PKI zur Verfügung Ablaufüberwachung ausschließlich in der produktiven PKI

Agenda Theorie der digitalen Zertifikate FIDUCIA PKI Lessons Learned aus den Web Service-Projekten Wir haben die Theorie, FIDUCIA-PKI, jetzt kommen die Erfahrungen aus der Praxis

Lessons Learned aus Web Service-Projekten Hintergründe Partner-Unternehmen FIDUCIA IT AG Client Server agree® Servicenehmer Servicegeber Maschinelle B2B-Kommunikation: VR-Services für Verbundpartner agree Customer Interface (aCI) für Banken und Agenturen

Lessons Learned aus Web Service-Projekten Frage: WER wird authentifiziert? Betreiber Servicenehmer Servicegeber System Anwendung Mandant Benutzer agree® FIDUCIA IT AG Authentifizierungs-Kandidaten beim Servicenehmer: Benutzer Anwendung System Mandant Betreiber …

Lessons Learned aus Web Service-Projekten Frage: WER wird authentifiziert? Servicenehmer Servicegeber Betreiber  Beispiel- Szenario Mandant  agree® Benutzer / Anwendung / System  FIDUCIA IT AG Authentifiziert wird der Betreiber, seinen Angaben wird vertraut („Federation“) Juristischer Partner ist derjenige, dessen Mitarbeiter die Zugriffe ausführen Servicegeber vergibt Zugriffs-Rechte, Servicenehmer nutzt „logische Profile“

Naheliegende Authentifizierungsform Risiken und Nebenwirkungen Lessons Learned aus Web Service-Projekten Frage: WIE wird authentifiziert? Naheliegende Authentifizierungsform Risiken und Nebenwirkungen RACF (siehe Theorie) Bindung an natürliche Personen Gefahr für Single-Sign-On Gültigkeit auf 30 Tage begrenzt Kanalabhängigkeit zu agree BAP (revoke) GenoUserID + Passwort Vorteil: Etablierte … Identität Technik Prozesse Ressourcen Digitale Zertifikate

Lessons Learned aus Web Service-Projekten Wahl der Zertifikats-Hierarchie Installation 0-stufig: Vorteil: Keine Aufwände für Hierarchien Nachteil: Pflegeaufwände immer auch beim Servicegeber m mal (Stufe 0) Laufzeit 1 mal (Stufe 0) n-stufig: Vorteil: Min. Pflegeaufwand durch max. Entkopplung Nachteil: Aufwändigere Prüfung auf Revocation Einschränkung bei Zertifikats-Identifizierung Installation 1 mal (Stufe 0) … Laufzeit x mal (Stufe 1-x) n Installation 1-stufig: Vorteil: Sinnvolle Entkoppelung der internen Details Nachteil: Keine beliebige logische Hierarchie 0 (Haus) 1 mal (Stufe 0) 1 (System) Laufzeit 1 mal (Stufe 1)

Merkmal vom Aussteller Merkmal vom Servicegeber Lessons Learned aus Web Service-Projekten Wahl des Identifizierungs-Merkmals bei Zertifikaten Ziel: Identifizieren eines Zertifikates Merkmal vom Aussteller Merkmal vom Servicegeber Distinguished Name Vollständig zur Laufzeit möglich Keine Kontrolle durch Servicegeber Gemeinsame Syntax notwendig Änderungen sind aufwändig Fingerprint Größtenteils zur Laufzeit möglich Kontrolle durch Servicegeber Keine Syntax notwendig Änderungen sind einfach möglich Alias im Keystore Nur für installierte Zertifikate möglich Kontrolle durch Installateur Rollentrennung Zertifikat / Identität

Lessons Learned aus Web Service-Projekten Weitere Punkte Prozesse und Rollen von Anfang an Planen zu Ende denken Teststufen Test, Produktion und Vorproduktionstest Nicht überspringen! Notwendigkeit für passende Tools Keytool Keytool-GUI XCA Notwendigkeit für passende Skills Analyse und Design Umsetzung Administration

Zusammenfassung Zertifikate sind für maschinelle B2B-Kommunikation unverzichtbar Sie können allerdings nicht alle Probleme lösen z.B. Schutz des Geheimnisses beim Servicenehmer Es gibt keine „Silver Bullet“ für alle Situationen abhängig von Eigentümer, Betreiber, … Zertifikate sind ein nicht-triviales Thema sie benötigen die richtigen Skills und Tools Frühzeitiger „Proof of Concept“ mit Test-Zertifikaten wie verhält sich die konkret eingesetzte Software? Handling der Zertifikate in Test, Pilot und Produktion z. B. Administration der privaten Schlüssel Ablaufüberwachung der Zertifikate Zertifikate erzwingen Konsequenz Wer verantwortet den privaten Schlüssel (Verfügbarkeit, Vertraulichkeit) Wer ist Besitzer der Daten die verarbeitet werden, wer betreibt die Systeme, wer integriert und wer entwickelt die Systeme?

Links FIDUCIA Security Portal (Extranet) http://www.itsec.fiducia.de/background/ca WESPE-Tools / Security-Paket http://jbfinfos.genoip.de:15555/jive/category.jspa?categoryID=51 XCA http://xca.sourceforge.net Cryptool-Projekt http://www.cryptool.de/ RFC 3280 (X.509v3 Zertifikate) http://www.ietf.org/rfc/rfc3280.txt

Fragen? – Diskussion? Jürgen Hartmann Christof Söhngen Zentrale Security (SEC) juergen.hartmann@fiducia.de 0721 / 4004 2805 Christof Söhngen SYRACOM AG christof.soehngen@syracom.de 0160 / 96 32 12 98 Danke für Ihre Aufmerksamkeit

Ihr IT-Partner Vielen Dank