DÉCISION 2008/616/JAI DU CONSEIL

du 23 juin 2008

concernant la mise en œuvre de la décision 2008/615/JAI relative à l'approfondissement de la coopération transfrontalière, notamment en vue de lutter contre le terrorisme et la criminalité transfrontalière

LE CONSEIL DE L'UNION EUROPÉENNE,

vu l'article 33 de la décision 2008/615/JAI du Conseil (1),

vu l'initiative de la République fédérale d'Allemagne,

vu l'avis du Parlement européen (2),

considérant ce qui suit:

Par la décision 2008/615/JAI, les éléments fondamentaux du traité du 27 mai 2005 entre le Royaume de Belgique, la République fédérale d'Allemagne, le Royaume d'Espagne, la République française, le Grand-Duché de Luxembourg, le Royaume des Pays-Bas et la République d'Autriche relatif à l'approfondissement de la coopération transfrontalière, notamment en vue de lutter contre le terrorisme, la criminalité transfrontalière et la migration illégale (ci-après dénommé «traité de Prüm») ont été transposés dans le cadre juridique de l'Union européenne.

L'article 33 de la décision 2008/615/JAI dispose que le Conseil doit arrêter les mesures nécessaires pour mettre en œuvre la décision 2008/615/JAI au niveau de l'Union, conformément à la procédure prévue à l'article 34, paragraphe 2, point c), deuxième phrase, du traité sur l'Union européenne. Il y a lieu que ces mesures se fondent sur l'accord d'exécution du 5 décembre 2006 concernant la mise en œuvre administrative et technique et l'exécution du traité de Prüm.

La présente décision établit les dispositions normatives communes qui sont indispensables à la mise en œuvre administrative et technique des formes de coopération prévues dans la décision 2008/615/JAI. L'annexe de la présente décision contient les dispositions d'exécution à caractère technique. En outre, un manuel distinct, comprenant exclusivement les informations factuelles que les États membres fourniront, sera élaboré et tenu à jour par le secrétariat général du Conseil.

DÉCIDE:

CHAPITRE I

GÉNÉRALITÉS

Article premier

Objet

La présente décision a pour objet d'établir les dispositions administratives et techniques nécessaires à la mise en œuvre de la décision 2008/615/JAI, en particulier en ce qui concerne les échanges automatisés des données ADN, des données dactyloscopiques et des données relatives à l'immatriculation des véhicules prévus au chapitre 2 de la présente décision, ainsi que pour les autres formes de coopération visées au chapitre 5 de la présente décision.

Article 2

Définitions

Aux fins de la présente décision, on entend par:

«consultation» et «comparaison» telles que visées aux articles 3, 4 et 9 de la décision 2008/615/JAI, les procédures par lesquelles il est établi qu'il y a une concordance entre, respectivement, des données ADN ou des données dactyloscopiques communiquées par un État membre et des données ADN ou des données dactyloscopiques contenues dans les bases de données d'un, de plusieurs, ou de tous les États membres;

«partie non codante de l'ADN», les régions chromosomiques non génétiquement exprimées, c'est-à-dire non connues pour fournir des propriétés fonctionnelles d'un organisme;

«profil ADN non identifié», le profil ADN obtenu à partir de traces recueillies lors d'une enquête pénale et appartenant à une personne non encore identifiée;

«cas par cas», par référence à l'article 3, paragraphe 1, deuxième phrase, à l'article 9, paragraphe 1, deuxième phrase, et à l'article 12, paragraphe 1, de la décision 2008/615/JAI, une seule enquête ou un seul dossier de poursuites pénales. Si ce dossier concerne plus d'un profil ADN, d'une donnée dactyloscopique ou d'une donnée relative à l'immatriculation des véhicules, ces profils ou ces données peuvent être transmis ensemble en une seule demande.

CHAPITRE 2

DISPOSITIONS COMMUNES EN MATIÈRE D'ÉCHANGE DE DONNÉES

Article 3

Spécifications techniques

Les États membres observent les spécifications techniques communes dans le cadre de toutes les demandes et réponses liées aux consultations et comparaisons de profils ADN, de données dactyloscopiques et de données relatives à l'immatriculation des véhicules. Ces spécifications techniques sont définies à l'annexe de la présente décision.

Article 4

Réseau de communication

L'échange électronique de données ADN, de données dactyloscopiques et de données relatives à l'immatriculation des véhicules entre les États membres s'effectue via le réseau de communication «Services télématiques transeuropéens sécurisés entre administrations (TESTA II)» et ses nouvelles versions.

Article 5

Disponibilité des échanges de données automatisés

Les États membres prennent toutes les mesures nécessaires pour que la consultation ou la comparaison automatisée de données ADN, de données dactyloscopiques et de données relatives à l'immatriculation de véhicules soit possible 24 heures sur 24 et 7 jours sur 7. Dans l'éventualité d'une défaillance technique, les points de contact nationaux des États membres s'en informent immédiatement et conviennent d'un autre système d'échange d'informations à titre temporaire, conformément aux dispositions juridiques applicables. L'échange automatisé des données est remis en service aussi rapidement que possible.

Article 6

Références des données ADN et des données dactyloscopiques

Les références visées à l'article 2 et à l'article 8 de la décision 2008/615/JAI consistent en la combinaison des éléments suivants:

CHAPITRE 3

DONNÉES ADN

Article 7

Principes régissant l'échange de données ADN

1. Les États membres utilisent les normes existantes en matière d'échange de données ADN, telles que l'ensemble européen de référence (European Standard Set, ESS) ou le groupe standard de loci d'Interpol (Interpol Standard Set of Loci, ISSOL).

2. La procédure de transmission, en cas de consultation et de comparaison automatisées de profils ADN, s'effectue dans le cadre d'une structure décentralisée.

3. Des mesures appropriées sont prises pour assurer la confidentialité et l'intégrité des données transmises aux autres États membres, notamment en matière de cryptage.

4. Les États membres prennent les mesures nécessaires pour garantir l'intégrité des profils ADN mis à la disposition des autres États membres ou transmis pour comparaison et pour faire en sorte que ces mesures soient conformes aux normes internationales, telles que l'ISO 17025.

5. Les États membres utilisent les codes «États membres» selon la norme ISO 3166-1 alpha-2.

Article 8

Règles applicables aux demandes et réponses relatives aux données ADN

1. Une demande de consultation ou de comparaison automatisée telle que visée à l'article 3 ou à l'article 4 de la décision 2008/615/JAI inclut uniquement les informations suivantes:

les types de profils ADN transmis (profils ADN non identifiés ou profils ADN de référence); et

2. La réponse (rapport de concordance) apportée à la demande visée au paragraphe 1 inclut uniquement les informations suivantes:

les profils ADN demandés et ceux pour lesquels une concordance est établie; et

3. La notification automatisée d'une concordance est effectuée uniquement si la consultation ou la comparaison automatisée a mis en évidence une concordance fondée sur un nombre minimal de loci. Ce minimum est fixé au chapitre 1 de l'annexe de la présente décision.

4. Les États membres prennent les mesures nécessaires pour que les demandes soient conformes aux déclarations communiquées en vertu de l'article 2, paragraphe 3, de la décision 2008/615/JAI. Ces déclarations figurent dans le manuel visé à l'article 18, paragraphe 2, de la présente décision.

Article 9

Procédure de transmission applicable à la consultation automatisée de profils ADN non identifiés conformément à l'article 3 de la décision 2008/615/JAI

1. Si, en cas de consultation à partir d'un profil ADN non identifié, la base de données nationale n'a mis en évidence aucune concordance ou a mis en évidence une concordance avec un profil ADN non identifié, ce profil ADN non identifié peut être transmis aux bases de données de tous les autres États membres et si, en cas de consultation à partir du profil ADN susvisé, les bases de données des autres États membres mettent en évidence des concordances avec des profils ADN de référence et/ou des profils ADN non identifiés, ces concordances sont automatiquement communiquées et les données indexées ADN sont transmises à l'État membre requérant; si les bases de données des autres États membres ne mettent en évidence aucune concordance, l'État membre requérant en est automatiquement informé.

2. Si, en cas de consultation à partir d'un profil ADN non identifié, les bases de données des autres États membres mettent en évidence une concordance, chaque État membre concerné peut insérer une annotation dans ce sens dans sa base de données nationale.

Article 10

Procédure de transmission applicable à la consultation automatisée de profils ADN de référence conformément à l'article 3 de la décision 2008/615/JAI

Si, en cas de consultation à partir d'un profil ADN de référence, la base de données nationale n'a mis en évidence aucune concordance avec un profil ADN de référence ou a mis en évidence une concordance avec un profil ADN non identifié, le profil ADN de référence concerné peut être transmis aux bases de données de tous les autres États membres, et si, en cas de consultation à partir du profil ADN de référence susvisé, les bases de données des autres États membres mettent en évidence des concordances avec des profils ADN de référence et/ou des profils ADN non identifiés, ces concordances sont automatiquement communiquées et les données indexées ADN sont transmises à l'État membre requérant; si les bases de données des autres États membres ne mettent en évidence aucune concordance, l'État membre requérant en est automatiquement informé.

Article 11

Procédure de transmission applicable à la comparaison automatisée de profils ADN non identifiés conformément à l'article 4 de la décision 2008/615/JAI

1. Si, en cas de comparaison avec des profils ADN non identifiés, les bases de données des autres États membres mettent en évidence des concordances avec des profils ADN de référence et/ou des profils ADN non identifiés, ces concordances sont automatiquement communiquées et les données indexées ADN sont transmises à l'État membre requérant.

2. Si, en cas de comparaison avec des profils ADN non identifiés, les bases de données des autres États membres mettent en évidence des concordances avec des profils ADN non identifiés ou des profils ADN de référence, chaque État membre concerné peut insérer une annotation dans ce sens dans sa base de données nationale.

CHAPITRE 4

DONNÉES DACTYLOSCOPIQUES

Article 12

Principes régissant l'échange de données dactyloscopiques

1. La numérisation des données dactyloscopiques et leur transmission aux autres États membres s'effectuent selon un format de données uniforme, décrit au chapitre 2 de l'annexe.

2. Chaque État membre s'assure que les données dactyloscopiques qu'il transmet sont d'une qualité suffisante en vue d'une comparaison par les fichiers automatisés d'empreintes digitales (FAED).

3. La procédure de transmission applicable à l'échange de données dactyloscopiques est mise en œuvre dans le cadre d'une structure décentralisée.

4. Des mesures appropriées sont prises pour assurer la confidentialité et l'intégrité des données dactyloscopiques transmises aux autres États membres, notamment en matière de cryptage.

5. Les États membres utilisent les codes «États membres» selon la norme ISO 3166-1 alpha-2.

Article 13

Capacités de consultation pour les données dactyloscopiques

1. Chaque État membre veille à ce que ses demandes de consultation ne dépassent pas les capacités de consultation indiquées par l'État membre requis. Les États membres adressent au secrétariat général du Conseil les déclarations visées à l'article 18, paragraphe 2, indiquant leurs capacités maximales de consultation journalières pour les données dactyloscopiques de personnes identifiées ou pour les données dactyloscopiques de personnes non encore identifiées.

2. Le nombre maximal de candidats admis par transmission pour vérification est fixé au chapitre 2 de l'annexe.

Article 14

Règles applicables aux demandes et aux réponses relatives aux données dactyloscopiques

1. L'État membre requis contrôle sans tarder, par un procédé entièrement automatisé, la qualité des données dactyloscopiques transmises. Au cas où les données ne se prêtent pas à une comparaison automatisée, l'État membre requis en informe sans tarder l'État membre requérant.

2. L'État membre requis effectue les consultations dans l'ordre chronologique d'arrivée des demandes. Les demandes doivent être traitées dans les vingt-quatre heures par un procédé entièrement automatisé. L'État membre requérant peut, si sa législation nationale l'exige, demander le traitement accéléré de ses demandes et l'État membre requis effectue la consultation sans tarder. Si les délais ne peuvent pas être respectés pour des raisons de force majeure, la comparaison est effectuée sans tarder dès que les obstacles ont été levés.

CHAPITRE 5

DONNÉES RELATIVES À L'IMMATRICULATION DES VÉHICULES

Article 15

Principes régissant la consultation automatisée de données relatives à l'immatriculation des véhicules

1. Pour la consultation automatisée de données relatives à l'immatriculation des véhicules, les États membres utilisent une version de l'application informatique du système d'information européen concernant les véhicules et les permis de conduire (Eucaris) spécialement conçue aux fins de l'article 12 de la décision 2008/615/JAI, ainsi que les versions modifiées de cette application.

2. La consultation automatisée de données relatives à l'immatriculation des véhicules s'effectue dans le cadre d'une structure décentralisée.

3. Les informations échangées via le système Eucaris sont transmises sous une forme cryptée.

4. Les éléments de données relatives à l'immatriculation des véhicules qui doivent être échangées sont décrits au chapitre 3 de l'annexe.

5. Dans le cadre de la mise en œuvre de l'article 12 de la décision 2008/615/JAI, les États membres peuvent donner la priorité aux consultations liées à la lutte contre la grande criminalité.

Article 16

Coûts

Chaque État membre prend en charge les coûts afférents à la gestion, à l'utilisation et à la maintenance de l'application informatique Eucaris visée à l'article 15, paragraphe 1.

CHAPITRE 6

COOPÉRATION POLICIÈRE

Article 17

Patrouilles communes et autres opérations conjointes

1. Conformément au chapitre 5 de la décision 2008/615/JAI, et en particulier aux déclarations communiquées au titre de l'article 17, paragraphe 4, et de l'article 19, paragraphes 2 et 4, de la présente décision, chaque État membre désigne un ou plusieurs points de contact afin de permettre aux autres États membres de s'adresser aux autorités compétentes, et chaque État membre peut préciser ses procédures pour l'organisation de patrouilles communes ou d'autres opérations conjointes, ses procédures à l'égard des initiatives des autres États membres concernant ces opérations, ainsi que d'autres aspects pratiques, et les modalités opérationnelles applicables à ces opérations.

2. Le secrétariat général du Conseil établit et tient à jour une liste des points de contact et informe les autorités compétentes de toute modification de cette liste.

3. Les autorités compétentes de chaque État membre peuvent prendre une initiative visant à mettre en place une opération conjointe. Avant le commencement d'une opération donnée, les autorités compétentes visées au paragraphe 2, déterminent, verbalement ou par écrit, les dispositions relatives aux modalités telles que:

4. Les déclarations, procédures et désignations prévues au présent article figurent dans le manuel visé à l'article 18, paragraphe 2.

CHAPITRE 7

DISPOSITIONS FINALES

Article 18

Annexe et manuel

1. L'annexe de la présente décision fixe les autres modalités applicables à la mise en œuvre technique et administrative de la décision 2008/615/JAI.

2. Un manuel est élaboré et tenu à jour par le secrétariat général du Conseil; il comprend exclusivement les informations factuelles fournies par les États membres, par le biais de déclarations faites conformément à la décision 2008/615/JAI ou à la présente décision ou de notifications faites au secrétariat général du Conseil. Ce manuel se présente sous la forme d'un document du Conseil.

Article 19

Autorités indépendantes compétentes en matière de protection des données

Conformément à l'article 18, paragraphe 2, les États membres communiquent au secrétariat général du Conseil le nom des autorités indépendantes compétentes en matière de protection des données ou des autorités judiciaires visées à l'article 30, paragraphe 5, de la décision 2008/615/JAI.

Article 20

Élaboration des décisions visées à l'article 25, paragraphe 2, de la décision 2008/615/JAI

1. Le Conseil prend la décision visée à l'article 25, paragraphe 2, de la décision 2008/615/JAI sur la base d'un rapport d'évaluation fondé sur un questionnaire.

2. En ce qui concerne l'échange automatisé de données visé au chapitre 2 de la décision 2008/615/JAI, le rapport d'évaluation est aussi fondé sur une visite d'évaluation et un essai pilote effectué lorsque l'État membre concerné a communiqué au secrétariat général du Conseil les informations visées à l'article 36, paragraphe 2, première phrase, de la décision 2008/615/JAI.

3. D'autres modalités pour cette procédure sont exposées au chapitre 4 de l'annexe.

Article 21

Évaluation de l'échange d'informations

1. L'application, d'un point de vue administratif, technique et financier, de l'échange d'informations au titre du chapitre 2 de la décision 2008/615/JAI, et notamment le recours au mécanisme prévu à l'article 15, paragraphe 5, fait l'objet d'une évaluation à intervalles réguliers. L'évaluation concerne les États membres qui appliquent déjà la décision 2008/615/JAI au moment de l'évaluation et porte sur les catégories de données pour lesquelles l'échange d'informations a commencé entre les États membres concernés. L'évaluation est fondée sur des rapports présentés par chacun de ces États membres.

2. D'autres modalités pour cette procédure sont exposées au chapitre 4 de l'annexe.

Article 22

Rapport avec l'accord d'exécution du traité de Prüm

Pour les États membres qui sont liés par le traité de Prüm, les dispositions concernées de la présente décision et de son annexe, lorsqu'elles seront pleinement en vigueur, s'appliquent en lieu et place des dispositions correspondantes contenues dans l'accord d'exécution du traité de Prüm. Toutes les autres dispositions de l'accord d'exécution restent applicables entre les parties contractantes au traité de Prüm.

Article 23

Mise en œuvre

Les États membres prennent les mesures nécessaires pour se conformer aux dispositions de la présente décision dans les délais prévus à l'article 36, paragraphe 1, de la décision 2008/615/JAI.

Article 24

Application

La présente décision prend effet vingt jours après sa publication au Journal officiel de l'Union européenne.

(1) Voir page 1 du présent Journal officiel.

(2) Avis du 21 avril 2008 (non encore paru au Journal officiel).

ANNEXE

TABLE DES MATIÈRES

CHAPITRE 1: Échange de données ADN

1. Questions de criminalistique et règles et algorithmes de concordance dans le domaine génétique

1.1. Propriétés des profils ADN

1.2. Règles de concordance

1.3. Règles en matière de rapports

2. Tableau des codes des États membres

3. Analyse fonctionnelle

3.1. Disponibilité du système

3.2. Deuxième étape

4. Document de contrôle des interfaces ADN

4.1. Introduction

4.2. Définition de la structure XML

5. Application, sécurité et architecture de communication

5.1. Présentation

5.2. Architecture de haut niveau

5.3. Normes de sécurité et protection des données

5.4. Protocoles et normes à mettre en œuvre pour le cryptage: S/MIME et mécanismes connexes

5.5. Architecture de l'application

5.6. Protocoles et normes à utiliser dans l'architecture de l'application

5.7. Cadre de communication

CHAPITRE 2: Échange de données dactyloscopiques (document de contrôle des interfaces)

1. Aperçu de la teneur des fichiers

2. Format des enregistrements

3. Enregistrement logique de type 1: en-tête de fichier

4. Enregistrement logique de type 2: descriptif

5. Enregistrement logique de type 4: image à haute résolution avec nuances de gris

6. Enregistrement logique de type 9: points caractéristiques

7. Enregistrement logique de type 13: image de trace latente à résolution variable

8. Enregistrement logique de type 15: images d'empreintes palmaires à résolution variable

9. Appendices au chapitre 2 (échange de données dactyloscopiques)

9.1. Codes de séparation ASCII

9.2. Calcul du caractère de contrôle alphanumérique

9.3. Codage de caractères

9.4. Résumé des opérations

9.5. Définition des enregistrements de type 1

9.6. Définition des enregistrements de type 2

9.7. Codes des algorithmes de compression (images à niveaux de gris)

9.8. Spécifications pour le courrier électronique

CHAPITRE 3: Échange de données relatives à l'immatriculation des véhicules

1. Ensemble commun de données aux fins de la consultation automatisée de données relatives à l'immatriculation des véhicules

1.1. Définitions

1.2. Recherche concernant un véhicule, un propriétaire ou un détenteur

2. Sécurité des données

2.1. Aperçu

2.2. Caractéristiques de sécurité liées à l'échange de messages

2.3. Caractéristiques de sécurité non liées à l'échange de messages

3. Conditions techniques de l'échange de données

3.1. Description générale de l'application Eucaris

3.2. Exigences fonctionnelles et non fonctionnelles

CHAPITRE 4: Évaluation

1. Procédure d'évaluation en vertu de l'article 20 (préparation des décisions conformément à l'article 25, paragraphe 2, de la décision 2008/615/JAI)

1.1. Questionnaire

1.2. Essai en conditions réelles

1.3. Visite d'évaluation

1.4. Rapport au Conseil

2. Procédure d'évaluation conformément à l'article 21

2.1. Statistiques et rapport

2.2. Révision

3. Réunion d'experts

CHAPITRE 1: Échange de données ADN

1. Questions de criminalistique et règles et algorithmes de concordance dans le domaine génétique

1.1. Propriétés des profils ADN

Le profil ADN peut comprendre 24 paires de nombres représentant les allèles des 24 loci également utilisés dans les procédures d'Interpol en la matière. Le nom de ces loci figure dans le tableau ci-après:

VWA TH01 D21S11 FGA D8S1179 D3S1358 D18S51 Amélogénine TPOX CSF1P0 D13S317 D7S820 D5S818 D16S539 D2S1338 D19S433 Penta D Penta E FES F13A1 F13B SE33 CD4 GABA

Les 7 loci grisés, au premier rang, constituent à la fois l'actuel ensemble européen de référence (European Standard Set of Loci, ESS) et le groupe standard de loci d'Interpol (Interpol Standard Set of Loci, ISSOL).

Règles d'inclusion:

Les profils ADN mis à disposition par les États membres à des fins de consultation et de comparaison, ainsi que les profils ADN transmis aux mêmes fins, doivent comporter au moins 6 loci complètement renseignés (1) et peuvent en comprendre d'autres, ou des blancs, en fonction des disponibilités. Les profils ADN de référence doivent comporter au moins 6 des 7 loci de l'ESS. Pour affiner la précision des concordances, tous les allèles disponibles sont stockés dans la base de données des profils ADN indexés et exploités aux fins des consultations et des comparaisons. Il conviendrait que chaque État membre mette en œuvre, aussi rapidement que possible en pratique, tout nouvel ESS adopté par l'Union européenne.

Il est interdit d'inclure des profils obtenus à partir d'échantillons mélangés, de sorte que les valeurs alléliques de chaque locus consisteront en deux nombres seulement, lesquels peuvent d'ailleurs être identiques, en cas d'homozygotie sur un locus spécifique.

Les règles ci-après s'appliquent aux caractères de remplacement (ou joker) et aux microvariants:

— toute valeur non numérique figurant dans le profil (par exemple «o», «f», «r», «na», «nr» ou «un»), à l'exception de celle correspondant à l'amélogénine, doit être convertie automatiquement en un caractère de remplacement (*) pour l'exportation et faire l'objet d'une comparaison globale,

— les valeurs numériques «0», «1» ou «99» contenues dans le profil doivent être converties automatiquement en un caractère de remplacement (*) pour l'exportation et faire l'objet d'une comparaison avec tous les autres,

— si 3 allèles sont fournis pour un locus, le premier sera accepté et les deux autres devront être automatiquement convertis en un caractère générique (*) pour l'exportation et faire l'objet d'une comparaison globale,

— lorsqu'une valeur de remplacement est fournie pour l'allèle 1 ou l'allèle 2, les deux permutations de la valeur numérique donnée pour le locus feront l'objet d'une recherche (par exemple 12, * pourrait concorder avec 12,14 ou 9,12),

— les microvariants pentanucléotidiques (Penta D, Penta E et CD 4) seront comparés selon le schéma suivant: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x.4 — x.4 = x.2, x.3, x + 1

— les microvariants tétranucléotidiques (le reste des loci sont des tétranucléotides) seront comparés selon le schéma suivant: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x + 1

1.2. Règles de concordance

Deux profils génétiques seront comparés à partir des loci pour lesquels une paire de valeurs alléliques est disponible dans les deux profils. Il doit y avoir concordance entre au moins 6 loci complets désignés (à l'exclusion de l'amélogénine) des deux profils ADN pour qu'une réponse indiquant l'existence d'une concordance soit fournie.

Une concordance complète (qualité 1) est définie comme une concordance lorsque l'ensemble des valeurs alléliques des loci contenus à la fois dans le profil de question et le profil de comparaison sont les mêmes. Une quasi-concordance est définie comme une concordance lorsque la valeur d'un seul de tous les allèles comparés diffère entre les deux profils ADN (qualité 2, 3 et 4). Une quasi-concordance n'est acceptée qu'en cas de concordance entre au moins 6 loci complets désignés des deux profils ADN comparés.

Une telle quasi-concordance peut-être due à:

— une faute de frappe dans l'un des profils ADN, dans la demande de consultation ou dans la base de données ADN,

— une erreur de détermination ou de désignation de l'allèle lors de l'établissement d'un profil ADN.

1.3. Règles en matière de rapports

Tant les concordances complètes que les quasi-concordances et les cas où il n'y a «pas de concordance» devront faire l'objet d'un rapport.

Les rapports de concordance seront adressés au point de contact national requérant et mis à la disposition du point de contact national requis (afin qu'il puisse évaluer la nature et le nombre des éventuelles demandes de suivi visant à obtenir d'autres données à caractère personnel disponibles et d'autres informations relatives au profil ADN correspondant à la concordance, conformément aux articles 5 et 10 de la décision 2008/615/JAI).

2. Tableau des codes des États membres

Conformément à la décision 2008/615/JAI, les codes de la norme ISO 3166-1 alpha-2 sont utilisés pour attribuer les noms de domaine et définir les autres paramètres de configuration des applications d'échange de données ADN en réseau fermé créées en application du traité de Prüm.

La norme ISO 3166-1 alpha-2 prévoit les codes à deux lettres ci-après pour les États membres:

État membre Code État membre Code Belgique BE Luxembourg LU Bulgarie BG Hongrie HU République tchèque CZ Malte MT Danemark DK Pays-Bas NL Allemagne DE Autriche AT Estonie EE Pologne PL Grèce EL Portugal PT Espagne ES Roumanie RO France FR Slovaquie SK Irlande IE Slovénie SI Italie IT Finlande FI Chypre CY Suède SE Lettonie LV Royaume-Uni UK Lituanie LT

3. Analyse fonctionnelle

3.1. Disponibilité du système

Il conviendrait que les demandes formulées conformément à l'article 3 de la décision 2008/615/JAI soient soumises à la base de données concernée dans l'ordre chronologique de l'envoi de chaque demande, alors que les réponses devraient être transmises de façon qu'elles parviennent à l'État membre requérant dans les quinze minutes qui suivent l'arrivée des demandes.

3.2. Deuxième étape

Lorsqu'un État membre reçoit un rapport indiquant l'existence d'une concordance, il incombe à son point de contact national de comparer les valeurs figurant dans le profil ayant fait l'objet de la demande et celles du ou des profils reçus en réponse, afin de valider et de vérifier la valeur probante du profil. Les points de contact nationaux peuvent entrer en communication les uns avec les autres aux fins de la validation.

Les procédures relatives à l'entraide judiciaire démarrent après la validation d'une concordance entre deux profils, sur la base d'un rapport de concordance complète ou de quasi-concordance obtenu pendant la phase de consultation automatisée.

4. Document de contrôle des interfaces ADN

4.1. Introduction

4.1.1. Objectifs

La présente partie définit les prescriptions en matière d'échange d'informations relatives aux profils ADN entre les bases de données génétiques de l'ensemble des États membres. Les champs d'en-tête sont spécifiquement définis pour l'échange de données ADN en application du traité de Prüm, alors que les champs de données sont fondés sur la partie correspondant aux données du profil ADN, dans le schéma XML défini pour la passerelle ADN d'Interpol.

Les données sont échangées au moyen du protocole SMTP (Simple Mail Transfer Protocol) ou d'autres techniques modernes, par l'intermédiaire d'un serveur central de messagerie électronique mis en place par le fournisseur de réseau. Le fichier XML est transmis dans le corps d'un message.

4.1.2. Champ d'application

Le présent document de contrôle des interfaces ne définit que le corps des messages électroniques. Tous les aspects qui concernent spécifiquement le réseau et la messagerie électronique sont définis d'une façon uniforme afin de prévoir une base technique commune pour l'échange de données ADN.

Ce cadre commun:

— prévoit une définition du format du champ «objet» du message, afin de permettre un traitement automatisé des messages,

— précise s'il y a lieu de crypter le contenu et, le cas échéant, quelles méthodes doivent être utilisées,

— fixe la longueur maximale des messages.

4.1.3. Principes et structure XML

Le message XML est structuré comme suit:

— en-tête, contenant des informations sur la transmission, et

— données, contenant des informations propres au profil, ainsi que le profil lui-même.

Le même schéma XML est utilisé tant pour la demande que pour la réponse.

Pour pouvoir procéder à des vérifications complètes des profils ADN non identifiés (article 4 de la décision 2008/615/JAI), il doit être possible d'envoyer une série de profils dans un seul message. Il faut fixer un nombre maximal de profils pouvant être inclus dans un même message. Ce nombre dépend de la taille maximale autorisée des messages électroniques et sera fixé une fois que le serveur de messagerie électronique aura été sélectionné.

Exemple de code XML:

<?version="1.0" standalone="yes"?>

<PRUEMDNAx xmlns:msxsl="urn:schemas-microsoft-com:xslt"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<header>

[…]

</header>

<datas>

[…]

</datas>

[<datas> structure «datas» répétée si plus d'un profil est envoyé (….) dans un même message SMTP, uniquement dans les cas visés à l'article 4

</datas>]

</PRUEMDNA>

4.2. Définition de la structure XML

Les définitions qui suivent sont présentées à titre documentaire et pour faciliter la lecture. Les informations réellement obligatoires sont définies dans un fichier de schéma XML (PRUEM DNA.xsd).

4.2.1. Schéma PRUEMDNAx

Il comprend les champs ci-après:

Champ Type Description header PRUEM_header Nombre: 1 datas PRUEM_datas Nombre: 1 … 500

4.2.2. Contenu de l'en-tête

4.2.2.1. PRUEM_header Il s'agit d'une structure décrivant l'en-tête du fichier XML. Elle comprend les champs ci-après: Champ Type Description direction PRUEM_header_dir Direction de circulation du message ref String (chaîne de caractères) Référence au ficher XML generator String (chaîne de caractères) Créateur du fichier XML schema_version String (chaîne de caractères) Numéro de version du schéma à utiliser requesting PRUEM_header_info Informations relatives à l'État requérant requested PRUEM_header_info Informations relatives à l'État requis

4.2.2.2. PRUEM_header dir Type des données contenues dans le message. La valeur peut être: Valeur Description R Demande (Request) A Réponse (Answer)

4.2.2.3. PRUEM_header_info Structure permettant de décrire l'État membre ainsi que la date et l'heure de la création du message. Cette structure comprend les champs ci-après: Champ Type Description source_isocode String (chaîne de caractères) Code ISO 3166-2 de l'État membre requérant destination_isocode String (chaîne de caractères) Code ISO 3166-2 de l'État membre requis request_id String (chaîne de caractères) Identifiant unique d'une demande date Date Date de la création d'un message time Time (heure) Heure de la création d'un message

4.2.3. Contenu des profils de données PRUEM

4.2.3.1. PRUEM_datas Il s'agit d'une structure décrivant la partie des données XML concernant le profil. Elle comprend les champs suivants: Champ Type Description reqtype PRUEM_request_type Type de demande (article 3 ou 4) date Date Date de stockage du profil type PRUEM_datas_type Type de profil result PRUEM_datas_result Résultat de la demande agency String (chaîne de caractères) Nom de l'unité correspondante responsable du profil profile_ident String (chaîne de caractères) Identifiant unique de profil d'État membre message String (chaîne de caractères) Message d'erreur si le résultat = E profile IPSG_DNA_profile Si direction = A (réponse) ET résultat ≠ H (concordance) vide match_id String (chaîne de caractères) En cas de HIT PROFILE_ID du profil requérant quality PRUEM_hitquality_type Qualité de la concordance hitcount Integer (entier) Nombre d'allèles faisant l'objet de la concordance rescount Integer (entier) Nombre de profils faisant l'objet de la concordance. Si la direction = R (demande), alors champ vide. Si la qualité! = 0 (profil original requis), alors champ vide.

4.2.3.2. PRUEM_request_type Type de données contenues dans le message. Les valeurs peuvent être les suivantes: Valeur Description 3 Demandes au titre de l'article 3 de la décision 2008/615/JAI 4 Demandes au titre de l'article 4 de la décision 2008/615/JAI

4.2.3.3. PRUEM_hitquality_type Valeur Description 0 Concerne le profil requérant original: S'il n'y a «pas de concordance»: le profil requérant original est renvoyé seul. S'il y a «concordance»: le profil requérant original est renvoyé avec les profils ayant fait l'objet de la concordance. 1 Identique pour tous les allèles disponibles, sans caractères génériques 2 Identique pour tous les allèles disponibles, avec caractères génériques 3 Concordance moyennant déviation (microvariant) 4 Concordance avec non-concordance

4.2.3.4. PRUEM_data_type Type de données contenues dans le message. Les valeurs peuvent être les suivantes: Valeur Description P Profil d'une personne S Trace (Stain)

4.2.2.5. PRUEM_data_result Type de données contenues dans le message. Les valeurs peuvent être les suivantes: Valeur Description U Indéfini (Undefined), si direction = R (demande) H Concordance (Hit) N Pas de concordance (Non Hit) E Erreur

4.2.3.6. IPSG_DNA_profile Structure décrivant un profil ADN. Elle contient les champs suivants: Champ Type Description ess_issol IPSG_DNA_ISSOL Groupe de loci correspondant à l'ISSOL (groupe standard de loci d'Interpol) additional_loci IPSG_DNA_additional_loci Autres loci marker String (chaîne de caractères) Méthode utilisée pour générer l'ADN profile_id String (chaîne de caractères) Identifiant unique du profil ADN

4.2.3.7. IPSG_DNA_ISSOL Structure contenant les loci ISSOL (groupe standard de loci d'Interpol). Elle comporte les champs suivants: Champ Type Description vwa IPSG_DNA_locus Locus vwa th01 IPSG_DNA_locus Locus th01 d21s11 IPSG_DNA_locus Locus d21s11 fga IPSG_DNA_locus Locus fga d8s1179 IPSG_DNA_locus Locus d8s1179 d3s1358 IPSG_DNA_locus Locus d3s1358 d18s51 IPSG_DNA_locus Locus d18s51 amelogenin IPSG_DNA_locus Locus amélogénine

4.2.3.8. IPSG_DNA_additional_loci Structure contenant les autres loci. Elle comporte les champs suivants: Champ Type Description tpox IPSG_DNA_locus Locus tpox csf1po IPSG_DNA_locus Locus csf1po d13s317 IPSG_DNA_locus Locus d13s317 d7s820 IPSG_DNA_locus Locus d7s820 d5s818 IPSG_DNA_locus Locus d5s818 d16s539 IPSG_DNA_locus Locus d16s539 d2s1338 IPSG_DNA_locus Locus d2s1338 d19s433 IPSG_DNA_locus Locus d19s433 penta_d IPSG_DNA_locus Locus penta_d penta_e IPSG_DNA_locus Locus penta_e fes IPSG_DNA_locus Locus fes f13a1 IPSG_DNA_locus Locus f13a1 f13b IPSG_DNA_locus Locus f13b se33 IPSG_DNA_locus Locus se33 cd4 IPSG_DNA_locus Locus cd4 gaba IPSG_DNA_locus Locus gaba

4.2.3.9. IPSG_DNA_locus Structure décrivant un locus. Elle comporte les champs suivants: Champ Type Description low_allele String (chaîne de caractères) Valeur la plus basse d'un allèle high_allele String (chaîne de caractères) Valeur la plus élevée d'un allèle

5. Application, sécurité et architecture de communication

5.1. Présentation

Pour la mise en œuvre d'applications aux fins de l'échange de données ADN dans le cadre de la décision 2008/615/JAI, un réseau de communication fermé sera mis en place à l'usage exclusif des États membres. Pour tirer parti de cette infrastructure commune de communication et envoyer les demandes et recevoir les réponses d'une façon plus efficace, un mécanisme asynchrone a été retenu pour transmettre les demandes de données ADN et dactyloscopiques dans un message électronique transmis via le protocole SMTP. Pour des raisons de sécurité, on aura recours à la norme S/MIME (Secure Multipurpose Internet Mail Extensions, ou MIME sécurisé), qui étend les fonctionnalités du protocole SMTP, afin d'établir un véritable tunnel sécurisé de bout en bout sur le réseau.

Le réseau de communication opérationnel TESTA (Services télématiques transeuropéens sécurisés entre administrations) est utilisé pour l'échange de données entre États membres. TESTA relève de la responsabilité de la Commission européenne. Comme les bases de données ADN nationales et les points d'accès nationaux actuels à TESTA peuvent se trouver sur différents sites dans les États membres, il peut exister deux modes d'accès à TESTA:

1) soit en utilisant les points d'accès nationaux existants ou en établissant un nouveau point d'accès TESTA;

2) soit en créant un lien local sécurisé entre le site où se trouve la base de données ADN et le point d'accès national TESTA existant, ce lien étant administré par le service national compétent.

Les protocoles et les normes utilisés pour la mise en œuvre des applications prévues dans le cadre de la décision 2008/615/JAI sont conformes aux standards ouverts et aux exigences imposées par les autorités chargées de l'élaboration de la politique des États membres en matière de sécurité.

5.2. Architecture de haut niveau

La décision 2008/615/JAI prévoit que chaque État membre met ses données ADN à disposition des autres États membres, conformément au format commun standardisé, à des fins d'échange et/ou de consultation. L'architecture se fonde sur le modèle de communication «de point à point». Il n'existe ni serveur informatique centralisé ni base de données unique contenant des profils ADN.

Figure 1: topologie de l'échange de données ADN

Outre le respect des contraintes juridiques nationales, chaque État membre doit décider du type de matériel et de logiciel devant être déployé pour que la configuration mise en œuvre sur son site respecte les exigences de la décision 2008/615/JAI.

5.3. Normes de sécurité et protection des données

Trois niveaux de sécurité ont été envisagés et mis en œuvre.

5.3.1. Niveau des données

Les données relatives aux profils ADN fournies par chaque État membre doivent être préparées conformément à une norme commune de protection des données, de sorte qu'un État membre requérant reçoive une réponse indiquant essentiellement l'existence ou l'absence d'une concordance, ainsi qu'un numéro d'identification en cas de concordance, sans aucune information à caractère personnel. Les recherches complémentaires, après notification d'une concordance, seront menées au niveau bilatéral, conformément aux instruments nationaux applicables aux sites de chacun des États membres en matière juridique et organisationnelle.

5.3.2. Niveau de la communication

Avant d'être transmis vers les sites des autres États membres, les messages contenant des informations sur les profils ADN (demandes et réponses) seront cryptés au moyen d'un système moderne conforme aux standards ouverts, par exemple le protocole S/MIME.

5.3.3. Niveau de la transmission

Tous les messages cryptés contenant des informations relatives à des profils ADN seront envoyés vers les sites des autres États membres via un système de réseau privé virtuel, administré par un fournisseur de réseau de confiance au niveau international. Les accès sécurisés à ce réseau privé relèveront de la responsabilité nationale. Ce système de réseau privé virtuel n'est pas relié à l'internet.

5.4. Protocoles et normes à mettre en œuvre pour le cryptage: S/MIME et mécanismes connexes

Le standard ouvert S/MIME, qui étend les fonctionnalités du protocole SMTP, norme de facto pour la messagerie électronique, sera déployé pour crypter les messages contenant des informations relatives à des profils ADN. Le protocole S/MIME (v. 3), qui prévoit des confirmations signées, des étiquettes de sécurité et des listes de diffusion sécurisées, est organisé en couches selon la spécification de l'Internet Engineering Task Force (IETF) pour la protection cryptographique des messages, à savoir la Cryptographic Message Syntax (CMS). Il peut être utilisé pour signer, résumer, authentifier ou crypter numériquement les données numériques sous toutes leurs formes.

Le certificat sous-jacent utilisé par le mécanisme S/MIME doit être conforme à la norme X.509. Pour garantir l'uniformité des normes et des procédures avec les autres applications déployées dans le cadre du traité de Prüm, les règles de traitement des opérations de cryptage S/MIME ou à appliquer par les diverses plates-formes du commerce sont les suivantes:

— la séquence des opérations est: d'abord cryptage, puis signature,

— on appliquera les algorithmes de cryptage AES (Advanced Encryption Standard) avec une clé de 256 bits, et RSA (Rivest Shamir Adleman) avec une clé de 1 024 bits, respectivement aux cryptages symétriques et asymétriques,

— la fonction de hachage cryptographique SHA-1 sera appliquée.

La fonctionnalité S/MIME est intégrée dans la grande majorité des logiciels modernes de messagerie électronique, notamment Outlook, Mozilla Mail et Netscape Communicator 4.x, et est capable d'interopérer avec tous les principaux logiciels de messagerie.

Le protocole S/MIME pouvant être facilement intégré dans les infrastructures informatiques nationales, dans tous les sites des États membres, il a été choisi comme mécanisme viable de mise en œuvre de la sécurité au niveau de la communication. Pour valider cette approche d'une façon plus efficace et réduire les coûts, l'interface de programmation (API) JavaMail, qui est un standard ouvert, est retenue pour le prototypage de l'échange des données ADN. L'API JavaMail prévoit un processus simple de cryptage et de décryptage des courriels, grâce aux normes S/MIME et/ou OpenPGP. Le but est de disposer d'une interface de programmation unique et d'utilisation simple pour les clients de messagerie avec lesquels on souhaite envoyer et recevoir des messages cryptés avec les deux méthodes les plus utilisées. C'est pourquoi toute implémentation moderne de l'API JavaMail suffira pour satisfaire aux exigences visées par la décision 2008/615/JAI, par exemple, l'interface JCE (Java Cryptographic Extension) de BouncyCastle, qui sera utilisée pour la mise en œuvre du protocole S/MIME aux fins du prototypage de l'échange de données ADN entre l'ensemble des États membres.

5.5. Architecture de l'application

Chaque État membre fournira aux autres États membres un ensemble de données normalisées relatives à des profils ADN conformes à la version actuelle du document commun de contrôle des interfaces. Pour ce faire, on peut soit créer une vue logique à partir de la base de données nationale, soit créer une base de données alimentée par exports (base de données indexée).

Les quatre composantes principales (serveur de messagerie et protocole S/MIME, serveur d'applications, zone de structure des données pour extraire et ajouter des données et enregistrer les messages entrants et sortants, et moteur de concordance) appliquent l'ensemble de la logique de l'application indépendamment du produit.

Pour que tous les États membres puissent intégrer facilement les composantes dans leurs sites nationaux, la fonctionnalité commune spécifiée a été mise en œuvre au moyen de composantes de logiciels libres, qui pourraient être sélectionnées par chaque État membre en fonction de la politique et de la réglementation applicables au niveau national en matière informatique. Étant donné que des fonctions distinctes doivent être mises en œuvre pour accéder aux bases de données indexées contenant des profils ADN couverts par la décision 2008/615/JAI, il est loisible à chaque État membre de choisir sa plate-forme matérielle et logicielle, y compris la base de données et le système d'exploitation.

Un prototype pour l'échange de données ADN a été élaboré et testé avec succès sur le réseau commun existant. La version 1.0 a été déployée en production et est utilisée pour les opérations quotidiennes. Les États membres peuvent recourir au produit mis au point en commun mais peuvent aussi développer leurs propres produits. Les composantes du produit commun seront entretenues, adaptées et enrichies en fonction de l'évolution des besoins en matière informatique, criminalistique et/ou de police opérationnelle.

Figure 2: Aperçu topologique de l'application

5.6. Protocoles et normes à utiliser dans l'architecture de l'application

5.6.1. XML

L'échange de données ADN tirera pleinement parti d'un schéma XML en pièce jointe à des messages électroniques utilisant le protocole SMTP. Le XML (EXtensible Markup Language) est un langage de balisage polyvalent, recommandé par le Consortium World Wide Web (W3C) et utilisé pour créer des langages de balisage spécialisés permettant de décrire de nombreux types différents de données. La description d'un profil ADN susceptible d'être échangée entre l'ensemble des États membres repose sur le langage XML et sur un schéma XML figurant dans le document de contrôle des interfaces.

5.6.2. ODBC

La norme ODBC (Open DataBase Connectivity) propose une interface de programmation normalisée permettant d'accéder à des systèmes de gestion de bases de données (SGBD); l'interface est indépendante des langages de programmation, des bases de données et des systèmes d'exploitation. La norme ODBC a toutefois ses inconvénients. L'administration d'un grand nombre de clients peut nécessiter la mise en œuvre de pilotes et de bibliothèques de liens dynamiques (DLL) très divers. Cette complexité peut se traduire par des surcoûts en matière d'administration des systèmes.

5.6.3. JDBC

JDBC (Java DataBase Connectivity) est une interface de programmation pour le langage JAVA, qui définit de quelle manière un client accède à une base de données. Contrairement à la norme ODBC, l'API JDBC se passe de bibliothèques dynamiques locales installées sur l'ordinateur de bureau.

La logique du traitement des demandes et des réponses relatives aux profils ADN, dans les sites de chaque État membre, est décrite dans le diagramme ci-dessous. Les flux de demandes et de réponses interagissent avec une zone de données neutre comprenant divers ensembles de données partageant une même structure.

Figure 3: Aperçu du déroulement des opérations dans les sites des États membres

5.7. Cadre de communication

5.7.1. Réseau commun de communication: TESTA et son infrastructure de suivi

L'application d'échange des données ADN tirera parti de la messagerie électronique, un mécanisme asynchrone, pour l'envoi des demandes et la réception des réponses entre les États membres. Comme l'ensemble des États membres dispose d'au moins un point d'accès national au réseau TESTA, l'échange des données ADN passera par ce réseau. TESTA offre plusieurs services appréciables par le biais de son serveur de messagerie électronique. Outre qu'elle héberge les boîtes aux lettres électroniques spécifiques de TESTA, cette infrastructure permet de créer des listes de distribution de courrier électronique ainsi que des règles de routage. Il est ainsi possible de recourir à TESTA en tant que plaque tournante pour les messages adressés aux administrations reliées à des domaines couvrant l'ensemble de l'Union européenne. Il est également possible de mettre en place des mécanismes de protection contre les virus.

Le serveur de messagerie de TESTA repose sur une plate-forme matérielle à disponibilité élevée, qui est localisée dans les installations centrales du réseau et protégée par un pare-feu. Le système de noms de domaine (DNS, pour Domain Name System) de TESTA établit une correspondance entre les adresses universelles (URL) et les adresses IP et isole l'utilisateur et les applications des questions liées à la résolution des adresses.

5.7.2. Questions de sécurité

Le concept de réseau privé virtuel (VPN, pour Virtual Private Network) a été mis en œuvre dans le cadre de TESTA. La technologie de commutation de balises utilisée pour la mise en place de ce réseau privé virtuel sera mise en conformité avec la norme multiprotocoles de commutation d'étiquettes (MPLS, pour Multiprotocol Label Switching) conçue par l'IETF (Internet Engineering Task Force).

La technologie MPLS est une norme mise au point par l'IETF, qui permet d'accélérer le trafic sur le réseau en évitant l'analyse des paquets par les routeurs intermédiaires. À cet effet, des «étiquettes» sont jointes aux paquets par les routeurs situés aux deux extrémités de la dorsale, en fonction d'informations contenues dans une table de routage (FIB, pour Forwarding Information Base). Ses étiquettes sont également utilisées pour la mise en œuvre des réseaux privés virtuels (VPN).

La technologie MPLS combine les avantages du routage (couche 3) et ceux de la commutation (couche 2). Les adresses IP n'étant pas analysées au cours de la transmission sur la dorsale, la technologie MPLS n'impose aucune limitation sur l'adressage IP.

En outre, les courriers électroniques transmis par le réseau TESTA seront protégés par le mécanisme de cryptage fondé sur le protocole S/MIME. Il est impossible pour qui que ce soit de déchiffrer les messages transmis par ce réseau sans la clé et le certificat approprié.

5.7.3. Protocoles et normes à utiliser sur le réseau de communication

5.7.3.1. SMTP Le protocole SMTP (Simple Mail Transfer Protocol) est la norme de facto pour la transmission du courrier électronique sur l'internet. Le protocole SMTP est assez simple et recourt à des informations textuelles: le ou les destinataires du message sont spécifiés, puis le corps du message est transmis. Le protocole SMTP utilise le port TCP 25, conformément aux spécifications de l'IETF. L'enregistrement MX (Mail eXchange record) du système de noms de domaines (DNS) est utilisé pour déterminer le serveur SMTP qui correspond à un nom de domaine donné. Comme ce protocole reposait entièrement, à ses débuts, sur du texte au format ASCII, il n'était pas bien adapté aux fichiers binaires. Des normes telles que le protocole MIME (Multipurpose Internet Mail Extensions) ont été mises au point afin d'encoder les fichiers binaires pour les transmettre par le protocole SMTP. De nos jours, la plupart des serveurs SMTP prennent en charge les extensions 8BITMIME et S/MIME, ce qui permet de transmettre des fichiers binaires presque aussi facilement que du texte brut. Les règles de traitement pour les opérations nécessitant le recours au protocole S/MIME sont décrites dans la partie concernée (voir le point 5.4). SMTP est un protocole de distribution sélective («push»): il ne permet pas de récupérer à la demande les messages se trouvant sur un serveur distant. Il faut recourir, à cet effet, à un client de messagerie utilisant les protocoles POP3 ou IMAP. Pour l'échange de données ADN, il a été décidé de recourir au protocole POP3.

5.7.3.2. POP Les clients de messagerie locaux utilisent le Post Office Protocol Version 3 (POP3), un protocole internet normalisé appartenant à la couche applications, pour récupérer des messages électroniques se trouvant sur un serveur distant, par le biais d'une connexion TCP/IP. Les clients de messagerie envoient des messages sur l'internet ou un réseau d'entreprise en recourant au profil «Submit» du protocole SMTP. Le protocole MIME est la norme pour les pièces jointes et le texte non-ASCII contenu dans les messages. Quoique ni le protocole POP3 ni le protocole SMTP n'exigent que les messages soient formatés selon le protocole MIME, la majorité des courriels transitant par l'internet ont ce format, de sorte que les clients POP doivent également prendre en charge et utiliser ce protocole. Par conséquent, l'ensemble de l'environnement de communication prévu par la décision 2008/615/JAI prendra en charge les composantes du protocole POP.

5.7.4. Attribution des adresses de réseau

Environnement opérationnel

Le RIPE (Réseaux IP européens), autorité compétente en Europe pour l'attribution des adresses IP, a alloué à TESTA un bloc d'adresses dédié pour sous-réseau de classe C. Si nécessaire, d'autres blocs d'adresses pourraient, à l'avenir, être alloués à TESTA. En Europe, les adresses IP sont attribuées aux États membres sur une base géographique. L'échange des données entre les États membres, dans le cadre de la décision 2008/615/JAI, se déroule à l'intérieur d'un réseau IP fermé (du point de vue logique) couvrant l'ensemble de l'Europe.

Environnement d'essai

Afin d'assurer le bon fonctionnement de l'environnement au quotidien pour l'ensemble des États membres qui y sont reliés, il faut mettre en place un environnement d'essai dans le réseau fermé, à l'intention des nouveaux États membres qui se disposent à participer aux opérations. Une liste comprenant notamment les adresses IP, les paramètres de configuration du réseau, les domaines de messagerie ainsi que les comptes d'utilisateurs des applications a été dressée et devrait être appliquée sur le site de l'État membre concerné. En outre, un ensemble de faux profils ADN a été constitué à des fins de test.

5.7.5. Paramètres de configuration

Un système de messagerie électronique sécurisé utilisant le domaine eu-admin.net est créé. Ce domaine — et les adresses qui y sont liées — ne sera pas accessible de l'extérieur du domaine TESTA, qui couvre l'ensemble de l'Union européenne, les noms n'étant connus que par le serveur DNS central de TESTA, qui est isolé de l'internet.

La conversion de ces adresses de sites TESTA (nom d'hôtes) en adresses IP est effectuée par le service DNS de TESTA. Pour chaque domaine local, un enregistrement MAIL sera ajouté à ce serveur DNS central de TESTA, ce qui permettra de réexpédier tous les messages électroniques envoyés à des domaines locaux du réseau TESTA vers le serveur central de messagerie de TESTA. Ce serveur central de TESTA les réexpédiera alors vers le serveur de messagerie spécifique du domaine local, en utilisant les adresses électroniques dudit domaine local. Grâce à une telle procédure de réexpédition des messages, les informations sensibles qu'ils contiennent ne transitent que par l'infrastructure de réseau fermée qui couvre l'ensemble de l'Europe, et non par l'internet, qui n'est pas un environnement sûr.

Sur les sites de chaque État membre, il faut créer des sous-domaines (indiqués en caractères gras et italiques ) selon la syntaxe qui suit:

« type-d'-application.pruem.code-de-l'État-membre .eu-admin.net», où:

«code-de-l'État-membre» est l'un des codes à deux lettres des États membres (par exemple AT, BE, etc.)

« type-d'-application» est l'une des deux valeurs qui suivent: DNA et FP.

Sur la base de la syntaxe décrite ci-dessus, les sous-domaines des États membres sont indiqués dans le tableau qui suit:

EM Sous-domaines Notes BE dna.pruem.be.eu-admin.net Création d'un lien local sécurisé vers le point d'accès à TESTA existant fp.pruem.be.eu-admin.net BG dna.pruem.bg.eu-admin.net fp.pruem.bg.eu-admin.net CZ dna.pruem.cz.eu-admin.net fp.pruem.cz.eu-admin.net DK dna.pruem.dk.eu-admin.net fp.pruem.dk.eu-admin.net DE dna.pruem.de.eu-admin.net Utilisation des points d'accès nationaux à TESTA II existants fp.pruem.de.eu-admin.net EE dna.pruem.ee.eu-admin.net fp.pruem.ee.eu-admin.net IE dna.pruem.ie.eu-admin.net fp.pruem.ie.eu-admin.net EL dna .pruem.el.eu-admin.net fp .pruem.el.eu-admin.net ES dna.pruem.es.eu-admin.net Utilisation du point d'accès national à TESTA II existant fp.pruem.es.eu-admin.net FR dna.pruem.fr.eu-admin.net Utilisation du point d'accès national à TESTA II existant fp.pruem.fr.eu-admin.net IT dna.pruem.it.eu-admin.net fp.pruem.it.eu-admin.net CY dna.pruem.cy.eu-admin.net fp.pruem.cy.eu-admin.net LV dna.pruem.lv.eu-admin.net fp.pruem.lv.eu-admin.net LT dna.pruem.lt.eu-admin.net fp.pruem.lt.eu-admin.net LU dna.pruem.lu.eu-admin.net Utilisation du point d'accès national à TESTA II existant fp.pruem.lu.eu-admin.net HU dna.pruem.hu.eu-admin.net fp.pruem.hu.eu-admin.net MT dna.pruem.mt.eu-admin.net fp.pruem.mt.eu-admin.net NL dna.pruem.nl.eu-admin.net Projet de création d'un nouveau point d'accès à TESTA II au Nederlands Forensisch Instituut (NFI) fp.pruem.nl.eu-admin.net AT dna.pruem.at.eu-admin.net Utilisation du point d'accès national à TESTA II existant fp.pruem.at.eu-admin.net PL dna.pruem.pl.eu-admin.net fp.pruem.pl.eu-admin.net PT dna.pruem.pt.eu-admin.net …… fp.pruem.pt.eu-admin.net …… RO dna.pruem.ro.eu-admin.net fp.pruem.ro.eu-admin.net SI dna.pruem.si.eu-admin.net …… fp.pruem.si.eu-admin.net …… SK dna.pruem.sk.eu-admin.net fp.pruem.sk.eu-admin.net FI dna.pruem.fi.eu-admin.net [À insérer] fp.pruem.fi.eu-admin.net SE dna.pruem.se.eu-admin.net fp.pruem.se.eu-admin.net UK dna.pruem.uk.eu-admin.net fp.pruem.uk.eu-admin.net

CHAPITRE 2: Échange de données dactyloscopiques (document de contrôle des interfaces)

L'objet du présent document de contrôle des interfaces est de définir les besoins en ce qui concerne l'échange d'informations dactyloscopiques entre les fichiers automatisés d'empreintes digitales (FAED) des États membres. Il repose sur la norme ANSI/NIST-ITL 1-2000 (INT-I, version 4.22b), telle que mise en œuvre par Interpol.

Cette version couvre l'ensemble des définitions de base des enregistrements logiques de types 1, 2, 4, 9, 13 et 15 nécessaires pour le traitement dactyloscopique fondé sur les images et les points caractéristiques (ou minuties).

1. Aperçu de la teneur des fichiers

Un fichier dactyloscopique se compose de plusieurs enregistrements logiques. La norme ANSI/NIST - ITL1 - 2000 définit seize types d'enregistrements logiques. Chaque enregistrement est séparé du suivant par un séparateur ASCII approprié. Il en va de même à l'intérieur des enregistrements, pour chaque zone et chaque sous-zone.

Seuls six types d'enregistrements sont utilisés pour l'échange d'informations entre l'agence expéditrice et l'agence destinataire:

Type 1 → en-tête de fichier Type 2 → descriptif Type 4 → image à haute résolution avec nuances de gris Type 9 → points caractéristiques Type 13 → image de trace latente à résolution variable Type 15 → images d'empreintes palmaires à résolution variable

1.1. Type 1 — en-tête de fichier

L'enregistrement «en-tête de fichier» contient des informations relatives au routage du message et des indications sur la structure du reste du fichier. Il définit également le type d'opération, qui peut appartenir à l'une des grandes catégories décrites ci-après.

1.2. Type 2 — descriptif (défini par l'utilisateur)

L'enregistrement «descriptif» contient diverses informations textuelles intéressant le service expéditeur et le service destinataire.

1.3. Type 4 — image à haute résolution avec nuances de gris

Ce type d'enregistrement est utilisé pour la transmission d'images dactyloscopiques à haute résolution avec niveaux de gris (valeurs exprimées sur huit bits), scannées à une résolution de 500 pixels par pouce. Les images dactyloscopiques seront compressées au moyen de l'algorithme WSQ, le rapport de compression ne dépassant pas 15:1. Il convient de ne pas utiliser d'autre algorithme de compression ni d'image non compressée.

1.4. Type 9 — points caractéristiques

L'enregistrement de type 9 sert à transmettre des informations sur les lignes ou les points caractéristiques, en partie dans le but d'éviter la répétition des calculs de codes FAED et en partie afin de transmettre des codes plutôt que des images, les codes étant moins «volumineux» que les images correspondantes.

1.5. Type 13 — image de trace latente à résolution variable

Cet enregistrement est utilisé pour échanger des images à résolution variable de traces latentes de doigts et de paumes, ainsi que du texte. Les images doivent être numérisées à une résolution de 500 ppp et comporter 256 niveaux de gris. Si l'image est de bonne qualité, elle doit être compressée au moyen de l'algorithme WSQ. Au besoin, l'image peut être améliorée au-delà de 500 ppp et des 256 niveaux de gris prévus, sur accord bilatéral. Dans ce cas, il est fortement recommandé d'utiliser le format JPEG 2000 (voir l'appendice 7).

1.6. Type 15 — image d'empreinte palmaire à résolution variable

L'enregistrement de type 15 est utilisé pour échanger des images d'empreintes palmaires à résolution variable, ainsi que du texte. Les images doivent être numérisées à 500 ppp et comporter 256 niveaux de gris. Toutes les images d'empreintes palmaires doivent être compressées au moyen de l'algorithme WSQ, ce qui permet de réduire le volume de données. Au besoin, l'image peut être améliorée au-delà de 500 ppp et des 256 niveaux de gris prévus, sur accord bilatéral. Dans ce cas, il est fortement recommandé d'utiliser le format JPEG 2000 (voir l'appendice 7).

2. Format des enregistrements

Un fichier d'opération comprend un ou plusieurs enregistrements logiques. Chaque enregistrement logique se compose d'une ou de plusieurs zones compatibles avec le type de l'enregistrement. Chaque zone peut contenir un ou plusieurs éléments d'information dont on spécifie la valeur (une seule). C'est l'ensemble des éléments d'information dont se compose une zone qui définissent la valeur de celle-ci. Une zone peut également contenir un ou plusieurs éléments d'information regroupés et répétés un certain nombre de fois. Un tel groupe d'informations est appelé «sous-zone». Une zone peut donc comporter plusieurs sous-zones.

2.1. Les séparateurs

En ce qui concerne les enregistrements logiques à zones balisées, les séparateurs utilisés sont les quatre séparateurs ASCII. Ces codes peuvent servir à délimiter les éléments d'information figurant dans une zone ou dans une sous-zone, les zones elles-mêmes ou les multiples occurrences des sous-zones. Ils sont définis dans la norme ANSI X3.4. Ils servent à délimiter et à qualifier logiquement les informations. Il s'agit, par ordre d'importance, du séparateur de fichier FS («File Separator»), du séparateur de groupe GS («Group Separator»), du séparateur d'enregistrement RS («Record Separator») et du séparateur d'unité US («Unit Separator»). On trouvera dans le tableau 1 ci-après le récapitulatif de l'utilisation de ces codes dans le cadre de la présente norme.

Les séparateurs donnent une indication sur le type de données qui les suivent. Le séparateur US sépare des éléments d'information à l'intérieur d'une zone ou d'une sous-zone; il signale que l'élément d'information suivant appartient à cette zone ou sous-zone. Le séparateur RS sépare des sous-zones; sa présence signale le début d'un énième élément d'information répété. Le séparateur GS sépare des zones d'enregistrement; il signale le début d'une autre zone avant le numéro d'identification de zone. De même, le séparateur FS signale le début d'un autre enregistrement logique.

Ces quatre codes n'ont de signification que lorsqu'ils sont utilisés comme séparateurs dans du texte ASCII. Ils n'ont aucune signification dans des enregistrements ou dans des zones binaires; ils font alors partie des données échangées.

Une zone ou un élément d'information ne doit normalement pas être vide. Par conséquent, on ne doit trouver qu'un séparateur entre deux éléments d'information. Les exceptions à cette règle sont les cas où les données sont indisponibles, manquantes ou facultatives, et que le traitement de l'opération concernée ne dépend pas de la présence de ces données. Dans ces cas, on trouvera plusieurs séparateurs côte à côte au lieu de données fictives entre des séparateurs.

Pour la définition d'une zone comportant trois éléments d'information, on appliquera ce qui suit. Si les données manquent pour spécifier le deuxième élément d'information, on aura deux séparateurs US entre le premier et le troisième élément d'information. Si les données manquent pour spécifier le deuxième et le troisième éléments d'information, il faudra introduire trois séparateurs: deux séparateurs US plus le séparateur indiquant la fin de la zone ou de la sous-zone. De façon générale, si un ou plusieurs éléments d'information obligatoires ou facultatifs sont indisponibles pour une zone ou une sous-zone, il faut introduire le nombre voulu de séparateurs.

Il est possible de trouver côte à côte plusieurs combinaisons de deux ou plus des quatre séparateurs utilisables. Lorsque des données sont manquantes ou indisponibles pour un élément d'information, une sous-zone ou une zone d'enregistrement logique, il doit y avoir un séparateur de moins que le nombre d'éléments d'information, de sous-zones ou de zones requis.

Tableau 1: séparateurs utilisés

Code Type Fonction Valeur hexadécimale Valeur décimale US Unit Separator Sépare des éléments d'information 1F 31 RS Record Separator Sépare des sous-zones 1E 30 GS Group Separator Sépare des zones 1D 29 FS File Separator Sépare des enregistrements logiques 1C 28

2.2. Format des enregistrements

En ce qui concerne les enregistrements logiques à zones balisées, chaque zone utilisée doit être numérotée conformément à la présente norme et présenter le format suivant: numéro de type de l'enregistrement logique suivi d'un point (».»), numéro de zone suivi d'un deux-points (»:»), données compatibles avec cette zone. Le numéro de la zone balisée peut être n'importe quel nombre d'un à neuf chiffres, ce numéro devant être placé entre le point et le deux-points. Ce numéro est interprété comme un entier non signé. Cela implique qu'un numéro de zone tel que «2 123:» équivaut au numéro de zone «2.000000123» et est interprété de la même façon.

Dans les exemples donnés tout au long de ce document, on utilisera un nombre à trois chiffres pour désigner les zones contenues dans chacun des enregistrements logiques à zones balisées décrits. Les numéros de zones se présentent sous la forme: «TT.xxx», «TT» représentant le type d'enregistrement à un ou deux caractères suivi d'un point. Les trois caractères suivants correspondent au numéro de zone suivi d'un deux-points. Les caractères ASCII ou les données relatives à l'image arrivent après le deux-points.

Les enregistrements logiques de type 1 et 2 contiennent uniquement des zones de texte ASCII. La première zone ASCII de chacun de ces types d'enregistrement permet d'enregistrer la longueur totale de l'enregistrement (qui prend en compte les numéros de zones, les deux-points et les séparateurs). Le séparateur et caractère de contrôle «FS» (qui marque la fin d'un enregistrement logique ou d'une opération) suit le dernier octet des données ASCII et est pris en compte dans le calcul de la longueur de l'enregistrement.

À la différence des enregistrements à zones balisées, les enregistrements de type 4 ne contiennent que des données binaires enregistrées comme des zones binaires ordonnées à longueur fixe. La longueur totale de l'enregistrement est enregistrée dans la première zone binaire à quatre octets de chaque enregistrement. Pour ces enregistrements binaires, ni le numéro d'enregistrement suivi de son point ni le numéro d'identification de champ et son deux-points ne sont pris en compte. En outre, les longueurs respectives de ces six enregistrements étant soit fixes, soit à spécifier, aucun des quatre séparateurs («US», «RS», «GS» ou «FS») n'est interprété autrement que comme données binaires. En ce qui concerne ces enregistrements binaires, le caractère «FS» ne doit pas être utilisé comme séparateur d'enregistrements ou caractère de fin d'opération.

3. Enregistrement logique de type 1: en-tête de fichier

L'enregistrement «en-tête de fichier» décrit la structure du fichier et en précise le type. Il donne également d'autres informations importantes. Le jeu de caractères utilisé dans l'enregistrement logique de type 1 est uniquement le code ANSI à sept bits pour l'échange d'informations.

3.1. Les différentes zones de l'enregistrement logique de type 1

3.1.1. Zone 1.001: LEN (Logical Record Length — longueur de l'enregistrement logique)

Cette zone définit le nombre d'octets total de l'enregistrement. Elle commence par «1 001:», suivi de la longueur totale de l'enregistrement, en comptant chaque caractère de chaque zone et les séparateurs.

3.1.2. Zone 1.002: VER (Version Number — numéro de version)

Afin que les utilisateurs sachent sous quelle version de la norme ANSI/NIST ils travaillent, cette zone de quatre octets spécifie le numéro de la version utilisée par le logiciel sous lequel le fichier a été créé ou par le système sur lequel il a été créé. Les deux premiers octets spécifient le numéro de version proprement dit et les deux suivants le numéro de révision: par exemple, la norme 1986 d'origine est considérée comme la première version, spécifiée «0100», et la norme actuelle comme la deuxième version, spécifiée «0300».

3.1.3. Zone 1.003: CNT (File Content — contenu du fichier)

Cette zone contient la liste de tous les enregistrements du fichier, avec leur type et suivant l'ordre dans lequel ils apparaissent dans le fichier logique. Elle peut comporter une ou plusieurs sous-zones. Chaque sous-zone contient deux éléments d'information décrivant un enregistrement logique du fichier. Les sous-zones sont spécifiées suivant l'ordre dans lequel les enregistrements sont enregistrés et transmis.

Le premier élément d'information de la première sous-zone est 1 (pour «enregistrement de type 1»). Le deuxième élément d'information est le nombre des autres enregistrements contenus dans le fichier. Ce nombre est égal au total des sous-zones restantes de la zone 1 003.

Chacune des sous-zones restantes est associée à un enregistrement du fichier, et l'ordre des sous-zones correspond à l'ordre des enregistrements. Chaque sous-zone contient deux éléments d'information. Le premier élément correspond au type de l'enregistrement. Le deuxième élément est l'IDC de l'enregistrement. Les deux éléments d'information présents dans chaque sous-zone sont séparés par le caractère «US».

3.1.4. Zone 1.004: TOT (Type of Transaction — type d'opération)

Cette zone contient un code mnémonique de trois lettres qui désigne le type d'opération. Ces codes sont différents de ceux utilisés dans d'autres versions de la norme ANSI/NIST.

CPS (Criminal Print-to-Print Search — comparaison d'empreintes dans le cadre d'une infraction) correspond à une recherche de concordance entre des empreintes relevées dans le cadre d'une infraction et celles enregistrées dans une base de données. Les empreintes de la personne doivent figurer dans le fichier sous la forme d'une image compressée au moyen de l'algorithme WSQ.

En cas de non-concordance, les enregistrements logiques ci-après seront renvoyés:

— 1 enregistrement de type 1,

— 1 enregistrement de type 2.

En cas de concordance, les enregistrements logiques ci-après seront renvoyés:

— 1 enregistrement de type 1,

— 1 enregistrement de type 2,

— 1-14 enregistrement(s) de type 4.

Le TOT CPS est résumé au tableau A.6.1 (annexe 6).

PMS (Print-to-Latent Search — comparaison empreintes/traces) correspond à une recherche de concordance entre un ensemble d'empreintes et les traces non identifiées enregistrées dans une base de données. La réponse comportera le résultat (concordance ou non-concordance) de la recherche effectuée par le FAED destinataire. S'il y a plusieurs traces non identifiées, plusieurs opérations SRE seront générées, chaque opération concernant une trace latente. Les empreintes de la personne doivent figurer dans le fichier sous la forme d'une image compressée au moyen de l'algorithme WSQ.

En cas de non-concordance, les enregistrements logiques ci-après seront renvoyés:

— 1 enregistrement de type 1,

— 1 enregistrement de type 2.

En cas de concordance, les enregistrements logiques ci-après seront renvoyés:

— 1 enregistrement de type 1,

— 1 enregistrement de type 2,

— 1 enregistrement de type 13.

Le TOT PMS est résumé au tableau A.6.1 (annexe 6).

MPS (Latent-to-Print Search — comparaison trace/empreintes) correspond à une recherche de concordance entre une trace relevée et les empreintes enregistrées dans une base de données. Les points caractéristiques et l'image correspondant à la trace (compressée au moyen de l'algorithme WSQ) doivent figurer dans le fichier.

En cas de non-concordance, les enregistrements logiques ci-après seront renvoyés:

— 1 enregistrement de type 1,

— 1 enregistrement de type 2.

En cas de concordance, les enregistrements logiques ci-après seront renvoyés:

— 1 enregistrement de type 1,

— 1 enregistrement de type 2,

— 1 enregistrement de type 4 ou de type 15.

Le TOT MPS est résumé au tableau A.6.4 (annexe 6).

MMS (Latent-to-Latent Search — comparaison trace/traces): le fichier contient une trace qu'il s'agit de comparer aux traces non identifiées enregistrées dans une base de données, afin d'établir s'il existe des liens entre diverses scènes de crime. Les points caractéristiques et l'image correspondant à la trace (compressée au moyen de l'algorithme WSQ) doivent figurer dans le fichier.

En cas de non-concordance, les enregistrements logiques ci-après seront renvoyés:

— 1 enregistrement de type 1,

— 1 enregistrement de type 2.

En cas de concordance, les enregistrements logiques ci-après seront renvoyés:

— 1 enregistrement de type 1,

— 1 enregistrement de type 2,

— 1 enregistrement de type 13.

Le TOT MMS est résumé au tableau A.6.4 (annexe 6).

SRE (Search Results — résultats de recherche): cette opération est générée par l'agence destinataire en réponse à des requêtes dactyloscopiques. La réponse comporte le résultat (concordance ou non-concordance) de la recherche effectuée par le FAED destinataire. S'il y a plusieurs candidats, plusieurs opérations SRE seront générées, chaque opération concernant un candidat.

Le TOT SRE est résumé au tableau A.6.2 (annexe 6).

ERR (erreur): cette opération est générée par le FAED destinataire pour indiquer qu'une erreur s'est produite. Elle comporte un message (ERM) indiquant l'erreur détectée. Les enregistrements logiques ci-après seront renvoyés:

— 1 enregistrement de type 1,

— 1 enregistrement de type 2.

Le TOT ERR est résumé au tableau A.6.3 (annexe 6).

Tableau 2: types d'enregistrements spécifiés dans les différents types d'opérations

Type d'opération Type d'enregistrement logique 1 2 4 9 13 15 CPS O O O — — — SRE O O C — (C en cas de concordance de traces) C C MPS O O — O (1*) O — MMS O O — O (1*) O — PMS O O O* — — O* ERR O O — — — —

O = obligatoire O* = un seul des deux types d'enregistrements peut être inclus F = facultatif C = à condition que des données soient disponibles — = interdit 1* = Pour les systèmes anciens uniquement, à condition que des données soient disponibles

3.1.5. Zone 1.005: DAT (Date of Transaction — date d'opération)

Cette zone indique la date à laquelle l'opération a été lancée. Elle doit être au format ISO, c'est-à-dire: AAAAMMJJ

AAAA correspondant à l'année, MM au mois et JJ au jour. Les éléments à un seul chiffre doivent être complétés par des zéros à gauche. Par exemple, «19931004» signifie «4 octobre 1993».

3.1.6. Zone 1.006: PRY (Priority — priorité)

Cette zone facultative définit le niveau de priorité de la demande, qui peut varier de 1 à 9. 1 est la priorité la plus élevée et 9 la priorité la plus basse. Les opérations ayant la priorité 1 sont traitées immédiatement.

3.1.7. Zone 1.007: DAI (Destination Agency Identifier — identificateur du service destinataire)

Cette zone indique le service destinataire de la demande.

Elle comporte deux éléments d'information et se présente sous le format suivant: CC/service.

CC correspond au code de pays membre d'Interpol, composé de deux caractères alphanumériques, tel qu'il est défini par la norme ISO 3166. Service désigne le service destinataire, en trente-deux caractères alphanumériques au maximum.

3.1.8. Zone 1.008: ORI (Originating Agency Identifier — identificateur du service expéditeur)

Cette zone désigne l'expéditeur du fichier et se présente sous le même format que DAI (zone 1 007).

3.1.9. Zone 1.009: TCN (Transaction Control Number — référence de l'opération)

Cette référence est générée par l'ordinateur et doit se présenter sous le format suivant: AASSSSSSSSC,

AA correspondant à l'année de l'opération, SSSSSSSS à un numéro de série à huit chiffres et C à un caractère de contrôle calculé au moyen des formules exposées dans l'annexe 2.

En l'absence de TCN, la partie AASSSSSSSS est complétée par des zéros et C est calculé normalement.

3.1.10. Zone 1.010: TCR (Transaction Control Response — référence de la réponse)

Dans le cas d'une réponse à une demande, cette zone facultative contient la référence de la demande. Elle se présente donc sous le même format que TCN (zone 1 009).

3.1.11. Zone 1.011: NSR (Native Scanning Resolution — résolution de numérisation du système demandeur)

Cette zone définit la résolution normale de numérisation du système de l'auteur de la demande. La résolution est spécifiée sous la forme de deux chiffres suivis de la marque décimale et de deux autres chiffres.

Pour l'ensemble des opérations effectuées au titre de la décision 2008/615/JAI, la résolution est de 500 pixels/pouce ou 19,68 pixels/mm.

3.1.12. Zone 1.012: NTR (Nominal Transmitting Resolution — résolution de transmission)

Cette zone de cinq octets spécifie la résolution de transmission des images. Elle est exprimée en pixels/mm, sous le même format que NSR (zone 1 011).

3.1.13. Zone 1.013: DOM (Domain Name — nom de domaine)

Cette zone obligatoire indique le nom de domaine de la version utilisée pour formater l'enregistrement de type 2 (défini par l'utilisateur). Elle comprend deux éléments d'informations et se présente comme suit: «INT-I{US}4.21{GS}».

3.1.14. Zone 1.014: GMT (Greenwich Mean Time — heure de Greenwich)

Cette zone obligatoire permet de préciser la date et l'heure en temps universel. Elle s'ajoute à la date «en temps local» indiquée dans la zone 1 005 (DAT). Le fait de spécifier la zone GMT élimine les incohérences qui peuvent se produire lorsqu'une opération et sa réponse sont transmises entre deux sites séparés par plusieurs fuseaux horaires. Le temps universel permet de spécifier une date et une heure en temps universel sur 24 heures indépendamment des fuseaux horaires. Cette zone se présente sous la forme d'une chaîne de quinze caractères au format suivant: «SSAAMMJJHHMMSSZ». SSCAA représente l'année de l'opération, MM représente le mois, JJ représente le jour, HH représente l'heure, MM représente les minutes, SS représente les secondes. La date complète ne peut pas être postérieure à la date en cours.

4. Enregistrement logique de type 2: descriptif

La majeure partie de l'enregistrement «descriptif» n'est pas définie par la norme ANSI/NIST. Cet enregistrement contient des informations spécifiques intéressant les services qui envoient ou reçoivent le fichier. Afin que les systèmes de reconnaissance automatique des empreintes digitales puissent communiquer entre eux sans problèmes, il est nécessaire que seules les zones décrites ci-après soient définies. Leur caractère obligatoire ou facultatif est précisé, et leur structure décrite.

4.1. Les différentes zones de l'enregistrement logique de type 2

4.1.1. Zone 2.001: LEN (Logical Record Length — longueur de l'enregistrement logique)

Cette zone obligatoire définit la longueur de l'enregistrement de type 2: elle indique le nombre total d'octets, en comptant tous les caractères de toutes les zones et les séparateurs.

4.1.2. Zone 2.002: IDC (Image Designation Character — caractère d'identification de l'image)

Cette zone obligatoire contient la représentation ASCII de l'IDC spécifié dans la zone CNT de l'enregistrement de type 1 (zone 1 003).

4.1.3. Zone 2.003: SYS (System Information — version d'INT-I utilisée)

Cette zone obligatoire est d'une longueur de quatre octets. Elle indique d'après quelle version d'INT-I est défini cet enregistrement de type 2.

Les deux premiers octets spécifient le numéro de version et les deux suivants le numéro de révision: par exemple, «version 4 révision 22» seraient spécifiés sous la forme 0422.

4.1.4. Zone 2.007: CNO (Case Number — numéro d'affaire)

C'est le numéro attribué par le service de dactyloscopie concerné à un ensemble de traces latentes relevées sur les lieux d'une infraction. Il doit être spécifié sous le format suivant: CC/numéro.

CC est le code de pays membre d'Interpol, en deux caractères alphanumériques. numéro est défini en fonction des exigences locales; il peut comporter jusqu'à trente-deux caractères alphanumériques.

Cette zone permet au système d'identifier les traces associées à une infraction donnée.

4.1.5. Zone 2.008: SQN (Sequence Number — numéro de la série de traces)

Ce numéro identifie chaque série de traces dans le cadre d'une affaire donnée. Il peut comporter jusqu'à quatre chiffres. Une série est constituée d'une trace ou d'un ensemble de traces regroupées à des fins de classement et/ou de recherche. Cette définition implique qu'il faut attribuer un numéro de série même à une seule trace.

Associée à MID (zone 2 009), cette zone peut servir à identifier une trace donnée dans une série.

4.1.6. Zone 2.009: MID (Latent Identifier — identificateur de trace)

Désigne une trace donnée dans une série au moyen d'une seule lettre: «A» désigne la première trace, «B» la deuxième, etc. jusqu'à «ZZ». Cette zone est utilisée comme SQN (zone 2 008).

4.1.7. Zone 2.010: CRN (Criminal Reference Number — numéro de référence du malfaiteur)

C'est le numéro de référence unique attribué par le service d'un pays à un individu qui est accusé pour la première fois d'avoir commis une infraction. Dans un pays donné, un individu ne peut avoir qu'un seul CRN et ce CRN ne peut pas être le même que celui d'un autre. Cependant, le même individu peut avoir des CRN différents dans différents pays (repérables par le code du pays).

La zone CRN se présente sous le format suivant: CC/numéro

CC est le code de pays selon la norme ISO 3166, en deux caractères alphanumériques; numéro est défini en fonction des règles en vigueur dans le pays où se trouve le service émetteur de la demande; il peut comporter jusqu'à trente-deux caractères alphanumériques.

En ce qui concerne les opérations effectuées au titre de la décision 2008/615/JAI, cette zone sera utilisée pour le numéro national de référence du malfaiteur attribué par le service expéditeur et lié aux images figurant dans les enregistrements logiques de types 4 ou 5.

4.1.8. Zone 2.012: MN1 (Miscellaneous Identification Number — numéro d'identification 1)

Cette zone contient le CRN (zone 2 010) transmis par une opération CPS ou PMS, sans le code du pays.

4.1.9. Zone 2.013: MN2 (Miscellaneous Identification Number — numéro d'identification 2)

Cette zone contient le CNO (zone 2 007) transmis par une opération MPS ou MMS, sans le code du pays.

4.1.10. Zone 2.014: MN3 (Miscellaneous Identification Number — numéro d'identification 3)

Cette zone contient le SQN (zone 2 008) transmis par une opération MPS ou MMS.

4.1.11. Zone 2.015: MN4 (Miscellaneous Identification Number — numéro d'identification 4)

Cette zone contient le MID (zone 2 009) transmis par une opération MPS ou MMS.

4.1.12. Zone 2.063: INF (Additional Information — informations complémentaires)

En cas d'opération SRE en réponse à une demande PMS, cette zone donne des informations sur le doigt ayant entraîné la concordance éventuelle. Le format de cette zone est le suivant:

NN, où NN est le code à deux chiffres correspondant à la position du doigt, tel qu'indiqué au tableau 5.

Dans tous les autres cas, cette zone est facultative. Elle comprend trente-deux caractères alphanumériques et peut donner des informations complémentaires sur la demande.

4.1.13. Zone 2.064: RLS (Respondents List — liste des réponses)

Cette zone contient au minimum deux sous-zones. La première indique le type de recherche qui a été effectuée, spécifié à l'aide du code de trois lettres utilisé dans TOT (zone 1 004). La deuxième sous-zone contient un seul caractère: «I» s'il y a correspondance (HIT), ou «N» si aucune correspondance n'a été trouvée (NOHIT). La troisième sous-zone contient le numéro de série de la proposition et le nombre total de propositions, ces deux éléments d'information étant séparés par une barre oblique. Il est transmis autant de messages que de propositions.

En cas de correspondance possible (HIT), la quatrième sous-zone contient une note, d'une longueur maximum de six chiffres. Si cette correspondance a été vérifiée, la sous-zone a la valeur «999999».

Exemple: «CPS{RS}I{RS}001/005{RS}10205{GS}»

Si le système FAED distant n'attribue pas de note, c'est la note «0» qui est attribuée.

4.1.14. Zone 2.074: ERM (Status/Error Message Field — message d'état/d'erreur)

Cette zone contient les messages d'erreur qui résultent des opérations; ces messages seront transmis à l'auteur de la demande dans le cadre d'une opération ERR.

Tableau 3: messages d'erreur

Code numérique (1-3) Signification (5-128) 003 ERREUR: ACCÈS NON AUTORISÉ 101 Zone obligatoire manquante 102 Type d'enregistrement incorrect 103 Zone non définie 104 Nombre supérieur au maximum autorisé 105 Nombre de sous-zones incorrect 106 Longueur de zone insuffisante 107 Longueur de zone excessive 108 La zone doit contenir une valeur numérique 109 Valeur numérique trop faible dans la zone 110 Valeur numérique trop élevée dans la zone 111 Caractère incorrect 112 Date incorrecte 115 Valeur d'élément incorrecte 116 Type d'opération incorrect 117 Données de l'enregistrement incorrectes 201 ERREUR: TCN INCORRECT 501 ERREUR: QUALITÉ DES EMPREINTES INSUFFISANTE 502 ERREUR: EMPREINTES MANQUANTES 503 ERREUR: ÉCHEC DU CONTRÔLE DE LA SÉQUENCE D'EMPREINTES DIGITALES 999 ERREUR: AUTRE. POUR PLUS DE DÉTAILS, ADRESSEZ-VOUS AU SERVICE DESTINATAIRE

Messages d'erreur numérotés de 100 à 199:

Ces messages d'erreur concernent la conformité des enregistrements aux critères définis par la norme ANSI/NIST. Ils sont définis de la façon suivante:

<code_erreur 1>: IDC <nombre_idc 1> FIELD <id_zone 1> <texte dynamique 1> LF

<code_erreur 2>: IDC <nombre_idc 2> FIELD <id_zone 2> <texte dynamique 2>…

où:

— code_erreur est un code unique correspondant à une explication donnée (voir le tableau 3),

— id_zone est le numéro de la zone incorrecte, tel qu'il est défini dans la norme ANSI/NIST (par exemple, 1.01, 2 001, ...). Il est défini sous la forme <type_enregistrement>.<id_zone>.<id_sous-zone>,

— texte dynamique est une description dynamique plus détaillée de l'erreur,

— LF est un code d'avance ligne séparant les différentes erreurs,

— pour les enregistrements de type 1, le DCI a la valeur «-1».

Exemple:

201: IDC - 1 FIELD 1009 WRONG CONTROL CHARACTER {LF} 115: IDC 0 FIELD 2003 INVALID SYSTEM INFORMATION

Cette zone est obligatoire pour les opérations ERR.

4.1.15. Zone 2.320: ENC (Expected Number of Candidates — nombre de propositions attendues)

Cette zone contient le nombre maximal de propositions attendues, à des fins de vérification, par le service demandeur. La valeur d'ENC ne doit pas être supérieure aux valeurs définies au tableau 11.

5. Enregistrement logique de type 4: image à haute résolution avec nuances de gris

L'enregistrement logique de type 4 est de type binaire, et non de type ASCII. Chaque zone a donc une position spécifique dans l'enregistrement, ce qui implique que toutes les zones sont obligatoires. La norme permet de définir la taille et la résolution de l'image dans l'enregistrement même. Les images d'empreintes digitales contenues dans les enregistrements de type 4 doivent avoir une résolution de transmission de 500 à 520 pixels par pouce. Pour les nouveaux systèmes, la résolution minimale est de 500 pixels par pouce (soit 19,68 pixels par mm). INT-I prévoit une résolution de 500 pixels par pouce, ce qui n'empêche pas des systèmes semblables de communiquer entre eux à une autre résolution, dans la limite de 500 à 520 pixels par pouce.

5.1. Les différentes zones de l'enregistrement logique de type 4

5.1.1. Zone 4.001: LEN (Logical Record Length — longueur de l'enregistrement logique)

Zone de quatre octets définissant la longueur de l'enregistrement logique de type 4, c'est-à-dire son nombre total d'octets, en comptant chaque octet de chaque zone.

5.1.2. Zone 4.002: IDC (Image Designation Character — caractère d'identification de l'image)

Zone d'un octet contenant la représentation en binaire de l'IDC spécifié dans l'enregistrement d'en-tête.

5.1.3. Zone 4.003: IMP (Impression Type — méthode d'obtention de l'image)

Zone d'un octet constituant le sixième octet de l'enregistrement.

Tableau 4: méthodes d'obtention des images d'empreintes digitales

Code Description 0 Numérisation directe d'empreinte à plat 1 Numérisation directe d'empreinte roulée 2 Numérisation d'empreinte à plat à partir d'un support papier 3 Numérisation d'empreinte roulée à partir d'un support papier 4 Photographie numérique de trace latente 5 Reproduction manuelle agrandie de trace latente 6 Photo argentique de trace latente 7 Transfert de trace latente 8 Relevé à l'aide d'un lecteur magnétique 9 Inconnu

5.1.4. Zone 4.004: FGP [(Finger Position — doigt(s) concerné(s)]

Zone d'une longueur fixe de six octets occupant les octets 7 à 12 de l'enregistrement de type 4. Elle désigne les doigts concernés, en commençant par l'octet de gauche (le septième). La position connue ou la plus probable du doigt est reprise du tableau 5. On peut spécifier jusqu'à cinq doigts supplémentaires dans les cinq octets restants, de la même façon. Si l'on spécifie moins de cinq doigts, on spécifie l'équivalent binaire de 255 dans les octets non utilisés. Lorsqu'on ne sait pas de quel doigt il s'agit, on spécifie le code 0.

Tableau 5: codes des différents doigts et dimensions de l'image

Doigt Code Largeur maximale (mm) Longueur maximale (mm) Doigt non identifié 0 40,0 40,0 Pouce droit 1 45,0 40,0 Index droit 2 40,0 40,0 Majeur droit 3 40,0 40,0 Annulaire droit 4 40,0 40,0 Auriculaire droit 5 33,0 40,0 Pouce gauche 6 45,0 40,0 Index gauche 7 40,0 40,0 Majeur gauche 8 40,0 40,0 Annulaire gauche 9 40,0 40,0 Auriculaire gauche 10 33,0 40,0 Empreinte à plat du pouce droit 11 30,0 55,0 Empreinte à plat du pouce gauche 12 30,0 55,0 Empreintes à plat des quatre autres doigts de la main droite 13 70,0 65,0 Empreintes à plat des quatre autres doigts de la main gauche 14 70,0 65,0

Pour les traces latentes, seules les valeurs 0 à 10 peuvent être utilisées.

5.1.5. Zone 4.005: ISR (Image Scanning Resolution — résolution de numérisation)

Zone d'un octet constituant le treizième octet de l'enregistrement de type 4. Elle contient 0 si l'image a été scannée à la résolution de 19,68 pixels/mm (500 pixels par pouce). Elle contient 1 si l'image a été scannée à une autre résolution (information spécifiée dans l'enregistrement d'en-tête).

5.1.6. Zone 4.006: HLL (Horizontal Line Length — longueur de ligne)

Cette zone occupe les octets 14 et 15 de l'enregistrement de type 4. Elle spécifie le nombre de pixels de chaque ligne de numérisation. Le premier octet est le plus significatif.

5.1.7. Zone 4.007: VLL (Vertical Line Length – longueur de colonne)

Cette zone occupe les octets 16 et 17 de l'enregistrement de type 4. Elle spécifie le nombre de colonnes de numérisation de l'image. Le premier octet est le plus significatif.

5.1.8. Zone 4.008: GCA (Gray-scale Compression Algorithm — algorithme de compression de l'échelle de gris)

Zone d'un octet spécifiant l'algorithme de compression de l'échelle de gris utilisé pour l'image. Pour la mise en œuvre en question, le code binaire 1 signifie que l'algorithme de compression WSQ (annexe 7) a été utilisé.

5.1.9. Zone 4.009: Image (image)

Cette zone contient une suite d'octets représentant l'image. Sa structure dépend évidemment de l'algorithme de compression utilisé.

6. Enregistrement logique de type 9: points caractéristiques

L'enregistrement logique de type 9 contient du texte ASCII décrivant les points caractéristiques (ou minuties) d'une trace latente et les informations qui s'y rapportent. En ce qui concerne les opérations de recherche de trace latente, les enregistrements de type 9 ne sont pas limités en nombre dans un fichier, chaque enregistrement correspondant à une vue différente ou à une trace latente différente.

6.1. Extraction des points caractéristiques

6.1.1. Identification du type de points caractéristiques

La présente norme définit trois numéros d'identification désignant les différents types de points caractéristiques. Le tableau 6 résume la signification de ces numéros d'identification. Le type 1 correspond à un arrêt de ligne. Le type 2 correspond à une bifurcation. Lorsqu'un point caractéristique ne relève pas clairement de l'une des deux catégories ci-dessus mentionnées, il est dit «autre», ce qui correspond au type 0.

Tableau 6: types de points caractéristiques

Type Description 0 Autre 1 Arrêt de ligne 2 Bifurcation

6.1.2. Type et emplacement des points caractéristiques

Afin de mettre les modèles en conformité avec la section 5 de la norme ANSI INCITS 378-2004, on aura recours à la méthode décrite ci-dessous, qui améliore la norme INCITS 378-2004 actuelle, pour déterminer l'emplacement (localisation et direction angulaire) de chaque point caractéristique.

Le positionnement ou la localisation d'un point caractéristique représentant un arrêt (ou terminaison) de ligne (ou crête) est le point situé juste avant l'arrêt de ligne, à l'endroit où la partie commune de la vallée (creux) se sépare en deux branches. Si les trois branches de la vallée (creux) sont réduites à un squelette d'une largeur de 1 pixel, le point caractéristique est le point d'intersection. À l'inverse, la localisation d'un point caractéristique représentant une bifurcation est le point où la partie commune de la crête se sépare en deux branches. Si les trois branches de la crête sont réduites à un squelette d'une largeur de 1 pixel, le point caractéristique est le point d'intersection.

Après conversion de toutes les terminaisons en bifurcations, tous les points caractéristiques de l'image dactyloscopique sont représentés par des bifurcations. Les coordonnées X et Y, exprimées en pixels, de l'intersection des trois branches de chaque point caractéristique, peuvent être formatées directement. À partir de chaque bifurcation des squelettes, il est possible de déterminer la direction des points caractéristiques. Les trois branches de chaque bifurcation doivent être examinées et les terminaisons de chaque branche doivent être déterminées. La figure 6.1.2 illustre les trois méthodes mises en œuvre pour déterminer l'emplacement de la fin d'une branche sur la base d'une résolution de numérisation de 500 ppp.

L'emplacement de la terminaison est établi en fonction de l'événement qui se produit en premier. Le comptage des pixels repose sur une numérisation à la résolution de 500 ppp. Des résolutions de numérisation différentes donneraient des comptages de pixels différents.

— Distance de 0,064 pouce (32e pixel).

— La fin de la branche du squelette qui apparaît à une distance comprise entre 0,02 pouce et 0,064 pouce (entre le 10e et le 32e pixel): les branches les plus courtes ne sont pas utilisées.

— Une deuxième bifurcation apparaît à une distance de moins de 0,064 pouce (avant le 32e pixel).

Figure 6.1.2

L'angle du point caractéristique est déterminé en construisant trois rayons virtuels ayant leur origine au point de bifurcation et s'étendant jusqu'à la fin de chaque branche. Le plus petit des trois angles formé par les rayons est divisé en deux parties égales afin d'indiquer la direction du point caractéristique.

6.1.3. Coordonnées

Les points caractéristiques d'une empreinte digitale sont décrits par un système de coordonnées cartésien. Les coordonnées X et Y des points caractéristiques représentent leur emplacement. L'origine du système de coordonnées est le coin supérieur gauche de l'image originale, X augmentant vers la droite et Y augmentant vers le bas. Les coordonnées X et Y d'un point caractéristique sont représentées en unités de pixels à partir de l'origine. Il y a lieu de noter que l'emplacement de l'origine et les unités de mesure ne sont pas conformes à la convention utilisée dans les définitions du type 9 prévues dans la norme ANSI/NIST-ITL 1-2000.

6.1.4. Direction des points caractéristiques

Les angles sont exprimés selon le format mathématique standard, le degré 0 étant placé à droite et les angles augmentant dans le sens contraire des aiguilles d'une montre. Dans le cas d'un arrêt de ligne, la direction de l'angle est en sens contraire, le long de la ligne; dans le cas d'une bifurcation, la direction de l'angle est vers le centre de la vallée. Cette convention est l'inverse de celle qui est décrite dans les définitions du type 9 dans la norme ANSI/NIST-ITL 1-2000.

6.2. Les différentes zones de l'enregistrement logique de type 9 au format INCITS-378

Toutes les zones de l'enregistrement de type 9 sont enregistrées sous forme de texte ASCII. Aucune valeur binaire n'est autorisée dans ce type d'enregistrement à zones balisées.

6.2.1. Zone 9.001: LEN (Logical Record Length — longueur de l'enregistrement logique)

Cette zone ASCII obligatoire définit la longueur de l'enregistrement logique, c'est-à-dire son nombre total d'octets, en comptant chaque octet de chaque zone.

6.2.2. Zone 9.002: IDC (Image Designation Character — caractère d'identification de l'image)

Cette zone obligatoire de deux octets sert à identifier et à définir l'emplacement des points caractéristiques. L'IDC contenu dans cette zone correspond à celui spécifié dans la zone CNT de l'enregistrement de type 1.

6.2.3. Zone 9.003: IMP (Impression Type — méthode d'obtention de l'image)

Cette zone obligatoire d'un octet décrit la manière dont l'image d'empreinte digitale a été obtenue. Elle contient la valeur ASCII du code approprié (voir tableau 4).

6.2.4. Zone 9.004: FMT (Minutiæ Format — présentation des points caractéristiques)

La mention «U» indique que les points caractéristiques sont présentés selon la norme M1-378. Même si les informations peuvent être encodées conformément à ladite norme M1-378, les zones des enregistrements de type 9 données doivent rester