Kapitel 4 Schlüsselmanagement PDF

Technische Universität München Kapitel 4 Schlüsselmanagement Welche Schlüsselmanagement-Aufgaben fallen an? Erzeugung von kryptografisch starken Schlüsseln. Nachweis der Authentizität öffentlicher Schlüssel. Sicherer Austausch/Vereinbarung von Schlüsseln zw. Partnern. Schlüsselerneuerung....

Technische Universität München Kapitel 4 Schlüsselmanagement Welche Schlüsselmanagement-Aufgaben fallen an? Erzeugung von kryptografisch starken Schlüsseln. Nachweis der Authentizität öffentlicher Schlüssel. Sicherer Austausch/Vereinbarung von Schlüsseln zw. Partnern. Schlüsselerneuerung. Sichere Speicherung geheimer Schlüssel. Langzeitarchivierung von verschlüsselten Daten. Im Kapitel 4: Fokus auf Schlüsselerzeugung bei symmetrischen Verfahren Schlüsselauthentizität bei asymmetrischen Verfahren Schlüsselaustausch bzw. Schlüsselvereinbarung Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 1  Technische Universität München 4.1 Generierung symmetrischer Schlüssel Kerkhoffs-Prinzip: Stärke des Kryptoverfahrens sollte nur von der Güte des Schlüssels abhängen. Starke symmetrische Schlüssel müssen hohe Entropie besitzen. Konsequenz: Schlüsselbits können nur mit geringer Wahrscheinlichkeit (insbes. von Angreifer) bestimmt, also korrekt vorhergesagt werden. Benötigt werden gute Generatoren, um hohe Entropie zu erzielen! Frage: Was sind gute Schlüsselgeneratoren? Antwort: mögliche Kandidaten sind gute Zufallszahlengeneratoren (1) Echte Zufallszahlen TRNG (True Random Number Generator) Die Entropiequelle basiert auf physikalischen Phänomenen. Beispiele: Atmosphärisches Rauschen, Mausbewegung, thermisches Rauschen,… Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 2  Technische Universität München (2) Pseudozufallszahlengenerator (PRNG) PRNG-Algorithmus arbeitet deterministisch, wirkt nach Außen zufällig. Das deterministische Verhalten basiert auf dem Startwert, dem Seed. Mit Seed ist die Berechnung aller Ausgaben des PRNG möglich. Konsequenz: Wenn ein PRNG zur Generierung von Schlüsselbits genutzt wird, dann muss der Seed-Wert vertraulich sein! (3) Kryptografisch sichere Zufallszahlengenerator (CSPRNG) 1. Genutzte PRNG sind nicht vorhersagbar, selbst wenn der Angreifer bereits einen Teil der generierten Zufallsfolge kennt. 2. CSPRNG liefert keinen Hinweis auf vorhergehende Zufallszahlen. 3. Erzeugte Zufallsfolgen hat statistisch gleichviele Nullen und Einsen und ist nicht komprimierbar. Beispiel für CSPRNG: Nichtlinear rückgekoppelte Schieberegister. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 3  Technische Universität München Eine Blockchiffre im CTR Modus mit Schlüssel k ist ein CSPRNG. Nonce ctr Nonce ctr Nonce ctr Nonce ctr k AES k AES k AES k AES Die Komponenten in definieren einen CSPRNG. AES-CTR ist ein kryptografisch sicherer Zufallszahlengenerator. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 4  Technische Universität München 4.2 Austausch gemeinsamer, geheimer Schlüssel Zwei Klassen von Ansätzen: Schlüsselaustausch,-verteilung (Key Distribution) Schlüsselvereinbarung (Key Agreement) 4.2.1 Schlüsselaustausch mit zentraler Schlüsselverteilung Kleines Rechenbeispiel: n = 1300 Studierende seien in der Vorlesung. Jeder habe mit jedem anderen Studierenden einen gemeinsamen Schlüssel vorab erhalten, um sicher zu kommunizieren. Frage: Wie viele Schlüssel mussten vorab ausgetauscht werden? 1. n-1= 1299 ? 2. n ∗ (n-1) = 1.688.700? 3. (𝒏∗(𝒏−𝟏))/𝟐 = 844.350? Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 5  Technische Universität München Problem: Schlüsselaustausch vorab, jeder mit jedem, skaliert nicht. Lösungsmöglichkeit: Aufsetzen eines zentralen Schlüsselverteilungs-Servers. Häufig KDC-Server (Key Distribution Center) genannt und als Trusted Third Party (TTP) bezeichnet. Aufgabe eines KDC (vereinfacht): Jeder Partner A vereinbart vorab mit KDC einen Pre-Shared Key kA Pre-Shared Key kA ist bei symmetrischer Krypto ein secret Key Pre-Shared Key kA ist bei Public-Key Verfahren der public Key eA. Langlebige Keys kA,kB werden zur Authentisierung von A, B sowie zum Austausch eines neuen Schlüssels kAB genutzt. Austauschwege für Pre-Shared Keys: QR-Code, SMS, PIN-Brief, …. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 6  Technische Universität München Allgemeines Nutzungsprinzip des KDC: Szenario Partner A, B A : kA Schlüssel- KDC speicher KDC mit Pre-Shared, B : kB secret Keys kA , kB …. für A und B. kA A B kB Ausgangspunkt: A möchte mit B kommunizieren (grüne Linie) Aktionen des KDC KDC erzeugt für die Partner A und B einen neuen geheimen Key kAB , Der KDC verteilt den kAB sicher an A und B. A, B nutzen kAB , um miteinander verschlüsselt zu kommunizieren. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 7  Technische Universität München Sehr stark vereinfachter Ablauf: in der Praxis deutlich komplexer, sicherer! Partner A KDC Partner B pre-shared mit KDC: kA pre-shared mit A: kA pre-shared mit KDC: kB mit B: kB (1) Request: Key für Kommunikation mit B (2) Generiert kAB, Verschlüsselung von kAB: cA = AESkA(kAB ), (3) Response: cA , cB cB = AESkB(kAB ) (4) Entschl. kAB= AES-1kA(cA) Nutzung: (6) Entschl. Verschlüsseln (5) Verschlüsselte Kommunikation mit B: kAB= AES-1kB(cB), einer Nachricht m A, c, cB c = AESkAB(m) Nachricht m Frage: Sehen Sie Schwächen in dem vereinfachten Ablauf? m = AES-1kAB(c) Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 8  Technische Universität München 4.2.2 Schlüsselaustausch mit hybridem Ansatz, zentral oder dezentral Key Encapsulation Mechanism (KEM): Symmetrischer Schlüssel kAB wird asymmetrisch verschlüsselt. Einfacher (naiver) dezentraler Ansatz, oBdA Nutzung von RSA: A kennt eB , A generiert kAB B mit RSA-Paar (eB, dB) (1) A kapselt kAB c = RSAeB(kAB) (2) c (3) B entschlüsselt c: kAB = RSAdB(c) Frage: was stimmt? 1. Nur B kann den Schlüssel kAB aus c rekonstruieren. 2. Wenn dB ab Zeitpunkt t kompromittiert ist, sind alle ausgetauschten Schlüssel ab Zeitpunkt t unsicher. 3. Wie (2), dann sind auch alle Schlüssel vor t unsicher. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 9  Technische Universität München Frage 3. von Folie 9 zeigt, welche Folgen ein kompromittierter Schlüssel haben kann. Dies führt zur Forderung nach: Perfect Forward Secrecy (PFS), „Folgelosigkeit“ In heutigen Protokollen wird versucht, diese Eigenschaft umzusetzen. Was bedeutet die PFS-Eigenschaft: Wird ein Schlüssel unsicher (z.B. Pre-Shared Key, privater Schlüssel) dürfen dadurch andere, zu früheren Zeitpunkten genutzte Schlüssel nicht auch unsicher werden. Das ist die geforderte Folgenlosigkeit! Konsequenz: Die Kompromittierung eines Schlüssels macht eine sichere Kommunikation nicht im Nachhinein unsicher. Ein neuer Schlüssel darf nicht von einem alten Schlüssel abhängen. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 10  Technische Universität München 4.3 Dezentrale Berechnung gemeinsamer, geheimer Schlüssel Diffie-Hellman-Verfahren (DH) (1976 entwickelt) Verfahren zur dezentralen Schlüsselvereinbarung. Achtung: DH ist ein Public-Key Verfahren, das nicht zum Verschlüsseln verwendet werden kann! Weit verbreitet: Verwendung u.a. in TLS, WhatsApp Basis von DH: Schwierigkeit des diskreten Logarithmus-Problems y = gx mod p ist einfach zu berechnen, aber die Umkehrung logg y mod p = f-1(y) = x mod p ist für große p sehr schwer zu berechnen. Exponentation in ℤ∗𝑝 mit 𝑝 ist Primzahl, ist eine Einweg-Funktion Exponentation ist kommutativ: d.h. 𝑘 = (𝑎 𝑦 )𝑥 ≡ 𝑎𝑥 𝑦 𝑚𝑜𝑑 𝑝. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 11  Technische Universität München Phasen des klassischen DH-Verfahrens Ziel: Partner A und B benötigen einen gemeinsamen, symmetrischen Schlüssel kAB als Basis für eine vertrauliche Kommunikation. Vorgehen bei DH: Wichtig: Es wird keine vertrauliche Information ausgetauscht, um den gemeinsamen Key kAB zu berechnen. Phase 1: Austausch öffentlicher Information zwischen A und B. Phase 2: lokale Berechnung eines shared DH-Secrets: DH-kAB. Phase 3: Mit festgelegter Funktion (nicht geheim), erzeugen A und B lokal auf der Basis des DH-kAB den gemeinsamen Schlüssel kAB. Phase 4: Ableiten von Keys mittels kAB , z.B. 128-bit k= KDF(kAB|| nonce) Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 12  Technische Universität München DH-Verfahren: Phase 1 und Phase 2 (1) Wähle große Primzahl p (allen Teilnehmern bekannt). (2) Wähle nicht-geheimen Wert g  ℤ∗𝑝 , Generator-Element Für Generator-Element g für eine Menge {1, …, p-1} gilt: für alle m {1, …, p-1} gibt es ein r  {0, …, p-1} so, dass gr mod p = m Wähle geheime Zahl A B a ∊ {2, …, p-2}, Wähle geheime Zahl a=dA private Key von A. b ∊ {2, …, p-2}, b=dB Berechne öffentlichen Berechne öffentlichen Schlüssel Schlüssel A=ga mod p A= eA B=gb mod p Berechne DH-kAB B= eB Berechne DH-kAB DH-kAB = Ba mod p DH-kAB = A b mod p = gba mod p = gab mod p Shared DH-kAB = eBa mod p = eAb mod p Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 13  Technische Universität München Phase 3 A und B haben jeweils lokal den Shared DH-Key DH-kAB berechnet. Phase 4: Ableiten von Schlüssel auf Basis von DH-kAB DH-kAB wird als Eingabe für einen PRNG genutzt, um symmetrische Keys kAB der Länge n-Bit zu generieren. In der Praxis: Nutzen einer dedizierten Key Derivation Function KDF das ist meist eine Keyed-Hashfunktion (MAC), z.B. SHA3 KDF ist allen Partnern bekannt Eingabe der KDF: DH-kAB und weitere Werte, wie z.B. die Schlüssellänge n, Nonces Jeder Partner berechnet shared secret k der Länge n-bit. k = KDF(DH-kAB , n, nonceA, nonceB) Mit KDF werden n Schlüsselbits erzeugt, z.B. n = 256 für AES-256. Dafür wird KDF ggf. mehrfach angewandt auf die Eingabe. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 14  Technische Universität München Problem: Man-in-the-Middle (MitM) Angriff: Alice (A) MitM Joe Bob (B) DH-Keys (eA, dA) e (eJ, dJ) (eB,dB) A eJ eB eJ DH-kAJ= eJa mod p DH-kBJ= eJb mod p Erzeugt kAJ Erzeugt kAJ Erzeugt kBJ kAJ = KDF(DH-kAJ ) Erzeugt kBJ kBJ = KDF(DH-kBJ ) Kommunikation mit kAJ Kommunikation mit kBJ A glaubt ihr Partner ist B. B glaubt sein Partner ist A. Joe sieht alles. Lösung: Signierter Austausch der öffentlichen DH-Schlüssel eA, eB. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 15  Technische Universität München 4.4 PFS-Umsetzung mit dem DH-Verfahren Basis: Jeder Partner X besitzt Signatur-Schlüssel-Paar (veri_x, sig_x). Vorgehen: oBdA sei RSA das Signaturverfahren Für jeden neuen DH-Key DH-kAB generiert jeder Partner jeweils ein neues DH-Schlüsselpaar (e, d), ephemeral keys (flüchtig). Die öffentlichen Schlüssel werden signiert ausgetauscht: Sei eA der neu generierte, ephemeral DH-Key von A: Signieren des Schlüssels eA : sig = RSAsig_A(eA). Empfänger verifiziert die Signatur sig: RSAveri_A(sig). Nutzung in der Praxis häufig: Partner-1 benutzt ein statisches DH-Schlüsselpaar und Partner-2 generiert neues DH-Paar für jeden neuen DH-kAB. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 16  Technische Universität München Variante: Diffie-Hellman auf elliptischen Kurven (ECDH) ECDH-Ablauf ist analog zum klassischen DH ECDH ist weit verbreitet im Einsatz, u.a. in TLS (sichere Internetkommunikation), ePersonalausweis, WhatsApp, … ECDH Klassisches DH Symm. Verfahren 160 1024 80 224 2048 112 256 3072 128 384 7680 192 Fazit: Schlüsselaustausch/-vereinbarungen werden in der Praxis überall benötigt. Unternehmensumfeld häufig KDC-basierte, zentrale Server-Lösung. Internet: DH-Verfahren ist De-Fakto-Standard. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 17  Technische Universität München 4.5 Public Key Infrastructure (PKI) Ziel: Konzepte und Protokolle zum Nachweis und zur dezentralen Überprüfung der Authentizität von Public Keys: Zertifikate und PKI 4.5.1 Zertifikat Datenstruktur im Standardformat: X.509.v3 Bescheinigt Bindung von Public Key eA an die Identität der Instanz/Subjekt A (Person, Server, Gerät…). Mit digitaler Signatur des Zertifikat-Ausstellers wird die Korrektheit der Daten bestätigt. Beispiel: Webserver Zertifikat für www.tum.de (nächste Folie) Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 18  Data: Version: 3 (0x2) Technische Universität München Serial Number: 1c:52:30:5b:df:7d:d3:25:89:63:87:ed Signature Algorithm: sha256WithRSAEncryption X.509.v3 Zertifikat Issuer: […], O = TUM, CN = Zertifizierungsstelle der TUM Validity Not Before: Nov 21 08:39:41 2016 GMT Ausgestellt für: Not After : Jul 9 23:59:00 2019 GMT Subject: […] O = TUM, OU = Leibniz-Rechenzentrum, CN = wwwv1.tum.de Subject Public Key Info: www.tum.de Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Ausgestellt durch eine Modulus: […] Exponent: 65537 (0x10001) Certificate Authority (CA) X509v3 extensions: X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.22177.300.1.1.4.3.5 Enthält Angabe zur CA […] X509v3 Basic Constraints: (Issuer) CA:FALSE X509v3 Key Usage: critical Enthält Public Key eA von A Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication und Verfahren z.B. RSA. X509v3 Subject Key Identifier: 7E:2B:DD:38:51:E0:60:50:66:FB:03:75:22:33:12:64:B9:E4:D8:36 Enthält Information zum X509v3 Authority Key Identifier: keyid:9D:9F:23:F0:19:1B:7E:C7:23:5D:27:2A:CC:A5:36:3A:A6:69:E5:89 Ablaufdatum: gültig bis …. X509v3 Subject Alternative Name: DNS:tum.de, DNS:www.tum.de, […] X509v3 CRL Distribution Points: Hash der Daten im Full Name: URI:http://cdp1.pca.dfn.de/tum-ca/pub/crl/cacrl.crl Full Name: URI:http://cdp2.pca.dfn.de/tum-ca/pub/crl/cacrl.crl Zertifikat mit dem privaten Authority Information Access: OCSP - URI:http://ocsp.pca.dfn.de/OCSP-Server/OCSP Key dCA der CA signiert. CA Issuers - URI:http://cdp1.pca.dfn.de/tum-ca/pub/cacert/cacert.crt CA Issuers - URI:http://cdp2.pca.dfn.de/tum-ca/pub/cacert/cacert.crt Signature Algorithm: sha256WithRSAEncryption Signature Value: 77:d8:91:01:91:1b:6f:e7:10:3c:a6:3d:4e:0e:7f:88:63:84: […] Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 19  Technische Universität München 4.5.2 Komponenten einer PKI 1. Registration Authority (RA): bürgt für die Verbindung zw. öffentlichem Schlüssel und Identitäten/Attributen 2. Certification Authority (CA): Stellt Zertifikate aus 3. Validierungsstelle (VA) Überprüfung von Zertifikaten 4. Verzeichnisdienst: Verzeichnis mit ausgestellten Zertifikaten 5. Personal Security Environment (PSE): Sichere Speicherung des privaten Schlüssels Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 20  Technische Universität München Beispielhafter Einsatz A möchte B eine verschlüsselte Mail 4. 5. senden. Schritte 1-4 von B (vorab): Beantragung eines Zertifikats Schritte von A: Schritt 5: A holt B‘s 3. 2 Zertifikat von einem 6.. Verzeichnisdienst. Schritt 6: A verschlüsselt den Mail-Key mit B‘s 1. Antrag auf Zertifikats- Public Key aus dem ausstellung Zertifikat Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 21  Technische Universität München 4.5.3 Hierarchie von CAs Die Wurzel-Instanz: root besitzt ein root Zertifikat. Root Zertifikate sind selbstsigniert (trusted). Root CA stellt Zertifikate für untergeordnete CAs aus. Validierung eines Zertifikats: prüfen des Zertifizierungspfads. z.B. Alice eAlice z.B. LRZ, eLRZ Frage: Bob möchte A‘s Public-Key z.B. DFN, nutzen. Was muss Bob eDFN prüfen? Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 22  Technische Universität München Zertifikatvalidierung Prüfen der Gültigkeit der Signatur des Zertifikats: Validierungspfad: Jedes Zertifikat auf dem Pfad muss die Bedingungen 1-5 erfüllen: 1. Die Signatur ist gültig und 2. es werden keine veralteten Verfahren (z.B. SHA-1) genutzt. 3. Das Zertifikat ist nicht zurückgerufen. 4. Das Zertifikat ist noch nicht abgelaufen. 5. Der Zertifizierungspfad endet bei einer Root-CA, der vertraut wird. Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 23  Technische Universität München 4.5.4 Zertifikatsrückruf (Revocation) Problem: Privater Key ist offengelegt oder ungültig geworden. Frage: In welchen Situationen könnte dies vorkommen? Lösung: Online Certificate Status Protocol (OCSP) Stapling Server erfragt regelmässig Gültigkeits-Bestätigung von CA. Bestätigung ist über mehrere Requests gültig. Server liefert Bestätigung beim Verbindungs- aufbau mit. Frage: mögliche Probleme? Vorlesung IT-Sicherheit, WS 24/25, C. Eckert, Kapitel 4: Schlüsselmanagement 24