IT-Sicherheit: Authentisierung, Sicherheitsprotokolle Authentisierung! Ziel! eindeutige Identifikation und Nachweis der Identität! Abwehr von Spoofing-Angriffen! Problem:! Nicht nur Mensch-zu-Gerät Interaktion, sondern auch! Gerät-zu-Gerät bzw. Gerät/Dienst-zu-Gerät/Dienst! Bemerkung: zunehmende Vernetzung u. Miniaturisierung: Geräte-zu-Geräte-Kommunikation steigt rapide an!! Notwendig: Konzepte und Verfahren, um sowohl! menschliche Individuen eindeutig zu identifizieren! als auch Geräte (Web-Server, Laptop, Mobiltelefon,...) und! Dienste (Dateisystem, Amazon, Bankportal,...) 2
Beispiele für die Authentisierung! Viele Beispiele in der Praxis:! Benutzer gegenüber PC (Mensch-zu-Gerät)! Mobiltelefon gegenüber Netzbetreiber (Gerät-zu Gerät)! Bankkunde gegenüber Bankautomat (Mensch-zu-Gerät)! WWW-Server gegenüber Nutzer (Dienst-zu-Mensch)! Laptop gegenüber Access Point im WLAN (Gerät-zu-Gerät) 3 Arten der Authentisierung! Authentisierung durch! Wissen: z.b. Passworte, PINs, kryptogr. Schlüssel ( Was ich weiß )! Besitz: z.b. Smartcard, USB-Token, SIM-Karte ( Was ich habe )! biometrische Merkmale: z.b. Fingerabdruck ( Was ich bin )! Mehrfaktor-Authentisierung: Kombination von Konzepten:! z.b. SIM-Karte + PIN, Biometrie + Zugangskarte,! Beispiel: 2-Faktor-Authentisierung beim Mobiltelefon: (1) Authentisierung über PIN (Wissen) gegenüber SIM-Karte (2) und Besitz der SIM-Karte (enthält geheimen Schlüssel K SIM ) SIM-Karte authentisiert sich gegenüber dem Netz mit K SIM 4
Authentisierung durch Passwörter! Vereinbartes Geheimnis zwischen dem Benutzer und dem System! Meist speichert das System nur einen kryptographischen Hashwert des Passwortes! Zum Beispiel in Unix: /etc/passwd! Ablauf der Authentisierung durch Passwörter:! Angabe der Identität (Benutzerkennung, Login)! System: Geben Sie Ihr Passwort ein!! Benutzer: Eingabe des Passwortes! Überprüfung durch das System:! Berechne den kryptographischen Hashwert des Passwortes! Vergleiche das Ergebnis dieser Berechnung mit dem Eintrag in der Passwort-Datei für die Benutzerkennung 5 Angriffe auf Passwort-Systeme (1)! Angriffe auf die Passwort-Eingabe:! Über die Schulter schauen! Mitschneiden ( Sniffen ) von Passwörtern in einem LAN bei unverschlüsselter Kommunikation); Keylogger im Tastaturkabel! Nicht vertrauenswürdige Rechner: Keylogger im System! Zum Beispiel in einem öffentlichen Terminalraum! Passwort auf Post-it-Zettel! Social Engineering-Angriffe! Beispiel: Telefonanruf an einen Administrator: Hallo, hier ist die Sekretärin der Geschäftsführung. Mein Chef braucht dringend das Administrator-Passwort für die Anwendung XYZ! 6
Angriffe auf Passwort-Systeme (2)! Angriffe auf den Passwort-Speicher! Besonders leicht bei unverschlüsselten Passwörtern: Nie Passwörter im Klartext speichern (besser kryptographische Hashwerte)!! Nutzen von Logging-Informationen: Ein nicht-existenter Login- Name wie z.b. gzu%8yp in einer Log-Datei ist lohnendes Ziel! Password-Cracking (folgende Folie) 7 Password-Cracking! Password-Cracker:! Enthalten Wörterbücher (Dictionaries): u.u. in verschiedenen Sprachen! Unterstützen Heuristiken, um Kombinationen aus Sonderzeichen und Wörtern durchzuprobieren: Das Passwort Cars%ten kann leicht ermittelt werden! Brute-Force-Angriff (vor allem bei zu kurzen Passwörtern erfolgreich)! Üblicherweise können mit einem Password-Cracker ungefähr 21-25% der Passwörter eines Systems ermittelt werden (Studie).! Gängige Password-Cracker:! Crack, L0phtCrack! Cain & Abel, http://www.oxid.it/cain.html, für Windows-Systeme! John the Ripper (JtR), www.openwall.com/john, für Unix und Windows 8
Wahl guter Passwörter! Richtlinien für die Wahl guter Passwörter 1. Nicht weniger als acht Zeichen 2. Kein Name oder Wort, das in einem Wörterbuch nachschlagbar ist 3. Mindestens ein Sonderzeichen 4. Keine Folge von Zeichen, die auf einer Tastatur nebeneinander liegen... und Passwörter sollten in regelmäßigen Abständen geändert werden! 9 Sicherheit von Unix-Passwörtern! Design-Fehler im ursprünglichen Unix:! Passwort-Datei /etc/passwd ist zwar verschlüsselt, aber world-readable!! Gefahr eines Wörterbuchangriffs durch einen Password-Cracker (offline!)! Lösung des Problemes: shadow-passwort Datei; /etc/passwd enthält dann Dummy-Einträge! Sicherheit von Unix-Passwörtern! Unix-Passwörter können maximal acht Zeichen lang sein,! 95 druckbare Zeichen möglich Es gibt somit 95 8! 2 52.6 Möglichkeiten zur Passwortwahl. Eine gut ausgestattete Organisation (z.b. NSA) kann also jedes Unix- Passwort knacken. 10
Zusammenfassung: Authentisierung durch Passwörter! Passwort-Authentisierung angreifbar! Dictionary-Angriffe! Sniffing! Social Engineering! Angriffe auf die Passwort-Speicherung! Lösungen: u.a.! Einmal-Passwort-Verfahren, OTP (One-time Passwort) z.b. S/Key (Hash-Kette) oder RSA SecureID ( Key Fob )! Authentisierung zwischen Systemen: Ticket-basiert mit Nachweis, dass man der Eigentümer des Tickets ist (z.b. Kerberos)! Vielen dieser Lösungen ist gemeinsam: Sie basieren auf einem Challenge-Response Verfahren (später). 11 Hardware-basierte OTP- Verfahren: ID-Token! OTP-Verfahren zur Authentisierung beim Server Beispiel: Online-Banking! Benutzer erhält ein Hardware-Token! Token besitzt eindeutige Nummer; Server kennt diese! Token berechnet periodisch eine neue Zahl (Code), z.b. alle 60 Sekunden, Code ist das OTP! Tokencode hängt von einem Seed ab, der Zeit, der Seriennummer des Tokens und ggf einer PIN! Benutzer: Eingabe des OTP an einem Terminal dazu: ablesen des Passwortes vom Display des Tokens! Server muss Seed, Zeit, Seriennummer, PIN kennen, generiert ebenfalls das Passwort und vergleicht beide 12
Beispiel: RSA SecureID Token! Basis für 2-Faktor-Authentisierung (Wissen und Besitz)! Zeit-synchronisiertes Vorgehen! Synchronisation von Server (RSA ACE/Server) und Token! Admin des Servers richtet Benutzer-Account ein, mit:! Token-Nummer und 64-Bit Seed s! Seed s wird auch auf Token gespeichert! Token wird an Benutzer ausgegeben! Erzeugen von OTPs:! alle 60 Sekunden generieren Token u. Server neues Passwort: AES-Hashwert: Tokencode = AES(TokenId s Zeit) 13 Beispiel: S/Key! Einmal-Passwörter über Hash-Ketten generieren! Benutzer und System vereinbaren Passwort s! Hash-Funktion f wird i-mal wiederholt: f i! Benutzer erhält s und einen PDA mit f! Alternativ: Benutzer erhält für n Einlogvorgänge f i (s) für 0 < i < n! System fordert mit n heraus (und merkt sich i=n)! Benutzer antwortet mit f i (s)! Beim nächsten mal fordert System mit i:=i!" heraus! Benutzer antwortet mit f i-1 (s) (nicht aus f i (s) ableitbar!) 14
Probleme von S/Key! Wie alle Passwort-Mechanismen anfällig gegen middleperson-angriff! Untergeschobener Server kann Passwort für j abfragen mit j < i; daraus kann f i (s) berechnet werden! Lösung: Server-Authentisierung 15 Authentisierung durch Biometrie (1)! Gilead besetzte die nach Efraim führenden Übergänge über den Jordan. Und wenn efraimitische Flüchtlinge (kamen und) sagten: Ich möchte hinüber!, fragten ihn die Männer aus Gilead: Bist du ein Efraimiter? Wenn er Nein sagte, forderten sie ihn auf: Sag doch einmal «Schibbolet». Sagte er dann «Sibbolet», weil er es nicht richtig aussprechen konnte, ergriffen sie ihn und machten ihn dort an den Furten des Jordan nieder. So fielen damals zweiundvierzigtausend Mann aus Efraim., Richter 12:5-6! Erster dokumentierter militärischer Einsatz eines Protokolls zur Authentisierung basierend auf einem biometrischen Merkmal:! Hier: der Akzent! Was ich bin ( something you are ) 16
Authentisierung durch Biometrie (2)! Biometrisches Merkmal: Verhaltenstypische oder physiologische Eigenschaft eines Menschen, die diesen eindeutig charakterisieren! Anforderungen an biometrische Merkmale:! Universalität: Jede Person besitzt das Merkmal.! Eindeutigkeit: Merkmal ist für jede Person verschieden! Beständigkeit: Merkmal ist unveränderlich! quantitative Erfassbarkeit mittels Sensoren! Performance: Genauigkeit und -geschwindigkeit! Akzeptanz des Merkmals beim Benutzer! Fälschungssicherheit 17 Biometrische Verfahren: Beispiele! Fingerabdruckerkennung:! weit verbreitetes Verfahren für viele Anwendungen: preiswerte, kompakte Sensoren sind verfügbar (auf Mobiltelefon, PDA, Laptop,...)! Schreibdynamik ist besonders geeignet für Willenserklärung (z.b. Signaturen): Unterschreiben als bewusster, willentlicher Akt! Iris-Erkennung sehr fälschungssicher, aber aufwendige Technik und geringe Akzeptanz (vgl. Fraport-Pilot-Projekt)! Gesichtskontrolle:! gute Akzeptanz, aber z.zt. noch nicht ausgereift, vgl. http://www.bsi.bund.de/literat/studien/biop/biopabschluss.pdf; Studie zu Gesichtserkennungssystemen zum Einsatz bei Lichtbildausweisen 18
Iris-Erkennung 19 Problembereiche! Abweichungen zwischen Referenz- und Verifikationsdaten sind unvermeidlich.! Zwei Fehlertypen:! Berechtigter Benutzer wird abgewiesen " Akzeptanzproblem (false negative, FRR false rejection rate)! Unberechtigter wird authentisiert, Kontrollen zu locker " Sicherheitsproblem (false positive, FAR false acceptance rate) Leistungsmaße zur Bewertung der Güte eines Systems! Ergebnisse einer dreijährigen Studie BioTrusT: www.biotrust.de: Aktuelle Produkte besitzen noch erhebliche Fehlerraten (Stand 2002, aber durchaus noch aktuell). 20
Aktuelle Diskussion in Deutschland: Biometrie in Ausweisdokumenten! In Pässen und Personalausweisen dürfen neben dem Lichtbild und der Unterschrift weitere biometrische Merkmale von Fingern, Händen oder Gesicht des Inhabers aufgenommen werden.! Alle Merkmale und Angaben über die Person dürfen auf den Ausweispapieren verschlüsselt gespeichert werden.! Es darf keine bundesweite Datei eingerichtet werden.! Die biometrischen Merkmale dürfen nur dazu verwendet werden, die werden, die Echtheit des Dokumentes und die Identität des Inhabers zu prüfen. Weitere Informationen zum aktuellen Stand der Diskussion: http://www.bsi.de/fachthem/epass 21 Challenge-Response-Protokolle (1)! Einfaches Protokoll: Passwort A! B : K AB Problem: u.a. Mitschneiden der Passwörter! Verbesserung: Challenge-Response-Protokoll Ziel: B authentisiert sich gegenüber A 1. A! B : N A schickt B eine Herausforderung (challenge) N (nonce) 2. B! A : {N} KAB B beantwortet die Challenge mit {N} KAB (response) 22
Challenge-Response-Protokolle (2)! Mutual Challenge-Response: 1. A! B : N A 2. B! A : {N A, N B } KAB 3. A! B : N B Bemerkung: Dieses einfache Protokoll ist angreifbar (Übung).! Anwendung von Challenge-Response-Protokollen:! GSM/GPRS/UMTS! PPP (Authentisierungsprotokoll CHAP)! Kerberos 23 Zugangssicherheit in Netzen Network access security
Overview! Network Access Security: Traditions! WLAN Security! WLAN Roaming (not today) 25 Overview! Network Access Security: Traditions! WLAN Security! WLAN Roaming 26
Bad, bad world out there The old Modem User DB The Host world 27 Access Servers The network Basisprotokoll: PPP Authentisierungsprotokolle: PAP (Passwörter) CHAP (Challenge/Response) EAP (Plugin-fähig) 28
Access network Routers Access Servers Campus network world Intranet X 29 Routers Centralize AAA info Access network Campus network world Intranet X RADIUS Server(s) 30
Elements of traditional Network Access Security! Handle Network Access Security at L2! PPP and attendant authentication protocols (PAP, CHAP, EAP)! Mainly user/password based! RADIUS as backend protocol! Access devices (PEPs) stay dumb! RADIUS server is PDP! NAIs and RADIUS proxying! Network Access Identifier: cabo@tzi.de! Use part after @ to identify home RADIUS server 31 802.1X: Network Access Security for Ethernet! Before 802.1X: Everyone can attach to a switch and get network access! 802.1X: Run EAP over the LAN! Supplicant: Client trying to obtain access! Authenticator (PEP): Switch! Authentication Server (PDP): RADIUS server! Switch can make decisions such as VLAN assignment based on information returned from RADIUS server 32
What is being protected?! Scarce Network Resources! Dialin pool etc.! Network Security! Often, Network Access Security was the only Network Security!! No longer an option in Internet times! Privileged IP addresses! Access behind firewall 33 Overview! Network Access Security: Traditions! WLAN Security! WLAN Roaming 34
WLANs are different! WLANs are radio-based! Everyone can hear everything! Requirement for confidentiality! No line any more! Rogue devices can insert/modify information! Less requirement for protection of access resources! WLAN is fast! ISM band radio cannot be protected anyway 35 WLAN Security: Requirements! Confidentiality (Privacy):! Nobody can understand foreign traffic! Insider attacks as likely as outsiders'! Accountability:! We can find out who did something! Prerequisite: Authentication 36
WLAN Security: Approaches! AP-based Security: AP is network boundary! WEP (broken), WEP fixes! 802.1X (EAP variants + RADIUS) + 802.11i ( WPA Enterprise )! Network based Security: deep security! VPNs needed by mobile people anyway! SSH, PPTP, IPsec! Alternative: Web-diverter (temporary MAC/IP address filtering)! No confidentiality at all, though 37 Routers.1X Access network Campus network world Intranet X RADIUS Server(s) 38
WLAN Access Control: Why 802.1X is better! 802.1X is taking over the world anyway! The EAP/XYZ people are finally getting it right! Only 5 more revisions before XYZ wins wide vendor support! Available for more and more systems (Windows 2000 up)! Distribute hard crypto work to zillions of access points! Block them as early as possible! More control to visited site admin, too!! Most of all: It just works 39 VPN-Gateways VPN Docking network Campus network world Intranet X DHCP, DNS, free Web 40
WLAN Access Control: Why VPN is better! Historically, more reason to trust L3 security than L2! IPsec has lots of security analysis behind it! Can use cheap/dumb/untrustworthy APs! Available for just about everything (Windows 98, PDA etc.)! Easy to accommodate multiple security contexts! Even with pre-2003 infrastructure! Data is secure in the air and up to VPN gateway! Most of all: It just works 41 Docking network Access Control Device Campus network Web world DHCP, DNS, free Web Web redirect Intranet X 42
WLAN Access Control: Why Web-based filtering is better! No client software needed (everybody has a browser)! Ties right into existing user/password schemes! Can be made to work easily for guest users! It s what the hotspots use, so guest users will know it already! May be able to tie in with hotspot federations! Privacy isn t that important anyway (use TLS and SSH)! Accountability isn t that important anyway! Most of all: It just works 43 Zurück zur Theorie: Wie funktionieren Sicherheitsprotokolle?
Das Needham-Schroeder- Protokoll! Roger Needham, Michael Schroeder (1978)! Schlüsselaustausch-Protokoll: Kommunikationspartner A und B vereinbaren mit Hilfe des Protokolls einen gemeinsamen Schlüssel K AB, ohne ein Public-Key-Verfahren zu verwenden.! Vertrauenswürdige dritte Instanz S (trusted third party), Authentisierungsserver! Voraussetzung:! A und B besitzen mit S jeweils einen gemeinsamen Schlüssel: K AS und K BS 45 Die Schritte des Needham- Schroeder-Protokolls (1) 1. A! S : A, B, N A! A fragt S nach einem gemeinsamen geheimen Schlüssel K AB für die Kommunikation mit B. 2. S! A : {N A, B, K AB, {K AB,A} KBS } KAS! S antwortet mit dem geheimen Schlüssel K AB, der mittels K AS verschlüsselt ist! das Nonce N A verhindert einen Replay-Angriff! Nachricht enthält ferner ein Zertifikat für B mit dem gemeinsamen geheimen Schlüssel K AB 46
Die Schritte des Needham- Schroeder-Protokolls (2) 3. A! B :, {K AB,A} KBS! A sendet das von S ausgestellte Zertifikat an B, d.h. B kennt nun den gemeinsamen Schlüssel K AB 4. B! A : {N B } KAB 5. A! B : {N B -1} KAB! Die Schritte 4. und 5. stellen eine Art Challenge-Response dar: B überprüft, dass A wirklich mit B kommunizieren will. 47 Sicherheitsproblem des Needham-Schroeder Protokolls! Subtiles Sicherheitsproblem: B nimmt an, dass der Schlüssel K AB aktuell von S stammt (vgl. Nachricht 3): 3. S! A : {N A, B, K AB, {K AB,A} KBS } KAS! Wiedereinspielungen mit geknacktem K AB sind möglich.! Bei Kompromittierung von K AS kann sich der Angreifer sogar auf Vorrat Schlüssel K AX für verschiedene Kommunikationsteilnehmer X besorgen (nicht nur für B). Selbst wenn A erkennt, dass K AS gebrochen ist, werden dadurch die Schlüssel K AX nicht automatisch ungültig.! Lösung: Nachrichten mit Zeitstempel versehen. 48
Design-Prinzipien für Sicherheitsprotokolle (1)! M. Abadi, R. Needham: Prudent Engineering Practice for Cryptographic Protocols, IEEE Transactions on Software Engineering, Vol.23, No.3, März 1997! Regel 1: Vollständige Information: Alle relevanten Informationen (z.b. Namen der Partner) sollten in einer Protokollnachricht kodiert werden. 49 Design-Prinzipien für Sicherheitsprotokolle (2)! Regel 2: Verschlüsselungszweck klären:! Gewährleisten der Vertraulichkeit,! Nachweis der Authentizität des Absenders! Verknüpfung unterschiedlicher Nachrichten-Bestandteile Bemerkung: unterschiedliche Schlüssel für unterschiedliche Zwecke verwenden, z.b. Signieren, Verschlüsseln! Regel 3: Vorsicht bei Doppelverschlüsselung Redundanz verursacht unnötige Kosten, ggf. sogar Lücken 50
Design-Prinzipien für Sicherheitsprotokolle (3)! Regel 4: Digitale Signaturen: Erst Signieren (nach dem Hashen), dann Verschlüsseln! Regel 5: frischer Schlüssel Frischenachweis über Zeitstempel oder Nonces (vgl. Problem bei Needham-Schroeder Protokoll) 51 Kerberos (1)! Weit verbreitete Weiterentwicklung des Needham-Schroeder Protokolls! Name: gr. Mythologie: 3-köpfiger Hund, der den Eingang zum Hades bewacht.! 1983 im Athena Projekt am MIT entwickelt (+ IBM, DEC)! Version 4 (nur TCP/IP, einige Sicherheits-Probleme)! Version 5 (RFC 1510, September 1993)! Ziele von Kerberos:! Authentisierung von Subjekten (Principals): u.a. Benutzer, PC/Laptop, Server! Austausch von Sitzungs-Schlüsseln für Principals! Single-Sign-on für Dienste in einer administrativen Domäne! Beispiele für Dienste: Drucker, NFS, DB 52
Kerberos (2)! Im Gegensatz zum Needham-Schroeder-Protokoll zwei Server:! Authentisierungsserver (AS)! Ticket-Granting Server (S)! AS und S werden oft zusammen KDC genannt (Key Distribution Center)! Idee: Trennung von Authentisierung (zentral beim KDC) und Überprüfung (dezentral bei den einzelnen Dienst-Servern)! Vorgehen:! Client C besitzt Passwort für Authentisierungsserver AS! C fordert einen Schlüssel K CS für den Ticket-Granting Server S von AS an! K CS ist verschlüsselt mit dem Passwort von C (Kerberos v4)! v5: Wörterbuchangriffe durch verschlüsselte Anfragen verhindern! Client führt korrigierte Variante von Needham-Schroeder mit Hilfe von S und dem Dienst -Server B durch 53 Kerberos-Architektur Key Distribution Center KDC Benutzer Alice Client C 1. 2. 3. Schlüsseldatenbank AS 5. 6. 4. Ticket-Granting-Server S DB Drucken... NFS Server Server Server 54
Kerberos: Protokollschritte! Schritte 1. und 2.: Aushandlung des gemeinsamen Schlüssel K CS für den Client C und den Ticket-Granting-Server S! Hier nur das abgewandelte Needham-Schroeder-Protokoll: 3. C! S : C, B 4. S! C : {T S, L, K CB, B, {T S, L, K CB,C} K BS } KCS (T Zeitstempel, L Gültigkeitsdauer) 5. C! B :, {T S, L, K CB,C} KBS, {C,T C } KCB 6. B! C : {T S +1} KCB! {T S, L, K CB,C} KBS ist das Ticket für den Zugriff auf den Server! {C,T C } KCB der Authentikator 55 Nächste Termine Mo, 13.06.2005 10 12 Uhr: Demo: Passwort-Cracker; Schwächen in Sicherheitsprotokollen (z.b. Denning-Sacco-Protokoll) Do, 17.06.2005 08 10 Uhr: Sicherheitsprotokolle: EAP, IKE (IPsec) Übungsblatt 8 bald auf Stud.IP, s.: https://elearning.uni-bremen.de 56