Intégrité d'un message chiffré avec RSA
Kevin Denis
je m'interroge sur l'int�grit� d'un message chiffr� par RSA.
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.
Maintenant que se passe t'il si l'int�grit� du message n'est pas
garantie?
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..
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) Si le fichier n'est pas zipp�, comment cela est il g�r�?
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?
Merci
--
Kevin
Francois Grieu
> 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
Kevin Denis
>> 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).
>
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.
Thomas Pornin
> 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
Kevin Denis
>> 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�.
>
> 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
Thomas Pornin
> 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
Kevin Denis
>> 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.
>
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
Thomas Pornin
> 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
Kevin Denis
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
Mehdi Tibouchi
<slrnhdr0cj...@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).
Francois Grieu
> un CRC32 laisse fuir 32 bits d'information essentiellement
> en clair sur le message dont est calcul�e la somme de contr�le.
> �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\0").
Francois Grieu
Thomas Pornin
> 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 surtout :
- si "Chiffr�" est un chiffrement par XOR avec un flux (cas de la
plupart des stream ciphers, et aussi des block ciphers en mode CTR),
alors il est trivial pour l'adversaire d'inverser n'importe quel
bit (m�me s'il ne conna�t pas la valeur de ce bit !) et d'ajuster
le CRC en fonction.
--Thomas Pornin
Kevin Denis
>> 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.
nous sommes donc d'accord.
> 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.
>
Et aucun cryptographe n'aurait pens� � �tendre la norme? Je ne ferais
pas plus confiance � un cryptographe qu'� un programmeur tant que le
principe n'est pas publiquement expos�, d�battu, et valid�.
Je ne suis pas programmeur, je ne cherche pas � programmer.
Je cherche � comprendre comment tout cela fonctionne. Or donc, si
je relis bien le thread, il n'existe pas de norme publique permettant
de v�rifier l'int�grit� d'un message chiffr� face � un mat�riel
d�fectueux. La solution consiste donc � impl�menter � sa mani�re (laiss�e
libre, en prenant conseil d'un cryptographe au besoin) un m�canisme de
redondance.
D�sormais, pla�ons nous dans le peau d'une personne cherchant � �valuer
la solidit� d'une solution de chiffrement vendue par un prestataire.
Le prestataire indique dans sa doc qu'il met en oeuvre un m�canisme
d'int�grit� (nous sommes toujours dans le cadre du mat�riel non
bellig�rant, pas d'une attaque cibl�e). Ce m�canisme d'int�grit� ne
pr�cise pas la norme (ou la RFC) correspondante employ�e (ce qui semble
�tre logique puisque cette norme n'existe pas). D�s lors, j'aurais
plut�t tendance � penser que ce m�canisme affaiblit la solution de
chiffrement plus qu'autre chose. La solution consisterait donc � publier
la solution choisie pour qu'elle soit �valu�e par les cryptologues,
mais ce n'est pas le cas.
--
Kevin
Francois Grieu
Euh oui, cet exemple important manquait, merci !
Francois Grieu
Jean-Marc Desperrier
> D�sormais, pla�ons nous dans le peau d'une personne cherchant � �valuer
> la solidit� d'une solution de chiffrement vendue par un prestataire.
>
> Le prestataire indique dans sa doc qu'il met en oeuvre un m�canisme
> d'int�grit� (nous sommes toujours dans le cadre du mat�riel non
> bellig�rant, pas d'une attaque cibl�e). Ce m�canisme d'int�grit� ne
> pr�cise pas la norme (ou la RFC) correspondante employ�e (ce qui semble
> �tre logique puisque cette norme n'existe pas).
Restons calme, dans la majorit� des cas, les RFC, etc. prennent bel et
bien en compte le probl�me d'int�grit�.
Il peut y avoir des exception, on va compter la RFC 3852 (CMS) l� dedans.
Je pense que la source du "fatal failure" dans la RFC3852, est que le
chiffrement n'y a pas �t� con�u pour �tre utilis� tout seul, mais comme
une sur-couche de la signature.
Au d�part, le chiffrement en RFC3852 se faisait uniquement sur base de
cryptographie sym�trique, donc pour emp�cher n'importe qui de chiffrer �
destination du certificat du destinataire, il fallait de toute fa�on une
couche de signature afin d'apporter la garantie � la fois d'origine des
donn�es et d'int�grit�.
Malheureusement, ensuite on a rajout� � CMS la possibilit� de faire du
chiffrement sym�trique sur la base de secrets partag�s. Sans ajouter de
couche d'int�grit�, en gardant juste le padding existant qui est
ultra-light m�me vis-�-vis d'une modification accidentelle.
Heureusement qu'� peu pr�s personne ne se sert de cette possibilit� :-)
et qu'un CMS chiffr� est presque toujours un CMS sign�, puis chiffr�, et
l� pas de probl�me.
Les RFC concernant le transport d'un flux comme WPA2/CCMP �voqu� plus
haut ou TLS 1.2 (RFC5246) ne passent absolument pas � cot� de ce point,
et d�crivent dans tous les d�tails le m�canisme d'int�grit� � mettre en
�uvre en plus du chiffrement.