Die verifizierte Siegelfalle: Fehlsignaturen bedrohen die Einzigartigkeit der Hash in Gits Verpflichtungen

Eine neue Forschungsarbeit von Jacob Ginesin (PhD in Carnegie Mellon und kryptografischer Auditor in Cure53) stellt eine erweiterte Annahme dar: Eine unterzeichnete Bestätigung (Mitteilung) in Git ist an sich ein einzigartiger und unveränderlicher Name für seinen Inhalt. Die Technik bricht SHA-1 oder SHA-256 nicht oder ändert den Code; es nutzt die Fehlfunktion der Unterschriften- verschiedene und gültige Weisen, um die gleiche Signatur zu repräsentieren - um die Signaturbytes neu zu schreiben, die im Commit-Objekt enthalten sind, so ändern Sie ihre Hash ohne berührende Dateien, Autor oder Datum. Ginesin dokumentiert drei konkrete Vektoren (ECDSA, RSA / EdDSA mit nicht authentifizierten OpenPGP-Feldern und S / MIME mit nicht-canonic DER encoding) und begleitet seine Studie mit Testwerkzeugen und Demo-Repositorien, die zeigen, wie GitHub nach diesen Mutationen das "Verified"-Siegel weiter ausdruckt.

Die Wurzel des Problems ist nicht Git oder die Menschen, die unterschreiben, aber wie die Forges konsumieren und der Unterschrift vertrauen: GitHub und andere Dienstleistungen normalisieren die Unterschriften nicht, bevor sie überprüft werden und ordnen Sie das verifizierte Siegel dem genauen Hash des empfangenen Objekts zu. Dies ermöglicht praktische Betriebsszenarien: die Blockierung eines Commits durch seine Hash hinterlässt ein Loch - ein Angreifer kann die gleiche Bestätigung mit neu codierten Signaturen unter einem anderen Hash und dennoch, um es als verifiziert zu sehen -; Redoubling-Systeme, Block-Listen und Quellbitals, die nur die Hash verwenden, wird die gleiche Fragonilität erben; ein kompromittierter Spiegel kann gültig signiert Bestätigungen, deren daher seine Darstellung in Bytes.

Es ist wichtig, zu betonen, was dies nicht ist: Es ist keine Tür, den Inhalt zu ändern, ohne dass die Unterschrift ihn erkennt. Der Filminhalt von Blobs und Bäumen bleibt identisch, und das Einklemmen eines kompletten Hash, um Code zu erhalten, sorgt weiterhin dafür, dass Sie genau erhalten, was Hash entspricht oder nicht downloaden. Das Problem ist semantisch und betriebsbereit: das "Verified"-Siegel garantiert nicht, dass die Hash ein einzigartiger und unveränderlicher Name des unterzeichneten Objekts ist Und viele Tools vertrauen dieser falschen Garantie.

Die praktische Lehre erinnert an einen bekannten Präzedenzfall in der angewandten Kryptographie: Bitcoin stolperte auf eine Symmetrie der ECDSA, die erlaubt, den Wert s um n - s zu ändern und die Transaktions-ID ohne den privaten Schlüssel zu ändern; die Lösung bestand darin, eine kanonische Form ("low-S") aufzuzwingen und in einem architektonischen Wandel Unterschriften von der Identifikation mit SegWit zu trennen. Die entsprechende Empfehlung für Forges ist offensichtlich und technisch: die Darstellung der Signaturen vor der Überprüfung und vor der Registrierung eines Vertrauenssiegels. In der Praxis bedeutet dies, nur kanonische Formen (z.B. Low-S für ECDSA) zu akzeptieren, OpenPGP nicht authentifizierte Felder zu entfernen oder zu normalisieren und DER Codierung in S / MIME zu validieren / normalisieren.

Was soll jeder Schauspieler tun? Zum Schmieden (GitHub, GitLab, etc.) ist die Aktion klar und dringend: normalisieren Sie die Unterschriften, bevor Sie sie als verifiziert, speichern und überprüfen Sie die kanonisierte Form und ungültigen Stempel, wenn die Signatur oder der Schlüssel nicht mehr kanonisch oder widerrufen ist. Bei Werkzeugen, die durch Hash-, Deduplizier- oder Compute-Rückverfolgbarkeit blockieren, ist die Empfehlung nicht auf den groben Hash eines eingehenden signierten Objekts zu vertrauen: die Signatur überprüfen, sie können und dann die Kennung berechnen, die sie für Schloss oder Log verwenden, oder alternativ die Deduplizierung auf Content-Tracks (Tree / Blobs) anstelle der Hash des kompletten Commit-Objekts.

Für Entwickler und Verbraucher von Paketen oder Aktionen ist die gute Nachricht, dass die besten Praktiken nicht Wurzel ändern: weiterhin vollständige Verpflichtungen zu lackieren ist richtig, und Verankerung auch Chemikalien unabhängig von den Artefakten oder verwenden Systeme, die Inhalte überprüfen (z.B. feste Ausgangsableitungen in Nix) fügt eine Sicherung, die ganze Arten von Problemen vermeidet. Allerdings gibt es eine Anpassung an die Überwachung: Das "verifizierte" Siegel sollte nicht als einziges Sicherheitskriterium zur Annahme oder Blockierung von Code verwendet werden; das Siegel zeigt, wer unterzeichnet hat, nicht dass Hash eine einzigartige und unbändige Identität ist.

Ginesins Arbeit wurde an relevante Projekte (Git, GNU und Forges) berichtet und zumindest zum Zeitpunkt seiner Veröffentlichung erwartete er immer noch einen Spread-Patch. Die Gemeinschaft hat reife konzeptionelle Arrangements: Die kanonizierende Signatur ist eine bekannte und gut verstandene Praxis. Der erste offensichtliche Punkt der Aufmerksamkeit ist S / MIME, wo das öffentliche Werkzeug reproduziert Fälle, die strenge lokale Git ablehnen, aber GitHub akzeptiert als "Verified".

Kurz gesagt, wir sind mit einem Problem des betrieblichen Vertrauens konfrontiert, nicht der Inhalt Integrität: Die Gabeln müssen ihre Überprüfung Pipeline korrigieren, so dass die "Verified" Band wirklich bedeutet, was Nutzer erwarten. In der Zwischenzeit sollten Sicherheits- und Versorgungsinfrastrukturmanager ihre Sperr- und Deduplizierlogik aktualisieren, um Signaturen zu validieren und zu kanonisieren, bevor sie auf Hash angewiesen werden, und Entwickler sollten weiterhin Einheiten mit kompletter Hashe und, soweit möglich, mit zusätzlichen Prüfsummen und reproduzierbaren Geräteverifikationsmechanismen verankern.

Um die von Ginesin veröffentlichten Arbeiten und Tests zu lesen, können Sie ihre Liste in arXiv sehen und die Demos abspielen; die Autorsuche bietet das Dokument und die dazugehörigen Materialien offen an: arXiv - Suche von Jacob Ginesin. Um zu verstehen, wie GitHub die Überprüfung von Unterschriften in Verpflichtungen vorlegt und dokumentiert, ist seine offizielle Dokumentationsseite ein nützlicher Bezugspunkt: GitHub Docs - Über die Unterschriftsprüfung. Um vor Ort nach Verpflichtungssignaturen zu überprüfen und zu sehen, wie git die Verifikation übernimmt, ist die Git-Dokumentation auf git-verify-commit praktisch: git-verify-commit.