Le chiffrement symétrique assure-t-il l'intégrité des données?
Disons que j'ai un serveur qui chiffre un fichier avec une clé symétrique, par exemple AES-CBC et l'envoie aux clients qui le déchiffrent. Cela garantit-il l'intégrité des données lors du déchiffrement? Ou est-il possible que quelqu'un falsifie le fichier alors qu'il est encore crypté, et plus tard, lorsque le client le déchiffre, produit un fichier modifié?
Je vois généralement l'intégrité et l'authenticité des données discutées en termes d'utilisation de signatures numériques ou de MAC, mais jamais dans le contexte du cryptage. J'ai également vu des références qui montrent que le chiffrement est plus cher que le hachage, mais ce n'est pas ma principale considération.
MISE À JOUR
J'ai essayé une expérience, où j'ai utilisé l'outil openssl sous Linux pour crypter un fichier. Ensuite, j'ai essayé de modifier le fichier de différentes manières (changer un octet, supprimer un octet, ajouter un octet). Dans tous les cas, lorsque j'essayais de décrypter, j'obtenais un message "bad decrypt". Les commandes que j'ai utilisées étaient:
openssl enc -aes-128-cbc -in test -out test.enc
openssl enc -d -aes-128-cbc -in test.enc -out test.dec
Le chiffrement symétrique ne pas assure l'intégrité. La quantité de contrôle qu'un attaquant peut avoir sur les données chiffrées dépend du type de chiffrement; et certains détails spécifiques de certains modes de cryptage peuvent rendre la vie un peu plus difficile à l'attaquant s'il souhaite effectuer des modifications chirurgicales. Avec CBC, l'attaquant peut retourner n'importe quel bit qu'il souhaite, à condition que cela ne le dérange pas de transformer une douzaine d'autres octets en ordure aléatoire.
Il existe modes de cryptage récents qui combinent le cryptage symétrique et l'intégrité vérifiée (avec un MAC ). Ces modes garantissent à la fois la confidentialité et l'intégrité. AES-CBC est pas l'un d'eux. Si vous voulez un mode de cryptage avec intégrité, je recommande EAX .
Mise à jour: concernant votre expérience: CBC est un mode où la longueur des données source doit être un multiple de la longueur du bloc de chiffrement de bloc (16 octets, pour AES) . Puisqu'un message d'entrée arbitraire peut avoir n'importe quelle longueur, certains padding sont ajoutés: quelques octets, avec un contenu spécifique de sorte qu'ils peuvent être supprimés sans ambiguïté lors du déchiffrement. Dans votre cas, OpenSSL se plaint que, lors du déchiffrement, il ne trouve pas de structure de remplissage appropriée. Cependant, si l'attaquant ne modifie pas les 32 derniers octets des données chiffrées, le remplissage ne sera pas endommagé, de sorte que les modifications de tous sauf les 32 derniers octets resteront non détectées. Et même pour les 32 derniers octets, il existe des moyens d'échapper à la détection avec une probabilité pas si faible.
Le cryptage CBC n'assure pas l'intégrité des données. Voici pourquoi:
Correction d'une clé k (inconnue de l'attaquant). Soit E (k, -) et D (k, -) les fonctions de chiffrement et de déchiffrement nues de certains chiffrements par blocs. Soit p un bloc unique de texte en clair. Je dénoterai XOR par +. Après avoir corrigé certains IV, nous chiffrons comme suit:
c = E (k, p + IV).
Ensuite, nous envoyons IV et c sur le fil. Pour décrypter, nous calculons
p = D (k, c) + IV.
(Notez que cela équivaut à la déclaration D (k, c) = IV + p.)
Supposons maintenant qu'un attaquant connaisse une seule paire texte en clair/texte chiffré. Notons-les p et (IV, c), comme ci-dessus. Supposons maintenant que l'attaquant souhaite créer un texte chiffré qui sera décrypté vers un autre bloc de texte en clair de son choix - disons p '. Je prétends que (IV + p + p ', c) décrypte en p'. Pourquoi?
Eh bien, nous suivons simplement la procédure de décryptage ci-dessus, en remplaçant IV par IV + p + p '. On a
D (k, c) + (IV + p + p ') = (IV + p) + (IV + p + p') = p '.
De manière amusante, le mode ECB n'est pas vulnérable à ce problème (bien que je n'approuve pas non plus son utilisation).
Le chiffrement AES-CBC n'assure pas l'intégrité. Selon la façon dont il est implémenté et utilisé, il peut arriver de détecter des modifications accidentelles du texte chiffré, mais il ne protège pas contre toute falsification malveillante du texte chiffré .
Le cryptage sans authentification est l'une des erreurs les plus courantes dans l'utilisation de la cryptographie . Cela a entraîné de graves vulnérabilités dans de nombreux systèmes, notamment ASP.NET, le chiffrement XML, Amazon EC2, JavaServer Faces, Ruby on Rails, OWASP ESAPI, IPSEC et WEP. Voir le lien précédent pour Plus d'information.
Le correctif: vous devez soit utiliser un schéma de chiffrement authentifié (pas AES-CBC), comme EAX, ou vous devez utiliser un code d'authentification de message, comme CMAC, en mode chiffrer puis authentifier.
Si vous allez mettre en œuvre la cryptographie vous-même, je vous encourage à lire la question ici intitulée Leçons apprises et idées fausses concernant le cryptage et la cryptologie pour vous aider à éviter certaines des erreurs les plus courantes. L'utilisation du chiffrement sans authentification en fait partie.
Les chiffrements symétriques n'assurent pas à eux seuls l'intégrité car ils ne détectent pas les modifications malveillantes ou accidentelles du texte chiffré; le déchiffrement produira autre chose que le texte en clair d'origine et à moins que cela n'entraîne une violation de protocole pour la charge utile déchiffrée, vous avez un problème d'intégrité.
La solution consiste à envelopper le texte en clair dans des packages qui incluent des données qui peuvent être utilisées pour valider l'intégrité du package, généralement une somme de contrôle basée sur le hachage ( edit: HMAC). C'est ce qui se fait par exemple pour la sécurité de la couche de transport.
Voici un exemple d'un schéma de protection en texte brut utilisé dans un protocole de transport d'octets sécurisé Versile Platform (avertissement: je suis impliqué dans le développement de VP).
Edit: J'ai réalisé que l'encapsulation des messages est exagérée pour votre scénario qui implique un fichier complet, et donc vous feriez mieux d'ajouter simplement un MAC à clé sur l'ensemble texte chiffré. Pour les formats protégés par package, comme D.W. souligne l'importance des détails et la "somme de contrôle" doit être effectuée comme un MAC à clé.