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?
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
According to Francois Grieu <fgrieu@gmail.com>:
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.
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
Le 20-10-2009, Mehdi Tibouchi a écrit :
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
Le 20-10-2009, Mehdi Tibouchi <medtib@alussinan.org> a écrit :
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
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
Thomas Pornin a écrit :
According to Francois Grieu :
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.
Euh oui, cet exemple important manquait, merci !
Francois Grieu
Thomas Pornin a écrit :
According to Francois Grieu <fgrieu@gmail.com>:
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.
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.
Euh oui, cet exemple important manquait, merci !
Francois Grieu
Jean-Marc Desperrier
Kevin Denis wrote:
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.
Kevin Denis wrote:
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.
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.
