Layout der Vorlesung Kryptographie an der FH Furtwangen ========================================================== $Id: layout.txt,v 1.15 2003/11/26 16:03:13 dziadzka Exp $ Literaturempfehlungen: http://mirko.dziadzka.net/fhf/Cryptography/literatur Voraussetzungen: - Viel Interesse an Kryptographie - Es kann nicht Schaden, sich schon mal damit beschaeftigt zu haben, aber es ist nicht zwingend notwendig ------------------------------------------------------------------------ - Vorwort + Einleitung - Was soll die Vorlesung erreichen - Verständnis für die Möglichkeiten und vor allem die Probleme moderner Kryptographie Was wird geboten Vorstellung von Grundkonzepten moderner Kryptographie Was bieten die Was muss man beim Einsatz beachten (pitfalls) Vorstellung und Analyse häufig eingesetzter Protokolle sowohl "guter" als auch "schlechter" Vorstellung von "interessanten", aber nicht eingesetzten Protokollen Was wird _nicht_ geboten Zahlentheorie (auch spannend, aber ...) Statistik Kryptoanalyse der "Building Blocks" - Ziele der Kryptographie - Vertraulichkeit / confidentiality - Integrität / integrity - Authentizität / authentication - Nachweisbarkeit / non-repudiation - Anonymität / anonymity - Kurze Geschichte von der Antike bis zum WW2 (optional) - monoaphabetische chiffren - polyalphabetischen chiffren - enigma - one-time-pad (-> quantenkryptograhie) - was gibt es fuer angriffe - ciphertext only -> m, k - known plaintext -> k - choosen plaintext -> k - Angriff gegen das schwächste Glied der Kette - Krypto ist es nicht (wenn nicht grade selbstentwickelt) - Protokolle werden öfter von Laien entwickelt - Implementation ist fast immer von Laien - PRNGD - Sicherer Speicher - Caching von Keys - fallback auf alte Protokolle - zuviel Info im Fehlerfall / Orakel - Und ueber die Sicherheit unser Computer müssen wir nicht reden - ein (ex)student: du hast in dieser Aufzählung den User vergessen ----------------------------------------------------------------- 10 % - Sicherheit von Grundalgorithmen / Komplexitaet - Kerckhoffsches(sp?) Prinzip - Die Sicherheit eines Verschlüsselungsalgorithmus darf nur von der Geheimhaltung des Schlüssels abhängen, nicht von der Geheimhaltung des Algorithmus. - Wann ist ein algorithmus "sicher" - haengt von den zu schützenden Daten ab - Brute Force vs. Analyse des Algorithmus - Erforderliche "Ressourcen" des Angreifers > 2^128 - Grundbausteine der modernen Kryptograpie - Blockchiffren - 3DES, IDEA, AES - blocksize vs chiper size - mode of operations - ECB, Electronic Codebook - C[i] = E(K,P[i]) - same plaintext block -> same ciphertext block - CBC, Cipher Block Chaining - c[i] = E(K,P[i] + C[i-1]) - braucht einen IV: nonce - nonce systemweit! - OFB, Output Feedback Mode - K[i] = E(K, K[i-1]) - C[i] = P[i] + K[i] - CTR, Counter Mode - K[i] = E(K, nonce || i) - C[i] = P[i] + K[i] - nonce: msg-nr, rand, count - kann einzelnen Bloecke verschluesseln (db) - - Streamchiffren - Message XOR prngd(key) - Security Problem - Wiederholung des IV - gezieltes Kippen von Bits moeglich - Hashfunktionen - md5, sha-1, sha-256(new) - ideale vs praktische - h(foobar|baz) == h(foo|barbaz) -> Strukturerhaltung P = lambda x: len(x) | x h(a,b) -> h(P(a)|P(b)) use ASN1 or similar - h(a) == h(b) -> h(a|foo) == h(b|foo) - h(a|b) = f(h(a),b) -> uups - use: h(P(m)) instead of h(m) Schneier: - h(h(m) || m) - h(h(m)) -> use ASN.1 like Encoding of the message, siehe P oben -> use h(h(asn1(message))) - Message-Authentication-Code (MAC) - warum h(key,message) problematisch ist - length extension attack - warum h(message,key) problematisch ist Schneier: some clever key recovery attack in 2^(n/2) - HMAC: h(ki + C1 ,h(k + C2 ,data)) attack in 2^(n/2) - schneier: authenticate the meaning, not the message - include all information that you need to intepret the message (including protocol name, version, blocknumber, sizes, number, etc) - authentication of lower protocol level is not sufficent for authentication auf higher protocoll level - eindeutige darstellung -> siehe h(ab|c) == h(a|bc) - Zufallszahlengeneratoren, RNG, PRNG - hartes problem im computer - begriff der entropie - real random: seed the prng - simple implementation: - def seed(s): state = hash( state | s ) - def getblock(): Enc( state, ++C) - hash != Enc - use external prngd - wann hat prngd genuegend entropie - state sollte beim booten nicht verloren gehen - getblock loest nur das rand(2^n) Problem def rand(p): p < 2^n loop: r = rand(2^n) if r < p: return r - public key Verfahren - lösen das Problem des Schlüsselaustausches (zumindest zum Teil) - RSA, DSA, DH, ECC - primzahlgenerierung - a^(p-1) == 1 mod p - miller-rabin-test - aber: safe primes, etc. - Diffie-Hellman Key Exchange Protocol (1976) - man in the middle moeglich - RSA p,q, n = p*q e = 3, d: d*e = 1 mod phi(n) c = p^e mod n p = c^d mod n Padding ! - verschiedene e, d fuer sig/enc - Vermeidung von Orakeln - klare struktur der nachrichten - getrennte keys fuer - encryption - transport - storage - GAK ist hier sinnvoll - signatur - authentisierung - Performance - Sinnvolle Keylaengen - PKI - Hybride Ansätze - ENCPUB(k,r),ENCSYSM(r,m) - wenn e klein, dann muss hier auf padding geachtet werden, sonst ist DECPUB trivial -> SIGN(HASH(m)),m - perfect forward secrecy - Key negotioation / renegotiaion - Session Keys aushandeln - notwendig fuer PF - erschwert kryptoalanalyse gegen den eigentlichen key, da nur wenig material vorhanden ist - Diffie Hellman Key Exchange mit Auth - schneier 261ff -> nonce, minimal sec requirements <- dh data, auth -> dh data, auth - Nonce - eindeutig! global! - kann aus clock + misc gebildet werden - clock muss dafuer streng monoton sein (verify!) - reboot, same state - Timestamps - secure padding - das ende einer nachricht muss eindeutig erkennbar sein - message | 1 | 0 | 0 ... | 0 - eine nachricht mit padding ist immer laenger als das original! ----------------------------------------------------------------- 50 % - - secure channel - encrypted, authenticated, integrity protected - einen neuen key fuer jede verbindung - nachrichten numeriert (counter, kein wrap!) - schneier: E(A(m)) besser als A(E(m)) im secure channel - A(E()) hilft, nur pakete zu entschlusseln, die authentisch sind. - E(A()) schuetz die auth besser, aber: vorsicht mit fehlermeldungen. keine unnotige info rausgeben - auth != sig - auth ueber alle bisherigen daten - Angriffe auf Protokolle - replay - man-in-the-middle - Orakel - Kollisionen (besonders bei IVs und Hashes) -> don't invent a new protocol unless you name is Schneier. Use SSL or IPSec - ssl -> ClientHello accepta version, acceptable ciphers Nonce (256 Bit, inkl timestamp) SessionID <- ServerHello choose version + ciphers Nonce Define SessionId <- ServerKeyExchange public key <- ServerCertificate certs <- Optional: CertificateRequest <- ServerHelloDone -> ClientKeyExchange RSA(SessionKey) -> ChangeCipherSpec -> Finished <- ChangeCipherSpec <- Finished - keine Perfect Forward Secrecy garantiert - client waehlt premaster secret - DH wird nicht zwingend genutzt - ssh - pgp / S/mime -> Aber was "unterschreibe" ich hier - ipsec - Pitfalls - CRC als MAC (wavelan, cipe?) - Reuse des IV (wavelan) - ssh1 ----------------------------------------------------------------- 90 % - - Trusted Computing Environment - Der PC ist es nicht; kann TCPA helfen? - Smartcards - tamper protected hardware? Welches Angriffsszenario - wie authentisiert sich der Benutzer gegenüber der Karte? - PGP Smartcard - Sicherheit von Schlüsseln im Computer - nachrichtenformat dekodierung - TCPA - technische Details - politische Probleme Interessante Protokolle blinde unterschrift secret sharing / secret splitting digitales geld hashcash