Cryptographie appliquée

Carte à puce, JavaCard, APDU de commande : guide technique

Carte à puce et JavaCard expliqués : architecture IC, ISO 7816, APDU commande/réponse, status words, applets JavaCard 3.1, cas EMV/SIM/PKI, outillage dev.

Naim Aouaichia
17 min de lecture
  • Carte à puce
  • JavaCard
  • APDU
  • ISO 7816
  • EMV
  • Secure Element
  • PKI

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

FabricantMarques ICPart marché 2024
InfineonSLE series, SOLID FLASH~25-30 %
STMicroelectronicsST31, ST33 series~20-25 %
NXPSmartMX, JCOP platform~15-20 %
Samsung SemiconductorS3 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

InterfaceStandardDébitUsage
ContactISO/IEC 7816-2, -310 kbps à 1 Mbps (etu T=1, T=0)Cartes bancaires, SIM 2FF, PKI tokens
Sans-contactISO/IEC 14443 (Type A, B)106 à 848 kbpsNFC paiement, transports, passeports
Sans-contact longue portéeISO/IEC 1569326 kbpsTags RFID logistique (pas sécurisé)
Dual interface7816-2 + 14443-Cartes bancaires modernes (contact + NFC)
USB CCIDCCID specificationUSB 2.0YubiKey, 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 :

PartieContenu
7816-1Caractéristiques physiques (format ID-1, résistance)
7816-2Emplacements et dimensions des contacts
7816-3Protocole transmission asynchrone (T=0, T=1), ATR
7816-4Organisation fichiers + APDUs + commandes (cœur applicatif)
7816-5Numérotation applications (AID)
7816-6Éléments de données inter-sectoriels
7816-7SQL for smart cards (peu utilisé)
7816-8Commandes sécurité (INTERNAL/EXTERNAL AUTHENTICATE, VERIFY)
7816-9Commandes gestion fichiers et applets
7816-11Identification biométrique
7816-13Gestion applications sur multi-app cards
7816-15Information 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 :

CaseStructureUsage
Case 1CLA INS P1 P2Aucune data, aucune réponse data
Case 2CLA INS P1 P2 LeAucune data envoyée, data attendue en réponse
Case 3CLA INS P1 P2 Lc dataData envoyée, pas de data attendue en réponse
Case 4CLA INS P1 P2 Lc data LeData 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 2

4.1 Status Words à connaître

SW1 SW2Signification
90 00Succès normal
61 xxSuccès, xx octets disponibles via GET RESPONSE (T=0)
6A 82Fichier ou application non trouvé(e)
6A 86P1/P2 incorrect
6A 87Lc inconsistant avec P1/P2
6D 00Instruction (INS) non supportée
6E 00Classe (CLA) non supportée
69 82Condition de sécurité non satisfaite (PIN requis)
69 83Authentification bloquée (trop d'échecs PIN)
69 84Donnée référencée invalide ou expirée
63 CxPIN incorrect, x tentatives restantes
67 00Lc incorrect
6F 00Erreur inconnue / non-spécifiée
65 81Erreur mémoire (corruption EEPROM)
9F xxPlus 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 ouverte

6. 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éristiqueJava SEJavaCard
Types de donnéesByte, short, int, long, float, doublebyte, short uniquement (int optionnel sur certaines cartes)
Garbage collectorAutomatiqueManuel (Allocate & free), rarement utilisé
ThreadsOuiNon (single-threaded)
StringSupport completPas de support natif (byte[] à la place)
LibrariesVastes (stdlib)Minimales (javacard.framework, javacard.security, javacardx.crypto)
ExceptionsOuiOui mais limitées (ISOException, CryptoException)
SerializationOuiNon
RéflexionOuiNon

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

OutilUsagePrix indicatif
Lecteur PC/SC USB (Identiv, Gemalto, HID)Communication cartes contact15-50 €
Lecteur sans-contact ACR122UNFC ISO 1444330-50 €
Proxmark3Analyse RFID/NFC, clonage200-400 €
ChipWhispererSide-channel analysis SPA/DPA250 € (Lite) à 2000 € (Pro)
PicoEMPElectromagnetic Fault Injection DIY~100 €
Carte dev JavaCard (NXP JCOP 4, Feitian)Dev applets30-80 €

8.2 Logiciel

OutilLicenceUsage
pyscard (Python)LGPLCommunication PC/SC
javax.smartcardioJava SECommunication PC/SC Java
GlobalPlatformProApache 2.0Install/delete/personalize applets
gpshellLGPLCLI GlobalPlatform
opensc-toolLGPLOutil multi-fonction (PKI, read cards)
ant-javacardApache 2.0Build CAP files depuis Gradle/Ant
jcardsimBSDSimulateur JavaCard pour tests unitaires
JCIDECommercialIDE JavaCard complet (Windows)
Oracle JavaCard Development KitFree downloadSDK 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

ClasseDescriptionContre-mesures
APDU fuzzingEnvoyer APDUs malformés, hors-specValidation stricte INS/P1/P2/Lc
Side-channel SPA/DPAAnalyse consommation électrique pendant opération cryptoRandomisation masking, constant-time
EM emanationÉcoute émissions électromagnétiquesShielding, randomisation
Timing attackMesure délai réponse pour deviner secretsConstant-time comparisons
Fault injectionGlitch tension, horloge, laser pour induire bugDétection glitch hardware, redondance
Semi-invasiveMicrosondes sur decap, laser cibléShielding active, capteurs
InvasiveChemical decapsulation + FIB + probingMesh 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 :

EALNiveauCartes typiques
EAL 1-3Faible (cartes fidélité, certains tags)Cartes transport low-end
EAL 4+Moyen, standard industrieCartes bancaires, SIM
EAL 5+ÉlevéCartes EMV haute gamme, cartes santé Vitale 2
EAL 6+Très élevéPasseports, eID gouvernementaux
EAL 7Maximum (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.

Questions fréquentes

  • Qu'est-ce qu'une carte à puce exactement ?
    Une carte à puce est un ordinateur miniaturisé complet sur un circuit intégré (IC) d'environ 5×5 mm, embarqué dans un support physique (carte plastique ISO/IEC 7810 ID-1, SIM 2FF/3FF/4FF, eSIM embedded, module HSM). Elle contient CPU 16-32 bits (historiquement SLE66/SLE77 Infineon, ST31/ST33 STMicroelectronics), ROM (code système), EEPROM ou Flash (données persistantes), RAM (exécution volatile), crypto co-processor hardware (AES, RSA, ECC, RNG vrai aléatoire), interface de communication (contact ISO 7816-2, sans-contact ISO 14443 NFC, ou hybride dual-interface). Elle exécute son propre OS sécurisé (JCOP chez NXP, Kinibi chez Trustonic, Multos, Basic Card, ou OS custom), expose une interface applicative via APDUs. Les usages 2025 : SIM/eSIM (6+ milliards d'unités par an), cartes bancaires EMV (~14 milliards en circulation), cartes d'identité électronique (eID, passeports biométriques), PKI tokens (YubiKey 5, Feitian, OpenPGP card), cartes de santé (Carte Vitale en France 2026).
  • C'est quoi un APDU ?
    APDU signifie Application Protocol Data Unit — unité de communication entre le terminal (lecteur de carte, téléphone, PoS) et la carte à puce, standardisée par ISO/IEC 7816-4. Il existe deux types : C-APDU (Command APDU, envoyée au terminal vers la carte) avec structure [CLA | INS | P1 | P2 | Lc | data | Le] où CLA = classe d'instruction, INS = code instruction (ex: A4 = SELECT, B0 = READ BINARY), P1 et P2 = paramètres, Lc = longueur data envoyée, Le = longueur attendue en retour. R-APDU (Response APDU, renvoyée par la carte au terminal) avec structure [data | SW1 | SW2] où SW1/SW2 = Status Word de 2 octets indiquant le résultat (9000 = succès, 6A82 = fichier non trouvé, 6D00 = INS non supporté, 6982 = condition de sécurité non satisfaite). Toute interaction avec une carte à puce est une séquence d'APDU, c'est le fondement du dialogue hardware-sécurisé.
  • Pourquoi JavaCard et pas C natif ?
    Trois raisons historiques et persistantes. 1) Portabilité : JavaCard (1996, Sun puis Oracle) permet d'écrire un applet une fois et de le déployer sur des cartes de multiples fabricants (NXP, STMicroelectronics, Infineon, Samsung) — un C natif lie au silicium spécifique. 2) Sécurité mémoire : la VM JavaCard exclut par conception les classes de vulnérabilités C (buffer overflow, use-after-free, dangling pointers) — critique sur un secure element où l'exploit ne peut pas être corrigé facilement en production. 3) Écosystème développement : JavaCard 3.1 (2019) a standardisé l'API, GlobalPlatform 2.3.1 standardise le cycle de vie des applets (install/load/personalize/lock), IDE dédiés (JCIDE, Oracle JavaCard Development Kit). Le C natif reste sur certains OS custom (Basic Card Micro, cartes Multos) ou sur du matériel high-end avec CC EAL 6+ où le surcoût Java est problématique.
  • Comment communiquer avec une carte à puce depuis un PC ?
    Stack 2025 : PC/SC (Personal Computer/Smart Card) est la norme cross-platform (Linux via pcsc-lite, macOS natif, Windows WinSCard). On connecte un lecteur (Gemalto IDBridge, Identiv, HID OMNIKEY, YubiKey en mode CCID) en USB, puis on utilise une librairie pour envoyer des APDUs. Python : pyscard est la référence (from smartcard.System import readers; reader = readers()[0]; connection = reader.createConnection(); connection.connect()). Java : javax.smartcardio (inclus Java Standard Edition). Outils CLI pour interagir manuellement : opensc-tool, gpshell, GlobalPlatformPro (jar Java), JCOP Tools Eclipse Plugin. Outils de debug et pentest : Proxmark3 pour RFID/NFC, ChipWhisperer pour attaques side-channel, logiciels commerciaux type Riscure Inspector ou Keysight pour analyse hardware approfondie.
  • Les cartes à puce sont-elles réellement sûres en 2025 ?
    Oui, mais avec nuances selon classe. Les cartes certifiées Common Criteria EAL 5+ ou EAL 6+ (passeports, cartes bancaires haute gamme, cartes d'identité) offrent protection contre : attaques logiques (APDU fuzzing, timing), side-channel (SPA/DPA power analysis), invasive (microsonde, déencapsulation), semi-invasive (laser fault injection, glitching tension/horloge). Les durées de certification longues (12-36 mois) et les coûts élevés (500k-2M€ par produit) garantissent une revue approfondie. Les cartes non-certifiées (cartes de fidélité, transport public non-régulé) peuvent être vulnérables — cf attaques MIFARE Classic 2008, cartes transport compromises régulièrement. En 2025, l'écosystème fait face au post-quantum : passeports / eID en cours de migration vers ML-DSA / ML-KEM (standards NIST FIPS 203-204-205 publiés août 2024), transition prévue sur 10-15 ans. Les attaques émergentes 2023-2024 : Chicken Soup (side-channel sur ECC), DEFCON papers sur eSIM security.
  • Peut-on développer un applet JavaCard personnel en 2025 ?
    Oui, l'écosystème est plus accessible qu'il y a 10 ans. Approche pratique : 1) Acheter une carte JavaCard développeur (NXP JCOP 4 Classic ou similaire ~30-80€ chez Smartcard Focus, Feitian, Identiv) + lecteur PC/SC USB ~15-50€. 2) Installer JavaCard Development Kit (Oracle, gratuit) ou alternatives (ant-javacard, jcardsim pour simulation). 3) Écrire l'applet Java selon API JavaCard 3.1 (classes javacard.framework.Applet, APDU, etc). 4) Compiler en CAP file via ant-javacard ou JDK. 5) Déployer via GlobalPlatformPro : gp --install applet.cap --default. 6) Tester via pyscard ou gpshell. Communautés actives : smartcard sur Stack Overflow, FOSDEM dev room smart card, Github repositories martinpaljak/GlobalPlatformPro (~4 000 stars), martinpaljak/ant-javacard. Premiers applets didactiques typiques : HelloWorld (retourne un greeting), calculator, générateur de TOTP, gestionnaire de clés RSA/ECDSA basique.

Écrit par

Naim Aouaichia

Expert cybersécurité et fondateur de Zeroday Cyber Academy

Expert cybersécurité avec un master spécialisé et un parcours hybride : développement, DevOps, DevSecOps, SOC, GRC. Fondateur de Hash24Security et Zeroday Cyber Academy. Formateur et créateur de contenu technique sur la cybersécurité appliquée, la sécurité des LLM et le DevSecOps.