Kapitel 5 Digitale Identität, Authentisierung PDF

Technische Universität München Kapitel 5 Digitale Identität, Authentisierung 5.1. Einordnung/Begriffsklärung Schutzziel: Authentizität: Echtheit und Glaubwürdigkeit einer Identität. Authentisierung/Authentifikation Prüfung der Authentizität; Basis: eindeutige Identität. Identität:...

Technische Universität München Kapitel 5 Digitale Identität, Authentisierung 5.1. Einordnung/Begriffsklärung Schutzziel: Authentizität: Echtheit und Glaubwürdigkeit einer Identität. Authentisierung/Authentifikation Prüfung der Authentizität; Basis: eindeutige Identität. Identität: Name, Identifier, charakterisierende Attribute: Beispiele? Beispiel: Identität und Glaubwürdigkeit: TUM-Kennung und Passwort Authentisierung: Nachweis und Prüfung der Kenntnis des Passworts. IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 1  Technische Universität München Autorisierung: Vergabe von Zugriffsberechtigungen, z.B. Lese-Recht, an Entitäten (Person, Maschine/Gerät, Service, …) Bem.: eine korrekte Authentisierung der Entität ist idR die Basis für die Wahrnehmung der Autorisierungen. Personenbeziehbare Daten nach Datenschutzgrundverordnung (DSGVO) (seit 2018 in Kraft, hat BDSG abgelöst) Personenbezogene Daten sind gemäß Art. 4 Nr. 1 DSGVO „alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen.“ IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 2  Technische Universität München Pseudonymisierung: Art. 4 Nr. 5 DSGVO „die Verarbeitung personenbezogener Daten in einer Weise, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher DSGVO, -- Art. 4 Nr. 5 DSGVO Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen, die gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten oder identifizierbaren natürlichen Person zugewiesen werden“ Beispiele: Nickname bei Mail, Matrikelnummer, gehashte IDs TMSI beim Mobilfunk, Pseudonym rID beim Personalausweis Frage: Sind dynamische IP Adressen Pseudonyme (j,n)? IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 3  Technische Universität München Anonymisierung „das Verändern personenbezogener Daten derart, dass die Einzelangaben über persönliche oder sachliche Verhältnisse nicht mehr oder nur mit einem unverhältnismäßig großen Aufwand an Zeit, Kosten und Arbeitskraft einer bestimmten oder bestimmbaren natürlichen Person zugeordnet werden können.“ Anonymisierung gilt als Verarbeitung von personenbezogenen Daten und unterliegt der DSGVO. Anonymisierte, anonyme Daten besitzen keinen Personenbezug und unterliegen der DSGVO nicht. Beispiel: Ersetzen von Namen durch Zufallszahlen IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 4  Technische Universität München 5.2. Drei Klassen von Faktoren zur Authentisierung Authentisierung durch 1. Wissen: z.B. Passwort, PIN, Schlüssel 2. Besitz: z.B. Smartcard, Token, SIM Karte 3. Biometrie: z.B. Fingerabdruck, Gesicht, Tippverhalten Multi-Faktor Authentisierung: Kombination verschiedener Authentisierungsfaktoren Ziel: Hürde für Angreifer erhöhen Frage: Kennen Sie Beispiele für Multi-Faktor Authentisierung? IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 5  Technische Universität München Multi-Faktor Authentisierung: Beispiel: Zwei-Faktor Authentisierung beim Online-Banking Seit 14.9.2019: gesetzliche Vorgabe für Banken, PSD2 für Online-Zugriff auf Informationen zum Konto für Freigaben von Internet-Kartenzahlungen 2-Faktor-Authentisierung 1. Kennung und Passwort/PIN 2. Eingabe einer dynamisch generierten Einmal-TAN TAN-Generator: z.B. Separates Gerät, Handy App IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 6  Technische Universität München 5.3 Authentifikation durch Wissen Wissen: Passwörter, Passphrasen, Shared Secret 5.3.1 Passwort-basierte Authentisierung Frage: Die häufigsten Passwörter in Deutschland 2023 (https://hpi.de/artikel/123456789-ist-das-beliebteste-passwort-2023-in-deutschland/ Patz 1 ist 123456789, was glauben Sie ist Platz 2? und 3? Problem: Passwortdiebstahl, z.B. RockYou2021 > 8,4 Milliarden Passworte Angriffe: Dictionary Angriff: Durchprobieren. Social Engineering: Nutzer gibt Passwort preis. z.B: via Phishing: Login auf fake-Webseite Abwehr: gute Passwörter und Mehrfaktor-Authentisierung IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 7  Technische Universität München Was ist ein gutes Passwort? Passwortrichtlinien: NIST: 2017 vgl. https://pages.nist.gov/800-63-3/sp800-63b.html deutliche Abkehr von früher geforderten Richtlinien, Lehren aus Nutzerstudien, die gezeigt haben, dass komplexe Richtlinien Benutzer zu unsicheren Praktiken verleiten, um einfache Passworte zu finden, die den Richtlinien genügen. Neu: explizites Abraten vom Erzwingen von mehreren Zeichenklassen (groß, klein, Zahlen und Sonderzeichen) Neu: explizites Abraten von der Vorschrift, regelmäßig das Passwort zu ändern, Änderung aber bei Verdacht von Leaks BSI: erst 2/2020 Empfehlungen aktualisiert: keine Empfehlung für proaktives, regelmäßiges Passwortwechseln mehr. IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 8  Technische Universität München NIST Passwort Guidelines: u.a. User-generated passwords should be at least 8 characters in length All ASCII/Unicode characters should be allowed, incl. emojis and spaces Stored passwords should be hashed and salted, and never truncated Passwords should be compared against pwd breach databases Passwords should not expire Users should be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters Question-based authentication should not be used, „What is the name..“ Users should be allowed 10 failed password attempts before being locked out of a system or service. Complexity requirements should not be used, ex. requiring special characters, numbers, uppercase, etc. Context-specific words, such as the name of the service, the user’s username, etc. should not be permitted IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 9  Technische Universität München 5.3.2 Einmal-Passworte (One-time Password OTP) CR: Challenge-Response (Frage/Antwort) Protokoll Software-basierte OTPs: HMAC-based OTP (HOTP), RFC 4226 Time-based OTP (TOTP), RFC 6238 IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 10  Technische Universität München Beispiel: Google Authenticator Software-basiert: App für Android und iOS Zeitsynchronisierte OTP (TOTP) plus Hash-basiert Basis: Nutzer besitzt Kennung beim Server, Authenticator App ist auf Nutzer-Gerät installiert. Server generiert 80 bit Pre-Shared-Secret s Übertragung auf Nutzer-Gerät : z.B. via SMS, Voice, QR Code App speichert s in SQL Datenbank. App und Server generieren unabhängig voneinander alle 30 Sekunden ein neues 6-stelliges One-Time Password OTP OTP = HMAC_SHA1(s, Unixzeit_counter). Bem.: Unixzeit_counter ist Anzahl Sekunden seit dem 1.1.1970 IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 11  Technische Universität München Verschiedene OTP für verschiedene Accounts Nutzer: Login mit Kennung und Passwort und zusätzlich Eingabe des aktuell angezeigten OTP = HMAC_SHA1(s, Unixzeit_counter) Server: validiert mit Server-OTP Server-OTP = HMAC_SHA1(s, Unixzeit_counter) Prüfung: Nutzereingabe-OTP = Server-OTP? Schwachpunkte: u.a. 80 bit secret s: zu kurz (RFC 4226 fordert mind.128 Bit), s in Klartext auf Smartphone in App gespeichert, Server wird nicht authentisiert. IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 12  Technische Universität München 5.4 Authentifikation durch physischen Besitz Hardware-Token als Identitätsnachweis: z.B. digitaler Personalausweis (mit Chip), EC-Karte, USB-Dongle Hardware-basierte OTPs sind Token. Ein Token besitzt eindeutige Nummer, die der Server kennt. Beispiel: RSA SecureID-Token Basis: Auf Server: Benutzer-Account mit: Token-Nummer und pre-shared 128-Bit Seed s Seed s wird auch im RSA-Token gespeichert. Tokenlebenszeit: 1-5 Jahre, automatisches Abschalten nach Ablauf. IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 13  Technische Universität München Erzeugen von OTPs: auf Server und in Token alle 60 sec, OTP = AES(TokenId | s | Zeit), 6-8 stellige Zahl Login mit RSA-Token: OTP wird auf Token-Display angezeigt. Nutzer gibt den Code ein. Validierung eines OTP durch Server: Es werden die nächsten 3-5 OTPs zugelassen. 8 sec Abweichung bei Zeitsynchronisation wird toleriert Frage Welche Aussagen stimmen? (1) Phishing ist nicht mehr erfolgreich möglich. (2) OTP schützt vor Fake-Server. IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 14  Technische Universität München 5.5 Authentifikation durch Biometrie Biometrisches Merkmal: Bios = Leben, metron = Maß Verhaltenstypische oder physiologische Eigenschaft eines Menschen, die diesen eindeutig charakterisieren 5.5.1 Anforderungen an biometrische Merkmale: z.B. Fingerabdruck 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 IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 15  Technische Universität München Unterschiede zur wissensbasierten Authentisierung: Merkmal ist personengebunden Frage: Welche mögliche Konsequenzen sehen Sie? Charakteristische Merkmale müssen extrahiert und mit Referenzwert verglichen werden Frage: Welche möglichen Probleme sehen Sie? Klassen biometrischer Merkmale physiologische Merkmale (statisch): nur geringe Möglich- keiten zur Auswahl oder Änderung von Referenzdaten Beispiele: Fingerabdruck, Retina, Iris, Gesicht Verhaltensmerkmale (dynamisch):Merkmal ist nur bei bestimmter Aktion vorhanden. Beispiele: Stimme, Tippverhalten IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 16  Technische Universität München 5.5.2 Vorgehen bei biometrischer Authentisierung Schritte 1-2: Vorbereitung: einmalig 1. Messdatenerfassung durch biometrischen Sensor und Digitalisierung (Feature-Extraction) 2. Enrollment: Registrierung eines Benutzers: Aufnahme, Auswahl und Speicherung der Referenzdaten, z.B. 5 bis 7 Fingerabdrücke Schritte 3-5: bei jeder Authentisierung: 3. Erfassung der aktuellen Verifikationsdaten (mit Sensoren) 4. Verifikationsdaten digitalisieren (u.a. ggf. normieren) 5. mit gespeichertem Referenzwert (Template) vergleichen, Toleranzschwellen sind notwendig Frage: Wo/Wie sollten Referenzwerte gespeichert werden? Was sind mögliche Kriterien für Toleranzschwellen ? IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 17  Technische Universität München Problembereiche Abweichungen zwischen Referenz- und Verifikationsdaten Zwei Fehlertypen: Berechtigter Benutzer wird abgewiesen,  Akzeptanzproblem (false negative) Unberechtigter wird authentifiziert, Kontrollen zu locker  Sicherheitsproblem (false positive, false accept) Leistungsmaße zur Bewertung der Güte eines Systems False-Acceptance-Rate (FAR): Wahrscheinlichkeit für fälschliche Akzeptanz einer unberechtigten Person. False Rejection Rate (FRR): Wahrscheinlichkeit für fälschliche Rückweisung einer berechtigten Person IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 18  Technische Universität München Equal Error Rate (EER): Gleichfehlerrate, Wahrscheinlichkeit für unerlaubte Authentisierung und Wahrscheinlichkeit für falsche Ablehnung sind gleich. Maß für die Güte eines biometrischen Systems Beispiele: Fingerabdruck FAR: 0,001% FRR: 0,1% Iris FAR: 0,0001% FRR: 0,01% IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 19  Technische Universität München Fazit: Biometrische Techniken Qualität der Sensoren: sehr unterschiedliche Angriffsresilienz: hohe Anforderungen in Hochsicherheitsbereichen, hoheitlichen Identifikationsdokumenten (PA, Pass) Bei Commodity Produkten häufig leicht zu überlistende, einfache Sensoren, vgl. iPhone Probleme: enge Kopplung zwischen Merkmal und Person Bedrohung der informationellen Selbstbestimmung Gefahren durch gewaltsame Angriffe gegen Personen Problem der öffentlichen Daten und rechtliche Aspekte Ethische Problem: Gefahr der Diskriminierung Zunehmend: Deep Fakes: Audio, Video-Deep Fakes für ID IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 20  Technische Universität München 5.6 Grundlegende Authentisierungstechnik: CR Challenge-Response (CR) Protokoll zur Authentizitätsprüfung mit Authentisierungsfaktor(en) Prinzip der CR-Authentisierung: Instanz A gegenüber Instanz B: A gibt ihre Identität an: Server B Accounts: z.B. Name, MAC-Adr. A Alice A Request: A B sendet eine Challenge an A Challenge z.B. Zufallszahl RAND Challenge Res = A erstellt Response für B f(Challenge) Res z.B. mittels Verschlüsselung. Authentifizierung erfolgreich Res korrekt? B prüft Response: falls korrekt, dann hat A ihre Identität glaubwürdig bewiesen. IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 21  Technische Universität München Frage: Welchen Aussagen stimmen Sie zu? Der klassische Passwort-Login ist ein CR-Verfahren. (1) Stimmt nicht, da es keine Challenge gibt. (2) Stimmt nicht, der Nutzer muss keine Response erstellen. (3) Stimmt. Man unterscheidet zwischen: Symmetrischen CR und Asymmetrischen CR-Verfahren IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 22  Technische Universität München 5.6.1 Symmetrisches CR-Verfahren: A authentifiziert sich gegenüber B Naiver erster Versuch: Basis: Pre-shared Key kA , assoziiert mit Identität IdA. A: Prüfende Instanz B: Pre-shared: kA, IdA Pre-shared: kA zu IdA (1) RAND (2) EkA(RAND) = c (3) RAND, c, IdA (4) DkA(c) = RAND‘ (6) ok oder failed (5) RAND‘ = RAND? Retry, if failed Frage: Wo steckt der Fehler und was kann ein Angreifer machen? IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 23  Technische Universität München Korrektes, symmetrisches CR-Protokoll Basis: Pre-shared Key kA , assoziiert mit Identität IdA. A: Prüfende Instanz B: Pre-shared: kA, IdA Pre-shared: kA , IdA Login (1) IdA (2) Generiere: (4) Erstelle (3) RAND RAND EkA(RAND) = c (5) c (6) Entschlüssle (8) ok oder failed DkA(c) = RAND‘ (9) Retry, if failed (7) Prüfe RAND‘ = RAND? Verbesserung gegenüber dem naiven Ansatz von Folie 23: RAND (= challenge) wird von prüfender Instanz B erstellt, frisch! A muss bei jedem Login explizit Kenntnis von kA nachweisen. IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 24  Technische Universität München 5.6.2 Asymmetrisches CR-Verfahren: Vorteil gegenüber symmetrischem CR: Kein pre-shared Secret erforderlich Basis: Sei für Alice (A) ein Schlüsselpaar (eA, dA) generiert, dA ist der private Signaturschlüssel und eA ist der öffentliche Validierungsschlüssel. Naiver Versuch: Alice : (eA, dA) , IdA (1) Login-request IdA Instanz B (2) Generiert (4) Signierte Response (3) RAND RAND sig = EdA (RAND) (5) sig, eA (6) Prüfen DeA(sig) = RAND‘ (7) ok oder failed RAND‘ = RAND? Frage: Auch dieses Protokoll ist angreifbar, sehen Sie wie? IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 25  Technische Universität München Korrektes asymmetrisches CR-Verfahren Basis: Sei für Alice (IdA ) ein Schlüsselpaar (eA, dA) generiert, dA ist der private Signaturschlüssel und eA ist der öffentliche Validierungsschlüssel. X509-Zertifikat(eA): bestätigt, dass eA zu IdA gehört. Alice : (eA, dA) Instanz B Zertifikat(eA), IdA (1) Login-request IdA Zertifikat(eA) (2) Prüft Zertifikat(eA) (4) Signierte Response (3) RAND Generiert RAND. sig = EdA (RAND) (5) sig (6) Prüft Signatur DeA(sig) = RAND‘ (7) ok oder failed RAND‘ = RAND? IT Sicherheit, WS 24/25, C. Eckert, Kapitel 5: Digitale Identität, Authentifizierung 26