it-swarm.com.de

Warum werden nicht kollisionssichere Hash-Funktionen als unsicher angesehen, um selbst generierte Informationen zu signieren?

Lassen Sie uns eine Hash-Funktion haben, die zweitens vorbildlich, aber nicht kollisionssicher ist.

Dann kann ein Gegner ein Paar verschiedener Nachrichten M und M 'erstellen, M ist gutartig und M' ist bösartig, für beide ist die Signatur gültig.

Ich verstehe nicht, warum dies ein Problem in der Einstellung ist, in der Signaturen zur Authentifizierung des Ursprungs von Daten verwendet werden, die von derselben Entität erstellt wurden. Wenn man also eine Software signiert, behauptet er, "Ich habe diesen Inhalt selbst erstellt, wenn er Malware enthält, beschuldige mich". Und für Schlüssel: "Dieser öffentliche Schlüssel hat einen entsprechenden privaten Schlüssel, ich habe Zugriff darauf".

Wenn man eine Kollision herstellt und selbst generierte Daten signiert ... behauptet er immer noch die obigen Aussagen.

Sollten solche Hash-Funktionen für Dinge wie selbstsignierte Zertifikate und Codesignatur als sicher angesehen werden?

5
KOLANICH

Digitale Signaturen dienen drei Aufgaben:

  1. Stellen Sie die Integrität der signierten Daten sicher
  2. Erstellen Sie ein gewisses Maß an Nicht-Zurückweisung durch den Unterzeichner
  3. Der von Ihnen erwähnte Zweck ist die Authentifizierung des Ursprungs der Nachricht

Das größte Problem bei Hash-Funktionen, die für Kollisionen anfällig sind, besteht darin, dass Sie das erste Entwurfsziel sehr schnell verlieren. Wenn zwei verschiedene Nachrichten dieselbe Signatur haben können, können Sie nicht wissen, welche echt sind.

Was ist die große Sache, wenn ich zwei verschiedene Nachrichten mit derselben Signatur signieren kann? Sie wissen immer noch, dass beide von mir kamen und mich zur Rechenschaft ziehen können, oder? Na ja, vielleicht. Es gibt sicherlich einige Fälle, in denen dies missbraucht werden kann, aber wir werden sie ignorieren, weil sie nicht das eigentliche Problem sind. Das eigentliche Problem besteht darin, dass Sie zwei Nachrichten mit derselben Signatur erstellen und eine davon senden können, damit jemand anderes signiert.

Das kanonische Beispiel hier ist eine x.509 (SSL/TLS) -Zertifikatanforderung . In diesem Fall kann ein schlecht gestalteter Zertifikatsignierungsprozess genutzt werden, um eine Zertifizierungsstelle zu veranlassen, ein Zertifikat für einen Betreff oder mit einer Reihe von Eigenschaften (wie ein Endentitätszertifikat) zu signieren, nur damit die Signatur mit der Signatur für kollidiert Ein zweites Zertifikat, das ebenfalls von den Angreifern generiert wurde, dass würde nicht für ein Thema ausgestellt wurde, das die Angreifer nicht kontrollieren, oder für ein CA-Zertifikat, und dieses Rogue-Zertifikat kann jetzt von dem vollkommen gültigen Zertifikat profitieren Unterschrift mit dem ersten gutartigen Zertifikat.

15
Xander

Xanders Antwort ist grundsätzlich richtig: Das Problem besteht darin, dass jemand anderes eine harmlose Nachricht signiert und die Signatur für die böswillige verwendet. Es ist erwähnenswert, dass Sie sich bei einer Kollision zwar nicht direkt für die Nachrichten entscheiden können, sich jedoch häufig für einen Teil der Nachricht entscheiden müssen. Zum Beispiel konnte ich Sie nicht überreden, "Mein Name ist KOLANICH" zu unterschreiben und gegen "Mein Name ist Josiah" zu tauschen: Es ist unwahrscheinlich, dass die Hashes übereinstimmen. Möglicherweise kann ich Sie jedoch dazu bringen, zu unterschreiben: "Bitte zahlen Sie die Kontonummer X $ 50 für Schuhe mit dem Referenzcode ZZZZZZZZZ." und ersetzen Sie es dann durch "Bitte zahlen Sie die Kontonummer X $ 50000 mit dem Referenzcode JJJJJJJJJ." In diesem Szenario wähle ich das Y und Z aus, das ich für die Kollision benötige.

Ein weiterer Grund, warum sie als unsicher gelten, ist ein Kanarienvogel in einer Kohleminen-Situation. Es ist einfacher, eine Kollision zu finden, als ein zweites Vorbild. Genau genommen, denn wenn Sie einen zweiten Preimage-Angriff hatten, haben Sie automatisch eine Kollision, aber nicht umgekehrt. Obwohl eine Technik zum Auffinden einer Kollision keine direkten Vorbilder liefert, deutet dies darauf hin, dass die Hash-Funktion eine gewisse Regelmäßigkeit aufweist, die Schwachstellen aufdeckt, die bei weiteren Untersuchungen das Auffinden von Vorbildern ermöglichen würden.

12
Josiah

Theoretisch hätten Sie recht. In einige sehr spezielle Fälle würden diese Hashes nicht vollständig gebrochen.

Sie müssten jedoch besonders vorsichtig sein, und angeblich könnten einige "selbst generierte" Daten tatsächlich unsicher sein. Würden Sie die vom Buchhalter ausgestellten Schecks als vom Buchhalter selbst erstellt betrachten? Anscheinend ja, aber es enthält tatsächlich extern gesteuerte Daten, mit denen eine Signatur eines anderen Inhalts erstellt werden kann.

Sollten solche Hash-Funktionen für Dinge wie selbstsignierte Zertifikate und Codesignatur als sicher angesehen werden?

Sie überprüfen selbstsignierte Zertifikate nicht wirklich, sodass Sie die verwendete Hash-Funktion ignorieren können.

Andererseits würde ich es nicht als sicher für die Codesignatur betrachten. Sie verwenden wahrscheinlich externe Bibliotheken, sodass ein Dritter möglicherweise eine Bibliothek vorbereitet hat, die es beim Kompilieren ermöglicht, einen Codeblock durch einen böswilligen zu ersetzen, der mit ihm kollidiert.

Bitte beachten Sie, dass in einigen bestimmten Fällen ein "defekter Hash" möglicherweise funktioniert, da wir über einwandfreie, nicht defekte Hash-Funktionen verfügen, für die keine so sorgfältigen Details erforderlich sind. Es ist jedoch viel besser, diese nach Möglichkeit zu verwenden.

Und schließlich denken Sie daran, dass Angriffe mit der Zeit immer schlimmer werden. Der Sicherheitsspielraum dieser Funktion ist viel größer als bei kollisionssicheren. Ein Angriff, der eines Tages nicht durchführbar schien, oder eine Hash-Funktion, die "nur" nicht kollisionssicher und nicht allzu lange danach war, kann durch eine neue Entdeckung weiter unterbrochen werden, sodass Sie sie sehr schnell ändern müssen.

5
Ángel