Une carte à puce (smart card, secure element) est un ordinateur miniaturisé sur circuit intégré d'environ 5×5 mm — CPU 16 ou 32 bits, ROM système, EEPROM/Flash données, RAM, crypto co-processeur hardware, interface contact ou sans-contact — conçu pour stocker et exécuter du code et des secrets cryptographiques dans un environnement résistant aux attaques physiques et logiques. C'est le socle hardware de ~6 milliards de SIM et eSIM fabriquées par an, ~14 milliards de cartes bancaires EMV en circulation fin 2024, des passeports biométriques (ICAO 9303), des cartes d'identité électroniques (eID, Carte Vitale France, eIDAS UE), des tokens PKI (YubiKey 5, OpenPGP card, Feitian), et des modules HSM (TPM 2.0, Apple Secure Enclave, Android Strongbox). La communication avec le terminal (lecteur, téléphone, PoS) se fait via des APDU (Application Protocol Data Unit) standardisées par ISO/IEC 7816-4 : le terminal envoie une C-APDU de structure [CLA | INS | P1 | P2 | Lc | data | Le], la carte répond par une R-APDU de structure [data | SW1 SW2] où SW1/SW2 est le Status Word (9000 = succès, 6A82 = fichier non trouvé, 6D00 = instruction non supportée). La plateforme logicielle dominante est JavaCard (Oracle depuis 2010, version 3.1 publiée 2019), qui permet d'écrire des applets en Java portable entre fabricants, bénéficiant de la sécurité mémoire de la VM Java et de l'écosystème GlobalPlatform 2.3.1 pour le cycle de vie (install, personalize, lock, delete). Cet article détaille l'architecture matérielle des cartes à puce, la norme ISO 7816 et ses parties, la structure complète d'un APDU (commande et réponse) avec exemples byte-par-byte, les commandes standard ISO 7816-4 (SELECT, READ BINARY, GET CHALLENGE, INTERNAL AUTHENTICATE, etc.), les Status Words à connaître, la plateforme JavaCard 3.1 avec exemple d'applet, les cas d'usage dominants 2025 (SIM/eSIM, EMV, PKI, eID), l'outillage développement (pyscard, GlobalPlatformPro, JCIDE, ant-javacard), les attaques connues et les certifications Common Criteria qui encadrent la confiance (EAL 4+ à EAL 7). Pour le contexte cryptographique (RSA, ECC, AES embarqués), voir RSA expliqué, Chiffrement asymétrique et PKI expliquée.
1. Architecture matérielle d'une carte à puce
1.1 Composants du circuit intégré
Architecture typique IC carte à puce (~5×5 mm)
──────────────────────────────────────────────
┌──────────────────────────────┐
│ CPU 16 ou 32 bits │
│ (SLE66/SLE77 Infineon, │
│ ST31/ST33 STMicro, │
│ S3FS/S3CC Samsung) │
└──────────────────────────────┘
│
┌───────┴───────┐
│ │
┌──────────┐ ┌──────────┐
│ ROM │ │ RAM │
│ 128-512 │ │ 4-16 KB │
│ KB │ │ │
│ (OS) │ └──────────┘
└──────────┘
│ │
┌──────────┐ ┌──────────────────┐
│ EEPROM/ │ │ Crypto │
│ Flash │ │ Co-processor │
│ 32-512 KB│ │ (AES, RSA, ECC, │
│ (apps, │ │ SHA, TRNG) │
│ data) │ └──────────────────┘
└──────────┘
│
┌──────────────────┐
│ Interface │
│ Contact (7816-2) │
│ OR Sans-contact │
│ (ISO 14443 NFC) │
│ OR Dual │
└──────────────────┘1.2 Fabricants dominants
| Fabricant | Marques IC | Part marché 2024 |
|---|---|---|
| Infineon | SLE series, SOLID FLASH | ~25-30 % |
| STMicroelectronics | ST31, ST33 series | ~20-25 % |
| NXP | SmartMX, JCOP platform | ~15-20 % |
| Samsung Semiconductor | S3 series | ~10-15 % |
| Renesas, Microchip (ex Atmel) | divers | ~10-15 % |
Les OEM (Thales, Giesecke+Devrient, IDEMIA, Watchdata) achètent les IC et développent leur OS / applets pour chaque segment marché (banking, SIM, government, identity).
1.3 Interfaces de communication
| Interface | Standard | Débit | Usage |
|---|---|---|---|
| Contact | ISO/IEC 7816-2, -3 | 10 kbps à 1 Mbps (etu T=1, T=0) | Cartes bancaires, SIM 2FF, PKI tokens |
| Sans-contact | ISO/IEC 14443 (Type A, B) | 106 à 848 kbps | NFC paiement, transports, passeports |
| Sans-contact longue portée | ISO/IEC 15693 | 26 kbps | Tags RFID logistique (pas sécurisé) |
| Dual interface | 7816-2 + 14443 | - | Cartes bancaires modernes (contact + NFC) |
| USB CCID | CCID specification | USB 2.0 | YubiKey, tokens PKI |
2. ISO/IEC 7816 : la norme de référence
ISO/IEC 7816 est la famille de normes qui définit les cartes à puce à contact. Publiée à partir de 1987, maintenue par ISO/IEC JTC 1/SC 17. Parties principales :
| Partie | Contenu |
|---|---|
| 7816-1 | Caractéristiques physiques (format ID-1, résistance) |
| 7816-2 | Emplacements et dimensions des contacts |
| 7816-3 | Protocole transmission asynchrone (T=0, T=1), ATR |
| 7816-4 | Organisation fichiers + APDUs + commandes (cœur applicatif) |
| 7816-5 | Numérotation applications (AID) |
| 7816-6 | Éléments de données inter-sectoriels |
| 7816-7 | SQL for smart cards (peu utilisé) |
| 7816-8 | Commandes sécurité (INTERNAL/EXTERNAL AUTHENTICATE, VERIFY) |
| 7816-9 | Commandes gestion fichiers et applets |
| 7816-11 | Identification biométrique |
| 7816-13 | Gestion applications sur multi-app cards |
| 7816-15 | Information format cryptographique (certificat, clés) |
Pour le sans-contact, ISO/IEC 14443 parties 1-4 définit le physique + protocole anti-collision + transmission de blocs.
3. Structure d'un APDU de commande (C-APDU)
3.1 Format général
C-APDU — Command Application Protocol Data Unit
────────────────────────────────────────────────
┌─────┬─────┬─────┬─────┬─────┬─────────┬─────┐
│ CLA │ INS │ P1 │ P2 │ Lc │ data │ Le │
├─────┼─────┼─────┼─────┼─────┼─────────┼─────┤
│ 1 B │ 1 B │ 1 B │ 1 B │0/1/3│ 0-255 │0/1/3│
└─────┴─────┴─────┴─────┴─────┴─────────┴─────┘
CLA — Class byte : classe d'instruction (ex: 00 ISO, 80 propriétaire, CC GlobalPlatform)
INS — Instruction code : quelle commande (ex: A4 SELECT, B0 READ BINARY, 20 VERIFY)
P1 — Parameter 1 : paramètre spécifique à l'instruction
P2 — Parameter 2 : paramètre spécifique
Lc — Length command : nombre d'octets data qui suivent (0 si absent)
data — Données de la commande (longueur Lc)
Le — Length expected : nombre d'octets attendus en réponse (0 = 256)3.2 Cases de commande (4 types)
Selon ISO 7816-4, un APDU suit l'une de 4 structures :
| Case | Structure | Usage |
|---|---|---|
| Case 1 | CLA INS P1 P2 | Aucune data, aucune réponse data |
| Case 2 | CLA INS P1 P2 Le | Aucune data envoyée, data attendue en réponse |
| Case 3 | CLA INS P1 P2 Lc data | Data envoyée, pas de data attendue en réponse |
| Case 4 | CLA INS P1 P2 Lc data Le | Data envoyée + data attendue |
Cas étendu Extended length (ISO 7816-4 2013+) : Lc et Le sur 3 octets chacun (1 octet 00 marker + 2 octets valeur) pour data > 255 octets.
3.3 Exemple concret : SELECT AID (Application Identifier)
Commande SELECT par AID — sélectionner une application EMV
──────────────────────────────────────────────────────────
C-APDU : 00 A4 04 00 07 A0000000041010 00
Décodage :
CLA = 00 (ISO 7816-4, pas secure messaging)
INS = A4 (SELECT)
P1 = 04 (sélection par AID)
P2 = 00 (first occurrence, return FCI)
Lc = 07 (7 octets de data qui suivent)
data = A0000000041010 (AID MasterCard credit)
Le = 00 (256 octets attendus max)
Réponse possible :
R-APDU : 6F 2C 84 07 A0000000041010 A5 21 ... 9000
└─FCI─────────────────────────┘ └SW┘4. Structure d'une R-APDU (Response)
R-APDU — Response Application Protocol Data Unit
─────────────────────────────────────────────────
┌─────────┬─────┬─────┐
│ data │ SW1 │ SW2 │
├─────────┼─────┼─────┤
│ 0-256 │ 1 B │ 1 B │
└─────────┴─────┴─────┘
data — Données de réponse (peut être vide selon commande)
SW1 — Status Word byte 1
SW2 — Status Word byte 24.1 Status Words à connaître
| SW1 SW2 | Signification |
|---|---|
90 00 | Succès normal |
61 xx | Succès, xx octets disponibles via GET RESPONSE (T=0) |
6A 82 | Fichier ou application non trouvé(e) |
6A 86 | P1/P2 incorrect |
6A 87 | Lc inconsistant avec P1/P2 |
6D 00 | Instruction (INS) non supportée |
6E 00 | Classe (CLA) non supportée |
69 82 | Condition de sécurité non satisfaite (PIN requis) |
69 83 | Authentification bloquée (trop d'échecs PIN) |
69 84 | Donnée référencée invalide ou expirée |
63 Cx | PIN incorrect, x tentatives restantes |
67 00 | Lc incorrect |
6F 00 | Erreur inconnue / non-spécifiée |
65 81 | Erreur mémoire (corruption EEPROM) |
9F xx | Plus de data disponible, xx octets à lire |
Une liste exhaustive est documentée dans ISO 7816-4 Annexe A, avec variantes propriétaires par fabricant (Infineon, NXP, ST) qui étendent la plage 9F xx.
5. Commandes ISO 7816-4 standard
Les commandes les plus rencontrées :
Commandes standard ISO 7816-4 (CLA = 00 typique)
──────────────────────────────────────────────────
INS Nom Usage
──────────────────────────────────────────────────
A4 SELECT Sélectionner fichier ou application (AID)
B0 READ BINARY Lire un fichier transparent
D0 WRITE BINARY Écrire dans fichier transparent
D6 UPDATE BINARY Mettre à jour fichier transparent
B2 READ RECORD Lire un enregistrement (fichier linéaire)
DC UPDATE RECORD Mettre à jour un enregistrement
E2 APPEND RECORD Ajouter un enregistrement
20 VERIFY Vérifier PIN ou biométrie
24 CHANGE REFERENCE DATA Changer PIN
2C RESET RETRY COUNTER Déblocage PIN (PUK)
84 GET CHALLENGE Obtenir un défi aléatoire (auth challenge-response)
82 EXTERNAL AUTHENTICATE Authentifier le terminal à la carte
88 INTERNAL AUTHENTICATE Authentifier la carte au terminal
CA GET DATA Obtenir donnée par tag
DA PUT DATA Écrire donnée par tag
C0 GET RESPONSE Récupérer data après SW 61 xx (T=0)5.1 Exemple de séquence VERIFY PIN + READ
Séquence typique : authentification PIN puis lecture donnée
────────────────────────────────────────────────────────────
1. SELECT application
→ 00 A4 04 00 07 A0000000041010 00
← 6F xx ... 9000
2. VERIFY PIN (P2 = 01 pour PIN global, data = PIN 4-8 chiffres)
→ 00 20 00 01 04 31323334
← 9000 (PIN correct)
ou 63 C2 (incorrect, 2 tentatives restantes)
ou 69 83 (carte bloquée)
3. READ RECORD (SFI 01, record 01)
→ 00 B2 01 0C 00
← 70 xx ... 9000 (data + succès)
4. (Optionnel) Seconde opération autorisée tant que la session PIN est ouverte6. Plateforme JavaCard 3.1
6.1 Pourquoi JavaCard
Développé par Sun Microsystems (1996), maintenu par Oracle depuis 2010. Permet d'écrire des applets en Java portable entre cartes de multiples fabricants. Différences avec Java standard :
| Caractéristique | Java SE | JavaCard |
|---|---|---|
| Types de données | Byte, short, int, long, float, double | byte, short uniquement (int optionnel sur certaines cartes) |
| Garbage collector | Automatique | Manuel (Allocate & free), rarement utilisé |
| Threads | Oui | Non (single-threaded) |
| String | Support complet | Pas de support natif (byte[] à la place) |
| Libraries | Vastes (stdlib) | Minimales (javacard.framework, javacard.security, javacardx.crypto) |
| Exceptions | Oui | Oui mais limitées (ISOException, CryptoException) |
| Serialization | Oui | Non |
| Réflexion | Oui | Non |
6.2 API JavaCard 3.1 — principales packages
javacard.framework Applet, APDU, ISO7816, JCSystem, Util, OwnerPIN, PIN
javacard.security KeyBuilder, KeyPair, Signature, MessageDigest, RandomData,
AESKey, RSAPublicKey, ECKey, DESKey
javacardx.crypto Cipher (AES, DES, RSA, ECC, ChaCha20 JC 3.1+)
javacardx.framework.util ArrayLogic, IntX (si int supporté)
javacardx.biometry BioBuilder, BioTemplate
javacard.security.* Extensions post-quantum ML-KEM/ML-DSA (JavaCard 3.1.1 en draft)6.3 Structure d'un applet minimal
import javacard.framework.*;
public class HelloWorldApplet extends Applet {
// Instruction codes propriétaires (CLA = 80)
private static final byte INS_HELLO = (byte) 0x10;
private final byte[] greeting;
protected HelloWorldApplet() {
greeting = new byte[] {
'H', 'e', 'l', 'l', 'o', ' ', 'J', 'a', 'v', 'a', 'C', 'a', 'r', 'd'
};
register();
}
public static void install(byte[] bArray, short bOffset, byte bLength) {
new HelloWorldApplet();
}
public void process(APDU apdu) {
if (selectingApplet()) {
return;
}
byte[] buffer = apdu.getBuffer();
byte cla = buffer[ISO7816.OFFSET_CLA];
byte ins = buffer[ISO7816.OFFSET_INS];
if (cla != (byte) 0x80) {
ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);
}
switch (ins) {
case INS_HELLO:
sendGreeting(apdu);
break;
default:
ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
}
}
private void sendGreeting(APDU apdu) {
byte[] buffer = apdu.getBuffer();
short len = (short) greeting.length;
Util.arrayCopy(greeting, (short) 0, buffer, (short) 0, len);
apdu.setOutgoingAndSend((short) 0, len);
}
}Déploiement typique avec GlobalPlatformPro :
# Compilation CAP file avec ant-javacard ou JDK JavaCard Development Kit
ant -f build.xml
# Install sur carte via GlobalPlatformPro
gp --install HelloWorldApplet.cap --default
# Test avec commande propriétaire 80 10 00 00 0E
echo -n "00a4040007a0000000620101" | python -c "
from smartcard.System import readers
from smartcard.util import toBytes, toHexString
r = readers()[0].createConnection()
r.connect()
apdu = toBytes('80 10 00 00 0E 00')
data, sw1, sw2 = r.transmit(apdu)
print(bytes(data).decode(), hex(sw1), hex(sw2))
"7. Cas d'usage dominants 2025
7.1 SIM / eSIM
Applet SIM sur carte à puce isolée (SIM 2FF/3FF/4FF, physique) ou eSIM (Embedded UICC, GSMA SGP.22). Fonctions : authentification réseau 3G/4G/5G (Ki key + K algorithm), stockage opérateur config, OTA updates via SMS. ~6 milliards d'unités/an, domination NXP + IDEMIA + Thales.
7.2 Cartes bancaires EMV
Standard EMV Co (Europay/MasterCard/Visa) depuis 1999. Applet EMV qui gère : CDOL (Card-Data Object List), Cryptogram generation (ARQC), offline verification PIN, SDA/DDA/CDA. ~14 milliards de cartes en circulation fin 2024, chaque transaction génère 10-40 APDUs. Pour la visualisation d'une transaction EMV, outils comme ReaderAID ou emv-qrcps-tools.
7.3 Tokens PKI (OpenPGP card, YubiKey, Feitian)
OpenPGP card (spec v3.4 2020, Werner Koch) : applet JavaCard open-source compatible GnuPG. Stockage jusqu'à 3 clés (signing, encryption, authentication), RSA jusqu'à 4096 bits ou ECC Ed25519/Curve25519. YubiKey 5 (2018+) : firmware propriétaire Yubico, multi-fonction (FIDO2, PIV, OpenPGP, OATH-TOTP). Cas d'usage : SSH sur serveur prod sans clé privée sur disque, signature commits Git, déchiffrement email.
7.4 eID et passeports biométriques
ICAO 9303 définit les MRTD (Machine Readable Travel Documents). Passeports biométriques avec photo + empreintes stockées sur eMRTD, accessibles via BAC (Basic Access Control) ou PACE (Password Authenticated Connection Establishment). eIDAS UE (regulation 910/2014) encadre les moyens d'identification électronique, chaque pays a son schéma (France Identity, Belgium eID, Estonian ID-card, etc.).
7.5 Carte Vitale 2 (France)
Déploiement progressif depuis 2022, remplacement Carte Vitale 1 (ancienne carte) prévu achèvement 2026-2028. Applet JavaCard avec authentification mutuelle forte, signature des actes, stockage Assurance Maladie. Certification ANSSI EAL 4+ et CC EAL 5+ en Common Criteria.
8. Outillage de développement et debug
8.1 Matériel
| Outil | Usage | Prix indicatif |
|---|---|---|
| Lecteur PC/SC USB (Identiv, Gemalto, HID) | Communication cartes contact | 15-50 € |
| Lecteur sans-contact ACR122U | NFC ISO 14443 | 30-50 € |
| Proxmark3 | Analyse RFID/NFC, clonage | 200-400 € |
| ChipWhisperer | Side-channel analysis SPA/DPA | 250 € (Lite) à 2000 € (Pro) |
| PicoEMP | Electromagnetic Fault Injection DIY | ~100 € |
| Carte dev JavaCard (NXP JCOP 4, Feitian) | Dev applets | 30-80 € |
8.2 Logiciel
| Outil | Licence | Usage |
|---|---|---|
| pyscard (Python) | LGPL | Communication PC/SC |
| javax.smartcardio | Java SE | Communication PC/SC Java |
| GlobalPlatformPro | Apache 2.0 | Install/delete/personalize applets |
| gpshell | LGPL | CLI GlobalPlatform |
| opensc-tool | LGPL | Outil multi-fonction (PKI, read cards) |
| ant-javacard | Apache 2.0 | Build CAP files depuis Gradle/Ant |
| jcardsim | BSD | Simulateur JavaCard pour tests unitaires |
| JCIDE | Commercial | IDE JavaCard complet (Windows) |
| Oracle JavaCard Development Kit | Free download | SDK officiel + simulator cref |
8.3 Exemple pyscard — envoyer un SELECT
from smartcard.System import readers
from smartcard.util import toHexString, toBytes
# Lister les lecteurs connectés
reader_list = readers()
print(f"Lecteurs disponibles : {len(reader_list)}")
for r in reader_list:
print(f" {r}")
# Connexion au premier lecteur
reader = reader_list[0]
connection = reader.createConnection()
connection.connect()
# ATR (Answer To Reset) — identifiant carte
atr = connection.getATR()
print(f"ATR: {toHexString(atr)}")
# SELECT AID Mastercard
select_emv_mc = toBytes("00 A4 04 00 07 A0000000041010 00")
data, sw1, sw2 = connection.transmit(select_emv_mc)
print(f"Response: {toHexString(data)}")
print(f"SW: {sw1:02X} {sw2:02X}")
# Si SW = 9000, la carte supporte Mastercard
if sw1 == 0x90 and sw2 == 0x00:
print("Application EMV Mastercard sélectionnée avec succès")
elif sw1 == 0x6A and sw2 == 0x82:
print("Pas d'application Mastercard sur cette carte")
connection.disconnect()9. Sécurité et certifications
9.1 Classes d'attaques
| Classe | Description | Contre-mesures |
|---|---|---|
| APDU fuzzing | Envoyer APDUs malformés, hors-spec | Validation stricte INS/P1/P2/Lc |
| Side-channel SPA/DPA | Analyse consommation électrique pendant opération crypto | Randomisation masking, constant-time |
| EM emanation | Écoute émissions électromagnétiques | Shielding, randomisation |
| Timing attack | Mesure délai réponse pour deviner secrets | Constant-time comparisons |
| Fault injection | Glitch tension, horloge, laser pour induire bug | Détection glitch hardware, redondance |
| Semi-invasive | Microsondes sur decap, laser ciblé | Shielding active, capteurs |
| Invasive | Chemical decapsulation + FIB + probing | Mesh actif, autodestruction données sensibles |
9.2 Common Criteria — cadre d'évaluation
Common Criteria (ISO/IEC 15408) définit des niveaux EAL (Evaluation Assurance Level) de 1 à 7 :
| EAL | Niveau | Cartes typiques |
|---|---|---|
| EAL 1-3 | Faible (cartes fidélité, certains tags) | Cartes transport low-end |
| EAL 4+ | Moyen, standard industrie | Cartes bancaires, SIM |
| EAL 5+ | Élevé | Cartes EMV haute gamme, cartes santé Vitale 2 |
| EAL 6+ | Très élevé | Passeports, eID gouvernementaux |
| EAL 7 | Maximum (très rare) | Modules HSM critiques, aerospace |
Durée évaluation : 12-36 mois, coût 500 k€ à 2 M€ par produit. Laboratoires agréés en France : CEA-Leti, Serma Safety & Security, Thales ITSEF.
9.3 Évolutions 2024-2025
- Post-quantum crypto : standards NIST FIPS 203 ML-KEM (Kyber), FIPS 204 ML-DSA (Dilithium), FIPS 205 SLH-DSA (SPHINCS+) publiés août 2024. Migration cartes à puce prévue sur 10-15 ans, prototypes JavaCard 3.1.1 en 2024-2025.
- Attaques récentes publiées : recherches BlackHat 2023-2024 sur eSIM downgrade attacks, papers DEFCON sur cartes Visa EMV variants, fault injection sur puces NXP SE050.
- Regulations eIDAS 2.0 (UE, 2024) : wallet numérique obligatoire dans chaque État membre UE d'ici 2026, embarqué sur smartphone avec Secure Element ou eSIM.
Points clés à retenir
- Carte à puce = ordinateur miniaturisé (~5×5 mm) avec CPU, ROM, EEPROM/Flash, RAM, crypto co-processeur, interface contact ou sans-contact. Socle de 6 milliards de SIM/an, 14 milliards de cartes EMV, passeports, eID, tokens PKI.
- ISO/IEC 7816 standardise cartes contact : 7816-4 couvre APDUs et commandes applicatives (cœur développeur).
- C-APDU :
CLA INS P1 P2 [Lc data] [Le](4 cases structurels selon présence Lc/Le). - R-APDU :
[data] SW1 SW2— SW = Status Word (9000 succès, 6A82 not found, 69 82 PIN requis, 6D00 INS non supporté). - Commandes ISO 7816-4 courantes : SELECT (A4), READ BINARY (B0), VERIFY (20), GET CHALLENGE (84), EXTERNAL AUTHENTICATE (82).
- JavaCard 3.1 (Oracle 2019) : plateforme dominante, portabilité multi-fabricants, sécurité mémoire VM Java. Langage réduit (byte/short seulement), packages spécifiques.
- Cas d'usage 2025 : SIM/eSIM, EMV bancaire, PKI (YubiKey/OpenPGP), eID (passeport, Carte Vitale 2), eIDAS 2.0 wallet UE.
- Outillage dev : pyscard/javax.smartcardio (PC/SC), GlobalPlatformPro (install), ant-javacard (build CAP), jcardsim (tests), JCIDE (IDE).
- Sécurité : attaques APDU fuzzing, side-channel SPA/DPA, fault injection, invasive. Contre-mesures hardware randomisation + Common Criteria EAL 4+ à 7.
- Post-quantum : FIPS 203-204-205 (août 2024), migration cartes débutée 2024-2025, transition 10-15 ans.
Pour le contexte crypto sous-jacent, voir RSA expliqué, Chiffrement asymétrique, PKI expliquée. Pour la rotation des clés hardware, Rotation de clés. Pour la confiance via certificats, Qu'est-ce qu'un certificat TLS.







