7 DECEMBRE 2006. - Arrêté royal fixant les spécifications et la procédure d'enregistrement des appareils de lecture pour la carte d'identité électronique et modifiant l'arrêté royal du 13 février 1998 relatif aux spécifications des appareils de lecture de la carte d'identité sociale

Rapport au Roi Sire, Le présent projet d'arrêté royal que nous avons l'honneur de présenter à Votre Majesté, vise à exécuter l'article 6quinquies de la loi du 19 juillet 1991 relative aux registres de la population et aux cartes d'identité et modifiant la loi du 8 août 1983 organisant un Registre national des personnes physiques, inséré par la loi du 25 mars 2003.

L'article précité stipule que les normes et les spécifications techniques et fonctionnelles auxquelles doivent satisfaire les appareils (le lecteur de cartes) et les applications qui rendent possible la lecture et la mise à jour des données reprises de manière électronique sur la carte d'identité peuvent être déterminées.

La détermination de normes et d'exigences techniques et fonctionnelles est souhaitable dans l'intérêt des utilisateurs de la carte d'identité électronique et des diverses applications. Si l'on veut encourager l'utilisation de la carte d'identité électronique, il faut veiller à ce qu'il y ait suffisamment de lecteurs de cartes en circulation capables de lire la carte d'identité électronique.

Afin d'éliminer dans le chef de l'utilisateur le doute quant à la compatibilité des lecteurs avec la carte d'identité électronique, une procédure d'enregistrement libre est prévue pour les fournisseurs de lecteurs compatibles. Cette procédure permet de contrôler la conformité des appareils aux normes et spécifications déterminées afin de pouvoir garantir à l'utilisateur et à l'acheteur potentiel que les appareils fonctionnent correctement. La conformité d'un lecteur de cartes aux standards précités est confirmée au moyen d'un label.

Enfin, la procédure d'enregistrement vise à éviter, par le biais de l'attribution d'un label, l'utilisationd'appareils susceptibles d'endommager la carte d'identité électronique.

L'utilisation du label, déposé comme marque, par les fournisseurs d'appareils de lecture est soumise à certaines exigences minimales.

Les spécifications relatives au label ainsi que ses conditions d'utilisation sont reprises en annexe au présent projet d'arrêté.

Il convient de viser une interopérabilité maximale des divers lecteurs de cartes; autrement dit, les autorités doivent faire en sorte que les lecteurs de cartes utilisés pour la carte d'identité électronique soient également compatibles avec d'autres types de cartes utilisés dans la relation avec les autorités, et en particulier avec la carte d'identité sociale. C'est la raison pour laquelle on choisit d'utiliser la même procédure d'enregistrement que celle utilisée actuellement pour les fournisseurs d'appareils de lecture de la carte d'identité sociale. Dans un souci de clarté, on choisit dès lors de régler les deux procédures d'enregistrement par le biais d'un seul et même arrêté. A cette fin, le présent arrêté modifie l'arrêté royal du 13 février 1998 relatif aux spécifications des appareils de lecture de la carte d'identité sociale.

La procédure d'enregistrement peut être résumée comme suit : Le fournisseur d'appareils de lecture doit être en mesure de montrer aux autorités la conformité de l'appareil aux spécifications fonctionnelles et aux normes de standardisation, telles que reprises en annexe au présent arrêté royal.

Si cette conformité est prouvée, le fournisseur est enregistré par les autorités et pourvoit ensuite son appareil de lecture d'un numéro d'enregistrement électronique et appose sur l'appareil le label destiné à cet effet.

La liste des appareils de lecture conformes, ainsi que les spécifications relatives à ces lecteurs, peuvent également être consultées sur le site web de l'autorité compétente.

Nous avons l'honneur d'être, Sire, De Votre Majesté le très respectueux et très fidèle serviteurs, Le Ministre de l'Intérieur, P. DEWAEL Le Ministre de l'Economie, M. VERWILGHEN Le Ministre des Affaires sociales, R. DEMOTTE La Ministre des Classes moyennes et de l'Agriculture, Mme S. LARUELLE Le Ministre de l'Emploi, P. VANVELTHOVEN

7 DECEMBRE 2006. - Arrêté royal fixant les spécifications et la procédure d'enregistrement des appareils de lecture pour la carte d'identité électronique et modifiant l'arrêté royal du 13 février 1998 relatif aux spécifications des appareils de lecture de la carte d'identité sociale ALBERT II, Roi des Belges, A tous, présents et à venir, Salut.

Vu la loi du 19 juillet 1991 relative aux registres de la population et aux cartes d'identité et modifiant la loi du 8 août 1983 organisant un Registre national des personnes physiques, notamment l'article 6quinquies, inséré par la loi du 25 mars 2003;

Vu la loi du 26 juillet 1996Documents pertinents retrouvés type loi prom. 26/07/1996 pub. 05/10/2012 numac 2012205395 source service public federal interieur Loi relative à la promotion de l'emploi et à la sauvegarde préventive de la compétitivité. - Coordination officieuse en langue allemande fermer portant modernisation de la sécurité sociale et assurant la viabilité des régimes légaux des pensions, notamment les articles 41 et 49;

Vu l'arrêté royal du 18 décembre 1996 portant des mesures en vue d'instaurer une carte d'identité sociale à l'usage de tous les assurés sociaux, en application des articles 38, 40, 41 et 49 de la loi du 26 juillet 1996Documents pertinents retrouvés type loi prom. 26/07/1996 pub. 05/10/2012 numac 2012205395 source service public federal interieur Loi relative à la promotion de l'emploi et à la sauvegarde préventive de la compétitivité. - Coordination officieuse en langue allemande fermer portant modernisation de la sécurité sociale et assurant la viabilité des régimes légaux des pensions, sanctionné par la loi du 26 juin 1997, notamment l'article 4, alinéa trois;

Vu l'arrêté royal du 13 février 1998 relatif aux spécifications des appareils de lecture de la carte d'identité sociale;

Vu l 'avis de l'Inspection des Finances, donné le 14 mai 2006;

Vu l'accord de Notre Ministre du Budget, donné le 30 juin 2006;

Vu l'avis de la Banque Carrefour de la Sécurité sociale, donné le 26 septembre 2006;

Vu l'accomplissement des formalités prescrites par la directive du Parlement Européenne et le Conseil 98/34/EG du 22 juin 1998 prévoyant une procédure d'information dans le domaine des normes et réglementations techniques;

Vu avis 40.903/1/V du Conseil d'Etat, donné le 3 août 2006, en application de l'article 84, § 1er, alinéa 1er, 1°, des lois coordonnées sur le Conseil d'Etat;

Sur la proposition de Notre Ministre de l'Intérieur, de Notre Ministre de l'Economie, de Notre Ministre des Affaires sociales et de la Santé publique, de Notre Ministre des Classes moyennes et de l'Agriculture et de Notre Ministre de l'Emploi, et de l'avis de Nos Ministres qui en ont délibéré en Conseil, Nous avons arrêté et arrêtons :

Article 1er.L'intitulé de l'arrêté royal du 13 février 1998 relatif aux spécifications des appareils de lecture de la carte d'identité sociale, est remplacé par l'intitulé suivant : "Arrêté royal fixant les spécifications et la procédure d'enregistrement des appareils de lecture pour la carte d'identité électronique et la carte d'identité sociale".

Art. 2.A l'article 1er du même arrêté sont apportées les modifications suivantes: a) au deuxième tiret, les mots "-"fournisseur": toute personne qui fabrique, distribue directement ou indirectement, ou assure la maintenance de tout ou partie d'un appareil de lecture destiné à lire ou écrire des données figurant au sein de la carte d'identité sociale;" sont remplacés par les mots "-"fournisseur" : toute personne qui fabrique, distribue directement ou indirectement, ou assure la maintenance de tout ou partie d'un appareil de lecture destiné à lire ou écrire des données figurant au sein de la carte d'identité sociale et/ou de la carte d'identité électronique"; b) un troisième tiret est ajouté, rédigé comme suit: "-loi" : Loi du 19 juillet 1991 relative aux registres de la population et aux cartes d'identité et modifiant la loi du 8 août 1983 organisant un Registre national des personnes physiques."

Art. 3.L'article 2 du même arrêté est remplacé comme suit : "Les appareils de lecture visés à l'article 4, alinéa 3, de l'arrêté royal ou visés à l'article 6quinquies de la loi, doivent respecter les spécifications fonctionnelles applicables et les normes de standardisation applicables décrites en annexe, pour que les cartes d'identité puissent être utilisées."

Art. 4.Dans la première phrase de l'article 3 du même arrêté, les mots "pour l'emploi de la carte d'identité sociale" sont insérés entre les mots "des personnes habilitées" et les mots "peuvent obtenir la documentation suivante".

Art. 5.Un article 3bis, rédigé comme suit, est inséré dans le même arrêté : "Les fournisseurs souhaitant mettre à disposition ces appareils de lecture pour l'emploi de la carte d'identité électronique peuvent obtenir auprès du Service public fédéral Technologie de l'Information et de la Communication la documentation suivante : 1° spécifications du système de la carte d'identité électronique, 2° descriptif des commandes nécessaires à la lecture et à l'écriture de la carte d'identité électronique, 3° descriptif de la procédure pour tester en ligne la carte d'identité électronique, 4° spécimens de la carte d'identité électronique."

Art. 6.A l'article 4 du même arrêté sont apportées les modifications suivantes: a) dans la première phrase, les mots "des personnes habilitées" et "auprès de la Banque Carrefour de la sécurité sociale" sont supprimés;b) dans la disposition au 2°, les mots "concernant d'une part le respect de la norme ISO 7816 - 1 à 4 et d'autre part le respect des spécifications fonctionnelles ainsi que des spécifications techniques et critères de qualité et de performance figurant en annexe" sont remplacés par les mots "concernant d'une part le respect des parties pertinentes de la norme ISO 7816 et d'autre part le respect des spécifications fonctionnelles ainsi que des spécifications techniques applicables et critères de qualité et de performance applicables dans l'annexe I au présent arrêté".

Art. 7.Un article 4bis, rédigé comme suit, est inséré dans le même arrêté : «

Art. 4bis.§ 1er. Le fournisseur dépose son dossier de référence : 1° auprès de la Banque Carrefour de la sécurité sociale pour autant que seul un numéro d'enregistrement soit demandé pour un appareil de lecture destiné à lire et/ou écrire des données figurant au sein de la carte d'identité sociale;2° auprès du Service public fédéral Technologie de l'Information et de la Communication pour autant que seul un numéro d'enregistrement soit demandé pour un appareil de lecture destiné uniquement à lire et/ou écrire des données figurant au sein de la carte d'identité électronique. § 2. Si un numéro d'enregistrement est demandé simultanément pour un appareil de lecture destiné à lire et/ou écrire des données figurant au sein de la carte d'identité sociale et la carte d'identité électronique, le fournisseur dépose les deux dossiers de référence distincts et spécifie à chaque fois qu'il s'agit d'une procédure d'enregistrement simultanée.

La Banque Carrefour de la sécurité sociale et le Service public fédéral Technologie de l'Information et de la Communication s'informent sans délai du dépôt simultané par le fournisseur. » § 3. La demande d'enregistrement d'un appareil de lecture de la carte d'identité électronique est faite au moyen du modèle de formulaire établi dans l'annexe II du présent arrêté.

Art. 8.A l'article 5 du même arrêté sont apportées les modifications suivantes : a) la première phrase est remplacée comme suit : "La Banque Carrefour de la sécurité sociale ou, après avis conforme du Service public fédéral Intérieur, le Service public fédéral Technologie de l'Information et de la Communication, attribue(nt) dans une période de 45 jours civils suivant la réception du dossier de référence un numéro d'enregistrement à chaque dossier de référence déposé, pour autant que ce dossier comprenne les pièces citées à l'article 4 et qu'il en ressorte qu'il satisfait aux conditions citées à l'article 2."; b) la deuxième phrase est remplacée comme suit : "Le fournisseur qui dépose un dossier de référence s'engage, à incorporer électroniquement dans les appareils de lecture le numéro d'enregistrement attribué par la Banque Carrefour de la sécurité sociale et/ou le Service public fédéral Technologie de l'Information et de la Communication.En ce qui concerne les appareils de lecture utilisés pour la carte d'identité électronique, le fournisseur s'engage en outre, selon les spécifications prévues à l'annexe II du présent arrêté, à pourvoir de façon visible d'un label tout appareil de lecture enregistré."

Art. 9.Un article 5bis, rédigé comme suit, est inséré dans le même arrêté : «

Art. 5bis.La Banque Carrefour de la sécurité sociale, en ce qui concerne la carte d'identité sociale, et le Service public fédéral Technologie de l'Information et de la Communication, en ce qui concerne la carte d'identité électronique, disposent du droit de soumettre les appareils de lecture enregistrés à un contrôle approfondi en cas de plainte ou de soupçon de non-conformité de l'appareil de lecture au dossier de référence déposé. »

Art. 10.L'alinéa 2 de l'article 6 du même arrêté est remplacée comme suit : "Le fournisseur qui a déposé un dossier de référence s'engage à adapter les appareils de lecture qu'il a installés en cas d'évolution des spécifications fonctionnelles et des normes de standardisation qui lui sont communiquées par la Banque Carrefour de la sécurité sociale et/ou le Service public fédéral Technologie de l'Information et de la Communication."

Art. 11.A l'article 6bis du même arrêté sont apportées les modifications suivantes : a) le première alinéa est remplacée comme suit : "Chaque modification des spécifications fonctionnelles qui est communiquée par la Banque carrefour de la sécurité sociale et/ou le Service public fédéral Technologie de l'Information et de la Communication, est enregistrée auprès de la Banque carrefour de la sécurité sociale, en ce qui concerne les appareils de lecture de la carte d'identité sociale et/ou auprès du Service public fédéral Technologie de l'Information et de la Communication, en ce qui concerne les appareils de lecture de la carte d'identité électronique."; b) l'alinéa 2 est remplacée comme suit : "Le délai entre la fourniture des nouvelles spécifications fonctionnelles par la Banque carrefour de la sécurité sociale et/ou le Service public fédéral Technologie de l'Information et de la Communication et la possibilité de décharger les adaptations auprès des utilisateurs des appareils de lecture ne peut excéder trois mois."; c) le troisième alinéa est remplacée comme suit : "Le dossier de référence relatif aux nouvelles spécifications fonctionnelles est soumis selon les conditions visées à l'article 4bis du présent arrêté par le déposant du dossier d'enregistrement original."; d) dans le quatrième alinéa les mots ", en ce qui concerne la Banque carrefour de la sécurité sociale, " sont insérés entre les mots "comprend" et "les éléments suivants";e) un cinquième alinéa est ajouté, rédigée comme suit : "Le dossier de référence comprend, en ce qui concerne le Service public fédéral Technologie de l'Information et de la Communication, les éléments suivants qui relèvent de la responsabilité du déposant : 1.documentation des procédures de déchargement des nouvelles spécifications fonctionnelles sur les appareils de lecture; 2. manuel d'utilisation permettant à l'utilisateur de l'appareil de lecture de décharger en toute sécurité les nouvelles spécifications fonctionnelles sur son appareil de lecture;3. contrats de maintenance modèles; 4. démonstration du déchargement de la nouvelle version sur chaque type d'appareils de lecture enregistrés.".

Art. 12.L'article 7 du même arrêté est remplacé comme suit : «

Art. 7.Le fournisseur qui a reçu un numéro d'enregistrement s'engage par tous les moyens appropriés à aider la Banque Carrefour de la sécurité sociale et/ou le Service public fédéral Technologie de l'Information et de la Communication à pouvoir dépister l'origine d'éventuels problèmes de fonctionnement du lecteur de cartes enregistré et/ou de son logiciel ou d'éventuels problèmes de falsification des cartes d'identité sociale et/ou des cartes d'identité électroniques. »

Art. 13.L'article 8 du même arrêté est remplacé comme suit : «

Art. 8.Toute personne habilitée à utiliser la carte d'identité sociale et/ou la carte d'identité électronique peut consulter auprès de la Banque Carrefour, en ce qui concerne les appareils de lecture pour la carte d'identité sociale, et auprès du Service public fédéral Technologie de l'Information et de la Communication, en ce qui concerne les appareils de lecture pour la carte d'identité électronique, la liste des dossiers de référence ainsi que les dossiers de référence des modèles d'appareils de lecture tels que déposés par les fournisseurs, en ce compris les indications d'équivalence par rapport aux spécifications techniques, aux critères de qualité ou de performance. »

Art. 14.A l'article 9 du même arrêté les mots ", Notre Ministre des Affaires sociales et de la Santé publique, Notre Ministre de l'Intérieur, Notre Ministre de l'Economie, Notre Ministre des Classes moyennes et de l'Agriculture et notre Ministre de l'Emploi, sont, chacun en ce qui les concerne," sont insérés entre les mots "Affaires" et "chargés".

Art. 15.L'annexe Ire jointe au présent arrêté remplace l'annexe à l'arrêté royal du 13 février 1998 relatif au spécifications des appareils de lecture de la carte d'identité sociale.

Les annexes II et III jointes au présent arrêté sont ajoutées commes annexes II et III au même arrêté royal.

Art. 16.Le présent arrêté entre en vigueur le jour de sa publication au Moniteur belge.

Art. 17.Notre Ministre de l'Intérieur, Notre Ministre de l'Economie, Notre Ministre des Affaires sociales et de la Santé publique, Notre Ministre des Classes moyennes et de l'Agriculture et Notre Ministre de l'Emploi sont, chacun en ce qui les concerne, chargés de l'exécution du présent arrêté.

Donné à Bruxelles, le 7 décembre 2006.

ALBERT Par le Roi : Le Ministre de l'Intérieur, P. DEWAEL Le Ministre de l'Economie, M. VERWILGHEN Le Ministre des Affaires sociales, R. DEMOTTE La Ministre des Classes moyennes et de l'Agriculture, Mme S. LARUELLE Le Ministre de l'Emploi, P. VANVELTHOVEN

Annexe Ire Table des matières Art.1er Procédure d'enregistrement d'un lecteur 1.introduction 1.1. But des annexes 1.2. Portée 1.3. Catégories des lecteurs 1.4. Plates-formes 1.5. Environnement 2. Besoins et spécifications 2.1. Besoins et termes de modèle et de sécurité 2.2. Besoins en termes d'interface carte 2.3. Besoins en termes d'interface utilisateur 2.4. Besoins en termes d'interface application 2.5. Besoins spécifiques 3. Scénarios de test de bas niveau 3.1. Scénario ISO7816/APDU 3.2. Scénario Data Capture 3.2.1. Version carte et certificat RRN 3.2.2. Identité, adresse, photo 3.2.3. Contrôle PIN 3.3. Scénario Cryptoki/PKCS (11 3.3.1. Initialisation bibliothèque, slot et token 3.3.2. Déclenchement signature avec clé d'authentication 3.3.3. Modifier PIN 3.3.4. Déclenchement signature avec clé de signature 3.3.5. Modifier PIN 4. Scénarios de validation de haut niveau 4.1. Scénario I : installation/désinstallation et Plug&Play 4.1.1. Conditions préalables 4.1.2. Objectifs de contrôle 4.1.3. Conditions postérieures 4.2. Scénario II : authentication forte 4.2.1. Conditions préalables 4.2.2. Objectifs de contrôle 4.2.3. Conditions postérieures 4.3. Scénario III : capture de données et modification PIN 4.3.1. Conditions préalables 4.3.2. Objectifs de contrôle 4.3.3. Conditions postérieures 4.4. Scénario IV : signature électronique 4.4.1. Conditions préalables 4.4.2. Objectifs de contrôle 4.4.3. Conditions postérieures Art. 2.

Spécifications des lecteurs 1. Compatibilité materielle avec la puce 2.Compatibilité logicielle avec la puce 2.1. Tous les lecteurs 2.2. Lecteurs avec clavier PIN 2.2.1. Commandes de carte (APDU) à mettre en oeuvre 2.2.2. Commandes de lecteur (APDU) à mettre en oeuvre 2.2.3. Format PIN 3. Compatibilité logicielle avec le middleware 3.1. Pilotes PC/SC 3.2. Intégration au middleware 3.2.1. SCR_Init ( ) 3.2.2. SCR_VerifyPIN ( ) 3.2.3. SCR_ChangePIN ( ) 3.3. Afficheur 3.3.1. SCR_VerifyPIN ( ) 3.3.2. SCR_ChangePIN ( ) Art. 3.

Spécifications du middleware Identité 1. Introduction 1.1. Matrice des environnements de développement 2. Spécifications fonctionnelles 2.1. Gestion des versions et compatibilité 2.2. Saisie du PIN 2.3. Remarque qur la longueur maximale des paramètres 2.4. Applications multifilières 2.5. Organisation des API 2.6. Fonctions d'initialisation et de terminaison 2.6.1. BEID_Init 2.6.2. BEID_Exit 2.7. Fonctions d'identité 2.7.1. BEID_GetID 2.7.2. BEID_GetAddress 2.7.3. BEID_GetPicture 2.7.4. Fonctions d'identité hors ligne 2.7.4.1. BEID_GetRawData 2.7.4.2. BEID_SetRawData 2.8. Fonctions générales de haut niveau 2.8.1. BEID_BeginTransaction 2.8.2. BEID_EndTransaction 2.8.3. BEID_SelectApplication 2.8.4. BEID_ReadFile 2.8.5. BEID_WriteFile 2.8.6. BEID_VerifyPIN 2.8.7. BEID_ChangePIN 2.8.8. BEID_GetPINStatus 2.9. Fonctions de bas niveau 2.9.1. BEID_GetVersionInfo 2.9.2. BEID_SendAPDU 2.9.3. BEID_FlushCache 2.10. Identification PIN 2.10.1. Types de PIN 2.10.2. Utilisations du PIN 2.11. Paramètres de politique en entrée - OCSP et CRL 2.12. Statut des fonctions 2.12.1. Codes d'erreur généraux 2.13. Contrôle de signature et validation de certificat 2.13.1. Contrôle de signature 2.13.2. Résultat du contrôle et de la validation du certificate 2.13.3. Politiques OCSP et CRL appliqués 3. Interfaces de programmation 3.1. APIC 3.1.1. Structures 3.1.2. Fonctions 3.2. API Java 3.2.1. Data Classes 3.2.2. Main Classe 3.2.3. Applet Classe 3.3. API ActiveX 3.3.1. Définitions d'interface 3.3.2. Fonctions 4. Installation 4.1. Package d'installation 4.2. Runtime 4.3. Bibliothèque C 4.4. Java Art. 3bis Spécifications du middleware Crypto 1. But 2.Architecture 2.1. Interfaces 2.1.1. l'Interface Crypto API 2.1.1.1. CSP-Architecture de haut niveau 2.1.1.2. CSP-Architecture de bas niveau 2.1.2. l'Interface PKCS (11 2.1.2.1. PKCS (11-Architecture de haut niveau 3. Guide de programmation 3.1. Introduction 3.2. l'Interface Crypto API 3.2.1. CryptAcquireContext 3.2.2. CryptReleaseContext 3.2.3. CryptGenerateKey 3.2.4. CryptDeriveKey 3.2.5. CryptDestroyKey 3.2.6. CryptSetKeyParam 3.2.7. CryptGetKeyParam 3.2.8. CryptSetProvParam 3.2.9. CryptGetProvParam 3.2.10. CryptSetHashParam 3.2.11. CryptGetHashParam 3.2.12. CryptExportKey 3.2.13. CryptImportKey 3.2.14. CryptEncrypt 3.2.15. CryptDecrypt 3.2.16. CryptCreateHash 3.2.17. CryptHashData 3.2.18. CryptHashSessionKey 3.2.19. CryptSignHash 3.2.20. CryptDestroyHash 3.2.21. CryptVerifySignature 3.2.22. CryptGenRandom 3.2.23. CryptGetUserKey 3.2.24. CryptDuplicateHash 3.2.25. CryptDuplicateKey 3.3. l'Interface PKCS#11 3.3.1. Appels d'API mis en oeuvre 3.3.1.1. Fonctions générales 3.3.1.2. Fonctions de gestion de slot et de token 3.3.1.3. Fonctions de gestion de session 3.3.1.4. Fonctions de gestion d'objets 3.3.1.5. Fonctions de signature 3.3.1.6. Fonctions de digest 3.3.1.7. Fonctions de generation aléatoire (à confirmer bientôt) 3.3.2. Mécanismes de signature supportés 3.3.3. Informations de slot et de token 3.3.4. Comportement en cas de lecteur à clavier PIN 3.3.5. Comportement en cas de clé de non-répudiation 4. Références Art.1er. Procédure d'enregistrement d'un lecteur 1. Introduction 1.1. But des annexes Ce document référence les spécifications et décrit les exigences à remplir pour obtenir le label " compatible eID belge " d'un lecteur.

Avant le processus d'enregistrement, le demandeur (fabricant, revendeur, distributeur ou intégrateur du lecteur) accomplira dans ses services internes un ensemble d'opérations/scénarios qui serviront de base aux certificats de conformité, aux données d'essai et à la validation finale : 1) Obtenir les certificats d'accréditation ISO, garantissant la conformité technique, auprès des instances ISO (voir le chapitre "Spécifications techniques").2) Exécuter (dans ses services internes, sur son propre équipement) les scénarios de test de bas niveau et obtenir les données d'essai demandées (voir le chapitre "Scénarios de bas niveau").3) Exécuter (en ligne, sur le site de test eID) les scénarios de validation de haut niveau et obtenir les données de confirmation nécessaires (voir le chapitre "Scénarios de haut niveau"). Le demandeur complétera ensuite le formulaire d'enregistrement (avec tous les détails demandés au sujet du produit) et le soumettra à l'instance d'enregistrement des lecteurs.

Note 1 : le formulaire d'enregistrement contient une déclaration de conformité du fabricant, certifiant que le demandeur a accompli toutes les étapes précédentes et que l'information fournie avec la déclaration est correcte.

Note 2 : l'instance d'enregistrement des lecteurs se réserve le droit d'évaluer plus en détail la conformité du lecteur (p.ex. en cas de réclamation). Trois exemplaires du produit visé dans le formulaire d'enregistrement accompagneront le formulaire, aux fins d'archivage et d'évaluation. 1.2. Portée Le présent document porte principalement sur l'enregistrement des lecteurs. Par "lecteur", nous entendons tout dispositif servant d'interface SmartCard avec la carte eID (autonome ou non, incorporé ou non, propre à l'application ou non).

Le document ne couvre pas les besoins spécifiques liés aux lecteurs utilisés pour des opérations de gestion de carte (activation, (ré)initialisation de PIN/PUK, changement dans les données, etc.) qui sont propres à l'émetteur de la carte (p.ex. activation initiale de la carte), pour le blocage/déblocage de la carte (p.ex. si le nombre de tentatives de saisie du PIN atteint la limite), et/ou pour une modification de la carte (p.ex. quand il faut mettre à jour le fichier d'adresses). Ce type de lecteur nécessite des fonctions spéciales de fusion PIN/PUK, qui sortent du cadre de ce document. 1.3. Catégories des lecteurs Les lecteurs sont répartis en catégories suivant les critères ci-dessous : - connectable : le lecteur est équipé d'une interface hôte (p.ex. USB, RSR232, PCMCIA, etc.) - affichage sécurisé : le lecteur possède un affichage réservé à la visualisation des messages - clavier PIN sécurisé : le lecteur possède un clavier numérique PIN destiné à la saisie du numéro PIN - application sécurisée : le lecteur met en place un canal de communication sécurisé avec l'application qui le commande Pour la consultation du tableau, voir image - Value Checker (lecteur de valeur) : lecteur non connecté, conçu pour lire facilement le contenu de la puce, sans être capable d'accomplir des transactions cryptographiques (ne nécessite pas d'enregistrement). - Transparent Reader (lecteur transparent) : lecteur connectable, sans affichage ni clavier PIN dédié (PIN et code d'état sont introduits et affichés sur des supports non dignes de confiance comme le clavier normal et le moniteur). - Secured reader (lecteur sécurisé) : lecteur connectable avec affichage et/ou clavier PIN dédié (PIN et code d'état sont introduits directement sur le clavier PIN et/ou présentés sur l'affichage). - Trusted Reader (lecteur de confiance) : lecteur sécurisé, avec applications de confiance, établissant un canal de communication sécurisé avec le lecteur. 1.4. Plates-formes Le support de la carte eID étant lié à la plate-forme, l'enregistrement sera demandé par plate-forme (le lecteur peut naturellement faire l'objet de plusieurs enregistrements, pour des plates-formes différentes).

Les plates-formes suivantes sont actuellement prises en charge, mais l'instance d'enregistrement des lecteurs se réserve le droit d'ajouter ou de supprimer des plates-formes en fonction de la demande du marché, du support des fournisseurs, etc.

Pour la consultation du tableau, voir image En raison du grand nombre de variantes dans les plates-formes, nous supposons que les tests/scénarios sont exécutés sur la version la plus légère, nue, de la plate-forme en question (p.ex. édition familiale plutôt que professionnelle, édition personnelle plutôt que serveur, etc.), après installation de tous les correctifs (de sécurité) disponibles. Si le lecteur nécessite une variante ou un correctif spécifique, le fait doit être précisé clairement dans le formulaire d'enregistrement et sera mentionné sur le site web listant les lecteurs enregistrés.

Pour mettre en place une interface commune avec les applications, le lecteur doit comporter un ensemble d'API (dans le package d'installation ou directement préinstallé). Certaines de ces API sont propres à une plate-forme (p.ex. Microsoft CryptoAPI), d'autres sont spécifiquement belges (p.ex. eID runtime) - voir le chapitre "Spécifications".

L'instance d'enregistrement des lecteurs se réserve le droit d'adapter le scénario de test à l'évolution technique des interfaces et des normes propres aux plates-formes. 1.5. Environnement Les impératifs de sécurité de la carte eID étant propres à l'environnement, l'enregistrement fera par ailleurs une distinction entre les lecteurs destinés à un environnement domestique/professionnel/mobile et les lecteurs destinés à un environnement public (voir le chapitre "Impératifs de sécurité").

En effet, les lecteurs à installer dans des endroits publics, sans être soumis au contrôle de citoyens belges, présentent des impératifs de sécurité spéciaux, que l'on peut résumer ainsi : - disponibilité d'un clavier PIN sécurisé, pour garantir la confidentialité du code PIN - disponibilité d'un affichage sécurisé pour garantir l'exactitude des messages.

Deux logos " compatible eID belge " distingueront ces deux catégories de lecteurs. 2. Besoins et spécifications 2.1. Besoins et termes de modèle et de sécurité Un environnement compatible avec la carte eID se compose d'un utilisateur final en interaction avec un système compatible eID. A son tour, le système eID compte trois parties : - la carte eID elle-même - le lecteur compatible avec la carte eID - l'application compatible avec la carte eID. Pour la consultation du tableau, voir image L'application compatible eID contient tous les composants propres à l'application, nécessaires notamment pour la présentation des documents, la visualisation des données/attributs, la mise en forme de la signature, etc. Plusieurs instances de l'application peuvent être présentes dans la même unité physique et partager le même lecteur.

Le lecteur compatible eID doit comporter tous les composants génériques (matériels et/ou logiciels) nécessaires à l'interfaçage de la carte eID conformément aux impératifs de sécurité décrits dans [CEN/CWA 14170] et traduits en spécifications techniques dans [EID/READERS 2.7.3], [EID/CRYPTO 1.4.0] et [EID/IDENTITY 1.0.0]. En particulier : - PINPAD (User Input & Authentication Component - composant de saisie utilisateur et authentification) : ce composant assure les fonctions d'authentification sécurisée via lesquelles le code PIN de l'utilisateur est introduit et comparé au code PIN contenu dans la carte. L'on distingue généralement les lecteurs munis d'un clavier PIN spécifique et ceux qui font usage du clavier générique (numpad). Ce composant doit être conforme aux impératifs de sécurité de [CEN/CWA 14170 - Chapitre 13], traduits en spécifications techniques dans [EID/READERS 2.7.3 - Chapitres 2 & 3]. - DISPLAY (User Output & Control Component - composant d'affichage utilisateur et contrôle) : ce composant se charge des interactions sécurisées entre l'utilisateur et l'application qui permettent au premier de contrôler l'exécution et qui renvoient codes d'erreur et messages d'état. L'on distingue généralement les lecteurs munis d'un afficheur dédié et ceux qui font usage de l'écran générique. Ce composant doit être conforme aux impératifs de sécurité de [CEN/CWA 14170 - Chapitre 12], traduits en spécifications techniques dans [EID/READERS 2.7.3 - Chapitres 2 & 3]. - APPLI/F (Application Input/Output Interface Component - composant d'interface d'entrée/de sortie de l'application) : ce composant met en place les fonctions de manipulation sécurisée des données qui permettent à l'application d'interagir avec le lecteur eID pour envoyer et recevoir les données de façon normalisée et sécurisée. Il constitue généralement une interface générique avec l'application. Il doit être conforme aux impératifs de sécurité de [CEN/CWA 14170 - Chapitre 15], traduits en spécifications techniques dans [EID/CRYPTO 1.4.0] et [EID/IDENTITY 1.0.0]. - CARDI/F (Card Input/Output Interface Component - composant d'interface d'entrée/de sortie de la carte) : ce composant met en place les fonctions d'interaction qui permettent à l'application d'échanger [ISO/IEC 7816] des commandes avec la carte. Il doit être conforme aux impératifs de sécurité de [CEN/CWA 14170 - Chapitre 16], traduits en spécifications techniques dans [EID/READERS 2.7.3 - Chapitres 1 et 2.1]. 2.2 Besoins en termes d'interface carte L'interface carte [ISO7816] sera conforme aux paramètres des spécifications [EID/READER 2.7.3, chapitres 1er et 2.1].

Elle respectera aussi : - les impératifs de sécurité décrits dans [EN60950] - les critères génériques d'émissions électromagnétiques décrits dans [EN50081] - les critères génériques d'immunité électromagnétique décrits dans [EN50081] - les critères génériques de perturbations radio-électriques décrits dans [EN55022].

Note : si le lecteur possède une interface à deux slots, il devra être conforme aux spécifications des lecteurs de cartes SIS/SAM (voir www.ksz-bcss.fgov.be). 2.3 Besoins en termes d'interface utilisateur Le processus d'interaction avec l'utilisateur peut trouver place dans deux types d'environnement physique, où le système eID est contrôlé par des organismes différents : 1. Lieu public : le système eID est installé dans un lieu public (gare, agence de banque, bureau de poste ou tout autre endroit exploité par un prestataire de services qui n'est pas nécessairement lié à l'utilisateur final ou sous son contrôle).Sans autres mesures de sécurité techniques, ce type d'environnement est exposé à une série de risques (p.ex. remplacement par un système eID contrefait). En conséquence, dans les lieux publics, les impératifs techniques des systèmes eID seront nécessairement plus stricts. 2. Domicile et lieu de travail : le système eID est installé dans un domicile ou sur un lieu de travail, généralement sous le contrôle direct de l'utilisateur (p.ex. téléphone mobile). Dans ce cas, les impératifs de sécurité peuvent être respectés par des méthodes d'organisation mises en place par l'utilisateur. Les moyens techniques nécessaires pour répondre aux impératifs de sécurité peuvent être moins stricts.

Selon son utilisation, le lecteur de carte devra se conformer à des besoins et spécifications différents, résumés ci-dessous : - les lecteurs installés dans les lieux publics devront posséder un clavier PIN et un afficheur dédiés et sécurisés, intégrés dans l'appareil (clavier et écran standard ne peuvent servir aux interactions avec l'utilisateur) les lecteurs installés dans un environnement domestique ou professionnel peuvent faire appel au clavier et à l'écran génériques pour les interactions avec l'utilisateur. 2.4 Besoins en termes d'interface application Le gouvernement fédéral a développé un environnement runtime eID qui est mis gratuitement à la disposition de tout utilisateur final. Il constitue un ensemble de bibliothèques, outils et exécutables permettant de donner une interface générique aux applications qui doivent communiquer/s'interfacer avec une carte eID. Cet environnement regroupe quatre composants : - middleware (intergiciel) données eID : présente une interface d'extraction de données standardisée aux applications, pour leur permettre d'exploiter les fonctions de capture de données de la carte. - middleware cryptographique eID : présente une interface de cryptographie standardisée aux applications, pour leur permettre d'exploiter les fonctions d'authentification et de signature de la carte. - middleware d'accès eID : utilisé par les deux autres pour se connecter et communiquer de façon sécurisée avec un service d'accès eID - le service d'accès eID utilisé par un middleware d'accès eID pour la connexion au lecteur physique (il peut s'agir d'un simple câble ou d'un réseau).

Pour la consultation du tableau, voir image L'environnement runtime eID est naturellement lié à la plate-forme.

Une version est disponible pour chaque plate-forme supportée.

Plusieurs releases de l'environnement eID seront prévus pour suivre les releases de la carte eID dans le temps.

Note : selon la plate-forme, le middleware cryptographique pourra posséder plusieurs interfaces pour répondre aux impératifs propres au fournisseur : - Linux : seul PKCS#11 est requis - Microsoft : PKCS#11 et Microsoft CryptoAPI sont requis - MacOS : PKCS#11 et Apple CryptoAPI sont requis.

Le gouvernement belge considère l'environnement runtime eID comme remplissant tous les impératifs à respecter par le composant interface d'application. De plus, l'environnement runtime eID porte une signature codée du gouvernement belge, qui garantit la diffusion des exemplaires légitimes uniquement. Un kit de développement logiciel est aussi disponible gratuitement, avec des exemples et des directives concernant l'interface avec l'environnement runtime eID. L'environnement runtime eID étant considéré comme faisant partie du lecteur, il existe deux alternatives : - le lecteur eID est acquis par l'utilisateur final en tant que composant séparé (p.ex. lecteur connectable); il doit alors inclure les outils d'installation du runtime eID et les guides d'installation/utilisation livrés avec le lecteur. Le package d'installation doit intégrer à la fois les pilotes propres au lecteur et l'environnement runtime eID (la partie concernant le runtime eID peut être rendue facultative pour que l'utilisateur puisse décider de l'installer ou non). - le lecteur eID est acquis incorporé dans un autre produit (p.ex. un PC comprenant un lecteur de carte à puce). Dans ce cas, le runtime eID doit être préinstallé. Le package d'installation eID et les guides d'installation/utilisation doivent aussi être fournis (dans la perspective d'une réinstallation).

Note : s'il n'existe pas d'environnement runtime pour un lecteur particulier (plate-forme non supportée et/ou middleware identité/crypto directement mis en oeuvre dans le firmware de l'appareil), le demandeur a le droit de développer le sien (ou d'adapter la version officielle à son environnement propriétaire).

Dans un tel cas, l'instance d'enregistrement des lecteurs se réserve le droit d'évaluer la conformité et l'équivalence avec l'environnement runtime eID officiel. 2.5 Besoins spécifiques L'utilisateur final doit pouvoir installer/réinstaller/supprimer/mettre à niveau l'environnement runtime eID quand une nouvelle version est publiée sur le site web eID. Pour cette raison, la présente procédure d'enregistrement ne prendra pas en charge les environnements runtime de tiers ni les environnements runtime modifiés, sauf accord contractuel avec l'instance d'enregistrement des lecteurs.

Après installation, l'utilisateur final doit pouvoir déconnecter/reconnecter physiquement le lecteur (mode plug and play) sans devoir redémarrer ou réamorcer le système. Cette exigence ne concerne que les lecteurs connectables utilisés dans le contexte domestique ou professionnel.

Il doit être facile de déterminer si le lecteur a été enregistré conformément à la procédure décrite dans ce document (p.ex. via un autocollant). L'on doit également pouvoir connaître sans difficulté la marque et le modèle de lecteur, surtout s'il est incorporé dans un autre appareil. La marque et le type doivent figurer clairement dans la documentation et sur les parties visibles de l'unité. 3. Scénarios de test de bas niveau Ces ensembles de scénarios seront exécutés par chaque fournisseur de lecteur eID pour établir la compatibilité de son produit avec la carte eID.Ils sont organisés en quatre parties, suivant la plate-forme : - La première partie se compose d'un jeu de commandes ISO7816 à exécuter et tester dans l'appel de fonction SendAPDU de l'environnement runtime eID. - La deuxième partie se compose d'un jeu de fonctions Data Capture à exécuter et tester dans les appels de fonction GetXXX de l'environnement runtime eID. - La troisième partie se compose d'un jeu de fonctions crypto à exécuter et tester dans le middleware crypto de l'environnement runtime eID (mise en oeuvre PKCS#11). - La quatrième partie (nécessaire seulement sur les plates-formes Microsoft et Apple) se compose d'un jeu de fonctions crypto à exécuter et tester dans le middleware crypto de l'environnement runtime eID (mise en oeuvre CryptoAPI).

Les spécifications du contenu de la carte et des interfaces se trouvent dans : - [EID/CRYPTO 1.4.0] pour les éléments cryptographiques (clés, certificats, PIN, etc.) et les spécifications du middleware crypto - [EID/IDENTITY 1.0.0] pour les données (identité, adresse, photo) et spécifications du middleware données - [EID/CARD 2.0.0] pour les commandes ISO7816 supportées et les spécifications de l'interface de carte eID. 3.1 Scénario ISO7816/APDU Conditions préalables : - Lecteur de carte à puce correctement installé et configuré - Bibliothèque d'identité correctement installée et configurée - Carte de test insérée Pour la consultation du tableau, voir image Conditions postérieures : - assertion entièrement réussie - les informations suivantes doivent figurer dans le formulaire d'enregistrement : réponse de la carte au SGNID sélection. 3.2 Scénario Data Capture 3.2.1 Version carte et certificat RRN Conditions préalables : - Lecteur de carte à puce correctement installé et configuré - Bibliothèque d'identité correctement installée et configurée - Carte de test insérée Pour la consultation du tableau, voir image Conditions postérieures : - assertion entièrement réussie - les informations suivantes doivent figurer dans le formulaire d'enregistrement : - version (numéro de série, code composant, numéro et version système d'exploitation, numéro et version softmask, version applet, version système d'exploitation global, version interface applet, support PKCS#1, version échange de clés, cycle de vie application, personnalisation graphique, personnalisation électronique, interface personnalisation électronique) - Certificat RRN. 3.2.2 Identité, adresse et photo Conditions préalables : - Lecteur de carte à puce correctement installé et configuré - Bibliothèque d'identité correctement installée et configurée - Carte de test insérée Pour la consultation du tableau, voir image Conditions postérieures : - assertion entièrement réussie - les informations suivantes doivent figurer dans le formulaire d'enregistrement : - identité (numéro carte et puce, validité, commune, NRN, prénoms et nom de famille, lieu et date de naissance, nationalité, sexe, titre de noblesse) - adresse (rue, numéro, boîte, code postal, localité, pays) 3.2.3 Contrôle PIN Conditions préalables : - Lecteur de carte à puce correctement installé et configuré - Bibliothèque d'identité correctement installée et configurée - Carte de test insérée Pour la consultation du tableau, voir image Conditions postérieures : - assertion entièrement réussie - les informations suivantes doivent figurer dans le formulaire d'enregistrement : - si le lecteur possède un clavier PIN sécurisé, celui-ci doit servir à introduire le PIN s'il s'agit d'un lecteur sans clavier PIN sécurisé, le PIN doit être introduit à l'écran. 3.3 Scénario Cryptoki/PKCS#11 3.3.1 Initialisation bibliothèque, slot et token Conditions préalables : - Lecteur de carte à puce correctement installé et configuré - Bibliothèque Cryptoki/PKCS#11 correctement installée et configurée - Carte de test insérée Pour la consultation du tableau, voir image Conditions postérieures : - assertion entièrement réussie - les informations suivantes doivent figurer dans le formulaire d'enregistrement : - bibliothèque (version cryptoki, id. fabricant, version et description bibliothèque) - slot/lecteur (description slot, id. fabricant, version matériel, version firmware) - token/carte (label et modèle token, id. fabricant, numéro de série, version matériel, version firmware). 3.3.2. Déclenchement signature avec clé d'authentification Conditions préalables : test précédent réussi (initialisation bibliothèque, slot et token) Pour la consultation du tableau, voir image Conditions postérieures : - assertion entièrement réussie - les informations suivantes doivent figurer dans le formulaire d'enregistrement : certificats, résumé et signature 3.3.3 Modifier PIN Conditions préalables : test précédent réussi (session initialisée) Pour la consultation du tableau, voir image Conditions postérieures : assertion entièrement réussie 3.3.4 Déclenchement signature avec clé de signature Conditions préalables : test précédent réussi (initialisation bibliothèque, slot et token) Pour la consultation du tableau, voir image Conditions postérieures : - assertion entièrement réussie - les informations suivantes doivent figurer dans le formulaire d'enregistrement : certificats, résumé et signature 3.3.5 Modifier PIN Conditions préalables : test précédent réussi (session initialisée) Pour la consultation du tableau, voir image Conditions postérieures : - assertion entièrement réussie 4. Scénarios de validation de haut niveau Ces ensembles de scénarios seront exécutés par chaque fournisseur de lecteur eID pour établir la compatibilité de son produit avec la carte eID.Ils sont organisés en quatre parties à exécuter l'une après l'autre (chaque partie réutilise les résultats de la précédente) : - Installation, désinstallation, mise à jour, reconfiguration - Authentification forte - Capture de données et modification PIN - Signature qualifiée.

Pour chaque scénario de validation, un ensemble de conditions préalables, objectifs de contrôle et conditions postérieures est décrit dans le but d'évaluer la compatibilité du lecteur et des logiciels correspondants.

Note : certains de ces scénarios peuvent ne pas s'appliquer, en fonction des circonstances suivantes : - conditionnement du lecteur (p.ex. la désinstallation/réinstallation ne s'applique évidemment pas aux lecteurs intégrés à un PC) - Plug&Play (p.ex. la déconnexion/reconnexion ne s'applique évidemment pas aux lecteurs incorporés dans un autre élément matériel comme un clavier). - CryptoAPI (p.ex. le support d'un middleware propriétaire/propre à une plate-forme ne concerne que la plate-forme en question). 4.1 Scénario I : installation/désinstallation et Plug&Play 4.1.1. Conditions préalables * Carte de test activée disponible (avec codes PIN connus) * PC local préinstallé (avec plate-forme/système d'exploitation cible), navigateur Internet, pilotes du lecteur et environnement runtime eID appropriés * Connexion Internet configurée avec les ports 80 (http) et 443 (https) disponibles. * Guide d'utilisation/installation du lecteur disponible. 4.1.2. Objectifs de contrôle * Installer le lecteur de carte suivant les instructions du guide d'utilisation (p.ex. redémarrage, droits d'administration, etc.) * [le cas échéant] Désinstaller et réinstaller le lecteur de carte suivant les instructions du guide d'utilisation (p.ex. redémarrage, droits d'administration, etc.) * [le cas échéant] Débrancher et rebrancher le lecteur de carte * Validation capture de données eID ==> OC1 : Lancer l'application de capture de données ==> OC3 : Insérer la carte eID ==> OC2 : Capturer les données ==> OC5 : Retirer la carte eID ==> OC6 : Capturer les données ==> OC7 : Insérer la carte eID (sur demande) * [le cas échéant] Installer un deuxième lecteur de carte du même modèle * [le cas échéant] Débrancher et rebrancher le deuxième lecteur de carte * Validation de la capture de données eID (à exécuter sur les deux lecteurs) ==> OC1 : Lancer l'application de capture de données ==> OC3 : Insérer la carte eID ==> OC2 : Capturer les données ==> OC5 : Retirer la carte eID ==> OC6 : Capturer les données ==> OC7 : Insérer la carte eID (sur demande) 4.1.3. Conditions postérieures * Ensemble de numéros de version de configuration (système d'exploitation/lecteur/runtime, etc.) * Images d'écran de l'outil de capture de données. 4.2. Scénario II : authentification forte 4.2.1. Conditions prélables * Scénario I réussi * Site de validation/test eID disponible * Navigateurs Internet préinstallés (compatibles SSLv3, avec interface PKCS#11) * [le cas échéant] Navigateurs Internet préinstallés (compatibles SSLv3, avec interface CryptoAPI) * Scénario II séléctionné 4.2.2. Objectifs de contrôle * Connexion au service de test via https avec navigateur compatible PKCS#11 : ==> OC1 : configurer le navigateur pour reconnaître l'interface eID PKCS#11 ==> OC2 : Serveur authentifié ==> OC3 : Certificat client "authentification" sélectionné ==> OC4 : Code PIN demandé ==> OC5 : Authentification réussie * [le cas échéant] Connexion au service de test via https avec navigateur compatible CryptoAPI : ==> OC1 : configurer le navigateur en chargeant les certificats de l'utilisateur final dans le dépôt de certificats ==> OC2 : Serveur authentifié ==> OC3 : Certificat client "authentification" sélectionné ==> OC4 : Code PIN demandé ==> OC5 : Authentification réussie 4.2.3. Conditiions postérieures * Données enregistrées avec succès sur le site de validation (système d'exploitation/navigateur/interface/carte/etc.). * Les messages apparaissant sur l'afficheur doivent être signalés. * Numéro de carte, données et heure approximative de la transaction avec le site de validation doivent être signalés. * Image d'écran de la dernière page du site de test eID. 4.3. Scénario III : capture de données et modification PIN 4.3.1. Conditions préalables * Scénario II réussi * Connexion sécurisée établie avec le site de validation * Scénario III sélectionné. 4.3.2. Objectifs de contrôle * Connexion au service de test via https avec navigateur compatible PKCS#11 : ==> OC1 : Serveur authentifié ==> OC2 : Certificat client "authentification" sélectionné ==> OC3 : Code PIN demandé ==> OC4 : Authentification réussie ==> OC5 : Capture de données appelée automatiquement ==> OC6 : Affichage Capture de données ==> OC7 : Modification code PIN ==> OC8 : Modification réussie * [le cas échéant] Connexion au service de test via https avec navigateur compatible CryptoAPI : ==> OC1 : Serveur authentifié ==> OC2 : Certificat client "authentification" sélectionné ==> OC3 : Code PIN demandé ==> OC4 : Authentification réussie ==> OC5 : Capture de données appelée automatiquement ==> OC6 : Affichage Capture de données ==> OC7 : Modification code PIN ==> OC8 : Modification réussie 4.3.3. Conditions postérieures * Données enregistrées avec succès sur le site de validation (système d'exploitation/navigateur/interface/carte/etc.). * Les messages apparaissant sur l'afficheur doivent être signalés. * Numéro de carte, données et heure approximative de la transaction avec le site de validation doivent être signalés. * Image d'écran de la dernière page du site de test eID. 4.4. Scénario IV : signature éléctronique 4.4.1. Conditions préalables * Scénario III réussi * Connexion sécurisée établie avec le site de validation * Scénario IV selectionné 4.4.2. Objectifs de contrôle * Connexion au service de test via https avec navigateur compatible PKCS#11 : ==> OC1 : Serveur authentifié ==> OC2 : Certificat client "authentification" sélectionné ==> OC3 : Code PIN demandé ==> OC4 : Authentification réussie ==> OC5 : Signature électronique appelée automatiquement ==> OC6 : Certificat client "signature" sélectionné ==> OC7 : Code PIN demandé ==> OC8 : Signature réussie * [le cas échéant] Connexion au service de test via https avec navigateur compatible CryptoAPI : ==> OC1 : Serveur authentifié ==> OC2 : Certificat client "authentification" sélectionné ==> OC3 : Code PIN demandé ==> OC4 : Authentification réussie ==> OC5 : Signature électronique appelée automatiquement ==> OC6 : Certificat client "signature" sélectionné ==> OC7 : Code PIN demandé ==> OC8 : Signature réussie 4.4.3.Conditions postérieures * Données enregistrées avec succès sur le site de validation (système d'exploitation/navigateur/interface/carte/etc.). * Les messages apparaissant sur l'afficheur doivent être signalés. * Numéro de carte, données et heure approximative de la transaction avec le site de validation doivent être signalés. * Image d'écran de la dernière page du site de test eID. Art.2. Spécifications des lecteurs 1. Compatibilité matérielle avec la puce Le lecteur doit être conforme aux normes ou recommandations suivantes : - ISO/IEC 7816-1 : caractéristiques physiques - ISO/IEC 7816-2 : dimensions et emplacement des contacts - ISO/IEC 7816-3 : signaux électroniques et protocoles de communication - Format de carte ID1 - Protocole asynchrone T=0 (T=1 facultatif) - Tension électrique VCC = 5V,5 % - maximum 50 mA - Tension de programmation VPP égale à VCC, 5 % - Fréquence d'horloge initiale de 3,5712 MHz (9.600 bps). La fréquence d'horloge de travail est égale ou supérieure à la fréquence d'horloge initiale. - Contacts : - pression de contact ( 1 N - résistance de contact ( 0,3 Ohm - force d'insertion de la carte ( 12 N - force d'extraction de la carte ( 1 N 2. Compatibilité logicielle avec la puce 2.1. Tous les lecteurs - Tous les lecteurs doivent être conformes aux normes ISO/IEC 7816-4 et 7816-8 de format d'échange de commandes. 2.2. Lecteurs avec clavier PIN Les lecteurs avec clavier PIN doivent mettre en oeuvre toutes les commandes ISO 7816-4 et 7816-8 (APDU) qui nécessitent la saisie du PIN mais sans le communiquer à l'extérieur du lecteur. 2.2.1 Commandes de carte (APDU) à mettre en oeuvre - PIN Verify Pour la consultation du tableau, voir image - PIN Change (Change Reference Data) Pour la consultation du tableau, voir image 2.2.2. Commandes de lecteur (APDU) à mettre en oeuvre Cette section décrit les commandes APDU que le lecteur doit mettre en oeuvre pour interagir avec les commandes PIN émanant de la carte. Si l'accès au lecteur passe par le middleware standard eID, une interface propriétaire peut être utilisée, pourvu que le fabricant fournisse la DLL qui met en oeuvre la bonne interface (voir section 3.2). En revanche, si l'accès au lecteur passe par une autre voie (p.ex. application sur mesure), les commandes proposées doivent être accessibles aux concepteurs d'applications.

Bien que la dernière solution puisse fonctionner sur le plan technique, elle est très limitée et pourrait se voir refusée par certaines institutions ou instances d'agrément officielles.

Les deux commandes décrites dans la section 2.2.1 doivent être appelées automatiquement par la demande d'un PIN (ou 2 PIN) sur le clavier PIN lorsque le paramètre Lc des commandes ci-dessus est égal à 0. Dans ce cas, le firmware du lecteur doit d'abord lire le PIN introduit sur le clavier PIN, puis remplacer les paramètres Lc et Data par les données correctes, générées à partir du PIN introduit. - Reader PIN Verify Pour la consultation du tableau, voir image - Reader PIN Change Pour la consultation du tableau, voir image Pour PIN Change, le nouveau PIN doit être introduit deux fois (avec comparaison) pour éviter les erreurs.

Le code renvoyé (octet d'état) doit être celui qui provient de la commande de carte, défini dans les normes 7816-4 et 7816-8, ou un des suivants : Pour la consultation du tableau, voir image 2.2.3. Format PIN Le PIN est une chaîne (string) de 8 octets au format suivant (par quartet), défini dans la section Global PIN du document "Global Platform - Card Specification - version 2.0.1' - April 7, 2000" : Pour la consultation du tableau, voir image 3. Compatibilité logicielle avec le middleware Cette section s'applique aux lecteurs reliés à un ordinateur et qui utiliseront la carte via l'interface Microsoft CryptoAPI ou l'interface PKCS#11. 3.1. Pilotes PC/SC Tous les lecteurs doivent s'accompagner d'un pilote conforme PC/SC version 1.1 pour le système d'exploitation cible. 3.2. Intégration au middleware En vue de l'intégration au middleware, le fournisseur du lecteur doit développer pour chaque système d'exploitation cible une Dynamic Linked Library (ou équivalent) mettant en oeuvre les fonctions suivantes : * SCR_Init () * SCR_VerifyPIN () * SCR_ChangePIN () Actuellement, seule l'application Belgian Identity (ci-après appelée ID) réside sur la carte. Dans la perspective de futures applications (revêtant la forme de fichiers de données ou de répertoires sur la carte), certaines fonctions possèdent un paramètre ApplicationID qui contient une chaîne identifiant l'application appelée à interagir avec un des PIN. Le but est que le lecteur affiche (voir 3.3) l'application qui demande un PIN. 3.2.1. SCR_Init ( ) Cette fonction est appelée tout de suite après le chargement de la DLL. Elle sert à initialiser la DLL et à vérifier si elle supporte le lecteur connecté.

Pour la consultation du tableau, voir image 3.2.2. SCR_VerifyPIN ( ) Cette fonction vérifie le PIN introduit par un utilisateur au clavier PIN du lecteur.

Pour la consultation du tableau, voir image 3.2.3. SCR_ChangePIN ( ) Cette fonction remplace le PIN introduit par un utilisateur au clavier PIN du lecteur par un nouveau, également introduit au clavier PIN. Pour la consultation du tableau, voir image 3.3. Afficheur Les paramètres Usage et ApplicationID sont des informations importantes pour le citoyen.

Usage indique pourquoi le citoyen est invité à introduire son PIN (pour s'authentifier, pour signer un document, etc.). Voici la signification de chaque possibilité : - 'A' : Authentification (log-on) - 'S' : Signature (non-répudiation) - 'E' : Encryption (cryptage) - 'P' : Modification fichier de préférences - 'M' : Maintenance (administration) ApplicationID est une chaîne identifiant l'application. Actuellement, seule l'application Belgian Identity (ID) réside sur la carte, mais d'autres pourraient s'y ajouter (ex. médecins (doctors) : Doc, avocats (lawyers) : LAW, etc.). C'est pourquoi cette information doit aussi être spécifiée.

Voici ce qui doit apparaître sur l'afficheur lors de l'appel des fonctions ci-dessus : 3.3.1. SCR_VerifyPIN ( ) Si l'espace d'affichage est limité, le minimum est : Pour la consultation du tableau, voir image Si la place le permet, cette information doit être traduite dans la langue spécifiée dans la fonction SCR_Init, p.ex. : Pour la consultation du tableau, voir image 3.3.2. SCR_ChangePIN( ) Pour la consultation du tableau, voir image Si l'espace d'affichage est limité, le minimum est : Si la place le permet, cette information doit être traduite dans la langue spécifiée dans la fonction SCR_Init, p.ex. : Pour la consultation du tableau, voir image

Art. 3.Spécifications du middleware Identité 1. Introduction 1.1. Matrice des environnements de développement L'eID Toolkit offrant plusieurs interfaces pour les mêmes fonctionnalités, l'on a décidé de faire un choix pour retenir la meilleure.

La matrice ci-dessous indique l'interface recommandée pour les environnements et langages de développement courants.

Pour la consultation du tableau, voir image Remarque importante : Pour accéder à la carte eID à partir d'une page web, il convient de ne pas utiliser ActiveX, parce que : 1. ActiveX ne fonctionne qu'avec Microsoft Internet Explorer 2.Le navigateur ne fait pas confiance à ActiveX, qui sera refusé par la plupart des installations et utilisateurs 3. L'applet Java contient une interface utilisateur qui sert à demander interactivement à l'utilisateur une confirmation d'accès. De plus, l'ActiveX actuel n'est pas scriptable : les scripts ne sont pas en mesure d'accéder à la mémoire allouée par le composant; un " wrapper " qui utilise un tampon créé par le script doit l'envelopper pour pouvoir le scripter. 2. Spécifications fonctionnelles 2.1. Gestion des versions et compatibilité Le Toolkit gère automatiquement toutes les différentes versions des cartes. Dans l'utilisation du Toolkit, il n'est pas nécessaire de se soucier de la façon interne dont la carte traite les données puisque celles-ci seront présentées de façon uniforme via l'API. Il existe une fonction de bas niveau pour connaître les différentes versions des composants de la carte, mais elle est réservée aux développeurs techniques qui doivent avoir accès à des propriétés très spécifiques de la carte. Une application normale n'a pas à s'inquiéter de la version de la carte. 2.2. Saisie du PIN Plusieurs fonctions acceptent une référence PIN en guise de paramètre entrant. Si une référence PIN est fournie et que la fonction rencontre un refus d'accès (" access denied ") en tentant d'accéder aux ressources de la carte, la fonction demandera automatiquement le PIN à l'utilisateur, puis réessaiera d'accéder aux ressources (après vérification réussie du PIN).

Le contrôle du PIN est effectué " juste à temps ", le PIN n'étant demandé que s'il est nécessaire. Par exemple, un PIN permanent peut avoir été introduit antérieurement et rester valable. Dans ce cas, il n'est pas redemandé.

Si le lecteur autorise la saisie sécurisée du PIN, le clavier PIN est utilisé. A défaut, l'on a recours au clavier du PC. 2.3. Remarque sur la longueur maximale des paramètres La longueur maximale des données renvoyées par les fonctions est indiquée dans le type du paramètre : * Octets * Caractères ASCII * Caractères UTF-8 Pour les développeurs C, toutes les chaînes ASCII et UTF-8 sont terminées par un vide (null). Attention : la longueur spécifiée ne comprend pas le '[0]' à la fin des chaînes terminées par un vide (null). 2.4. Applications multifilières La bibliothèque n'est pas à l'épreuve du multifilière. Il incombe à l'application appelante de ne pas utiliser la bibliothèque simultanément dans plusieurs filières parallèles.

Remarque : le CSP est à l'épreuve du multifilière, mais vous ne pouvez pas appeler le CSP dans une filière et le Toolkit dans une autre. 2.5. Organisation des API Les fonctions sont divisées en 4 catégories : * Fonctions d'initialisation et de terminaison, obligatoires pour initialiser et clôturer l'utilisation du Toolkit. * Fonctions d'identité, servant à obtenir les données d'identité (nom, adresse, etc.) de la carte. * Fonctions générales de haut niveau, servant à accéder à l'information de façon générique (fichiers, PIN), surtout dans les autres applications que l'identité. Il n'est pas nécessaire d'utiliser ces fonctions pour accéder aux données d'identité. * Fonctions de bas niveau, destinées aux développeurs qui ont besoin de fonctions très techniques, ou à des fins de débogage. Les développeurs normaux peuvent ignorer ces fonctions. 2.6. Fonctions d'initialisation et de terminaison 2.6.1. BEID_Init Cette fonction initialise le Toolkit.

Elle doit être appelée avant toute autre.

La politique de validation de certificat (via OCSP ou CRL) est donnée.

Elle est valable pour tous les appels de fonction suivants, jusqu'à l'appel de BEID_Exit ( ). Les drapeaux obligatoires OCSP et CRL s'excluent mutuellement. Quand OCSP et CRL sont utilisés tous les deux, OCSP est essayé en premier lieu; en cas de réussite, le processus s'arrête; en cas d'échec, CRL est utilisé.

Pour la consultation du tableau, voir image 2.6.2. BEID_Exit Cette fonction nettoie toutes les données utilisées par le Toolkit.

Elle doit être appelée à la fin du programme.

Pour la consultation du tableau, voir image 2.7. Fonctions d'identité Toutes les fonctions d'identité sont autosuffisantes. Autrement dit, il n'est pas nécessaire d'appeler une autre fonction en même temps qu'une fonction d'identité (sauf les fonctions d'initialisation et de terminaison).

Toutes les fonctions d'identité peuvent être appelées quel que soit l'état courant de la carte, et même si un DF (Data File) autre que l'identité est sélectionné, etc. 2.7.1. BEID_GetID Pour la consultation du tableau, voir image 2.7.4. Fonctions d'identité hors ligne Vous aurez parfois besoin d'archiver les données de la carte pour les valider immédiatement et en même temps les conserver comme preuve avec leur signature. Dans ce cas, vous devez recourir à deux fonctions : une pour lire les données brutes de la carte, l'autre pour transmettre ces données brutes aux fonctions d'identité en guise d'input. 2.7.4.1. BEID_GetRawData Cette fonction renvoie les données brutes issues de la carte (ID, Address, Picture, RRN certificate, CardData, TokenInfo, Challenge/Response from internal authenticate). Vous devez les enregistrer pour les réutiliser plus tard.

Remarque : les données brutes sont seulement lues, sans contrôle. Pour les valider, il faut appeler les fonctions d'identité normales.

Pour la consultation du tableau, voir image 2.7.4.2. BEID_SetRawData Cette fonction fait des données brutes l'input des fonctions d'identité suivantes. Cela permet de vérifier des données d'identité précédemment enregistrées. Notez que le recours à cette fonction n'exige pas la présence d'un lecteur.

Pour contrôler les données brutes, vous devez : * Appeler la fonction BEID_Init ( ) avec le paramètre lecteur égal à "VIRTUAL" * Appeler la fonction BEID_SetRawData ( ) Appeler les fonctions d'identité normales.

Pour la consultation du tableau, voir image 2.8. Fonctions générales de haut niveau Ces fonctions donnent accès (un accès intégré au Toolkit) à des fonctions générales destinées aux applications qui doivent effectuer d'autres opérations que la simple consultation des données d'identité. 2.8.1. BEID_BeginTransaction Cette fonction entame une transaction. Avant de commencer, elle attend la fin de toutes les autres transactions. Aucune autre application n'aura accès à la carte avant que BEID_EndTransaction soit appelée.

Cette fonction doit être appelée avant les autres fonctions d'exploitation de la carte, que l'on doit regrouper. Elle n'est pas nécessaire pour appeler une quelconque fonction individuelle ni les fonctions d'identité.

Normalement, une transaction sert à sélectionner une application avant l'accès à un fichier ou à un PIN. Pour la consultation du tableau, voir image 2.8.2. BEID_EndTransaction Cette fonction achève une transaction précédemment déclarée, pour permettre aux autres applications de reprendre les interactions avec la carte.

Elle doit être appelée à la fin de certaines fonctions d'exploitation de la carte.

Pour la consultation du tableau, voir image 2.8.3. BEID_SelectApplication Cette fonction sélectionne une application sur la carte.

Pour la consultation du tableau, voir image 2.8.4. BEID_ReadFile Cette fonction lit un fichier sur la carte. En présence d'une référence PIN, le PIN est demandé et corrigé au besoin (contrôle juste à temps).

Pour la consultation du tableau, voir image 2.8.5. BEID_WriteFile Cette fonction écrit un fichier sur la carte. En présence d'une référence PIN, le PIN est demandé et corrigé au besoin (contrôle juste à temps).

Pour la consultation du tableau, voir image 2.8.6. BEID_VerifyPIN Cette fonction vérifie un PIN. Pour la consultation du tableau, voir image 2.8.7. BEID_ChangePIN Cette fonction modifie un PIN. Pour la consultation du tableau, voir image 2.8.8. BEID_GetPINStatus Cette fonction obtient le statut du PIN. Le résultat peut être signé par la clé de base de la carte (clé " 0x81 " dans l'application DF actuelle).

Pour la consultation du tableau, voir image 2.9. Fonctions de bas niveau Remarque : les fonctions de bas niveau sont destinées aux applications qui doivent accéder à des fonctions techniques spécifiques, étrangères aux fonctions ordinaires, ou à des fins de débogage. Il n'est pas nécessaire d'utiliser ces fonctions de bas niveau dans les applications normales. 2.9.1. BEID_GetVersionInfo Cette fonction renvoie la version des différents composants (applet, système d'exploitation...). Le résultat peut être signé par la clé de base de la carte (clé " 0x81 " dans l'application DF actuelle).

Pour la consultation du tableau, voir image 2.9.2. BEID_SendAPDU Cette fonction envoie une commande APDU à la carte.

Attention : quand vous envoyez une commande APDU à la carte, le Toolkit n'est pas en mesure de vérifier la compatibilité entre les versions des applets (sauf pour la partie communication). L'appel risque de ne pas fonctionner avec une version suivante de l'applet.

En présence d'une référence PIN, le PIN est demandé et corrigé au besoin (contrôle juste à temps).

Remarque : la commande est d'abord tentée sans demander le PIN. En cas d'échec ("access denied"), le PIN est demandé et la commande réessayée.

Pour la consultation du tableau, voir image 2.9.3. BEID_FlushCache Cette fonction vide les données mises en cache en mémoire et sur le disque.

Pour la consultation du tableau, voir image 2.10. Identification PIN Lorsque vous communiquez un PIN au Toolkit, vous pouvez spécifier le PIN id. PKCS#15 ou la référence PIN du système d'exploitation.

De plus, si le PIN ne fait pas partie des PIN enregistrés dans le Toolkit, vous devez fournir une chaîne décrivant la raison pour laquelle le PIN est requis (p.ex. "Personal data modification"). Vous devez aussi fournir une courte chaîne (max. 3 caractères) à afficher sur l'écran du lecteur de carte (ex. : "MOD").

Un PIN se compose donc de 4 champs : - le type de PIN : PKCS#15 ou système d'exploitation (voir 2.10.1) - la référence OS du PIN ou : PKCS#15 id - le code d'utilisation (Voir 2.10.2) - la description longue (dans la langue de l'utilisateur) - la description courte (dans la langue de l'utilisateur) Pour améliorer la sécurité et standardiser l'affichage de l'information, la description donnée par l'application peut être écrasée par le Toolkit si celui-ci peut déterminer l'utilisation exacte.

En l'absence de PIN à contrôler, une valeur NULL doit être utilisée.

Remarque : quand un PIN est disponible dans la structure PKCS#15, il est plus sûr d'utiliser la référence PKCS#15 au lieu de celle de l'OS, celui-ci pouvant changer ultérieurement. 2.10.1. Types de PIN Pour la consultation du tableau, voir image 2.12. Statut des fonctions Chaque fonction renvoie un code général spécifiant le type d'erreur.

Dans la plupart des cas, seul ce code d'erreur sera utilisé.

Cependant, pour obtenir des informations détaillées sur les raisons techniques, les codes d'état suivants sont également prévus : * Code d'erreur système (long) * Code d'erreur PC/SC (long) * Mot d'état (double octet) de la carte à puce 2.12.1. Codes d'erreur généraux Pour la consultation du tableau, voir image 2.13. Contrôle de signature et validation de certificat Toute fonction renvoyant des données signées contrôle toujours la signature ainsi que l'intégrité de l'ensemble de la chaîne du certificat.

La fonction renvoie : * l'état du contrôle de signature (long) * l'état global de la validation de certificat (long) * pour chaque certificat : - le certificat - l'étiquette du certificat - l'état du contrôle individuel - l'état de la validation individuelle - la politique individuelle appliquée : OCSP ou CRL. Pour la consultation du tableau, voir image Voici un schéma décrivant le déroulement du controle de signature : Pour la consultation du tableau, voir image 2.13.1. Contrôle de signature Pour la consultation du tableau, voir image 3. Interfaces de programmation 3.1. API C Tous les tampons de sortie doivent être alloués par l'application appelante.

Toutes les fonctions utilisent les conventions d'appel de C et non de Pascal.

Struct packing est fixé à 8. 3.1.1. Structures Pour la consultation du tableau, voir image 3.1.2. Functions Pour la consultation du tableau, voir image 3.2. API Java Pour des raisons de compatibilité avec le code natif qui définit l'accès à la carte, l'implémentation Java ne fait pas de gestion d'exceptions : toutes les erreurs sont renvoyées sous forme de codes d'erreur (voir 2.12) Pour la consultation du tableau, voir image 3.2.1. Data Classes Pour la consultation du tableau, voir image 3.2.2. Main Class Pour la consultation du tableau, voir image 3.2.3. Applet Classe Pour la consultation du tableau, voir image Paramètres applet : Pour la consultation du tableau, voir image Snippet HTML : Pour la consultation du tableau, voir image 3.3.2. Fonctions Les définitions de fonction sont au format IDL. Pour la consultation du tableau, voir image 4. Installation 4.1. Package d'installation Le package d'installation (3) contient les fichiers suivants : Pour la consultation du tableau, voir image 4.2. Runtime Le runtime est nécessaire pour tous les environnements.

Il doit être installé suivant les instructions du document "Belgian eID Run-time Users guide". 4.3. Bibliothèque C L'application doit inclure le fichier include du Toolkit "eidlib.h".

L'application doit être linkée avec la bibliothèque partagée "libeid.so" ou "eidlib.dll" si l'éditeur de liens supporte un lien direct avec une bibliothèque partagée (comme GCC) ou avec les points d'entrée de la bibliothèque "eidlib.lib" ou "libeid.a" dans les autres cas (comme Visual C++). 4.4. Java Le Toolkit est compatible avec toutes les Java Virtual Machines de Sun à partir de 1.2.

Art. 3bis.Spécifications du middleware Crypto 1. But Le but de ce document est à la fois d'esquisser l'architecture du middleware et de donner au programmeur d'applications les informations nécessaires pour développer des programmes utilisant la carte d'identité électronique belge.Ce document est limité aux informations concernant le middleware "carte belge", destinées aux programmeurs. 2. Architecture 2.1. Interfaces Comme expliqué à la section précédente, deux interfaces sont mises en oeuvre dans le middleware : l'une peut être appelée directement (l'interface PKCS#11), l'autre indirectement (CSP). 2.1.1 L'interface Crypto API Microsoft(r) Cryptographic API 2.0 (CryptoAPI) permet aux développeurs d'applications d'ajouter l'authentification, le codage et le cryptage à leurs applications Win32(r). Les développeurs d'applications peuvent utiliser les fonctions de CryptoAPI sans rien savoir de la mise en oeuvre sous-jacente, de même que l'on peut exploiter une bibliothèque graphique sans connaître les détails de la configuration du matériel graphique.

La partie CSP du middleware établit un lien entre l'interface abstraite CryptoAPI et l'interface PKCS#11 sous-jacente. Le développeur n'appellera jamais les fonctions de CSP directement, mais toujours via CryptoAPI. Actuellement, la carte d'identité belge ne supporte que les opérations de signature numérique. Plus tard, quand l'Etat belge décidera que l'utilisateur de la carte d'identité électronique peut stocker des clés sur la carte qui supporte le cryptage, le CSP sera étendu à cette fonctionnalité supplémentaire. De plus, la carte d'identité belge contient deux paires de clés pouvant servir à la signature numérique (authentification et non-répudiation).

Bien que le CSP ne supporte que la signature numérique, le programme est enregistré comme CSP du type PROV_RSA_FULL, afin de pouvoir être utilisé dans les applications standard Microsoft(r). 2.1.1.1. CSP - Architecture de haut niveau L'API (application programming interface) Crypto de Microsoft est une interface abstraite avec les opérations cryptographiques.

L'utilisateur de l'API n'est pas tenu de connaître le fonctionnement interne de la cryptographie mise en oeuvre au niveau inférieur (celui de la carte). L'interface CryptoAPI est indépendante de la mise en oeuvre cryptographique sous-jacente. La carte d'identité électronique belge est une carte à puce (" smartcard "). Dans d'autres applications, cependant, il peut s'agir d'une solution logicielle.

Sous l'interface CryptoAPI, une interface différente est spécifiée pour les concepteurs de systèmes de sécurité. Elle s'appelle CSPI (Cryptgraphic Service Provider Interface). L'interface CSPI isole le dispositif cryptographique sous-jacent de l'interface CryptoAPI. Le nombre de mises en oeuvre CSPI sur un même système n'est pas limité.

Chaque mise en oeuvre CSPI est (normalement) propre à un type de matériel sous-jacent. Le schéma ci-dessous donne une vue d'ensemble de cette architecture : Pour la consultation du tableau, voir image Normalement, chaque CSP s'oriente lui-même vers un type particulier de carte à puce. La plupart du temps, en effet, le CSP est mis à disposition par le fournisseur de la carte à puce lui-même. Le middleware de la carte d'identité belge adopte une approche différente. Pour donner à l'émetteur de la carte d'identité (en l'occurrence l'Etat) un maximum de flexibilité dans le choix du type de carte à puce, le CSP ne met pas en oeuvre l'interface propriétaire de la carte à puce directement, mais passe par une interface PKCS#11 (pour en savoir plus sur l'interface PKCS#11, voyez la section 2.1.2).

Voici un schéma des blocs concernés : Pour la consultation du tableau, voir image Si, à un stade ultérieur, le gouvernement décide de changer de type matériel de carte à puce, la mise en oeuvre du CSP pourra rester en place (pourvu que la nouvelle carte à puce soit compatible avec la mise en oeuvre existante). 2.1.1.2. CSP - Architecture de bas niveau A un niveau inférieur, la mise en oeuvre du CSP opère une traduction entre l'interface CSPI standard et l'interface PKCS#11. La figure ci-dessous esquisse cette architecture : Pour la consultation du tableau, voir image A l'échelle interne, le CSP met en oeuvre une partie de l'interface PKCS#11 pour effectuer les opérations cryptographiques sur la clé publique. Ces opérations se limitent actuellement à la signature numérique (authentification et non-répudiation). Pour les opérations cryptographiques sur la clé privée (p.ex. le calcul du hachage), un CSP de base est utilisé. Normalement, l'on se sert pour cela du PROV_RSA_FULL CSP par défaut, en général celui de Microsoft.

Le CSP tient un fichier de configuration qui contient les paramètres indépendants de la carte d'identité électronique. Le nom (étiquette/label) des différentes clés, par exemple, est stocké avec une référence à la "key ID" correspondante. Ces informations sont communes à toutes les cartes d'identité électroniques belges. Il ne faut donc pas un fichier de configuration par carte utilisée sur un système donné.

Les certificats d'utilisateurs sont stockés par le système d'exploitation, dans un store "MY". Un nom convivial est défini pour chaque certificat (clé d'authentification et clé de signature). Dans l'environnement Microsoft, les conteneurs de certificat servent à établir un lien entre un certificat et la clé privée correspondante.

Le nom de ces conteneurs est déduit de l'étiquette de la clé (authentification ou signature) et du numéro de série de la carte, afin de permettre l'utilisation de plusieurs cartes d'identité sur la même machine. 2.1.2. L'interface PKCS#11 L'interface PKCS#11 (v2.11) est utilisée par les applications non-Microsoft, par exemple Netscape. Les applications sur mesure peuvent, elles aussi, faire usage de cette interface au lieu de CryptoAPI. L'interface PKCS#11 est parfois appelée Cryptoki.

Le site web de RSA Laboratories (http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/) en donne une description détaillée.

Conformément au souci d'ouverture affiché par le gouvernement, nous avons décidé d'utiliser la mise en oeuvre libre (" open source ") PKCS#11 de opensc (http ://www.opensc.org). Cette mise en oeuvre ne se limite pas à l'interface PKCS#11 : elle supporte aussi la structure de carte PKCS#15. 2.1.2.1. PKCS#11 - Architecture de haut niveau L'interface cryptoki est une interface abstraite avec la carte à puce, pour les applications qui ont besoin de la fonctionnalité cryptographique. Elle est normalement utilisée par les applications non-Microsoft telles que Netscape et Mozilla. Les fournisseurs de solutions indépendants peuvent aussi faire appel à cette interface pour mettre en oeuvre des fonctionnalités cryptographiques dans des applications tierces.

Voici un schéma qui illustre les modules PKCS#11 : Pour la consultation du tableau, voir image Comme indiqué dans la figure ci-dessus, la couche supérieure met en oeuvre l'interface PKCS#11 standard. C'est cette interface qui est exposée aux applications. Sous l'interface, le lien est établi avec la structure de carte dans PKCS#15, et les commandes nécessaires (APDU) sont envoyées via les fonctions d'interface standard PC/SC. Dans la couche OpenSC, un pilote de carte spécifique est mis en oeuvre pour utiliser la carte d'identité électronique belge. Si une carte différente est adoptée plus tard, ce pilote devra être remplacé. 3. Guide de programmation 3.1. Introduction Le middleware de la carte d'identité belge est un logiciel qui trouve place entre l'application mettant en oeuvre les fonctions de sécurité (signature numérique) et le dispositif chargé des opérations cryptographiques proprement dites (la carte à puce).

Le middleware lui-même se compose de deux interfaces indépendantes (voir figure ci-dessous). Mais en dépit de cette indépendance, chacune fait appel à l'autre. Pour les applications standard Microsoft(r) (Office, Outlook...), un Cryptographic Service Provider (CSP) est créé pour effectuer les opérations cryptographiques à partir de la carte à puce. Une application ne fera jamais appel à cette mise en oeuvre directement, mais via une interface standard appelée Crypto API. La mise en oeuvre CSP fait usage de la deuxième interface, PKCS#11, qui est utilisée par les applications standard non-Microsoft.

Quand une nouvelle application est créée, il appartient au développeur de décider laquelle des deux interfaces servira à mettre les fonctions cryptographiques à la disposition de l'utilisateur.

Pour la consultation du tableau, voir image Ce document explique à la fois les interfaces de programmation et la façon dont le concepteur d'applications peut s'en servir. 3.2. L'interface Crypto API Microsoft(r) Cryptographic API 2.0 (CryptoAPI) permet aux développeurs d'applications d'ajouter l'authentification, le codage et le cryptage à leurs applications Win32(r). Les développeurs d'applications peuvent utiliser les fonctions de CryptoAPI sans rien savoir de la mise en oeuvre sous-jacente, de même que l'on peut exploiter une bibliothèque graphique sans connaître les détails de la configuration du matériel graphique.

La partie CSP du middleware établit un lien entre l'interface abstraite CryptoAPI et l'interface PKCS#11 sous-jacente. Le développeur n'appellera jamais les fonctions de CSP directement, mais via CryptoAPI. Les sections ci-dessous décrivent les appels d'API que CryptoAPI transfère au CSP pour la suite du traitement. Elles ne contiennent pas d'information détaillée sur le fonctionnement de chaque appel d'API. Pour trouver ce type d'information, consultez le Microsoft Developer Network.

Actuellement, la carte d'identité belge ne supporte que les opérations de signature numérique. Les fonctions non liées aux opérations cryptographiques ne sont pas mises en oeuvre. Plus tard, quand l'Etat belge décidera que l'utilisateur de la carte d'identité électronique peut stocker des clés sur la carte qui supporte le cryptage, le CSP sera étendu à cette fonctionnalité supplémentaire. De plus, la carte d'identité belge contient deux paires de clés pouvant servir à la signature numérique (authentification et non-répudiation). Pour ces raisons, certains paramètres passés aux fonctions Crypto API sont sans signification. Par exemple, dans l'appel CryptGetUserKey, un paramètre dwKeySpec est passé. Ce paramètre définit le type de clé à obtenir : une clé AT_KEYEXCHANGE ou une clé AT_SIGNATURE. Cependant, dans le cas du CSP Belgian Identity Card, ce paramètre ne suffit pas pour déterminer le type de signature à charger. Dans cette situation, le conteneur qui abrite le certificat correct doit être passé à CryptAcquireContext. Un appel à CryptGetUserKey est ensuite effectué avec succès.

Bien que le CSP ne supporte que la signature numérique, le programme est enregistré comme CSP du type PROV_RSA_FULL, afin de pouvoir être utilisé dans les applications standard Microsoft(r). Un appel aux fonctions Crypto API qui ne sont pas mises en oeuvre dans le contexte de la signature numérique renvoie un code d'erreur indiquant que la fonction API n'est pas mise en oeuvre.

Ce document est valable pour la version 1.20 du CSP. 3.2.1.CryptAcquireContext Pour la consultation du tableau, voir image Le paramètre pszContainer contient le nom du conteneur abritant une clé spécifique sur la carte d'identité. Le nom des conteneurs de la carte d'identité peut être obtenu via un appel à CryptGetProvParam.

Le paramètre dwFlags peut recevoir les valeurs suivantes (d'après MSDN) : 0 (équivalent à CRYPT_SCKEYSET) CRYPT_VERIFYCONTEXT CRYPT_NEWKEYSET CRYPT_MACHINE_KEYSET CRYPT_DELETEKEYSET Le matériel des clés de la carte d'identité belge étant stocké sur une carte à puce et l'utilisateur n'étant pas autorisé à créer de nouveaux jeux de clés sur la carte, les valeurs CRYPT_NEWKEYSET, CRYPT_MACHINE_KEYSET et CRYPT_DELETEKEYSET ne sont pas supportées.

L'utilisation de ces valeurs génère une erreur NTE_BAD_FLAGS. Une valeur supplémentaire est définie pour ce paramètre : CRYPT_SCKEYSET. Par cette valeur, le développeur définit l'acquisition d'un contexte pour la clé suivant le contenu du paramètre pszContainer.

Pour les opérations de hachage seulement, un CSP de base est utilisé.

Si, pour une raison quelconque, le CSP de base échoue, le code d'erreur suivant est généré par SetLastError() : ERR_CANNOT_LOAD_BASE_CSP (0x1000) 3.2.2. CryptReleaseContext Pour la consultation du tableau, voir image Cette API est mise en oeuvre suivant les prescriptions de MSDN. 3.2.3. CryptGenerateKey Pour la consultation du tableau, voir image Le matériel des clés étant préinstallé sur la carte d'identité belge et l'utilisateur n'étant pas autorisé à créer des paires de clés supplémentaires, cet appel d'API n'est pas mis en oeuvre. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError (). 3.2.4. CryptDeriveKey Pour la consultation du tableau, voir image Le matériel des clés étant préinstallé sur la carte d'identité belge et l'utilisateur n'étant pas autorisé à créer des paires de clés supplémentaires, cet appel d'API n'est pas mis en oeuvre. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError (). 3.2.5. CryptDestroyKey Pour la consultation du tableau, voir image Le matériel des clés étant préinstallé sur la carte d'identité belge et l'utilisateur n'étant pas autorisé à créer des paires de clés supplémentaires, cet appel d'API n'est pas mis en oeuvre. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError (). 3.2.6.CryptSetKeyParam Pour la consultation du tableau, voir image Le matériel des clés étant préinstallé sur la carte d'identité belge et l'utilisateur n'étant pas autorisé à créer des paires de clés supplémentaires, cet appel d'API n'est pas mis en oeuvre. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError (). 3.2.7.CryptGetKeyParam Pour la consultation du tableau, voir image Le matériel des clés étant préinstallé sur la carte d'identité belge et l'utilisateur n'étant pas autorisé à créer des paires de clés supplémentaires, cet appel d'API n'est pas mis en oeuvre. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError (). 3.2.8.CryptSetProvParam Pour la consultation du tableau, voir image D'après la documentation MSDN, le paramètre dwParam peut recevoir les valeurs suivantes : PP_CLIENT_HWND PP_KEYSET_SEC_DESCR Ce dernier est sans objet, vu que le matériel des clés de la carte d'identité belge est stocké dans la carte à puce plutôt que dans le registre. Il est donc ignoré. 3.2.9.CryptGetProvParam Pour la consultation du tableau, voir image Cet appel d'API est mis en oeuvre conformément à la documentation MSDN, à l'exception du paramètre PP_KEYSET_SEC_DESCR, qui est ignoré.

Pour le paramètre PP_IMPTYPE, la valeur renvoyée est CRYPT_IMPL_MIXED parce que l'opération de signature est assumée par le matériel (la carte à puce), tandis que le hachage est confié au service cryptographique de base. 3.2.10. CryptSetHashParam Pour la consultation du tableau, voir image Cet appel d'API est mis en oeuvre conformément à la documentation MSDN. Le paramètre dwParam = HP_HASHVAL est mis en oeuvre mais doit être utilisé avec prudence. Il a pour but de permettre aux applications de signer les valeurs de hachage sans devoir accéder aux données de base.

L'application (et a fortiori l'utilisateur) n'ayant aucune idée de ce qui est signé, l'opération présente des risques intrinsèques. 3.2.11. CryptGetHashParam Pour la consultation du tableau, voir image Cet appel d'API est mis en oeuvre conformément à la documentation MSDN. 3.2.12.CryptExportKey Pour la consultation du tableau, voir image Cette fonction peut servir à exporter la clé publique associée au paramètre hKey. Un handle vers une clé publique peut être obtenu par un appel à CryptGetUserKey. Les clés privées étant stockées sur une carte à puce et l'exportation des clés privées n'étant pas permise, le seul dwBlobType permis est PUBLICKEYBLOB. Seules les clés publiques peuvent être exportées. Le paramètre hExpKey n'est donc pas utilisé et doit contenir NULL. La clé publique est renvoyée dans le paramètre pbData. Pour obtenir la longueur des données renvoyées, le paramètre pbData peut être mis à NULL. La longueur des données à renvoyer est alors placée dans pcbDataLen. Si le tampon passé à la fonction est trop petit, l'erreur ERROR_MORE_DATA est renvoyée et la longueur correcte du tampon est placée dans le paramètre pcbDataLen. 3.2.13. CryptImportKey Pour la consultation du tableau, voir image Le matériel des clés étant préinstallé sur la carte d'identité belge et l'utilisateur n'étant pas autorisé à créer des paires de clés supplémentaires, cet appel d'API n'est pas mis en oeuvre. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError (). 3.2.14.CryptEncrypt Pour la consultation du tableau, voir image Actuellement, l'utilisation des clés définie par le gouvernement belge ne supporte pas le cryptage. Cet appel d'API n'est donc pas mis en oeuvre. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError ().

S'il devient possible ultérieurement d'ajouter à la carte d'identité électronique des clés supportant le cryptage, cette fonction sera mise en oeuvre. 3.2.15.CryptDecrypt Pour la consultation du tableau, voir image Actuellement, l'utilisation des clés définie par le gouvernement belge ne supporte pas le cryptage. Cet appel d'API n'est donc pas mis en oeuvre. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError ().

S'il devient possible ultérieurement d'ajouter à la carte d'identité électronique des clés supportant le cryptage, cette fonction sera mise en oeuvre. 3.2.16. CryptCreateHash Pour la consultation du tableau, voir image Cet appel d'API est mis en oeuvre conformément à la documentation MSDN. Une erreur supplémentaire peut être renvoyée via SetLastError () : ERR_INVALID_PROVIDER_HANDLE (0x1001) Cette erreur signifie que le handle spécifié par hProv n'a pas été trouvé (c.-à-d. qu'il n'a pas été créé avec CryptAcquireContext ()).

Le traitement de cet appel est délégué à un CSP de base. 3.2.17. CryptHashData Pour la consultation du tableau, voir image Cet appel d'API est mis en oeuvre conformément à la documentation MSDN. Une valeur (autre que 0) peut être spécifiée dans le paramètre dwFlags : CRYPT_USERDATA. Selon le CSP de base retenu, l'appel peut être mis en oeuvre ou non. Dans Microsoft Base CSP, par exemple, il ne l'est pas.

Le traitement de cet appel est délégué à un CSP de base. 3.2.18.CryptHashSessionKey Pour la consultation du tableau, voir image Certains appels sous-jacents nécessaires à l'utilisation de cette fonction n'étant pas mis en oeuvre actuellement par ce CSP, l'appel n'est pas disponible. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError (). 3.2.19.CryptSignHash Pour la consultation du tableau, voir image Cet appel d'API est mis en oeuvre conformément à la documentation MSDN. L'appel de la fonction déclenche une tentative de connexion et de log-on sur la carte d'identité belge (carte à puce). Si une de ces opérations échoue, l'erreur suivante peut être renvoyée via SetLastError () : ERR_CANNOT_LOGON_TO_TOKEN (0x1004) Pour signer les données de hachage, il faut lire certaines informations sur la carte (p.ex. longueur de la clé). Si une erreur se produit durant l'opération, le code d'erreur suivant est généré via SetLastError () : ERR_CANNOT_GET_TOKEN_SLOT_INFO (0x1003) Le mécanisme utilisé pour générer les signatures numériques s'appelle CKM_RSA_PKCS. Pour plus de détails à ce sujet, voyez la documentation PKCS#11.

Actuellement, voici les algorithmes de hachage qui peuvent servir à signer les données : MD2, MD4, MD5, SHA-1 et SSL3 SHAMD5. Bien que les algorithmes de hachage MDx soient encore disponibles pour la rétrocompatibilité, il est recommandé d'utiliser SHA-1 dans les nouvelles applications. 3.2.20.CryptDestroyHash Pour la consultation du tableau, voir image Cet appel d'API est mis en oeuvre conformément à la documentation MSDN. 3.2.21.CryptVerifySignature Pour la consultation du tableau, voir image Cette fonction est mise en oeuvre pour des raisons de facilité.

L'appel est délégué au CSP de base. 3.2.22.CryptGenRandom Pour la consultation du tableau, voir image Cet appel d'API est mis en oeuvre conformément à la documentation MSDN. Les données introduites via pbBuffer serviront à ensemencer la génération aléatoire. 3.2.23.CryptGetUserKey Pour la consultation du tableau, voir image Cet appel renvoie un handle vers une clé publique du conteneur de clés défini dans CryptAcquireContext. Il ne suffit pas de spécifier AT_SIGNATURE pour le paramètre dwKeySpec, parce qu'avec cette information, le CSP ne peut déterminer quelle clé de signature il faut renvoyer. La clé à charger doit donc d'abord être spécifiée dans CryptAcquireContext. 3.2.24.CryptDuplicateHash Pour la consultation du tableau, voir image Cet appel d'API est mis en oeuvre conformément à la documentation MSDN. 3.2.25.CryptDuplicateKey Pour la consultation du tableau, voir image Vu que le matériel des clés est stocké sur une carte à puce et ne peut en être extrait, cette fonction est sans objet. Cet appel d'API n'est donc pas mis en oeuvre. L'appel de la fonction génère l'erreur E_NOTIMPL dans SetLastError (). 3.3. L'interface PKCS#11 L'interface PKCS#11 (v2.11) est utilisée par les applications non-Microsoft, par exemple Netscape. Les applications sur mesure peuvent, elles aussi, faire usage de cette interface au lieu de CryptoAPI. L'interface PKCS#11 est parfois appelée Cryptoki.

Sa description détaillée se trouve sur le site de RSA Laboratories (http ://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/). 3.3.1. Appels d'API mis en oeuvre 3.3.1.1. Fonctions générales C_Initialize, C_Finalize C_GetInfo C_GetFunctionList 3.3.1.2. Fonctions de gestion de slot et de token C_GetSlotList C_GetSlotInfo C_GetTokenInfo C_GetMechanismList C_GetMechanismInfo C_WaitForSlotEvent C_SetPin 3.3.1.3. Fonctions de gestion de session C_OpenSession C_CloseSession C_CloseAllSessions C_GetSessionInfo C_Login C_Logout 3.3.1.4. Fonctions de gestion d'objets C_FindObjectsInit C_FindObjects C_FindObjectsFinal C_GetAttributeValue 3.3.1.5. Fonctions de signature C_SignInit C_Sign C_SignUpdate C_SignFinal 3.3.1.6. Fonctions de digest C_DigestInit C_Digest C_DigestUpdate C_DigestFinal 3.3.1.7. Fonctions de génération aléatoire (à confirmer bientôt) C_SeedRandom C_GenerateRandom 3.3.2. Mécanismes de signature supportés Pour les signatures : - CKM_RSA_X_509 - CKM_RSA_PKCS : hachages ASN.1-wrapped et purs (MD5, SHA1, SHA1+MD5, RIPEMD160 - si 20 octets sont donnés, le hachage est censé être du type SHA-1) - CKM_RIPEMD160_RSA_PKCS, CKM_SHA1_RSA_PKCS, CKM_MD5_RSA_PKCS - S'ils sont supportés par la carte d'identité électronique, les mécanismes de signature suivants seront aussi supportés par le middleware : CKM_RSA_PKCS_PSS, CKM_SHA1_RSA_PKCS_PSS Pour les digests : CKM_SHA_1, CKM_RIPEMD160, CKM_MD5 3.3.3. Informations de slot et de token Il y aura un slot/token virtuel pour chaque PIN (dans le cas de la carte d'identité électronique belge, cela veut donc dire 1 slot/token).

Les clés publiques, les clés privées et les certificats correspondants posséderont le même attribut d'objet CKA_ID. 3.3.4. Comportement en cas de lecteur à clavier PIN Dans ce cas, CK_TOKEN_INFO aura le drapeau CKF_PROTECTED_AUTHENTICATION_PATH levé, et l'application renverra un NULL PIN avec C_Login. A l'appel de C_Login, la bibliothèque PKCS#11 présentera à l'utilisateur un dialogue l'invitant à introduire son PIN au clavier PIN, en vue de la signature ou de l'authentification. 3.3.5. Comportement en cas de clé de non-répudiation Si une signature est demandée avec cette clé, la bibliothèque PKCS#11 elle-même affichera une interface graphique invitant l'utilisateur à introduire son PIN ou à le taper au clavier du lecteur. 4. Références [ISO/IEC 7816-1] Identification Cards - Integrated Circuit Cards with Contacts Part1 : Physical Characteristics [ISO/IEC 7816-2] Identification Cards - Integrated Circuit Cards with Contacts Part2 : Dimensions and Location of Contacts [ISO/IEC 7816-3] Identification Cards - Integrated Circuit Cards with Contacts Part3 : Electronic Signals and Transmission Protocols [ISO/IEC 7816-4] Identification Cards - Integrated Circuit Cards with Contacts Part4 : Inter-industry Commands for Interchange [ISO/IEC 7816-5] Identification Cards - Integrated Circuit Cards with Contacts Part5 : Numbering System for Application Identifiers [CEN/CWA 14170] Electronic Signature - Security Requirements Secure Signature Creation Applications [CEN/CWA 14171] Electronic Signature - Security Requirements Secure Signature Verification Applications [RSAS/PKCS#11] Public Key Cryptographic Standards Cryptographic Token Interface Standard [RSAS/PKCS#15] Public Key Cryptographic Standards Cryptographic Token Information Standard [EID/READERS 2.7.3] Belgian Electronic Identity Card Readers Technical Compatibility v 2.7.3 [EID/CRYPTO 1.4.0] Belgian Electronic Identity Card Security & Crypto Middleware v 1.4.0 [EID/IDENTITY 1.0.0] Belgian Electronic Identity Card Data & Identity Middleware v 1.0.0 [EID/CARD 2.0.0] Belgian Electronic Identity Card Card and Applet Specifications v 2.0.0 [EN45014] Conformity Assessment Generic Criteria (CE) [EN60950] Information Processing Equipment Security [EN50081] EMC (Electro-Magnetic Compatibility) Emission Generic Criteria [EN50081] EMC (Electro-Magnetic Compatibility) Immunity Generic Criteria [EN55022] REC (Radio-Electric Compatibility) Perturbations Generic Criteria Vu pour être annexé à Notre arrête du 7 décembre 2006 fixant les specifications et la procedure d'enregistrement des appareils de lecture pour la carte d'identité éléctronique et modifiant l'arrêté royal du 13 février 1998 relatif aux specifications des appareils de lecture de la carte d'identité sociale.

ALBERT Par le Roi : Le Ministre de l'Intérieur, P. DEWAEL Le Ministre de l'Economie M. VERWILGHEN Le Ministre des Affaires sociales, R. DEMOTTE La Ministre des Classes moyennes et de l'Agriculture, Mme S. LARUELLE Le Ministre de l'Emploi, P. VANVELTHOVEN

Annexe II FORMULAIRE TYPE POUR L'ENREGISTREMENT D'UN APPAREIL DE LECTURE DE LA CARTE D'IDENTITE ELECTRONIQUE BELGE (eID) Mode d'emploi Ce document comprend l'inventaire des différents documents ainsi que le relevé des données à compléter et à transmettre à l'autorité en vue de l'obtention d'un numéro d'enregistrement pour un appareil de lecture de la carte d'identité électronique belge. Tous les points décrits et toutes les informations demandées doivent faire l'objet d'une réponse aussi complète que possible.

Un modèle du formulaire d'enregistrement peut être téléchargé à partir de l'URL suivant : http://eid.belgium.be Le formulaire d'enregistrement dûment complété, y compris toutes les annexes requises, doit être transmis : a) par la poste à l'adresse suivante : Service public fédéral Technologie de l'Information et de la Communication rue Marie Thérèse 1-3 1000 Bruxelles b) par e-mail : enregistrement@fedict.be Pour la consultation du tableau, voir image Vu pour être annexé à Notre arrête du 7 décembre 2006 fixant les specifications et la procedure d'enregistrement des appareils de lecture pour la carte d'identité éléctronique et modifiant l'arrêté royal du 13 février 1998 relatif aux specifications des appareils de lecture de la carte d'identité sociale.

ALBERT Par le Roi : Le Ministre de l'Intérieur, P. DEWAEL Le Ministre de l'Economie, M. VERWILGHEN Le Ministre des Affaires sociales, R. DEMOTTE La Ministre des Classes moyennes et de l'Agriculture, Mme S. LARUELLE Le Ministre de l'Emploi, P.VANVELTHOVEN _______ Nota's (1) Certaines cartes ne contiennent que les deux premiers prénoms ensemble.Dans ce cas, les deux prénoms sont renvoyés dans ce champ et le champ " 2ème prénom " reste vide. (2) Certaines cartes contiennent aussi le numéro et le numéro de boîte dans le même champ.Dans ce cas, tout est renvoyé dans ce champ et les autres champs restent vides. (3) Le package peut se trouver dans un fichier archive (ZIP, TAR ou GZ). ANNEXE III Modèle de label et conditions d'utilisation. 1. Le label visé à l'article 8 de cet l'arrêté royal : - est strictement et limitativement lié à un appareil de lecture qui, pour ce qui est de la carte d'identité électronique, a satisfait et satisfait aux normes et exigences techniques et fonctionnelles imposées; - témoigne, sur l'initiative du fournisseur, de la conformité de l'appareil de lecture sur lequel il est apposé aux dites normes et exigences; - est de nature à éliminer dans le chef de l'utilisateur le doute quant à la compatibilité des appareils de lecture avec la carte d'identité électronique; - vise à soutenir la démarche volontariste des fournisseurs se faisant enregistrer. 2. Le label est figuré par le logo ici reproduit : version en couleurs : version monochrome : Pour la consultation du tableau, voir image 2.1. La version en couleurs est obligatoirement composée, selon les indications susmentionnées, des couleurs spécifiques suivantes : - (1) Pantone: Process Black CMYK : C 0, M 0, Y 0, K 100 RGB : R 0, G 0, B 0 - (2) Pantone : 115 CMYK : C 0, M 8,5, Y 79, K 0 RGB : R 255, G 233, B 0 - (3) Pantone : 032 CMYK : C 0, M 91, Y 87, K 0 RGB : R 246, G 0, B 0 - (4) Pantone : 338 CMYK : C 47, M 0, Y 32, K 0 RGB : R 135, G 207, B 163 - (5) Pantone : 343 CMYK : C 98, M 0, Y 72, K 61 RGB : R 2, G 56, B 37 - (6) Blanc CMYK : C 0, M 0, Y 0, K 0 RGB : R 255, G 255, B 255 La version en couleurs doit être préférée à la version monochrome; elle doit être reproduite sur un fond blanc. 2.2. La version monochrome, lorsque la version en couleur n'est pas possible, est obligatoirement composée de noir et de blanc, avec une trame à 35% du noir pour la partie grisée.

Elle doit être reproduite sur un fond blanc. 3. Le label doit être reproduit, selon le modèle supra, tel quel, sans altération de la forme, des couleurs, de la lisibilité et des proportions.4. Le logo figurant le label est entouré d'une zone d'exclusion, dans laquelle ne peut figurer aucun élément quelle qu'en soit la nature;sa reproduction respecte cette zone telle qu'ici définie : Pour la consultation du tableau, voir image Si le logo, en couleurs ou monochrome, devait être reproduit sur un support d'une couleur autre que le blanc, il conviendrait alors que la zone d'exclusion soit blanche.

Il peut, par exemple, s'agir d'un autocollant où le logo est reproduit sur un fond blanc épousant la zone d'exclusion. 5. Le label est placé sur l'appareil de lecture considéré de manière visible et de préférence sur sa face avant. Pour garantir sa visibilité, le label (logo hors zone d'exclusion) doit avoir une dimension proportionnée à l'appareil considéré, avec une valeur de Y (voir schéma) de minimum 10mm.

Le label ne peut pas dominer visuellement le logo ou la dénomination du fournisseur ou de l'appareil de lecture considéré. 6. Le label peut également être reproduit, aux même conditions que celles ici précisées, sur la publicité, l'emballage et la documentation de l'appareil de lecture considéré et ce pour autant que ces éléments présentent le label en le rattachant, directement et de manière explicite, audit appareil et à lui seul. A cet égard, un fournisseur ne peut pas se prévaloir de l'obtention du label indépendamment de l'appareil auquel il a été attribué.

Lorsque l'appareil de lecture considéré est proposé à la vente sous un emballage, ou un conditionnement, qui ne permet pas de voir le label apposé sur ledit appareil, le label doit être reproduit sur l'emballage ou le conditionnement. 7. Le label et les éléments nécessaires à sa reproduction peuvent être obtenus par téléchargement électronique, à l'adresse www.fedict.be.

Vu pour être annexé à Notre arrête du 7 décembre 2006 fixant les specifications et la procedure d'enregistrement des appareils de lecture pour la carte d'identité éléctronique et modifiant l'arrêté royal du 13 février 1998 relatif aux specifications des appareils de lecture de la carte d'identité sociale.

ALBERT Par le Roi : Le Ministre de l'Intérieur, P. DEWAEL Le Ministre de l'Economie, M. VERWILGHEN Le Ministre des Affaires sociales, R. DEMOTTE La Ministre des Classes moyennes et de l'Agriculture, Mme S. LARUELLE Le Ministre de l'Emploi, P. VANVELTHOVEN