Présentations

Javacard, les bases

  • Qui suis-je.
  • Qui êtes-vous ? Quelles sont vos attentes.
  • Présentation du plan.

Qui suis-je

  • Développeur d'applications mobiles Android.
  • Formateur Android/Java et Kotlin (scolaires et pros).
  • Ancien employé Gemplus et Gemalto.
  • Co-fondateur (1/7) de Startup Marseille.
    Logo Startup Marseille
  • Fondateur de Light4Events.
    Logo Light4events

Qui êtes vous ?

Tour de table :
  • Prénom.
  • Expérience (Java, JavaCard).
  • Attentes.

Javacard, les bases

Les grandes lignes

Historique

  • 1974 : Dépots de brevets par Roland Moreno.
  • 1978 : M. Ugon (Bull CP8) invente le M.A.M.
  • 1981 : Début de la normalisation AFNOR.
  • 1982 : Expérimentation baptisée «IPSO».
  • 1984 : Adoption de la Carte Bleue (Bull)
    Création du groupement des cartes bancaires.

Historique

  • 1983 : Lancement de la «télécarte» par la D.G.T.
  • Début de la normalisation ISO.
  • Décodeur Canal+ avec une carte mémoire.
  • Depuis 1992 : Essor des applications, premières Javacard.

Usages

  • Bancaire (cartes de débit et de crédit).
  • Téléphonie mobile(GSM) avec les cartes SIM.
  • TV (cartes satellite, ...).
  • Santé (carte Vitale, Sésame).
  • Identité (passeport, carte d'identité).
  • Fidélité.
  • Sécurité sur internet.
  • Transports.
  • Portes monnaie électronique (Proton).

Usages

  • 1997 : EMV, standard international de carte à puce.
  • Affaire Humpich : le secret des CB tombe.
  • 1999 : Lancement de moneo.
  • 2002 : 400 Millions de cartes bancaires.

Production

Le nombre d'élements sécurisés par usage dans le monde :
eurosmart


Source : Eurosmart

Production

eurosmart


Source : Eurosmart

Caractéristiques

Les principales caractéristiques d'une carte à puce sont les suivantes :
  • C'est un objet portable, qui loge des données et des procédures.
  • C'est un objet sécurisé.
  • Il est difficile de lire les données stockées dans les mémoires de la puce.
  • Le code est exécuté dans un espace de confiance, il n'est pas possible (difficile) d'obtenir les clés associées à des algorithmes cryptographiques.
  • C'est un objet de faible prix (1-5$ pour les SPOM, 0,1-0,5$ pour les cartes magnétiques), mais personnalisable pour des milliards d'exemplaires.
  • Une puce ne peut fonctionner seule, elle nécessite un CAD (Card Acceptance Device) qui lui délivre de l'énergie, une horloge (base de temps), et un lien de communication. Un CAD usuel est un lecteur de cartes.
  • Le nombre d'écriture dans la carte (EEPROM) est limité (de 10^4 à 10^6).

2 Familles de cartes

  • Carte à mémoire :
    • Simple mémoire (lecture / écriture) (EPROM / EEPROM).
    • Non standardisé.
  • Carte à microprocesseur :
    • Mémoire + processeur => programmable (algo sécurité : DES, RSA).
    • Normes ISO 7816.
    • Carte à contacts et sans contacts.

Glossaire

AES Advanced Encryption Standard
AID Application IDentifier
APDU Application Protocol Data Unit
API Application Programming Interface
ATR Answer To Reset
BCV ByteCode Verifier
CAP Converted APplet
COS Card Operating System
CRC Cyclic Redundancy Check
DES Data Encryption Standard
ECB Electronic CodeBook
EEPROM Electrically Erasable Programmable Read Only Memory

Glossaire

EMV Europay Mastercard Visa
GP Global Platform
JAR Java ARchive
JCA Java Card Assembly
JCRE Java Card Runtime Environment
JCVM Java Card Virtual Machine
JDK Java Development Kit
MAC Message Authentication Code
NOP No Operation Performed
PIN Personal Identification Number
PIX Proprietary Identifier eXtension
PTS Protocol Type Selection

Glossaire

RAM Random Access Memory
RID Resource IDentifier
ROM Read-Only Memory
RSA Rivest Shamir Adelman
SCQL Smart Card Query Language
SDK Software Development Kit
TDES Triple Data Encryption Standard
TPDU Transmission Protocol Data Unit

ISO/IEC 7816

Les parties

Les caractéristiques des cartes (magnétiques, à puce avec ou sans contact, ...) sont décrites dans la norme :
ISO 7816. Cette norme est composée de plusieurs parties que nous allons détailler :

Caractéristiques physiques

Cette première partie décrit les caractéristiques physiques des cartes, tel que la résistance mécanique, à la torsion, aux UV, rayons X, ... :
ISO 7816-1.
smartcard

Dimensions et emplacements des contacts

Cette partie décrit les dimensions et emplacements des contacts :
ISO 7816-2.
smartcard
ISO/IEC 7816-2 pinout
Pin # Name Description
1 VCC +5 V or 3.3 V DC
2 Reset Card Reset (Optional)
3 CLOCK Card Clock
4 AS Application Specific
5 GND Ground
6 VPP +21 V DC [Programming], or NC
7 I/O In/Out [Data]
8 AS Application Specific

Interface électrique et protocoles de transmission

Cette partie décrit l'nterface électrique et protocoles de transmission :
ISO 7816-3.
Nous y trouverons par exemple :
  • Les caractéristiques électriques.
  • L'activation, désactivation et remise à zéro de la carte.
  • L'encodage des messages.
  • La réponse à la remise à zéro (Answer to Reset).
  • TPDU (Transmission Protocol Data Unit).
  • Le protocole T=0, half-duplex, communication par caractères.
  • Le protocole T=1, half-duplex, communication par blocs.
  • Le format des commandes :
    CLASSE INSTRUCTION PARAMETRE1 PARAMETRE2 LONGUEUR
    CLASS INS P1 P2 LEN.

Organisation, sécurité et commandes pour les échanges

Cette partie décrit l'organisation, sécurité et commandes pour les échanges :
les APDU (Application Programming Data Units) :
ISO 7816-4.
Nous y trouverons par exemple :
  • Les classes d'instruction (CLA).
  • L'encodage TLV (Tag Length Value).
  • L'encodage BER TLV ( T 8105 Value, T 8400000005 Value).
  • Authentification.
  • Récupération des données.

Système de fichiers

Le système de fichiers hiérarchique peut contenir 3 types de fichiers :
  • "Master File" (Fichier racine) : 3F00.
  • "Dedicated File" (Répertoire + qq infos).
  • "Elementary File" (Fichier de données).
smartcard

Types de fichiers

Selon les informations à enregistrer, nous disposons de différents types de fichiers :
  • Transparent.
  • Taille Fixe.
  • Taille variable.
  • Cyclique.
smartcard

Enregistrement des fournisseurs d'application

Cette partie décrit les procédures d'nregistrement des fournisseurs d'application :
ISO 7816-5.
Nous y trouverons par exemple :
  • L'enregistrement des identifiants à l'international.
  • Le Registration Management Group (RMG).
  • L'authorité d'enregistrement.

Éléments de données intersectoriels pour les échanges

Cette partie décrit les éléments de données intersectoriels pour les échanges :
ISO 7816-6.
Nous y trouverons par exemple, le format des données enregistrées (nom, description, format, encodage, ...) sur une carte, magnétique, à puce, avec ou sans contact.

Structured Card Query Language

Cette partie décrit le système de base de donnée SCQL :
ISO 7816-7.
Nous y trouverons par exemple :
  • Les principes de la base de donnée, des tables, des champs, des vues, ...
  • Langage spécifique de requêtes : SCQL (Smart Card Query Language).
  • Le format des requêtes.
  • Les opérations disponibles (CREATE TABLE, CRUD, GRANT, ...).
  • Le système de transaction.
  • La gestion des utilisateurs.

Structured Card Query Language

smartcard

Commandes et mécanismes pour les opérations de sécurité

Cette partie décrit les usages dans le domaine de la sécurité :
ISO 7816-8.
Nous y trouverons par exemple :
  • La génération de clés asymétriques.
  • Des exemples d'opérations de signature numérique.
  • Des exemples de certificats interprétés par la carte.
  • Des exemples de transfert de clés asymétriques.
  • Des exemples d'utilisation des clés asymétriques.

Commandes pour la gestion des cartes

Cette partie décrit les commandes pour la gestion des cartes :
ISO 7816-9.
Nous y trouverons par exemple :
  • La gestion du cycle de vie de la carte (avant la mise sur le marché, jusqu'à la fin de vie de la carte).
  • La création et l'effacement de fichiers, la gestion des accès, ...
  • Des exemples de contenu de cartes.
  • Des exemples de chargement de données dans la carte (clés/secrets, code et applications).

Signaux électroniques et réponse à la mise à zéro des cartes synchrones

Cette partie décrit les signaux électroniques et réponse à la mise à zéro des cartes synchrone :
ISO 7816-10.
Nous y trouverons par exemple :
  • L'alimentation de la carte (tension et courant).
  • La définition des rôles des contacts de la carte.
  • La structure des signaux de communication.
  • La gestion des fréquences de communication.
  • La description du contenu du message de réponse à une mise à zéro de la carte ( Answer To Reset : ATR ).

Vérification personnelle par méthodes biométriques

Cette partie décrit la vérification personnelle par méthodes biométriques :
ISO 7816-11.
Nous y trouverons par exemple :
  • Les méthodes de validation d'identité, utilisant des caractéristiques biométriques.
  • Des exemples de format de données biométriques.
  • L'inscription des données.

Interface électrique USB et procédures de fonctionnement

Cette partie décrit l'interface électrique USB et procédures de fonctionnement :
ISO 7816-12.
Nous y trouverons par exemple :
  • La gestion électrique de l'interface.
  • Les descripteurs et classes USB.
  • Les protocoles de communications.
  • Le mode de communication asynchrone.
  • La gestion des erreurs.

Commandes pour la gestion d'application dans un environnement de plusieurs applications

Cette partie décrit les commandes pour la gestion d'application dans un environnement de plusieurs applications :
ISO 7816-13.
Nous y trouverons par exemple :
  • Le cycle de vie d'une application dans un environnement multi applications.
  • Commandes de chargement, d'effacement et de gestion des applications.
  • Des exemples de gestion des applications.

Application des informations cryptographiques

Cette partie décrit les fonctions cryptographiques d'une carte :
ISO 7816-15.
Nous y trouverons par exemple :
  • Le stockage de plusieurs instances d'informations cryptographiques.
  • L'utilisation des informations cryptographiques.
  • La récupoération des informations cryptographiques.
  • Les différents mécanismes d'authentifications.
  • Les divers algorithmes cryptographiques.
  • La gestion de clé publiques, privées, de certificats, ....

Plates-formes ouvertes pour cartes à puces

Plusieurs solutions

Avant l'arrivée de cartes basées sur des plates-formes ouvertes, les applications étaient développées spécifiquement pour une carte propriétaire.
Trois plates-formes ont vu le jour :

Windows for Smart Card

Cet OS dévoilé en 1999 par Microsoft basé sur le langage Visual Basic n'existe plus. Probablement du fait de sa nature propriétaire.

Multos

Les cartes MULTOS peuvent être écrites en Java, C ou en langage assembleur MULTOS (le Visual Basic utilisant l'outil SwiftCard ayant été abandonné).
Le code compilé en MULTOS Executable Language (MEL) est interprété par la machine virtuelle présente sur la carte.
La machine virtuelle permet d'assurer la sécurité d'exécution des applications.

Java Card

Présentation

  • Langage à objet simplifié pour carte à puce.
  • 1996 : Sun adopte le JavaCard (Schlumberger).
  • 1997 : Java Card Forum (Bull,Gemplus et Schlumberger).
  • 2000 : 40 entreprises ont une licence d'exploitation.

Architecture

  • Peu de mémoire
    • 1Ko de RAM, 16Ko d'EEPROM et de 24Ko de ROM.
    • Supporte un sous-ensemble du langage Java.
    • Machine virtuelle en 2 étapes (On-card et Off-card).
  • Java Card Runtime Environment
    • Machine virtuelle Javacard.
    • APIs.
    • Méthodes natives.
archi

Éléments supportés

  • Les types primitifs : boolean, byte et short.
  • Le type primitif int est optionnel.
  • Tableau à une dimension
  • Paquetages, classes, interfaces et exceptions.
  • Héritages, objets virtuels, surcharge et création d'objets (new).

Principaux éléments non supportés

  • Type simple de donnée de grosse taille : long, double et float.
  • Tableau à plusieurs dimensions.
  • Caractères et chaînes.
  • Chargement dynamique des classes.
  • Security Manager.
  • Ramasse-miettes et finalisation.
  • Threads.
  • Sérialisation d'objet.
  • Clonage d'objet.

Avantages

  • Facilité de développement (Java).
  • Sécurité.
  • Portabilité.
  • Stockage et gestion de multiples applications.
  • Compatibilité.

JVM Java Card

Architecture simple

archi

Architecture V3

archi v3

Fichiers mis en oeuvre

  • CLASS : Version compilée du code.
  • JCA : Fichier ASCII permettant de tester et de débugger l'Applet. Utilisé pour produire le JAR.
  • JAR : Le fichier qui regroupe les CAP qui seront chargés sur la carte.
  • CAP : Converted APplet le code optimisé, chargé dans la carte.
  • IJC : Optimisation de la taille des fichiers à charger.
  • EXP : L'équivalent des fichier .h en C.
    Il contient l'interface publique du package.

Class à CAP

De Class à CAP

Class à CAP (détails)

De Class à CAP2

Firewall

JVM firewall

Chargement sur la carte

Chargement d'une Applet dans la carte :
archi

Chargement sur la carte (suite)

archi

Sécurité

Mécanisme de paiement par carte bleue

  • Authentification de la carte : Algo RSA, fonctions de tests, identifie la carte de manière unique.
archi

Mécanisme de paiement par carte bleue

  • Code confidentiel : Terminal de paiement envoie requête à la carte, la carte calcule puis envoi sa réponse au terminal.
archi
  • Authentification de la transaction : Algo DES et TDES, fonctions de tests, code les informations de la transaction.

Le standard EMV

(Europay Mastercard Visa)
  • Transaction cryptée par TDES avec une clé de 90 bits.
  • Signature RSA était de 896 bits.
  • Signature RSA est actuellement (depuis 2018) de 1408 bits.
  • Signature RSA doit passer à 1984 bits (en 2025) et sera valable jusqu'en 2027.
  • Protocole d’authentification statique : 1 contrôle de certificats.
  • Protocole d’authentification dynamique : 3 contrôles de certificats en cascade
    Nécessite des cartes puissantes et des ressources.
Sources dates tailles clés.

APDU

Définition

APDU call
APDU call

APDU Détails

Requête Réponse
CLA INS P1 P2 Lc [Lc octets] sw1 sw2
CLA INS P1 P2 Le [Le octets] sw1 sw2
CLA INS P1 P2 Lc [Lc octets] 61 Le
CLA C0 00 00 Le (GET RESPONSE) [Le octets] sw1 sw2

Format des APDU : CLA

CLA.
Ce paramètre est définit pour des types de cartes particuliers ou par des fabricants particuliers.
00 est la valeur ISO, A0 pour les cartes SIM, BC a été utilisé par Bull CP8, FF est réservé pour le protocole PTS.
Le quartet de poids fort est défini par le standard ISO 7816 pour les valeurs 0,8,9 et A. Dans ce cas le quartet de poids faible comporte deux bits qui indiquent l’usage du Secure Messaging (SM - signature et chiffrement des APDUs), et les deux derniers bits désignent un numéro de canal logique (compris entre 0 et 3).
L’utilisation du service SM n’est pas détaillée dans ce cours.
La notion de canal logique consiste à utiliser simultanément plusieurs application logées dans la carte.

Format des APDU : INS

READ_BINARY
CLA B0 P1 P2 Le
Réalise la lecture de Le octets à partir de offset dans un fichier transparent.
  • Si le bit de poids fort de P1 est égal à 1, EF est désigné par les 5 bits de poids faible, P2 représente l’offset.
  • Sinon l’offset est égal à (256*P1) +P2.

Format des APDU : INS

WRITE_BINARY
CLA D0 P1 P2 Lc [Lc octets]
Réalise l’écriture de Le octets à partir de offset dans un fichier transparent.
  • Si le bit de poids fort de P1 est égal à 1, EF est désigné par les 5 bits de poids faible, P2 représente l’offset.
  • Sinon l’offset est égal à (256*P1) +P2.

Format des APDU : INS

UPDATE_BINARY
CLA D6 P1 P2 Lc [Lc octets].
Réalise l’écriture de Le octets à partir de l'offset dans un fichier transparent.
  • Si le bit de poids fort de P1 est égal à 1, EF est désigné par les 5 bits de poids faible, P2 représente l’offset.
  • Sinon l’offset est égal à (256*P1) +P2.

Format des APDU : INS

ERASE_BINARY
CLA 0E P1 P2 [Lc=2 ou non présent] [2 octets ou rien]
Efface le fichier à partir de l’adresse jusqu’à la fin du fichier.
  • Si Lc=2, l’offset est indiquée par les deux octets de données.
  • Sinon si le bit de poids fort de P1 est égal à 1, EF est désigné par les 5 bits de poids faible, P2 représente l’offset.
  • Sinon l’offset est égal à (256*P1) +P2.

Format des APDU : INS

READ_RECORD
CLA B2 P1 P2 Le
Lit un enregistrement dans un fichier.
  • P1, numéro d’enregistrement ou premier enregistrement à lire égal à 00 indique l’enregistrement courant.
  • P2= 04 lecture de l’enregistrement P1=05 lecture des enregistrements à partir de P1 jusqu'à la fin du fichier.

Format des APDU : INS

WRITE_RECORD
CLA D2 P1 P2 Lc [lc octets]
Écriture d’un enregistrement.
  • P1 numéro d’enregistrement.
  • P2=04 enregistrement P1.

Format des APDU : INS

APPEND_RECORD
CLA E2 P1 P2 Lc [Lc octets]
Pour P1 = P2 =0, cette commande ajoute un nouvel enregistrement à la fin d’un fichier à structure linéaire ou réalise l’écriture du premier enregistrement d’un fichier cyclique.

Format des APDU : INS

UPDATE_RECORD
CLA DC P1 P2 Lc [Lc octets]
Cette commande réalise la mise à jour d’un enregistrement.
Lorsque P2=04 P1 indique la valeur de l’enregistrement.

Format des APDU : INS

GET_DATA
CLA CA P1 P2 Le
Cette commande permet d’obtenir un objet identifié par son tag (P1 P2) dans le contexte courant (par exemple le DF sélectionné ou relatif à une implémentation particulière).

Format des APDU : INS

PUT_DATA
CLA DA P1 P2 Lc [Lc octets]
Cette commande insère un objet dans le contexte courant (DF sélectionné ou relatif à une implémentation particulière).
P1 P2 désigne le type (tag) de l’objet.

Format des APDU : INS

SELECT_FILE
CLA A4 P1 P2 Lc [Lc octets] [Le ou omis]
Sélectionne un répertoire ou un fichier.
  • P1 = 00 (sélection par identifiant MF DF EF).
  • P1= 01 (sélection DF).
  • P1=02 (sélection EF).
  • P1= 03 (Sélection du père du DF courant).
  • P2 =00 première occurrence.

Format des APDU : INS

VERIFY
CLA 20 P1 P2 Lc(ou omis) [Lc octets]
Cette commande réalise la vérification d’un mot de passe.
Le nombre d’essai peut être limité.
En général P1=P2=0.

Format des APDU : INS

INTERNAL_AUTHENTICATE
CLA 88 P1 P2 Lc [Lc octets] Le
Cette commande réalise un calcul d’authentification relativement à une clé interne en transférant un nombre aléatoire (challenge) délivré par le lecteur.
  • P1 représente la référence d’un algorithme.
  • P2 est égal à zéro par défaut.
Le challenge est contenu dans les Lc octets sortants.

Format des APDU : INS

EXTERNAL_AUTHENTICATE
CLA 88 P1 P2 Lc[Lc octets] Le
Cette commande met à jour l’état d’une carte en fonction du résultat d’un calcul réalisé par le lecteur à partir d’un nombre aléatoire délivré par la carte (CHALLENGE).
  • P1, référence d’un algorithme.
  • P2 est égal à zéro par défaut.

Format des APDU : INS

GET_CHALLENGE
CLA 84 P1 P2 Le
Cette commande produit un nombre aléatoire de Le octets.

Format des APDU : INS

GET_RESPONSE
CLA C0 P1 P2 Le
Cette commande est utilisé pour lire de l’information depuis la carte lorsque le protocole de transport ne le permet pas directement (par exemple T=0).

Format des APDU : INS

ENVELOPE
CLA C2 P1 P2 Lc [Lc octets] Le ou omis
Cette commande est utilisée par les ordres entrant/sortant lorsque le protocole de transport ne les supportent pas (par exemple T=0).

Carte SIM

Présentation

Une carte SIM réalise les fonctions suivantes :
  • Identification et authentification d’un abonné.
  • Confidentialité des données inchangées.
  • Sécurisation des accès aux fichiers à l’aide d’un PIN code.

Présentation

Elle intègre pour l’essentiel :
  • Un identifiant d’abonné GSM (IMSI).
  • Une clé secrète (Ki) associée aux algorithmes cryptographiques A3 et A8, qui permettent l’authentification d’un client.
  • Un algorithme RUN_GSM_ALGORITHM() qui calcule une signature SRES et une clé de chiffrement Kc à partir d’un nombre aléatoire (RAND).
  • Un système de fichier avec sous répertoire DF est 7F20, qui contient en particulier un fichier IMSI (EF_6F07), deux fichiers d’annuaire (phonebook) et un fichier stockant les messages SMS.
  • 22 APDUs sont supportées.
    Une carte comporte deux PIN codes (CHV1 et CHV2, Card Holder Verification Information) et deux codes (PUK) de déblocage associés UNBLOCK CHV1 et UNBLOCK CHV2.

APDUs disponibles

SIM APDU list

Status Word

SIM SW list

Status Word

SIM SW list

Environnement de développement

JavaCardOs

Afin de développer notre première applet, nous allons commencer par installer un environnement de développement : JavaCardOs.
Allons sur : JavaCardOs, et téléchargeons JCKit Release Version v7.1.0.0.

Lancement

Lançons JCIDE.
Home de JCIDE

Création d'un projet

Menu : File / New / Project
Création du projet

Nom du projet

  • Nom : HelloWorld
  • Path : HelloWorld
  • JC : java_card_kit-2_2_2
Nom du projet

Package

  • Package Name : fr.salaun.tristan.javacard.helloworld
  • Package AID : 74 72 69 73 74 61 6e 73 61 6c 61 75 6e 68 65 6c
  • New Applet
Nom du package

Applet

  • Applet Name : HelloWorld
  • Package AID : 74 72 69 73 74 61 6e 73 61 6c 61 75 6e 68 65 00
Nom de l'Applet

Code de L'Applet


package fr.salaun.tristan.javacard.helloworld;

import javacard.framework.*;
import javacard.security.RandomData;

public class HelloWorld extends Applet
{


	private static final short BUFFER_SIZE = 32;

	private byte[] tmpBuffer = JCSystem.makeTransientByteArray(BUFFER_SIZE, JCSystem.CLEAR_ON_DESELECT);
	private RandomData random;

	public static void install(byte[] bArray, short bOffset, byte bLength)
	{
		// new HelloWorld().register(bArray, (short) (bOffset + 1), bArray[bOffset]);
		new HelloWorld(bArray, bOffset, bLength);
	}

	protected HelloWorld(byte[] bArray, short bOffset, byte bLength){
		//random = RandomData.getInstance(RandomData.ALG_SECURE_RANDOM);
        random = RandomData.getInstance(RandomData.ALG_PSEUDO_RANDOM);
        register(bArray, (short) (bOffset + 1), bArray[bOffset]);
	}

	public void process(APDU apdu)
	{
		if (selectingApplet())
		{
			return;
		}

		byte[] apduBuffer = apdu.getBuffer();
		byte cla = apduBuffer[ISO7816.OFFSET_CLA];
		byte ins = apduBuffer[ISO7816.OFFSET_INS];
		short lc = (short)apduBuffer[ISO7816.OFFSET_LC];
		short p1 = (short)apduBuffer[ISO7816.OFFSET_P1];
		short p2 = (short)apduBuffer[ISO7816.OFFSET_P2];

		random.generateData(tmpBuffer, (short) 0, BUFFER_SIZE);

		Util.arrayCopyNonAtomic(tmpBuffer, (short)0, apduBuffer, (short)0, BUFFER_SIZE);
		apdu.setOutgoingAndSend((short)0, BUFFER_SIZE);
	}
}

Configuration simulateur

  • Menu : Tool / IDE Options
  • Run/Debug / Check Enable PCSC Interface
Configuration
Configuration PCSC

Lancement Applet

  • Menu : Debug / Go (F5)
Run

Lancement Applet

  • Affichage en vert de : You can send apdu with PC/SC interface now
Run ok

Lancement Client

  • Lancer le programme : PyApduTool
PyApduTool

Connectons le lecteur

  • Cliquons sur : Connect
Connect

Sélectionnons l'Applet

  • Menu : Manager
  • Cap File Path
  • Select
Select Applet

Appelons l'Applet

  • Menu : Apdu
  • CLA : 00 : Canal par défaut.
  • INS : 00 : Peu importe la valeur.
  • P1 : 00 : Peu importe la valeur.
  • P2 : 00 : Peu importe la valeur.
  • LE : 00 : Taille de la réponse attendu : 0 bytes.
  • => SW : 6C 20.
Appel Applet
Pourquoi avons nous un retour en erreur, et que doit on modifier ?

Appelons l'Applet

  • Menu : Apdu
  • CLA : 00 : Canal par défaut.
  • INS : 00 : Peu importe la valeur.
  • P1 : 00 : Peu importe la valeur.
  • P2 : 00 : Peu importe la valeur.
  • LE : 20 : Taille de la réponse attendu : 32 bytes (20 en hexa).
  • => Recv: 24 F7 C7 78 62 55 0F 62 52 A2 61 02 61 FC 39 C3 77 9F DE 4C AD 9D 47 31 51 20 60 4A 99 9E 92 27 90 00.
Appel Applet OK

Allons plus loin

  • Effaçons l'applet.
  • Laçons la commande pour récupérer le random.
  • Sélectionnons l'Applet.
  • Chargeons l'Applet.
  • Installons l'Applet.
  • Sélectionnons l'Applet.
  • Laçons la commande pour récupérer le random.

Ligne de commande JCIDE

  • Dans l'écran : Debug Shell -Debug
  • /select 7472697374616E73616C61756E686500.
  • /send 000000000020.
Run ok

Cycle de vie d'une Applet

Les méthodes principales

La classe javacard.framework.Applet comporte 8 méthodes principales :
  • static void install(byte[]bArray, short bOffset, byte bLength) throws ISOException
    Cette méthode est utilisée par l’entité JCRE lors de l’installation d’un applet. Le paramètre indique la valeur de l’AID associé à l’application. Les objets nécessaires à l’application sont crées lors de l’appel de cette procédure (à l’aide de l’opérateur new).
  • protected final void register() throws SystemException
    Cette méthode réalise l’enregistrement de l’applet avec l’AID proposée par le JCRE.
  • protected void register(byte[]bArray, short bOffset, byte bLength)
    Cette méthode enregistre l’applet avec un AID spécifié dans les paramètres d’appel.
  • public boolean select()
    Cette méthode est utilisée par le JCRE pour indiquer à l’applet qu’il a été sélectionné. Elle retourne la valeur true.

Les méthodes principales

  • protected final boolean selectingApplet()
    Indique si un APDU SELECT (CLA=A4) est associé à l’opération de sélection de l’applet.
  • public void deselect()
    Cette méthode notifie la désélection de l’applet.
  • public Shareable getShareableInterfaceObject(AID clientAID, byte parameter)
    Cette méthode est surchargée par une application (serveur) qui désire offrir une interface partageable.
  • public abstract void process(APDU apdu) throws ISOException
    Cette méthode est la clé de voûte d’un applet. Elle reçoit les commandes APDUs et construit les réponses. L’exception ISOException comporte une méthode ISOException.throwIt(short SW) utilisée pour retourner le status word (SW) d’un ordre entrant.

Le traitement des APDUs

De la classe javacard.framework.APDU :
  • public short setIncomingAndReceive() throws APDUException
    Cette méthode retourne le paramètre Lc d’une commande entrante. Les Lc octets sont mémorisés à partir de l’adresse 5 du buffer (tampon) de réception.
  • public void setOutgoingAndSend(short bOff, short len) throws APDUException
    Cette méthode transmet un message de réponse contenu dans le tampon de réception. Dans le cas d’une APDU sortante (Lc=0 ET Le#0) le statut 9000 est ajouté à la fin du message. Dans le cas d’une APDU entrante et sortante (Lc#0 et Le#0) le mot de statut 61 Le est généré afin de permettre une lecture ultérieure par un GET_RESPONSE (CLA C0 00 00 Le).


Divers & utile : De la classe javacard.framework.ISOException :
  • public static void throwIt(short sw)
    Permet de quitter la méthode process en générant un mot de statu SW. La classe ISO7816 contient une liste de valeurs utiles.

Le traitement des APDUs

De la classe javacard.framework.Util :
  • public static final short arrayCopy(byte[] src, short srcOff, byte[] dest, short destOff, short length)
    ET
    public static final short arrayCopyNonAtomic(byte[] src, short srcOff, byte[] dest, short destOff, short length)
    Réalisent des transferts de mémoire à mémoire avec ou sans atomicité.
  • public static final short makeShort(byte b1, byte b2)
    Fabrique un entier short à partir de deux octets.

Le cycle de vie de la carte

Le cycle de vie d’une carte se divise en cinq états :
  1. OP_READY
  2. INITIALIZED
  3. SECURED
  4. CARD_LOCKED
  5. TERMINATED

Le cycle de vie de la carte

Les deux premiers états (OP_READY et INITIALIZED) sont actifs lors des phases dites de pré émission de la carte. Les états restant seront observés lors des phases qualifiées de post- émission.

L’état OP_READY indique que l’environnement d'exécution et le domaine de sécurité de l’émetteur (issuer) sont disponibles.
Ce dernier peut recevoir, exécuter, et répondre aux commandes APDUs générées par le système hôte.

L’état INITIALIZED est actif lors de la production de la carte. Il permet de transférer des données initiales dans la carte (les clés du domaine de sécurité de l’émetteur par exemple).
La transition de l’état OP_READY à INITIALIZED est irréversible.

Le cycle de vie de la carte

Dans l’état SECURED, l’entité Card Manager contrôle la politique de sécurité en phase de post émission (par exemple le chargement, installation, activation de domaines de sécurité ou d’applications, …).
La transition de l’état INITIALIZED à SECURED est irréversible.

Dans l’état CARD_LOCKED, la carte est contrôlée uniquement par le domaine de sécurité de l’émetteur.
La transition entre l’état SECURED et CARD_LOCKED est réversible.

L’état TERMINATED, signifie la fin du cycle de vie de la carte.
La transition à cet état peut s’effectuer à partir de n’importe quel état mais est irréversible.

Cycle de vie d’une application

Une application comporte trois états :
  1. INSTALLED
  2. SELECTABLE
  3. LOCKED

Dans l’état INSTALLED, le code et les données de l’application sont chargés en mémoire.

L’état SELECTABLE indique que l’application est prête à recevoir des commandes (APDUs) du système hôte; elle est responsable de la gestion de son cycle de vie.
La transition de l’état INSTALLED à SELECTABLE est irréversible.
Cependant, dans l’état SELECTABLE une application peut gérer un sous état propre, qualifié de SPECIFY.

L’état LOCKED interdit la sélection et l’exécution de l’application.
La transition vers l’état LOCKED est réversible et contrôlé par le domaine de sécurité de l’émetteur.

Javacard avec InteliJ

Installation

Allons sur le site de Jet Brains pour télécharger IntelliJ IDEA Community.

Creation projet avec JcardSim

Menu File/ New / Project :
Création du projet
Choisir : Gradle / Java :
Type de projet
  • fr.salaun.tristan.javacard.jcardsim
  • JcardSimTest
Nom de l'artefact
Laisser tout par défaut :
Nom du projet
Ouvrons le fichier build.gradle :
Ajout de dépendance
Dans la balise dependencies, Alt + Inser, puis : Add Maven artifact dependency :
Ajout de dépendance
Cherchons jcardsim, sélectionnons la dernière version :
Ajout de dépendance
Créons maintenant notre classe client, click droit sur Project / JcardSimTest / src / main / java :
Ajout d'une classe
Nommons la, par exemple JcardSimClient :
Nommage de la classe
Créons maintenant notre classe client, click droit sur Project / JcardSimTest / src / main / java :
Ajout d'une classe
Ajoutons le code suivant :

import com.licel.jcardsim.base.Simulator;
import com.licel.jcardsim.samples.HelloWorldApplet;
import javacard.framework.AID;

import javax.smartcardio.CommandAPDU;
import javax.smartcardio.ResponseAPDU;
import java.nio.charset.StandardCharsets;

public class JcardSimClient {

    public static void main(String[] args) {
        // 1. create simulator
        Simulator simulator = new Simulator();

        // 2. install applet
        AID appletAID = new AID(new byte[]{(byte) 0xF0, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x01}, (short) 0, (byte) 5);
        simulator.installApplet(appletAID, HelloWorldApplet.class);

        // 3. select applet
        simulator.selectApplet(appletAID);

        // 4. send APDU echoWorld
        CommandAPDU commandAPDU = new CommandAPDU(0x00, 0x01, 0x00, 0x00);
        byte[] responseBytes = simulator.transmitCommand(commandAPDU.getBytes());

        ResponseAPDU response = new ResponseAPDU(responseBytes);

        // 5. check response
        System.out.println(JavaCardTools.bytesToHex(response.getBytes()));
        System.out.println(Integer.toHexString(response.getSW()));
        System.out.println(new String(response.getData(), StandardCharsets.UTF_8));

        // 6. send APDU echoWorld2
        commandAPDU = new CommandAPDU(0x00, 0x03, 0x00, 0x00, "Bonjour le monde".getBytes());
        responseBytes = simulator.transmitCommand(commandAPDU.getBytes());
        response = new ResponseAPDU(responseBytes);
        System.out.println(JavaCardTools.bytesToHex(response.getBytes()));
        System.out.println(Integer.toHexString(response.getSW()));
        System.out.println(new String(response.getData(), StandardCharsets.UTF_8));

        // 7. send APDU echoWorld2
        commandAPDU = new CommandAPDU(0x00, 0x07, 0x00, 0x00);
        responseBytes = simulator.transmitCommand(commandAPDU.getBytes());
        response = new ResponseAPDU(responseBytes);
        System.out.println(JavaCardTools.bytesToHex(response.getBytes()));
        System.out.println(Integer.toHexString(response.getSW()));
        System.out.println(new String(response.getData(), StandardCharsets.UTF_8));
    }
}
Avec la classe utilitaire JavaCardTools :

public class JavaCardTools {
    private static final char[] HEX_ARRAY = "0123456789ABCDEF".toCharArray();
    public static String bytesToHex(byte[] bytes) {
        char[] hexChars = new char[bytes.length * 2];
        for (int j = 0; j < bytes.length; j++) {
            int v = bytes[j] & 0xFF;
            hexChars[j * 2] = HEX_ARRAY[v >>> 4];
            hexChars[j * 2 + 1] = HEX_ARRAY[v & 0x0F];
        }
        return new String(hexChars);
    }
}

Applet de JCIDE

Prenons le code de l'applet HelloWorld utilisé dans JCIDE, intégrons le dans notre projet InteliJ. Remplaçons :

register(bArray, (short) (bOffset + 1), bArray[bOffset]);
par :

register();
Il ne nous reste plus qu'à adapter le code de notre client.

SIM Toolkit

Les commandes Proactive

La carte peut "prendre le contrôle" du fil d'exécution.
  • TERMINAL PROFILE
  • Du Terminal (le téléphone par exemple) à la carte (UICC).
  • Déclaration des fonctionnalités prises en charge.

Exemples de commandes

Les principales commandes disponibles sont :
  • DISPLAY TEXT : Affichage d'un texte.
  • GET INPUT : Saisie par l'utilisateur d'un caractère.
  • GET INKEY : Saisie par l'utilisateur d'une chaîne de caractère.
  • MORE TIME : Demande plus de temps au terminal, pour terminer le traitement en cours.
  • PLAY TONE : Demande au terminal de jouer une sonnerie.
  • POLL INTERVAL : Demande au terminal d'envoyer une commande STATUS à interval régulier.
  • REFRESH : Demande au terminal de rafraîchir ses informations (par exemple lire de nouveau les fichiers).
  • SET UP MENU : Demande au terminal d'ajouter des entrées à son menu.
  • SELECT ITEM : Affichage d'une liste pour que l'utilisateur choisisse.
  • SEND SHORT MESSAGE : Demande au terminal d'envoyer un SMS.
  • SET UP CALL : Demande au terminal d'initier un appel téléphonique.

Exemple de session STK

ts_102223v090100p.pdf, Annexe D, page 178.
cours_cartes_urien-2008.pdf, Page 65.

Exemple de code

Étudions un peu plus précisément un exemple de code d'Applet STK.
HelloSTK.java

Javacard 3.0

Introduction

Version Java Card 3 « Connectée »
La version 3 « Connectée » des spécifications de la plate-forme Java Card présente des différences profondes avec les autres versions existantes.
Tout d'abord, alors que les versions antérieures ne pouvaient charger que des fichiers binaires spécifiques (les fichiers CAP), les applications Java Card 3 « Connectées » sont déployées sous forme de fichiers java compilés de façon conventionnelle (des fichiers .class) regroupés dans des fichiers .jar, à l'instar des machines virtuelles java conventionnelles. Il n'est alors plus nécessaire d'avoir recours à des outils de conversions de code.

Par ailleurs Java Card 3 « Connectée » privilégie le mode de communication de l'internet : les protocoles internet via norme IP ISO 7816-4 pour les interfaces « avec contacts ». La norme ISO 14443 est elle utilisée pour les interfaces «sans contact». Les applications Java Card 3 « Connectées » sont en fait, des Servlets, c'est-à-dire de véritables Services Web, qui respectent, à ce titre, le protocole HTTP.

La machine virtuelle Java Card 3 est basée sur le CLDC largement utilisé dans le monde de la téléphonie mobile. Cette plate-forme donne accès aux fonctionnalités les plus riches du langage JAVA9. La plate-forme CLDC a été réduite en taille, les protocoles et les systèmes sécurités de cartes à puce ont été intégrés.
Carte à puce traditionnelle Carte à puce récente compatible V3
8/16-bit CPU 32-bit CPU
2 kb RAM 24 kb RAM
48 kb - 64 kb ROM >256 kb ROM
8–32 kb EEPROM >128 kb EEPROM
Serial I/O interface High-speed interfaces
9,6 kb/s - 30 kb/s 1,5 Mb/s - 12 Mb/s
Full duplex Half duplex

Amélioration apportée par la version 3 connectée

  • Applications de type servlets.
  • Gestion de multitâches (Multithreading).
  • Vérification par byte code interne (Vérification de.class par la machine virtuelle interne).
  • Ramasse Miette automatique (Garbage collector) inclut dans la machine virtuelle.
  • Ajout des types Char, Long et String.
  • Tableau multidimensionnel.
  • Classe représentant les types primitifs (Boolean, Integer,...).
  • Classe de la manipulation de Chaines de caractères (StringBuilder...).
  • Classe pour la gestion des Entrées/Sorties (Reader, Writer et Stream).
  • Classe pour la gestion du réseau.
  • Classe pour la gestion des collections (Vector, hashtable..).
  • Classe pour la gestion des dates.
  • Classe pour la gestion de la localisation et de l’internationalisation.
Le langage de programmation a été étoffé de spécificités issues de Java SE :
  • Générics.
  • Métadonnées.
  • Autoboxing.
  • Amélioration de la boucle for.
  • Assert (test unitaire).
  • Énumération.
  • Utilisation de méthodes à argument Variables.
  • Import static.

Limitation du moteur de servlet de java card V3

Liste des principales caractéristiques présentes dans les spécifications Java Servlet 2.4 (Novembre 2003) qui ne sont pas supportées par la plate-forme Java Card V3 :
  • API non supportées (java.io.File, java.net.URL, java.util.Map, java.util.Set, java.security.cert.X509Certificate...). Par exemple, il est impossible d'effacer un fichier avec la méthode delete de la classe java.io.File, impossible d’utiliser la structure hashmap, impossible d'utiliser la gestion des certificats X509 (RFC 245936).
  • Nombre flottant (float). Il est impossible de réaliser des opérations sur des nombres à virgules.
  • Sérialisation et clonage d'objets (java.io.Serializable, java.lang.Cloneable). Il impossible de convertir les objets en flux binaire pour gérer persistance. Il est impossible de créer de nouvelles instances à partir d'une référence d'objet (clone).
  • Support des Java Server Pages V2.0. Les balises JSP ne sont pas reconnues, donc obligation d'écrire des servlets en Java.
  • Java Naming and Directory Interface. Pas d’accès aux classes de gestion d'annuaires.

Workshop

Exemples à étudier

Servlets

Servlet

Suivons le tutoriel proposé par Netbeans pour créer notre première Servlet :
http://netbeans.apache.org/kb/docs/javame/java-card.html.

Références

Javacard

La carte SIM

Développement

STK

Gestion de la carte

Simulateurs

Annexe

Liste de Status Word connus

Nous pouvons trouver une liste de SW connus à l'adresse suivante :
https://www.eftlab.com/knowledge-base/complete-list-of-apdu-responses/.
SW1 SW2 Message
'6X XX' Transmission protocol related codes
'61 XX' SW2 indicates the number of response bytes still available
'62 00' No information given
'62 81' Returned data may be corrupted
'62 82' The end of the file has been reached before the end of reading
'62 83' Invalid DF
'62 84' Selected file is not valid. File descriptor error
'63 00' Authentification failed. Invalid secret code or forbidden value
'63 81' File filled up by the last write
'63 CX' Counter provided by 'X' (valued from 0 to 15) (exact meaning depending on the command)

Liste de Status Word connus

SW1 SW2 Message
'65 01' Memory failure. There have been problems in writing or reading the EEPROM.
Other hardware problems may also bring this error.
'65 81' Write problem / Memory failure / Unknown mode
'67 XX' Error, incorrect parameter P3 (ISO code)
'67 00' Incorrect length or address range error
'68 00' The request function is not supported by the card.
'68 81' Logical channel not supported
'68 82' Secure messaging not supported

Liste de Status Word connus

SW1 SW2 Message
'69 00' No successful transaction executed during session
'69 81' Cannot select indicated file, command not compatible with file organization
'69 82' Access conditions not fulfilled
'69 83' Secret code locked
'69 84' Referenced data invalidated
'69 85' No currently selected EF, no command to monitor / no Transaction Manager File
'69 86' Command not allowed (no current EF)
'69 87' Expected SM data objects missing
'69 88' SM data objects incorrect

Liste de Status Word connus

SW1 SW2 Message
'6A 00' Bytes P1 and/or P2 are incorrect.
'6A 80' The parameters in the data field are incorrect
'6A 81' Card is blocked or command not supported
'6A 82' File not found
'6A 83' Record not found
'6A 84' There is insufficient memory space in record or file
'6A 85' Lc inconsistent with TLV structure
'6A 86' Incorrect parameters P1-P2
'6A 87' The P3 value is not consistent with the P1 and P2 values.
'6A 88' Referenced data not found.

Liste de Status Word connus

SW1 SW2 Message
'6B 00' Incorrect reference; illegal address; Invalid P1 or P2 parameter
'6C XX' Incorrect P3 length.
'6D 00' Command not allowed. Invalid instruction byte (INS)
'6E 00' Incorrect application (CLA parameter of a command)
'6F 00' Checking error
'90 00' Command executed without error
'91 00' Purse Balance error cannot perform transaction
'91 02' Purse Balance error

Liste de Status Word connus

SW1 SW2 Message
'92 XX' Memory error
'92 02' Write problem / Memory failure
'92 40' Error, memory problem
'94 XX' File error
'94 04' Purse selection error or invalid purse
'94 06' Invalid purse detected during the replacement debit step
'94 08' Key file selection error

Liste de Status Word connus

SW1 SW2 Message
'98 XX' Security error
'98 00' Warning
'98 04' Access authorization not fulfilled
'98 06' Access authorization in Debit not fulfilled for the replacement debit step
'98 20' No temporary transaction key established
'98 34' Error, Update SSD order sequence not respected
(should be used if SSD Update commands are received out of sequence).
'9F XX' Success, XX bytes of data available to be read via "Get_Response" task.