Pour l'exemple du Rapsberry Pi, c'est quelque chose qu'on connait bien dans l'industrie de la carte à puce, qu'on appelle simplement les attaques "flash". C'est utilisé depuis des années. L'intérêt est que pendant le flash et pendant quelque micro-secondes après, le processeur effectue des NOP au lieu d'instructions valides, mais il incrémente quand même le compteur d'instruction. Ca permet donc de sauter quelques instructions assembleur.
L'attaque est très peu coûteuse en matériel, il faut un appareil photo en gros, gratter un peu la puce pour que la lumière pénètre et un bon système de synchronisation pour déclencher le flash au bon moment.
Il suffit de déclencher à la fin du IF qui vérifie que ton code PIN est faux et se termine par un return pour arriver dans le ELSE où ton code PIN est censé être juste. C'est déclinable selon plein de variantes et les labos de tests de sécurité s'amusent beaucoup avec ça. Inutile de préciser que c'est dévastateur en terme de cassage de cartes/algo/sécurité.
Pas cher en matériel et dévastateur en sécurité, autant dire qu'on a pas intérêt à laisser passer de près ou de loin ce genre de truc.
Du coup, on déploie plein de contre-mesures, qui vérifient qu'on est bien arrivé dans un bout de code pour une bonne raison. Ces contre-mesures n'ayant aucune validité si on analyse le flot de code logique, elles se font parfois virer lors de la compilation ou à l'édition de lien des compilos performants. Ou bien ça marche une fois et la version mineure suivante du compilo va elle virer la contre-mesure. Donc on s'amuse à auditer une partie du code assembleur pour vérifier que le compilo a pas tout sagouiner notre code. Bref, on s'amuse bien par chez nous.
L'un dans l'autre, on se prend dans les 10% de code en plus rien que pour cette attaque. Et les labos de tests un peu sournois commencent à nous balancer des doubles ou triples attaques flash, où ils vont nous nicker le code principal dans un premier temps, puis la contre-mesure. Là, ça peut vraiment faire mal et être pénible à protéger.
# Attaques hardware
Posté par Philippe F (site web personnel) . En réponse à la dépêche La voiture allergique à la glace à la vanille, et autres bugs. Évalué à 10.
Pour l'exemple du Rapsberry Pi, c'est quelque chose qu'on connait bien dans l'industrie de la carte à puce, qu'on appelle simplement les attaques "flash". C'est utilisé depuis des années. L'intérêt est que pendant le flash et pendant quelque micro-secondes après, le processeur effectue des NOP au lieu d'instructions valides, mais il incrémente quand même le compteur d'instruction. Ca permet donc de sauter quelques instructions assembleur.
L'attaque est très peu coûteuse en matériel, il faut un appareil photo en gros, gratter un peu la puce pour que la lumière pénètre et un bon système de synchronisation pour déclencher le flash au bon moment.
Il suffit de déclencher à la fin du IF qui vérifie que ton code PIN est faux et se termine par un return pour arriver dans le ELSE où ton code PIN est censé être juste. C'est déclinable selon plein de variantes et les labos de tests de sécurité s'amusent beaucoup avec ça. Inutile de préciser que c'est dévastateur en terme de cassage de cartes/algo/sécurité.
Pas cher en matériel et dévastateur en sécurité, autant dire qu'on a pas intérêt à laisser passer de près ou de loin ce genre de truc.
Du coup, on déploie plein de contre-mesures, qui vérifient qu'on est bien arrivé dans un bout de code pour une bonne raison. Ces contre-mesures n'ayant aucune validité si on analyse le flot de code logique, elles se font parfois virer lors de la compilation ou à l'édition de lien des compilos performants. Ou bien ça marche une fois et la version mineure suivante du compilo va elle virer la contre-mesure. Donc on s'amuse à auditer une partie du code assembleur pour vérifier que le compilo a pas tout sagouiner notre code. Bref, on s'amuse bien par chez nous.
L'un dans l'autre, on se prend dans les 10% de code en plus rien que pour cette attaque. Et les labos de tests un peu sournois commencent à nous balancer des doubles ou triples attaques flash, où ils vont nous nicker le code principal dans un premier temps, puis la contre-mesure. Là, ça peut vraiment faire mal et être pénible à protéger.