Folgende (Schutz)-Ziele können mit Hilfe von Kryptographie erreicht werden:
Vertraulichkeit (confidentiality) bzw. Geheimhaltung (secrecy): Daten dürfen lediglich von autorisierten Benutzern gelesen werden, dies gilt sowohl beim Zugriff auf gespeicherte Daten, wie auch während der Datenübertragung.
Integrität (integrity): Daten dürfen nicht unbemerkt verändert werden. Alle Änderungen müssen nachvollziehbar sein.
Nicht-Abstreitbarkeit / Unbestreitbarkeit (non-repudiation): Die Authentizität einer Nachricht kann validiert werden, d.h. der/die Autor:in kann nicht leugnen, dass er/sie der/die Autor:in der Nachricht ist und er/sie die Nachricht so verfasst hat.
Kryptographie erlaubt die sichere Kommunikation über einen unsicheren Kanal. Dabei kann neben der Vertraulichkeit auch die Korrektheit der Nachricht und die Identität des Absenders gewährleistet werden.
Nebenbemerkung:
Codes werden heutzutage (typischerweise) nicht mehr verwendet.
Verschlüsselung ist der Prozess eine Nachricht im Klartext (plaintext) in ein "unlesbares" (unverständliches) Format zu überführen:
$$ C = E_K(P) $$
D.h. durch die Verschlüsselungsfunktion wird eine Nachricht in eine verschlüsselte Nachricht überführt.
$$ P = D_{K'}(C) $$
Für die Entschlüsselung benötigt man wieder einen Schlüssel $K'$:
Typischerweise geht man davon aus, dass das Verfahren zum Verschlüsseln und Entschlüsseln öffentlich ist.
"Alle Algorithmen ($E$ und $D$) sind öffentlich. Nur die Schlüssel sind privat."
Beachte: Security by obscurity (hier: Geheimhaltung der Algorithmen) funktioniert nicht wirklich und sollte daher in der Praxis (in der Regel) nicht angewandt werden.
Bei asymmetrischen Verfahren ist einer der Schlüssel öffentlich (siehe unten).
Brute-force Attacken (hier: Angriff mittels Ausprobieren aller möglichen Schlüssel).
Beispiel: Zahlen als Schlüssel mit Länge $l$.
Der Aufwand ist exponentiell in der Schlüssellänge (Zeichen).
Beispiel Dezimalzahlen als Schlüssel:
openssl oder gpg¶Verschlüsseln:
openssl enc -aes-256-cbc -pbkdf2 -salt -in msg.txt -out msg.enc
Entschlüsseln
openssl enc -aes-256-cbc -pbkdf2 -d -in msg.enc -out msg.txt
Probieren Sie oben stehenden Befehl aus. Was ist Salting?
Beim symmetrischen Verfahren ergibt sich das sogenannte Schlüsselverteilungsproblem: Wie können die beiden Kommunikationspartner den (symmetrischen) Schlüssel über einen unsicheren Kanal austauschen? Ein/e Angreifer:in könnte beim Schlüsselaustausch diesen ebenfalls erhalten.
Whitfield Diffie und Martin E. Hellman entwarfen das asymmetrische Verschlüsselungsverfahren, das dieses Problem löst.
Ein Schlüsselpaar ($K$, $K'$) wird mit einem Schlüsselerzeugungsalgorithmus erzeugt: Dieser Algorithmus generiert einen privaten Schlüssel (private key) zufällig gleichverteilt (uniform) aus der Menge der möglichen privaten Schlüssel. Der Algorithmus gibt neben dem privaten Schlüssel auch den korrespondierenden öffentlichen Schlüssel (public key) zurück.
Wenn Bob Alice eine Nachricht senden will, verschlüsselt er die Nachricht mit dem öffentlichen Schlüssel von Alice. Da nur Alice den korrespondierenden privaten Schlüssel hat, kann nur sie die Nachricht entschlüsseln. Analog verschlüsselt Alice eine Nachricht an Bob mit dem öffentlichen Schlüssel von Bob. Diese Nachricht kann dann nur Bob entschlüsseln.
Verschlüsselung und Entschlüsselung funktionieren mit zwei Algorithmen: Der Verschlüsselungsalgorithmus entspricht der Verschlüsselungsfunktion mit dem öffentlichen Schlüssel $K$. Der Entschlüsselungsalgorithmus (Entschlüsselungsfunktion) verwendet dagegen den zu $K$ korrespondierenden privaten Schlüssel $K'$.
Eine Hashfunktion nimmt als Input Daten beliebiger Menge auf und erzeugt deterministisch einen Hash-Wert fester Länge.
$$h = H(d)$$
Weitere (englische) Begriffe, die in diesem Zusammenhang einen solchen Hash-Wert bezeichnen, sind: Hash, Summary, Digest, Checksum oder Fingerprint.
Da Hashs feste Länge haben und aus beliebigen Daten berechnet werden, können Kollisionen (collisions) auftreten. Kollision bedeutet, dass zwei Datensätze $d$ und $d'$ den gleichen Hash-Wert $h$ haben. Bei geeignet langen Hash-Werten ist die Wahrscheinlichkeit der Kollision (echter Daten) bei kryptographischen Hashfunktionen aber extrem gering.
Betrachte $n$ Personen mit zufälligen Geburtsdaten mit der Annahme, dass alle Personen nicht in einem Schaltjahr (365 Tage) geboren wurden. Bei wievielen Personen $n$ ist die Wahrscheinlichkeit, dass zwei Personen an einem Tag geboren wurden (Kollision), mindestens 50%?
Anzahl der Kombinationen $n=23$ (unterscheidbare) Personen auf $d = 365$ Tage zu verteilen, ohne dass ein Geburtstag auf den gleichen Tag fällt:
$$ 365 \cdot 364 \dots (365-23+1) = \frac{365!}{(365-23)!} $$
Anzahl der Kombinationen 23 (unterscheidbare) Personen auf 365 Tage beliebig zu verteilen: $365^{23}$
Wahrscheinlichkeit, dass von den 23 Personen alle an einem unterschiedlichen Tag Geburtstag haben, ist das Verhältnis der Kombinationen: $$ \frac{365!}{(365-23)! 365^{23} } \approx 0.4927 $$
Wahrscheinlichkeit, dass von den 23 Personen nicht alle an einem unterschiedlichen Tag Geburtstag haben:
$$ 1 -\frac{d!}{(d-n)! d^{n} } = 1-\frac{365!}{(365-23)! 365^{23} } \approx 0.5073 $$
Alice kann eine (öffentliche oder geheime) Nachricht mit Ihrem privaten Schlüssel signieren. Dabei wird eine digitale Signatur erzeugt. Die Nachricht und die zusätzliche digitale Signatur werden an Bob (eventuell mit seinem öffentlichen Schlüssel verschlüsselt) versendet bzw. veröffentlicht. Die digitale Signatur ergibt sich aus dem Hash-Wert der Nachricht, der mit dem privaten Schlüssel von Alice verschlüsselt wird.
Bob kann die Signatur verwenden, um die Authentizität der Nachricht zu überprüfen: Mittels der Nachricht, des öffentlichen Schlüssels (von Alice) und der Signatur wird mit einem Signatur-Verifizierungsalgorithmus bestimmt, ob die Nachricht authentisch ist.
Dazu wird von Bob mit dem öffentlichen Schlüssels (von Alice) der verschlüsselte Hash-Wert entschlüsselt. Außerdem wird aus der Nachricht der Hashwert mit derselben Hash-Funktion (z.B. SHA-2), die Alice verwendet hat, berechnet. Wenn die beiden Hash-Werte gleich sind, kann man davon ausgehen, dass die Integrität der Nachricht gewährleistet ist. Das heißt, dass die empfangene Nachricht vollständig der von Alice signierten Nachricht entspricht. Wenn Mallory die Nachricht verändert, wird von Bob ein anderer Hash-Wert als der in der digitalen Signatur berechnet. Daher erkennt Bob, dass die Nachricht verändert wurde.
Außerdem wird so das Schutzziel Nicht-Abstreitbarkeit gewährleistet: Alice kann nicht abstreiten, dass die Nachricht von ihr stammt. Nur sie hat ihren privaten Schlüssel und kann somit die korrekte Signatur, die zu ihrem öffentlichen Schlüssel korrespondiert, erstellen (d.h. den Hash mit ihrem privaten Schlüssel verschlüsseln).
Hinweis: Die Beschreibung „den Hash mit dem privaten Schlüssel verschlüsseln“ gilt so für RSA. Bei anderen Verfahren (z.B. DSA/ECDSA) ist die Signatur kein verschlüsselter Hash; das Prinzip (Signieren mit dem privaten, Verifizieren mit dem öffentlichen Schlüssel) bleibt aber gleich.
Die digitale Signatur funktioniert mit den zwei Algorithmen:
Die Performanz (Rechenaufwand) verhindert es, dass größere Datenmengen in der Praxis mittels asymmetrischer Verfahren ausgetauscht werden können.
Lösungsidee:
Austausch eines "symmetrischen Schlüssels" (für ein symmetrisches Verschlüsselungsverfahren) mittels Public Key Kryptographie zu Beginn der Kommunikation-Session. Der "symmetrische Schlüssel" wird dabei jedes mal zufällig und neu erzeugt. Diffie-Hellman-Schlüsselaustausch
Aber auch bei der asymmetrischen Kryptographie ergibt sich ein ungelöstes Problem (ähnlich zum Schlüsselaustauschproblem der symmetrischen Kryptographie):
Mallory könnte im Kommunikationskanal zwischen Alice und Bob stehen (man-in-the-middle) und die Nachrichten immer mit seinen privaten Schlüsseln entschlüsseln. Alice und Bob haben fälschlicherweise öffentliche Schlüssel von Mallory, denken aber diese kommen von Bob bzw. Alice. Mallory kann dann die abgefangenen Nachrichten weitersenden. Zuvor verschlüsselt er diese mit den richtigen öffentlichen Schlüsseln von Alice bzw. Bob.
Lösung:
CAs signieren die öffentlichen Schlüssel von Alice und Bob (typischerweise zusammen mit weiteren Daten über Alice und Bob) mit privaten Schlüsseln der CAs. Die CAs erstellen so digitale Zertifikate für die öffentlichen Schlüssel (von Alice und Bob). Das digitale Zertifikat ist dabei ein von der Zertifizierungsstelle signierter Datensatz, in dem die Eigenschaften von Alice bzw. Bob, wie z.B. Ihre Namen, Email Adressen zusammen mit dem öffentlichen Schlüssel beschrieben sind. Üblich ist hier der Standard X.509.
Ein digitales Zertifikat hat typischerweise folgenden Inhalt:
Die Zertifikate der großen CAs (root CAs) werden als Root-Zertifikate bezeichnet. Diese liegen typischerweise auch im Standard X.509 vor. Root-Zertifikate sind unsigniert oder selbst-signiert. Im Root-Zertifikat sind die Informationen über die entsprechende root-CA und der öffentliche Schlüssel der CA enthalten.
Die Root-Zertifikate der großen CA werden typischerweise mit Betriebssystemen bzw. Webbrowsern etc. ausgeliefert (gespeichert im local trust store oder root store). Alice und Bob besitzen somit (in der Regel) die korrekten Root-Zertifikate der großen CAs. Oft gibt es auch weitere (kleinere) CAs (Intermediate CAs), die ihre Zertifikate von Root-CAs signieren lassen.
Wenn Alice und Bob ihre öffentlichen Schlüssel von solchen Intermediate CAs signieren lassen, können sie über eine Chain of Trust als vertrauenswürdig angesehen werden. Eine Intermediate CA signiert, z.B. die Zertifikate von Alice und Bob. Das Zertifikat der Intermediate CA ist wiederum signiert von einer Root-CA.
Die Identitätsüberprüfung in einem digitalen Zertifikat, um sicherzustellen, dass es von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde und die Identität des Inhabers korrekt ist, erfolgt durch mehrere Schritte:
Vertrauenswürdige Wurzel-Zertifikate: Bob muss eine Liste von vertrauenswürdigen Wurzel-Zertifikaten besitzen. Diese Wurzelzertifikate gehören zu den Zertifizierungsstellen, denen Bob vertraut. Diese Wurzelzertifikate sind normalerweise vorinstalliert und Teil des sogenannten trust stores in Betriebssystemen und Anwendungen.
Zertifikatskette überprüfen: Das digitale Zertifikat von Alice enthält normalerweise nicht nur ihre Identitätsinformationen und den öffentlichen Schlüssel, sondern auch eine Signatur von einer Zwischenzertifizierungsstelle, die wiederum von einer übergeordneten Zertifizierungsstelle signiert wurde. Dies führt zu einer "Zertifikatskette" bis zur Wurzelzertifizierungsstelle.
Signaturen überprüfen: Bob überprüft die Signatur jedes Zertifikats in der Kette. Dies geschieht durch die Anwendung des öffentlichen Schlüssels der ausstellenden Zertifizierungsstelle auf die Signatur des Zertifikats. Wenn die Signatur überprüft werden kann, bedeutet dies, dass das Zertifikat (und somit auch der öffentliche Schlüssel) von der ausstellenden Zertifizierungsstelle signiert wurde und somit authentisch ist.
Ablaufdatum überprüfen: Bob überprüft auch das Ablaufdatum jedes Zertifikats in der Kette, um sicherzustellen, dass es noch gültig ist.
Identitätsinformationen prüfen: Bob überprüft die im Zertifikat enthaltenen Identitätsinformationen, wie den Namen und die E-Mail-Adresse, und vergleicht sie mit den erwarteten Informationen für Alice.
Wenn alle diese Überprüfungen erfolgreich sind, kann Bob sicher sein, dass Alices Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde und die darin enthaltenen Identitätsinformationen korrekt sind. Dies bildet die Grundlage für das Vertrauen in die Authentizität von Alices öffentlichem Schlüssel und somit für die Sicherheit der Kommunikation.
certbot Software-Werkzeug um Zertifikate von "Let's Encrypt" zu beantragen.CAs nehmen (oft) Gebühren für Ihre Dienste.
Für Interessierte: Wie die automatische Beantragung von Zertifikaten bei CAs abläuft kann, ist über Automatic Certificate Management Environment (ACME) geregelt.
Eine dezentrale Alternative zu PKI ist das Web of Trust. Das sich aber nicht wirklich breit durchgesetzt hat.
Im Internet wird in der Regel das TLS-Protokoll zur Authentifizierung und Verschlüsselung verwendet. TLS läuft als separate Schicht zwischen TCP und den Protokollen der Anwendungs- und Darstellungsschicht, d.h. es umschließt die TCP-Verbindungen. TLS garantiert dabei die Authentizität eines Servers mittels eines Zertifikats und verschlüsselt die Verbindung zwischen Client und Server.
Die SHA-Familie (SHA-2 und SHA-3) erzeugen solche kryptographischen Hashfunktionen.
Hinweis: In der Praxis wird manchmal auch MD5 verwendet. Dieser ist aber verwundbar auf Kollisionen.
sha256sum <<< "Das ist ein beliebiger Text."
# Ohne Punkt am Ende, erhält man einen komplett anderen Hashwert!
sha256sum <<< "Das ist ein beliebiger Text"
Für Dateien, die im Internet heruntergeladen werden können, werden oft auch Checksummen (Hashwerte) zur Verifikation angeboten. Mit diesen kann überprüft werden, ob die Datei korrekt (ohne Fehler) heruntergeladen wurde. Wenn ein Angreifer allerdings einen "falschen" Download (kompromittierte Webserver/Downloadserver) vorgaukelt, so kann er natürlich auch korrespondierende falsche Checksummen zur Verifikation anbieten.
Studieren Sie folgenden heise-Artikel: Kryptographie-in-der-IT-Empfehlungen-zu-Verschluesselung-und-Verfahren
Hinweis: Mit dem Aufkommen von Quanten-Computern werden die gängigen asymmetrischen Verschlüsselungsverfahren unsicher. Die Forschungsrichtung Post-Quanten-Kryptographie versucht, entsprechend sichere Verfahren zu entwickeln, siehe z.B. https://en.wikipedia.org/wiki/Post-quantum_cryptography
Die praktischen openssl-Übungen befinden sich nun im separaten Notebook openssl-praxis.ipynb.
Verschlüsselte (signierte) Emails lassen sich per PGP (Standard OpenPGP) austauschen, z.B. mit der GnuPG-Implementierung, siehe auch https://gnupg.org/. Gängige Email-Clients unterstützen dies.
Hinweis: Wenn Sie die Schlüssel auf der Kommandozeile mit gpg erzeugen und anschließend in ein Email-Programm, wie Thunderbird, importieren wollen, so müssen Sie auch den privaten Schlüssel exportieren, z.B. mit
gpg --export-secret-keys --armor > my-secret-keys.asc, siehe auch man gpg.
Beantworten Sie folgende Fragen:
Lesen Sie folgende Informationen über Virtual Private Networks vom BSI.
Installieren Sie den openconnect-Client auf Ihrer Maschine und richten die VPN Verbindung zur HTW Berlin ein. Hinweis: Nicht parallel mit dem Cisco-Client einrichten.
vpncl.htw-berlin.dels /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pemVPN-Verbindung aufbauen auf der Kommandozeile: sudo openconnect vpncl.htw-berlin.de.
Eventuell mit weiteren Optionen:
authgroup="HTW-SSL-VPN-Split" etc.
sudo openconnect vpncl.htw-berlin.de --authgroup=${authgroup} --user=${user}
Für Nutzung in der graphischen Oberfläche Gnome, siehe https://rz.htw-berlin.de/anleitungen/vpn/linux2/
Aufgaben: (Recherche):
Hinweis:
Neben den (bereits, erwähnten bzw. behandelten) Netzwerk-Werkzeugen, wie z.B. nmap, netcat
gibt es hierzu auch spezielle entwickelte Werkzeuge:
für IT-Security Interessierte: Informieren Sie sich Tools und Angriffsarten: