Netzwerksicherheit Teil 6: Sicherheitsprotokolle Martin Mauve, Björn Scheuermann und Philipp Hagemeister Sommersemester 2015 Heinrich-Heine-Universität Düsseldorf Netzwerksicherheit Sicherheitsprotokolle 1
Kryptographische Grundlagen Im vorangegangenen Kapitel haben wir betrachtet, wie die Struktur von Netzwerken und Protokolle mit deren Sicherheit zusammenhängt In diesem Kapitel betrachten wir nun einige Netzwerkprotokolle, die in unterschiedlicher Weise Sicherheit bieten Solche Protokolle setzen fast immer kryptographische Techniken ein Kryptographie ist nicht Thema dieser Vorlesung! Wir betrachten kryptographische Primitive als Black Box und interessieren uns hier dafür, wie sie eingesetzt werden Wir schauen uns zunächst im Überblick die wichtigsten kryptographischen Bausteine an die Beschreibungen sind vereinfacht und teils unvollständig Netzwerksicherheit Sicherheitsprotokolle 2
Zufallszahlen Zum Generieren von Schlüsseln, Tokens, oder Session-IDs brauchen wir Zufall Aber Computer arbeiten deterministisch! Woher kriegen wir Zufall? Dedizierte Zufalls-Hardware (Radioaktiver Zerfall u.a.) Dedizierte Entropie-Server (z.b. random.org) Abweichung der Uhr, Performance-Counter-Register Frequenz-/Spannungs-Schwankungen Temperatursensoren Mausbewegungen Netzwerkverkehr Dateisystem-Inhalte Aktueller Zustand des Systems (Prozess-ID, Portnummer) Netzwerksicherheit Sicherheitsprotokolle 3
Entropie Entropie: Maß für Zufall, Anzahl der zufälligen Bits Bei Werten x i mit Wahrscheinlichkeiten Entropie = P(x i ) log 2 P(x i ) i Ideale Münze: 2 1 2 log 2 1 2 = 1 Idealer Computer: 0 typisches Problem bei Heimroutern o.ä. Die Entropie muss der Länge des Schlüssels entsprechen. Netzwerksicherheit Sicherheitsprotokolle 4
Pseudozufallszahlengeneratoren (PRNGs) Problem: eingehende Entropie beschränkt (wenige Bits pro Sekunde) Lösung: Zufall in Software generieren Pseudoduzufallszahlengenerator (PRNG): Modifiziere internen Zustand, berechne daraus Ausgaben Beispiel: Linearer Kongruenz-Generator (LCG) X n+1 = (a X n + b) mod m Sehr einfach, typischerweise die Quelle für rand in C Parameter sind implementierungsspezifisch m ist typischerweise eine Zweierpotenz a ist teilerfremd zu m b ist oft 1 oder 12345 Netzwerksicherheit Sicherheitsprotokolle 5
Seeding X 0 muss von echtem Zufall kommen PRNGs haben ein seeding-funktion, die den internen Zustand setzt srand in C, Random.setSeed in Java, Random.seed in Python Kryptographische PRNGs ersetzen dabei nicht Sondern setzen X n+1 = X n seed Welchen Vorteil hat das? Mit einem XOR-Reseeding darf jeder (auch ein Angreifer) reseeden! Netzwerksicherheit Sicherheitsprotokolle 6
Kryptographische PRNGs Ein PRNG ist kryptographisch, wenn gilt: Aus vorherigen Ausgaben kann nicht aufpasst die folgenden Ausgaben geschlossen werden Aus folgenden Ausgaben kann nicht auf den vorherigen Ausgaben geschlossen werden Ein LCG ist kein kryptografischer Zufallszahlengenerator! Netzwerksicherheit Sicherheitsprotokolle 7
PRNGs: Fallstricke Achtung vor Backdoors! z.b. Dual_EC_DRBG von der NSA Achtung vor Inkompetenz! int make_random() { srand(time(null)); return rand(); } Was ist der Fehler im obigem Code? Was wenn wir hier statt eines LCGs ein besserer Algorithmus verwenden? Ein PRNG muss auch richtig initialisiert werden! Netzwerksicherheit Sicherheitsprotokolle 8
Zufall vom Betriebssystem Was sollen wir verwenden - Hardware- oder Software-Zufall? Fast immer genügt guter Software-Zufall In der Praxis: Kombination (/dev/urandom) /dev/random für verwürfelten Hardware-Zufall In der Praxis: Auch ein PRNG! Mit Entropie-Schätzung (von den Quellen) Wenn keine Entropie mehr vorhanden: Warten! /dev/urandom gibt einfach weiter Werte aus Netzwerksicherheit Sicherheitsprotokolle 9
Fallstricke in der Praxis Ein sicherheitsbewusster Administrator führt alle Anwendungen nur noch in chroots aus. Was passiert? Achtung! /dev/random und /dev/urandom können in chroots o.ä. fehlen!... oder weil keine Datei-Handles mehr verfügbar sind Was macht die Anwendung dann? Im besten Fall: Einen Fehler melden! Im schlimmsten Fall (OpenSSL): Versuchen Zufall selber zu initialisieren, z.b. aus Zeit und Prozess-IDs Darum neuer (2014) system call getrandom Netzwerksicherheit Sicherheitsprotokolle 10
Symmetrische Verschlüsselung Bei symmetrischen Kryptoverfahren kennen Sender und Empfänger beide denselben Schlüssel Der Schlüssel ist eine Bitfolge fester Länge (z. B. 128 Bit) Nachrichten, die mit Schlüssel K verschlüsselt wurden, können nur mithilfe von K wieder entschlüsselt werden Beispiele für symmetrische Verschlüsselungsalgorithmen: AES, Blowfish, Serpent, Twofish; historisch: DES, RC4 Netzwerksicherheit Sicherheitsprotokolle 11
Asymmetrische Verschlüsselung Separate Schlüssel für alle Paare von Kommunikationspartnern sind oft nicht möglich Dann helfen asymmetrische ( Public Key ) Verfahren (z. B. RSA, ElGamal, versch. EC-Algorithmen,...) Jeder Benutzer hat einen privaten und einen öffentlichen Schlüssel (hier mit K und K + bezeichnet) Was mit dem öffentlichen Schlüssel verschlüsselt wurde, kann nur mit dem privaten wieder entschlüsselt werden Netzwerksicherheit Sicherheitsprotokolle 12
Digitale Unterschriften Public-Key-Kryptographie lässt sich umgekehrt anwenden: Was mit dem privaten Schlüssel verschlüsselt wurde, kann nur mit dem passenden öffentlichen Schlüssel entschlüsselt werden Das ermöglicht Absenderauthentifizierung und digitale Signaturen: Die Nachricht kann nur vom Besitzer des privaten Schlüssels unterschrieben worden sein Netzwerksicherheit Sicherheitsprotokolle 13
Kryptographische Hashfunktionen Public-Key-Kryptographie ist rechenaufwändig und deshalb langsam Techniken für digitale Unterschriften werden daher oft mit kryptographischen Hashfunktionen kombiniert Eine Hashfunktion ist eine Funktion, die eine Eingabe auf einen Hashwert fester Länge abbildet Bei einer kryptographischen Hashfunktion ist es nicht möglich, zu einem gegebenen Hashwert y eine Nachricht x zu finden, für die H(x) = y (eine Kollision) Aktuelle Beispiele: SHA-2, SHA-3, Skein, Whirlpool Historisch (Komplexität der besten Kollisionsattacke): SHA-1 (2 51 ), MD5 (2 21 ), MD4 (2) Netzwerksicherheit Sicherheitsprotokolle 14
Digitale Signaturen mit Hashes Netzwerksicherheit Sicherheitsprotokolle 15
Schlüsselaustauschprotokolle Mit Schlüsselaustauschprotokollen können sich zwei Kommunikationspartnern über eine nicht abhörsichere Leitung auf einen gemeinsamen Schlüssel einigen Bekanntestes Beispiel: Diffie-Hellman-Schlüsselaustausch Um sog. Man-in-the-Middle-Angriffe zu verhindern, wird das üblicherweise mit Public-Key-Kryptographie kombiniert (Abbildung: [Wikipedia 2006]) Netzwerksicherheit Sicherheitsprotokolle 16
Public Key Infrastructure (PKI) Wie findet man bei asymmetrischer Krytographie den richtigen öffentlichen Schlüssel seines Kommunikationspartners? Welche Probleme sehen Sie? Das zentrale Problem: Vertrauenswürdige Abbildung einer realen Identität auf den dazugehörigen öffentlichen Schlüssel Netzwerksicherheit Sicherheitsprotokolle 17
Zertifikate Netzwerksicherheit Sicherheitsprotokolle 18
Vertrauenswürdigkeit von Zertifikaten Kann man einem Zertifikat vertrauen? Einem Zertifikat kann man höchstens so viel vertrauen, wie demjenigen, der es ausgestellt hat (in unserem Beispiel Bob): Vertraue ich darauf, dass er ehrlich ist? Vertraue ich darauf, dass er die Identität richtig geprüft hat? Vertraue ich darauf, dass er gut auf seinen geheimen Schlüssel aufpasst? Weiteres Problem: woher bekommt man zuverlässig den öffentlichen Schlüssel desjenigen, der ein Zertifikat ausgestellt hat? Netzwerksicherheit Sicherheitsprotokolle 19
Public Key Infrastructure (PKI) Wer sollte für wen Zertifikate ausstellen? Die Regeln nach denen Zertifikate ausgestellt werden und die dafür notwendige Infrastruktur nennt man Public Key Infrastructure (PKI): Häufig: oligopolistisch und hierarchisch (X.509/PKIX) Alternative: anarchisch (Web of Trust) Zentrale Frage: wem vertraue ich? Netzwerksicherheit Sicherheitsprotokolle 20
Hierarchisches Vorgehen Es gibt einige Anbieter, die sogenannte Root-Zertifikate besitzen: Mit einem Root-Zertifikat zertifiziert man sich selbst (ich bestätige hiermit, dass ich ich bin) Root-Zertifikate schaffen kein neues Vertrauen Root-Zertifikaten könnte man z.b. vertrauen, weil sie als Bestandteile von Programmen oder Betriebssystemen ausgeliefert werden Jemand, der von einem solchen Anbieter ein Zertifikat erhalten hat, kann dann wieder Zertifikate für andere ausstellen Wann kann man einem Zertifikat in einem solchen hierarchischen System vertrauen? Netzwerksicherheit Sicherheitsprotokolle 21
Vertrauen beim hierarchischen Vorgehen Einem Zertifikat A in einer hierarchischen PKI kann man nur dann vertrauen, wenn: es eine Kette von Zertifikaten gibt, die von einem Root Zertifikat zu A führt bei dieser Kette jeder Nachfolger vom Vorgänger zertifiziert wird man jedem einzelnen Element dieser Kette vertraut Fazit: je länger die Kette ist, desto schwerer fällt das Vertrauen Konsequenz: meist möchte man sein Zertifikat direkt von einem vertrauenswürdeigen Inhaber eines Root-Zertifikats erhalten Netzwerksicherheit Sicherheitsprotokolle 22
Hierarchische PKI im Internet Im Internet kommen häufig PKI Systeme zum Einsatz, die auf X.509/PKIX basieren X.509 ist ein allgemeiner Standard zur Darstellung von Zertifikaten PKIX ist eine IETF Arbeitsgruppe die X.509 auf die Bedürfnisse des Internet anpasst Das zentrale Dokument: RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Sehr trocken! Im folgenden schauen wir uns einfach einmal das Zertifikat für das Homebanking der Deutschen Bank an Netzwerksicherheit Sicherheitsprotokolle 23
X.509 PKIX Zertifikat Certificate: Version: 3 Serial Number: 22:59:3d:f4:39:48:06:69:a6:5e:91:80:c6:da:b4:2c Issuer: O=VeriSign, Inc. CN=VeriSign Class 3 Extended Validation SSL SGC CA Validity: Not Before: Oct 7 00:00:00 2010 GMT Not After : Oct 17 23:59:59 2011 GMT Subject: O=Deutsche Bank AG CN=meine.deutsche-bank.de Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00 cb 50 dc... Signature Algorithm: sha1withrsaencryption b1 02 d0 ab... Netzwerksicherheit Sicherheitsprotokolle 24
Das dazugehörige VeriSign-Zertifikat Certificate: Version: 3 Serial Number: 2c:48:dd:93:0d:f5:59:8e:f9:3c:99:54:7a:60:ed:43 Issuer: O=VeriSign, Inc. CN=VeriSign Class 3 Public Primary Certification Authority - G5 Validity: Not Before: Nov Not After : Nov 8 00:00:00 2006 GMT 7 23:59:59 2016 GMT Subject: O=VeriSign, Inc. CN=VeriSign Class 3 Extended Validation SSL SGC CA Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00 bd 56 88... Signature Algorithm: sha1withrsaencryption 27 74 a6 34... Netzwerksicherheit Sicherheitsprotokolle 25
Das Root-Zertifikat Certificate: Version: 3 Serial Number: 57:bf:fb:03:fb:2c:46:d4:e1:9e:ce:e0:d7:43:7f:13 Issuer: O=VeriSign, Inc. OU=Class 3 Public Primary Certification Authority Validity: Not Before: Nov Not After : Nov 8 00:00:00 2006 GMT 7 23:59:59 2021 GMT Subject: O=VeriSign, Inc. CN=VeriSign Class 3 Public Primary Certification Authority - G5 Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00 af 24 08... Signature Algorithm: sha1withrsaencryption a9 7b 66 29... Netzwerksicherheit Sicherheitsprotokolle 26
Certificate Revocation Geheime Schlüssel können kompromittiert werden Dann muss man Zertifikate ungültig machen können Typisches Vorgehen: Zertifikate haben eine eingeschränkte Lebenszeit Wenn sie während dieser Zeit ungültig werden: Melden beim Herausgeber des Zertifikats Dieser setzt das Zertifikat auf eine Certificate Revocation List (CRL) Die CRL wird regelmäßig bekanntgegeben... oder man fragt immer vor Annahme eines Zertifikates beim Herausgeber nach, ob es auf dieser Liste steht Netzwerksicherheit Sicherheitsprotokolle 27
SSL/TLS Ein Anwendungsgebiet für PKI (wahrscheinlich das wichtigste) im Internet heute sind verschlüsselte Verbindungen zu Internet-Servern Gängigste Technik: SSL (Secure Sockets Layer) bzw. TLS (Transport Layer Security) Protokoll(e) zum Authentifizieren und Verschlüsseln von TCP-Verbindungen SSLv2 ursprünglich von Netscape entwickelt Weiterentwickelt zu SSLv3 Von der IETF nochmals weiterentwickelt und standardisiert als TLS (in RFC 2246) Netzwerksicherheit Sicherheitsprotokolle 28
SSL/TLS SSL bzw. TLS sind (teilweise unnötig) komplexe Protokolle Deshalb hier nur ein kurzer Abriss der wesentlichen Grundlagen Prinzip von SSL/TLS: zusätzliche Protokollschicht zwischen Transport- und Anwendungsprotokoll implementiert im Userspace (typischerweise in einer Bibliothek, z. B. OpenSSL) nutzt eine darunterliegende normale TCP-Verbindung verlässt sich insbes. auf Zuverlässigkeit und Reihenfolgeerhaltung durch TCP Einer der häufigsten Anwendungsfälle: HTTPS = HTTP über SSL/TLS über TCP über IP über... Netzwerksicherheit Sicherheitsprotokolle 29
Protokollstapel mit SSL/TLS Tatsächlich besteht SSL bzw. TLS aus mehreren Protokollen in zwei Teilschichten: Netzwerksicherheit Sicherheitsprotokolle 30
SSL/TLS-Handshake Struktur eines SSL/TLS-Handshakes (vereinfacht): Beispiel für eine subtile Falle: Wofür der Hash über bisherige Nachrichten? Ein Man-in-the-Middle könnte sonst in der 1. Nachricht die Liste unterstützter Verfahren kürzen, um schwache Verschlüsselung zu erzwingen! Netzwerksicherheit Sicherheitsprotokolle 31
Transport von Anwendungsschichtdaten Zum Transport über SSL oder TLS werden die Anwendungsschichtdaten...... und dann über die darunterliegende TCP-Verbindung übertragen. Netzwerksicherheit Sicherheitsprotokolle 32
HTTPS: Fallstricke HTTP(S)-Authentifizierung wird oft mit Cookies (Header in jeder HTTP(S)-Anfrage) realisiert Cookies für http://example.com gelten auch für https://example.com und umgekehrt Wie kann ein Angreifer das ausnutzen? Angreifer (MITM) kapert irgendeine unverschlüsselte HTTP-Verbindung...... und leitet weiter auf http://example.com/ Browser sendet Zugangsdaten (Cookies) unverschlüsselt Abhilfe: Secure-Attribut für Cookies spezifizieren Diese Cookies werden dann nur über HTTPS übertragen [RFC 6265: HTTP State Management Mechanism, Section 5.4] Netzwerksicherheit Sicherheitsprotokolle 33
HTTPS: Strict Transport Security Problem: Benutzer können SSL-Fehler ignorieren ( click-through insecurity ) Und steuern häufig (http://)example.com statt https://example.com an Lösung: HTTP-Header Strict-Transport-Security Für einen angegebenen Zeitraum (z. B. 1 Jahr) sendet der Browser alle Anfragen an example.com über HTTPS SSL-Fehler können nicht mehr ignoriert werden Von modernen Browsern unterstützt (außer Internet Explorer, aber wahrscheinlich ab IE11/Edge) Darüber hinaus HSTS-Domain-Listen fest eingebaut [IETF Draft: HTTP Strict Transport Security (HSTS)] Netzwerksicherheit Sicherheitsprotokolle 34
TLS und Kompression: Fallstricke Annahmen: TLS kombinieren Kompression und Verschlüsselung Manchmal auch: Kompression auf anderen Schichten, z.b. HTTP Content-Encoding Kompressionsverfahren ersetzen am häufigsten vorkommenden / längsten Zeichenfolgen Angreifer kann verschlüsselten Text mitlesen Angreifer kann Opfer veranlassen beliebige URLs zu laden Wie kann der Angreifer das Geheimnis tok finden? Netzwerksicherheit Sicherheitsprotokolle 35
TLS: CRIME/BREACH-Angriffe Schaue auf die Längen der verschlüsselten Anfragen! Probiere URL mit tok=a, tok=b, tok=c, etc. aus Wird die Anfrage kleiner (besser komprimiert): Zeichen gefunden! Dann Suche für das nächste Zeichen starten Laufzeit insgesamt linear, nicht exponentiell! Netzwerksicherheit Sicherheitsprotokolle 36
SSL/TLS Zusammenfassung SSL bzw. TLS ermöglichen Authentifizierung und Verschlüsselung in anwendungsprotokollunabhängiger Weise Sie sind deshalb (relativ) einfach in neue Anwendungen integrierbar Es gibt viele Feinheiten/Erweiterungen, die wir hier nicht erwähnt haben, z. B.: Wiederaufnahme von ausgehandelten Verbindungen Authentifikation auch des Clients... Wichtig: SSL/TLS ist nicht unfehlbar und höchstens so vertrauenswürdig wie das verwendete Zertifikat! [Soghoian, Stamm: Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL, http://files.cloudprivacy.net/ssl-mitm.pdf] Netzwerksicherheit Sicherheitsprotokolle 37
Web of Trust Alternative zu hierarchischen PKIs Grundsätzliche Idee: Benutzer stellen anderen Benutzern Zertifikate aus zur Überprüfung eines öffentlichen Schlüssels: suche Zertifikate bezüglich dieses öffentlichen Schlüssels die von Personen ausgestellt wurden, die ich kenne und denen ich vertraue Beispiel (Wikipedia/Ogmios): Netzwerksicherheit Sicherheitsprotokolle 38
Web of Trust Konkretes Vorgehen I Bob erzeugt ein Schlüsselpaar (privater Teil, öffentlicher Teil) Bob lädt den öffentlichen Teil auf einen Key-Server Alice möchte mit Bob sicher kommunizieren Was muss sie dazu machen? Alice überprüft, ob der öffentliche Teil des Schlüssels tatsächlich zu Bob gehört z. B. durch einen Telefonanruf bei Bob und Abgleich des Schlüssels Das ist ganz schön aufwändig! Wie kann man den Aufwand reduzieren? Netzwerksicherheit Sicherheitsprotokolle 39
Web of Trust Konkretes Vorgehen II Alice stellt Bob nach der Überprüfung ein Zertifikat aus Wenn jetzt jemand den öffentlichen Schlüssel von Alice kennt und (!) ihr vertraut......dann kann er mit diesem Zertifikat die Abbildung von Bob auf seinen öffentlichen Schlüssel überprüfen Allgemeiner: Finde Zertifikate... die den gesuchen öffentlichen Schlüssel zertifizieren und die von Personen ausgestellt wurden, deren öffentlichen Schlüssel ich kenne und denen ich vertraue Diskutieren Sie diese Idee, was halten Sie davon? Netzwerksicherheit Sicherheitsprotokolle 40
Web of Trust Formal I Public Keyring: fremde+eigene öffentliche Schlüssel sowie zugehörige Zertifikate Private Keyring: eigene private Schlüssel Owner Trust für jeden Schlüssel im Public Keyring: unknown unbekannt, nicht überprüft not trusted nicht vertrauenswürdig marginal geringes Vertrauen complete volles Vertrauen ultimate privater Schlüssel bekannt (eigener Schlüssel!) Netzwerksicherheit Sicherheitsprotokolle 41
Web of Trust Formal II Signatory Trust: Zertifikate erhalten ebenfalls einen Vertrauenswert complete wenn man es selber ausgestellt hat complete wenn es von jemandem ausgestellt wurde, dessen Owner Trust complete ist marginal wenn es von jemandem ausgestellt wurde, dessen Owner Trust marginal ist not trusted sonst Netzwerksicherheit Sicherheitsprotokolle 42
Web of Trust Formal III Key Legitimacy: Anhand des Vertrauens in die relevanten Zertifikate versucht man abzuleiten, ob ein öffentlicher Schlüssel korrekt ist: x = Vorhandene Signaturen mit Signatory Trust marginal X = Anzahl notwendiger Signaturen marginal y = Vorhandene Signaturen mit Signatory Trust complete Y = Anzahl notwendiger Signaturen complete Key Legitimacy L = x/x + y/y (häufig X = 3 und Y = 1) L = 0: nicht vertrauenswürdig 0 < L < 1: teilweise vertrauenswürdig L 1: vertrauenswürdig Netzwerksicherheit Sicherheitsprotokolle 43
Pretty Good Privacy (PGP) Pretty Good Privacy ist ein Programm zum Verschlüsseln und Signieren von Daten mittels Public-Key-Kryptographie Öffentliche Schlüssel werden dabei nach dem Prinzip des Web of Trust zertifiziert Historie erste Version 1991 von Phil Zimmermann konnte nicht aus den USA exportiert werden als Buch veröffentlicht, abgetippt, wurde zu PGPi 1997 wurde PGP von NAI (McAfee) aufgekauft und weiterentwickelt, kein offener Quellcode mehr Gegenbewegung 1998, 2007: OpenPGP (RFC 4880) populäre Implementierung von OpenPGP: GnuPG Netzwerksicherheit Sicherheitsprotokolle 44
GnuPG (gpg) Um gpg bequem zu nutzen braucht man: gpg Anwendungsprogramme, die gpg einbinden (z. B. Enigmail als Plugin für Thunderbird) (optional) eine GUI zum Management von Schlüssel (z. B. KGpg) Typisches Vorgehen: mit gpg/kgpg einen neuen Schlüssel erzeugen auf einen Keyserver hochladen (werden synchronisiert!) andere Schlüssel unterschreiben (Web of Trust) Netzwerksicherheit Sicherheitsprotokolle 45
Let s have a party Hausaufgabe (Mittwoch, den 17. Juni 2015) Wir veranstalten in der nächsten Vorlesung eine Key-Signing-Party. Installieren Sie dafür gpg, eine geeignete Erweiterung für Ihren Mail-Client und optional eine GUI für das Schlüsselmanagement. Erzeugen Sie ein PGP-Schlüsselpaar (oder verwenden Sie ein bestehendes) und legen es auf einem Key-Server ab. Verwenden Sie dazu Ihren richtigen Namen und eine Ihrer E-Mail-Adressen als Attribute. Danach bereiten Sie bitte mindestens fünf Zettel vor (z.b. mit Hilfe von http://keysheet.net/), auf denen Ihr Name, Ihre E-Mail-Adresse und der Fingerprint Ihres öffentlichen Schlüssels stehen. Außerdem bringen Sie bitte zur nächsten Vorlesung einen Ausweis/Führerschein mit Lichtbild mit. [The Keysigning Party HOWTO, http://cryptnet.net/fdp/crypto/ keysigning_party/en/keysigning_party.html] Netzwerksicherheit Sicherheitsprotokolle 46
Party! Hausaufgabe (Jetzt) Suchen Sie die öffentlichen Schlüssel, zu denen Sie Zettel erhalten haben auf einem Key-Server. Überprüfen Sie Name und Fingerprint. Wenn beides übereinstimmt, dann unterschreiben Sie den Schlüssel und laden ihn wieder hoch. Beobachten Sie, wie Ihr Schlüssel nach und nach von ihren Kommilitonen unterschrieben wird! Wählen Sie für die Kommilitonen, deren Schlüssel Sie unterschrieben haben, ein Ihrer Meinung nach geeignetes Vertrauensniveau. Suchen Sie nach anderen Kommilitonen auf einem Key-Server. Überprüfen Sie so die Funktionsweise des Web of Trust! Schicken Sie sich gegenseitig verschlüsselte und/oder signierte E-Mails. Netzwerksicherheit Sicherheitsprotokolle 47
Ex-Kurs: Passwortwahl Wie wählen wir Passwörter? Und wie nicht? Häufigste Passwörter (Komplexität: 10 0 10 3 ) 12345, Passwort, qweasd, Benutzername Wörter / Namen (10 3 10 6 ) Nudelsuppe, HeinrichHeine Wörter mit Nummern am Ende/Leetspeak (10 5 10 7 ) Nudelsuppe3, H31nrichHeine (12+) zufällig generierte Buchstaben (10 20 10 60 ) niefubahth7a, Uoquozu1oo0neevi Aber: Nur mit Passwortmanager (im Webbrowser, kwallet, keepass, GNOME wallet,...) merkbar Trick: Einen Satz ausdenken Die Heinrich-Heine-Universität bietet seit 1965 beste Bedingungen für das akademische Leben. DHHUbs1bBfdaL Nicht ganz so gut: Satz aus einem Buch entnehmen Netzwerksicherheit Sicherheitsprotokolle 48
Speichern von Passwörtern Viele Leute verwenden Passwörter bei mehreren Diensten Dienste werden gehackt Bei Hack eines Dienstes: Angreifer erlangt Zugriff auf E-Mail-Konto, Social Media,... Darum: Passwörter nicht im Klartext abspeichern! Welches kryptographische Primitiv kann hier helfen? Hash des Passworts abspeichern Beim Login hash(eingabe) == gespeicherter Hash vergleichen Dann muss der Angreifer alle Passwörter durchprobieren! Netzwerksicherheit Sicherheitsprotokolle 49
Passwörter knacken Idee: Alle Passwörter hashen, dies effizient speichern Erlaubt schnelle Berechnung von Hash Passwort Diese Rainbow Tables sind nicht zu groß z.b. MD5, 9 alphanumerische Zeichen: 24GB Verteidigung: Verwende für jeden Eintrag irgendein salt und speichere salt und hash(passwort + salt) Dann muss der Angreifer wieder für jeden Eintrag alle Passwörter hashen Vorsicht: Mit GPUs kann auch das schnell gehen! Darum stretching: hash(hash(..hash(passwort+salt)..)) Nicht selber implementieren! Sondern PBKDF2/bcrypt/scrypt verwenden (oder erst gar keine Passwörter speichern, s.u.) Netzwerksicherheit Sicherheitsprotokolle 50
Single Sign On Typisches Arbeitsszenario: Alice meldet sich morgens an ihrem Arbeitsplatzrechner an......und nutzt dann über den Tag immer wieder verschiedene Netzdienste: Dateifreigaben Drucker E-Mail... Wie können all diese Netzdienste sicher sein, dass wirklich Alice an dem Rechner sitzt? Netzwerksicherheit Sicherheitsprotokolle 51
Single Sign On Eine Möglichkeit: Jeder Dienst hat eine eigene Benutzer- und Passwortdatenbank Der Benutzer meldet sich bei allen einzeln mit dem jeweiligen Passwort an Netzwerksicherheit Sicherheitsprotokolle 52
Single Sign On Eine Möglichkeit: Jeder Dienst hat eine eigene Benutzer- und Passwortdatenbank Der Benutzer meldet sich bei allen einzeln mit dem jeweiligen Passwort an Keine gute Idee: Immer wieder müssen Kennwörter eingegeben werden Verwaltung ist aufwändig und fehleranfällig Sicherheitsrelevante Daten (Passwörter) liegen an vielen Stellen verstreut Netzwerksicherheit Sicherheitsprotokolle 53
Single Sign On Viel besser wäre: Eine zentrale, gemeinsame Authentifizierungsstelle Einmaliges Anmelden des Benutzers Danach können alle Netzdienste ohne erneute Passworteingabe genutzt werden Im folgenden zwei Beispiele: Kerberos und OpenID Netzwerksicherheit Sicherheitsprotokolle 54
Kerberos Authentifizierungsdienst, der in Anwendungen integriert werden kann Sogenannte Kerberized Applications Beispiele: SSH, Authentifizierung in Windows, alle Dienste mit GSS-API Entstanden im Projekt Athena am MIT (1983 1991) als Teil eines umfassenden IT-Konzeptes Netzwerksicherheit Sicherheitsprotokolle 55
Kerberos Ein Kerberos-System besteht aus: einem Anmeldeserver (Key Distribution Center [KDC] oder Authentication Server [AS]) Principals, das sind Benutzer und Netzdienste, die sich (gegenseitig) über Kerberos authentifizieren können Anwendungen, die die Kerberos-Authentifizierung verwenden Netzwerksicherheit Sicherheitsprotokolle 56
Schlüssel in Kerberos Kerberos verwendet symmetrische Kryptographie Das KDC hat einen gemeinsamen symmetrischen Schlüssel mit jedem Principal bei Menschen: Passwort Netzwerksicherheit Sicherheitsprotokolle 57
Prinzipielle Funktionsweise Alice (A) möchte mit dem Mailserver Bob (B) sprechen und ihm dafür beweisen, dass sie wirklich Alice ist. Grundidee: KDC erzeugt einen neuen Schlüssel K AB und übermittelt ihn an Alice und Bob Alice und Bob beweisen sich gegenseitig, dass sie K AB kennen Netzwerksicherheit Sicherheitsprotokolle 58
Prinzipielle Funktionsweise Alice (A) möchte mit dem Mailserver Bob (B) sprechen und ihm dafür beweisen, dass sie wirklich Alice ist. 1 Alice teilt dem KDC mit, dass sie mit Bob sprechen möchte Netzwerksicherheit Sicherheitsprotokolle 58
Prinzipielle Funktionsweise Alice (A) möchte mit dem Mailserver Bob (B) sprechen und ihm dafür beweisen, dass sie wirklich Alice ist. 2 Das KDC erzeugt einen neuen Schlüssel K AB Netzwerksicherheit Sicherheitsprotokolle 58
Prinzipielle Funktionsweise Alice (A) möchte mit dem Mailserver Bob (B) sprechen und ihm dafür beweisen, dass sie wirklich Alice ist. 3 Das KDC verschlüsselt K AB mit K A zu {K AB } KA und verwendet K B, um {K AB, Alice } KB (ein Ticket ) zu erzeugen; beides wird an Alice übertragen Netzwerksicherheit Sicherheitsprotokolle 58
Prinzipielle Funktionsweise Alice (A) möchte mit dem Mailserver Bob (B) sprechen und ihm dafür beweisen, dass sie wirklich Alice ist. 4 Alice kann {K AB } KA entschlüsseln und merkt sich K AB und das Ticket Netzwerksicherheit Sicherheitsprotokolle 58
Prinzipielle Funktionsweise Alice (A) möchte mit dem Mailserver Bob (B) sprechen und ihm dafür beweisen, dass sie wirklich Alice ist. 5 Alice leitet das Ticket an Bob weiter und fügt die mit K AB verschlüsselte aktuelle Zeit ( Authenticator ) hinzu Netzwerksicherheit Sicherheitsprotokolle 58
Prinzipielle Funktionsweise Alice (A) möchte mit dem Mailserver Bob (B) sprechen und ihm dafür beweisen, dass sie wirklich Alice ist. 6 Bob kann das Ticket entschlüsseln und erfährt so K AB ; ist der Authenticator korrekt und aktuell, weiß Bob, dass die Anfrage von Alice kommt Netzwerksicherheit Sicherheitsprotokolle 58
Prinzipielle Funktionsweise Alice (A) möchte mit dem Mailserver Bob (B) sprechen und ihm dafür beweisen, dass sie wirklich Alice ist. 7 Bob kann sich nun gegenüber Alice ausweisen, indem er die Zeit aus dem Authenticator + 1 mit K AB verschlüsselt und an Alice schickt Netzwerksicherheit Sicherheitsprotokolle 58
Prinzipielle Funktionsweise Alice (A) möchte mit dem Mailserver Bob (B) sprechen und ihm dafür beweisen, dass sie wirklich Alice ist. Bob weiß, dass er mit Alice spricht Alice weiß, dass sie mit Bob spricht Netzwerksicherheit Sicherheitsprotokolle 58
Ticket Granting Tickets Problem: Alice benötigt für jede Ticketanforderung immer wieder K A Also müsste Alice s Passwort zwischengespeichert bleiben (oder sie muss es ständig neu eintippen...) Lösungsidee: Füge einen Netzwerkdienst hinzu, der Tickets mit begrenzter Gültigkeitsdauer ausstellt Dann braucht Alice nur zu Beginn einmal ein Ticket für diesen Ticket Granting Server (TGS) Umsetzung dieses Ticket Granting Ticket (TGT) ist sehr ähnlich zu normalen Tickets Netzwerksicherheit Sicherheitsprotokolle 59
Anfordern eines TGT Alice möchte ein TGT erhalten. 1 Alice meldet sich (z. B. beim Login) beim KDC und beantragt ein TGT mit einem festen Ablaufzeitpunkt typische Gültigkeitsdauer: 8 Stunden Netzwerksicherheit Sicherheitsprotokolle 60
Anfordern eines TGT Alice möchte ein TGT erhalten. 2 Das KDC erzeugt einen Sitzungsschlüssel S A für Alice Netzwerksicherheit Sicherheitsprotokolle 60
Anfordern eines TGT Alice möchte ein TGT erhalten. 3 Das KDC schickt {S A } KA und {S A, Alice,Ablaufzeitpunkt} KKDC (das TGT) an Alice Netzwerksicherheit Sicherheitsprotokolle 60
Anfordern eines TGT Alice möchte ein TGT erhalten. Alice erhält so S A und das (für sie nicht lesbare) TGT Netzwerksicherheit Sicherheitsprotokolle 60
Nutzen eines TGT Alice möchte nun mit Bob kommunizieren. 1 Alice teilt dem TGS mit, dass sie mit Bob sprechen möchte, und sendet ihr TGT {S A, Alice } KKDC mit Netzwerksicherheit Sicherheitsprotokolle 61
Nutzen eines TGT Alice möchte nun mit Bob kommunizieren. 2 TGS entschlüsselt das TGT, erhält so S A und erzeugt einen neuen Schlüssel K AB falls das TGT noch gültig ist Netzwerksicherheit Sicherheitsprotokolle 61
Nutzen eines TGT Alice möchte nun mit Bob kommunizieren. 3 TGS sendet {K AB } SA sowie das Ticket {K AB, Alice } KB an Alice Netzwerksicherheit Sicherheitsprotokolle 61
Nutzen eines TGT Alice möchte nun mit Bob kommunizieren. Alles weitere wie gehabt Alice benötigt K A also nicht mehr! Netzwerksicherheit Sicherheitsprotokolle 61
Weitergehende Fragen Wie werden Replay-Angriffe verhindert? Kann das KDC repliziert werden? Können KDCs verschiedener administrativer Domänen zusammenarbeiten? Netzwerksicherheit Sicherheitsprotokolle 62
Replay-Angriffe Wie könnte hier ein Replay-Angriff aussehen? Netzwerksicherheit Sicherheitsprotokolle 63
Verhindern von Replay-Angriffen Ein Principal akzeptiert nur Zeitstempel, die nahe an seiner eigenen Systemzeit liegen Kerberos erfordert synchronisierte Uhren! dies alleine reicht noch nicht... Ein Principal merkt sich alle akzeptierten Zeitstempel eines anderen Principals und akzeptiert diese anschließend nicht mehr akzeptierte Zeitstempel dürfen vergessen werden, sobald sie nicht mehr nah genug an der eigenen Systemzeit liegen die Auflösung der Zeitstempel beschränkt die Anzahl der akzeptierten Verbindungen pro Zeiteinheit Was passiert wenn man als Angreifer die Systemzeit eines Principals Bob manipulieren kann? Angreifer stellt die Uhr vor Bob vergisst Zeitstempel Angreifer stellt die Uhr zurück und sendet die Nachrichten, die Alice an Bob geschickt hat, nochmal Netzwerksicherheit Sicherheitsprotokolle 64
Kerberos: Zusammenfassung Kerberos bietet Single Sign-On-Funktionalität in Netzwerken mittels eines zentralen Authentifizierungsservers Dort werden Tickets für einzelne Netzdienste erworben Mittels dieser Tickets kann dann eine Authentifizierung bei den Diensten erfolgen Ticket Granting Tickets vermeiden die Notwendigkeit, ständig den eigenen Schlüssel verwenden zu müssen Netzwerksicherheit Sicherheitsprotokolle 65
OpenID OpenID: Single Sign-On im Web Seit 2005 von einer Stiftung entwickelt Ein Provider übernimmt die Kontoverwaltung für eine Relying Party(auch Consumer genannt) Wie viele OpenID-Accounts haben Sie? Provider: AOL, Blogger, flickr, Launchpad, myopenid, MySpace, Steam, WordPress, Yahoo,... Früher auch google Relying Parties: Facebook, SourceForge, stackoverflow,... Im folgenden: Nur eine Variante von OpenID [OpenID Authentication 2.0, http://openid.net/specs/openid-authentication-2_0.html] Netzwerksicherheit Sicherheitsprotokolle 66
OpenID: Discovery Netzwerksicherheit Sicherheitsprotokolle 67
OpenID: Discovery Netzwerksicherheit Sicherheitsprotokolle 67
OpenID: Discovery Netzwerksicherheit Sicherheitsprotokolle 67
OpenID: Discovery Netzwerksicherheit Sicherheitsprotokolle 67
OpenID: Login Netzwerksicherheit Sicherheitsprotokolle 68
OpenID: Login Netzwerksicherheit Sicherheitsprotokolle 68
OpenID: Login Netzwerksicherheit Sicherheitsprotokolle 68
OpenID: Login Netzwerksicherheit Sicherheitsprotokolle 68
OpenID: Vorteile Benutzer hat freie Providerwahl Viele verschiedene Authentisierungsmethoden möglich Passwort, Chipkarte, Fingerabdruck, SSL-Zertifikat,... Relying Party muss nur einen Standard implementieren Viele verschiedene, kompatible Implementierungen Mehr als 1 Milliarde OpenID-Accounts Benutzer muss also nichts konfigurieren, kein neues Passwort wählen Erweiterungen erlauben die Bestätigung weiter Daten, z.b. Realname, Rolle,... Netzwerksicherheit Sicherheitsprotokolle 69
OpenID: Fallstricke OpenID dem Benutzer oft nicht bekannt (im Gegensatz zu z.b. Facebook Connect) Benutzer muss eine URL eingeben Abhilfe oft: Sehr viele Varianten und Modi (Attribute Exchange, Diffie-Hellman, ohne return_to, stateless, SSL, multi-step discovery, XRI,...) Mittlerweile wird stattdessen oft oauth eingesetzt Netzwerksicherheit Sicherheitsprotokolle 70