Auteur Sujet: Cryptographie symétrique : introduction  (Lu 6618 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Cryptographie symétrique : introduction
« le: 07 mai 2011 à 06:09:52 »
Tous les protocoles de sécurité WiFi qui protègent les trames échangées entre AP et stations utilisent uniquement la cryptographie à clé secrète.

Remarque : ceci n'est qu'une rapide introduction à la cryptographie symétrique (à clé secrète); la description des propriétés de sécurité est très simplifiée.

Petite introduction à la cryptographie à clé secrète

En cryptographie à clé secrète plusieurs participants partagent des données secrètes utilisées dans un protocole cryptographique, principalement les clefs secrètes :

étant donné
  • un message M (appelé le cleartext ou texte clair) d'une longueur quelconque (ou multiple de la taille de bloc dans le cas des fonctions de chiffrement par blocs);
  • une clé K;
  • EK : une fonction de chiffrement (ou chiffre) E paramétrée par une clé K; c'est une fonction bijective des séquences de longueur n sur les séquences de longueur n (n étant quelconque ou bien multiple de la taille de bloc dans le cas des fonctions de chiffrement par blocs)
  • DK : la fonction réciproque de EK
le contenu M est transformé par EK en un chiffré c :
c = EK(M)

Le message c peut en principe être transmis sur un média non sûr.

Quand un récepteur légitime (qui connait la clé K) reçoit un chiffré c' il applique D pour retrouver le texte clair :
M' = EK (c')
si c' = c, alors M' = EK (EK(M)) = M

Un espion n'ayant par hypothèse pas la clé K ne peut pas déterminer M à partir de c (ni même une partie de M ni un seul bit ni la moindre information sauf la taille de M).

Dans la notation, le transmetteur envoie c et le récepteur reçoit c' : on ne peut pas faire l'hypothèse qu'un message, s'il arrive, arrive inchangé. Un adversaire pourrait non seulement écouter les messages mais aussi les intercepter, les transformer, et les réinjecter.

On suppose habituellement que l'adversaire voit tous les messages envoyés, les intercepte tous, et qu'il réinjecte les messages qu'il veut de telle façon qu'ils semblent a priori avoir été envoyés par un participant légitime; autrement dit, il n'y a aucun canal qui échappe à coup sûr à l'adversaire.

Par contre, les participants partagent avant de commencer des secrets cryptographiques qui leur permettent d'utiliser les outils cryptographiques. Un secret de nature cryptographique est une donnée qui est comme issue d'un tirage aléatoire, et qui comporte suffisamment de bits pour qu'une exploration systématique soit impossible en pratique quels que soient les moyens informatiques de l'adversaire.

Intégrité des messages; insertion de faux messages

Même en supposant que la primitive cryptographique E est sure, si la clé K est bien de taille suffisante, générée de façon aléatoire et gardée secrète (transmise uniquement de façon sure), on voit qu'il reste un problème : le remplacement d'un chiffré par un autre ne peut pas être détecté au niveau du protocole cryptographique, la fonction E étant bijective, à toute séquence est associée une autre séquence. (Cela ne veut pas forcèment dire que le problème ne sera pas détecté à un autre niveau : si p.ex. le remplacement de c par le chiffré c' est fait n'importe comment, M' sera n'importe quoi et vraisemblablement ne sera pas décodable, et le récepteur ne sera pas induit en erreur.)

Avec certaines fonctions de chiffrement, étant donné un message chiffré et sans connaitre la clef, il est absolument impossible (dans l'état des connaissances actuelles) de produire un autre chiffré qui une fois déchiffré donne un résultat prévisible : changer un bit du chiffré provoquera des modifications sur à peu près 1 bit de texte clair sur 2; autrement dit, le moindre changement dans le chiffré remplace le texte clair par une suite aléatoire de bits. Aucun intérêt pour l'adversaire.

Mais cela n'est pas toujours vrai : pour certaines fonctions de chiffrement, l'inversion d'un bit dans le chiffré produit un résultat très prévisible dans le texte clair, ce qui peut rendre possible des attaques si une protection n'est pas mise en place.

On utilise donc toujours dans les protocoles cryptographique un code d'intégrité des messages, afin de pouvoir vérifier que l'èmetteur d'un message connaissait bien la clé secrète (ou un secret quelconque); si une partie du message est modifiée en route, la vérification du code d'intégrité échouera, et le message sera ignoré (éventuellement des contre-mesures seront initiées pour rendre encore plus difficile une attaque : p.ex. installer de nouvelles clefs secrètes; dans un système solide, ces contre-mesures font partie de la défense en profondeur et ne sont pas indispensables si les primitives sont aussi solides que prévu).

Bien sûr, un adversaire ignorant la clé ne doit avoir aucun moyen de rétablir le code d'intégrité d'un message qu'il a altéré, sinon c'est une perte de temps : le code d'intégrité est un outil cryptographique, et non un détecteur d'erreurs sur le média.

Le code d'intégrité ne remplace pas les codes FEC/CRC qui servent à corriger et détecter les erreurs. La couche de codage/décodage correspondant au média doit évidemment utiliser ces codages contre les perturbations électromagnétiques. La couche cryptographique intervient seulement quand les simples erreurs de transmission ont été corrigées ou éliminées (les trames non récupérables par la correction d'erreurs sont ignorées).
« Modifié: 07 mai 2011 à 07:49:24 par corrector »

corrector

  • Invité
Cryptographie symétrique
« Réponse #1 le: 07 mai 2011 à 07:16:09 »
Le chiffrement circulaire

Le chiffrement circulaire xor est la fonction de chiffrement la plus simple.

Un "masque" est une séquence de même taille (au moins) que le texte clair; c'est la clef. Le chiffré est le résultat du "ou exclusif" du masque et du texte clair :

EK(M) = K xor M

Pour retrouver le texte clair à partir du chiffré il suffit de refaire cette même opération; le déchiffrement est la même opération que le chiffrement (D = E) :

DK(c) = K xor c

M' = K xor K xor M = M

La difficulté la plus évidente est que la clé K doit être aussi longue que le message; il faut un moyen sûr de la transmettre, or transmettre de façon sure un message d'une telle longueur est le problème qu'on essayait de résoudre en premier lieu.

Le problème mathématique est évident si jamais un masque est utilisé à 2 reprises, pour chiffrer M1 puis M2 :

c1 = EK(M1) = K xor M1
c2 = EK(M2) = K xor M2

Un espion qui récupère c1 et c2 peut calculer :

c1 xor c2 = EK(M1) xor EK(M2)
= (K xor M1) xor (K xor M2)
= (K xor K) xor M1 xor M2
= M1 xor M2

ce qui donne une information très forte sur les messages.

Très souvent l'adversaire connait a priori certains messages échangés (parce qu'un protocole détermine presque entièrement le contenu de certains messages, comme ARP); souvent, il peut envoyer des données à un agent qui va les chiffrer avec sa clef, auquel cas l'attaquant connait entièrement un texte clair donné, mettons M1. Par hypothèse, l'attaquant écoute tous les messages chiffrés; s'il peut corréler le message M1 qu'il a injecté et c1 qu'il a capté, il peut décrypter un message M2; en effet

M2 = (M1 xor M1) xor M2
= M1 xor (M1 xor M2)
= M1 xor (c1 xor c2)

Il ne faut donc jamais au grand jamais réutiliser un même "masque".

Le "masque jetable"

Le principe du "masque jetable" est de disposer a priori d'un "masque" de longueur suffisante, et de le jeter au fur et à mesure qu'il est utilisé pour chiffrer des messages.

Cette approche n'est évidemment pas utilisable directement dans un système pratique, puisqu'il faut une séquence secrète partagée de longueur arbitrairement grande. Il faut un générateur capable de produire une séquence arbitrairement longue à partir d'une graine de taille donnée, de telle manière que la séquence ai le même comportement qu'un dé non pipé : la connaissance d'une séquence de jets d'un dé ne permet de prévoir les jets futures plus précisèment que le pur hasard.

Générateur de nombres pseudo-aléatoires

En pratique un générateur de nombres pseudo-aléatoires (pseudorandom number generator, PRNG) est donc utilisé pour générer le masque. C'est un système déterministe : les nombres sortis générés sont uniquement fonctions de l'état interne du générateur, il n'y a pas de véritable aléa.

Le générateur doit être initialisé avec un état initial secret. Un générateur pseudo-aléatoire peut donc servir à construire un chiffre : la clé secrète K du chiffre correspond à l'état initial du générateur (la "graine").

On appelle un tel procédé un "chiffre de Vernam".

vivien

  • Administrateur
  • *
  • Messages: 47 170
    • Twitter LaFibre.info
Cryptographie symétrique
« Réponse #2 le: 07 mai 2011 à 11:17:57 »
Merci pour ces informations.

En pratique un générateur de nombres pseudo-aléatoires (pseudorandom number generator, PRNG) est donc utilisé pour générer le masque. C'est un système déterministe : les nombres sortis générés sont uniquement fonctions de l'état interne du générateur, il n'y a pas de véritable aléa.
C'est dans le générateur de nombres pseudo-aléatoires d'Open SSL que la plus grosse faille de sécurité jamais rencontré par les systèmes basés sur Debian à été découverte en 2008 => http://www.securite-informatique.gouv.fr/gp_article617.html

corrector

  • Invité
CVE-2008-0166 : 32768 clefs possibles avec Open SSL Debian
« Réponse #3 le: 07 mai 2011 à 20:42:03 »
C'est dans le générateur de nombres pseudo-aléatoires d'Open SSL que la plus grosse faille de sécurité jamais rencontré par les systèmes basés sur Debian à été découverte en 2008 => http://www.securite-informatique.gouv.fr/gp_article617.html
C'est la vulnérabilité CVE-2008-0166. (Je préfère la référence CVE à CERTA, parce que tout le monde utilise la référence CVE ce qui facilite les recherches.)

L'alerte Debian : DSA-1571-1 openssl -- Générateur de nombres aléatoires prévisible

Et ce n'était pas du tout une faiblesse d'un protocole cryptographique!

15 bits d'entropie

D'après Just Another Geek! : Pire que je croyais...

Rendez moi mon entropie !

Toute la cryptographie repose sur la génération de nombres aléatoires, on a ainsi pû en voir les effets à de nombreuses reprises. Tout le monde citera la fameuse débacle Debian/OpenSSL mais c'est un incident parmi tant d'autres... Par exemple, un des CVE d'aujourd'hui concerne un défaut dans l'initialisation de la graîne (CVE-2009-0255) dans un CMS, "hier" c'était le générateur pseudo-aléatoire Microsoft qui était prit la main dans le sac par newsoft et Kostya, etc.

Tout ça, ce sont des problèmes "résolvables" : il y a tout un tas de recommendations pour éviter que cela ne se reproduise, en théorie. Mais si on commençe à regarder ce que le futur nous prévoit, on se rend compte qu'on va vers un tas d'ennuis...

L'entropie & ses problèmes

Commençons par expliquer comment on fait aujourd'hui. Tout d'abord, à part avec du matériel dédié, on ne sait générer que des nombres pseudo-aléatoires. Pour cela, on va utiliser des sources de bruit environnementales (température, timing d'accès disque, bruit d'un capteur, accéléromètre, interruptions clavier, etc.). Bref, tout ça relève quand même de la bidouille, mais de la bidouille qui fonctionne :)

Les choses se compliquent avec les nouvelles générations de matériels. On peut considérer qu'on est progressivement en train de changer "on-the-fly" la moquette par du lino tout en laissant les meubles posés. Autrement dit, on se repose sur les hypothèses de la dernière décennie pour montrer la solidité d'un système d'aujourd'hui.

Hardware 2.0

L'exemple du temps d'accès disque est flagrant, il avait été montré en 1995 que le temps d'accès pouvait être considéré comme aléatoire grace aux turbulences à l'intérieur des disques dur donc cela validait son utilisation pour contribuer à l'entropie du système. Mais là où ça devient embetant, c'est que l'on n'a pas remit en question cette propriété pour les disques dur SSD qui sont pourtant dépourvus de système mécanique. Hypothèse fail

Les mini-ordinateurs (NAS, bornes d'accès Wifi, boxes Internet, etc.) sont dépourvus de disques dur (remplaçés par de la CF ou équivalent), n'ont pas de clavier et ont tous une configuration exactement identiques en sortie d'usine (à part l'adresse MAC et le numéro de série marqué en NVRAM), comment peuvent ils avoir une entropie suffisante pour générer des clefs robustes (administration HTTPS, clefs SSH, clefs Wifi, etc.) lors du premier démarrage ? Rien ne l'indique... Il y a quelques "work-arounds" comme l'obligation de se plugger en Ethernet à la box afin de l'administrer pour la première fois (ça charge ainsi un peu d'entropie) mais les cryptographes ne considèrent pas les évenements venant du réseau comme "sûr" pour alimenter l'entropie.

Hypothèses fail

Virtualisation

La virtualisation apporte aussi son lot de problème : on utilise par exemple les interruptions car on considère qu'elles sont décorrélées de l'horloge du processeur (puisqu'elles sont normalement déclenchées par un évenement externe). Or avec un hyperviseur logiciel comme Xen, ce n'est plus le cas puisque c'est le dom0 qui génère ces interruptions, donc l'hypothèse de départ est encore invalidée. FAIL

De plus, avec la virtualisation matérielle, étant donné que les guests et le host partagent quelques ressources matérielles, sommes-nous vraiment certains qu'un guest ne peut pas prévoir le PRNG de son host ou de son voisin ?

Mutualisation

Beaucoup plus simplement, on a vu que la mutualisation de virtual hosts PHP pouvait mener à en partager un peu trop : s'ils ne sont pas utilisés en CGI, deux scripts PHP de vhosts différents peuvent tourner dans le même processus. Grossièrement, cela signifie que si le premier script fixe la graine d'aléa, le deuxième script utilisera le PRNG laissé dans l'état précédent. FAIL

Solution

La solution ? L'utilisation de RNG matériel est la seule possibilité. Les chipsets Intel et Via intègrent déjà cette fonctionnalité en XOR-ant les sorties d'oscillateurs libres fonctionnant à des horloges différentes.

Il n'y a plus qu'à espérer que ces HW-RNG soient vraiment robustes et que les implèmentations soient correctes (pas comme NetBSD qui croyait détecter un HW-RNG alors que ce hub ne fournissait qu'un flux de 0xff :)...


http://web.archive.org/web/20111014045212/http://chdir.org/~nico/blog/tags/openssl/

Citer
Donc si je résume, la seule graine d'aléa est en fait le PID du processus.
Soit en tout 2**15 = 32768 clefs possibles!

Mais que s'est-il passé?

Deux appels en moins à MD_Update

Une modification qui avait supprimé deux appels (ligne 276 et ligne 473) à la fonction MD_Update qui alimente la réserve d'entropie :
/openssl/trunk/rand/md_rand.c : modification de 2 mai 2006

Quel était le problème en premier lieu? Le deuxième appel ligne 473 dans la fonction ssleay_rand_bytes lit le tampon "buf" qui n'est pas initialisé, ce qui est quasiment toujours un bug puisque lire un tampon non initialisé donne des valeurs imprévisibles, ce qui faisait donc râler l'outil de test Rational Purify. En l'occurrence obtenir des valeurs non prévisibles était l'effet recherché (mais c'est quand même très moche et pas forcèment efficace).

Si on regarde bien, on voit que la ligne 473 est dans une conditionnelle préprocesseur : si le symbole préprocesseur PURIFY est défini, elle est supprimée. Il suffisait donc de compiler avec -DPURIFY pour régler le problème!

Bon, commenter cette ligne n'était pas forcèment catastrophique.

Une autre occurrence de "MD_Update(&m,buf,j);" a été enlevée ligne 276 dans la fonction ssleay_rand_add, ce qui neutralisait presque complètement le remplissage de la réserve d'aléa!

Avez-vous essayé de lire ces fonctions? Franchement c'est incompréhensible pour qui n'est pas familier avec la logique de ce code. Il faut un peu de boulot pour arriver à suivre ce genre de code, sans parler de le comprendre parfaitement pour pouvoir le modifier.

Vous oseriez modifier ce genre de code, vous? Moi non, en tout cas pas comme ça en passant.

Le mainteneur Debian, lui, a eu le cran de le modifier!

C'était aux développeurs d'Open SSL de modifier - éventuellement - un tel code. Un mainteneur n'a tout simplement pas les compétences pointues pour ce genre de choses.

Logiciel libre

Toute personne qui reçoit le code source d'un logiciel libre est autorisée à l'étudier, le modifier, et à redistribuer les modifications apportées. Cela ne veut pas dire que toute personne capable de pondre trois lignes de code doive modifier elle-même un code complexe.

Le logiciel libre, ce n'est pas le mythe de l'égalitarisme. Tout le monde n'a pas les mêmes compétences.
« Modifié: 15 septembre 2013 à 20:10:53 par corrector »

corrector

  • Invité
CVE-2008-0166 : 32768 clefs possibles avec Open SSL Debian
« Réponse #4 le: 23 mai 2011 à 20:15:31 »
Une autre occurrence de "MD_Update(&m,buf,j);" a été enlevée ligne 276 dans la fonction ssleay_rand_add, ce qui neutralisait presque complètement le remplissage de la réserve d'aléa!
Cela montre encore une fois que tester qu'un soft "marche" ne suffit pas : il peut avoir l'air de fonctionner alors qu'en réalité...


Le logiciel libre, ce n'est pas le mythe de l'égalitarisme. Tout le monde n'a pas les mêmes compétences.
On trouve parfois des erreurs grossières dans des logiciels libres :


Hint : allez sur ses pages et laissez un certain temps la souris sur les images.
« Modifié: 24 mai 2011 à 16:47:07 par corrector »

corrector

  • Invité
CVE-2008-0166 : 32768 clefs possibles avec Open SSL Debian
« Réponse #5 le: 24 mai 2011 à 16:51:16 »
Cela montre encore une fois que tester qu'un soft "marche" ne suffit pas : il peut avoir l'air de fonctionner alors qu'en réalité...

La seule source d'aléa d'Open SSL Debian était le PID.

Si OpenSSL n'avait pas utilisé le PID comme source d'aléa, alors Open SSL Debian n'aurait pas eu d'aléa du tout (0 bits d'entropie) et aurait toujours produit la même clef, et on se serait aperçu très vite du problème!

En pratique, la sécurité est la même avec un espace de 15 bits et un espace de 0 bits. Cela prend un temps négligeable à casser avec le plus vieux des PC.

Mais 15 bits de l'extérieur peuvent ressembler à au moins 80 bits (un espace d'au moins 80 bits est considéré comme impossible à explorer par force brute).

corrector

  • Invité
Google confirms critical Android crypto flaw used in $5,700 Bitcoin heist
« Réponse #6 le: 15 septembre 2013 à 20:02:04 »
Même chose ici :

Google developers have confirmed a cryptographic vulnerability in the Android operating system that researchers say could generate serious security glitches on hundreds of thousands of end-user apps, many of them used to make Bitcoin transactions.

This weakness in Android's Java Cryptography Architecture is the root cause of a Bitcoin transaction that reportedly was exploited to pilfer about $5,720 worth of bitcoins out of a digital wallet last week. The disclosure, included in a blog post published Wednesday by Google security engineer Alex Klyubin, was the first official confirmation of the Android vulnerability since Ars and others reported the incident last weekend. Klyubin warned that other apps might also be compromised unless developers change the way they access so-called PRNGs, short for pseudo random number generators.

"We have now determined that applications which use the Java Cryptography Architecture (JCA) for key generation, signing, or random number generation may not receive cryptographically strong values on Android devices due to improper initialization of the underlying PRNG," he wrote. "Applications that directly invoke the system-provided OpenSSL PRNG without explicit initialization on Android are also affected." Apps that establish encrypted connections using the HttpClient and java.net classes aren't vulnerable.

The confirmation came a few hours after researchers from security firm Symantec warned that hundreds of thousands of Android apps may be affected by the vulnerability. By Symantec's count, as many as 360,000 programs rely on the SecureRandom, which is one of the programming services for generating random numbers provided by the JCA. Contrary to many earlier reports, the flaw affects all versions of Android, not just 4.2 and earlier, Android Security Engineer Adrian Ludwig told Ars.

"Call me the tumblin' dice"

PRNGs ensure that computers produce long numbers that are impossible to predict ahead of time and are a core requirement in many cryptographic applications. They're akin to the shakers used by board game players to make sure dice don't land in predictable patterns. Among other things, the random numbers PRNGs produce help ensure that the secret keys used to encrypt or digitally sign data can't be cracked easily.

The Android apps that were exploited in the recent Bitcoin thefts may have signed multiple transactions using an identical number the apps presumed was random, Symantec researchers said in their blog post. "Since transactions are public on the Bitcoin network, attackers scanned the transaction block chain looking for these particular transactions to retrieve the private key and transfer funds from the Bitcoin wallet without the owner’s consent."

Wednesday's blog post from Google recommended developers update all apps that use JCA to "explicitly initialize the PRNG with entropy from /dev/urandom or /dev/random." The advisory went on to suggest developers consider regenerating cryptographic keys or other random values that were previously generated using JCA programming interfaces including SecureRandom, KeyGenerator, KeyPairGenerator, KeyAgreement, and Signature. It also provided example code for implementing the suggestions.

The post said Google developers have delivered patches to handset manufacturers but gave no indication when those updates may find their way onto end-user devices. Instead, the post emphasized the steps third-party developers should take to ensure their Android software. At least four Bitcoin wallets have already been updated to close the vulnerability, according to a Bitcoin advisory that was updated Tuesday. It wouldn't be surprising to see many more apps follow suit in the next few days.

http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/