Algerian ID Chip Security for Businesses

La CNIBE algérienne (Carte Nationale d'Identité Biométrique Électronique) est l'un des documents d'identité nationaux les plus cryptographiquement sécurisés de la région. Émise par le CNIFS (Centre National de l'Informatique et des Fichiers de Sécurité), la carte intègre une puce NFC qui ne fonctionne pas seulement comme un stockage de données, mais comme un participant cryptographique actif à la vérification d'identité. Pour les entreprises qui déploient l'eKYC en Algérie — banques sous règlement 24-64, PSP sous instruction 06-2025, assureurs ou toute entité soumise aux obligations LBC de la loi 05-01 — comprendre l'architecture de sécurité de la puce CNIBE est la clé pour déployer le flux de vérification offrant la plus haute assurance disponible.

Cet article explique les couches cryptographiques à l'intérieur de la puce CNIBE, comment chaque couche est vérifiée pendant la vérification NFC d'identité, et ce que cela signifie pour les entreprises qui prennent des décisions technologiques.

Inside the CNIBE NFC Chip: Architecture and Data Groups

La puce CNIBE suit la norme OACI 9303 pour les documents de voyage à lecture automatique électroniques (eMRTD), la même norme utilisée dans les passeports biométriques du monde entier. La puce stocke les données dans des Data Groups (DG) structurés, chacun contenant des informations spécifiques :

• DG1 — Zone de lecture automatique (MRZ) : Les données d'identité textuelles (nom, prénoms, date de naissance, numéro de document, expiration, nationalité)
• DG2 — Image faciale codée : Une photographie faciale compressée en JPEG2000, stockée dans la puce par l'autorité émettrice au moment de la production du document
• DG14 — Informations de sécurité : Clé publique d'authentification active et algorithmes cryptographiques pris en charge
• EF.SOD — Security Object Document : Empreintes cryptographiques de tous les groupes de données, signées numériquement par le Document Signer Certificate (DSC) émis par la CSCA algérienne (Country Signing Certification Authority)

Cette architecture signifie que la puce contient non seulement des données d'identité, mais aussi une preuve cryptographique vérifiable que les données sont authentiques et n'ont pas été altérées depuis l'émission du document.

Three Cryptographic Security Layers

Couche 1 : Contrôle d'accès — BAC et PACE

Avant qu'aucune donnée de la puce ne puisse être lue, le lecteur doit prouver qu'il dispose d'un accès légitime — empêchant tout skimming non autorisé. La CNIBE utilise deux mécanismes de contrôle d'accès :

• Basic Access Control (BAC) : Le lecteur dérive une clé d'accès à partir des données MRZ (numéro de document + date de naissance + expiration), qui doivent être scannées optiquement avant la lecture NFC. Cela signifie qu'une puce ne peut être lue sans la possession physique du document.
• Password Authenticated Connection Establishment (PACE) : Un protocole cryptographique plus moderne offrant un contrôle d'accès plus robuste. La pile NFC d'Assurique prend en charge à la fois BAC et PACE, sélectionnant automatiquement le protocole le plus robuste supporté par la puce.

Couche 2 : Authentification passive — Vérification de l'intégrité des données

L'authentification passive vérifie que les données de la puce n'ont pas été modifiées depuis leur émission. Le processus :

• Le lecteur lit le fichier EF.SOD, qui contient les empreintes SHA-256 de chaque Data Group
• Le lecteur hache les fichiers DG réels de la puce et les compare aux empreintes du SOD — si un DG a été modifié, les empreintes ne correspondront pas (DG_INTEGRITY_FAILED)
• Le SOD est signé numériquement par le Document Signer Certificate, qui se rattache à la racine CSCA algérienne — le lecteur vérifie cette chaîne de signature (SOD_SIGNATURE_FAILED si invalide)
• Cela prouve que toutes les données de la puce sont exactement telles que l'autorité émettrice algérienne les a écrites au moment de la production

Couche 3 : Authentification active — Prouver l'authenticité de la puce

L'authentification passive prouve que les données ne sont pas modifiées, mais ne prouve pas que la puce elle-même est l'originale. L'authentification active traite le clonage de puce :

• Le lecteur envoie un défi aléatoire (un nonce cryptographique) à la puce
• La puce signe le défi avec sa clé privée — une clé générée à la production de la puce et qui ne quitte jamais l'élément sécurisé
• Le lecteur vérifie la signature avec la clé publique d'authentification active stockée dans DG14
• Une puce clonée ne peut reproduire cela : il faudrait la clé privée de la puce originale, qui ne peut être extraite de l'élément sécurisé. Un résultat CHIP_CLONE_SUSPECTED apparaît si le défi-réponse échoue.

NFC vs OCR: The Assurance Gap

La vérification d'identité basée sur l'OCR lit des informations visuelles à partir de photos de documents. Même avec des contrôles d'authenticité pilotés par IA — détectant les anomalies d'impression, les hologrammes et les éléments réactifs aux UV — l'OCR ne peut fournir de preuve cryptographique de l'authenticité du document. Une contrefaçon suffisamment sophistiquée peut passer l'inspection visuelle. La vérification de puce NFC est catégoriquement différente : les clés cryptographiques de la CSCA algérienne sont physiquement protégées par des modules de sécurité matérielle souverains. Falsifier une signature de puce valide est calculatoirement infaisable. C'est pourquoi le règlement 24-64 (banque digitale) et l'instruction 06-2025 (PSP) imposent de fait la vérification NFC pour les cas d'usage à plus haut risque : banques et PSP sont tenues d'utiliser le mécanisme d'assurance d'identité le plus robuste disponible pour les onboardings réglementés.

Hard Gates: When NFC Verification Fails Instantly

Dans le moteur de vérification d'Assurique, certains résultats NFC déclenchent un REFUS immédiat quel que soit le score des autres vérifications. Ces portes strictes ne peuvent être contournées par l'opérateur :

• DG_INTEGRITY_FAILED : Un ou plusieurs groupes de données ne correspondent pas à leurs empreintes dans le SOD — les données de la puce ont été modifiées
• SOD_SIGNATURE_FAILED : La signature du Security Object Document ne se vérifie pas dans la chaîne de certificats CSCA — le document n'est pas une CNIBE authentique
• CHIP_CLONE_SUSPECTED : L'échange défi-réponse de l'authentification active a échoué — la puce ne peut prouver qu'elle détient la clé privée originale

Dans tous les autres parcours de vérification, le moteur de risque applique un scoring pondéré (authenticité document/puce 30 % + correspondance faciale 60 % + signaux comportementaux 10 %) avec APPROUVÉ à ≥ 75, REVUE_MANUELLE à 50–74, et REJETÉ en dessous de 50. Mais les échecs de portes strictes contournent entièrement le scoring — la vérification est refusée immédiatement.

Integration: How Assurique Implements CNIBE NFC Verification

Le SDK Android et l'API côté serveur d'Assurique implémentent la pile complète de vérification NFC. Le SDK gère le contrôle d'accès BAC/PACE, lit et analyse tous les groupes de données pertinents, transmet les données de la puce au serveur sur site via un canal chiffré, et le serveur effectue l'authentification passive et active contre la chaîne de certificats algérienne. Le pipeline complet — du premier tap NFC à la décision finale — s'achève en moins de 5 secondes. L'image faciale stockée dans la puce (DG2) est utilisée pour la correspondance biométrique avec le selfie en direct de l'utilisateur, fournissant une correspondance avec l'enregistrement biométrique original de l'autorité émettrice plutôt qu'avec une photo scannée.