UDPデータペイロードにCRCを含める必要がありますか？

私が働いていた会社の場合、ソケットレシーバーを実装する必要がありました。ソケットレシーバーのほとんどは、特殊なセンサーハードウェアからローカル接続を介してUDP形式でデータを取得していました。問題のデータは整形式のUDPパケットでしたが、興味深いことに、データペイロードは常に残りのデータを使用して形成されたCRC16チェックサムで終了しました。

私は仕様に従ってチェックを実装しましたが、これが必要かどうかはいつも疑問でした。結局のところ、UDPプロトコル自体は16ビットCRCを伝送していませんか？したがって、UDPパケットは失われたり順序が乱れたりする可能性がありますが、OSのプロセスに到達する前にネットワークハードウェアによって破棄されることなく破損することはできないという印象を受けました。または、私が見逃している特別なユースケースがありますか？

私が防衛産業で働いていたことは付け加えておく価値があります。想像できると思いますが、これはこのようなことすべてについて超明示的であることが好きなので、単なる「セキュリティOCD」のケースであったのかと思います。 ..

security networking data-integrity

— 異種霊長類
ソース

偶発的な破損を防止するだけでなく、セキュリティを目的とする場合は、MACを使用する必要があります。これは、チェックサムと同等のキー付きです。

— CodesInChaos

UDPチェックサムは、UDPパケットに挿入されたデータに対してのみ有効です。実際にチェックサムを作成するのは何ですか？チェックサムを使用するのは何ですか？UDPパケットが作成される前に整合性を確保するために使用されますか、またはパケットと一緒に運ばれて、他のシステムを通過するときに整合性を維持するようにしますか？システムのコンポーネント、およびデータの作成、変換、使用方法に関する幅広い理解がなければ、あなたの質問に答えられるかどうかわかりません。

— トーマスオーエンズ

@ThomasOwensデータは、発信元デバイスから受信ハードウェアに連続して送信されました。中間者はいません。チェックサムは、送信する前の最後のステップとして発信者によって作成されました。

— ゼノ霊長類

回答:

UDPプロトコルは、メッセージが順番に送達されるか、またはすべてで配信されることを保証するものではありませんが、それは、これらのメッセージことを確認するんです配信を受けるには、自動的に16ビットのチェックサムを含めることにより、完全かつ不変です。つまり、アプリケーション層に別の16ビットチェックサムを追加することは通常冗長です。

...通常....

まず、IPv4（IPv6ではない）では、チェックサムはオプションです。つまり、チェックサムの生成と検証を行わないエキゾチックな構成を使用している可能性があります（ただし、その場合は、アプリケーションレイヤーでこれをon索するのではなく、ネットワークスタックを修正する必要があります）。

次に、16ビットチェックサムでは、65536分の1の確率で、完全にランダムなメッセージに有効なチェックサムが含まれる可能性があります。この許容誤差がユースケースに対して大きすぎる場合（そして、防衛産業ではいくつかの場所にあると想像できます）、別のCRC-16チェックサムを追加するとさらに減少します。ただし、その場合は、CRC-16の代わりにSHA-256などの適切なメッセージダイジェストを使用することを検討してください。または、最後まで実際の暗号署名を使用します。これにより、ランダムな破損だけでなく、攻撃者による意図的な破損からも保護されます。

第三に、データの送信元と送信先に応じて、ネットワーク経由で送信される前または後に破損する可能性があります。その場合、メッセージ内の追加のチェックサムは、2つのネットワークホスト間だけでなく、メッセージの整合性をさらに保護する可能性があります。

— フィリップ
ソース

なぜ暗号化？暗号化ハッシュの設計に使用される制約は、送信に使用されるハッシュの設計に使用される制約と同じではありません（たとえば、リソースを集中的に使用することは、暗号化ハッシュの機能であり、送信に問題があります）。

— AProgrammer

@AProgrammer言葉の選択は誤解を招くかもしれないと認めます。「適切なメッセージダイジェスト」に置き換えました。メッセージダイジェスト関数ははるかに長いため、偶発的な衝突が発生する可能性が低いため、実際の目的では不可能と見なすことができます。

— フィリップ

それはしようとしたメッセージが変更されていないことを保証するために、しかし、UDPで使用されるチェックサムはかなり弱いです。有効なチェックサムを持つランダムメッセージの確率は、実際にはすべての16ビットチェックサムに対して65536分の1ですが、より有用な測定値は、ランダムまたはバーストのいずれかに配置された検出可能な数のビットフリップを含み、すべてのチェックサムはこのメトリック。

— ベンフォークト

@AProgrammer暗号化ハッシュ（MD5、SHA-1 / 2/3、...）は、衝突抵抗などのセキュリティプロパティを確保しながら、できるだけ安価になることを目指しています。通常、1秒間に数百MBを処理できるため、Gbit接続よりも小さいもののボトルネックになることはありません。それらは、衝突抵抗である必要のない多くの非暗号化のものよりもまだ遅いです。パスワードハッシュ（PBKDF2、bcrypt、scrypt、Argon、...）のみが計算コストが高いことを目指しています。

— CodesInChaos

ただし、UDPはチェックサムを提供します。

UDPチェックサムは16ビットのみです。つまり、破損したパケットがチェックサムを通過する確率は65536分の1です。
UDP over IPv4ではチェックサムはオプションであるため、送信者は理論的にはチェックサムなしでパケットを送信することになります。
チェックサムは、IP /ポート情報とデータをカバーします。これは、破損したアドレスを持つパケットをドロップするのに役立ちますが、パケットがNATを通過する場合、チェックサムをNATで再計算する必要があることを意味します。
チェックサムは、UDPパケットで送信されるデータのみを保護します。アプリケーションレベルのチェックサムは、データがより複雑なシステムを通過するときに、エンドツーエンドでデータを保護できます。
UDPチェックサムは、パケットがUDP実装によって生成されたことのみをわかりやすく伝えます。それはあなたのセンサーから来たことを教えてくれません。一方、アプリケーションレベルのチェックサムは、有効なUDPであるが他のソースからのパケットを拒否するのに役立つ場合があります。

したがって、UDPチェックサムを信頼しないが、UDPチェックサムを同様に信頼せず、アプリケーションレベルで同様に弱いチェックサムを実装する正当な理由を見ることができます。

プロトコルを設計している人は、UDPがチェックサムを提供したこと、またはプロトコルが実際にチェックサムを提供しない媒体上で実行するように設計されたプロトコルのわずかな変形であるということを知らなかった可能性があります。

PSこの投稿にはセキュリティがタグ付けされているため、問題のチェックサムは不注意による変更から保護するように設計されていることに注意してください。意図的な変更またはスプーフィングから保護するには、意図的な衝突/プリイメージに耐性のある暗号化ハッシュ関数の使用と、ハッシュ自体が変更されていないことを検証するためのメカニズム（公開鍵を使用して作成された署名など）の両方が必要です。

— ピーター・グリーン
ソース