Masking et shuffling partiels

Après avoir analysé séparément l’effet de chacune des contre-mesures, nous allons, à présent, les combiner. Cependant, combiner les 17 possibilités de masking et les 16 possibilités de shuffling aurait conduit à un trop grand nombre d’expériences. Pour cette raison, nous nous sommes limités aux cas où le nombre de bytes masqués et/ou shufflés varie parmi les possibilités sui-vantes : 4, 8, 10, 12, 14 et 16. De plus, nous avons vu, dans le cadre du

masking partiel, que le masking seul affecte faiblement le nombre de traces nécessaires pour mener l’attaque (en comparaison avec l’influence du nombre de bytes shufflés). Nous avons alors décidé de nous intéresser seulement aux cas où le nombre de bytes masqués est plus petit ou égal au nombre de bytes shufflés. Nous n’avons ainsi plus que 21 possibilités différentes.

Méthode d’évaluation

Les bytes de STATE peuvent être classés en 3 catégories et seront attaqués de manière différente en fonction de ces catégories :

– les bytes non protégés : ces bytes ne sont ni masqués ni shufflés. Ils sont attaqués à l’aide d’une attaque par analyse de l’information mutuelle telle que décrite à l’équation 6.2.

– les bytes shufflés : sont attaqués comme lors de la section précédente (équa-tion 6.3).

– les bytes shufflés et masqués.

Pour cette dernière catégorie, l’attaque se réalise en combinant les méthodes appliquées lors des attaques, séparées, des bytes shufflés et des bytes masqués, c’est-à-dire que, dans un premier temps, nous combinons, en considérant la va-leur absolue de la différence¹⁶, deux points relatifs au byte attaqué : le poids de Hamming de la sortie de la SBox masquée (HW (SBox⁰(d ⊕ min⊕ k))) et le poids de Hamming du masque de sortie (HW (m_out)).

Lors de l’attaque d’un byte k de la clé, nous retenons la valeur estimée ˆk qui maximise : ˆ k = arg max k I N X t=1 | T_t⁽¹⁾− T_t⁽²⁾|, HW (SBox (d ⊕ k)) ! (6.4)

où T_t⁽¹⁾ est une valeur liée à la sortie d’une SBox masquée, T_t⁽²⁾ une infor-mation relative au masque de sortie, d un byte du texte clair, N le nombre de bytes shufflés et I l’information mutuelle. Comme précédemment, le maxi-mum est obtenu en testant toutes les valeurs du byte de clé attaqué et en retenant celui qui donne le plus grand résultat.

16. Ceci permet de simuler la suppression du masque et ainsi de réduire la dépendance avec celui-ci. Dans [45], les auteurs montrent qu’il s’agit de la meilleure fonction pour combiner deux valeurs, afin de mener une attaque de second ordre.

Analyse du schéma

Analyse du temps d’exécution

La table 6.10 indique, pour chaque expérience, le temps nécessaire à la réa-lisation de 100 000 chiffrements¹⁷ en fonction du nombre de bytes masqués et du nombre de bytes shufflés. L’augmentation du nombre de masques a une plus grande influence sur le temps d’exécution que l’augmentation du nombre de bytes shufflés. Ceci s’explique par le fait que le surcoût d’un byte masqué est supérieur au surcoût d’un byte shufflé (génération de nombres aléatoires, cal-cul de SBox, opérations supplémentaires vs. génération de nombres aléatoires plus petits et permutations supplémentaires).

TABLE 6.10 – Temps pour 100 000 chiffrements en fonction du nombre de masques et d’instructions shufflées.

Nombre de bytes shufflés

4 8 10 12 14 16 4 0.971s 1.174s 1.270s 1.342s 1.419s 1.472s Nombre 8 1.193s 1.443s 1.535s 1.612s 1.694s 1.735s de 10 1.261s 1.473s 1.581s 1.656s 1.771s 1.809s masques 12 1.402s 1.631s 1.750s 1.813s 1.906s 1.971s 14 1.620s 1.871s 1.993s 2.054s 2.138s 2.227s 16 1.798s 2.047s 2.165s 2.246s 2.358s 2.390s Analyse de la sécurité

La table 6.11 résume, pour chaque scénario, le nombre maximum de traces nécessaires pour retrouver un des 16 bytes lors de nos attaques. De manière évidente, plus la sécurité est haute (nombre de bytes masqués et nombre de bytes shufflés élevés), plus il faut de traces pour retrouver la clé.

TABLE 6.11 – Nombre de traces nécessaires pour l’attaque en fonction du nombre de masques et d’instructions shufflées.

Nombre de bytes shufflés

4 8 10 12 14 16 4 3396 4161 6237 6077 9555 9182 Nombre 8 4556 7887 11969 10462 14776 de 10 8106 12771 12431 15796 masques 12 11883 13613 14129 14 14102 19831 16 18810

Pour éviter certaines répétitions, nous parlons des scénarios sous la forme « scénario x/y », où x indique le nombre de bytes masqués et y le nombre de bytes shufflés. Les scénarios 4/4, 4/8 et 8/8 sont ceux offrant le moins de sécurité. Protéger au plus 8 bytes peut ne pas être très conseillé pour des ad-versaires pouvant passer en force (attaque par force brute) pour l’attaque de ces 8 bytes. Les scénarios 14/14, 8/16, 10/16, 12/16, 14/16 et 16/16 sont ceux offrant la plus grande sécurité (en terme de traces requises dans le cadre de nos expériences). La zone centrale du tableau 6.11 (8/12, 8/14, 10/12, 10/14, 12/12, 12/14) est une zone qui semble prometteuse et intéressante, car elle semble offrir un bon compris entre temps d’exécution et effort néces-saire (traces à collecter) lors de l’attaque.

6.2.6 Conclusion

Au vu des résultats, et comme déjà constaté dans des travaux précédents [25, 27, 45, 68], la combinaison des deux contre-mesures renforce l’effet de sécurité : le gain obtenu est plus fort que le produit des gains séparés, car la recherche des valeurs masquées est compliquée par le mélange des instruc-tions. Il n’y a qu’à constater l’effet de l’augmentation du nombre de masques lorsque les deux contre-mesures sont appliquées, alors que lorsque seul le mas-king est de mise, cet effet n’a pas lieu. Ce qui semble intéressant, c’est la partie centrale du tableau 6.11 pour le compromis qu’elle offre. Un choix de contre-mesures correspondant à cette zone permettra de faire l’économie du stockage de quelques SBoxes masquées, et de plusieurs calculs supplémentaires, mais aussi et surtout l’économie de la génération de plusieurs nombres aléatoires. Au final, on obtient une implantation protégée (moins protégée que si toutes les valeurs étaient protégées, mais suffisamment pour compliquer le travail d’un attaquant), moins gourmande en terme de stockage de données (SBoxes masquées, stockage de masques...) et plus rapide (puisqu’il y a moins

d’opé-rations à réaliser).

Ces résultats sont à placer dans le contexte des expériences réalisées et des choix d’attaques et de schémas de contre-mesures employés. D’autres schémas de contre-mesures n’auraient pas forcément fourni le même type de résultats. De même, d’autres attaques n’auraient pas nécessité les mêmes quantités de traces lors de l’attaque. De plus, tel que présenté, le schéma de masking per-met à l’attaquant de cibler des valeurs du deuxième tour qui ne seraient plus masquées. Pour contrer ce point, il faudrait considérer des schémas où les va-leurs, initialement masquées, le restent tout au long du schéma. Il ne faudrait alors pas replacer les masques à la même position au début de chaque tour, mais cela sort du cadre de l’analyse que nous voulions mener dans un premier temps. Il serait intéressant d’analyser la sécurité des schémas de masking et shuffling partiels en considérant des attaques qui cibleraient des valeurs des deuxièmes et troisièmes tours par exemple, afin d’observer si la sécurité des schémas n’est pas plus faible à ces endroits. Enfin, nous avons délibérément choisi de ne pas ajouter de bruit à nos mesures pour nous placer dans le pire cas pour l’analyse, mais il serait intéressant d’observer l’effet du bruit sur les attaques menées et constater si les gains, en terme de traces nécessaires, sont toujours du même ordre de grandeur. En revanche, ce travail aura peut-être le mérite de faire en sorte que, dans certains cas, des mesures de protection trop lourdes ne soient appliquées, au détriment des performances, alors qu’elles ne seraient pas entièrement justifiées. L’efficacité de certains services pourrait ainsi être augmentée étant donné que les temps de réponses pourraient être plus courts.

Nos implantations

7.1 Programmation Orientée Aspects

Nous avons vu, au chapitre 2, les principes de la programmation orientée aspects (POA, ou AOP en anglais). La programmation orientée aspects offre un grand avantage au développement d’application cryptographique, à savoir qu’elle permet la validation séparée de chaque acteur : l’application cryptogra-phique, le tisseur et les aspects implantant des contre-mesures. Ceci permet de ne devoir valider qu’une seule fois l’application cryptographique et le tisseur et d’ensuite valider chaque aspect séparement au lieu de devoir valider l’en-semble du code pour chaque nouvelle contre-mesure implantée.

Les principes de la programmation orientée aspects ont été mis en pratique pour implanter deux contre-mesures différentes. La première contre-mesure concerne le balancement de RSA pour éviter à un attaquant de pouvoir, éven-tuellement, trouver le poids de Hamming de la clé sur base du temps d’exé-cution. La seconde contre-mesure consiste en l’implantation du schéma de masking d’ordre supérieur de Prouff et Rivain [59].

Le but de ces implantations n’est pas de rendre l’exécution plus rapide ou d’augmenter la sécurité (par rapport à une implantation plus conventionnelle de la contre-mesure), mais de séparer le développement du chiffrement et des contre-mesures. Ces deux facettes vont, dès lors, se retrouver séparées dans le code et il serait tout à fait envisageable de modifier la contre-mesure sans avoir à retoucher à la partie chiffrement, et ainsi à sa validation. L’inverse (modifier l’algorithme de chiffrement tout en gardant la même contre-mesure) semble plus compliqué, mais pas infaisable, étant donné que la contre-mesure est bien souvent taillée sur mesure pour l’algorithme de chiffrement. Il s’agit d’une nouvelle utilisation de la programmation orientée aspects qui vise à implanter des contre-mesures pour les attaques par canaux auxiliaires.