Intégrité d'un message chiffré avec RSA

Kevin Denis a écrit :

je m'interroge sur l'intégrité d'un message chiffré par RSA.

Et vous avez raison.

En cryptographie, il faut distinguer intégrité et confidentialité.
Ce sont deux objectifs différents, qui sont remplis de façon différente.
C'est tout particulièrement vrai en cryptographie asymétrique, où le
chiffrement du message se fait au moyen de la clé publique du
destinataire, et ne peut donc donner aucune garantie de l'intégrité du
message (tout un chacun peut chiffrer par la même méthode un tout autre
message).

Si je comprends bien, RSA va permettre de chiffrer non pas le message,
mais une clé AES qui est utilisée pour chiffrer le message.
Ce message chiffré ainsi que la clé AES chiffrée sont ensuite livrés
à son destinataire.

Oui.

Maintenant que se passe t'il si l'intégrité du message n'est pas
garantie?

Le destinataire déchiffre un message dont le chiffrement décrit
ci-dessus ne lui donne aucune garantie sur son auteur.

Je fait un raccourci en donnant l'hypothèse que le chiffré peut être coupé
en trois parties:
1/ Un en-tête spécifiant que le message est chiffré.
2/ La clé AES chiffrée par la clé publique du correspondant
3/ le message en lui-même chiffré par la clé AES.

Imaginons qu'un ou plusieurs bits soient modifiés

A) dans le message chiffré:
-Le début du document sera correct, la fin modifiée.
B) dans la clé AES chiffrée:
-Le document déchiffré sera une bouillie incompréhensible
C) dans l'entête
-Que se passe t'il?

En gros, l'intégrité du message n'est pas assurée du tout..

En effet.

Mes questions:
J'ai aussi lu que l'on peut zipper le message avant de le chiffrer.
auquel cas le déchiffrement se fera, mais pas le dézippage, on aura
une erreur -> Ok, l'intégrité est vérifiée (par effet de bord, mais
bon)

Non, l'intégrité n'est pas vérifiée. Seule l'absence d'erreur
accidentelle de transmission est vérifiée.

Si le fichier n'est pas zippé, comment cela est il géré?

Pour assurer l'intégrité, il faut que l'émetteur signe le message avec
sa clé privée (et non pas le chiffre avec la clé publique du
destinataire). Une manière habituelle est d'adjoindre au message
la signature calculée comme
Signature = ((Expansion(Hash(Message)))^^d)%n
où
Hash est une fonction de hashage comme SHA256
Expansion est une fonction appropriée (voir PKCS#1 ou ISO 9796-2)
n est le module public de l'émetteur (et non du destinataire)
d est l'exposant secret de l'émetteur (et non du destinataire)

La RFC3852 précise que le contenu peut être signé, chiffré
condensé ou authentifié. Il me semble donc possible d'ajouter un
condensat systématiquement afin de s'assurer de l'intégrité des
messages.
D'où mon autre question: lorsque je reçois un message chiffré, comment
savoir s'il est intègre? L'outil de déchiffrement me le signale? ou
bien il y a d'autres mécanismes?

Pour savoir que le message reçu est intègre, il faut que vous disposiez
de la clé publique (n,e) de l'émetteur, que vous ayez confiance en son
intégrité et en son association avec l'émetteur, et que l'émetteur ai
pris soit de signer le message avec sa clé privée, comme décrit
ci-dessus). La vérification de la signature consiste alors à extraire le
message et la signature supposée de ce qui est reçu, puis à vérifier que
(Signature^^e)%n et Expansion(Hash(Message)) sont identiques.


François Grieu

Le 14-10-2009, Francois Grieu <fgrieu@gmail.com> a écrit :

je m'interroge sur l'intégrité d'un message chiffré par RSA.

Et vous avez raison.

En cryptographie, il faut distinguer intégrité et confidentialité.
Ce sont deux objectifs différents, qui sont remplis de façon différente.
C'est tout particulièrement vrai en cryptographie asymétrique, où le
chiffrement du message se fait au moyen de la clé publique du
destinataire, et ne peut donc donner aucune garantie de l'intégrité du
message (tout un chacun peut chiffrer par la même méthode un tout autre
message).

effectivement. Mais je pose bien la question de l'intégrité du
message chiffré, pas de son authenticité.

Maintenant que se passe t'il si l'intégrité du message n'est pas
garantie?

Le destinataire déchiffre un message dont le chiffrement décrit
ci-dessus ne lui donne aucune garantie sur son auteur.

Tout à fait. Ceci dit, les garanties sur l'auteur sont données par
l'authenticité de l'émetteur qui est un cas distinct du chiffrement, et
je me pose des questions sur l'intégrité.

(J'ai du mal à cerner les différences entre authentification et
signature, d'ailleurs).

La question de l'intégrité du message signé se pose moins. Puisque dans
un message signé nous avons l'original et son Hash, la moindre
modification du message signé devrait remonter un problème.

Mes questions:
J'ai aussi lu que l'on peut zipper le message avant de le chiffrer.
auquel cas le déchiffrement se fera, mais pas le dézippage, on aura
une erreur -> Ok, l'intégrité est vérifiée (par effet de bord, mais
bon)

Non, l'intégrité n'est pas vérifiée.

Comme je dis, par un effet de bord, si le dézip échoue, alors
on peut imaginer que le message n'est plus intègre: Pb pendant
la transmission réseau, support de stockage défectueux, ou tout
autre raison.

Seule l'absence d'erreur
accidentelle de transmission est vérifiée.

C'est ce que j'appelle l'integrité, et ce que j'essaie de vérifier.

Si le fichier n'est pas zippé, comment cela est il géré?

Pour assurer l'intégrité, il faut que l'émetteur signe le message avec
sa clé privée

Selon moi, la signature permet d'authentifier l'émetteur.

Pour savoir que le message reçu est intègre, il faut que vous disposiez
de la clé publique (n,e) de l'émetteur, que vous ayez confiance en son
intégrité et en son association avec l'émetteur, et que l'émetteur ai
pris soit de signer le message avec sa clé privée, comme décrit
ci-dessus). La vérification de la signature consiste alors à extraire le
message et la signature supposée de ce qui est reçu, puis à vérifier que
(Signature^^e)%n et Expansion(Hash(Message)) sont identiques.

Je suis d'accord que l'authentification de l'émetteur est un point
à prendre en compte. Toutefois, ce qui me pose problème, c'est
uniquement l'assurance que le message reste intègre dans le temps,
intègre dans le sens ou une modification accidentelle de son contenu
soit détectée.

According to Kevin Denis <kevin@alinto.comNOSPAM>:

Mais je pose bien la question de l'intégrité du message chiffré, pas
de son authenticité.

Intégrité et authenticité sont un peu la même chose...

Qu'est-ce qu'un message intègre ? C'est un message qui est tel qu'il
était quand il a été envoyé. Quand est-ce que le message "a été envoyé" ?
Eh bien cet "envoi initial" n'est pas défini en dehors du cadre de
l'authenticité.

Prenons un exemple : vous avez une clé publique RSA. Alice veut vous
envoyer un message ; elle choisit une clé secrète, la chiffre avec RSA,
chiffre son message en AES avec la clé secrète, et vous envoie le tout.
Bob, qui est un petit malin, intercepte la transmission, choisit un
autre message, une autre clé secrète, chiffre son message avec sa clé
secrète à lui, elle-même chiffrée avec votre clé RSA, et vous envoie le
tout. C'est ce que vous recevez.

Est-ce que ce message reçu, qui vient dans les faits de Bob, est intègre ?
Ce message est bien, bit à bit, tel que _Bob_ l'a envoyé. Pour dire
que ce message n'est pas intègre, il faut déclarer _a priori_ que seul
le message d'Alice est valide, et ça c'est de l'authenticité : on
définit la validité du message en fonction de l'identité de l'émetteur.


Dans le cadre d'un chiffrement par paquets, relativement à une clé
publique RSA, avec une clé secrète spécifique au paquet, chiffrée en
RSA, et envoyée avec, dans ce cadre donc, il n'y a pas vraiment de
notion d'intégrité applicable. Si on parle d'email, eh bien ça veut dire
que n'importe quel Bob venu peut vous envoyer un email quand il le
souhaite, et que par ailleurs vous ne savez pas si Alice vous a envoyé
un email avant de le recevoir (donc si l'email est bloqué en route, vous
n'en savez rien).

En revanche, si on fait rentrer un cadre temporel, alors on peut avoir
une notion d'intégrité non triviale. Par exemple, la clé secrète est
échangée à un autre moment (la clé chiffrée en RSA est envoyée
préalablement). Dans ce cas, on peut vouloir utiliser la notion
d'intégrité suivante : le message sera considéré comme intègre s'il
émane de la même entité que celle avec qui on a fait du RSA. Une
variante, c'est quand on fait du multi-paquets : on fait _un_
chiffrement RSA pour une clé secrète, puis on envoie _plusieurs_
messages distincts, chiffrés avec cette même clé secrète (attention :
chiffrer plusieurs messages avec la même clé est plus délicat qu'il n'y
paraît). La notion d'intégrité est alors : les messages sont intègres
s'ils utilisent tous la même clé secrète (en gros, on utilise une
"session" qui est un ensemble d'échanges, et on s'assure que la session
dans son ensemble est un bloc uni, qu'il n'y a pas eu de découpage et de
remplacement partiel -- c'est le modèle de SSL).

Pour ces notions d'intégrité, RSA ne fait assurément pas le boulot (son
job s'arrête une fois la clé secrète échangée) et AES non plus (lui,
il chiffre, mais ne comporte pas de vrai contrôle de non-altération).
On utilise alors habituellement un MAC (Message Authentication Code).
Un MAC est une sorte de hachage à clé : on calcule une somme de contrôle
sur le message, calcul qui prend en compte une clé secrète. Un MAC
très couramment utilisé (d'ailleurs SSL s'en sert), c'est HMAC. HMAC
est une construction qui utilise une fonction de hachage classique
(genre SHA-256). HMAC est décrit dans la RFC 2104 :
http://tools.ietf.org/html/rfc2104
Conceptuellement, faire une archive Zip du message et chiffrer le tout,
c'est réutiliser le checksum intégré dans l'archive Zip (un CRC32)
comme un MAC, i.e. en espérant que le chiffrement AES injectera
suffisamment de clé secrète dedans. C'est bancal si l'AES et utilisé
en mode CBC, et fort faux en mode CTR. Donc mieux vaut ne pas nourrir
ces espérances.

Il est tentant d'utiliser la même clé secrète pour le chiffrement du
message en AES et pour le MAC. C'est, théoriquement et parfois
pratiquement, une fort mauvaise idée : le MAC pourrait faire "fuir" de
l'information sur la clé utilisable contre le chiffrement, et
réciproquement. C'est particulièrement vrai quand le MAC est CBC-MAC,
qui utilise un algorithme de chiffrement pour en faire un MAC. Pour
faire simple, il faut alors échanger en RSA une grosse clé secrète
(genre 256 bits), utiliser la première moitié pour l'AES, et la deuxième
moitié pour HMAC. On peut aussi partir d'une clé "maître" qu'on
étend avec un générateur pseudo-aléatoire pour en sortir la clé de
chiffrement et la clé de MAC ; c'est ce que fait SSL, et c'est moins
facile à bien faire que ça n'en a l'air.

Une autre possibilité est d'utiliser un mode de chiffrement spécialement
étudié pour faire le chiffrement symétrique _et_ calculer un MAC avec
la même clé, sans que ces deux opérations ne se marchent sur les pieds.
Les modes les plus intéressants (du point de vue performances) ont été
brevetés, mais il reste encore quelques modes pas trop mal fichus qui
sont libres de droits. Le plus connu est CCMP :
http://tools.ietf.org/html/rfc3610
C'est le mode qui a été choisi pour faire la protection du WiFi
"correctement" en WPA2 (contrairement au WEP, fort mal conçu, et
au WPA avec TKIP, protocole de transition conçu pour réparer
rapidement le matériel qui fait du WEP en attendant la nouvelle
génération de matériel apte à faire du CCMP).

Avec CCMP, une clé de 128 bits échangée en RSA, puis chiffrement et MAC
du message en une seule passe, selon cette clé. J'insiste, ça n'empêche
pas, dans le mode mon-paquet évoqué plus haut, un quelconque Bob
d'envoyer un message de son crû, et ça ne fait rien contre les
interceptions des messages d'Alice. Ça n'identifie pas non plus
l'émetteur (le message de Bob pourrait commencer par "From: Alice", et
ni RSA ni l'AES n'y verraient quoi que ce soit à redire). Cette notion
d'intégrité ne peut prendre son sens que relativement à une notion
d'identité de l'émetteur, par exemple si la même clé est utilisée pour
plusieurs messages, alors on a la notion d'identité suivante : "ces
messages viennent de la même personne". Notons au passage que rien ne
dit à froid que tous les messages ont été reçus, et qu'ils ont été reçus
"dans le bon ordre". Comme je dis plus haut, c'est délicat.

Pour avoir une notion d'identité qui corresponde à la notion "physique"
d'identité (celle dont parle un certificat de naissance, par exemple),
il faut un peu plus de matériel. Par exemple, Alice a sa propre clé
publique, et calcule une signature électronique sur la clé secrète
qu'elle chiffre avec votre clé RSA. Mais là encore, il y a lieu de
s'inquiéter d'une foule de détails (par exemple, on ne veut pas que la
signature "montre" une partie de la clé signée).

(J'ai du mal à cerner les différences entre authentification et
signature, d'ailleurs).

C'est surtout entre "intégrité" et "authentification" que la différence
est difficile à voir. En fait tout ça dépend de la notion d'identité
qu'on utilise.

La signature électronique rajoute une autre propriété, qui est la
non-répudiation : la signature peut convaincre un tiers. Dans un échange
entre vous et Alice, vous pouvez acquérir la certitude que vous parlez
bien à Alice. Si vous pouvez _en outre_ convaincre Jérôme (avec un J
comme "juge") que c'est bien le cas, alors vous avez de la
non-répudiation. Et il y a des gradations : au niveau bas, vous avez une
preuve qu'Alice est passée par là, mais rien sur le contenu des
échanges. Au niveau haut, vous avez aussi une preuve que le message reçu
est bien celui d'Alice (une preuve retournable contre Alice, je veut
dire).

Par exemple, dans un échange HTTPS, le client a la garantie (via le
certificat du serveur et la mécanique SSL) qu'il parle bien au bon
serveur, mais face à un juge, même s'il enregistre toute la
conversation, il ne pourra prouver qu'une seule chose, à savoir qu'il a
bien causé au serveur désigné ; il n'aura pas de preuve sur le contenu
des échanges. Cela est également vrai dans l'autre sens, dans le cas où
le client s'authentifie lui aussi avec un certificat (cas très rare sur
le Web, mais techniquement possible) : le serveur est convaincu qu'il
parle au client attendu, mais en termes de preuves montrables à un juge,
il a seulement une preuve du passage du client, mais rien sur ce que le
client a envoyé.

Notons qu'il existe beaucoup de documentations diverses qui emploient
sans vergogne le terme de "signature" pour désigner quelque chose qui
n'en est pas (souvent, un simple hachage), ce qui augmente
considérablement la confusion sur le sujet.


--Thomas Pornin

Le 14-10-2009, Thomas Pornin <pornin@bolet.org> a écrit :

Mais je pose bien la question de l'intégrité du message chiffré, pas
de son authenticité.

Intégrité et authenticité sont un peu la même chose...

Qu'est-ce qu'un message intègre ? C'est un message qui est tel qu'il
était quand il a été envoyé. Quand est-ce que le message "a été envoyé" ?
Eh bien cet "envoi initial" n'est pas défini en dehors du cadre de
l'authenticité.

ok

Dans le cadre d'un chiffrement par paquets, relativement à une clé
publique RSA, avec une clé secrète spécifique au paquet, chiffrée en
RSA, et envoyée avec, dans ce cadre donc, il n'y a pas vraiment de
notion d'intégrité applicable.

Ok. C'est bien le cas qui me pose question. L'authenticité est pour
moi un autre problème. Je réfléchis plutôt à l'intégrité, i.e.
un message altéré par un support défectueux. Je me demande si le
mécanisme de déchiffrement saura détecter cet altération ou pas. Il
semble que non, ce qui serait logique, puisque ce n'est pas son
job.

Pour ces notions d'intégrité, RSA ne fait assurément pas le boulot (son
job s'arrête une fois la clé secrète échangée) et AES non plus (lui,
il chiffre, mais ne comporte pas de vrai contrôle de non-altération).

C'est bien la réflexion que je me faisais. Il faut donc ajouter quelque
chose.

On utilise alors habituellement un MAC (Message Authentication Code).
Un MAC est une sorte de hachage à clé : on calcule une somme de contrôle
sur le message, calcul qui prend en compte une clé secrète. Un MAC
très couramment utilisé (d'ailleurs SSL s'en sert), c'est HMAC. HMAC
est une construction qui utilise une fonction de hachage classique
(genre SHA-256). HMAC est décrit dans la RFC 2104 :
http://tools.ietf.org/html/rfc2104

Je vais lire, merci.
Ceci dit, cela signifie donc qu'avec chiffrement+HMAC, je peux vérifier
l'intégrité du message. Une altération du support sera immédiatement
détectée lors du déchiffrement.

Conceptuellement, faire une archive Zip du message et chiffrer le tout,
c'est réutiliser le checksum intégré dans l'archive Zip (un CRC32)
comme un MAC, i.e. en espérant que le chiffrement AES injectera
suffisamment de clé secrète dedans. C'est bancal si l'AES et utilisé
en mode CBC, et fort faux en mode CTR. Donc mieux vaut ne pas nourrir
ces espérances.

En effet.

Pour avoir une notion d'identité qui corresponde à la notion "physique"
d'identité (celle dont parle un certificat de naissance, par exemple),
il faut un peu plus de matériel. Par exemple, Alice a sa propre clé
publique, et calcule une signature électronique sur la clé secrète
qu'elle chiffre avec votre clé RSA. Mais là encore, il y a lieu de
s'inquiéter d'une foule de détails (par exemple, on ne veut pas que la
signature "montre" une partie de la clé signée).

Je fais un apparté: existe t'il des exemples concrets de ce genre?

(J'ai du mal à cerner les différences entre authentification et
signature, d'ailleurs).

C'est surtout entre "intégrité" et "authentification" que la différence
est difficile à voir. En fait tout ça dépend de la notion d'identité
qu'on utilise.

La signature électronique rajoute une autre propriété, qui est la
non-répudiation : la signature peut convaincre un tiers. Dans un échange
entre vous et Alice, vous pouvez acquérir la certitude que vous parlez
bien à Alice. Si vous pouvez _en outre_ convaincre Jérôme (avec un J
comme "juge") que c'est bien le cas, alors vous avez de la
non-répudiation. Et il y a des gradations : au niveau bas, vous avez une
preuve qu'Alice est passée par là, mais rien sur le contenu des
échanges. Au niveau haut, vous avez aussi une preuve que le message reçu
est bien celui d'Alice (une preuve retournable contre Alice, je veut
dire).

Ok, mais la signature dispose bien d'un mécanisme d'intégrité. Puisque
un fichier signé contient à la fois le message et son hash, la moindre
modification de ce message (toujours en imaginant un support
défectueux) entrainera une non vérification de la signature.

Par exemple, dans un échange HTTPS, le client a la garantie (via le
certificat du serveur et la mécanique SSL) qu'il parle bien au bon
serveur, mais face à un juge, même s'il enregistre toute la
conversation, il ne pourra prouver qu'une seule chose, à savoir qu'il a
bien causé au serveur désigné ; il n'aura pas de preuve sur le contenu
des échanges. Cela est également vrai dans l'autre sens, dans le cas où
le client s'authentifie lui aussi avec un certificat (cas très rare sur
le Web, mais techniquement possible)

Par exemple le site des impôts.

: le serveur est convaincu qu'il
parle au client attendu, mais en termes de preuves montrables à un juge,
il a seulement une preuve du passage du client, mais rien sur ce que le
client a envoyé.

C'est de nouveau un apparté, mais dans le cas du site des impots, nous
nous authentifions via certificat au site web, puis nous signons notre
déclaration. Ceci doit être suffisant comme preuve? Le site web a donc
la preuve du passage du client, ainsi que sa déclaration signée.

Notons qu'il existe beaucoup de documentations diverses qui emploient
sans vergogne le terme de "signature" pour désigner quelque chose qui
n'en est pas (souvent, un simple hachage), ce qui augmente
considérablement la confusion sur le sujet.

Ok.

Merci pour toutes ces précisions.
--
Kevin

According to Kevin Denis <kevin@alinto.comNOSPAM>:

Ceci dit, cela signifie donc qu'avec chiffrement+HMAC, je peux
vérifier l'intégrité du message. Une altération du support sera
immédiatement détectée lors du déchiffrement.

Il faut distinguer les altérations aléatoires des attaques.

Une altération aléatoire implique un changement de certaines des données
par un matériel rétif mais pas foncièrement méchant (c'est du matériel,
il n'a pas de telles émotions). Certains bits peuvent changer, des bouts
peuvent être oubliés, ou dupliqués, ou réordonnancer, il peut y avoir
des données supplémentaires insérées ici ou là. La réplique est connue :
il suffit d'ajouter une "somme de contrôle" qui est, en fait, de la
redondance sur le message complet. Mathématiquement, on déclare que
seule une fraction faible des suites de bits possibles forme un message
"valide", de sorte qu'une altération aléatoire a très peu de chances
de retomber sur une suite valide. Dans la pratique, on rajoute un
checksum, genre CRC32 : si le checksum fait 32 bits, alors la proportion
de messages valides qui redeviennent "valides" après altération est de
1/2^32 : il faut un gros coup de pas de bol pour que ça arrive (1 chance
sur 4 milliards et quelques -- à comparer aux 1 sur 14 millions du Loto).
Les protocoles de transport genre TCP ont déjà des checksums qui font
assez bien ce travail.

(J'ai néanmoins connu un routeur qui altérait les données, avec en
moyenne un bit changé tous les 10 méga-octets transférés. En fait,
le routeur faisait une faute mémoire. Comme en IPv4 le checksum du
paquet est recalculé à chaque saut -- puisque le champ TTL change --
le routeur recalculait un checksum correct sur des données fausses.
Il ne restait que le checksum TCP, lequel est sur 16 bits, donc laissant
passer 1 erreur sur 65536.)

Une fonction de hachage fait, par nature, un très bon checksum. Donc
simplement rajouter au bout du paquet un SHA-256 du paquet fait
l'affaire. Mais comme on est dans un cadre non-belligérant (on parle ici
d'altération aléatoire par un matériel obtus, pas d'un acte vindicatif
d'un attaquant), une fonction de hachage nominalement "cassée" fait
aussi bien, voire mieux si on s'inquiète de performances. Après tout, on
parle d'un usage où un CRC32 est adéquat, et un CRC32 n'a aucune
protection cryptographique. je recommande MD4 (cf RFC 1320), qui est
cryptographiquement déplorable, mais offre des performances excellentes
(souvent équivalentes, voire meilleures qu'un CRC32, pour une sortie de
128 bits, contre seulement 32 pour le CRC en question).

Dans des versions plus avancées, on peut jouer avec des codes
correcteurs d'erreurs, afin de non seulement _détecter_ l'altération,
mais encore de tenter de la _corriger_ (en supposant qu'il y a peu
d'erreurs). C'est ce qui est utilisé dans les CDROM et DVD. Sur un
CDROM, les données sont découpées en "secteurs" de 2048 octets, qui en
fait prennent 2356 octets sur le disque physique. Les 308 octets
supplémentaires sont du code correcteur qui permet de retrouver les
données originelles même si elles ont été endommagées (i.e. une rayure
malencontreuse a blasté une douzaine d'octets). Les codes correcteurs
ne sont souvent pas pertinents dans une transmission réseau, qui est
normalement parfaitement fiable (i.e. détecter l'altération suffit).


Dans le cas d'une _attaque_, par un intrus doué de raison et sachant ce
qu'il fait, la situation est différente. Un CRC32 ou un hash,
l'attaquant peut les recalculer à loisir. Le point que je soulevais,
c'est qu'on ne _peut pas_ se prémunir contre ce genre d'attaque "à
froid", c'est-à-dire sans information supplémentaire sur l'émetteur, et
c'est une question fondamentale, un problème de définition : si on peut
recevoir un message de la part de n'importe qui, eh bien l'attaquant est
un "n'importe qui" comme un autre. Pour qu'on puisse parler
d'altération, il faut qu'il y ait quelque chose qui distingue l'émetteur
"légitime" (Alice dans mon exemple) de l'attaquant (Bob). En
cryptographie, toutes les entités sont réductibles à leurs connaissances
(tout le monde a des ordinateurs, c'est la connaissance de telles ou
telles données -- appelées "clés" -- qui définit l'identité et
conditionne le pouvoir).

Quand Alice est définie par sa connaissance d'une clé qu'elle partage
avec vous, alors l'outil cryptographique à utiliser est un MAC. Bob, ne
connaissant pas la clé, ne pourra pas recalculer un MAC valide sur les
données altérées. Quand Alice est définie par sa connaissance d'une clé
privée qu'elle seule détient, mais qui correspond à une autre donnée
publique (une "clé publique") et que vous avez une connaissance _a
priori_ de cette clé publique (par exemple via un annuaire fiable ou des
certificats), alors l'outil cryptographique est la signature
électronique. Les deux sont combinables, les variantes sont nombreuses.

Mais dans tous les cas, pour parler d'intégrité, il faut qu'il existe
une distinction entre l'émetteur "légitime" et l'"attaquant". Si Alice
et Bob connaissent précisément les mêmes données, alors ils sont, de
votre point de vue, la même personne, et il n'y a pas de notion
d'attaque.

Ou, dit autrement, si vous voulez détecter un Bob qui intercepte et
modifie un message d'Alice, alors il va bien falloir qu'Alice ait une
donnée privée d'une quelconque sorte.

> Pour avoir une notion d'identité qui corresponde à la notion "physique"
> d'identité (celle dont parle un certificat de naissance, par exemple),
> il faut un peu plus de matériel. Par exemple, Alice a sa propre clé
> publique, et calcule une signature électronique sur la clé secrète
> qu'elle chiffre avec votre clé RSA. Mais là encore, il y a lieu de
> s'inquiéter d'une foule de détails (par exemple, on ne veut pas que la
> signature "montre" une partie de la clé signée).
>
Je fais un apparté: existe t'il des exemples concrets de ce genre?

Tout le concept du courrier électronique sécurisé (i.e. soit S/MIME,
qui se raccorde sur l'armada des certificats X.509, soit OpenPGP, qui
refait tout ça dans son coin). Pour OpenPGP, voir RFC 4880. S/MIME et
X.509 sont assez nettement plus compliqués.

> : le serveur est convaincu qu'il
> parle au client attendu, mais en termes de preuves montrables à un juge,
> il a seulement une preuve du passage du client, mais rien sur ce que le
> client a envoyé.
>
C'est de nouveau un apparté, mais dans le cas du site des impots, nous
nous authentifions via certificat au site web, puis nous signons notre
déclaration. Ceci doit être suffisant comme preuve? Le site web a donc
la preuve du passage du client, ainsi que sa déclaration signée.

C'est la signature qui fait preuve. Conceptuellement, la preuve du
passage n'apporte rien : ça prouve simplement que le contribuable
existe, et ça il semble douteux que le contribuable le conteste. Mais le
droit en général, le droit fiscal en particulier, sont des domaines qui
réservent souvent des surprises et que je ne maîtrise pas du tout.


--Thomas Pornin

Le 15-10-2009, Thomas Pornin <pornin@bolet.org> a écrit :

Ceci dit, cela signifie donc qu'avec chiffrement+HMAC, je peux
vérifier l'intégrité du message. Une altération du support sera
immédiatement détectée lors du déchiffrement.

Il faut distinguer les altérations aléatoires des attaques.

Je me pose bien dans le cadre d'altération aléatoire réalisées par
un matériel 'non belligérant'

La réplique est connue :
il suffit d'ajouter une "somme de contrôle" qui est, en fait, de la
redondance sur le message complet.

Mais qui définit ce 'il suffit d'ajouter' ? Une norme? Ou bien le
programmeur qui décide d'implémenter un échange de fichiers chiffrés?

Dans le cas d'une _attaque_, par un intrus doué de raison et sachant ce
qu'il fait, la situation est différente. Un CRC32 ou un hash,
l'attaquant peut les recalculer à loisir.

Tout à fait. Mais on retombe dans la problématique précédente: qu'est ce
qu'un message intègre? C'est un message qui est tel qu'il a été émis par
l'émetteur. D'où mise en place d'un mécanisme d'authentification, comme la
signature par l'émetteur.

Quand Alice est définie par sa connaissance d'une clé qu'elle partage
avec vous, alors l'outil cryptographique à utiliser est un MAC. Bob, ne
connaissant pas la clé, ne pourra pas recalculer un MAC valide sur les
données altérées. Quand Alice est définie par sa connaissance d'une clé
privée qu'elle seule détient, mais qui correspond à une autre donnée
publique (une "clé publique") et que vous avez une connaissance _a
priori_ de cette clé publique (par exemple via un annuaire fiable ou des
certificats), alors l'outil cryptographique est la signature
électronique. Les deux sont combinables, les variantes sont nombreuses.

Ok. Merci.
--
Kevin

According to Kevin Denis <kevin@alinto.comNOSPAM>:

Mais qui définit ce 'il suffit d'ajouter' ? Une norme? Ou bien le
programmeur qui décide d'implémenter un échange de fichiers chiffrés?

Une communication réussie repose sur une convention entre l'émetteur
et le récepteur. Ici, que l'émetteur calcule un hash avec une fonction
de hachage donnée et rajoute le résultat à un endroit idoine dans le
flux, et que le récepteur fasse le même calcul du hash sur les mêmes
données et avec la même fonction, et pioche le résultat attendu là
où l'émetteur l'a mis.

Que cette convention soit un fait des seuls programmeurs impliqués des
deux côtés du tuyau, ou que d'autres personnes suivent cette même
convention, ne change rien à cette affaire.


--Thomas Pornin

Le 19-10-2009, Thomas Pornin <pornin@bolet.org> a écrit :

Mais qui définit ce 'il suffit d'ajouter' ? Une norme? Ou bien le
programmeur qui décide d'implémenter un échange de fichiers chiffrés?

Une communication réussie repose sur une convention entre l'émetteur
et le récepteur. Ici, que l'émetteur calcule un hash avec une fonction
de hachage donnée et rajoute le résultat à un endroit idoine dans le
flux, et que le récepteur fasse le même calcul du hash sur les mêmes
données et avec la même fonction, et pioche le résultat attendu là
où l'émetteur l'a mis.

Que cette convention soit un fait des seuls programmeurs impliqués des
deux côtés du tuyau, ou que d'autres personnes suivent cette même
convention, ne change rien à cette affaire.

La cryptographie est un domaine tellement sensible que je me demande
pourquoi les concepteurs ont laissé le champ libre aux programmeurs à
ce niveau là...
Imaginons un programmeur qui implémente un CRC (ou un hash) tellement
mal que, ou la clé, ou le message, fuite. Ce serait dramatique. Donc
j'espère qu'une norme a prévu le cas et régisse de manière fiable
la situation.

Mais je me trompe peut-être. Soit dans le fait que cette norme n'existe
pas, soit dans les conséquences de laisser l'implémenteur programmer
sa vérification d'intégrité.
--
Kevin

Kevin Denis wrote in message
<slrnhdr0cj.chv.kevin@slackwall.local.tux>:

La cryptographie est un domaine tellement sensible que je me demande
pourquoi les concepteurs ont laissé le champ libre aux programmeurs à
ce niveau là...

C'est le contraire. Un programmeur dans son coin est généralement mal
armé pour construire un protocole sûr, même en mettant bout à bout des
éléments estampillés « sûrs » par telle ou telle norme. Donc la bonne
façon de faire, si vous avez un protocole sécurisé à développer pour une
application particulière, c'est d'en confier la conception à un
cryptographe. Mais c'est comme le fait d'écrire le programme, ce n'est
pas gratuit.

Imaginons un programmeur qui implémente un CRC (ou un hash) tellement
mal que, ou la clé, ou le message, fuite.

De fait, un CRC32 laisse fuir 32 bits d'information essentiellement en
clair sur le message dont est calculée la somme de contrôle. Ce qu'il
faut transmettre, c'est Chiffré(m|crc(m)) ou éventuellement
Chiffré(m)|crc(Chiffré), mais surtout pas Chiffré(m)|crc(m).

Mehdi Tibouchi a écrit :
> un CRC32 laisse fuir 32 bits d'information essentiellement
> en clair sur le message dont est calculée la somme de contrôle.
> Ce qu'il faut transmettre, c'est Chiffré(m|CRC(m)) ou
> éventuellement Chiffré(m)|CRC(Chiffré), mais surtout pas
> Chiffré(m)|CRC(m).


Oui. Et il faut être conscient que pour certains choix des
méthodes produisant "Chiffré" et "CRC", même Chiffré(m|crc(m))
ne donne pas de garantie d'intégrité face à un adversaire.

En particulier, il y a des attaques triviales:
- si "Chiffré" est un chiffrement par bloc en mode CBC et que
"CRC" est calculé avec le polynôme x^n + 1 où n est la taille
de bloc en bit (il suffit de permuter deux blocs du chiffré
ne rentrant pas dans le bloc codant CRC)
- si "Chiffré" est un chiffrement par bloc en mode ECB, quel
que soit le CRC (certaines autres permutations de blocs
dépendant seulement de la nature du CRC ne sont pas détectées)

Et il y a des attaques plausibles si l'on dispose de
"suffisamment" d'exemples; y compris avec ce que contient
un DVD pour certains choix en apparence raisonnable de
"Chiffré" (chiffrement DES CBC, CRC standard 64 bits).


Par ailleurs, comme Thomas Pornin, mon avis est qu'en
cryptographie, sauf indication contraire, pour "assurer
l'intégrité", il faut résister à un adversaire qui
souhaite produire un cryptogramme qui sera accepté
mais qu'aucun émetteur légitime n'a produit; et que l'on
doit supposer que l'adversaire connait le cryptosystème,
est capable d'intercepter et altérer de multiples cryptogrammes,
connait le clair des messages passés, est capable de soumettre
de multiples cryptogrammes à des vérificateurs et d'obtenir
toute information que le système laisse filtrer (code d'erreur,
durée..), et même que l'adversaire peut soumettre presque tout
message de son choix à un émetteur et obtenir le cryptogramme
correspondant (ce qui est plausible: par exemple l'émetteur
peut accepter de produire un cryptogramme correspondant à
tout message commençant par "test.com").

Francois Grieu