Sollten UDP-Datennutzdaten eine CRC enthalten?

Für ein Unternehmen, für das ich früher gearbeitet habe, musste ich einen Socket-Empfänger implementieren, der Daten in UDP-Form über eine lokale Verbindung von einer speziellen Sensor-Hardware abnahm. Die fraglichen Daten waren wohlgeformte UDP-Pakete, aber interessanterweise endete die Datennutzlast immer mit einer CRC16-Prüfsumme, die unter Verwendung der restlichen Daten gebildet wurde.

Ich habe die Prüfung an meinem Ende gemäß der Spezifikation durchgeführt, aber ich habe mich immer gefragt, ob dies notwendig ist. Ist das UDP-Protokoll nicht selbst mit einem 16-Bit-CRC ausgestattet? Obwohl UDP-Pakete verloren gehen oder nicht in der richtigen Reihenfolge vorliegen können, hatte ich den Eindruck, dass sie nicht beschädigt werden können, ohne von der Netzwerkhardware verworfen zu werden, bevor sie die Prozesse des Betriebssystems erreichen. Oder gibt es einen speziellen Anwendungsfall, den ich vermisse?

Es ist erwähnenswert, dass ich in der Rüstungsindustrie gearbeitet habe, was, wie Sie sich sicher vorstellen können, in all diesen Dingen sehr explizit ist. Daher frage ich mich, ob es sich nur um eine "Sicherheits-OCD" handelte. ..

security networking data-integrity

— Xenoprimate
quelle

Wenn es nicht nur um die Verhinderung versehentlicher Korruption geht, sondern auch um Sicherheitszwecke, müssen Sie einen MAC verwenden, der dem verschlüsselten Äquivalent einer Prüfsumme entspricht.

— CodesInChaos

Die UDP-Prüfsumme gilt nur für die Daten, die in das UDP-Paket eingespeist wurden. Was schafft eigentlich die Prüfsumme? Was nutzt die Prüfsumme? Wird es verwendet, um die Integrität sicherzustellen, bevor das UDP-Paket erstellt oder möglicherweise zusammen mit dem Paket übertragen wird, um sicherzustellen, dass die Integrität aufrechterhalten wird, während es durch andere Systeme fließt? Ohne ein umfassenderes Verständnis der Komponenten Ihres Systems und der Art und Weise, wie die Daten erstellt, transformiert und verwendet werden, bin ich mir nicht sicher, ob Ihre Frage beantwortet werden kann.

— Thomas Owens

@ThomasOwens Die Daten wurden vom Ursprungsgerät direkt an die empfangende Hardware gesendet. Keine Mittelsmänner. Die Prüfsumme wurde vom Absender als letzter Schritt vor dem Senden erstellt.

— Xenoprimate

Antworten:

Das UDP - Protokoll garantiert nicht , dass Nachrichten, um geliefert werden oder gar nicht bereitgestellt, aber es ist sicher , dass diese Botschaften , die sie geliefert bekommen vollständig und unverändert bleiben , indem sie automatisch ein 16-Bit - Prüfsumme enthalten. Das bedeutet, dass das Hinzufügen einer weiteren 16-Bit-Prüfsumme auf der Anwendungsschicht normalerweise redundant ist.

...in der Regel....

Erstens ist bei IPv4 (nicht IPv6) die Prüfsumme optional . Das bedeutet, dass Sie möglicherweise eine exotische Konfiguration verwenden, die keine Prüfsummengenerierung und -validierung durchführt (in diesem Fall sollten Sie jedoch lieber den Netzwerkstapel reparieren, anstatt ihn auf der Anwendungsebene zu manipulieren).

Zweitens besteht bei einer 16-Bit-Prüfsumme eine Wahrscheinlichkeit von eins zu 65536, dass eine vollständig zufällige Nachricht eine gültige Prüfsumme aufweist. Wenn diese Fehlerspanne für Ihren Anwendungsfall zu groß ist (und in der Verteidigungsindustrie könnte ich mir mehrere vorstellen, wo sie sich befindet), würde sie durch Hinzufügen einer weiteren CRC-16-Prüfsumme weiter verringert. In diesem Fall sollten Sie jedoch einen korrekten Message Digest wie SHA-256 anstelle von CRC-16 verwenden. Oder gehen Sie den ganzen Weg und verwenden Sie eine echte kryptografische Signatur. Dies schützt nicht nur vor zufälliger Beschädigung, sondern auch vorsätzlicher Beschädigung durch einen Angreifer.

Drittens, je nachdem, woher die Daten stammen und wohin sie gehen, können sie vor oder nach dem Senden über das Netzwerk beschädigt werden. In diesem Fall schützt die zusätzliche Prüfsumme in der Nachricht möglicherweise die Integrität der Nachricht weiter als nur zwischen den beiden Netzwerkhosts.

— Philipp
quelle

Warum kryptografisch ? Die beim Entwerfen von kryptografischen Hashes verwendeten Einschränkungen stimmen nicht mit denen überein, die beim Entwerfen eines bei der Übertragung verwendeten Hashes verwendet werden (Ressourcenintensität ist beispielsweise ein Merkmal für kryptografische Hashes und Probleme bei der Übertragung).

— AProgrammer

@AProgrammer Ich gebe zu, dass die Wortwahl irreführend gewesen sein könnte. Ich habe es durch "richtigen Nachrichtenüberblick" ersetzt. Message Digest-Funktionen sind viel länger und machen versehentliche Kollisionen so unwahrscheinlich, dass sie aus praktischen Gründen als unmöglich angesehen werden können.

— Philipp

Es wird versucht sicherzustellen, dass die Nachrichten unverändert sind, aber die in UDP verwendete Prüfsumme ist eher schwach. Während die Wahrscheinlichkeit, dass eine Zufallsnachricht eine gültige Prüfsumme aufweist, für alle 16-Bit-Prüfsummen tatsächlich 1 zu 65536 beträgt, umfassen die nützlicheren Maßnahmen eine feststellbare Anzahl von Bitflips, die entweder zufällig oder in einem Burst angeordnet sind, und nicht alle Prüfsummen sind entsprechend gleich diese Metrik.

— Ben Voigt

@AProgrammer Kryptografische Hashes (MD5, SHA-1/2/3, ...) zielen darauf ab, so billig wie möglich zu sein und gleichzeitig Sicherheitseigenschaften wie Kollisionssicherheit zu gewährleisten. Normalerweise können sie mehrere hundert MB pro Sekunde verarbeiten, sodass sie kein Engpass für alles sein sollten, was weniger als Gbit-Verbindungen sind. Sie sind immer noch langsamer als viele nicht kryptografische, die keine Kollisionssicherheit erfordern. Nur Passwort- Hashes (PBKDF2, bcrypt, scrypt, Argon, ...) sind teuer in der Berechnung.

— CodesInChaos

UDP bietet jedoch eine Prüfsumme.

Die UDP-Prüfsumme beträgt nur 16 Bit. Dies bedeutet eine 1: 65536-Wahrscheinlichkeit, dass ein beschädigtes Paket die Prüfsumme passiert.
Bei UDP über IPv4 ist die Prüfsumme optional, sodass ein Absender theoretisch ein Paket ohne Prüfsumme senden könnte.
Die Prüfsumme umfasst die IP / Port-Informationen sowie die Daten. Dies ist zwar beim Löschen von Paketen mit beschädigten Adressen hilfreich, bedeutet jedoch, dass die Prüfsumme vom NAT neu berechnet werden muss, wenn das Paket ein NAT durchläuft.
Die Prüfsumme schützt die Daten nur, während sie im UDP-Paket übertragen werden. Eine Prüfsumme auf Anwendungsebene kann die Daten von Ende zu Ende schützen, wenn sie ein komplexeres System durchlaufen.
Die UDP-Prüfsumme gibt nur klar an, dass das Paket von einer UDP-Implementierung generiert wurde. Es sagt Ihnen nicht, dass es von Ihrem Sensor kam. Andererseits kann eine Prüfsumme auf Anwendungsebene dabei helfen, Pakete abzulehnen, die gültiges UDP sind, aber von einer anderen Quelle stammen.

Ich kann also berechtigte Gründe dafür erkennen, dass ich der UDP-Prüfsumme nicht vertraue, aber auch der UDP-Prüfsumme nicht und dann eine ähnlich schwache Prüfsumme auf Anwendungsebene implementiere.

Es besteht die Möglichkeit, dass die Person, die das Protokoll erstellt hat, einfach nicht weiß, dass UDP Prüfsummen bereitstellt, oder dass das Protokoll tatsächlich eine geringfügige Variante von einem ist, das für die Ausführung auf einem Medium ohne Prüfsummen ausgelegt ist.

PS, da dieser Beitrag mit Sicherheit gekennzeichnet ist, beachten Sie, dass die fraglichen Prüfsummen zum Schutz vor versehentlichen Änderungen vorgesehen sind. Der Schutz vor absichtlicher Änderung oder Fälschung erfordert sowohl die Verwendung kryptografischer Hash-Funktionen, die gegen absichtliche Kollisionen / Vorimages resistent sind, als auch die Verwendung einiger Mechanismen (z. B. Signaturen, die mit einem öffentlichen Schlüssel erstellt wurden), um zu überprüfen, ob die Hashes selbst nicht geändert wurden.

— Peter Green
quelle