Contrôle de redondance cyclique

En informatique et dans certains appareils numériques, un contrôle de redondance cyclique ou CRC (cyclic redundancy check) est un outil logiciel permettant de détecter des erreurs de transmission ou de transfert par ajout, combinaison et comparaison de données redondantes, obtenues grâce à une procédure de hachage. Ainsi, une erreur peut être signalée à l'utilisateur lors de la copie d'un support (disque dur, CD-Rom, DVD-Rom, clé USB, etc.) vers un autre support de sauvegarde. Les CRC sont utilisés depuis le début des transmissions de donnée en informatique dès les bas niveaux. Les checksums (sommes de contrôle) sont un mode de contrôle fonctionnant aussi par hachage, plus élaboré.

Principe[modifier | modifier le code]

Le CRC d'une trame (chaîne de donnée délimitée) est évalué (échantillonné puis calculé) avant la transmission ou le transfert et inscrit sur quelques bits à la fin de la trame. Après transmission, il est recalculé et comparé au chiffre de fin de trame pour s’assurer que les données sont probablement identiques (probablement seulement car toutes les erreurs ne peuvent être détectées, c'est une détection statistique). Une différence conduit à une retransmission, parfois un code erreur.

Les calculs de CRC les plus utilisés sont conçus afin de pouvoir toujours détecter les erreurs de certains types, comme celles dues par exemple, aux interférences lors de la transmission.

On trouve des fonctions CRC dans différents logiciels comme ceux destinés à la sauvegarde, à la capture de données (échantillonnage) ainsi que dans les appareils et dispositifs de transmission de signaux numériques : DVB, MPEG-2 TS, DAB, etc.

Le plus simple et largement répandu dans le transfert ordinateur /machine (commande numérique par exemple) est le CRC1, le bit de parité.

Intégrité des données[modifier | modifier le code]

Les CRC sont spécialement conçus pour protéger contre les types d'erreurs courants sur les canaux de communication, où ils peuvent fournir une assurance rapide et raisonnable de l'intégrité des messages livrés. Cependant, ils ne conviennent pas pour protéger contre l'altération intentionnelle des données.

Premièrement, comme il n'y a pas d'authentification, un attaquant peut éditer un message et recalculer le CRC sans que la substitution ne soit détectée. Lorsqu'ils sont stockés avec les données, les CRC et les fonctions de hachage cryptographique ne protègent pas en eux-mêmes contre la modification intentionnelle des données. Toute application nécessitant une protection contre de telles attaques doit utiliser des mécanismes d'authentification cryptographique, tels que des codes d'authentification de message ou des signatures numériques (qui sont généralement basés sur des fonctions de hachage cryptographiques).

Deuxièmement, contrairement aux fonctions de hachage cryptographiques, le CRC est une fonction facilement réversible, ce qui la rend inadaptée à une utilisation dans les signatures numériques^[1].

Troisièmement, CRC satisfait une relation similaire à celle d'une fonction linéaire (ou plus précisément, une fonction affine)^[2] :

\operatorname {CRC} (x\oplus y)=\operatorname {CRC} (x)\oplus \operatorname {CRC} (y)\oplus c

,

où $c$ dépend de la longueur de $x$ et $y$ . Cela peut également être indiqué comme suit, où $x$ , $y$ et $z$ ont la même longueur

\operatorname {CRC} (x\oplus y\oplus z)=\operatorname {CRC} (x)\oplus \operatorname {CRC} (y)\oplus \operatorname {CRC} (z);

par conséquent, même si le CRC est chiffré avec un chiffrement de flux qui utilise XOR comme opération de combinaison (ou un mode de chiffrement par bloc qui le transforme effectivement en un chiffrement de flux, tel que OFB ou CFB), le message et le CRC associé peut être manipulé sans connaître la clé de chiffrement ; c'était l'un des défauts de conception bien connus du protocole Wired Equivalent Privacy (WEP)^[3].

Implémentation[modifier | modifier le code]

L’opération mathématique^[4] essentielle dans le calcul d’un CRC est une division modulo 2 dont le reste représente le CRC. Les CRC sont souvent appelés abusivement checksums (sommes de contrôle), mais les sommes de contrôle proprement dites sont le résultat d'une addition. La partie principale de l’algorithme est la suivante :

fonction crc(tableau de bits bitString[1..longueur], entier polynome)
{
    shiftRegister := valeur_initiale  // Généralement tous les bits à 0 ou 1
    pour i de 1 à longueur
    {
        si bit de poids fort de shiftRegister xor bitString[i] vaut 1
        {
            // décaler d'1 bit vers la gauche équivaut à multiplier par 2
            shiftRegister := (shiftRegister décalé d'1 bit vers la gauche) xor polynome
        }
        sinon
        {
            shiftRegister := (shiftRegister décalé d'1 bit vers la gauche)
        }
    }
    retourne shiftRegister
}

Exemples d'implémentation[modifier | modifier le code]

(en) Implémentation de CRC-32 en JavaScript

Évolution[modifier | modifier le code]

Les checksums (sommes de contrôle) sont un mode de contrôle fonctionnant aussi par hachage, plus élaboré, portant sur des fichiers plus importants (transfert de fichier, image disque etc.) très visibles dans le monde Linux.

Lors du téléchargement d'une distribution Linux, le MD5sum est disponible au téléchargement à côté de l'image disque. On télécharge les deux, puis un logiciel sur le pc recalcule le MD5sum pour le comparer à l'original pour valider l'intégrité du fichier téléchargé.

Bibliographie[modifier | modifier le code]

Arvind M. Patel, A Multi-Channel CRC Register, AFIPS'71 (printemps) Proceedings, mai 1971 DOI 10.1145/1478786.1478789
P. E. Boudreau, R. F. Steen, Cyclic Redundancy Checking by Program, AFIPS'71 (automne) Proceedings, novembre 1971 DOI 10.1145/1479064.1479067
John R. Hill, A Table Driven Approach to Cyclic Redundancy Check Calculations, ACM SIGCOMM Computer Communication Review, Volume 9 Numéro 2, avril 1979 DOI 10.1145/1015860.1015862
Georgia Griffiths, G. Carlyle Stones, The Tea-Leaf Reader Algorithm: An Efficient Implementation of CRC-16 and CRC-32, Communications of the ACM, Volume 30 Numéro 7, juillet 1987 DOI 10.1145/28569.28572
Dilip V. Sarwate, Computation of Cyclic Redundancy Checks via Table Look-Up, Communications of the ACM, Volume 31 Numéro 8, août 1988 DOI 10.1145/63030.63037
Guido Duerinckx, Cyclic Redundancy Checks in Ada95, ACM SIGAda Letters, Volume XVII Issue 1, janvier/février 1997 DOI 10.1145/249984.249994
(en) Philip Koopman, Kevin Driscoll et Brendan Hall, « Cyclic Redundancy Code and Checksum Algorithms to Ensure Critical Data Integrity » [archive du 18 mai 2015], Federal Aviation Administration, mars 2015 (consulté le 9 mai 2015)

Liens externes[modifier | modifier le code]

(en) Calcul de CRC-32 en ligne, à partir de texte ou d'un fichier, avec polynôme standard ou personnalisé, et le code source JavaScript correspondant
(en) A Painless Guide to CRC Error Detection Algorithms
(en) The Great CRC Mystery - Terry Ritter
Tutoriel sur le calcul des CRC - DVSoft
Calcul du CRC 16
(en) Greg Cook, « Catalogue of parameterised CRC algorithms » [archive du 1^er août 2020], sur CRC RevEng (consulté le 18 septembre 2020)
(en) Phil Koopman, « Blog: Checksum and CRC Central » [archive du 16 avril 2013] (consulté le 3 juin 2013) — includes links to PDFs giving 16 and 32-bit CRC Hamming distances
(en) Mechanics of Cyclic Redundancy Check Calculations (Janvier 2023)

Notes et références[modifier | modifier le code]

↑ Martin Stigge, Henryk Plötz, Wolf Müller et Jens-Peter Redlich, « Reversing CRC – Theory and Practice » [archive du 19 juillet 2011], Humboldt University Berlin, mai 2006 (consulté le 4 février 2011) : « The presented methods offer a very easy and efficient way to modify your data so that it will compute to a CRC you want or at least know in advance. », p. 17
↑ « algorithm design — Why is CRC said to be linear? », sur Cryptography Stack Exchange (consulté le 5 mai 2019)
↑ Nancy Cam-Winget, Russ Housley, David Wagner et Jesse Walker, « Security Flaws in 802.11 Data Link Protocols », Communications of the ACM, vol. 46, n^o 5,‎ mai 2003, p. 35–39 (DOI 10.1145/769800.769823, S2CID 3132937, CiteSeer^x 10.1.1.14.8775, lire en ligne [archive du 26 mai 2013], consulté le 1^er novembre 2017)
↑ (en) « Cyclic redundancy check in Python », sur python.engineering, 13 décembre 2022

[stigge-reversecrc-1] Martin Stigge, Henryk Plötz, Wolf Müller et Jens-Peter Redlich, « Reversing CRC – Theory and Practice » [archive du 19 juillet 2011], Humboldt University Berlin, mai 2006 (consulté le 4 février 2011) : « The presented methods offer a very easy and efficient way to modify your data so that it will compute to a CRC you want or at least know in advance. », p. 17

[2] « algorithm design — Why is CRC said to be linear? », sur Cryptography Stack Exchange (consulté le 5 mai 2019)

[wep-3] Nancy Cam-Winget, Russ Housley, David Wagner et Jesse Walker, « Security Flaws in 802.11 Data Link Protocols », Communications of the ACM, vol. 46, n^o 5,‎ mai 2003, p. 35–39 (DOI 10.1145/769800.769823, S2CID 3132937, CiteSeer^x 10.1.1.14.8775, lire en ligne [archive du 26 mai 2013], consulté le 1^er novembre 2017)

[4] (en) « Cyclic redundancy check in Python », sur python.engineering, 13 décembre 2022

[1]

[2]

[3]

[4]