December 21, 2023

STP048: Vertrauen

1 hour 19 minutes

Nach Xyrills gewaltigem humorischen Auftakt kommen wir zu wirklich wichtigen Dingen: Wem kann vertraut werden und warum? Hat Vertrauen ein Haltbarkeitsdatum? Wem vertraue ich, ohne explizit davon zu wissen? Zum Schluss gibt es noch Aufklärung über die Herkunft des Wortes Spam für unerwünschte Werbung.

Shownotes

Rückbezug zu STP039: Authentifizierung ("Wer ist diese Person?" bzw "Was darf diese Person?")

Problem: Woher weiß man, ob ein Identitätsnachweis verlässlich ist? -> Vertrauen

Vorstellung verschiedener Arten von Vertrauensvermittlung -> Ziel: Vokabular aufbauen, Methoden gegeneinander abwägen

Beispiele im realen Leben: gemeinsame Vorgeschichte und Inside-Jokes, Geheimlosungen, Personalausweise

Vererbung von Vertrauen: Digitale Zertifikate nach dem X.509-Standard

basierend auf asymmetrischer Verschlüsselung (siehe STP043)

Zertifikat = öffentlicher Schlüssel + Identitätsinformationen + Signatur durch ein übergeordnetes Zertifikat

durch die Signaturkette geht Vertrauen vom Anfang der Kette (Zertifikatsautorität, CA) auf die abgeleiteten Zertifikate über

authentifizierende Systeme müssen nur das allererste Zertifikat in der Kette kennen (das Wurzel-Zertifikat bzw. Root-CA)

Beispiel: Wurzelzertifikat signiert Zertifikat einer unterliegenden CA, und dieses signiert ein Zertifikat für einen Nutzer

Einsatzfälle

Transportverschlüsselung im Web (HTTPS, Zertifikat enthält Domain-Namen)

Impfzertifikate in der Corona-Warn-App

Benutzerseitige Zertifikate im Firmen-Intranet oder bei Elster

Äquivalente in der realen Welt: Personalausweis oder Reisepass (ausgestellt durch eine Regierungsstelle), Zugangskarte in der Firma (ausgestellt durch die Liegenschaftsverwaltung der Firma), Mitarbeiteruniform (eine Person in DB-Uniform auf einem Bahnhof wird wahrscheinlich ein DB-Mitarbeiter sein)

Vorteile: skaliert sehr gut auf viele Akteure, nur relativ wenig Speicher notwendig (für die Root-CAs)

Nachteil: erfordert Vertrauen in eine zentrale Stelle

Vertrauen durch Beständigkeit: Trust on first use (TOFU)

beim ersten Kontakt mit einer Person wird deren öffentlichen Schlüssel blind vertraut

bei weiteren Kontakten wird demselben Schlüssel weiterhin vertraut, aber die Präsentation eines neuen Schlüssels wird als Angriffsversuch bzw. Betrugsversuch gewertet

Einsatzfälle

die meisten Messenger mit Ende-zu-Ende-Verschlüsselung (z.B. Signal, WhatsApp, verschlüsselte Chats in Telegram)

Fernzugriff auf Server mittels SSH (für den Teil, wo die Identität des Servers überprüft wird)

Äquivalente in der realen Welt: Bekanntschaften unter Nachbarn oder Vereinsmitgliedern (alles, was auf der Basis von "den kenn ich" läuft)

Vorteil: braucht keinen zentralen Vertrauensanker

Nachteil: anfällig gegen Attacken beim initialen Verbindungsaufbau

Vertrauen durch Vitamin B: Web of Trust (WoT)

Zertifikate ähnlich wie bei X.509: öffentlicher Schlüssel + Identitätsinformatione + Liste von Signaturen

Signaturen nicht vertikal (in einer Hierarchie), sondern horizontal (zwischen gleichrangigen Zertifikaten verschiedener Nutzer)

Vertrauen vererbt sich zwischen Nutzern:

unendliches Vertrauen in das eigene Zertifikat

hohes Vertrauen in Zertifikate, die man selbst signiert hat

mittelhohes Vertrauen in Zertifikate, die von diesen Zertifikaten signiert wurden

und so weiter

Einsatzfälle

E-Mail-Verschlüsselung mit PGP/GPG, siehe auch Keysigning-Parties

Verifikation eines Chat-Kontakts über einen Seitenkanal

Äquivalent in der realen Welt: Bekanntschaften über Bande ("der Freund der Freundin des Schwippschwagers")

Vorteil: braucht keinen zentralen Vertrauensanker

Nachteil: Schlüssel mit vielen Signaturen sind eigentlich wertvoll, aber auch unhandlich; Angriff möglich durch bösartige Müll-Signaturen

Seitenleiste: Wie könnte man solchen Signatur-Spam verhindern?

Problem: Spam (sowohl bei E-Mails als auch GPG-Signaturen) ist für den Versender sehr günstig und für den Empfänger extrem lästig -> Kann man den Spieß umdrehen?

Idee (1990er): wir nutzen Einwegfunktionen (Streuwertfunktionen siehe STP004, STP043), aber drehen die Sache um

Sender muss einen Datensatz bilden, für den eine Streuwertfunktion ein Ergebnis mit X führenden Nullen hat (X kann variiert werden je nach Leistungsfähigkeit aktueller Prozessoren) -> erfordert sehr viel Durchprobieren von Eingabewerten

Empfänger muss nur schauen, dass die Lösung stimmt -> erfordert nur eine Berechnung mit dem präsentierten Eingabewert

Implementation (2002): Hashcash als eines der ersten Proof-of-Work-Verfahren

Vertrauen durch Proof of Work: Blockchain

Kombination von Proof of Work mit Merkle-Bäumen

Merkle-Baum = Baumstruktur aus Datenpaketen, die jeweils die Hash-Werte ihrer untergeordneten Knoten enthalten -> Hash-Wert des Wurzelknotens ist die einzige benötigte Information, um die Integrität des gesamten Baumes zu überprüfen

Blockchain: System zur kontinuierlichen Erweiterung eines Merkle-Baums (genauer: einer Merkle-Kette) um neue Blöcke, aber die Hashes jedes Blocks müssen eine Proof-of-Work-Bedingung erfüllen

kein Vertrauen in einzelne Akteure notwendig, nur in die Sicherheit des Algorithmus

Abendgedanken: Vertrauen lässt sich nicht eliminieren, nur verschieben

Vertraue ich einem Menschen? Einer Maschine? Einer Organisation? Einem Algorithmus?

Niemandem vertrauen ist auch keine Lösung.

im Gespräch erwähnt

Versionsverwaltungssystem "git", wie von uns besprochen im Pentaradio vom Juli 2021

...more

View all episodes

By Xyrillian Noises

December 21, 2023

STP048: Vertrauen

1 hour 19 minutes

Shownotes

Rückbezug zu STP039: Authentifizierung ("Wer ist diese Person?" bzw "Was darf diese Person?")

Problem: Woher weiß man, ob ein Identitätsnachweis verlässlich ist? -> Vertrauen

Vorstellung verschiedener Arten von Vertrauensvermittlung -> Ziel: Vokabular aufbauen, Methoden gegeneinander abwägen

Beispiele im realen Leben: gemeinsame Vorgeschichte und Inside-Jokes, Geheimlosungen, Personalausweise

Vererbung von Vertrauen: Digitale Zertifikate nach dem X.509-Standard

basierend auf asymmetrischer Verschlüsselung (siehe STP043)

Zertifikat = öffentlicher Schlüssel + Identitätsinformationen + Signatur durch ein übergeordnetes Zertifikat

durch die Signaturkette geht Vertrauen vom Anfang der Kette (Zertifikatsautorität, CA) auf die abgeleiteten Zertifikate über

authentifizierende Systeme müssen nur das allererste Zertifikat in der Kette kennen (das Wurzel-Zertifikat bzw. Root-CA)

Beispiel: Wurzelzertifikat signiert Zertifikat einer unterliegenden CA, und dieses signiert ein Zertifikat für einen Nutzer

Einsatzfälle

Transportverschlüsselung im Web (HTTPS, Zertifikat enthält Domain-Namen)

Impfzertifikate in der Corona-Warn-App

Benutzerseitige Zertifikate im Firmen-Intranet oder bei Elster

Vorteile: skaliert sehr gut auf viele Akteure, nur relativ wenig Speicher notwendig (für die Root-CAs)

Nachteil: erfordert Vertrauen in eine zentrale Stelle

Vertrauen durch Beständigkeit: Trust on first use (TOFU)

beim ersten Kontakt mit einer Person wird deren öffentlichen Schlüssel blind vertraut

bei weiteren Kontakten wird demselben Schlüssel weiterhin vertraut, aber die Präsentation eines neuen Schlüssels wird als Angriffsversuch bzw. Betrugsversuch gewertet

Einsatzfälle

die meisten Messenger mit Ende-zu-Ende-Verschlüsselung (z.B. Signal, WhatsApp, verschlüsselte Chats in Telegram)

Fernzugriff auf Server mittels SSH (für den Teil, wo die Identität des Servers überprüft wird)

Äquivalente in der realen Welt: Bekanntschaften unter Nachbarn oder Vereinsmitgliedern (alles, was auf der Basis von "den kenn ich" läuft)

Vorteil: braucht keinen zentralen Vertrauensanker

Nachteil: anfällig gegen Attacken beim initialen Verbindungsaufbau

Vertrauen durch Vitamin B: Web of Trust (WoT)

Zertifikate ähnlich wie bei X.509: öffentlicher Schlüssel + Identitätsinformatione + Liste von Signaturen

Signaturen nicht vertikal (in einer Hierarchie), sondern horizontal (zwischen gleichrangigen Zertifikaten verschiedener Nutzer)

Vertrauen vererbt sich zwischen Nutzern:

unendliches Vertrauen in das eigene Zertifikat

hohes Vertrauen in Zertifikate, die man selbst signiert hat

mittelhohes Vertrauen in Zertifikate, die von diesen Zertifikaten signiert wurden

und so weiter

Einsatzfälle

E-Mail-Verschlüsselung mit PGP/GPG, siehe auch Keysigning-Parties

Verifikation eines Chat-Kontakts über einen Seitenkanal

Äquivalent in der realen Welt: Bekanntschaften über Bande ("der Freund der Freundin des Schwippschwagers")

Vorteil: braucht keinen zentralen Vertrauensanker

Nachteil: Schlüssel mit vielen Signaturen sind eigentlich wertvoll, aber auch unhandlich; Angriff möglich durch bösartige Müll-Signaturen

Seitenleiste: Wie könnte man solchen Signatur-Spam verhindern?

Problem: Spam (sowohl bei E-Mails als auch GPG-Signaturen) ist für den Versender sehr günstig und für den Empfänger extrem lästig -> Kann man den Spieß umdrehen?

Idee (1990er): wir nutzen Einwegfunktionen (Streuwertfunktionen siehe STP004, STP043), aber drehen die Sache um

Empfänger muss nur schauen, dass die Lösung stimmt -> erfordert nur eine Berechnung mit dem präsentierten Eingabewert

Implementation (2002): Hashcash als eines der ersten Proof-of-Work-Verfahren

Vertrauen durch Proof of Work: Blockchain

Kombination von Proof of Work mit Merkle-Bäumen

Blockchain: System zur kontinuierlichen Erweiterung eines Merkle-Baums (genauer: einer Merkle-Kette) um neue Blöcke, aber die Hashes jedes Blocks müssen eine Proof-of-Work-Bedingung erfüllen

kein Vertrauen in einzelne Akteure notwendig, nur in die Sicherheit des Algorithmus

Abendgedanken: Vertrauen lässt sich nicht eliminieren, nur verschieben

Vertraue ich einem Menschen? Einer Maschine? Einer Organisation? Einem Algorithmus?

Niemandem vertrauen ist auch keine Lösung.

im Gespräch erwähnt

Versionsverwaltungssystem "git", wie von uns besprochen im Pentaradio vom Juli 2021

...more