Les processeurs vont-ils nous trahir ?

Dimanche 19 novembre 2006

Tout le monde sait combien la sécurité est importante surtout dans le monde virtuel des ordinateurs. Dans ce domaine il y a la cryptographie qui nous permet de protéger des messages permettant notamment de garantir la confidentialité ainsi que l’ authenticité à l’aide de l’utilisation de clés ou secret.

Un récent d’article publié sur Le Monde samedi annonce qu’une équipe allemande dirigé par Jean-Pierre Seifert, a découvert une grosse faille au plus bas niveau de l’ordinateur : le processeur.

En effet, le processeur travaillant en parallèles avec un pipeline d’exécution inclut un système de prédiction d’embranchements qui lui permet de commencer à traiter les instructions qui ne sont pas encore fini en essayant de « prédire » leurs résultats. Si la valeur deviner était la bonne : tant mieux ont a gagné du temps, par contre si la valeur prédit n’est pas correcte, le processeur doit revenir en arrière mais statistiquement cela fait gagner beaucoup de temps et donc de performance. (Plus d’info sur Wiki Cublic)

La faille se base donc sur cet élément du processeur, qui nous permettrait en écoutant de manière synchrone le processeur de prédire la clé privé quand celui ci l’utiliserait. La faille sera présenté à la conférence RSA en début d’année 2007 mais Mr Seifert estime qu’il ne serait une question de semaine avant de voir arriver dans la toolbox des hackers des petites taupes observant les calculs du processeur pour récupérer les clés.

Ce type de faille est bien connu par l’armée américaine qui mettent en garde depuis longtemps contre les attaques fondées sur l’analyse des temps de calcul. Ces attaques sont déjà possibles sur des cartes à puce, avec lequel ont peu mesurer tout un tas de paramètres comme sa consommation pour tenter de deviner la série de bit utilisée lors d’un simple calcul RSA. Mais d’âpres certain expert, les systèmes d’exploitation eux même inclut une couche de sécurité en faisant du bruit au niveau du processeur lors de l’accès aux clés.

Un document plus technique d’un expert en la matière disponible ici, affirme que ce genre d’attaque est très difficile à mettre en oeuvre car elle dépends de nombreux facteurs (type de processeur, sa fréquence, etc..). Il serait donc difficile pour certains de voir généraliser ce genre d’attaque dans la vie courante sur tout type de processeur. De plus, comme stipulé dans l’article, David Naccache de l’ université Paris II estime qu’il n’y a pas d’opération à coeur ouvert possible, en d’autre terme, difficile de pouvoir toucher/observer le système de prédiction sans perturber l’activité normale du processeur.

En clair, je pense qu’il faut mieux attendre la présentation de cette « faille » début 2007 à la conférence RSA pour vraiment savoir de quoi il s’agit avant de monter sur ces grands chevaux en criant que la sécurité informatique ne vaut plus rien comme l’affirme le titre son article : Les puces ne garantissent pas la sécurité des échanges en ligne… Certe il y a un problème de sécurité, après il faut voir comment elle pourra être exploitée. Dans le long terme, les processeurs vont surement eux même intégré une notion plus forte de sécurité, à court terme ce genre d’attaque peut être contré en désactivant le système de prédiction (qui réduit tout de même les performances de près du quart)…

Bref, attendons la suite…. Qui vivra verra :)

[UPDATE du 23/11/06] : J’ai trouvé un article publié sur Indexel qui confirme ma position prise sur le sujet : Cryptographie : fausse faille ou véritable intox ?. Je vous cite la conclusion :

Toutes ces réservent ne remettent cependant pas en cause la publication de Jean-Pierre Seifert : en tant qu’amélioration d’une technique connue, la découverte est passionnante. Mais il faut la replacer dans son contexte : d’une attaque difficile à mettre en oeuvre et qui exige par ailleurs un scénario improbable, l’universitaire en a fait une attaque plus simple à mettre en oeuvre dans certains cas particuliers mais qui exige toujours un scénario aussi improbable. Ce n’est donc pas la fin des achats sur internet, comme ont pu le croire certains médias généralistes.

Qu’est ce qu’on s’amuse en ASM !!!!

Jeudi 2 mars 2006

Dans le cadre des cours d’architecture des ordinateurs a Supinfo, je me suis amusé a faire un petit programme COM pour processeur 8086 en assembleur qui calcule la somme des termes des lignes dans une matrice !! (un truc qui sert a rien, je sais !!!)

Le principe est simple, je definie une matrice de 4×3 dans mon programme et il m’affiche le resultat pour chaque ligne !

Exemple matrice nommé tab :

	3 4 9
  	14 11 2
  	6 4 8
 	7 5 1

Definie en ASM par :

1
tab	DW	3,4,9,14,11,2,6,4,8,7,5,1

Le programme nous affiche :

16 27 18 13

(car 3+4+9=16, 14+11+2=27, etc….)

Sans en faire tout un roman, voici le code (env. 30 lignes) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
; ==============================================
org  100h		; Structure d'un .COM 
JMP code		; Demarrage du programme
 
; ======= Variable du tableau de données =======
tab	DW	3,4,9,14,11,2,6,4,8,7,5,1 	; matrice de 4x3
 
code:
; ============= Init des registres =============
MOV	AX, 0		; AX : Somme par ligne
MOV	CX, 0		; CX : Index du tableau TAB
MOV	DI, 0		; DX : Compteur de ligne
 
boucle:
; ============== Boucle principale =============
LEA	BX, tab		; Chargement du tableau TAB dans BX
MOV	SI, CX		; Calcul de l'index dans SI
ADD	SI, SI		; 		du tableau TAB
MOV	DX, [BX+SI]	; Mets le tab[SI] dans DX
ADD	AX, DX		; Additionne AX = AX + DX
INC	CX		; Incremente CX pour la boucle
INC	DI		; Incremente DI pour le compteur de ligne
CMP	DI, 3		; Si DI=3, nouvelle ligne (newline)
JE	newline	
CMP	CX, 12		; Si AX = 12, fin du programme (fin)
JGE	fin
JMP 	boucle		; Retour au debut de la boucle
 
newline:
; ================ Nouvelle ligne ===============
MOV	BL, 10		; Divise AX/10
DIV	BL		; AL = quotien et AH = reste
ADD	AL, 48		; Char ASCII de AL (quotient)
MOV	BH, AH		; Sauvegarde du reste (AH) dans BH
ADD	BH, 48		; Char ASCII de BH (reste)
MOV    	AH, 0Eh		; Fonction d'affichage   
INT    	10h       	; Interruption 1OH : affichage de AL (quotient)
MOV	AL, BH		; Reste (BH) dans AL
INT    	10h  		; Interruption 1OH : affichage de AL (reste)
MOV	AL, 10		; AL = 10  (Saut de ligne = \n en C = char 10 + 13)
INT	10h		; Affiche AL=10
MOV	AL, 13		; AL = 13
INT	10h     	; Affiche AL=13
MOV	DI, 0		; Remet DI a 0
MOV	AX, 0		; Remet AX a 0
JMP	boucle		; Retour au debut de la boucle
 
fin:
; ================= Fin du programme ==============
RET			; Retourne la main a l'OS

Wahou, vive la galère ^^ Heuresement qu’ils ont inventés les langages de haut niveau, parce que voila la galère pour faire un programme relativement simple (….et sans interêt d’ailleur ^^) !

A noter aussi que mon programme ne gere que 2 octects à l’affichage (AH et AL = 8 + 8 = 16bits), ce qui fait que la valeur maximum est 99 à l’affichage, au dessus ca affiche divers caractères !!

Au passage, un grand merci a Alex C. (a.k.a EvilSnake) pour son aide au niveau de la gestion de l’affichage des resultats a l’ecran !! C’est toujours un plaisir de coder avec toi :-)

Téléchargez le fichier code source ASM