Wichtige kryptographische Grundlagen - Kryptographie (crypography)¶
- Anwendung von Mathematik für das Problem der sicheren Kommunikation
- Fast alle Netzwerksicherheitsverfahren basieren auf Kryptographie.
- Krypographische Algorithmen (Cipher)
Anwendungen von Kryptographie¶
Folgende (Schutz)-Ziele können mit Hilfe von Kryptographie erreicht werden:
Vertraulichkeit (confidentiality) bzw. Geheimhaltung (secrecy): Daten dürfen lediglich von autorisierten Benutzern gelesen bzw. modifiziert 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 Author:in kann nicht leugnen, dass er/sie der/die Author:in der Nachricht ist und er/sie die Nachricht so verfasst hat.
Kryptographie erlaubt die sichere Kommunikation über einen unsicheren Kanal. Dabei wird kann neben der Vertraulichkeit auch die Korrektheit der Nachricht und die Identität des Absenders gewährleistet werden.
Nebenbemerkung:
- Ein weiteres Schutzziel in der IT-Security ist Verfügbarkeit, d.h. dass ein IT-System nutzbar ist und nicht durch Unterbrechungen gestört ist.
Verschlüsselung (Encryption) $E$¶
Verschlüsselung ist der Prozess eine Nachricht im Klartext (plaintext) in ein "unlesbares" (unverständliches) Format zu überführen:
$$ C = E_K(P) $$
- $E$ Verschlüsselungsfunktion (encryption)
- $P$: Nachricht als Klartext (plaintext)
- $C$: verschlüsselte Nachricht (ciphertext)
- $K$: Der Schlüssel (key) ist ein Parameter für die Verschlüsselungsfunktion.
D.h. durch die Verschlüsselungsfunktion wird eine Nachricht in eine verschlüsselte Nachricht überführt.
Entschlüsselung (Decryption) $D$¶
$$ P = D_{K'}(C) $$
- $D$ Entschlüsselungsfunktion (decryption)
Für die Entschlüsselung benötigt man wieder einen Schlüssel $K'$:
- bei symmetischen Verfahren ist dies derselbe Schlüssel wie beim Verschlüsseln, d.h. $K=K'$. Nur dann kann die Nachricht wieder (sinnvoll) gelesen werden.
- beim asymmetrischen Verfahren benutzt man beim Verschlüsseln und Entschlüsseln zwei unterschiedliche Schlüssel (Schlüsselpaar), siehe unten. Die beiden Schlüssel müssen natürlich zueinander passen.
Kerckhoff-Prinzip¶
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).
Länge der Schlüssel¶
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:
- $10^l = \exp(l \ln 10)$ (Exponentialfunktion)
- bei $l=3$ haben gibt es die möglichen Schlüssel $000$ bis $999$ also $10^3 = 1000$ Möglichkeiten.
Alice, Bob and Mallory¶
- In der kryptographischen Literatur werden typischerweise die beiden Akteure, die sicher kommunizieren wollen, mit Alice und Bob bezeichnet.
- Mallory dagegen will die Kommunikation abhören bzw. Nachrichten verändern, z.B. durch eine Man-in-the-middle Attack (MitM-Attack). Bei einer MitM-Attack setzt sich der/die Angreifer:in zwischen die Kommunkationspartner:innen.
Symmetrische Verfahren (symmetric key cryptography)¶
- Alice und Bob haben beide den gleichen (geheimen) Schlüssel $K$. Diese muss zu Beginn einer Kommunikation irgendwie ausgetauscht werden.
- Hier ergibt sich das Problem, wie der Schlüssel $K$ sicher ausgetauscht werden kann.
- Symmetrische Verfahren sind sehr effizient in Bezug auf Resourcenverbrauch (wie CPU-Nutzung und Nutzdaten (payload))
Standards für symmetrische Verfahren¶
Ver- und Entschlüsseln auf der Kommandozeile per openssl
oder gpg
¶
Verschlüsseln:
openssl enc -aes-256-cbc -salt -in msg.txt -out msg.enc
Entschlüsseln
openssl enc -aes-256-cbc -d -in msg.enc -out msg.txt
Aufgabe¶
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.
Asymmetrische Verfahren (Public Key Cryptography)¶
- Alice erzeugt zwei (korrespondierende) Schlüssel:
- einen öffentlichen Schlüssel (public key). Dieser wird veröffentlicht.
- einen privaten Schlüssel (private key). Diesen kennt nur Alice.
- Bob tut das Gleiche, d.h. er erzeugt auch so ein Schlüsselpaar und veröffentlich seinen öffentlichen Schlüssel.
Schlüsselerzeugungsalgorithmus (key generation algorithm)¶
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 korresponierenden öffentlichen Schlüsel (public key) zurück.
Sichere Kommunikation¶
Wenn Bob Alice eine Nachricht senden will, verschlüsselt er die Nachricht mit dem öffentlichen Schlüssel von Alice. Da nur Alice den korresponierenden 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$ korresponierenden privaten Schlüssel $K'$.
Kryptographische Hashfunktionen¶
Eine Hashfunktion nimmt als Input Daten beliebiger Menge auf und erzeugt deterministisch ein Hash-Wert fester Länge.
$$h = H(d)$$
- $d$: Datensatz (Nachricht etc.) beliebiger Länge
- $H$: Hash-Funktion/Algorithmus
- $h$: Hash-Wert mit fester Länge, d.h. die Länge ist unabhängig von der Länge von $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 kryptographische Hashfunktionen aber extrem gering.
Quiz "Birthday-Paradox"¶
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%?
- 23
- 57
- 184
- 367
Erklärung¶
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 unterschiedlichem 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 unterschiedlichem Tag Geburtstag haben:
$$ 1 -\frac{d!}{(d-n)! d^{n} } = 1-\frac{365!}{(365-23)! 365^{23} } \approx 0.5073 $$
(Gewünschte) Eigenschaften kryptographischer Hashfunktionen¶
- Entanglement: Jedes Bit des Hashwertes wird von jedem Bit des Inputs bestimmt. Wenn ein Bit des Inputs verändert wird, sollte im Durchschnitt sich jedes Hash-Bit mit einer Wahrscheinlichkeit von 50% ändern.
- Pseudo-randomness: Hashwerte sollten wie (gleichverteilte) Zufallsdaten aussehen. Es sollte keine interen Struktur bzw. Relation zum Input erkennbar sein. Alle Test auf Zufall sollten erfüllt sein.
- Nonreversibility: Wenn der Hashwert gegeben ist, ist es praktisch nicht machbar (infeasible) einen anderen Input zu generieren, der den gleichen Hashwert produziert.
Gewährleistung der Authentizität mittels digitaler Signatur¶
Alice kann eine Nachricht mit ihrem privaten Schlüssel signieren. Dadurch wird eine digitale Signatur erzeugt. Die Nachricht und die dazugehörige digitale Signatur werden an Bob gesendet. Optional kann die Nachricht zusätzlich mit Bobs öffentlichem Schlüssel verschlüsselt werden, um auch die Vertraulichkeit sicherzustellen.
Die digitale Signatur wird erzeugt, indem Alice zuerst einen kryptografischen Hash-Wert (auch "digitaler Fingerabdruck" oder "Digest" genannt) der Nachricht mit einer Hash-Funktion (z.B. SHA-256) berechnet. Dieser Hash-Wert ist eine kurze, eindeutige Zusammenfassung der Nachricht (und ggf. zusätzlichen Metadaten, wie Zeitstempel, Identität des Verfassers etc.). Anschließend verschlüsselt Alice diesen Hash-Wert mit ihrem privaten Schlüssel. Das Ergebnis dieser Verschlüsselung ist die digitale Signatur.
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. Um die Signatur zu überprüfen, führt Bob folgende Schritte durch:
- Er berechnet mit derselben Hash-Funktion (z.B. SHA-256) den Hash-Wert der empfangenen Nachricht (und ggf. der Metadaten).
- Er entschlüsselt die empfangene digitale Signatur mit Alices öffentlichem Schlüssel. Dadurch erhält er den ursprünglichen Hash-Wert, den Alice berechnet hat.
- Er vergleicht die beiden Hash-Werte. Wenn die beiden Hash-Werte identisch sind, ist die Signatur gültig. Das bedeutet, dass die Nachricht von Alice stammt (Authentizität) und dass sie seit der Signierung nicht verändert wurde (Integrität).
Außerdem wird so das Schutzziel Nicht-Abstreitbarkeit gewährleistet: Alice kann nicht abstreiten, dass die Nachricht von ihr stammt. Da nur Alice im Besitz ihres privaten Schlüssels ist (sein sollte), kann nur sie die korrekte Signatur, die zu ihrem öffentlichen Schlüssel korrespondiert, erstellen (d.h. den Hash mit ihrem privaten Schlüssel verschlüsseln). Dies ist besonders wichtig in rechtlichen oder geschäftlichen Kontexten, in denen es wichtig ist, die Urheberschaft einer Nachricht eindeutig nachweisen zu können.
Kombination symmetischer mit asymmetrischen Verfahren¶
Die Performanz (Rechenaufwand) verhindern es, dass größere Datenmengen in der Praxis mittels asymmetischer Verfahren ausgetauscht werden können.
Lösungsidee:
Austausch eines "symmetrischen Schlüssels" (für ein symmetisches 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
Public Key Infrastructure (PKI)¶
Aber auch bei der asymmetrischen Kryptographie ergibt sich ein ungelöstes Problem (ähnlich zum Schlüsselaustauschproblem der symmetrischen Kryptographie): Wie kann der öffentliche Schlüssel, z.B. von Alice an Bob, ausgetauscht werden, ohne dass Mallory diesen (unbemerkt) gegen seinen öffentlichen Schlüssel austauscht? Anders ausgedrückt: Wie kann die Authentizität des öffentlichen Schlüssels beim ersten Kontakt geprüft werden?
Mallory könnte im Kommunikationskanal zwischen Alice und Bob stehen (Man-in-the-Middle-Angriff) und die Nachrichten immer mit seinen privaten Schlüsseln entschlüsseln. Mallory positioniert sich unbemerkt im Kommunikationskanal zwischen Alice und Bob. Wenn Alice Bob ihren öffentlichen Schlüssel schickt, fängt Mallory diesen ab und ersetzt ihn durch seinen eigenen öffentlichen Schlüssel. Umgekehrt verfährt er genauso, wenn Bob seinen öffentlichen Schlüssel an Alice schickt. Nun besitzen Alice und Bob jeweils Mallorys öffentlichen Schlüssel und glauben, es seien die Schlüssel des jeweils anderen. Wenn Alice nun eine Nachricht mit dem (fälschlicherweise für Bobs gehaltenen) öffentlichen Schlüssel verschlüsselt, kann Mallory diese mit seinem privaten Schlüssel entschlüsseln, lesen, möglicherweise verändern und anschließend mit Bobs echtem öffentlichen Schlüssel wieder verschlüsseln, bevor er sie an Bob weiterleitet. Bob denkt, die Nachricht stamme authentisch von Alice. Das Gleiche passiert in umgekehrter Richtung.
Lösung:
Die Lösung basiert auf dem Vertrauen in Zertifizierungsstellen (Certificate Authorities, kurz CA), die für die Echtheit (Authentizität) der öffentlichen Schlüssel (von Alice und Bob) bürgen. Diese Lösung implementiert eine Public Key Infrastructure (PKI).
Skizzierung der PKI-Idee¶
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, E-Mail-Adressen zusammen mit dem öffentlichen Schlüssel beschrieben sind. Üblich ist hier der Standard X.509, der das Format und die Kodierung (z.B. ASN.1) der Zertifikate definiert.
Ein digitales Zertifikats hat typischerweise folgenden Inhalt:
- Name des Zertifikatinhabers,
- ausstellende Zertifizierungsstelle (Issuer),
- Gültigkeitsdauer (von - bis),
- Seriennummer,
- öffentlicher Schlüssel des Inhabers,
- Digitale Signatur der Zertifizierungsstelle, zur Überprüfung der Echtheit des Zertifikats.
Hierachie und Root-Zertifikate (optional)¶
Es gibt oft eine Hierarchie von CAs. An der Spitze steht eine Root CA, deren Zertifikat in der Regel in Browsern und Betriebssystemen vorinstalliert ist (gespeichert im local trust store oder root store). 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. Unterhalb der Root CA können Intermediate CAs existieren, die wiederum Zertifikate für Endbenutzer ausstellen. Um die Gültigkeit eines Zertifikats zu überprüfen, muss Bob die gesamte Zertifikatskette (Chain of Trust) bis zur Root CA überprüfen. Er muss also nicht nur die Signatur des Zertifikats von Alice überprüfen, sondern auch die Signaturen aller Intermediate CA-Zertifikate in der Kette. Zusätzlich muss Bob die Gültigkeitsdauer des Zertifikats prüfen und sicherstellen, dass es nicht widerrufen wurde (z.B. durch Abruf einer Certificate Revocation List (CRL) oder über das Online Certificate Status Protocol (OCSP)).
Identitätsüberprüfung im Detail (optional)¶
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.
Beispiele für CAs):¶
- IdenTrust
- GeoTrust
- DigiCert
- Sectigo
- Let's Encrypt (freier Service gesponsort durch Organisationen, wie Electronic Frontier Foundation, Mozilla Foundation, Linux Foundation etc.)
certbot
Software-Werkzeug um Zertifikate von "Let's Encrypt" zu beantragen.
- CAcert (gemeinschaftsbetriebene, nichtkommerzielle Zertifizierungsstelle)
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.
Web of Trust (optional)¶
Eine dezentrale Alternative zu PKI ist das Web of Trust.
Im Gegensatz zur hierarchischen Struktur einer PKI, bei der Zertifizierungsstellen (CAs) als zentrale Vertrauensinstanzen fungieren, basiert das Web of Trust auf direkten Vertrauensbeziehungen zwischen den Benutzern. Jeder Benutzer kann im WoT die öffentlichen Schlüssel anderer Benutzer signieren und somit deren Authentizität bestätigen.
Das Grundprinzip ist die transitive Vertrauensübertragung:
Wenn Alice Bob vertraut und Bobs öffentlichen Schlüssel signiert, und Bob Charlie vertraut und Charlies öffentlichen Schlüssel signiert, dann kann Alice indirekt auch Charlie vertrauen, da sie Bob vertraut, der wiederum Charlie vertraut.
Jeder Benutzer verwaltet seinen eigenen „Schlüsselbund“ (Keyring), der die öffentlichen Schlüssel anderer Benutzer sowie die von ihm ausgestellten Signaturen enthält. Um die Authentizität eines öffentlichen Schlüssels zu überprüfen, sucht ein Benutzer nach einer „Vertrauenskette“ (Trust Path) zu dem entsprechenden Schlüssel. Diese Kette besteht aus einer Reihe von Signaturen, die von vertrauenswürdigen Personen ausgestellt wurden und den Weg zum Zielschlüssel nachvollziehbar machen.
Vorteile des Web of Trust:
- Dezentralisierung: Es gibt keine zentrale Autorität, die kontrolliert oder ausfallen könnte. Dies macht das System widerstandsfähiger gegen Zensur und Single Points of Failure.
- Benutzerkontrolle: Die Benutzer haben die volle Kontrolle darüber, wem sie vertrauen und wessen Schlüssel sie signieren.
- Flexibilität: Das WoT ist flexibler als PKI und kann an verschiedene Anwendungsfälle angepasst werden.
Nachteile des Web of Trust:
- Komplexität: Die Verwaltung von Schlüsseln und Signaturen kann für Benutzer komplex sein, insbesondere in großen Netzwerken. Die Suche nach Vertrauensketten kann zeitaufwendig sein.
- Mangelnde Skalierbarkeit: Das WoT skaliert schlecht für große Benutzerzahlen. Je mehr Benutzer es gibt, desto schwieriger wird es, Vertrauensketten zu finden und zu verwalten.
- Subjektivität des Vertrauens: Das Vertrauen im WoT ist subjektiv und basiert auf persönlichen Beziehungen. Es gibt keine objektiven Kriterien für die Vertrauenswürdigkeit eines Schlüssels. Dies kann zu Problemen führen, wenn Benutzer falsche oder unzuverlässige Schlüssel signieren.
- Schwierigkeiten bei der Einführung: Die Etablierung eines funktionierenden Web of Trust erfordert eine kritische Masse an Benutzern, die aktiv Schlüssel signieren und verwalten. Dies ist in der Praxis oft schwierig zu erreichen.
- Kein Widerruf von Schlüsseln: Es gibt keinen Mechanismus zum Widerruf von Schlüsseln im WoT. Wenn ein privater Schlüssel kompromittiert wird, bleibt die Signatur dieses Schlüssels gültig, bis der Benutzer sie manuell aus seinem Schlüsselbund entfernt.
Gründe für die geringe Verbreitung:
Die oben genannten Nachteile, insbesondere die Komplexität, die mangelnde Skalierbarkeit und die Schwierigkeiten bei der Einführung, haben dazu beigetragen, dass sich das Web of Trust im Vergleich zu PKI nicht breit durchgesetzt hat.
- Benutzerfreundlichkeit: PKI mit ihren automatischen Zertifikatsüberprüfungen ist für Endbenutzer deutlich einfacher zu handhaben als das WoT, das manuelle Interaktion und Entscheidungen erfordert.
- Unternehmensanforderungen: In Unternehmensumgebungen, in denen zentrale Kontrolle und Verwaltung wichtig sind, ist PKI die bevorzugte Lösung.
- Standardisierung: PKI ist durch Standards wie X.509 gut standardisiert, was die Interoperabilität verschiedener Systeme ermöglicht. Das WoT hingegen ist weniger standardisiert.
Anwendungsfälle des Web of Trust:
Trotz seiner geringen Verbreitung gibt es einige Anwendungsfälle, in denen das Web of Trust relevant ist:
- PGP/GPG: Das bekannteste Beispiel für die Verwendung des WoT ist die E-Mail-Verschlüsselungssoftware PGP (Pretty Good Privacy) und ihr Open-Source-Pendant GPG (GNU Privacy Guard).
- Kleine, geschlossene Gemeinschaften: In kleinen Gruppen oder Gemeinschaften, in denen sich die Mitglieder persönlich kennen oder einander vertrauen, kann das WoT gut funktionieren.
Transport Layer Security (TLS)¶
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 Zertifikat und verschlüsselt die Verbindung zwischen Client und Server.
- TLS verwendet Public-Key Kryptographie und PKI, um (zufällige) Schlüssel zwischen Knoten (Rechner) eines Netzwerks auszutauschen. Die eigentliche Kommunikation zum Datenaustausch findet dann mittels symmetrischer Verschlüsselung statt.
- TLS ist der Nachfolger von SSL, daher wird TLS auch als TLS/SSL bezeichnet.
- TLS gepaart mit HTTP ergibt HTTPS.
- Wenn Client und Server eine TLS-Connection aufgebaut haben, wird der Inhalt des Austauschs geschützt, inkl. URLs und Header-Dateien etc. Nur Host und Port der TCP-Verbindung können von einem Angreifer gelesen werden.
- Basis für sichere Anwendungen, wie Online-Banking etc.
- Typischerweise one-way TLS Encryption, d.h. Server mit Zertifikat. Aber auch two-way TLS möglich (hier muss sich auch der Client mit Zertifikat ausweisen).
SHA (Secure Hash Algorithms)¶
Die SHA-Famile (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."
7df6d2201e904d2c028a5269a1fce420acb30d5c687a66c86705283a7aef7b9d -
# Ohne Punkt am Ende, erhält man einen komplett anderen Hashwert!
sha256sum <<< "Das ist ein beliebiger Text"
8cc1181fdde2251c11bd4f7414a6623b186d50f3b562a5255da8ccdd633633c3 -
Verifikation von heruntergeladenen Dateien¶
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 (kompromitierte Webserver/Downloadserver) vorgaugelt, so kann er natürlich auch korrespondierende falsche Checksummen zur Verifikation anbieten.
Aufgabe (optional)¶
Studieren Sie folgenden heise-Artikel: Kryptographie-in-der-IT-Empfehlungen-zu-Verschluesselung-und-Verfahren
Zukunft der Kryptographie¶
Hinweis: Mit dem Aufkommen von Quanten-Computern werden die gängigen asymmetrischen Verschlüsselungsverfahren unsicher. Die Forschung Post-Quanten-Kryptographie versucht entsprechenden sichere Verfahren zu entwickeln, siehe z.B. https://en.wikipedia.org/wiki/Post-quantum_cryptography
PGP - Pretty Good Privacy für Email-Verschlüsselung¶
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.
Aufgabe:¶
- Arbeiten Sie das Tutorial https://wiki.ubuntuusers.de/GnuPG/ durch und erzeugen Sie ein Schlüsselpaar. Richten Sie anschließend Ihren Email-Client entsprechend ein. Tauschen Sie ggf. die öffentlichen Schlüssel mit Ihren Kommiliton:innen aus.
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
.
Weitere IT-Security Themen¶
Aufgabe: Studieren Sie folgende grundlegenden Hinweise zur Sicherheit:¶
Aufgabe¶
Beantworten Sie folgende Fragen:
- Was ist ein Digitales Zertifikat? Wozu dient es und wie wird dabei das Vertrauen gewährleistet?
- Was ist Spoofing?
VPN - Virtual Private Network (optional)¶
Aufgabe (optional)¶
Lesen Sie folgende Informationen über Virtual Private Networks vom BSI.
Aufgabe (optional)¶
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.
- Gateway:
vpncl.htw-berlin.de
- Überprüfen, ob das Zertifikat vorhanden ist:
ls /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
VPN-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/
Penetration Testing (optional)¶
Aufgaben: (Recherche):
- Was ist Penetration Testing? Was für Typen von Penetration Tests gibt es? Informieren Sie sich bei Interesse, z.B. mittels des Praxis-Leitfaden: IT-Sicherheits-Penetrationstest des BSI
Hinweis:
Neben den (bereits, erwähnten bzw. behandelten) Netzwerk-Werkzeugen, wie z.B. nmap
, netcat
gibt es hierzu auch spezielle entwickelte Werkzeuge:
Verschlüsselung von Festplatten bzw. Verzeichnissen¶
Aufgaben (optional):¶
- Richten Sie auf Ihrem Linux-Rechner ein verschlüsseltes Verzeichnis ein, z.B. mit ecryptfs, siehe https://wiki.ubuntuusers.de/ecryptfs/Einrichten/
Literatur¶
- E. Nemeth et al, Unix and Linux System Administrator Handbook, fifth edition, 2018 Pearson Education
- J. Woods, Understanding Public Key Infrastructure and X.509 Certificates, Linux Journal 2019