Les attaques au laser appelées communément "attaques flash" (parce qu'un bricoleur du dimanche peut en réaliser une avec un flash d'appareil photo) consistent à changer un bit, soit en RAM, soit dans un registre, soit à faire avancer le pointeur d'instruction de plusieurs pas sans que le processeur execute lesdites instructions.
Les conséquences possibles :
- lire à une mauvaise adresse en EEPROM et retourner des données secrètes au lieu de données banales
- sauter le "if (code is incorrect) exit" pour sauter les tests de vérification
- faire faire des calculs erronés au DES et en déduire la clé
- faire du bit flipping sur les clé DES et en déduire des choses
Les contre-mesures sont assez simples : puisque tu ne peux pas faire confiance à ta RAM ou au déroulement de ton programme à un instant t, il suffit d'ajouter de la redondance et de vérifier qu'elle est toujours là :
- les valeurs en EEPROM sont lues, relues et parfois encore relues. Les adresses sources et destination sont stockées à deux endroits différents et comparées en permanence.
- les valeurs écrites en EEPROM sont écrites puis relues puis encore relues. Idem, double copie des adresses.
- les copies de RAM à RAM sont vérifiées avant, pendant la boucle puis après avec encore une double-vérification.
- les chemins d'exécution du code comportent des sémaphores qu'on incrémente à côté de chaque instruction sensible et qu'on vérifie régulièrement
Il y a aussi des petites protections matérielles, comme une grille au dessus de la puce pour détecter si la puce est mise à nue. Mais ça ne fait perdre que quelques heures à l'attaquant, le temps qu'il reroute les courant ailleurs et qu'il gratte la grille.
La sécurité vient donc de la combinaison des protections physiques et logicielles.
Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. Quand une carte passe trois semaines dans un labo, ils sont capables de dire exactement quelle instruction est executée à quel moment, synchroniser une attaque laser dessus et voir si le programme pète.
Avec un peu plus de temps, ils peuvent carrément modifier le silicium et rerouter des chemins électroniques, donc concrètement, reprogrammer le hardware de la puce. Tiens, si je mettait un random nul ? Face à ça, il y a bien sur des protections logicielles, mais étant donné qu'ils comprennent tout ce qui est fait au niveau logiciel, ils peuvent prendre le temps de les contourner.
Au final, une carte obtient une note de résistance, qui correspond à la quantité de moyen qu'il faut pour la craquer, et à la disponibilité de ces moyens pour le grand public.
[^] # Re: DES?
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
Les conséquences possibles :
- lire à une mauvaise adresse en EEPROM et retourner des données secrètes au lieu de données banales
- sauter le "if (code is incorrect) exit" pour sauter les tests de vérification
- faire faire des calculs erronés au DES et en déduire la clé
- faire du bit flipping sur les clé DES et en déduire des choses
Les contre-mesures sont assez simples : puisque tu ne peux pas faire confiance à ta RAM ou au déroulement de ton programme à un instant t, il suffit d'ajouter de la redondance et de vérifier qu'elle est toujours là :
- les valeurs en EEPROM sont lues, relues et parfois encore relues. Les adresses sources et destination sont stockées à deux endroits différents et comparées en permanence.
- les valeurs écrites en EEPROM sont écrites puis relues puis encore relues. Idem, double copie des adresses.
- les copies de RAM à RAM sont vérifiées avant, pendant la boucle puis après avec encore une double-vérification.
- les chemins d'exécution du code comportent des sémaphores qu'on incrémente à côté de chaque instruction sensible et qu'on vérifie régulièrement
Il y a aussi des petites protections matérielles, comme une grille au dessus de la puce pour détecter si la puce est mise à nue. Mais ça ne fait perdre que quelques heures à l'attaquant, le temps qu'il reroute les courant ailleurs et qu'il gratte la grille.
La sécurité vient donc de la combinaison des protections physiques et logicielles.
Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. Quand une carte passe trois semaines dans un labo, ils sont capables de dire exactement quelle instruction est executée à quel moment, synchroniser une attaque laser dessus et voir si le programme pète.
Avec un peu plus de temps, ils peuvent carrément modifier le silicium et rerouter des chemins électroniques, donc concrètement, reprogrammer le hardware de la puce. Tiens, si je mettait un random nul ? Face à ça, il y a bien sur des protections logicielles, mais étant donné qu'ils comprennent tout ce qui est fait au niveau logiciel, ils peuvent prendre le temps de les contourner.
Au final, une carte obtient une note de résistance, qui correspond à la quantité de moyen qu'il faut pour la craquer, et à la disponibilité de ces moyens pour le grand public.