IT-Sicherheit: Authentisierung, Sicherheitsprotokolle Authentisierung

IT-Sicherheit:
Authentisierung,
Sicherheitsprotokolle
Authentisierung
!
Ziel
!
!
!
Problem:
!
!
!
!
eindeutige Identifikation und Nachweis der Identität
Abwehr von Spoofing-Angriffen
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 KSIM)
SIM-Karte authentisiert sich gegenüber dem Netz mit KSIM
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 LoginName 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.
2.
3.
4.
Nicht weniger als acht Zeichen
Kein Name oder Wort, das in einem Wörterbuch nachschlagbar ist
Mindestens ein Sonderzeichen
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 958 ! 252.6 Möglichkeiten zur Passwortwahl.
Eine gut ausgestattete Organisation (z.B. NSA) kann also jedes UnixPasswort 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 OTPVerfahren: 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: fi
! Benutzer erhält s und einen PDA mit f
! Alternativ: Benutzer erhält für n Einlogvorgänge fi(s) für 0 < i < n
! System fordert mit n heraus (und merkt sich i=n)
! Benutzer antwortet mit fi(s)
! Beim nächsten mal fordert System mit i:=i!" heraus
! Benutzer antwortet mit fi-1(s) (nicht aus fi(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 fi(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 : KAB
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}K
AB
B beantwortet die Challenge mit {N}K
AB
(response)
22
Challenge-Response-Protokolle (2)
!
Mutual Challenge-Response:
1. A ! B : NA
2. B ! A : {NA, NB}K
AB
3. A ! B : NB
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
Modem
User DB
The old
world
The
Host
27
Access
Servers
The
network
• Basisprotokoll: PPP
• Authentisierungsprotokolle:
• PAP (Passwörter)
• CHAP (Challenge/Response)
• EAP (Plugin-fähig)
28
Routers
Access
Servers
world
Access
network
Campus
network
Intranet X
29
Routers
Centralize
AAA info
world
Access
network
Campus
network
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
world
Access
network
Campus
network
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
world
Docking
network
Campus
network
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
Access
Control
Device
Docking
network
W
r
eb
Web
world
Campus
network
e
e
d ir
ct
Intranet X
DHCP, DNS, free Web
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-SchroederProtokoll
! Roger Needham, Michael Schroeder (1978)
! Schlüsselaustausch-Protokoll:
Kommunikationspartner A und B vereinbaren mit Hilfe des
Protokolls einen gemeinsamen Schlüssel KAB, 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: KAS
und KBS
45
Die Schritte des NeedhamSchroeder-Protokolls (1)
1. A ! S : A, B, NA
! A fragt S nach einem gemeinsamen geheimen Schlüssel KAB für
die Kommunikation mit B.
2. S ! A : {NA, B, KAB, {KAB,A}K
}
BS KAS
! S antwortet mit dem geheimen Schlüssel KAB, der mittels KAS
verschlüsselt ist
! das Nonce NA verhindert einen Replay-Angriff
! Nachricht enthält ferner ein „Zertifikat“ für B mit dem
gemeinsamen geheimen Schlüssel KAB
46
Die Schritte des NeedhamSchroeder-Protokolls (2)
3. A ! B :, {KAB,A}K
BS
! A sendet das von S ausgestellte „Zertifikat“ an B, d.h. B kennt nun
den gemeinsamen Schlüssel KAB
4. B ! A : {NB}K
AB
5. A ! B : {NB-1} K
AB
! 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 KAB aktuell von S stammt
(vgl. Nachricht 3):
3. S ! A : {NA, B, KAB, {KAB,A}K }K
BS
AS
! Wiedereinspielungen mit geknacktem KAB sind möglich.
! Bei Kompromittierung von KAS kann sich der Angreifer sogar auf
Vorrat Schlüssel KAX für verschiedene Kommunikationsteilnehmer
X besorgen (nicht nur für B).
Selbst wenn A erkennt, dass KAS gebrochen ist, werden dadurch
die Schlüssel KAX 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 KCS für den Ticket-Granting Server S von AS an
! KCS 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
Client
2.
Benutzer
Alice
AS
1.
C
Schlüsseldatenbank
3.
4.
5.
S
6.
Ticket-Granting-Server
DB
Drucken
Server
Server
...
NFS
Server
54
Kerberos: Protokollschritte
!
!
Schritte 1. und 2.: Aushandlung des gemeinsamen Schlüssel KCS 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 : {TS, L, KCB, B, {TS, L, KCB,C}K }K
(T Zeitstempel, L
BS
CS
Gültigkeitsdauer)
5. C ! B :, {TS, L, KCB,C}K
BS
6. B ! C : {TS+1}K
!
!
, {C,TC}K
CB
CB
{TS, L, KCB,C}K ist das Ticket für den Zugriff auf den Server
BS
{C,TC}K
der Authentikator
CB
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