Verschlüsselung im Alltag

Contents

Symmetrische Chiffren

Sender und Empfänger benutzen gemeinsames Geheimnis

Typischerweise sehr performant

Problem: Austausch des Schlüssels

Falltürfunktionen

Kryptographische Hashfunktion

Hashes: Verdichtung von Daten auf eine charakteristische (kurze) Sequenz

Besonderheit in der Kryptographie: Finden von Daten zu einem gegebenen Hashwert schwierig

Asymmetrische Chiffren

Statt einem Schlüssel für Ver- und Entschlüsselung: Schlüsselpaare (heben Wirkung gegenseitig auf)

Verschlüssel-Schlüssel (Public Key) kann öffentlich sein

Problem: Habe ich wirklich den Schlüssel des gewünschten Empfängers?

Was macht SSL?

SSL sorgt für das "Schloß im Browser"

Protokoll zur Authentisierung und Verschlüsselung von Datenverbindungen

• Handshake (verwendete Verfahren aushandeln)
• Prüfung Serverzertifikat
• Optional: Prüfung Clientzertifikat
• Wechsel auf symmetrische Chiffre

...und mehr :-)

Mit wem spreche ich bitte?

Certification Authorities

Was kann wo schiefgehen?

Die Kette der Beteiligten:

→ → → →

Was schiefgehen kann: Benutzer

Sicherheit fängt immer beim Benutzer an!

Verwenden der falschen Adresse:

• Vertippen, absichtlich ähnliche URLs
  (googel.de vs. google.de,
  y0utube.com vs. youtube.com)
• Social Engineering: z.B. Links in Phishing-Mails (z.B. so: http://www.youtube.com/watch?v=HUEvRyemKSg)

Falsches Verhalten:

• Ignorieren von Sicherheitswarnungen

Was schiefgehen kann: Eigener Rechner, Zielrechner

Eigener Rechner: Infektion mit Malware, Backdoor, ...

Zielrechner: Eindringen in das System

In beiden Fällen:

• Alle Daten lesbar (Tastendrücke, Datenbanken, etc.)
• Rechner "gehört" nun jemand anderem
• Häufig nur durch sorgfältige Reinstallation zu beseitigen

Was schiefgehen kann: Browser

Malware im System kann...

• Netzwerkverkehr abhören (ist aber verschlüsselt)
• Tastendrücke mitschneiden (herstellen des Zusammenhangs schwierig)

• Mitschneiden, Manipulieren von Anzeige und Eingabe
• Installation neuer Root-Zertifikate
• Manipulation von Bookmarks

Was schiefgehen kann: Verbindung

Verbindung: Im LAN, Internet-Cafe, Router des ISPs, Proxy der Firma, ...

Man-in-the-Middle: Abhören und/oder manipulieren

Verhindern des Wechsels auf ssl

sslstrip agiert als transparenter Proxy

Parst durchlaufende Daten

Ersetzt alle https-Links durch http

Bei vielen Websites sind alle Seiten sowohl per http als auch per https abrufbar

Folgt man nur den Links, gelangt man nun nie auf die verschlüsselte Seite

Ganz fatal bei eingebetteten Formularen

⇒ Wichtige URLs immer prüfen!

Demo: sslstrip

Man-in-the-middle erzeugt eigene Zertifikate

sslsniff, webmitm, iSniff, ...: Ebenfalls transparente Proxy

Besitzen/erstellen eigene CA

Beschreibungstext in CA beim Erstellen: Beliebig!

Beim Verbindungsaufbau: Neues Zertifikat für Seite generieren

Browserwarnung (wenn CA unbekannt)

⇒ Bei Browserwarnung: Höchste Alarmstufe, nicht einfach wegklicken!

Trusted CAs in den Händen der falschen

Man in the middle + im Browser hinterlegte CA:

Trusted CAs in den Händen der falschen

Eines der Probleme: Jede CA (root und intermediary) darf beliebige Zertifikate ausstellen

Mögliche Auswege und Workarounds

Bei wichtigen Seiten: Fingerprint des Zertifikats von Hand prüfen

• Unbequem und aufwendig
• Woher die korrekte Information nehmen?

Convergence - Alternative zur CA-Hierarchie

Idee: Ein Man in the Middle kann nicht alle Verbindungen zu einem Ziel angreifen

Im Netz verteilte Notare fragen das Zertifikat eines Ziels ab und liefern es dem Browser

Browser prüft Übereinstimmung aller Notarantworten

Benutzer wählt Notare selbst

• Problem: Auswahl der Notare, initiales Vertrauen (Schlüsselaustausch)
• Je dichter der Angreifer an seinem Opfer, desto größer die Chance, die Notare täuschen zu können

Pretty Good Privacy (PGP)

E-Mails: Die Postkarten des Internets:
Keine Ende-zu-Ende-Verschlüsselung

Pretty Good Privacy: Projekt von Phil Zimmermann, 1991 begonnen

Funktionierte so gut, daß er in die Mühlen der US-Dienste geriet :-)

Gründung der Firma pgp.com, Verkauf an Symantec

Freie Implementierung: Gnu Privacy Guard

PGP-Schlüssel

Public-Key-Verfahren: Public Key und Secret Key

pub   1024D/0x75FD7074 2004-12-31 [expires: 2013-01-01]
uid [ultimate] Stefan Schlott (PGP mail only) <stefan.pgp@ploing.de>
uid [ultimate] Stefan Schlott <stefan.schlott@ulm.ccc.de>
sub   3072g/0xE9D795D0 2004-12-31 [expires: 2013-01-01]

• Schlüssel-ID (0x...)
• Hauptkey (Signieren von Inhalten und Schlüsseln), Subkey (Verschlüsselung)
• Ablaufdatum
• Identities (uid): Name, ggf. Kommentar, Mailadresse
• Trust-Info nicht Teil des Schlüssels (lokal gespeichert)

Schlüssel erzeugen

Verschiedene Verfahren: RSA, DSA/ElGamal

• Heute kein großer Unterschied mehr (Verbreitung, Patente)
• Key auf Smartcard: RSA bevorzugen

Schlüssellänge: Lieber zu groß :-)

Erzeugung braucht "gute" Zufallszahlen.
Idealerweise nicht auf einem frisch gestarteten Rechner durchführen.

Sicherung mit Passphrase (Mantra)

Desaster-Vorkehrungen

Was passiert, wen...

• Ich mein Mantra vergesse?
• Mein Secret Key (samt aller Backups) verloren geht?
• Secret Key und Mantra in die falschen Hände fallen?

Keyserver - das "Telefonbuch" für PGP

Ich will jemandem schreiben und brauche seinen Public Key... woher bekomme ich den?

• Homepage
• Per Mail fragen
• Keyserver!

Suchmöglichkeiten: Name, E-Mail, Schlüssel-ID

Mailadresse auf Keyserver sichtbar (mögliche Spam-Quelle)

Habe ich den richtigen Schlüssel?

Keine zentrale Instanz wie bei SSL, sondern Web of Trust

• Direkte Authentisierung: Persönlicher Austausch, Überprüfung, Signieren von Schlüsseln
• Indirekte Authentisierung durch Vertrauen in Zuverlässigkeit anderer

Direktes Vertrauen: Schlüssel signieren

Überprüfung des Schlüssels mit Fingerprint (auf authentischem Weg austauschen, z.B. am Telefon vorlesen oder persönliche Übergabe)

pub   1024D/0x75FD7074 2004-12-31 [expires: 2013-01-01]
      Key fingerprint = 9548 55E2 AC01 4862 BFE4  
                        670E FDF4 4AE8 75FD 7074

Festhalten dieses Wissens durch Signatur des Schlüssels

Signatur kann weitergegeben werden: Wissen für andere verfügbar

Transitives Vertrauen: Web of Trust

Festlegen des Vertrauensgrads in die Sorgfalt bei der Prüfung anderer: "Partial Trust" / "Full Trust"

Vertrauen wird nur berücksichtigt, wenn ein Schlüssel als verifiziert gilt:

• Selbst signiert
• Trägt Unterschrifte von einem verifizierten Schlüssel mit "Full Trust"
• Trägt zwei Unterschriften von verifizierten Schlüsseln mit "Partial Trust"

PGP warnt bei der Verwendung nicht verifizierter Schlüssel

Web of Trust - Beispiel

Alle direkt signierten Schlüssel gelten als verifiziert

Web of Trust - Beispiel

Armin ist verifiziert + volles Vertrauen: Dirk verifiziert

Web of Trust - Beispiel

Vertrauensinfo alleine: Bernd noch nicht zertifiziert!

Web of Trust - Beispiel

Erst durch (mindestens) teilweises Vertrauen in Claus werden Erwin und Frank verizifiert

"Pseudo-CAs"

Mit Web of Trust kann das CA-Modell nachgebildet werden (nicht aber umgekehrt)

Introducer: Vertrauenswürdige Person, die viele weitere Schlüssel signiert hat

• Gut vermaschte Schlüssel in Freundeskreis, Club, Verein: Jeder beliebige
• Heise-Kryptokampagne (seit 1997! Danke, Heise!)
• PGP-Signatur von CAcert

De-Mail - E-Mail mit Staatsverschlüsselung

Ziel: In einer Variante E-Mails mit Sicherheitsgarantie (Verschlüsselung) und Rechtsverbindlichkeit, ohne zusätzliche Hard- oder Software

Dahinterliegende Technik: Normale Mail-Komponenten

Vertragliche Garantien für Transport

• De-Mail-"Markierung" nur für Mails von und an De-Mail-Server
• Garantie verschlüsselter Verbindungen

De-Mail-Basisversion

De-Mail ist eine Art "kryptographische Rohrpost":

• Übertragungswege ("Rohrpost") geschützt
• Mail an jeder Zwischenstation unverschlüsselt

Aus Security-Sicht kein Vergleich zur Sicherheit von PGP

Off The Record Nachrichtenprotokoll

"Overlay-Protokoll" über jedem (beliebigen) Chatprotokoll

Als Bibliothek und Plugin für verschiedene Chatclients verfügbar

Verschlüsselung, Authentisierung

Deniability: Außenstehende erhalten kein Indiz über die eigene Identität

Perfect Forward Secrecy: Selbst bei Verlust der eigenen Schlüssel können alte (mitgeschnittene) Sitzungen nicht entschlüsselt werden

Aufbau der Verbindung

Bei der ersten Nutzung: Public-Key-Paar generieren

Verbindungsaufbau im Chatclient: Manuell oder durch automatische Erkennung (charakteristische Folge von Whitespace am Ende einer normalen Nachricht)

Austausch der Public Keys, Aushandeln eines Sitzungsschlüssels

Dann: Unauthentisierte Verbindung

Überprüfung seines Gegenübers

Wieder dieselbe Frage: Spreche ich mit dem richtigen?

Authentisierung über zweiten Kanal (z.B. Telefon), Austausch von Fingerprints

Information über erfolgreiche Überprüfung wird lokal gespeichert

Kein Web of Trust, etc.

Vorsichtsmaßnahmen

Beim Beenden einer Verbindung: Aufpassen, daß man nicht versehentlich unverschlüsselt weitertippt (manche Clients verhindern dies)

Vorsicht: OTR sichert nur die Übertragung über das Netzwerk! Keine Sicherung der Chatprotokolle des Clients!

Chatprotokolle werden typischerweise im Klartext gespeichert (aktuelles Negativbeispiel: Bradley Manning)

⇒ Häufig gehörte Empfehlung: Solche vertraulichen Chats nicht protokollieren (wirklich "Off the record")

Fazit

• Für jede Art von Sicherheit: Eine vertrauenswürdige (nichtkompromittierte) Umgebung ist nötig
• Ernsthafte Security ist kein Ponyhof. Regeln und Verfahren sind zwingend einzuhalten
• Selbstcheck: Was ist das eigene Sicherheitsbedürfnis?
• Si vis pacem, para bellum - eine Aversion gegen Gutgläubigkeit ist selten schädlich
• Preparedness: Sollte man in die Situation geraten, ernsthafte Sicherheit zu benötigen, ist es zu spät für Vorbereitungsmaßnahmen

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.