Soutenance de stage Développement d'un assembleur Java Card

(1)

Trusted Logic S.A.

5, Rue du Bailliage - 78000 Versailles - FRANCE Tel: +33 (0)1 30 97 25 00 Fax: +33 (0)1 30 97 25 19

http://www.trusted-logic.com

Soutenance de stage

Développement d'un assembleur Java Card™

Stagiaire : Benoît Lemaître Maître de stage : Emmanuel Lepavec

Présentation : soutenance de Stage fin de Master 2 TIIR Il s'est déroulé du 1 avril au 30 sept.

(2)

Page 2

www.trusted-logic.com

Objectifs de la présentation

• Présentation du contexte et du stage

• Vision du travail effectué

• Mise en situation de l'outil

Entreprise > Contexte > Problématiques > Solution > Démonstration

Plan de la présentation :

Présente le contexte / les besoins Explique ce que j'ai changé Termine par une démo

=> conclusion (mon impression sur le stage)

puis les QUESTIONS sur le rapport ou la présentation.

(3)

Page 3

Présentation de l'entreprise

• Historique :

• 1999 : Création de l'entreprise

• Projet R&D de l'INRIA et de Bull/CP8

• 2005 : Création de Trusted Labs

• Entité chargée des études sécuritaires

• 2007 : Fusion avec Bantry Technologies

• Logiciels et solutions SIM

• Présence sur 4 sites :

Versailles / Sofia Antipolis / Dublin / Singapour

Entreprise > Contexte > Problématiques > Solution > Démonstration

Entreprise qui a déjà 10 ans

Création par des ingénieurs de l'INRIA / BULL Création d'une branche sécurité

Fusion pour se porter sur le marché des télécom.

Différents sites : Base mère à Versailles Recherche à Sofia

Bantry (telecom) en Irlande (Dublin) Marché asiatique = comptoir à Singapour

(4)

Page 4

Présentation de l'entreprise : activités

• Smart cards and Secure Tokens :

• Depuis la création de Trusted Logic

• Java Card™ Virtual Machine sécurisée

• Outils et services pour applications sécurisées

• 3 secteurs visés : Bancaires, Télécom, Identité

Entreprise > Contexte > Problématiques > Solution > Démonstration

Trusted logic :

Carte à puce

Développement d'une plateforme extrêmement sécurisée Utilisation de Java Card

Différents secteurs de client visés

(5)

Page 5

Contexte – Java Card™

• Java Card™ : sous ensemble de Java

➢ Sun® Microsystems

➢ Dès 1999, version 2.1

➢ A partir de 2006, verison 2.2 (support RMI)

• Open platform :

➢ Chargement d'application

➢ Fichier CAP structuré en composants

Utilisation de Java Card = sous ensemble de Java mm fonctionnement limitation

Problème de Java <> Natif / C =>

Pas d'amélioration possible

Langage Objet (assez haut niveau)

Fichier cap = Un package

Carte possède des applets des sa création

On charge / décharge des applications sur la carte

(6)

Page 6

Contexte – Pourquoi un assembleur Java Card™

• Contrôle plus fin :

• Optimisation de la vitesse d'exécution

• Optimisation de la taille de l'applet

• Maskage d'applet : Patchs de correction / ajout

• Applet en ROM, non modifiable

• Ajout d'une applet de patch en EEPROM

• Dérivation vers le patch lors de l'exécution

• Tests : Applets malicieuses

• Réalisation de choses non conventionnelles

Assembleur => Possibilité d'optimisation (Taille / rapidité) Création d'applets malicieuses

Permet de faire des patchs

Permet de faire des tests (malicieux)

(7)

Page 7

Problématiques du sujet de stage

Entreprise > Contexte > Problématiques > Solution > Démonstration Besoins :

● Amélioration de l'existant :

➢ Génération du debug component

➢ Génération d'un fichier cap version 2.2

● Aide à la génération de patchs :

➢ Utilisation de symboles

➢ Amélioration de la granularité de l'assembleur

Projet existe déjà, et la BU s'en sert

Problèmes : Pas de version 2.2 (uniquement 2.1)

Pas de debug component => Pas de debug des applets créées

Utilisation de symbole :

valeurs hard codées => nombres = erreurs

pour différentes cibles = fichier symboles qui change Ne pas avoir à écrire de Java puis décompiler pour assembleur.

-> Bloc asm dans le code de méthodes

(8)

Page 8

Solution proposée

Différents apports pour répondre aux besoins :

• Ajout du debug component

• Ajout d'une option 'version 2.2'

• Modification des parsers

• Modification du langage TLJCA

• Création de nombreux tests

• Création d'un exemple de patch

On ne va pas redire le contenu du rapport qui est sensé être lu.

Retour rapide sur les différentes méthodes de travail & les nouvelles choses ajoutées.

(9)

Page 9

Démonstration

Entreprise > Contexte > Problématiques > Solution > Démonstration S'appuie sur le patch 'exemple'

• Applet de calcul simple

• Présence de bugs

Modification pour la démo de debug

• Correction des bugs en assembleur

• Exécution via debugger d'éclipse

Réalisation d'un patch exemple :

Applet qui fait les opérations de bases 5 bugs introduits pour faire un patch

Pour la demo => ajout du code de correction dans l'applet

NORMALEMENT : - Fichier séparé pour le patch - Utilisation de symboles

(10)

Page 10

Démonstration – Fichier de patch

• Fichier séparé de l'applet que l'on veut patcher

• Une méthode pour chaque point de patch

• Utilisation de symboles

• Granularité de bloc

On voit bien le fichier séparé, le package qui n'est pas le même

=> Utilisation de symbole pour avoir accès à des valeur maskées

=> granularité niveau black !

|_ On fait des chose en Java avant, on utilise assembleur à la fin !

(11)

Page 11

Démonstration

Entreprise > Contexte > Problématiques > Solution > Démonstration Debuggage d'une applet :

• Avant de patcher, trouver les bugs !

• Utilisation de 3 outils :

• Un debugger (Eclipse)

• Une interface de dialogue avec la carte (TLJTOPCT)

• Une interface entre le debugger et le lecteur (TL OCD (On Card Debugger))

Utilisation du debug !

Grace au debug component, on peut aller voir comment se déroule l'exécution d'une applet.

Possible avec les applets qui viennent du SunConverter, puisqu'elles ont un debug component, mais pas possible avec les applets générées par notre outil ;'(

Utilisation des 3 outils :

Driver OCD TLjTOPCT Eclipse Debugger

(12)

Page 12

Démonstration – Lancement du driver de debug

Première étape : utilisation de 'On Card Debuger' de TL

• Établissement d'un contact avec la carte

• Chargement des informations de debug

Lancement du driver. Il vérifie si une carte est accessible dans le lecteur.

Chargement des informations de debug.

Le driver fait le lien entre le lecteur et le debugger;

Le debuggeur se connecte au driver via un remote debug.

Fierté de TL ! Outil propriétaire /!\ Ne pas oublier :D

(13)

Page 13

Démonstration – Connexion avec la carte via driver

Entreprise > Contexte > Problématiques > Solution > Démonstration Seconde étape :

• Connexion avec le driver de debug

• Sélection de l'applet désirée

Une configuration permet de dire a TLJTOP de dialoguer avec le driver (qui retransmet ensuite au lecteur) plutôt que directement avec celui ci.

L'utilisation du debug est complément transparent pour l'utilisation de TljTOPCT On peut voir ici la liste des applets chargées sur la carte. On effectue alors la sélection de notre applet que l'on veut debugger.

(14)

Page 14

Démonstration – Envoi de l'APDU

On peut alors exécuter l'envoie d'APDU (Application Programming Data Unit) qui est le format des données échangées sous forme de requête entre une carte a puce et un terminal.

Ici : x -> exécution APDU

0x -> suite en Hexa

00 -> CLA

00 -> Inst (ADD) 00 00 -> P1 P2 (osef)

04 -> 4 byte de data (LC) 0123 -> 1er data

1111 -> 2eme data

02 -> nombre de byte attendu en réponse (LE)

=> PAS DE DETAIL SUR L'APDU !

On voit que le debugger s'est stop dur le 1er break point dans le process.

(15)

Page 15

Démonstration – Debug du bloc assembleur

On est dans le code du ADD.

Debug de bytecode un part un !

Normalement, on a oublié d'appeler la fonction, donc le patch en définit une nouvelle

Ici, on a copier le code de la fonction du patch : récupération des valeurs (normalement via les symboles) calcul, et affectation du résultat

On voit qu'on a très bien réussi à lire la valeur des champs de la classe.

/!\ IMPORTANT :

Debug step by step dans du code ASM Récupération des valeurs de locales

(16)

Page 16

Démonstration – Bug : appel d'une fonction ASM

Problème dans l'endianness !

On a inversé la position des 2 bytes, il faut les swap Appel d'une fonction entièrement assembleur.

(17)

Page 17

Démonstration – Fonction ASM complète

Grâce à un step into, on se retrouve dans la fonction.

Petit pb : Pas de BP dans une fonction qui ne compile pas - merci Eclipse Ici, on peut voir que grâce à la map, on a déclaré une locale temporaire.

/!\ IMPORTANT :

Fonction tout en assembleur => On peut debug du code TLJCA

(18)

Page 18

Démonstration – Retour de fonction

A la sortie, on remarque que les valeurs sont toujours correctes, et qu'une réponse va être envoyée.

On navigue de fonctions en fonctions (comme dans un debugger :D)

(19)

Page 19

Démonstration – Résultat de la commande

Sur TLJTOP, on peut constater le bon fonctionnement de l'applet qui retourne 0x1234 comme résultat de 0x0123 + 0x1111.

On a pu suivre pas à pas le travail de l'applet, et voir si des bugs subsistaient toujours.

(20)

Page 20

Conclusion

• Entreprise motivante

• Sujet intéressant :

• Proche de mon projet technique

• Recherche & Développement

• Utilisation avec des cas pratiques

• Besoins de Trusted Logic satisfaits

• Réalisation d'un tutoriel pour une formation

Très motivant de travailler dans une entreprise jeune et dynamique.

De plus, le travail sur de nouvelles technologies en constante évolution est d'autant plus motivant quand on est en recherche de nouvelles connaissances.

Le sujet de ce stage m'a bcp intéressé :

Rapprochement avec mon sujet de projet tech

Recherche et développement, une catégorie de travail que j'affectionne tout particulièrement.

La démonstration que je viens de vous faire vous montre le coté très pratique de cet outil !

Je pense que les besoins de Trusted Logic ont été couverts pendant ce stage.

De nombreux tests ont été ajoutés au cours du stage pour montrer la robustesse de l'outil. Je pense que Trusted Logic sont satisfaits de mon travail, puisqu'ils m'ont proposé une place au sein de leur équipe.

(21)

Page 21

Questions

Si vous avez des questions, que ce soit sur le rapport, sur la présentation, ou sur la démonstration !