STP048: Vertrauen

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 <a href="de.wikipedia.org/w/index.php?title=Spam&ol…; für unerwünschte Werbung.<h2>Shownotes</h2><ul>
<li>
Rückbezug zu STP039: Authentifizierung ("Wer ist diese Person?" bzw "Was darf diese Person?")
<ul>
<li>Problem: Woher weiß man, ob ein Identitätsnachweis verlässlich ist? -> Vertrauen</li>
<li>Vorstellung verschiedener Arten von Vertrauensvermittlung -> Ziel: Vokabular aufbauen, Methoden gegeneinander abwägen</li>
<li>Beispiele im realen Leben: gemeinsame Vorgeschichte und Inside-Jokes, Geheimlosungen, Personalausweise</li>
</ul>
</li>
<li>
Vererbung von Vertrauen: <a href="de.wikipedia.org/w/index.php?title=Digitales_Z… Zertifikate</a> nach dem <a href="de.wikipedia.org/w/index.php?title=X.509&o…;
<ul>
<li>basierend auf asymmetrischer Verschlüsselung (siehe STP043)
<ul>
<li>Zertifikat = öffentlicher Schlüssel + Identitätsinformationen + Signatur durch ein übergeordnetes Zertifikat</li>
<li>durch die Signaturkette geht Vertrauen vom Anfang der Kette (Zertifikatsautorität, CA) auf die abgeleiteten Zertifikate über</li>
</ul>
</li>
<li>authentifizierende Systeme müssen nur das allererste Zertifikat in der Kette kennen (das Wurzel-Zertifikat bzw. Root-CA)
<ul>
<li>Beispiel: Wurzelzertifikat signiert Zertifikat einer unterliegenden CA, und dieses signiert ein Zertifikat für einen Nutzer</li>
</ul>
</li>
<li>Einsatzfälle
<ul>
<li>Transportverschlüsselung im Web (HTTPS, Zertifikat enthält Domain-Namen)</li>
<li>Impfzertifikate in der Corona-Warn-App</li>
<li>Benutzerseitige Zertifikate im Firmen-Intranet oder bei Elster</li>
<li>Ä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)</li>
</ul>
</li>
<li>Vorteile: skaliert sehr gut auf viele Akteure, nur relativ wenig Speicher notwendig (für die Root-CAs)</li>
<li>Nachteil: erfordert Vertrauen in eine zentrale Stelle</li>
</ul>
</li>
<li>
Vertrauen durch Beständigkeit: <a href="en.wikipedia.org/w/index.php?title=Trust_on_fi… on first use (TOFU)</a>
<ul>
<li>beim ersten Kontakt mit einer Person wird deren öffentlichen Schlüssel blind vertraut</li>
<li>bei weiteren Kontakten wird demselben Schlüssel weiterhin vertraut, aber die Präsentation eines neuen Schlüssels wird als Angriffsversuch bzw. Betrugsversuch gewertet</li>
<li>Einsatzfälle
<ul>
<li>die meisten Messenger mit Ende-zu-Ende-Verschlüsselung (z.B. Signal, WhatsApp, verschlüsselte Chats in Telegram)</li>
<li>Fernzugriff auf Server mittels SSH (für den Teil, wo die Identität des Servers überprüft wird)</li>
<li>Äquivalente in der realen Welt: Bekanntschaften unter Nachbarn oder Vereinsmitgliedern (alles, was auf der Basis von "den kenn ich" läuft)</li>
</ul>
</li>
<li>Vorteil: braucht keinen zentralen Vertrauensanker</li>
<li>Nachteil: anfällig gegen Attacken beim initialen Verbindungsaufbau</li>
</ul>
</li>
<li>
Vertrauen durch Vitamin B: <a href="de.wikipedia.org/w/index.php?title=Web_of_Trus… of Trust (WoT)</a>
<ul>
<li>Zertifikate ähnlich wie bei X.509: öffentlicher Schlüssel + Identitätsinformatione + Liste von Signaturen</li>
<li>Signaturen nicht vertikal (in einer Hierarchie), sondern horizontal (zwischen gleichrangigen Zertifikaten verschiedener Nutzer)</li>
<li>Vertrauen vererbt sich zwischen Nutzern:
<ul>
<li>unendliches Vertrauen in das eigene Zertifikat</li>
<li>hohes Vertrauen in Zertifikate, die man selbst signiert hat</li>
<li>mittelhohes Vertrauen in Zertifikate, die von diesen Zertifikaten signiert wurden</li>
<li>und so weiter</li>
</ul>
</li>
<li>Einsatzfälle
<ul>
<li>E-Mail-Verschlüsselung mit PGP/GPG, siehe auch <a href="de.wikipedia.org/w/index.php?title=Keysigning-…;
<li>Verifikation eines Chat-Kontakts über einen Seitenkanal</li>
<li>Äquivalent in der realen Welt: Bekanntschaften über Bande ("der Freund der Freundin des Schwippschwagers")</li>
</ul>
</li>
<li>Vorteil: braucht keinen zentralen Vertrauensanker</li>
<li>Nachteil: Schlüssel mit vielen Signaturen sind eigentlich wertvoll, aber auch unhandlich; Angriff möglich durch bösartige Müll-Signaturen</li>
</ul>
</li>
<li>
Seitenleiste: Wie könnte man solchen Signatur-Spam verhindern?
<ul>
<li>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?</li>
<li>Idee (1990er): wir nutzen Einwegfunktionen (Streuwertfunktionen siehe STP004, STP043), aber drehen die Sache um
<ul>
<li>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</li>
<li>Empfänger muss nur schauen, dass die Lösung stimmt -> erfordert nur eine Berechnung mit dem präsentierten Eingabewert</li>
</ul>
</li>
<li>Implementation (2002): <a href="en.wikipedia.org/w/index.php?title=Hashcash&am…; als eines der ersten <a href="de.wikipedia.org/w/index.php?title=Proof_of_Wo…;
</ul>
</li>
<li>
Vertrauen durch Proof of Work: <a href="de.wikipedia.org/w/index.php?title=Blockchain&…;
<ul>
<li>Kombination von Proof of Work mit Merkle-Bäumen</li>
<li>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</li>
<li>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</li>
<li>kein Vertrauen in einzelne Akteure notwendig, nur in die Sicherheit des Algorithmus</li>
</ul>
</li>
<li>
Abendgedanken: Vertrauen lässt sich nicht eliminieren, nur verschieben
<ul>
<li>Vertraue ich einem Menschen? Einer Maschine? Einer Organisation? Einem Algorithmus?</li>
<li>Niemandem vertrauen ist auch keine Lösung.</li>
</ul>
</li>
<li>
im Gespräch erwähnt
<ul>
<li>Versionsverwaltungssystem "git", wie von uns besprochen im <a href="c3d2.de/news/pentaradio24-20210727.html"&… vom Juli 2021</a></li>
</ul>
</li>
</ul>

Kapitelklicken springt direkt hin

Shownotes