Réalisation de l’attaque sur l’applet « MonApplet »

Dans cette section, nous allons utiliser le kit de développement pour la plate-forme Java Card 2.2.2 (Javacard Developpment Kit 2.2.2) pour simuler une carte de crédit et nous essayons d’exploiter l’attaque d’accès à la mémoire complète sur une application de porte monnaie électronique contenue dans cette carte, dans le but de modifier dans le code de cette applet. La modification dans le code de l’applet va permettre au porteur de la carte de débiter des sommes d’argents qui dépassent son solde et donc d’obtenir un gain financier.

3.2.1. Cible d’attaque

La cible de notre attaque est la modification dans le code de l’applet MonApplet contenue dans le package pme présentée dans la section 2.4.

L’applet fournit une fonction de débit. Cette fonction permet à l’utilisateur de la carte de débiter une somme d’argents de son compte. Elle fonctionne comme suit :

- L’utilisateur entre le code PIN de la carte.

- Si le code PIN est valide, on lui permet d’entrer la somme d’argents qu’il voudrait débiter.

- La fonction de débit (dans l’applet) vérifie, entre autres choses, que le solde de l’utilisateur est suffisant pour effectuer ce débit.

Nous voulons, en utilisant l’attaque de lecture de mémoire complète présentée précédemment, accéder au code de cette applet après son installation sur la carte et modifier dans ce code. Précisément, effacer les instructions qui permettent la vérification de la suffisance du solde pour effectuer le débit et l’exception engendrée dans ce cas. La figure 6.15 montre le code de la fonction de débit et les instructions que nous voudrions effacer (les instructions sélectionnées).

Figure 6.15. Code de la fonction de débit. 3.2.2. Réalisation de l’attaque

Nous avons expliqué précédemment, que pour pouvoir réaliser ce type d’attaques nous avons besoin d’une carte à puce ouverte (permet le chargement de nouvelles applications), ce qui est le cas dans notre simulateur. Nous allons commencer, ici, par installer le package pme de l’applet ciblée sur le simulateur de la carte. Et ensuite, nous allons installer une autre applet sur cette carte qui contient le code malicieux qui réalise l’attaque, présenté précédemment.

Nous avons écrit une applet appelée MonAttack, contenue dans un package appelé packageAttack, qui permet d’ajouter une nouvelle fonctionnalité à la carte : consulter des informations sur la carte (titulaire de la carte, date d’activation, date d’expérimentation, etc.). La figure 6.16 montre le résultat de l’exécution de cette nouvelle applet.

Figure 6.16. Exécution de MonAttack avant l’ajout de l’attaque.

Cette applet ne contient pas encore le code de l’attaque. Nous allons ajouter, maintenant, le code décrit dans la section 3.1.5 à cette applet et adapter ce code pour pouvoir réaliser l’attaque dans notre projet. Et en fin, nous allons réinstaller le package packageAttack dans le simulateur de la carte pour réaliser l’attaque.

Notons, que la vérification de fichier CAP packageAttack.cap contenant le code de l’attaque, avant son installation sur la carte, par le vérifieur verifycap indique que le fichier ne contient pas d’erreurs et donc qu’il peut être installé sur la carte normalement. La figure 6.17 montre le résultat de la vérification.

Figure 6.17. Vérification du fichier packageAttack.cap.

3.2.3. Résultats de l’attaque

L’efficacité de l’attaque de lecture de mémoire persistante complète d’une Java Card est prouvée dans les travaux de [6]. Nous avons utilisé cette attaque pour réaliser un gain

Pour voir le résultat de cette attaque, nous avons utilisé l’environnement de développement pour la plate-forme Java Card 2.2.2 (Javacard Developpment Kit 2.2.2) qui contient les différents outils nécessaires pour simuler le chargement et l’exécution d’applets sur une Java Card.

Les différents outils de ce kit, à l’aide de l’environnement de développement Eclipse, nous ont permis de développer les applets MonApplet et MonAttack, d’effectuer les transformations nécessaires pour ces applets, de vérifier le code de ces applets et de les charger et installer sur le simulateur de la carte on créant une image mémoire de la carte, et en fin d’exécuter ces applets en coopérant avec une application cliente.

Cependant, nous avons rencontré des problèmes lors de l’exécution de l’applet MonAttack après l’ajout du code de l’attaque à cette applet.

Nous avons déjà expliqué que la réalisation de cette attaque repose sur l’organisation des données présentes sur la mémoire persistante de la carte. Le problème avec le simulateur c’est qu’il ne possède pas une vraie mémoire EEPROM, mais il utilise une image mémoire contenue dans un fichier texte enregistré dans le disque. Cette image mémoire fonctionne parfaitement pour l’exécution d’instructions d’une applet, à l’exception des instructions qui touchent directement aux blocs de mémoire EEPROM. Dans notre cas l’instruction d’avortement JCSystem.abortTransaction () qui permet d’annuler toutes les modifications dans la mémoire persistante depuis l’instruction JCSystem.beginTransaction ().

Le résultat de l’exécution de cette instruction dans notre application, est le relèvement d’une exception, la déconnection de la carte, et l’affichage d’un message d’erreur. Ceci est illustré dans la figure 6.18.

Le but dans notre projet n’est pas de prouver l’efficacité de l’attaque présentée ici, mais de prouver à travers le code contenant cette attaque l’efficacité du nouveau vérifieur hors-carte que nous avons réalisé.

Figure 6.18. L’exception causée par JCSystem.abortTransaction ().