Les charges utiles de données UDP doivent-elles inclure un CRC?

Pour une entreprise pour laquelle je travaillais auparavant, j'ai dû implémenter un récepteur de socket qui prenait principalement des données sous forme UDP via une connexion locale à partir d'un matériel de capteur spécialisé. Les données en question étaient un paquet UDP bien formé, mais il est intéressant de noter que la charge utile des données se terminait toujours par une somme de contrôle CRC16 formée en utilisant le reste des données.

J'ai implémenté la vérification de mon côté, conformément aux spécifications, mais je me suis toujours demandé si c'était nécessaire. Après tout, le protocole UDP lui-même ne comporte-t-il pas un CRC 16 bits? Par conséquent, bien que les paquets UDP puissent être perdus ou hors service, j'avais l'impression qu'ils ne peuvent pas être corrompus sans être éliminés par le matériel réseau avant d'atteindre les processus du système d'exploitation. Ou y a-t-il un cas d'utilisation spécial qui me manque?

Cela vaut la peine d'ajouter que je travaillais dans l'industrie de la défense, qui, comme vous pouvez l'imaginer, aime être super explicite à propos de tout cela, alors je me demande si ce n'était qu'un cas de "OCD de sécurité". ..

security networking data-integrity

— Xénoprimate
source

Si c'est à des fins de sécurité, et pas seulement pour prévenir la corruption accidentelle, vous devez utiliser un MAC, qui est l'équivalent à clé d'une somme de contrôle.

— CodesInChaos

La somme de contrôle UDP n'est valable que pour les données qui ont été injectées dans le paquet UDP. Qu'est-ce qui crée réellement la somme de contrôle? À quoi sert la somme de contrôle? Est-il utilisé pour garantir l'intégrité avant que le paquet UDP ne soit créé ou peut-être transporté avec le paquet pour garantir qu'il conserve son intégrité lorsqu'il circule dans d'autres systèmes? Sans une compréhension plus large des composants de votre système et de la façon dont les données sont créées, transformées et utilisées, je ne suis pas sûr que votre question puisse être résolue.

— Thomas Owens

@ThomasOwens Les données ont été envoyées de l'appareil d'origine dos à dos vers le matériel récepteur. Pas d'intermédiaire. La somme de contrôle a été créée par l'expéditeur comme dernière étape avant l'envoi.

— Xenoprimate

Réponses:

Le protocole UDP ne garantit pas que les messages sont livrés dans l' ordre ou du tout, mais il ne garantit que ces messages qui ne se sont livrés complets et sans changement en incluant automatiquement une somme de contrôle 16 bits. Cela signifie que l'ajout d'une autre somme de contrôle 16 bits sur la couche application est généralement redondant.

...d'habitude....

Tout d'abord, avec IPv4 (pas IPv6), la somme de contrôle est facultative . Cela signifie que vous utilisez peut-être une configuration exotique qui ne fait pas de génération et de validation de somme de contrôle (mais dans ce cas, vous devriez plutôt corriger votre pile réseau au lieu de truquer cela sur la couche application).

Deuxièmement, avec une somme de contrôle de 16 bits, il y a une chance sur 65536 qu'un message complètement aléatoire se trouve avoir une somme de contrôle valide. Lorsque cette marge d'erreur est trop grande pour votre cas d'utilisation (et dans l'industrie de la défense, je pourrais en imaginer plusieurs où elle se trouve), l'ajout d'une autre somme de contrôle CRC-16 la réduirait davantage. Mais dans ce cas, vous pourriez envisager d'utiliser un résumé de message approprié comme SHA-256 au lieu de CRC-16. Ou allez jusqu'au bout et utilisez une véritable signature cryptographique. Cela protège non seulement contre la corruption aléatoire mais aussi la corruption intentionnelle par un attaquant.

Troisièmement, selon la provenance et la destination des données, elles peuvent être corrompues avant ou après leur envoi sur le réseau. Dans ce cas, la somme de contrôle supplémentaire à l'intérieur du message peut protéger l'intégrité du message plus qu'entre les deux hôtes du réseau.

— Philipp
source

Pourquoi cryptographique ? Les contraintes utilisées dans la conception de hachages cryptographiques ne sont pas les mêmes que celles utilisées dans la conception d'un hachage utilisé en transmission (par exemple, le fait d'être gourmand en ressources est une caractéristique des hachages cryptographiques et des problèmes de transmission).

— Programmeur

@AProgrammer J'avoue que le choix des mots aurait pu induire en erreur. Je l'ai remplacé par "bon résumé du message". Les fonctions de résumé des messages sont beaucoup plus longues, ce qui rend les collisions accidentelles si improbables qu'elles peuvent être supposées impossibles à des fins pratiques.

— Philipp

Il tente de garantir que les messages restent inchangés, mais la somme de contrôle utilisée dans UDP est plutôt faible. Alors que la probabilité qu'un message aléatoire ait une somme de contrôle valide est en effet de 1 sur 65536 pour toutes les sommes de contrôle 16 bits, les mesures les plus utiles impliquent un nombre détectable de retournements de bits organisés de manière aléatoire ou en rafale, et toutes les sommes de contrôle ne fonctionnent pas de la même manière selon cette métrique.

— Ben Voigt

@AProgrammer Les hachages cryptographiques (MD5, SHA-1/2/3, ...) visent à être aussi bon marché que possible tout en garantissant des propriétés de sécurité comme la résistance aux collisions. En règle générale, ils peuvent traiter plusieurs centaines de Mo par seconde, ils ne devraient donc pas être un goulot d'étranglement pour rien de moins que les connexions Gbit. Ils sont encore plus lents que de nombreux systèmes non cryptographiques qui n'ont pas besoin d'être résistants aux collisions. Seuls les hachages de mot de passe (PBKDF2, bcrypt, scrypt, Argon, ...) visent à être coûteux à calculer.

— CodesInChaos

UDP fournit cependant une somme de contrôle.

La somme de contrôle UDP n'est que de 16 bits. Cela signifie une chance sur 65 536 qu'un paquet corrompu passe la somme de contrôle.
dans UDP sur IPv4, la somme de contrôle est facultative, donc un expéditeur pourrait théoriquement finir par envoyer un paquet sans somme de contrôle.
La somme de contrôle couvre les informations IP / port ainsi que les données. Bien que cela soit utile pour supprimer des paquets avec des adresses corrompues, cela signifie que si le paquet passe par un NAT, la somme de contrôle doit être recalculée par le NAT.
La somme de contrôle protège uniquement les données lors de leur déplacement dans le paquet UDP. Une somme de contrôle au niveau de l'application peut protéger les données de bout en bout lorsqu'elles traversent un système plus complexe.
La somme de contrôle UDP vous indique clairement que le paquet a été généré par une implémentation UDP. Il ne vous dit pas que cela vient de votre capteur. D'un autre côté, une somme de contrôle au niveau de l'application peut aider à rejeter les paquets qui sont des UDP valides mais qui proviennent d'une autre source.

Je peux donc voir des raisons légitimes de ne pas faire confiance à la somme de contrôle UDP, mais également de ne pas faire confiance à la somme de contrôle UDP, puis d'implémenter une somme de contrôle similaire au niveau de l'application semble étrange.

Il est possible que la personne qui conçoit le protocole ne sache tout simplement pas que UDP a fourni des sommes de contrôle ou que le protocole est en fait une légère variante de celui conçu pour fonctionner sur un support qui ne fournit pas de sommes de contrôle.

PS puisque ce post est étiqueté sécurité, sachez que les sommes de contrôle en question sont conçues pour vous protéger contre les modifications involontaires. La protection contre la modification délibérée ou l'usurpation d'identité nécessite à la fois l'utilisation de fonctions de hachage cryptographiques résistantes aux collisions / préimages délibérées et l'utilisation d'un mécanisme (par exemple, les signatures faites à l'aide d'une clé publique) pour vérifier que les hachages eux-mêmes n'ont pas été modifiés.

— Peter Green
source