<!-- Generated from prerendered index.html. HTML SHA-256: 05f90a8345dcd71aeb6525c36f71f515de66e6ba7a6bfbd6ffe3fdb07a1509be -->

# 01 · Enrôlement : lire la CNIe et créer l'identité numérique

> Section autonome du guide [eIDAS 2, échange par échange](https://signature.codethelaw.eu/).

Production et spécifié

Les échanges avec la puce suivent des normes publiques (ICAO 9303, BSI TR-03110). Le protocole entre l'application France Identité et ses serveurs n'est pas publié : ces étapes sont signalées.

C'est l'étape qui lie une personne physique à des données. L'application lit la puce de la carte d'identité par NFC, vérifie que les données ont été signées par l'État et que la puce n'est pas un clone, puis crée une identité numérique que l'usager peut faire certifier en mairie.

## 1.1 Saisir le numéro d'accès à la carte

Personne → France Identité · Saisie du CAN

### Entrée

Numéro imprimé sur la carte, utilisé comme mot de passe PACE.

**TEXTE**

```text
CNIe (format ID-1, émise depuis août 2021)
CAN (Card Access Number) : 6 chiffres imprimés au recto
Exemple : 123456
```

### Traitement

1.  L'application demande le CAN : sans lui, la puce refuse tout accès sans contact.
2.  Le CAN devient le mot de passe π du protocole PACE ; il n'est jamais transmis tel quel à la puce.
3.  Une clé Kπ est dérivée de π par la fonction de dérivation de BSI TR-03110 (compteur 3).

### Sortie

Matériel local prêt pour PACE.

**TEXTE**

```text
π  = "123456"
Kπ = KDF(π, 3)    -- clé de 128 bits pour une suite AES-128 (selon la suite annoncée par la puce)
```

**Suite :** Kπ sert à déchiffrer le nonce envoyé par la puce à l'étape suivante. Empêcher la lecture à distance à l'insu du titulaire est le but : il faut voir la carte pour connaître le CAN.

## 1.2 Établir un canal sécurisé avec la puce (PACE)

France Identité → Puce CNIe · PACE (APDU)

### Entrée

Commandes ISO 7816-4 envoyées par NFC. Suite cryptographique donnée à titre d'exemple : la CNIe l'annonce dans EF.CardAccess.

**APDU · ISO/IEC 7816-4**

```text
→ MSE:Set AT  (choix du protocole et du mot de passe)
00 22 C1 A4 0F
   80 0A 04 00 7F 00 07 02 02 04 02 02   -- OID id-PACE-ECDH-GM-AES-CBC-CMAC-128 (exemple)
   83 01 02                               -- référence du mot de passe : 02 = CAN
← 90 00

→ General Authenticate, étape 1 : demande du nonce chiffré
10 86 00 00 02 7C 00 00
← 7C 12 80 10 <z = E(Kπ, s), 16 octets> 90 00

→ étape 2 : mapping générique (clés éphémères de mapping)
10 86 00 00 45 7C 43 81 41 <PK_map,PCD : point P-256 non compressé> 00
← 7C 43 82 41 <PK_map,PICC> 90 00

→ étape 3 : accord de clés éphémères sur le générateur G' = s·G + H
10 86 00 00 45 7C 43 83 41 <PK_PCD> 00
← 7C 43 84 41 <PK_PICC> 90 00

→ étape 4 : jetons d'authentification mutuelle
00 86 00 00 0C 7C 0A 85 08 <T_PCD = MAC(KS_MAC, PK_PICC)> 00
← 7C 0A 86 08 <T_PICC = MAC(KS_MAC, PK_PCD)> 90 00
```

### Traitement

1.  La puce tire un nonce s et l'envoie chiffré sous Kπ ; seule une partie connaissant le CAN peut le déchiffrer.
2.  Le mapping générique dérive un nouveau générateur G' à partir de s et d'un secret Diffie-Hellman éphémère.
3.  Un second échange Diffie-Hellman sur G' donne le secret K, dont on dérive KS\_Enc et KS\_MAC.
4.  Chaque côté prouve qu'il a obtenu le même K en renvoyant un MAC de la clé publique éphémère de l'autre.

### Sortie

Canal de messagerie sécurisée (ISO 7816-4 secure messaging).

**TEXTE**

```text
KS_Enc, KS_MAC  -- clés de session
SSC             -- compteur de séquence
Toutes les commandes suivantes sont chiffrées (DO'87') et authentifiées (DO'8E').
```

**Suite :** Toutes les lectures de données de l'étape suivante passent par ce canal : un observateur radio ne voit que du chiffré.

## 1.3 Lire les données d'identité et l'objet de sécurité

France Identité → Puce CNIe · Lecture EF.SOD, DG

### Entrée

Commandes sous messagerie sécurisée (représentées ici en clair).

**APDU · ISO/IEC 7816-4**

```text
→ SELECT application eMRTD
00 A4 04 0C 07 A0 00 00 02 47 10 01
→ SELECT EF.DG1   00 A4 02 0C 02 01 01   → READ BINARY ...
→ SELECT EF.SOD   00 A4 02 0C 02 01 1D   → READ BINARY ...
(+ les autres groupes de données nécessaires à l'usage)
```

### Traitement

1.  DG1 contient la zone de lecture automatique (MRZ, format TD1 : trois lignes de 30 caractères).
2.  EF.SOD contient l'objet de sécurité du document : la liste des condensats de chaque groupe de données, signée.
3.  La puce ne délivre ces fichiers qu'à travers le canal PACE.

### Sortie

Structures lues (forme abrégée).

**CMS · RFC 5652**

```text
EF.DG1 :
61 5B 5F 1F 58 <MRZ TD1 : 3 lignes de 30 caractères>
   -- type de document, État émetteur FRA, numéro, date de naissance,
   -- sexe, date d'expiration, nationalité, noms et prénoms

EF.SOD : CMS SignedData {
  eContent : LDSSecurityObject {
    version          0,
    hashAlgorithm    id-sha256 (2.16.840.1.101.3.4.2.1),
    dataGroupHashValues {
      { dataGroupNumber 1,  dataGroupHashValue <SHA-256(DG1)> },
      { dataGroupNumber 2,  dataGroupHashValue <SHA-256(DG2)> },
      { dataGroupNumber 14, dataGroupHashValue <SHA-256(DG14)> }, ...
    }
  }
  certificates : { certificat du Document Signer }
  signerInfos  : { signature du Document Signer sur les attributs signés }
}
```

**Suite :** Les condensats de EF.SOD permettent de vérifier chaque groupe de données lu, et la signature de EF.SOD permet de remonter à l'État émetteur.

## 1.4 Vérifier que les données ont été signées par l'État

France Identité → France Identité · Authentification passive

### Entrée

EF.SOD, groupes de données lus, certificat CSCA France connu de l'application.

**CMS · RFC 5652**

```text
DG1, DG14, ...           (octets lus)
EF.SOD                   (CMS SignedData)
CSCA FR                  (ancre de confiance, publiée par l'État et via l'ICAO PKD)
```

### Traitement

1.  Recalculer SHA-256 de chaque groupe de données lu et le comparer à la valeur inscrite dans LDSSecurityObject.
2.  Vérifier la signature CMS de EF.SOD avec la clé publique du certificat Document Signer.
3.  Vérifier que le certificat Document Signer est signé par la CSCA France et qu'il n'est pas révoqué (CRL de la CSCA).

### Sortie

Résultat.

**TEXTE**

```text
Authentification passive : OK
=> les données n'ont pas été modifiées depuis leur personnalisation par l'État.
=> limite : une copie exacte des fichiers sur une autre puce passerait aussi ce contrôle.
```

**NOTE.** L'authentification passive ne fait intervenir aucune clé de la carte : elle vérifie une signature de l'État sur des données. Elle prouve l'intégrité et l'origine, pas la présence d'une puce authentique.

**Suite :** Comme la copie n'est pas détectée, il faut prouver que la puce elle-même est authentique : c'est l'étape suivante.

## 1.5 Prouver que la puce est authentique

France Identité → Puce CNIe · Anti-clonage

### Entrée

Clé publique de la puce, lue dans un groupe de données dont le condensat est déjà vérifié.

**TEXTE**

```text
Chip Authentication : clé publique Diffie-Hellman de la puce dans DG14
Active Authentication : clé publique de signature de la puce dans DG15
```

### Traitement

1.  Chip Authentication : accord Diffie-Hellman entre la clé statique de la puce et une clé éphémère de l'application ; seule la vraie puce peut calculer le secret, et le canal est re-chiffré avec de nouvelles clés. La preuve n'est pas transférable à un tiers.
2.  Active Authentication : l'application envoie un défi aléatoire, la puce le signe avec sa clé privée de DG15.
3.  Dans les deux cas, la clé publique est authentifiée par l'étape précédente, puisque DG14 ou DG15 figure dans EF.SOD.

### Sortie

Résultat.

**TEXTE**

```text
Puce authentique : OK
La clé privée de la puce n'a jamais quitté le composant.
```

**NON PUBLIÉ.** Le profil exact de la CNIe (Chip Authentication, Active Authentication ou les deux) n'est pas détaillé publiquement. Les deux mécanismes sont ceux définis par ICAO 9303 partie 11.

**Suite :** Les données sont authentiques et proviennent d'une vraie puce : l'application peut créer l'identité numérique.

## 1.6 Créer l'identité numérique France Identité

France Identité → Serveurs France Identité · Création de l'identité

### Entrée

Parcours public décrit par France Identité et FranceConnect.

**TEXTE**

```text
1. Saisie du CAN et lecture NFC de la carte
2. Vérification de l'identité via FranceConnect ou par courrier recommandé (au choix)
3. Choix d'un code personnel
```

### Traitement

1.  L'application transmet aux serveurs de l'État les éléments nécessaires à la création de l'identité numérique.
2.  Une vérification complémentaire est faite par FranceConnect ou par courrier recommandé.
3.  Le format des messages et la nature exacte des données envoyées ne sont pas publiés.

### Sortie

État de l'identité.

**TEXTE**

```text
Identité numérique créée (non certifiée)
Utilisable sur FranceConnect, pas sur FranceConnect+
```

**NON PUBLIÉ.** Étape interne non publiée : la page ne montre volontairement aucun format de message inventé.

**Suite :** Pour accéder aux démarches sensibles (FranceConnect+), l'identité doit être certifiée en mairie.

## 1.7 Certifier l'identité en mairie

Personne → Agent en mairie · QR code, face-à-face

### Entrée

Parcours public de certification.

**TEXTE**

```text
Dans l'application : confirmer l'adresse e-mail, saisir le code personnel,
relire la carte en NFC  =>  l'application génère un QR code
En mairie : présentation du QR code et de la carte à un agent
```

### Traitement

1.  L'agent compare la personne présente au titre présenté : c'est le face-à-face, qui n'a pas d'équivalent cryptographique.
2.  Le QR code relie ce contrôle à l'identité numérique créée sur le téléphone.
3.  Depuis avril 2025, l'identité numérique peut aussi être créée à la remise de la carte en mairie ou en consulat.

### Sortie

État de l'identité.

**TEXTE**

```text
Identité numérique certifiée
=> accès à FranceConnect+ (niveaux eidas2 et eidas3 côté fédération)
```

**BASE LÉGALE.** Juridiquement, c'est cette étape d'enrôlement qui fonde le niveau de garantie (règlement d'exécution (UE) 2015/1502 : preuve et vérification d'identité). La cryptographie des étapes suivantes ne fait que rejouer ce lien.

**Suite :** L'identité certifiée sert ensuite d'authentification forte auprès de FranceConnect+ (section 4) et sera la base d'un PID dans le portefeuille européen (section 2).

## Sources

-   [France Identité, identité numérique certifiée](https://france-identite.gouv.fr/identite-numerique-certifiee/)
-   [FranceConnect, compte France Identité (création, certification)](https://www.franceconnect.gouv.fr/comptes-disponibles/france-identite/)
-   [France Identité, authentification sans lecture de carte](https://france-identite.gouv.fr/actualite/utiliser_app_sans_lecture_CNI.html)
-   ICAO Doc 9303 partie 11 (PACE, Chip et Active Authentication) et BSI TR-03110 partie 3, normes de référence