Soatoks inoffizieller Leitfaden für Threat Modeling

 (soatok.blog)
2 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Threat Model endet nicht damit, Schutzgüter und Angreifer aufzuschreiben; es wird erst dann für Designentscheidungen nutzbar, wenn auch Beziehungen zwischen Assets, Annahmen und bewusst ausgeschlossene Bedrohungen offengelegt werden
  • Ein gutes Modell betrachtet Assets nicht als Liste, sondern als Graphen, prüft Risiken und Prämissen, indem es Eingaben, Ausgaben und Abhängigkeiten von Komponenten schrittweise eingrenzt
  • Wenn Annahmen wegfallen, müssen auch akzeptierte Risiken neu bewertet werden; der Invisible Salamanders-Angriff zeigt Probleme, wenn Missbrauchsmeldungen in E2EE mit der AEAD-Annahme „genau ein gültiger Schlüssel pro Nachricht“ kollidieren
  • Das Beispiel publickey.directory trennt Annahmen, Assets, Akteure und Risikostati, ist aber nicht perfekt; das Threat Model von Matrix v1.18 ähnelt eher einer Liste von Angriffstypen und lässt Kryptografie sowie Key Management aus
  • Threat Modeling hilft dabei, bei Themen wie Passkey-Authentifizierung, dezentralem E2EE-Design oder der PQC-Debatte technische Einschränkungen von realen Risiken zu trennen und so bessere Designentscheidungen zu treffen

Welche Fragen ein Threat Model beantworten muss

  • Threat Modeling kann ein formaler Cybersecurity-Prozess sein, lässt sich aber auch inoffiziell in der Design- und Architekturphase eines neuen Produkts oder Dienstes durchführen
  • Mindestens die folgenden Fragen müssen beantwortet werden
    • Was wird geschützt
    • Wer oder was versucht, das Schutzgut zu beeinträchtigen
    • Auf welche Weise kann ein Angreifer angreifen
    • Was wird getan, um diesen Angriff zu verhindern
  • Auch mit diesen vier Punkten kann man von einem Threat Model sprechen, in der Praxis fehlen dann aber oft wichtige Details
  • Zusätzlich erforderlich sind folgende Fragen
    • Wie sind die zu schützenden Assets miteinander verbunden
    • Welche Annahmen werden getroffen
    • Welche Bedrohungen werden bewusst nicht behandelt
  • Da nicht alle zukünftigen Angriffe abgedeckt werden können, sollten ausgeschlossene Bedrohungen ausdrücklich benannt werden
  • Wenn Annahmen falsch sind, ist das Modell unvollständig, und auch die bereits akzeptierten Risiken müssen erneut überprüft werden
  • Ein Threat Model sollte kein Snapshot eines bestimmten Zeitpunkts sein, sondern ein lebendes Dokument, das bei Bedarf aktualisiert wird

Probleme, wenn Annahmen brechen

  • Der Invisible Salamanders attack kann bei einigen E2EE-Messaging-Designs die Missbrauchsmelde-Funktion kaputtmachen, wenn diese eingeführt wird
  • Dieser Angriff hängt mit den Annahmen von AEAD-Schemata wie AES-GCM oder ChaCha20-Poly1305 zusammen
    • Diese Schemata setzen voraus, dass es für eine bestimmte Nachricht nur einen gültigen Schlüssel gibt
    • Wenn man mehrere gültige Schlüssel für eine Nachricht einführt oder confused deputies erzeugt, verlässt man die Sicherheitsgarantien des Algorithmus
  • Das explizite Festhalten von Annahmen hilft dabei, die eigenen unknown unknowns zu identifizieren
  • Perfektion ist nicht nötig, aber die zugrunde liegenden Prämissen sollten klar sein

Vorgehen für den Einstieg ins Threat Modeling

  • Wer professionell Threat Modeling betreiben will, sollte das Threat Modeling Manifesto lesen
  • In der Praxis beginnt man damit, zuerst sieben Punkte in ein Format zu schreiben, das sich schnell kopieren und verwenden lässt
  • Danach zeichnet man die Komponenten des zu analysierenden Systems auf Papier oder in einem digitalen Tool
    • Wenn ein Widget mit einem anderen Widget direkt kommuniziert, davon abhängt oder anderweitig interagiert, wird diese Beziehung markiert
    • Die Art der Darstellung sollte diejenige sein, die für die arbeitende Person am nützlichsten ist
  • Anschließend umrahmt man den gesamten Graphen mit einem Kasten und verengt den Fokus schrittweise auf einzelne Komponenten
    • In jeder Iteration werden Eingaben und Ausgaben der Komponente notiert
    • Dabei sollten die sieben Fragen so weit wie möglich beantwortet werden
  • Danach geht man so tief ins Detail, wie es die Abstraktionsebene zulässt, und brainstormt anschließend, welche Annahmen für die Ebenen gelten, in die man nicht weiter hineingegangen ist
  • Eine Datenbank ist möglicherweise nicht in derselben Weise von der Sicherheit von X25519 abhängig wie ein Load Balancer
  • Unpassende Beziehungen, etwa wenn RSS-Feeds in einer Datenbank landen, sollten dokumentiert und nach Möglichkeit getrennt werden

Das Beispiel publickey.directory

  • Die Arbeit an Key Transparency für das Fediverse wird unter publickey.directory verfolgt
  • Diese Arbeit begann mit der Spezifikation public-key-directory-specification, die auch ein Threat Model enthält
  • Dieses Threat Model besteht aus den folgenden Abschnitten
    • Annahmen
    • Assets
    • Akteure und Rollennamen, einschließlich Angreifern und den zu schützenden Personen
    • Risiken und Risikostati
  • Die Risikostati sind in vier Kategorien unterteilt
    • Prevented by design: Der Angriff funktioniert aufgrund des Designs nicht
    • Mitigated: Wenn die Annahmen nicht falsch sind, sollte der Angriff keinen Erfolg haben
    • Addressable: Es gibt Möglichkeiten zur Minderung, aber sie erfordern Aufwand oder Aufmerksamkeit und Operatoren müssen Bescheid wissen
    • Open: Das Risiko kann nicht oder nicht beabsichtigt gemindert werden, und der betreffende Angriff ist erfolgreich
  • Auch dieses Threat Model ist nicht perfekt
    • Es verbindet die Beziehungen zwischen Assets und Akteuren nicht vollständig zu einem für Menschen leicht lesbaren Graphen
    • Im Risikoteil kann es blinde Flecken geben, die nicht berücksichtigt wurden
    • Es könnten Annahmen fehlen, die für die Systemsicherheit wichtig sind

Kontrast zwischen Matrix und Signal

  • Das Security Threat Model von Matrix v1.18 listet Angriffstypen wie Denial of Service, Spoofing, Spam und Spying auf
  • Dieses Dokument hat mehrere Probleme
    • Es ist eher eine Liste von Angriffstypen
    • Es gibt keine Liste von Annahmen
    • Es gibt keine Asset-Liste und keine Beziehungen zwischen Assets
    • Die Angriffsliste ist unvollständig
    • Obwohl Matrix als E2EE-Messenger vermarktet wird, behandelt das Threat Model weder Verschlüsselung noch Key Management
  • Das Threat Model von Matrix hat sich seit v1.1 nicht wesentlich verändert; in der Zwischenzeit gab es Offenlegungen von Schwachstellen und zwei weitere kryptografische Angriffe von Lotte
  • Trotzdem hat Matrix überhaupt ein Threat Model
  • Signal stellt technische Spezifikationen bereit, überlässt es den Nutzern aber, sich das Threat Model selbst zu erschließen
  • Selbst ein schlechtes Threat Model ist besser als gar kein Threat Model

Wie Threat Models das Design verbessern

  • In der Security-Praxis taucht oft die Maxime auf, dass Verteidiger immer richtig liegen müssen, während Angreifer nur einmal Erfolg brauchen
  • Wenn Verteidiger ausreichend vorbereitet sind, können sie das Gelände bestimmen, auf dem sich Angreifer bewegen
  • Echtes Defense-in-Depth bedeutet auch, das Threat Model so gut zu verstehen, dass Angreifer in vorhersehbare Sackgassen gedrängt werden

  • Schutz vor Credential Stuffing

    • Credential Stuffing ist ein einfacher Angriff, der in der Praxis übermäßig effektiv ist
    • Der Grund ist, dass Menschen Passwörter wiederverwenden
    • Weil es Nutzern schwerfällt, sich viele einzigartige und sichere Passwörter zu merken, waren Passwortmanager lange eine sinnvolle Gegenmaßnahme
    • Heute gelten Passkeys als die bessere Wahl
    • Passkeys sind eine benutzerfreundlichere Methode, Authentifizierung mit asymmetrischer Kryptografie durchzusetzen
    • Im Idealfall verwendet man Hardware-Sicherheitstoken wie SoloKeys oder YubiKeys
    • Im Durchschnittsfall werden sie vom Betriebssystem oder Passwortmanager bereitgestellt
    • Um Credential Stuffing und ähnliche einfache Angriffe zu vermeiden, sollte das Design Folgendes vorsehen
      • Die Anwendung ist so entworfen, dass sie Passkeys verlangt
      • Nutzer können mehrere Passkeys registrieren oder müssen zumindest einen Backup-Passkey hinterlegen
      • Für Nutzer, die alle Zugangsdaten verloren haben, gibt es einen Break-Glass-Pfad, über den ein Administrator einen neuen Passkey hinzufügen kann
      • Diese Admin-Aktion wird so protokolliert, dass Administratoren die Logs nicht zensieren können
      • Wenn möglich, werden Passwörter zur Authentifizierung gar nicht unterstützt
      • Passwörter zur Ableitung von Verschlüsselungsschlüsseln sind in einem separaten Kontext in Ordnung
    • Bei der Registrierung werden Passkey-Credentials kryptografisch an den Domainnamen gebunden, wodurch Phishing unmöglich wird
    • Selbst wenn Passkeys Onboarding-Kosten verursachen, können sie den Supportaufwand durch Credential Stuffing und Phishing noch stärker reduzieren
    • Wenn man die unrealistische Erwartung beseitigt, dass Menschen sich hochentropische Geheimnisse merken und nicht wiederverwenden sollen, verschwinden mehrere Angriffsklassen und die Usability verbessert sich
    • Zitiert wird Avi Douglens Satz: „Sicherheit auf Kosten der Usability opfert Sicherheit“

Dezentrales E2EE und Threat Modeling

  • Für E2EE bei Direktnachrichten werden zwei Vorschläge diskutiert
  • Beide Projekte ziehen oder zogen zu einem bestimmten Zeitpunkt in Betracht, MLS als Key-Management-Protokoll für E2EE-Konversationsschlüssel zu verwenden
  • In dezentralen Systemen hat MLS zwei wichtige Einschränkungen
    • MLS spezifiziert ein abstraktes Konzept namens Authentication Service
    • Für die Sicherheit des Ratcheting Tree, der die Epochs von MLS trägt, ist die Nachrichtenreihenfolge wichtig
  • Wenn ActivityPub zur Lösung der ersten Einschränkung Key Transparency einsetzt, muss es festlegen, wie konkurrierende KeyUpdate-Nachrichten über mehrere Server hinweg behandelt werden
  • Bei ATProto und BlueSky ist die Lage schwieriger
    • ATProto hat keine Instanzen wie das Fediverse
    • In der Sicherheitsanalyse muss es fast wie P2P behandelt werden
    • Um Nachrichtenreihenfolge in einem verteilten System zu garantieren, könnte ein komplexes Protokoll nötig sein, etwa ein Ansatz wie der Raft consensus algorithm
    • Oder man überspringt MLS und setzt auf paarweises E2EE, wobei man die Gruppenabstraktion aufgibt
  • Wenn Vertraulichkeit von Nachrichten zwischen Nutzern das Sicherheitsziel ist und das Hosting dezentral sein soll, wird das blockchainartige Design von ATProto zu einem Hindernis für den Einsatz heutiger standardisierter effizienter Protokolle zur Gruppenschlüsselvereinbarung
  • Threat Modeling kann solche Designbeschränkungen schon in einer frühen Entwurfsphase sichtbar machen

Die Rolle von Threat Modeling in der PQC-Debatte

  • Im Zusammenhang mit hybrid post-quantum constructions läuft auf der Mailingliste der IETF-TLS-Working-Group eine RFC-Diskussion darüber, Code Points für nicht-hybrides ML-KEM zu etablieren
  • Die Debatte basiert auf folgenden Prämissen
    • ML-KEM ist kein NSA-Design
    • Haupteinreicher ist Peter Schwabe, der mit Daniel J. Bernstein und an der Kryptobibliothek NaCl gearbeitet hat und in Deutschland lebt
    • Weitere Einreicher stammen aus verschiedenen Teilen Europas
    • Informationstheorie schließt, wie etwa im Text von Sophie Schmieg, eine Hintertür in ML-KEM aus
    • ML-KEM wurde in einem offenen, zehn Jahre laufenden internationalen Standardisierungsprozess von NIST ausgewählt
    • NIST, FIPS und NSA verlangen für vertrauliche Systeme nicht-hybrides ML-KEM und ML-DSA
  • Der betreffende IETF-Entwurf spezifiziert nicht-hybrides ML-KEM und markiert es mit Recommend=N
  • Das Hybrid-KEM-RFC soll mit Recommend=Y markiert werden, sodass Hybrid-KEM gegenüber nicht-hybridem KEM bevorzugt wird
  • Systeme, die immer Hybrid-KEM verwenden, erleiden auch dann keine Verschlechterung der Sicherheit, wenn das ML-KEM-RFC erscheint
  • Google Chrome unterstützt bereits nicht-hybrides ML-KEM, und daran ändert sich nichts, auch wenn kein IETF-RFC erscheint
  • Der praktische Effekt dieses RFC besteht darin, prozedurale Einschränkungen für Organisationen zu beseitigen, die CNSA 2.0, FIPS 140-3 oder ähnliche Regeln befolgen müssen und dafür eine stabile IETF-RFC-Nummer statt eines Internet-Drafts benötigen
  • Das dürfte besonders in einigen Geschäftsbereichen häufig sein, die an staatliche Kunden verkaufen

  • Unterschied zwischen Hybrid PQ+ECDH und Pure PQ

    • Das Risiko bei KEMs ist nicht „Kryptografie nach dem Q-Day brechen“, sondern Harvest Now, Decrypt Later
    • Q-Day dient als Kurzbezeichnung für den Zeitpunkt, zu dem Angreifer einen kryptografisch relevanten Quantencomputer besitzen
    • Aufgeschlüsselt ergibt sich folgendes Risikobild
      • Reines ECDH, also ohne PQ, wird am Q-Day rückwirkend gebrochen
      • Reines PQ wird am Q-Day nicht gebrochen, sofern der PQ-Algorithmus nicht schon vorher zusammenbricht
      • Hybrid PQ+ECDH ist eine Absicherung gegen einen vorzeitigen Zusammenbruch von Algorithmen, bringt aber nach dem Q-Day gegenüber Pure PQ keinen Vorteil mehr
    • Wer ECDH + ML-KEM fordert, räumt damit langfristig bereits ein, dass ML-KEM ein sicherer Algorithmus ist
    • Es gibt im Wesentlichen zwei Gründe, Hybrid zu bevorzugen
      • Es ist leichter zu akzeptieren als ein völlig unbekannter Algorithmus und beschleunigt damit die PQ-Einführung
      • Es kann gegen einen algorithmischen Zusammenbruch von ML-KEM oder der gesamten Gitterkryptografie absichern
    • Wer auch gegen Quantencomputer mit kryptografischer Relevanz hedgen will, braucht ein PQ+PQ-Hybrid
    • Wenn algorithmische Diversität das Ziel ist, wäre ein 3-Wege-Hybrid aus ML-KEM + HQC + ECDH die ehrlichere Behauptung
    • ML-KEM ist ein gitterbasiertes KEM und gilt als widerstandsfähig gegen Quantenangriffe
    • HQC ist ein codebasiertes KEM und gilt als widerstandsfähig gegen Quantenangriffe
    • ECDH ist das heute übliche Verfahren, aber anfällig für Quantenangriffe
    • Threat Modeling kann in solchen Debatten helfen, ideologischen Widerstand von technischem Risiko zu trennen

Fazit

  • Im Internet gibt es viele Leitfäden, die Threat Models und zugehörige Methoden formal behandeln
  • Das Ziel hier ist, einen Smoke-Test zu haben, mit dem sich Qualität und Wirksamkeit eines Threat-Model-Dokuments schnell beurteilen lassen
  • Ein gutes Threat Model sollte über Schutzgüter, Angreifer, Angriffswege und Gegenmaßnahmen hinaus auch Asset-Beziehungen, Annahmen und akzeptierte Risiken offenlegen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Kommentare auf Lobste.rs
  • Ich wollte ihn schon loben, weil ich dachte, er hätte diesmal ausnahmsweise einen Blogpost ohne arroganten und unangenehmen Ton geschrieben, aber am Ende kam ich doch zu dem in diesem Blog üblichen Abschnitt mit Matrix-Kritik.
    „Unfreundlichkeit“ ist ein gültiger Grund, Kommentare zu melden; wenn wir das technische Internet besser machen wollen, sollten wir vielleicht aufhören, den aggressiven Ton zu konsumieren und weiterzuempfehlen, den dieser Autor in seinem Blog viel zu oft verwendet. Man könnte sogar erwägen, die Domain ganz zu sperren.
    • Es war eine ziemlich vernünftige Kritik, die alle kritisierten Formulierungen vollständig zitiert und substanzielle Gegenargumente geliefert hat. Ich halte sie für ein deutlich besseres Beispiel als die meisten Kritiken.
    • Das ist Verachtungskultur: https://blog.aurynn.com/2015/12/16-contempt-culture
    • Ich weiß nicht, wie es zusammenpasst, jemanden einen „arroganten, unangenehmen Idioten“ zu nennen und gleichzeitig zu fordern, ihn wegen Unfreundlichkeit zu sperren. Man sollte die Veränderung, die man sehen möchte, selbst vorleben.
    • Ich finde den Ton in Ordnung.
      Und ich denke, ein Protokoll, bei dem „alles ein Graph“ ist, sollte tatsächlich wie ein Forschungsprojekt behandelt werden. Das Fazit war gewissermaßen: „Oh je, Graphalgorithmen sind in der Praxis wirklich schwer zu durchdenken.“