BILAGA

INNEHÅLLSFÖRTECKNING

KAPITEL 1:

Utbyte av DNA-uppgifter

1.	DNA-relaterade kriminaltekniska frågor, matchningsregler och algoritmer

1.1	DNA-profilernas egenskaper

1.2	Matchningsregler

1.3	Rapporteringsregler

2.	Tabell över medlemsstatskoder

3.	Funktionsanalys

3.1	Systemets tillgänglighet

3.2

Steg 2

4.	Dokument för gränssnittskontroll – DNA

4.1

Inledning

4.2	Definition av XML-strukturen

5.	Tillämpnings-, säkerhets, och kommunikationsarkitektur

5.1

Översikt

5.2	Högnivåarkitektur

5.3	Säkerhetsstandarder och dataskydd

5.4	Protokoll och standarder för krypteringsmekanismen: S/MIME och därmed sammanhörande paket

5.5	Tillämpningsarkitektur

5.6	Protokoll och standarder för tillämpningsarkitekturen

5.7	Kommunikationsmiljö

KAPITEL 2:

Utbyte av fingeravtrycksuppgifter (gränssnittskontrolldokument)

1.	Översikt av filinnehållet

2.	Postformat

3.	Logisk post typ 1: Filhuvud

4.	Logisk post typ 2: Beskrivande text

5.	Logisk post typ 4: Högupplösningsbild i gråskala

6.	Logisk post typ 9: Minutiaepost

7.	Post typ 13: Bilder av latenta avtryck med varierande upplösning

8.	Post typ 15: Bilder av handavtryck med varierande upplösning

9.	Bilagor till kapitel 2

9.1	ASCII-koder för avgränsare

9.2	Beräkning av alfanumeriskt kontrolltecken

9.3	Teckenkoder

9.4	Sammanfattning av transaktioner

9.5	Post typ 1 definitioner

9.6	Post typ 2 definitioner

9.7	Koder för gråskalekomprimering

9.8	E-postspecifikation

KAPITEL 3:

Utbyte av uppgifter i fordonsregister

1.	Gemensam uppsättning uppgifter för automatiserad sökning i fordonsregister

1.1	Definitioner

1.2	Sökning på fordon/ägare/innehavare

2.	Datasäkerhet

2.1

Översikt

2.2	Säkerhetsfunktioner i samband med meddelandeutbytet

2.3	Säkerhetsfunktioner utan samband med meddelandeutbytet

3.	Tekniska villkor för informationsutbytet

3.1	Allmän beskrivning av Eucaris-applikationen

3.2	Funktionella och icke funktionella krav

KAPITEL 4:

Utvärdering

1.	Utvärderingsförfarande i enlighet med artikel 20 (förberedelse av beslut enligt artikel 25.2 i beslut 2008/615/RIF)

1.1	Frågeformulär

1.2	Testkörning

1.3	Utvärderingsbesök

1.4	Rapport till rådet

2.	Utvärderingsförfarande enligt artikel 21

2.1	Statistik och rapport

2.2	Revidering

3.	Expertmöten

KAPITEL 1: Utbyte av DNA-uppgifter

1.   DNA-relaterade kriminaltekniska frågor, matchningsregler och algoritmer

1.1   DNA-profilernas egenskaper

DNA-profilen kan innehålla 24 talpar som representerar allelerna i 24 lokus som också används vid Interpols DNA-förfaranden. Benämningarna för dessa lokus framgår av följande tabell:

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

De sju gråmarkerade lokusen i den översta raden utgör både den nuvarande europeiska standarduppsättningen av lokus (ESS) och Interpols standarduppsättning av lokus (Issol).

Inklusionsregler:

De DNA-profiler som medlemsstaterna gör tillgängliga för sökning och jämförelse samt de DNA-profiler som sänds för sökning och jämförelse måste innehålla minst 6 fullständigt angivna (1) lokus och får innehålla ytterligare lokus eller tomma positioner beroende på tillgång. DNA-personprofiler måste innehålla minst 6 av de 7 ESS-lokusen. För att öka noggrannheten vid matchningen ska alla tillgängliga alleler lagras i den indexerade databasen med DNA-profiler och användas för sökning och jämförelse. Varje medlemsstat ska så snart det är praktiskt möjligt tillämpa varje ny ESS-lokus som antas av EU.

Blandade profiler är inte tillåtna, vilket gör att allel-värdena för varje lokus består av endast två tal. Vid homozygositet kan dessa tal vara lika för ett givet lokus.

Jokertecken och mikrovarianter ska behandlas enligt följande regler:

—	Varje icke-numeriskt värde utom amelogenin som profilen innehåller (t.ex. ”o”, ”f”, ”r”, ”na”, ”nr” eller ”un”) måste automatiskt konverteras till ett jokertecken (*) vid exporten och sökas mot alla.

—	De numeriska värdena ”0”, ”1” or ”99” i profilen måste automatiskt konverteras till ett jokertecken (*) vid exporten och sökas mot alla.

—	Om 3 alleler ges för ett lokus ska den första allelen godtas och de återstående 2 måste automatiskt konverteras till ett jokertecken (*) vid exporten och sökas mot alla.

—	Om jokertecken ges för allel 1 eller 2 ska båda permutationerna av det numeriska värdet för lokuset sökas (”12,*” kan till exempel matcha ”12,14” eller ”9,12”).

—	Mikrovarianter av pentanukleotider (Penta D, Penta E och CD4) ska matchas på följande sätt: — 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.3, x.4, x + 1

—	Mikrovarianter av tetranukleotider (övriga lokus är tetranukleotider) ska matchas på följande sätt: — 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   Matchningsregler

Jämförelsen av två DNA-profiler ska göras på grundval av de lokus för vilka ett par allelvärden är tillgängliga i båda DNA-profilerna. Minst 6 fullständigt angivna lokus (exklusive amelogenin) måste överensstämma mellan de två DNA-profilerna innan ett träffsvar ges.

Full överensstämmelse (Quality 1) definieras som en överensstämmelse där samtliga allelvärden är identiska för de jämförda lokus som finns både i den DNA-profil som används för sökningen och i den sökta DNA-profilen. Nära överensstämmelse definieras som en överensstämmelse där värdet för endast en av samtliga jämförda alleler skiljer sig mellan de två DNA-profilerna (Quality 2, 3 och 4). En nära överensstämmelse godtas endast om det finns minst 6 fullständigt angivna lokus med full överensstämmelse i de två jämförda DNA-profilerna.

Anledningen till en nära överensstämmelse kan vara

—	ett skrivfel vid inmatningen av en av DNA-profilerna i sökningen eller i DNA-databasen,

—	ett fel vid allelbestämningen eller allelanropet under förfarandet för generering av DNA-profilen.

1.3   Rapporteringsregler

Både fulla överensstämmelser, nära överensstämmelser och ”inga träffar” ska rapporteras.

Överensstämmelserapporten ska sändas till den begärande nationella kontaktpunkten samt göras tillgänglig för den tillfrågade nationella kontaktpunkten (så att den kan uppskatta arten av och antal eventuella uppföljande begäranden om ytterligare personuppgifter och annan information med anknytning till den DNA-profil som svarar mot träffen i enlighet med artiklarna 5 och 10 i beslut 2008/615/RIF).

2.   Tabell över medlemsstatskoder

I enlighet med beslut 2008/615/RIF, används ISO 3166-1 tvåställiga bokstavskoder för att upprätta domännamn och andra konfigurationsparametrar som krävs för Prümtillämpningarna för utbyte av DNA-uppgifter via ett slutet nät.

De tvåställiga medlemsstatskoderna enligt ISO 3166-1 alpha-2 är följande:

Medlemsstatens namn	Kod	Medlemsstatens namn	Kod
Belgien	BE	Luxemburg	LU
Bulgarien	BG	Ungern	HU
Tjeckien	CZ	Malta	MT
Danmark	DK	Nederländerna	NL
Tyskland	DE	Österrike	AT
Estland	EE	Polen	PL
Grekland	EL	Portugal	PT
Spanien	ES	Rumänien	RO
Frankrike	FR	Slovakien	SK
Irland	IE	Slovenien	SI
Italien	IT	Finland	FI
Cypern	CY	Sverige	SE
Lettland	LV	Förenade kungariket	UK
Litauen	LT

3.   Funktionsanalys

3.1   Systemets tillgänglighet

En begäran om sökning enligt artikel 3 i beslut 2008/615/RIF bör nå den anropade databasen i kronologisk ankomstordning enligt vilken begäran sändes, medan svaren bör nå den anmodande medlemsstaten inom 15 minuter efter det att begäran inkom.

3.2   Steg 2

När en medlemsstat mottar en rapport om överensstämmelse ansvarar den nationella kontaktpunkten för en jämförelse mellan värdena i den profil som sänds som fråga och värdena i den profil/de profiler som har mottagits som svar i syfte att validera och kontrollera profilens bevisvärde. De nationella kontaktpunkterna kan ta direktkontakter i valideringssyfte.

Förfaranden för rättslig hjälp inleds efter det att en överensstämmelse mellan två profiler validerats, på grundval av ”fullständig överensstämmelse” eller ”nära överensstämmelse” under det automatiska sökningsförfarandet.

4.   Dokument för gränssnittskontroll – DNA

4.1   Inledning

4.1.1   Syfte

Detta kapitel anger kraven för informationsutbytet om DNA-profiler mellan samtliga medlemsstaters DNA-databassystem. Fälten i huvudet är specificerade speciellt för Prüm-utbytet av DNA-uppgifter och datadelen grundar sig på datadelen för DNA-uppgifter enligt XML-schemat för Interpols nätport för utbyte av DNA-uppgifter.

Uppgifterna utbyts genom SMTP (Simple Mail Transfer Protocol) med användning av en central e-postserver som ställs till förfogande av nätoperatören. XML-filen överförs som meddelandetext.

4.1.2   Omfattning

Detta dokument för gränssnittskontroll, ICD, rör endast e-postmeddelandets innehåll. Alla nätspecifika och e-postspecifika områden definieras på ett likartat sätt för att ge en gemensam teknisk grund för utbytet av DNA-uppgifter.

Detta inbegriper

—	formatet för meddelandets ärendefält, så att meddelandena kan bearbetas automatiskt,

—	specifikationer av huruvida kryptering erfordras och i så fall vilka metoder som bör väljas,

—	maximilängd för meddelandena.

4.1.3   XML-struktur och XML-principer

XML-meddelandet är indelat i

—	ett huvud som innehåller information om överföringen, och

—	en datadel som innehåller profilspecifik information samt själva profilen.

Samma XML-schema ska kunna användas för både begäran och svar.

För fullständiga kontroller av oidentifierade DNA-profiler (artikel 4 i beslut 2008/615/RIF) ska det vara möjligt att sända en uppsättning profiler i ett enda meddelande. Det maximala antalet profiler i ett meddelande måste fastställas. Detta antal är beroende av den maximala meddelandestorleken och ska fastställas efter val av e-postserver.

XML-exempel:

<?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> datastrukturen upprepas om fler än en profil sänds i (....) ett enda SMTP-meddelande, något som endast tillåts i fall enligt artikel 4

</datas>

</PRUEMDNA>

4.2   Definition av XML-strukturen

Följande definitioner medtas endast i dokumentationssyfte och för bättre läsbarhet, den faktiskt bindande informationen återfinns i en fil med XML-schemat (PRUEM DNA.xsd).

4.2.1   Specifikation PRUEMDNAx

Den innehåller följande fält:

Fields	Type	Description
header	PRUEM_header	Occurs: 1
datas	PRUEM_datas	Occurs: 1 ... 500

4.2.2   Innehåll i huvudfältets struktur

4.2.2.1

PRUEM-huvud Denna struktur beskriver XML-filhuvudet. Den innehåller följande fält: Fields Type Description direction PRUEM_header_dir Direction of message flow ref String Reference of the XML file generator String Generator of XML file schema_version String Version number of schema to use requesting PRUEM_header_info Requesting Member State info requested PRUEM_header_info Requested Member State info

4.2.2.2

PRUEM_header dir Typ av data i meddelandet, värden Value Description R Request A Answer

4.2.2.3

Information i PRUEM-huvudet Struktur som beskriver medlemsstaten samt anger datum och tid för meddelandet. Den innehåller följande fält: Fields Type Description source_isocode String ISO 3166-2 code of the requesting Member State destination_isocode String ISO 3166-2 code of the requested Member State request_id String unique Identifier for a request date Date Date of creation of message time Time Time of creation of message

4.2.3   PRUEM-profiluppgifter, innehåll

4.2.3.1

PRUEM_datas Denna struktur beskriver XML-profilens datadel: Den innehåller följande fält: Fields Type Description reqtype PRUEM request type Type of request (Article 3 or 4) date Date Date profile stored type PRUEM_datas_type Type of profile result PRUEM_datas_result Result of request agency String Name of corresponding unit responsible for the profile profile_ident String Unique Member State profile ID message String Error Message, if result = E profile IPSG_DNA_profile If direction = A (Answer) AND result ≠ H (Hit) empty match_id String In case of a HIT PROFILE_ID of the requesting profile quality PRUEM_hitquality_type Quality of Hit hitcount Integer Count of matched Alleles rescount Integer Count of matched profiles. If direction = R (Request), then empty. If quality!=0 (the original requested profile), then empty.

4.2.3.2

PRUEM_request_type Typ av data i meddelandet, värden: Value Description 3 Requests pursuant to Article 3 of Decision 2008/615/JHA 4 Requests pursuant to Article 4 of Decision 2008/615/JHA

4.2.3.3

PRUEM_hitquality_type Value Description 0 Referring original requesting profile: Case ”No Hit”: original requesting profile sent back only; Case ”Hit”: original requesting profile and matched profiles sent back. 1 Equal in all available alleles without wildcards 2 Equal in all available alleles with wildcards 3 Hit with Deviation (Microvariant) 4 Hit with mismatch

4.2.3.4

PRUEM_data_type Typ av data i meddelandet, värden: Value Description P Person profile S Stain

4.2.3.5

PRUEM_data_result Typ av data i meddelandet, värden: Value Description U Undefined, If direction = R (request) H Hit N No Hit E Error

4.2.3.6

IPSG_DNA_profile Struktur som beskriver en DNA-profil. Den innehåller följande fält: Fields Type Description ess_issol IPSG_DNA_ISSOL Group of loci corresponding to the ISSOL (standard group of Loci of Interpol) additional_loci IPSG_DNA_additional_loci Other loci marker String Method used to generate of DNA profile_id String Unique identifier for DNA profile

4.2.3.7

IPSG_DNA_ISSOL Struktur som innehåller Issol-lokus (Interpols standarduppsättning lokus). Den innehåller följande fält: Fields 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 amelogin

4.2.3.8

IPSG_DNA_additional_loci Struktur som innehåller övriga lokus. Den innehåller följande fält: Fields 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 Struktur som beskriver ett lokus. Den innehåller följande fält: Fields Type Description low_allele String Lowest value of an allele high_allele String Highest value of an allele

5.   Tillämpnings-, säkerhets- och kommunikationsarkitektur

5.1   Översikt

Vid införandet av tillämpningar för utbyte av DNA-uppgifter inom ramen för beslut 2008/615/RIF ska ett gemensamt, på logisk nivå slutet, nät mellan medlemsstaterna användas. För att mer effektivt utnyttja detta gemensamma kommunikationsnät för att sända begäranden och ta emot svar ska begäranden om DNA- och fingeravtrycksuppgifter överföras asynkront i inkapslade SMTP-meddelanden. Av hänsyn till säkerhetskraven kommer S/MIME-mekanismen att användas som tillägg till SMTP-funktionerna för att upprätta en obruten säker tunnel i nätet.

Det redan fungerande systemet Testa (Trans European Services for Telematics between Administrations) har valts som kommunikationsnät för datautbytet mellan medlemsstaterna. Europeiska kommissionen ansvarar för närvarande för Testa. Eftersom de nationella DNA-databaserna och de nuvarande nationella anslutningspunkterna för Testa kan vara belägna på olika ställen i medlemsstaterna kan tillgång till Testa anordnas antingen

1)	genom att använda den befintliga nationella anslutningspunkten eller inrätta en ny nationell anslutningspunkt till Testa, eller

2)	genom att etablera en säker lokal länk, från den plats där DNA-databasen finns och förvaltas av det behöriga nationella organet, till den befintliga nationella anslutningspunkten till Testa.

De protokoll och standarder som används vid införandet av tillämpningar enligt beslut 2008/615/RIF står i överensstämmelse med öppna standarder och uppfyller de kraven från dem som ansvarar för medlemsstaternas nationella säkerhet.

5.2   Högnivåarkitektur

Enligt beslut 2008/615/RIF ska varje medlemsstat göra sin DNA-databas tillgänglig för utbyte med och/eller sökning från andra medlemsstater i enlighet med ett standardiserat gemensamt dataformat. Arkitekturen bygger på kommunikationsmodellen alla-till-alla (any-to-any). Det finns ingen central server och inte heller någon centraliserad databas med DNA-profiler.

Figur 1: Topologi över utbyte av DNA-uppgifter

Medlemsstaterna ska iaktta de nationella rättsliga restriktionerna för medlemsstaternas webbplatser och kan också bestämma vilken typ av hårdvara och vilka program som bör användas för att konfigurera medlemsstatens webbplats för att iaktta kraven i beslut 2008/615/RIF.

5.3   Säkerhetsstandarder och dataskydd

Tre nivåer av säkerhetsklassning har övervägts och införts.

5.3.1   Datanivån

De DNA-profiluppgifter som tillhandahålls av varje medlemsstat måste utformas i enlighet med en gemensam standard för dataskydd så att den begärande medlemsstaten får ett svar som huvudsakligen anger TRÄFF eller ICKE-TRÄFF samt vid TRÄFF ett identifikationsnummer som inte innehåller några som helst personuppgifter. Den fortsatta undersökningen efter meddelande om TRÄFF kommer att genomföras på bilateral nivå i enlighet med de nationella rättsliga och organisatoriska föreskrifter som gäller vid respektive medlemsstats anläggning.

5.3.2   Kommunikationsnivån

Meddelanden som innehåller information om DNA-profiler (begäranden och svar) kommer att krypteras med senaste teknik, anpassad till öppna standarder, t.ex. S/MIME, innan de översänds till andra medlemsstaters anläggningar.

5.3.3   Transmissionsnivån

Alla krypterade meddelanden med DNA-profilinformation kommer att vidarebefordras till andra medlemsstaters anläggningar genom ett virtuellt privat tunnelsystem som på internationell nivå förvaltas av en tillförlitlig nätleverantör och med nationellt ansvar för de säkra länkarna till detta tunnelsystem. Det virtuella privata tunnelsystemet har ingen anslutning till det öppna Internet.

5.4   Protokoll och standarder för krypteringsmekanismen S/MIME och därmed sammanhörande paket

Den öppna standarden S/MIME, en vidareutveckling av den faktiska e-poststandarden SMTP, kommer att användas för att kryptera meddelanden med DNA-profilinformation. Protokollet S/MIME (version 3) ger möjlighet till signerade kvittenser, säkerhetsuppmärkning och säkra sändlistor på grundval av en kryptografisk meddelandestandard (Cryptographic Message Syntax, CMS), en specifikation från Internet Engineering Task Force (IETF) för meddelanden skyddade genom kryptering. Det kan användas för att digitalt signera, autentisera eller kryptera alla former av uppgifter i digital form.

Det certifikat som S/MIME-mekanismen använder måste överensstämma med X.509-standarden. För att se till att de gemensamma standarderna och förfarandena överensstämmer med andra Prüm-tillämpningar gäller följande regler för S/MIME-kryptering eller i samband med olika Cots-miljöer (Cots, färdigköpt allmänt tillgänglig produkt).

—	Bearbetningsordning: Först kryptering, därefter signering.

—	Krypteringsalgoritmerna AES (Advanced Encryption Standard) med 256 bitars nyckellängd och RSA med 1 024 bitars nyckellängd ska användas för symmetrisk respektive asymmetrisk kryptering.

—	Hash-algoritmen SHA-1 ska användas.

S/MIME-funktioner finns i de allra flesta moderna programpaket för e-post, bland annat Outlook, Mozilla Mail och Netscape Communicator 4.x och är interoperabla mellan alla viktigare programpaket för e-post.

S/MIME har valts som lämplig mekanism för dataskyddet på kommunikationsnivån eftersom den är lätt att införliva i den nationella infrastrukturen vid alla medlemsstaters anläggningar. För att på ett effektivare sätt och till lägre kostnader visa hur tekniken fungerar har dock den öppna standarden JavaMail API valts för prototypen till utbytet av DNA-uppgifter. JavaMail API erbjuder enkel kryptering och dekryptering av e-postmeddelanden med användning av S/MIME och/eller OpenPGP. Avsikten är att erbjuda ett enkelt och lättanvänt API för e-postkunder som vill sända och ta emot e-post i något av de två mest populära formaten för krypterade e-postmeddelanden. Därför är det tillräckligt med någon av de senaste tillämpningarna av JavaMail API för de krav som ställs i beslut 2008/615/RIF, t.ex. en produkt från Bouncy Castle JCE (Java Cryptographic Extension), som kommer att användas för tillämpningen av S/MIME för prototypen av utbytet av DNA-uppgifter mellan alla medlemsstater.

5.5   Tillämpningsarkitektur

Varje medlemsstat kommer att ge övriga medlemsstater en uppsättning standardiserade DNA-profiluppgifter som är anpassade till gällande dokument för gränssnittskontroll (Interface Control Document, ICD). Detta kan antingen göras genom en logisk visning av den enskilda nationella databasen eller genom att upprätta en fysiskt exporterad databas (indexerad databas).

De fyra huvuddelarna: E-postservern/S/MIME, tillämpningsservern, datastrukturområdet för hämtning/inmatning av uppgifter och registrering av inkommande/utgående meddelanden samt matchningsmotorn genomför tillämpningslogiken på ett produktoberoende sätt.

För att alla medlemsstater lätt ska kunna införliva dessa komponenter i sina respektive anläggningar har de specificerade gemensamma funktionerna införts genom öppna standarder och protokoll som varje medlemsstat själv kan välja med hänsyn till nationell IT-policy och nationella IT-föreskrifter. På grund av de oberoende funktioner som ska införas för att få tillgång till de indexerade DNA-profildatabaser som omfattas av beslut 2008/615/RIF kan varje medlemsstat fritt välja plattform för hårdvara och program, inklusive databas- och operativsystem.

En prototyp för utbytet av DNA-uppgifter har utarbetats och prövats med framgång på det befintliga gemensamma nätet. Version 1.0 har utnyttjats i produktionsmiljö och används för det löpande arbetet. Medlemsstaterna får använda den produkt som har utvecklats gemensamt men får också utveckla egna produkter. De gemensamma produktkomponenterna kommer att bevaras, anpassas och vidareutvecklas i enlighet med de förändrade kraven inom IT, kriminaltekniken och/eller polisfunktionerna.

Figur 2: Översikt av tillämpningstopologin

5.6   Protokoll och standarder för tillämpningsarkitekturen

5.6.1   XML

Vid utbytet av DNA-uppgifter kommer XML-schemat, som bifogas e-postmeddelanden enligt SMTP, att användas fullt ut. XML (Xtensible Markup Language) är ett av W3C rekommenderat allmänt markeringsspråk för att för särskilda ändamål skapa markeringsspråk som kan beskriva många olika former av uppgifter. En beskrivning av en DNA-profil som lämpar sig för utbyte mellan alla medlemsstater har utarbetats med hjälp av XML och XML-schemat i dokumentet för gränssnittskontroll.

5.6.2   ODBC

Open DataBase Connectivity tillhandahåller ett standardiserat programmeringsgränssnitt (Application Program Interface, API) som ger åtkomst till databashanterare, oberoende av programmeringsspråk, databassystem och operativsystem. ODBC har dock vissa nackdelar. Att hantera ett stort antal klienter kan innebära en mångfald drivrutiner och dynamiska länkbibliotek (DLL). Dessa komplikationer kan öka omkostnaderna för administration av systemet.

5.6.3   JDBC

Java DataBase Connectivity (JDBC) är ett programgränssnitt (API) for programmeringsspråket Java som definierar på vilket sätt en klient kan ha åtkomst till en databas. I motsats till ODBC kräver inte JDBC några särskilda DLL i den lokala persondatorn.

Affärslogiken för att bearbeta begäran om DNA-profiler och svar på dessa vid medlemsstaternas anläggningar beskrivs i följande diagram. Både flödet för begäran och flödet för svar växelverkar med ett neutralt dataområde bestående av olika datapooler med gemensam datastruktur.

Figur 3: Tillämpningens arbetsflöde vid medlemsstaternas anläggningar, översikt

5.7   Kommunikationsmiljö

5.7.1   Gemensamt kommunikationsnät: Testa och efterföljande infrastruktur

Tillämpningen för utbyte av DNA-uppgifter kommer att använda e-post, en asynkron mekanism, för att begära sökningar och ta emot svar mellan medlemsstaterna. Eftersom alla medlemsstater har minst en nationell anslutningspunkt till Testa-nätet kommer det nätet att användas för utbytet av DNA-uppgifter. Testa tillhandahåller ett antal mervärdestjänster via sitt e-postrelä. Infrastrukturen fungerar som värd för Testa-specifika e-postlådor och kan dessutom omfatta sändlistor och policy för dirigering. Detta gör att Testa kan användas som en clearingcentral för meddelanden som är adresserade till förvaltningar som är anslutna till EU-omfattande domäner. Mekanismer för viruskontroll kan också inrättas.

Relästationen för e-post i Testa är byggd på en maskinvaruplattform med hög tillgänglighet vid den centrala Testa-anläggningen och skyddas av en brandvägg. DNS-servern i Testa konverterar URL-strängar till IP-adresser så att adresseringsfrågorna inte berör användare och tillämpningar.

5.7.2   Säkerhetsfrågan

VPN-konceptet (Virtuellt Privat Nät) är genomfört inom ramen för Testa. Den teknik för Tag Switching som används för att bygga upp detta VPN kommer att utvecklas så att den är anpassad för den standard för MPLS (Multi-Protocol Label Switching) som har utarbetats av IETF (Internet Engineering Task Force).

MPLS är en standardteknik från IETF som påskyndar trafikflödet i nätet genom att inte analysera paketen i mellanliggande routrar (”hops”). Detta görs med hjälp av s.k. etiketter som bifogas paketet av stamnätets gränsroutrar på grundval av information i FIB (Forwarding Information Base). Etiketter används också för att genomföra virtuella privata nät.

MPLS kombinerar fördelarna med lager 3-routning och lager 2-switchning. Eftersom IP-adresserna inte analyseras vid överföringen i stamnätet, medför MPLS inte några begränsningar vad gäller IP-adresseringen.

Dessutom kommer e-postmeddelanden i Testa att skyddas av en krypteringsmekanism driven av S/MIME. Utan kännedom om nyckeln och utan rätt certifikat är det omöjligt att dekryptera meddelanden som sänds via nätet.

5.7.3   Protokoll och standarder för kommunikationsnätet

5.7.3.1

SMTP SMTP (Simple Mail Transfer Protocol) är en de facto-standard för överföring av e-post via Internet. SMTP är ett relativt enkelt textbaserat protokoll där man anger en eller flera mottagare och därefter överför meddelandetexten. SMTP använder TCP-port 25 enligt IETF:s specifikation. För att hitta SMTP-servern för en visst domännamn används DNS-informationen vid MX (Mail eXchange). Eftersom detta protokoll till att börja med uteslutande grundade sig på ASCII-text, kunde det inte hantera binära filer särskilt bra. Standarder som MIME utarbetades för att koda binära filer för överföring med SMTP. Numera är de flesta SMTP-servrarna anpassade till vidareutvecklingarna 8BITMIME och S/MIME, vilket gör att binära filer kan överföras nästan lika enkelt som klartext. Bearbetningsreglerna för S/MIME beskrivs i S/MIME-avsnittet. SMTP är ett push-protokoll som gör att meddelanden inte kan hämtas från en fjärrserver på begäran. För att göra detta måste postkunden använda POP3 eller IMAP. Man har beslutat att använda POP3-protokollet för utbytet av DNA-uppgifter.

5.7.3.2

POP De lokala e-postkunderna använder protokollet POP3 (Post Office Protocol, version 3), ett Internet-standardprotokoll för tillämpningslagret, för att hämta e-post från en fjärrserver via en TCP/IP-förbindelse. Genom att använda SMTP-protokollets profil för ”skicka” sänder e-postkunder meddelanden över Internet eller över ett företagsinternt nät. MIME används som standard för bilagor och icke-ASCII-text. Även om varken POP3 eller SMTP kräver MIME-formaterad e-post, kommer så gott som all e-post via Internet i MIME-format, vilket innebär att även POP-klienterna måste förstå och använda MIME. Hela kommunikationsmiljön enligt beslut 2008/615/RIF kommer därför att inkludera POP-komponenterna.

5.7.4   Tilldelning av nätadresser

Driftsmiljö

Testa har av den europeiska IP-registreringsmyndigheten (RIPE) redan tilldelats ett särskilt block av subnet-adresser av klass C. Ytterligare block av adresser kan senare komma att tilldelas Testa vid behov. Tilldelningen av IP-adresser till medlemsstaterna grundar sig på ett geografiskt mönster i Europa. Uppgiftsutbytet mellan medlemsstaterna inom ramen för beslut 2008/615/RIF genomförs i ett logiskt slutet IP-nät som omfattar hela Europa.

Testmiljö

För att tillhandahålla en väl fungerande miljö för den dagliga verksamheten i alla anslutna medlemsstater måste en testmiljö upprättas i det slutna nätet för nya medlemsstater som förbereder sitt deltagande. Ett blad med parametrar, bland annat IP-adresser, nätinställningar, e-postdomäner och användarkonton för tillämpningen har utarbetats och bör anslås vid dessa medlemsstaters anläggningar. En uppsättning pseudo-DNA-profiler för teständamål har också utformats.

5.7.5   Konfigurationsparametrar

Ett säkert e-postsystem har upprättats med användning av domänen eu-admin.net. Denna domän kommer inte att kunna nås från en plats som inte ingår i den EU-omfattande Testa-domänen, eftersom namnen endast är kända på Testas centrala DNS-server, som är skyddad från Internet.

Mappningen av dessa webbplatsadresser (värdnamn) till motsvarande IP-adresser sköts genom DNS-tjänsten i Testa. För varje lokal domän kommer ett postobjekt att läggas till på Testas centrala DNS-server, varifrån alla e-postmeddelanden från Testas lokala domäner skickas vidare till Testas centrala postrelä. Det centrala postrelät kommer därefter att vidarebefordra dem till den specifika lokala domänens e-postserver och använda de lokala domänernas e-postadresser. Genom att skicka vidare e-posten på detta sätt kommer kritisk information i e-postmeddelandena endast att passera den EU-omfattande slutna nätinfrastrukturen, inte det osäkra Internet.

Subdomäner ( fet kursiv stil ) enligt följande syntax måste upprättas för alla medlemsstaters anläggningar:

” typ_av_tillämpning.pruem. medlemsstatskod.eu-admin.net”, där

värdet för ” medlemsstatskod ” är en av de tvåställiga bokstavskoderna för medlemsstaterna (dvs. ”AT”, ”BE” etc.), och

värdet för ” typ_av_tillämpning ” är antingen DNA eller FP.

Med denna syntax blir medlemsstaternas subdomäner följande:

MS	Sub Domains	Comments
BE	dna.pruem.be.eu-admin.net	Setting up a secure local link to the existing TESTA II access point
	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	Using the existing TESTA II national access points
	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	Using the existing TESTA II national access point
	fp.pruem.es.eu-admin.net
FR	dna.pruem.fr.eu-admin.net	Using the existing TESTA II national access point
	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	Using the existing TESTA II national access point
	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	Intending to establish a new TESTA II access point at the NFI
	fp.pruem.nl.eu-admin.net
AT	dna.pruem.at.eu-admin.net	Using the existing TESTA II national access point
	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	[To be inserted]
	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

KAPITEL 2: Utbyte av fingeravtrycksuppgifter (gränssnittskontrolldokument)

Syftet med följande gränssnittskontrolldokument är att fastställa kraven för utbytet av fingeravtrycksuppgifter mellan AFIS-systemen i medlemsstaterna (Automated Fingerprint Identification Systems). Det grundar sig på Interpols implementation av ANSI/NIST-ITL 1-2000 (INT-I, version 4.22b).

Denna version ska omfatta alla grundläggande definitioner för de logiska posterna av typ 1, typ 2, typ 4, typ 9, typ 13 och typ 15 som krävs för bearbetning av fingeravtrycken utgående från bilder och minutiae.

1.   Översikt av filinnehållet

En fingeravtrycksfil består av flera logiska poster. I den ursprungliga standarden ANSI/NIST-ITL 1-2000 specificeras 16 posttyper. Lämpliga ASCII-avgränsare sätts in mellan posterna och mellan fält och delfält i posterna.

Endast sex posttyper används för att utbyta uppgifter mellan det sändande och det mottagande organet.

Typ 1	→	Transaktionsinformation
Typ 2	→	Alfanumeriska person- och/eller ärendeuppgifter
Typ 4	→	Högupplösta fingeravtrycksbilder i gråskala
Typ 9	→	Minutiaepost
Typ 13	→	Post för latent bild med varierande upplösning
Typ 15	→	Post för handavtrycksbild med varierande upplösning

1.1   Typ 1 – Filhuvud

Denna post innehåller routningsinformation och information som beskriver strukturen i resten av filen. Denna posttyp definierar också transaktionstypen, som ingår i någon av följande övergripande kategorier:

1.2   Typ 2 – Beskrivande text

Denna post innehåller informerande text av intresse för det sändande och det mottagande organet.

1.3   Typ 4 – Högupplöst bild i gråskala

Denna post används för att utbyta högupplösta fingeravtrycksbilder i gråskala (8 bitar) som skannats med upplösningen 500 pixel/tum. Fingeravtrycksbilderna ska komprimeras med WSQ-algoritmen i ett förhållande som inte överstiger 15:1. Andra komprimeringsalgoritmer eller okomprimerade bilder får inte användas.

1.4   Typ 9 – Minutiaepost

Posttyp 9 används för att utbyta karakteristiska papillarmönster eller uppgifter om minutiae. De tjänar dels till undvika onödig dubblering av AFIS-kodningsprocesserna, dels till att göra det möjligt att överföra AFIS-koder som innehåller färre uppgifter än motsvarande bilder.

1.5   Typ 13 – Latenta bilder med varierande upplösning

Denna post ska användas för att utbyta bilder av latenta fingeravtryck och handavtryck tillsammans med alfanumerisk textinformation. Bilder ska vara skannade med upplösningen 500 pixel/tum i 256 nivåer av grått. Om den latenta bildens kvalitet tillåter det, ska den komprimeras med WSQ-algoritmen. Om så behövs får, efter ömsesidig överenskommelse, bildernas upplösning ökas så att den överskrider 500 pixel/tum och gråskalan utvidgas till fler än 256 nivåer. I detta fall bör man absolut använda JPEG 2000 (se bilaga 7).

1.6   Post för handavtrycksbild med varierande upplösning

Poster av typ 15 med taggade fält ska användas för att utbyta handavtrycksbilder med varierande upplösning tillsammans med alfanumerisk textinformation. Bilder ska vara skannade med upplösningen 500 pixel/tum i 256 nivåer av grått. För att minimera datamängderna ska alla handavtrycksbilder komprimeras med WSQ-mekanismen. Om så behövs får, efter ömsesidig överenskommelse, bildernas upplösning ökas så att den överskrider 500 pixel/tum och gråskalan utvidgas till fler än 256 nivåer. I detta fall bör man absolut använda JPEG 2000 (se bilaga 7).

2.   Postformat

En transaktionsfil ska bestå av en eller flera logiska poster. I varje logisk post i filen ska det finnas flera fält med information associerad med posttypen i fråga. Varje informationsfält kan innehålla en eller flera grundläggande uppgifter som var och en representeras av endast ett värde. Sammantagna används dessa uppgifter för att förmedla olika aspekter av informationen i fältet. Ett informationsfält kan också bestå av en eller flera grupperade uppgifter som upprepas flera gånger inom fältet. En sådan grupp av uppgifter kallas delfält. Ett informationsfält kan därför bestå av ett eller delfält med uppgifter.

2.1   Informationsavgränsare

I de logiska posterna med taggade fält skiljs de olika informationskomponenterna från varandra med hjälp av fyra informationsavgränsare i ASCII-kod. De på så sätt avgränsade informationskomponenterna kan vara uppgifter inom ett fält eller ett delfält, fält i en logisk post eller de olika förekomsterna av delfält. Dessa informationsavgränsare definieras i ANSI X3.4-standarden. Dessa tecken används för att avgränsa och kvalificera information i logisk mening. Sedda i hierarkisk ordning uppifrån och ner är filavgränsningstecknet ”FS” den mest inklusiva avgränsaren, följd av gruppavgränsaren ”GS”, postavgränsaren ”RS” och sist enhetsavgränsningstecknet ”US”. Dessa ASCII-avgränsare, och hur de används inom ramen för denna standard, beskrivs i tabell 1.

Informationsavgränsarna bör ur funktionell synpunkt ses som en anvisning om vilken typ av information som följer efter avgränsaren. US-tecknet ska avgränsa olika enskilda uppgifter inom ett fält eller ett delfält. Det är en signal om att nästa uppgift är en informationskomponent inom det fältet eller delfältet. Flera olika delfält inom ett fält avgränsade med RS-tecknet signalerar början av nästa grupp av upprepade uppgifter. Avgränsningstecknet GS mellan informationsfält signalerar början av ett nytt fält och ska föregå det fältidentifikationsnummer som ska finnas. På liknande sätt ska början av en ny logisk post signaleras av FS-tecknet.

De fyra tecknen är endast meningsfulla när de används som avgränsare av informationskomponenter i fält i poster med ASCII-text. Dessa tecken har ingen särskild betydelse när de förekommer i binära bildposter och binära fält – de ingår då endast i de utbytta uppgifterna.

Det ska normalt inte finnas tomma fält eller uppgifter, och därför bör det endast förekomma ett avgränsningstecken mellan två uppgifter. Undantaget från denna regel inträffar till exempel när data i ett fält eller uppgifter i en transaktion inte är tillgängliga, saknas eller är frivilliga, och bearbetningen av transaktionen inte är beroende av att dessa specifika data finns att tillgå. I dessa fall ska flera och angränsande avgränsningstecken förekomma tillsammans, snarare än att uppgifter utan betydelse infogas mellan avgränsningstecknen.

Följande gäller för definitionen av ett fält som består av tre uppgifter. Om information för den andra uppgiften saknas, kommer två angränsande US-avgränsare att förekomma mellan den första och den tredje uppgiften. Om både den andra och den tredje uppgiften saknades, skulle tre avgränsningstecken användas – två US-tecken förutom den avslutande fält- eller delfältsavgränsaren. Allmänt sett gäller att om en eller flera obligatoriska eller frivilliga uppgifter inte finns att tillgå för ett fält eller ett delfält, ska det relevanta antalet avgränsningstecken infogas.

Det är möjligt att ha kombinationer med två eller flera av de fyra tillgängliga avgränsningstecknen gränsande till varandra. Om data saknas eller inte finns att tillgå för uppgifter, delfält eller fält, måste det förekomma ett avgränsningstecken mindre än antalet erforderliga uppgifter, delfält eller fält.

Tabell 1: Använda avgränsare

Code	Type	Description	Hexadecimal Value	Decimal Value
US	Unit Separator	Separates information items	1F	31
RS	Record Separator	Separates subfields	1E	30
GS	Group Separator	Separates fields	1D	29
FS	File Separator	Separates logical records	1C	28

2.2   Postformat

I logiska poster med taggade fält ska varje informationsfält som används numreras i enlighet med följande standard. Varje fält ska formateras så att det består av typnummer för den logiska posten följt av punkt ”.”, ett fältnummer följt av kolon ”:”, följt av den för detta fält relevanta informationen. Fältnumret för det taggade fältet kan vara ett godtyckligt en- till niosiffrigt nummer som förekommer mellan punkt ”.” och kolon ”:”. Det ska tolkas som ett fältnummer i positivt heltal. Detta innebär att ett fältnummer ”2 123:” är lika med och ska tolkas på samma sätt som ett fältnummer ”2.000000123:”.

I exemplifierande syfte används i hela detta dokument ett treställigt tal för numrering av de fält som ingår de logiska poster med taggade fält som beskrivs i dokumentet. Fältnummer får formatet ”TT.xxx:” där ”TT” representerar posttypen med ett eller två tecken följt av en punkt. De följande tre tecknen innehåller det relevanta fältnumret som följs av ett kolon. Efter kolon följer ASCII-information eller bilddata.

Logiska poster av typ 1 eller typ 2 innehåller endast datafält med ASCII-text. Den totala postlängden (inklusive fältnummer, kolon och avgränsningstecken) ska anges i det första ASCII-fältet i båda dessa posttyper. ASCII-filavgränsaren ”FS” (anger slutet av den logiska posten eller transaktionen) ska följa efter den sista positionen ASCII-information och inkluderas i postlängden.

I motsats till konceptet med taggade fält innehåller poster av typ 4 endast binära data som registrerats i form av ordnade binära fält med fast längd. Den totala postlängden ska anges i det första fältet om fyra positioner i varje post. I denna binära post ska varken postnumret med sin efterföljande punkt eller fältnumret med efterföljande kolon anges. Eftersom alla fältlängder i denna posttyp antingen är fasta eller specificerade, ska inget av de fyra avgränsningstecknen (”US”, ”RS”, ”GS”, eller ”FS”) tolkas som någonting annat än binära data. FS-tecknet ska inte användas som post- eller transaktionsavgränsare i den binära posten.

3.   Logisk post typ 1: Filhuvud

Denna post beskriver filens struktur och typ samt innehåller annan viktig information. De tecken som används för fält i logiska poster av typ 1 ska endast utgöras av den 7-bitars ANSI-koden för informationsutbyte.

3.1   Fält i logisk post typ 1

3.1.1   Fält 1.001: Logisk postlängd (Logical Record Length – LEN)

I detta fält anges det totala antalet byte i hela den logiska posten av typ 1. Fältet inleds med ”1 001:” följt av den totala postlängden, inklusive alla tecken i alla fält och informationsavgränsarna.

3.1.2   Fält 1.002: Versionsnummer (Version number – VER)

För att säkerställa att användarna känner till vilken version av ANSI/NIST-standarden som används, anges i detta fält versionsnumret för den standard som används av det program eller system som har skapat filen. I de första två positionerna anges versionsnumret, i de två följande revisionsnumret. Den ursprungliga standarden från 1986 skulle till exempel anses som den första versionen och anges som ”0100”, medan den nuvarande standarden ANSI/NIST-ITL 1-2000 anges som ”0300”.

3.1.3   Fält 1.002: Fältinnehåll (File Content – CNT)

I detta fält förtecknas varje post i filen efter posttyp och i den ordning i vilken de förekommer i den logiska filen. Det består av ett eller flera delfält, som vart och ett i sin tur innehåller två uppgifter som beskriver en logisk post som förekommer i den aktuella filen. Delfälten registreras i samma ordning som den i vilken posterna registreras och överförs.

Den första uppgiften i det första delfältet är ”1”, vilket hänvisar till denna post av typ 1. Den följs av en andra uppgift om antalet andra poster som förekommer i filen. Detta antal är också lika med antal återstående delfält i fält 1.003.

Vart och ett av de återstående delfälten är förknippat med en post i filen och sekvensen av delfält svarar mot sekvensen av poster. Varje delfält innehåller två uppgifter. Den första uppgiften identifierar posttypen. Den andra uppgiften är postens IDC. US-tecknet ska användas för att avgränsa de två uppgifterna.

3.1.4   Fält 1.003: Transaktionstyp (Type of Transaction – TOT)

Detta fält innehåller en treställig minneskod som anger transaktionstypen. Dessa koder kan skilja sig från dem som används i andra implementationer av ANSI/NIST-standarden.

CPS: Criminal Print-to-Print Search. Transaktionen är en begäran om sökning med en post i anslutning till ett brott mot en avtrycksdatabas. Personens avtryck måste inkluderas i filen som WSQ-komprimerade bilder.

Vid Icke-TRÄFF kommer följande logiska poster att returneras:

—	1 post typ 1.

—	1 post typ 2.

Vid TRÄFF kommer följande logiska poster att returneras:

—	1 post typ 1.

—	1 post typ 2.

—	1–14 poster typ 4.

Transaktionstypen CPS sammanfattas i tabell A.6.1 (bilaga 6).

PMS: Print-to-Latent Search. Denna transaktion används när en uppsättning avtryck ska användas för sökning mot en databas med oidentifierade latenta avtryck. Svaret kommer att innehålla Träff/Icke-träff-avgörandet vid den avsedda AFIS-sökningen. Om det finns flera oidentifierade latenta avtryck, kommer flera SRE-transaktioner att returneras med ett latent avtryck per transaktion. Personens avtryck måste inkluderas i filen som WSQ-komprimerade bilder.

Vid Icke-TRÄFF kommer följande logiska poster att returneras:

—	1 post typ 1.

—	1 post typ 2.

Vid TRÄFF kommer följande logiska poster att returneras:

—	1 post typ 1.

—	1 post typ 2.

—	1 post typ 13.

Transaktionstypen PMS sammanfattas i tabell A.6.1 (bilaga 6).

MPS: Latent-to-Print Search. Denna transaktion används när ett latent avtryck ska användas för sökning mot en avtrycksdatabas. Den latenta minutiaeinformationen och bilden (WSQ-komprimerad) måste ingå i filen.

Vid Icke-TRÄFF kommer följande logiska poster att returneras:

—	1 post typ 1.

—	1 post typ 2.

Vid TRÄFF kommer följande logiska poster att returneras:

—	1 post typ 1.

—	1 post typ 2.

—	1 post typ 4 eller typ 15.

Transaktionstypen MPS sammanfattas i tabell A.6.4 (bilaga 6).

MMS: Latent-to-Latent Search. För denna transaktion innehåller filen ett latent avtryck som ska användas för sökning mot en databas med oidentifierade latenta avtryck i syfte att ta konstatera kopplingar mellan olika brottsplatser. Den latenta minutiaeinformationen och bilden (WSQ-komprimerad) måste ingå i filen.

Vid Icke-TRÄFF kommer följande logiska poster att returneras:

—	1 post typ 1.

—	1 post typ 2.

Vid TRÄFF kommer följande logiska poster att returneras:

—	1 post typ 1.

—	1 post typ 2.

—	1 post typ 13.

Transaktionstypen MMS sammanfattas i tabell A.6.4 (bilaga 6).

SRE: Denna transaktion returneras av bestämmelseorganet som svar på begäran om fingeravtrycksundersökningar. Svaret kommer att innehålla Träff/Icke-träff-avgörandet vid den avsedda AFIS-sökningen. Om det finns flera kandidater, kommer flera SRE-transaktioner att returneras med en kandidat per transaktion.

Transaktionstypen SRE sammanfattas i tabell A.6.2 (bilaga 6).

ERR: Denna transaktion returneras av det avsedda AFIS-systemet för att ange ett fel vid bearbetningen av transaktionen. Den innehåller ett meddelandefält (ERM) som anger vilket fel som har upptäckts. Följande logiska poster kommer att returneras:

—	1 post typ 1.

—	1 post typ 2.

Transaktionstypen ERR sammanfattas i tabell A.6.3 (bilaga 6).

Tabell 2: Tillåtna koder i transaktioner

Transaction Type	Logical Record Type
	1	2	4	9	13	15
CPS	M	M	M	—	—	—
SRE	M	M	C	— (C in case of latent hits)	C	C
MPS	M	M	—	M (1*)	M	—
MMS	M	M	—	M (1*)	M	—
PMS	M	M	M*	—	—	M*
ERR	M	M	—	—	—	—

Nyckel:

M	=	Obligatorisk
M*	=	Endast en av båda posttyperna får ingå
O	=	Frivillig
C	=	Beroende av tillgängliga uppgifter
–	=	Ej tillåten
1*	=	Beroende av legacy systems

3.1.5   Fält 1.005: Transaktionsdatum (Date of Transaction – DAT)

Detta fält anger vilken dag transaktionen initierades och måste följa ISO-standarden YYYYMMDD

där YYYY är året, MM är månaden och DD är dagen i månaden. Ledande nollor ska användas för ensiffriga tal. ”19931004” står till exempel för den 4 oktober 1993.

3.1.6   Fält 1.006: PRIORITET (Priority – PRY)

Detta frivilliga fält anger prioritet, på en nivå 1–9, för begäran. ”1” anger högsta prioritet, ”9” lägsta prioritet. Prioritet ”1” ska behandlas omedelbart.

3.1.7   Fält 1.007: Bestämmelseorgansidentifierare (Destination Agency Identifier – DAI)

Detta fält anger transaktionens bestämmelseorgan.

Det består av två uppgifter i följande format: CC/organ.

Den första uppgiften består av en landskod om två alfanumeriska tecken enligt ISO 3166. Den andra uppgiften, organ, identifierar organet genom en sträng fri text om maximalt 32 alfanumeriska tecken.

3.1.8   Fält 1.008: Ursprungsorgansidentifierare (Originating Agency Identifier – ORI)

Detta fält anger vilket organ som har skapat filen och har samma format som DAI (fält 1.007).

3.1.9   Fält 1.009: Transaktionskontrollnummer (Transaction Control Number – TCN)

Detta är ett kontrollnummer för hänvisningsändamål. Det bör skapas av datorn och ha följande format: YYSSSSSSSSA

där YY är år för transaktionen, SSSSSSSS är ett åttaställligt serienummer och A är ett kontrolltecken som har genererats med den procedur som anges i bilaga 2.

Om TCN inte är tillgängligt, ska fältet YYSSSSSSSS fyllas med nollor och det kontrolltecken som genererats enligt ovan.

3.1.10   Fält 1.010: Transaktionskontrollsvar (Transaction Control Response – TCR)

När en begäran har sänts med denna post som svar, innehåller detta frivilliga fält Transaction Control Number (TCN) för meddelandet med begäran. Det har därför samma format som TCN (fält 1.009).

3.1.11   Fält 1.011: (Native Scanning Resolution – NSR)

Detta fält anger den normala upplösningen vid skanning för det system som avsändaren av transaktionen använder. Upplösningen ska anges med två siffror följd av decimalpunkt och därefter ytterligare två siffror.

För alla transaktioner i enlighet med beslut 2008/615/RIF ska samplingsfrekvensen vara 500 pixel/tum eller 19,68 pixel/mm.

3.1.12   Fält 1.012: Nominell överföringsresolution (Nominal Transmitting Resolution – NTR)

Detta fält om fem positioner anger nominell överföringsupplösning för de bilder som överförs. Upplösningen ska uttryckas i pixel/mm i samma format som NSR (fält 1.011).

3.1.13   Fält 1.013: Domännamn (Domaine Name – DOM)

I detta obligatoriska fält anges domännamnet för den användardefinierade implementationen av logisk post typ 2. Det innehåller två uppgifter och ska uttryckas som ”INT-I{US}4.22{GS}”.

3.1.14   Fält 1.014: Greenwich Mean Time (GMT)

Detta obligatoriska fält ger möjlighet att uttrycka datum och tidpunkt i GMT-enheter (Greenwich Mean Time). Om det används innehåller GMT-fältet universellt datum i tillägg till det lokala datum som anges i fält 1.005 (DAT). Om GMT-fältet används elimineras inkonsekvenser med lokal tid när en transaktion och dess svar överförs mellan två platser skilda åt av flera tidszoner. GMT ger ett universellt datum och en 24-timmarstid som är oberoende av tidszoner. Fältet anges som ”CCYYMMDDHHMMSSZ”, en 15-positioners teckensträng som utgörs av datum konkatenerat med GMT och avslutas med ”Z”. Tecknen ”CCYY” ska representera år för transaktionen, tecknen ”MM” ska ange tiotals- och entalssiffran för månad, tecknen ”DD” ska ange tiotals- och entalssiffran för dag i månaden, tecknen ”HH” ska ange timme, ”MM” ska ange minut och ”SS” ska ange sekund. Den fullständiga tidsangivelsen får inte ange en tidpunkt i framtiden.

4.   Logisk post typ 2: Beskrivande text

Större delen av denna posts struktur definieras inte genom den ursprungliga ANSI/NIST-standarden. Posten innehåller information av särskilt intresse för de organ som sänder eller tar emot filen. För att säkerställa att de kommunicerande fingeravtryckssystemen är kompatibla kräver detta ICD att posten innehåller endast de fält som förtecknas nedan. I dokumentet anges vilka fält som är obligatoriska frivilliga, samtidigt som de enskilda fältens struktur fastställs.

4.1   Fält i logisk post typ 2

4.1.1   Fält 2.001: Logisk postlängd (Logical Record Length – LEN)

Detta obligatoriska fält anger längden av typ 2-posten i totalt antal byte, inklusive varje tecken i varje fält och informationsavgränsarna.

4.1.2   Fält 2.002: Bilddesigneringstecken (IDC)

Den IDC som anges i detta obligatoriska fält är en ASCII-representation av den IDC som definieras i fältet File Content i typ 1-posten.

4.1.3   Fält 2.003: Systeminformation (System Information – SYS)

Detta fält om fyra positioner är obligatoriskt och anger vilken version av INT-I som just denna typ 2-post följer.

I de första två positionerna anges versionsnumret, i de två följande revisionsnumret. Denna implementation grundar sig till exempel på INT-I version 2 revision 22, vilket ska uttryckas som ”0422”.

4.1.4   Fält 2.007: Ärendenummer (Case Number – CNO)

Detta är ett nummer som av det lokala fingeravtrycksorganet tilldelas en samling latenta avtryck som hittas på brottsplatsen. Följande format ska användas: CC/nummer

där ”CC” är Interpols landskod med två alfanumeriska tecken och nummer följer de relevanta lokala riktlinjerna och kan bestå av upp till 32 alfanumeriska tecken.

Genom detta fält kan systemet identifiera latenta avtryck förknippade med ett visst brott.

4.1.5   Fält 2.008: Sekvensnummer (Sequence Number – SQN)

Detta specificerar varje sekvens av latenta avtryck inom ett fall. Det kan innehålla upp till fyra numeriska tecken. En sekvens är ett latent avtryck eller serier av latenta avtryck som förs samman i grupper för registrering och/eller sökning. Denna definition medför att även enskilda latenta avtryck måste tilldelas ett sekvensnummer.

Detta fält kan tillsammans med MID (fält 2.009) användas för att identifiera ett särskilt latent avtryck i sekvensen.

4.1.6   Fält 2.009: Latentavtrycksidentifierare (Latent Identifier – MID)

Detta fält specificerar det enskilda latenta avtrycket inom en sekvens. Värdet är en eller två bokstäver där ”A” tilldelas det första latenta avtrycket, ”B” tilldelas det andra och så vidare upp till gränsen ”ZZ”. Fältet används på samma sätt som sekvensnumret för det latenta avtrycket enligt beskrivningen av SQN (fält 2.008).

4.1.7   Fält 2.010: Brottsreferensnummer (Criminal Reference Number – CRN)

Detta är ett unikt referensnummer som ett nationellt organ tilldelar en person när denna för första gången döms för att ha begått ett brott. I ett visst land har en person aldrig mer än ett CRN, eller delar det med en annan person. Samma person kan emellertid ha Criminal Reference Numbers i flera länder, dessa kan då skiljas åt med hjälp av landskoden.

CRN-fältet ska ha följande format: CC/nummer

där ”CC” är landskod med två alfanumeriska tecken enligt ISO 3166 och nummer följer relevanta nationella riktlinjer från det utfärdande organet och kan bestå av upp till 32 alfanumeriska tecken.

I transaktioner i enlighet med beslut 2008/615/RIF kommer detta fält att användas för nationellt Criminal Reference Number från det organ som är kopplat till bilderna i poster av typ 4 eller typ 15.

4.1.8   Fält 2.012: (Miscellaneous Identification Number – MN1)

Detta fält innehåller det CRN (fält 2.010) som sänts med en CPS- eller PMS-transaktion, utan inledande landskod.

4.1.9   Fält 2.013: (Miscellaneous Identification Number – MN2)

Detta fält innehåller det CRO (fält 2.007) som sänts med en MPS- eller MMS-transaktion, utan inledande landskod.

4.1.10   Fält 2.014: (Miscellaneous Identification Number – MN3)

Detta fält innehåller det SQN (fält 2.008) som sänts med en MPS- eller MMS-transaktion.

4.1.11   Fält 2.015: (Miscellaneous Identification Number – MN4)

Detta fält innehåller det SQN (fält 2.009) som sänts med en MPS- eller MMS-transaktion.

4.1.12   Fält 2.063: Tilläggsinformation (Additional Information – INF)

Vid en SRE-transaktion efter en PMS-begäran informerar detta fält om vilket finger som gav anledning till den eventuella träffen. Fältet ska ha följande format:

NN där NN är den tvåställiga fingerpositionskod som definieras i tabell 5.

I alla övriga fall är detta fält frivilligt. Det består av upp till 32 alfanumeriska tecken och kan användas för att lämna ytterligare upplysningar om begäran.

4.1.13   Fält 2.064: (Respondents List – RLS)

Detta fält innehåller minst två delfält. Det första delfältet beskriver den typ av sökning som har gjorts med användning av den treställiga minneskod som specificerar transaktionstypen i TOT-fältet (fält 1.004). Det andra delfältet består av endast ett tecken. ”I” ska användas för att ange en TRÄFF, och ”N” ska användas för att ange att inga överensstämmelser har hittats (ICKE-TRÄFF). Det tredje delfältet innehåller sekvensidentifieraren för kandidatresultatet och totalt antal kandidater, avgränsat med snedstreck. Flera meddelanden kommer att returneras om det finns fler än en kandidat.

Vid en eventuell TRÄFF ska fjärde delfältet innehålla träffvärdet med upp till tio siffror. Om TRÄFFen har verifierats ska värdet för detta delfält definieras som ”999999”.

Exempel: ”CPS{RS}I{RS}001/001{RS}999999{GS}”

Om det AFIS till vilket transaktionen sänds inte tilldelar träffvärden, ska träffvärdet noll föras in på rätt plats.

4.1.14   Fält 2.074: Fält för status- och felmeddelanden (Status/Error Message Field – ERM)

Detta fält innehåller felmeddelanden vid transaktionsbearbetningen, vilka sänds tillbaka till den begärande parten som del av en feltransaktion.

Tabell 3: Felmeddelanden

Numeric Code (1-3)	Meaning (5-128)
003	ERROR: UNAUTHORISED ACCESS
101	Mandatory field missing
102	Invalid record type
103	Undefined field
104	Exceed the maximum occurrence
105	Invalid number of subfields
106	Field length too short
107	Field length too long
108	Field is not a number as expected
109	Field number value too small
110	Field number value too big
111	Invalid character
112	Invalid date
115	Invalid item value
116	Invalid type of transaction
117	Invalid record data
201	ERROR: INVALID TCN
501	ERROR: INSUFFICIENT FINGERPRINT QUALITY
502	ERROR: MISSING FINGERPRINTS
503	ERROR: FINGERPRINT SEQUENCE CHECK FAILED
999	ERROR: ANY OTHER ERROR. FOR FURTHER DETAILS CALL DESTINATION AGENCY.

Felmeddelanden i intervallet 100–199:

Dessa felmeddelanden gäller kontrollen av ANSI/NIST-posterna och ska uttryckas som

<error_code 1>: IDC <idc_number 1> FIELD <field_id 1> <dynamic text 1> LF

<error_code 2>: IDC <idc_number 1> FIELD <field_id 1> <dynamic text 1> LF

där

—	error_code är en kod som är entydigt kopplad till en viss orsak (se tabell 3),

—	field_id är ANSI/NIST-fältnumret för det felaktiga fältet (t.ex. 1.001, 2.001, ...) i formatet <record_type>.<field_id>.<sub_field_id>,

—	dynamic text är en mer utförlig situationsanpassad beskrivning av felet,

—	LF är ett LF-tecken som avgränsar felen om fler än ett fel har påträffats,

—	för typ 1-poster fastställs ICD till ”-1”.

Exempel:

201: IDC - 1 FIELD 1 009 FEL KONTROLLTECKEN {LF} 115: IDC 0 FIELD 2 003 OGILTIG SYSTEMINFORMATION

Detta fält är obligatoriskt för feltransaktioner.

4.1.15   Fält 2.320: Förväntat antal kandidater (Expected Number of Candidates – ENC)

Detta fält anger det maximala antal kandidater för kontroll som det begärande organet förväntar sig. Värdet ENC får inte överskrida de värden som definieras i tabell 11.

5.   Logisk post typ 4: Högupplösningsbild i gråskala

Det bör noteras att poster av typ 4 är binära poster snarare än ASCII-poster. Varje fält har där tilldelats en specifik position i posten, vilket medför att alla fält är obligatoriska.

Standarden medger att både bildstorlek och upplösning anges i posten. Logisk posttyp 4 måste innehålla fingeravtrycksuppgifter som överförs med en nominell pixeltäthet av 500–520 pixel/tum. Den täthet som föredras för nyutformningar är 500 pixel per tum, dvs. 19,68 pixel per mm. 500 pixel per tum är den täthet som specificeras i INT-I, med undantag för att liknande system får kommunicera med användning av en annan täthet inom intervallet 500–520 pixel per tum.

5.1   Fält i logisk post typ 4

5.1.1   Fält 4.001: Logisk postlängd (Logical Record Length – LEN)

Detta fält om fyra byte anger längden av typ 4-posten i totalt antal byte, inklusive varje byte i varje fält.

5.1.2   Fält 4.002: Bilddesigneringstecken (Image Designation Character – IDC)

Detta fält innehåller i binär form IDC-numret i filhuvudet.

5.1.3   Fält 4.003: Avtryckstyp (Impression Type – IMP)

Avtryckstyp är ett fält om en byte i sjätte positionen i posten.

Tabell 4: Fingeravtryckstyp

	Description
0	Live-scan of plain fingerprint
1	Live-scan of rolled fingerprint
2	Non-live scan impression of plain fingerprint captured from paper
3	Non-live scan impression of rolled fingerprint captured from paper
4	Latent impression captured directly
5	Latent tracing
6	Latent photo
7	Latent lift
8	Swipe
9	Unknown

5.1.4   Fält 4.004: Fingerposition (Finger Position – FGP)

Detta fasta fält med 6 byte upptar positionerna 7–12 i en post av typ 4. Det innehåller möjliga fingerställningar med början i den byte som befinner sig längst till vänster (byte 7 i posten). Känd eller mest trolig fingerposition har tagits från tabell 5. Upp till fem ytterligare fingrar kan registreras genom att man lägger in alternerande fingerpositioner i återstående fem byte i samma format. Om färre än fem fingerpositionsreferenser används fylls oanvända byte med binära 255. För att registrera alla fingerpositioner används 0 för okänd.

Tabell 5: Fingerposition och maximal storlek

Finger position	Finger code	Width (mm)	Length (mm)
Unknown	0	40,0	40,0
Right thumb	1	45,0	40,0
Right index finger	2	40,0	40,0
Right middle finger	3	40,0	40,0
Right ring finger	4	40,0	40,0
Right little finger	5	33,0	40,0
Left thumb	6	45,0	40,0
Left index finger	7	40,0	40,0
Left middle finger	8	40,0	40,0
Left ring finger	9	40,0	40,0
Left little finger	10	33,0	40,0
Plain right thumb	11	30,0	55,0
Plain left thumb	12	30,0	55,0
Plain right four fingers	13	70,0	65,0
Plain left four fingers	14	70,0	65,0

För latenta fingeravtryck på brottsplatsen bör endast koderna 0-10 användas.

5.1.5   Fält 4.005: Bildskanningsupplösning (Image Scanning Resolution – ISR)

Detta fält om en byte upptar position 13 i typ 4-posten. Om det innehåller ”0” har bilden skannats med en föredragen upplösning på 19,68 pixel/mm (500 pixel per tum). Om det innehåller ”1” har bilden skannats med en alternativ upplösning enligt typ 1-posten.

5.1.6   Fält 4.006: Horisontell linjelängd (Horizontal Line Length – HLL)

I detta fält som upptar positionerna 14-15 i typ 4-posten anges antalet pixel i varje skanningslinje. Den första positionen är mest signifikant.

5.1.7   Fält 4.007: Vertikal linjelängd (Vertical Line Length – VLL)

I detta fält i positionerna 16–17 anges antalet skanningslinjer i bilden. Den första positionen är mest signifikant.

5.1.8   Fält 4.008: Algoritm för komprimering av gråskalan (Gray-scale Compression Algorithm – GCA)

I detta fält om en byte anges vilken algoritm för komprimering av gråskalan som har använts för att koda bilddata. En binär kod 1 anger att WSQ-komprimering (bilaga 7 har använts för denna implementation.

5.1.9   Fält 4.009: Bilden (The Image)

Detta fält innehåller en teckensträng som representerar bilden. Fältets struktur kommer uppenbarligen att vara beroende av vilken komprimeringsalgoritm som används.

6.   Logisk post typ 9: Minutiaepost

Typ 9-poster ska innehålla ASCII-text som beskriver minutiae och dithörande uppgifter som har registrerats från ett latent avtryck. För en sökning efter latenta avtryck finns ingen övre gräns för antalet typ 9-poster i filen, som var och en ska svara mot en annan vy eller latent avtryck.

6.1   Extraktion av minutiae

6.1.1   Identifiering av minutiaetypen

I denna standard definieras tre identifikationsnummer som används för att beskriva minutiaetypen. Dessa specifikationer förtecknas i tabell 6. Åsavslutningar ska betecknas typ 1. Förgreningar ska betecknas typ 2. Om en minutiae inte klart kan kategoriseras en av de ovan nämnda typerna ska den betecknas som ”annan”, typ 0.

Tabell 6: Minutiaetyper

Type	Description
0	Other
1	Ridge ending
2	Bifurcation

6.1.2   Typ och placering av minutiae

För att mallarna ska uppfylla kraven i avsnitt 5 i standarden ANSI INCITS 378-2004, ska följande metod, som förstärker den nu gällande standarden INCITS 378-20204, användas för att bestämma placering (läge och vinkelriktning) för enskilda minutiae.

Positionen eller läget för en minutia som representerar avslutningen på en ås ska vara gaffelpunkten i dalområdets mittskelett omedelbart framför åsavslutningen. Om de tre benen i dalområdet tunnas ner till en skelettbild som är en enda pixel bred, är det skärningspunkten som är minutians läge. På samma sätt blir minutialäget för en förgrening förgreningspunkten för linjens mittskelett. Om de tre benen i åsen tunnas ner till en skelettbild som är en enda pixel bred är det skärningspunkten för de tre benen som är minutians läge.

När alla linjeslut har omvandlats till förgreningar, framställs alla minutiae i fingeravtrycksbilden som förgreningar. X- och Y-pixelkoordinaterna för skärningen av de tre benen i varje minutia kan direktformateras. Bestämning av minutiariktningen kan extraheras from varje skelettförgrening. De tre benen i varje skelettförgrening måste undersökas, och avslutningspunkten för varje ben bestämmas. Figur 6.1.2 illustrerar de tre metoder som används för att bestämma avslutningen på ett ben som grundar sig på en skanningsupplösning på 500 ppi.

Avslutningen fastställs i enlighet med det som först inträffar. Pixelantalet grundar sig på en skanningsupplösning på 500 ppi. Olika skanningsupplösningar innebär olika pixelantal.

—	Ett avstånd på .064 tum (den 32:a pixeln).

—	Avslutningen på skelettbenet som inträffar mellan ett avstånd på .02 tum och .064 tum (den 10:e till den 32:a pixeln. Kortare ben används ej.

—	En andra förgrening uppträder inom ett avstånd på .064 tum (före den 32:a pixeln).

Figur 6.1.2

Minutiavinkeln bestäms genom att man drar tre virtuella strålar som utgår från gaffelpunkten och fortsätter till avslutningen av varje ben. Den minsta av de tre vinklar som bildas av strålarna skärs av på mitten för att ange minutians riktning.

6.1.3   Koordinatsystem

Det koordinatsystem som används för att beskriva minutiae i ett fingeravtryck ska vara ett rätvinkligt koordinatsystem med två axlar. Läge för minutiae ska anges med deras x- och y-koordinater. Koordinatsystemet ska ha origo i det övre vänstra hörnet av den ursprungliga bilden, med x-axeln pekande åt höger och y-axeln pekande nedåt. Både x-koordinaten och y-koordinaten för en minutia ska anges i pixlar från origo. Det bör noteras att läget för origo och måttenheten inte stämmer med definitionen av typ 9-poster i ANSI/NIST-ITL 1-2000.

6.1.4   Minutiaeriktning

Vinklar ska uttryckas i vanlig matematisk form, med nollgrader åt höger och vinkelvärden som ökar moturs. Registrerade vinklar pekar i riktningen tillbaka längs åsen på en avslutning av åsen och mot dalens centrum på en förgrening. Enligt denna konvention avviker vinklarna 180 grader från vad som anges i definitionen poster av typ 9 i ANSI/NIST-ITL 1-2000.

6.2   Fält i poster av typ 9, INCITS-378-format

Samtliga fält i typ 9-poster ska registreras som ASCII-text. I denna posttyp med taggade fält tillåts inga binära fält.

6.2.1   Fält 9.001: Logisk postlängd (Logical record length – LEN)

I detta obligatoriska fält anges längden av den logiska posten som det sammanlagda antalet byte i varje fält i posten.

6.2.2   Fält 9.002: (Image Designation Character – IDC)

Detta obligatoriska fält om två positioner ska användas för att identifiera och ange läge för minutiaeuppgifterna. IDC i detta fält ska stämma överens med IDC i filinnehållsfältet i typ 1-posten.

6.2.3   Fält 9.003: (Impression Type – IMP)

Detta obligatoriska fält om en byte ska beskriva på vilket sätt informationen i fingeravtrycksbilden har erhållits. ASCII-värdet för rätt kod för avtryckstypen ur tabell 4 ska registreras i detta fält.

6.2.4   Fält 9.004: Minutiaeformat (Minutiæ format – FMT)

Detta fält ska innehålla ”U” för att ange att minutiae är formaterade enligt M1-378. Även om informationen kan ha kodats enligt M1-378-standarden, måste samtliga fält i typ 9-posten förbli fält med ASCII-text.

6.2.5   Fält 9.126: CBEFF-information (CBEFF-information)

Detta fält ska innehålla tre uppgifter. Den första uppgiften ska ha värdet ”27” (0x1B). Detta är en identifikation av ägaren av CBEFF-formatet som har tilldelats INCITS:s tekniska kommitté M1 av International Biometric Industry Association (IBIA). <US>-avgränsaren ska avgränsa denna uppgift från CBEFF-formattypen som har tilldelats värdet ”513” (0x0201), vilket anger att denna post endast innehåller uppgifter om läge och vinkelriktning utan att ange någon information ur Extended Data Block. <US>-avgränsaren ska avgränsa denna uppgift från CBEFF-produktidentifieraren (PID) som identifierar ”ägaren” av kodningsutrustningen. Det är säljaren som fastställer detta värde. Det kan erhållas från IBIA:s webbplats (www.ibia.org) om det har publicerats på webben.

6.2.6   Fält 9.127: Identifikation av upptagningsutrustning (Capture equipment identification)

Detta fält ska innehålla två uppgifter skilda åt med <US>-avgränsaren. Den första uppgiften ska innehålla ”APPF”, om den utrustning som användes för att ursprungligen ta upp bilden var certifierad att överensstämma med bilaga F (Bildkvalitetsspecifikation för IAFIS, 29 januari 1999) till FBI:s specifikation för överföring av fingeravtryck i elektronisk form CJIS-RS-0010. Om utrustningen inte överensstämmer med denna specifikation, ska fältet innehålla teckensträngen ”NONE”. Den andra uppgiften ska innehålla upptagningsutrustningens identifikationsbegrepp (Capture Equipment ID), ett produktnummer för upptagningsutrustningen som tilldelats av säljaren. Värdet ”0” anger att upptagningsutrustningens identifikationsbegrepp inte har rapporterats.

6.2.7   Fält 9.128: Horisontell linjelängd (Horizontal Line Length – HLL)

Detta obligatoriska ASCII-fält ska innehålla antalet pixel i en enstaka horisontell linje i den överförda bilden. Storleken i horisontell led är begränsad till 65 534 pixel.

6.2.8   Fält 9.129: Vertikal linjelängd (Vertical Line Length – VLL)

Detta obligatoriska ASCII-fält ska innehålla antalet horisontella linjer i den överförda bilden. Storleken i vertikal led är begränsad till 65 534 pixel.

6.2.9   Fält 9.130: Skalenheter (Scale units – SLC)

Detta obligatoriska ASCII-fält ska ange enhet för samplingsfrekvensen (pixeltätheten). ”1” i detta fält anger pixel per tum, ”2” anger pixel per centimeter. ”0” i detta fält betyder att ingen enhet har angivits. I detta fall ger kvoten HPS/VPS pixelsidförhållandet (pixel aspect ratio).

6.2.10   Fält 9.131: Horisontell pixelskala (Horizontal pixel scale – HPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i horisontell led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den horisontella komponenten av pixelsidförhållandet (pixel aspect ratio).

6.2.11   Fält 9.132: Vertikal pixelskala (Vertical pixel scale – VPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i vertikal led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den vertikala komponenten av pixelsidförhållandet (pixel aspect ratio).

6.2.12   Fält 9.133: Fingervy (Finger view)

Detta obligatoriska fält innehåller vynumret för det finger postens uppgifter avser. Vynumren börjar på ”0” och ökar till ”15” med steglängden ett.

6.2.13   Fält 9.134: Fingerposition (Finger Position – FGP)

Detta fält ska innehålla koden för den fingerposition som lämnade informationen i denna typ 9-post. En kod mellan 1 och 10 från tabell 5, eller rätt handflatekod från tabell 10, ska användas för att ange finger- eller handflateposition.

6.2.14   Fält 9.135: Fingerkvalitet (Finger quality)

Detta fält ska ange den sammanlagda kvaliteten för uppgifterna om fingerminutiae med ett värde mellan 0 och 100. Detta tal sammanfattar fingerpostens kvalitet och avspeglar originalbildens kvalitet, kvaliteten vid extrahering av minutiae och andra operationer som kan påverka minutiaeposten.

6.2.15   Fält 1.136: Minutiaeantal (Number of minutiae)

I detta obligatoriska fält ska antalet minutiae som registrerats i denna logiska post anges.

6.2.16   Fält 9.137: Uppgifter om fingerminutiae (Finger minutiæ data)

Detta fält ska innehålla sex uppgifter åtskilda med <US>-avgränsaren. Det består av flera delfält där vart och ett innehåller detaljerna för enskilda minutiae. Det totala antalet minutiaedelfält måste stämma överens med antalet i fält 136. Den första uppgiften är minutiaeindexnummer, som ska initialiseras till ”1” och ökas med ”1” för varje tillkommande minutia i fingeravtrycket. Den andra och den tredje uppgiften är x-koordinaten och y-koordinaterna för minutiae i pixelenheter. Den fjärde uppgiften är minutiaevinkeln angiven i enheter om två grader. Detta värde ska vara icke-negativt mellan 0 och 179. Den femte uppgiften är minitiaetypen. Ett värde av ”0” används för att representera minutiae av typen ”ANNAN”, ett värde av ”1” för en åsavslutning och ett värde av ”2” för en åsförgrening. Den sjätte uppgiften anger kvaliteten för varje minutiae. Värdet ska ligga mellan minst 1 och mest 100. Ett ”0”-värde anger att kvalitetsvärde saknas. Varje delfält ska skiljas från nästa delfält med <RS>-avgränsaren.

6.2.17   Fält 9.138: Uppgifter om åsantal (Ridge count information)

Fältet består av en serie delfält där vart och ett innehåller tre uppgifter. Den första uppgiften i det första delfältet ska ange metoden för extrahering av antal åsar. ”0” anger att metoden för att extrahera antalet åsar är okänd, liksom ordningen i posten. ”1” anger att för varje centrumminutia har uppgifter om åsantal tagits fram till närmaste angränsande minutia i fyra kvadranter, och åsantal för varje centrumminutia har förtecknats tillsammans. ”2” anger att för varje centrumminutia har uppgifter om åsantal tagits fram till närmaste grannminutia i fyra kvadranter, och åsantal för varje centrumminutia har förtecknats tillsammans. De återstående två uppgifterna i det första delfältet ska båda innehålla ”0”. Uppgifterna ska åtskiljas av <US>-avgränsaren. Följande delfält får centrumminutians indexnummer som första uppgift, indexnummer för angränsande minutiae som andra uppgift och antalet åsövergångar som tredje uppgift. Uppgifterna ska åtskiljas av <US>-avgränsaren.

6.2.18   Fält 9.139: Uppgifter om centrumpunkter (Core information)

Detta fält består av ett delfält för varje centrumpunkt i originalbilden. Varje delfält innehåller tre uppgifter. De första två uppgifterna innehåller x- och y-koordinatpositionerna i pixelenheter. Den tredje uppgiften innehåller centrumpunktens vinkel angiven i enheter om 2 grader. Detta värde ska vara icke-negativt mellan 0 och 179. Multipla centrumpunkter ska åtskiljas av <RS>-avgränsaren.

6.2.19   Fält 9.140: Deltauppgifter (Delta information)

Detta fält består av ett delfält för varje deltapunkt i originalbilden. Varje delfält innehåller tre uppgifter. De första två uppgifterna innehåller x- och y-koordinatpositionerna i pixelenheter. Den tredje uppgiften innehåller deltapunktens vinkel angiven i enheter av 2 grader. Detta värde ska vara icke-negativt mellan 0 och 179. Multipla centrumpunkter ska åtskiljas av <RS>-avgränsaren.

7.   Post typ 13: Bilder av latenta avtryck med varierande upplösning

Logisk post av typ 13 med taggade fält ska innehålla data från bilder av latenta avtryck. Dessa bilder är avsedda att överföras till organ som automatiskt extraherar eller använder mänsklig intervention och behandling för att extrahera den önskade detaljinformationen från bilderna.

Uppgifter om skanningsupplösning, bildstorlek och andra parametrar som krävs för att behandla bilden registreras som taggade fält inom posten.

Tabell 7: Post typ 13: Bilder av latenta avtryck med varierande upplösning

Ident	Cond. code	Field Number	Field Name	Char type	Field size per occurrence		Occur count		Max byte count
					min.	max.	min	max
LEN	M	13 001	LOGICAL RECORD LENGTH	N	4	8	1	1	15
IDC	M	13 002	IMAGE DESIGNATION CHARACTER	N	2	5	1	1	12
IMP	M	13 003	IMPRESSION TYPE	A	2	2	1	1	9
SRC	M	13 004	SOURCE AGENCY/ORI	AN	6	35	1	1	42
LCD	M	13 005	LATENT CAPTURE DATE	N	9	9	1	1	16
HLL	M	13 006	HORIZONTAL LINE LENGTH	N	4	5	1	1	12
VLL	M	13 007	VERTICAL LINE LENGTH	N	4	5	1	1	12
SLC	M	13 008	SCALE UNITS	N	2	2	1	1	9
HPS	M	13 009	HORIZONTAL PIXEL SCALE	N	2	5	1	1	12
VPS	M	13 010	VERTICAL PIXEL SCALE	N	2	5	1	1	12
CGA	M	13 011	COMPRESSION ALGORITHM	A	5	7	1	1	14
BPX	M	13 012	BITS PER PIXEL	N	2	3	1	1	10
FGP	M	13 013	FINGER POSITION	N	2	3	1	6	25
RSV		13 014 13 019	RESERVED FOR FUTURE DEFINITION	—	—	—	—	—	—
COM	O	13 020	COMMENT	A	2	128	0	1	135
RSV		13 021 13 199	RESERVED FOR FUTURE DEFINITION	—	—	—	—	—	—
UDF	O	13 200 13 998	USER-DEFINED FIELDS	—	—	—	—	—	—
DAT	M	13 999	IMAGE DATA	B	2	—	1	1	—

Nyckel för teckentyp: N = numerisk, A = alfabetisk, AN = alfanumerisk, B = binär

7.1   Fält i logisk post typ 4

Följande stycken beskriver uppgifterna i vart och ett av fälten för logisk post typ 13.

Inom en logisk post typ 13 ska registreringar läggas in i numrerade fält. De första två fälten i posten måste vara i rätt ordning, och fältet med bilduppgifterna ska vara det sista fysiska fältet i posten. För varje fält i typ 13-posten förtecknas i tabell 7 koden ”Beroende på tillgång på uppgifter” (”condition code”) som obligatorisk ”M” eller frivillig/valfri ”O”, fältnummer, fältbenämning, teckentyp, fältstorlek och förekomstgränser. Maximal storlek för fältet, uttryckt i antal byte och grundad på ett treställigt fältnummer, anges i sista kolumnen. När fler siffror används för fältnumret ökar också maximalt antal byte. De två registreringarna i fältstorlek per förekomst (”field size per occurrence”) inkluderar alla teckenavgränsare i fältet. Maximalt antal byte (”Maximum byte count”) inkluderar fältnummer, uppgifter och alla teckenavgränsare inklusive <GS>-avgränsaren.

7.1.1   Fält 13.001: Logisk postlängd (Logical record length – LEN)

I detta obligatoriska fält anges det totala antalet byte i hela logisk post typ 1. I fält 13.001 anges postens längd inklusive alla tecken i alla fält i posten samt uppgiftsavgränsare.

7.1.2   Fält 13.002: Bilddesigneringstecken (Image Designation Character – IDC)

Detta obligatoriska ASCII-fält ska användas för att identifiera bilduppgifterna om latent avtryck i posten. Detta IDC ska matcha IDC i fältet för filinnehåll (CNT) i typ 1-posten.

7.1.3   Fält 13.003: Avtryckstyp (Impression Type – IMP)

Detta obligatoriska fält om en eller två byte ska beskriva på vilket sätt bildinformationen om det latenta avtrycket har erhållits. Korrekt latentkod från tabell 4 (finger) eller tabell 9 (handflata) ska föras in i detta fält.

7.1.4   Fält 13.004: Källorgan (Source agency/ORI – SRC)

Detta obligatoriska ASCII-fält ska innehålla identifikation av den myndighet eller organisation som ursprungligen tog upp ansiktsbilden i posten. Normalt sett är det ursprungsorgansidentifieraren för det organ som tog upp bilden som ska stå i detta fält. Det består av två uppgifter i följande format: CC/organ.

Den första uppgiften består av Interpols landskod om två alfanumeriska tecken. Den andra uppgiften, organ, identifierar organet genom en sträng fri text om maximalt 32 alfanumeriska tecken.

7.1.5   Fält 13.005: Upptagningsdatum för latent avtryck (Latent capture date – LCD)

Detta obligatoriska ASCII-fält ska innehålla datum för upptagningen av den latenta bilden i posten. Datum skrivs som åtta siffror i formatet CCYYMMDD. CCYY-tecknen står för året för upptagningen av bilden. MM-tecknen är månadens tiotals- och enhetsvärden och DD-tecknen tiotals- och enhetsvärden för dagen i månaden. Till exempel står 20000229 för den 29 februari 2000. Fullständigt datum måste vara ett riktigt datum.

7.1.6   Fält 13.065: Horisontell linjelängd (Horizontal Line Length – HLL)

Detta obligatoriska ASCII-fält ska innehålla antalet pixel i en enstaka horisontell linje i den överförda bilden.

7.1.7   Fält 13.007: Vertikal linjelängd (Vertical Line Length – VLL)

Detta obligatoriska ASCII-fält ska innehålla antalet horisontella linjer i den överförda bilden.

7.1.8   Fält 13.008: Skalenheter (Scale units – SLC)

Detta obligatoriska ASCII-fält ska ange enhet för samplingsfrekvensen (pixeltätheten). ”1” i detta fält anger pixel per tum, ”2” anger pixel per centimeter. ”0” i detta fält betyder att ingen enhet har angivits. I detta fall ger kvoten HPS/VPS pixelsidförhållandet (pixel aspect ratio).

7.1.9   Fält 13.009: Horisontell pixelskala (Horizontal pixel scale – HPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i horisontell led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den horisontella komponenten av pixelsidförhållandet (pixel aspect ratio).

7.1.10   Fält 13.010: Vertikal pixelskala (Vertical pixel scale – VPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i vertikal led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den vertikala komponenten av pixelsidförhållandet (pixel aspect ratio).

7.1.11   Fält 13.011: Komprimeringsalgoritm (Compression algoritm – CGA)

Detta obligatoriska ASCII-fält ska ange den algoritm som används för att komprimera gråskalebilder. Komprimeringskoderna anges i bilaga 7.

7.1.12   Fält 13.012: Bitar per pixel (Bits per pixel – BPX)

Detta obligatoriska ASCII-fält ska innehålla antalet bitar som används för en pixel. I detta fält står ”8” för normala gråskalevärden från ”0” till ”255”. Alla värden i detta fält som är större än ”8” står för gråskalepixel med högre precision.

7.1.13   Fält 13.013: Fingerposition/handflateposition (Finger/Palm Position – FGP)

Detta obligatoriska taggade fält ska innehålla en eller flera av de möjliga finger-/handflatepositioner som kan matcha den latenta bilden. Det decimalkodsnummer som motsvarar den kända eller mest troliga fingerpositionen ska tas från tabell 5 eller den mest troliga handflatepositionen från tabell 10 och föras in som ett ASCII-delfält med ett eller två tecken. Ytterligare finger- och/eller handflatepositioner kan registreras genom att man lägger in alternerande positionskoder som delfält åtskilda av RS-avgränsaren. Koden ”0” för ”Okänt finger” ska användas för att registrera varje fingerposition från ett till tio. Koden ”20” för ”Okänd handflata” ska användas för att registrera varje handflateposition i förteckningen.

7.1.14   Fält 13.014-019: Reserverad för framtida definition (Reserved for future definition – RSV)

Dessa fält har reserverats för att ingå i framtida revisioner av denna standard. Inget av dessa fält får användas i denna revision. Om något av fälten förekommer ska de lämnas utan avseende.

7.1.15   Fält 13.020: Kommentar (Comment COM)

Detta frivilliga fält kan användas för kommentarer eller annan information i ASCII-text med uppgifter om latent bild.

7.1.16   Fält 13.021-199: Reserverad för framtida definition (Reserved for future definition – RSV)

Dessa fält har reserverats för att ingå i framtida revisioner av denna standard. Inget av dessa fält får användas i denna revision. Om något av fälten förekommer ska de lämnas utan avseende.

7.1.17   Fält 13.200-998: Användardefinierade fält (User-defined fields – UDF)

Dessa fält är användardefinierade fält och kommer att användas för framtida behov. Deras storlek och innehåll ska definieras av användaren i enlighet med det mottagande organet. Om de förekommer ska de innehålla information i ASCII-text.

7.1.18   Fält 13.999: Bilduppgifter (Image data – DAT)

Detta fält ska innehålla alla uppgifter från en upptagen latent bild. Det ska alltid få fältnummer 999 och måste vara det sista fysiska fältet i posten. Till exempel följs ”13.999” av bilduppgifter i binärt format.

Varje pixel av okomprimerade gråskaleuppgifter ska normalt kvantifieras till åtta bitar (256 grå nivåer) i en enda byte. Om värdet i BPX-fältet 13.102 är större än eller mindre än ”8” får man ett annat antal byte som krävs för att innehålla en pixel. Om komprimering används ska pixeluppgifterna komprimeras i enlighet med den komprimeringsteknik som anges i GCA-fältet.

7.2   Avslutning post typ 13: Latenta bilder med varierande upplösning

Omedelbart efter sista byte uppgifter från fält 13.199 ska för konsekvensens skull en <FS>-avgränsare användas för att avgränsa den från nästa logiska post. Denna avgränsare måste inkluderas i typ 13-postens längdfält.

8.   Post typ 15: Bilder av handavtryck med varierande upplösning

Det taggade fältet i logisk post typ 15 ska innehålla och användas för att utbyta uppgifter om handflateavtryck tillsammans med fasta och användardefinierade textinformationsfält avseende den digitaliserade bilden. Uppgifter om skanningsupplösning, bildstorlek och andra parametrar eller kommentarer som krävs för att behandla bilden registreras som taggade fält inom posten. Handflateavtrycksbilder som översänds till andra organ kommer att behandlas av de mottagande organen för att extrahera den önskade detaljinformation som krävs för matchning.

Bilduppgifterna fås direkt från en person med hjälp av en livescan-utrustning eller från en handflateavtrycksblankett eller annat medium som innehåller personens handflateavtryck.

Alla metoder som används för att få fram bilder av handflateavtrycket ska också medge upptagning av en uppsättning bilder för varje hand. Denna uppsättning ska inkludera handflatans yttre kant som en enda skannad bild och hela området för hela handen från handleden till fingertopparna som en eller två skannade bilder. Om två bilder används för att visa hela handflatan, ska den nedre bilden visa området från handleden till övre delen av området mellan fingrarna (tredje fingerleden) inklusive områdena kring handflatans tumvalk och lillfingervalk. Den övre bilden ska visa området från nedre delen av det interdigitala området till de översta fingertopparna. Detta ger tillräcklig överlappning mellan de två bilderna som båda visar handflateområdet mellan fingrarna. Genom att matcha åsstrukturen och detaljerna i detta gemensamma område kan en undersökare med tillförlitlighet konstatera att båda bilderna kom från samma handflata.

Eftersom en handavtryckstransaktion kan användas för olika ändamål, kan det innehålla ett eller flera unika bildområden registrerade från handflatan eller handen. En fullständig registrering av ett handflateavtryck från en individ inkluderar normalt handflatans yttre kant och fullständig/a bild/er av varje handflata. Eftersom en logisk bildpost med taggade fält kan innehålla endast ett binärt fält, kommer det att krävas en enda typ 15-post för varje handflatekant och en eller två typ 15-poster för varje fullständig handflata. Därför behövs det fyra till sex typ 15-poster för att visa personens handflateavtryck i en normal transaktion med handflateavtryck.

8.1   Fält i logisk post typ 15

Följande stycken beskriver uppgifterna i vart och ett av fälten för logisk post typ 15.

Inom en logisk post typ 15 ska registreringar läggas in i numrerade fält. De första två fälten i posten måste vara i rätt ordning, och fältet med bilduppgifterna ska vara det sista fysiska fältet i posten. För varje fält i typ 15-posten förtecknas i tabell 8 korskoden ”Beroende av tillgång på uppgifter” (”condition code”) som obligatorisk ”M” eller frivillig/valfri ”O”, fältnummer, fältbenämning, teckentyp, fältstorlek och förekomstgränser. Maximal storlek för fältet, uttryckt i antal byte och grundad på ett treställigt fältnummer, anges i sista kolumnen. När fler siffror används för fältnumret ökar också maximalt antal byte. De två registreringarna i fältstorlek per förekomst (”field size per occurrence”) inkluderar alla teckenavgränsare i fältet. Maximalt antal byte (”Maximum byte count”) inkluderar fältnummer, uppgifter och alla teckenavgränsare inklusive GS-avgränsaren.

8.1.1   Fält 15.001: Logisk postlängd (Logical record length – LEN)

I detta obligatoriska ASCII-fält anges det totala antalet byte i hela den logiska posten av typ 15. I fält 15.001 ska anges postens längd inklusive alla tecken i alla fält i posten samt uppgiftsavgränsare.

8.1.2   Fält 15.002: Bildbenämningstecken (Image Designation Character – IDC)

Detta obligatoriska ASCII-fält ska användas för att identifiera uppgifterna om handflateavtrycksbilden i posten. Detta IDC ska matcha IDC i fältet för filinnehåll (CNT) i typ 1-posten.

8.1.3   Fält 15.003: Avtryckstyp (Impression Type – IMP)

Detta obligatoriska ASCII-fält om en byte ska ange på vilket sätt informationen i handavtrycksbilden har erhållits. Korrekt kod från tabell 9 ska föras in i detta fält.

8.1.4   Fält 15.004: Källorgan (Source agency/ORI – SRC)

Detta obligatoriska ASCII-fält ska innehålla identifikation av den myndighet eller organisation som ursprungligen tog upp ansiktsbilden i posten. Normalt sett är det ursprungsorgansidentifieraren för det organ som tog upp bilden som ska stå i detta fält. Det består av två uppgifter i följande format: CC/organ.

Den första uppgiften består av Interpols landskod om två alfanumeriska tecken. Den andra uppgiften, organ, identifierar organet genom en sträng fri text om maximalt 32 alfanumeriska tecken.

8.1.5   Fält 15.005: Upptagningsdatum för handflateavtrycket (Palmprint capture date – PCD)

Detta obligatoriska ASCII-fält ska ange datum för upptagningen av handflateavtrycket. Datum skrivs som åtta siffror i formatet CCYYMMDD. CCYY-tecknen står för året för upptagningen av bilden. MM-tecknen ska ange tiotals- och entalssiffran för månaden och DD-tecknen tiotals- och entalssiffran för dagen i månaden. Till exempel står 20000229 för den 29 februari 2000. Fullständigt datum måste vara ett verkligt datum.

8.1.6   Fält 15.006: Horisontell linjelängd (Horizontal Line Length – HLL)

Detta obligatoriska ASCII-fält ska innehålla antalet pixlar i en enstaka horisontell linje i den överförda bilden.

8.1.7   Fält 15.007: Vertikal linjelängd (Vertical Line Length – VLL)

Detta obligatoriska ASCII-fält ska ange antalet horisontella linjer i den överförda bilden.

8.1.8   Fält 15.008: Skalenheter (Scale units – SLC)

Detta obligatoriska ASCII-fält ska ange enhet för samplingsfrekvensen (pixeltätheten). ”1” i detta fält anger pixel per tum, ”2” anger pixel per centimeter. ”0” i detta fält betyder att ingen enhet har angivits. I detta fall ger kvoten HPS/VPS pixelsidförhållandet (pixel aspect ratio).

8.1.9   Fält 15.009: Horisontell pixelskala (Horizontal pixel scale – HPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i horisontell led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den horisontella komponenten av pixelsidförhållandet (pixel aspect ratio).

8.1.10   Fält 15.010: Vertikal pixelskala (Vertical pixel scale – VPS)

Detta obligatoriska ASCII-fält ska ange heltalsvärdet av pixeltätheten i vertikal led, förutsatt att SLC innehåller ”1” eller ”2”. I annat fall anger det den vertikala komponenten av pixelsidförhållandet (pixel aspect ratio).

Tabell 8: Post typ 15: Bilder av handflateavtryck med varierande upplösning

Ident	Cond. code	Field Number	Field Name	Char type	Field size per occurrence		Occur count		Max byte count
					min.	max.	min.	max.
LEN	M	15 001	LOGICAL RECORD LENGTH	N	4	8	1	1	15
IDC	M	15 002	IMAGE DESIGNATION CHARACTER	N	2	5	1	1	12
IMP	M	15 003	IMPRESSION TYPE	N	2	2	1	1	9
SRC	M	15 004	SOURCE AGENCY/ORI	AN	6	35	1	1	42
PCD	M	15 005	PALMPRINT CAPTURE DATE	N	9	9	1	1	16
HLL	M	15 006	HORIZONTAL LINE LENGTH	N	4	5	1	1	12
VLL	M	15 007	VERTICAL LINE LENGTH	N	4	5	1	1	12
SLC	M	15 008	SCALE UNITS	N	2	2	1	1	9
HPS	M	15 009	HORIZONTAL PIXEL SCALE	N	2	5	1	1	12
VPS	M	15 010	VERTICAL PIXEL SCALE	N	2	5	1	1	12
CGA	M	15 011	COMPRESSION ALGORITHM	AN	5	7	1	1	14
BPX	M	15 012	BITS PER PIXEL	N	2	3	1	1	10
PLP	M	15 013	PALMPRINT POSITION	N	2	3	1	1	10
RSV		15 014 15 019	RESERVED FOR FUTURE INCLUSION	—	—	—	—	—	—
COM	O	15 020	COMMENT	AN	2	128	0	1	128
RSV		15 021 15 199	RESERVED FOR FUTURE INCLUSION	—	—	—	—	—	—
UDF	O	15 200 15 998	USER-DEFINED FIELDS	—	—	—	—	—	—
DAT	M	15 999	IMAGE DATA	B	2	—	1	1	—

Tabell 9: Handflateavtryckstyp

Description	Code
Live-scan palm	10
Nonlive-scan palm	11
Latent palm impression	12
Latent palm tracing	13
Latent palm photo	14
Latent palm lift	15

8.1.11   Fält 15.011: Komprimeringsalgoritm (Compression algoritm – CGA)

Detta obligatoriska ASCII-fält ska ange den algoritm som används för att komprimera gråskalebilder. ”NONE” i detta fält anger att uppgifterna i denna post inte har komprimerats. För de uppgifter som ska komprimeras ska detta fält innehålla den metod som valts för komprimering av fingeravtrycksbilder av 10 fingrar. Giltiga komprimeringskoder definieras i bilaga 7.

8.1.12   Fält 15.012: Bitar per pixel (Bits per pixel – BPX)

Detta obligatoriska ASCII-fält ska innehålla antalet bitar som används för en pixel. I detta fält ska ”8” stå för normala gråskalevärden från ”0” till ”255”. Alla värden i detta fält som är större än eller mindre än ”8” står för en gråskalepixel med högre respektive lägre precision.

Tabell 10: Handflatekoder, områden och storlekar

Palm Position	Palm code	Image area (mm2)	Width (mm)	Height (mm)
Unknown Palm	20	28 387	139,7	203,2
Right Full Palm	21	28 387	139,7	203,2
Right Writer s Palm	22	5 645	44,5	127,0
Left Full Palm	23	28 387	139,7	203,2
Left Writer s Palm	24	5 645	44,5	127,0
Right Lower Palm	25	19 516	139,7	139,7
Right Upper Palm	26	19 516	139,7	139,7
Left Lower Palm	27	19 516	139,7	139,7
Left Upper Palm	28	19 516	139,7	139,7
Right Other	29	28 387	139,7	203,2
Left Other	30	28 387	139,7	203,2

8.1.13   Fält 15.013: Handavtrycksposition (Palmprint position – PLP)

Detta obligatoriska taggade fält ska innehålla den handavtrycksposition som matchar bilden av handflateavtrycket. Det decimalkodsnummer som motsvarar den kända eller mest troliga handavtryckspositionen ska tas från tabell 10 och föras in som ett ASCII-delfält med ett eller två tecken. Tabell 10 listar också maximala bildområden och dimensioner för var och en av de möjliga positionerna för handavtrycken.

8.1.14   Fält 15.014-019: Reserverad för framtida definition (Reserved for future definition – RSV)

Dessa fält har reserverats för att ingå i framtida revisioner av denna standard. Inget av dessa fält får användas i denna revision. Om något av fälten förekommer ska de lämnas utan avseende.

8.1.15   Fält 15.020: Kommentar (Comment – COM)

Detta frivilliga fält kan användas för kommentarer eller annan information i ASCII-text med uppgifter om handavtrycksbild.

8.1.16   Fält 15.021-199: Reserverad för framtida definition (Reserved for future definition – RSV)

Dessa fält har reserverats för att ingå i framtida revisioner av denna standard. Inget av dessa fält får användas i denna revision. Om något av fälten förekommer ska de lämnas utan avseende.

8.1.17   Fält 15.200-998: Användardefinierade fält (User-defined fields – UDF)

Dessa fält är användardefinierade fält och kommer att användas för framtida behov. Deras storlek och innehåll ska definieras av användaren i enlighet med det mottagande organet. Om de förekommer ska de innehålla information i ASCII-text.

8.1.18   Fält 15.999: Bilduppgifter (Image data – DAT)

Detta fält ska innehålla alla uppgifter om en upptagen handavtrycksbild. Det ska alltid tilldelas fältnummer 999 och måste vara det sista fysiska fältet i posten. Till exempel ”15.999” följs av bilduppgifter i binärt format. Varje pixel av okomprimerade gråskaleuppgifter ska normalt kvantifieras till åtta bitar (256 grå nivåer) i en enda byte. Om värdet i BPX-fältet 15.012 är större än eller mindre än ”8” får man ett annat antal byte som krävs för att innehålla en pixel. Om komprimering används ska pixeluppgifterna komprimeras i enlighet med den komprimeringsteknik som anges i CGA-fältet.

8.2   Avslutning post typ 15: Handavtrycksbilder med varierande upplösning

Omedelbart efter sista byte av uppgifter från fält 15.999 ska för konsekvensens skull en <FS>-avgränsare användas för att avgränsa den från nästa logiska post. Denna avgränsare måste inkluderas i typ 15-postens längdfält.

8.3   Ytterligare handavtrycksbilder av post typ 15 med varierande upplösning

Ytterligare typ 15-poster kan inkluderas i filen. För varje ytterligare handavtrycksbild krävs en fullständig logisk post typ 15 tillsammans med <FS>-avgränsaren.

Tabell 11: Högsta för verifiering godtagna antal kandidater per sändning

Type of AFIS Search	TP/TP	LT/TP	LP/PP	TP/UL	LT/UL	PP/ULP	LP/ULP
Maximum Number of Candidates	1	10	5	5	5	5	5

Sökningstyper:

TP/TP: tiofingersavtryck mot tiofingersavtryck

LP/TP: latent fingeravtryck mot tiofingersavtryck

LP/PP: latent handflateavtryck mot handflateavtryck

TP/UL: tiofingersavtryck mot olöst latent fingeravtryck

LT/UL: latent fingeravtryck mot olöst latent fingeravtryck

PP/ULP: handflateavtryck mot olöst latent handflateavtryck

LP/ULP: latent handflateavtryck mot olöst latent handflateavtryck

9.   Bilagor till kapitel 2 (utbyte av finger- och handavtrycksuppgifter)

9.1   Bilaga 1 ASCII-koder för avgränsare

ASCII	Position (2)	Description
LF	1/10	Separates error codes in field 2.074
FS	1/12	Separates logical records of a file
GS	1/13	Separates fields of a logical record
RS	1/14	Separates the subfields of a record field
US	1/15	Separates individual information items of the field or subfield

9.2   Bilaga 2 Beräkning av alfanumeriskt kontrolltecken

För TCN och TCR (Fält 1.09 och 1.10)

Det tal som motsvarar kontrolltecknet genereras enligt följande formel:

(YY * 108 + SSSSSSSS) Modulo 23

där YY and SSSSSSSS är de numeriska värdena av de sista två siffrorna för år respektive serienummer.

Kontrolltecknet genereras sedan ur tabellen nedan.

För CRO (Fält 2.010)

Det tal som motsvarar kontrolltecknet genereras enligt följande formel:

(YY * 106 + NNNNNN) Modulo 23

där YY and SSSSSSSS är de numeriska värdena av de sista två siffrorna för år respektive serienummer.

Kontrolltecknet genereras sedan ur tabellen nedan.

Kontrollteckentabell

1-A	9-J	17-T
2-B	10-K	18-U
3-C	11-L	19-V
4-D	12-M	20-W
5-E	13-N	21-X
6-F	14-P	22-Y
7-G	15-Q	0-Z
8-H	16-R

9.3   Bilaga 3 Teckenkoder

7-bitars ANSI-kod för informationsutbyte

ASCII Character Set
+	0	1	2	3	4	5	6	7	8	9
30				!	”	#	$	%	&	’
40	(	)	*	+	,	—	.	/	0	1
50	2	3	4	5	6	7	8	9	:	;
60	<	=	>	?	@	A	B	C	D	E
70	F	G	H	I	J	K	L	M	N	O
80	P	Q	R	S	T	U	V	W	X	Y
90	Z	[	\	]	^	_	`	a	b	c
100	d	e	f	g	h	i	j	k	l	m
110	n	o	p	q	r	s	t	u	v	w
120	x	y	z	{	|	}	~

9.4   Bilaga 4 Sammanfattning av transaktioner

Post typ 1 (obligatorisk)

Identifier	Field Number	Field Name	CPS/PMS	SRE	ERR
LEN	1.001	Logical Record Length	M	M	M
VER	1.002	Version Number	M	M	M
CNT	1.003	File Content	M	M	M
TOT	1.004	Type of Transaction	M	M	M
DAT	1.005	Date	M	M	M
PRY	1.006	Priority	M	M	M
DAI	1.007	Destination Agency	M	M	M
ORI	1.008	Originating Agency	M	M	M
TCN	1.009	Transaction Control Number	M	M	M
TCR	1.010	Transaction Control Reference	C	M	M
NSR	1.011	Native Scanning Resolution	M	M	M
NTR	1.012	Nominal Transmitting Resolution	M	M	M
DOM	1.013	Domain name	M	M	M
GMT	1.014	Greenwich mean time	M	M	M

Under villkorskolumnen:

O = frivilligt, M = obligatoriskt, C = beroende på om transaktionen är ett svar till ursprungsorganet

Post typ 2 (obligatorisk)

Identifier	Field Number	Field Name	CPS/PMS	MPS/MMS	SRE	ERR
LEN	2.001	Logical Record Length	M	M	M	M
IDC	2.002	Image Designation Character	M	M	M	M
SYS	2.003	System Information	M	M	M	M
CNO	2.007	Case Number	—	M	C	—
SQN	2.008	Sequence Number	—	C	C	—
MID	2.009	Latent Identifier	—	C	C	—
CRN	2.010	Criminal Reference Number	M	—	C	—
MN1	2.012	Miscellaneous Identification Number	—	—	C	C
MN2	2.013	Miscellaneous Identification Number	—	—	C	C
MN3	2.014	Miscellaneous Identification Number	—	—	C	C
MN4	2.015	Miscellaneous Identification Number	—	—	C	C
INF	2.063	Additional Information	O	O	O	O
RLS	2.064	Respondents List	—	—	M	—
ERM	2.074	Status/Error Message Field	—	—	—	M
ENC	2.320	Expected Number of Candidates	M	M	—	—

Under kolumnen ”Condition”:

O = frivilligt, M = obligatoriskt, C = beroende av tillgängliga uppgifter

*

=

om översändningen av uppgifterna är i enlighet med nationell lag (omfattas ej av beslut 2008/615/RIF)

9.5   Bilaga 5 Post typ 1 definitioner

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	1.001	Logical Record Length	N	1.001:230{GS}
VER	M	1.002	Version Number	N	1.002:0300{GS}
CNT	M	1.003	File Content	N	1.003:1{US}15{RS}2{US}00{RS}4{US}01{RS}4{US}02{RS}4{US}03{RS}4{US}04{RS}4{US}05{RS}4{US}06{RS}4{US}07{RS}4{US}08{RS}4{US}09{RS}4{US}10{RS}4{US}11{RS}4{US}12{RS}4{US}13{RS}4{US}14{GS}
TOT	M	1.004	Type of Transaction	A	1.004:CPS{GS}
DAT	M	1.005	Date	N	1.005:20050101{GS}
PRY	M	1.006	Priority	N	1.006:4{GS}
DAI	M	1.007	Destination Agency	1*	1.007:DE/BKA{GS}
ORI	M	1.008	Originating Agency	1*	1.008:NL/NAFIS{GS}
TCN	M	1.009	Transaction Control Number	AN	1.009:0200000004F{GS}
TCR	C	1.010	Transaction Control Reference	AN	1.010:0200000004F{GS}
NSR	M	1.011	Native Scanning Resolution	AN	1.011:19.68{GS}
NTR	M	1.012	Nominal Transmitting Resolution	AN	1.012:19.68{GS}
DOM	M	1.013	Domain Name	AN	1.013: INT-I{US}4.22{GS}
GMT	M	1.014	Greenwich Mean Time	AN	1.014:20050101125959Z

Under kolumnen ”Condition”: O = frivillig, M = obligatorisk, C = beroende av tillgängliga uppgifter

Under teckentypkolumn: A = Alfa, N = Numerisk, B = Binär

1* tillåtna tecken för organets namn är [”0...9”, ”A...Z”, ”a...z”, ”_”,”.”, ””, ”-”]

9.6   Bilaga 6 Post typ 2 definitioner

Tabell A.6.1: CPS- och PMS-transaktion

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
CRN	M	2.010	Criminal Reference Number	AN	2.010:DE/E999999999{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
ENC	M	2.320	Expected Number of Candidates	N	2.320:1{GS}

Tabell A.6.2: SRE-Transaktion

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
CRN	C	2.010	Criminal Reference Number	AN	2.010:NL/2222222222{GS}
MN1	C	2.012	Miscellaneous Identification Number	AN	2.012:E999999999{GS}
MN2	C	2.013	Miscellaneous Identification Number	AN	2.013:E999999999{GS}
MN3	C	2.014	Miscellaneous Identification Number	N	2.014:0001{GS}
MN4	C	2.015	Miscellaneous Identification Number	A	2.015:A{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
RLS	M	2.064	Respondents List	AN	2.064:CPS{RS}I{RS}001/001{RS}999999{GS}

Tabell A.6.3: ERR-transaktion

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
MN1	M	2.012	Miscellaneous Identification Number	AN	2.012:E999999999{GS}
MN2	C	2.013	Miscellaneous Identification Number	AN	2.013:E999999999{GS}
MN3	C	2.014	Miscellaneous Identification Number	N	2.014:0001{GS}
MN4	C	2.015	Miscellaneous Identification Number	A	2.015:A{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
ERM	M	2.074	Status/Error Message Field	AN	2.074: 201: IDC - 1 FIELD 1 009 WRONG CONTROL CHARACTER {LF} 115: IDC 0 FIELD 2 003 INVALID SYSTEM INFORMATION {GS}

Tabell A.6.4: MPS- och MMS-transaktion

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
CNO	M	2.007	Case Number	AN	2.007:E999999999{GS}
SQN	C	2.008	Sequence Number	N	2.008:0001{GS}
MID	C	2.009	Latent Identifier	A	2.009:A{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
ENC	M	2.320	Expected Number of Candidates	N	2.320:1{GS}

Under kolumnen ”Condition”: O = frivillig, M = obligatorisk, C = beroende av tillgängliga uppgifter

Under teckentypkolumn: A = Alfa, N = Numerisk, B = Binär

1* tillåtna tecken är [”0...9”, ”A...Z”, ”a...z”, ”_”,”.”, ””, ”-”]

9.7   Bilaga 7 Koder för gråskalekomprimering

Komprimeringskoder

Compression	Value	Remarks
Wavelet Scalar Quantization Grayscale Fingerprint Image Compression Specification IAFIS-IC-0010(V3), dated December 19, 1997	WSQ	Algorithm to be used for the compression of grayscale images in Type-4, Type-7 and Type-13 to Type-15 records. Shall not be used for resolutions > 500dpi.
JPEG 2000 [ISO 15444/ITU T.800]	J2K	To be used for lossy and losslessly compression of grayscale images in Type-13 to Type-15 records. Strongly recommended for resolutions > 500 dpi

9.8   Bilaga 8 E-postspecifikation

För att förbättra det interna arbetsflödet måste ärenderubriken för en Prümtransaktion fyllas i med landskod (CC) för den medlemsstat som sänt meddelandet och även typ av transaktion (TOT-fältet 1.004).

Format: CC/transaktionstyp

Exempel: ”DE/CPS”

Fältet för meddelandetext kan vara tomt.

KAPITEL 3: Utbyte av uppgifter i fordonsregister

1.   Gemensam uppsättning uppgifter för automatiserad sökning i fordonsregister

1.1   Definitioner

Definitionerna av obligatoriska och frivilliga uppgifter enligt artikel 16.4 är följande:

Obligatoriska uppgifter (M)

Uppgiften måste vidarebefordras när informationen är tillgänglig i en medlemsstats nationella register. Det finns därför en skyldighet att utbyta uppgifterna när de finns tillgängliga.

Frivilliga uppgifter (O)

Uppgiften får vidarebefordras när informationen är tillgänglig i en medlemsstats nationella register. Det finns därför ingen skyldighet att utbyta uppgifterna även om de finns tillgängliga.

Beteckningen (Y) används för varje uppgift i uppsättningen uppgifter som anses vara särskilt viktig med avseende på beslut 2008/615/RIF.

1.2   Sökning på fordon/ägare/innehavare

1.2.1   Sökkriterier

Det finns två olika sätt att söka efter uppgifterna, nämligen

—	på fordonets identifieringsnummer (VIN), referensdatum och referenstid (frivilliga uppgifter),

—	på numret på registreringsskylten, identifieringsnumret (VIN), referensdatum och referenstid (frivilliga uppgifter).

Med hjälp av dessa sökkriterier får man uppgifter om ett eller flera fordon. Om uppgifterna endast gäller ett fordon lämnas samtliga uppgifter i ett svar. Om fler än ett fordon har hittats kan den tillfrågade medlemsstaten själv besluta vilka uppgifter som ska lämnas ut: alla uppgifter eller endast de uppgifter som behövs för att begränsa sökningen (t.ex. av integritetsskäl eller prestandaskäl).

De uppgifter som behövs för att begränsa sökningen anges i punkt 1.2.2.1. I punkt 1.2.2.2 beskrivs den fullständiga uppsättningen uppgifter.

När man söker på identifieringsnummer, referensdatum och referenstid kan sökningen göras i en eller alla deltagande medlemsstater.

När man söker på registreringsnummer, referensdatum och referenstid måste sökningen göras i en viss medlemsstat.

Vanligen används nuvarande datum och tid för sökningen, men det är möjligt att göra en sökning med ett referensdatum och en referenstid i det förflutna. Om man gör en sökning med ett referensdatum och en referenstid i det förflutna, och historiska uppgifter inte finns tillgängliga i en viss medlemsstats register eftersom sådana uppgifter inte registreras över huvud taget, kan de aktuella uppgifterna komma upp som sökresultat med en angivelse om att det rör sig om aktuella uppgifter.

1.2.2   Uppsättning uppgifter

1.2.2.1

Uppgifter som behövs för att begränsa sökningen Item M/O (3) Remarks Prüm Y/N (4) Data relating to vehicles       Licence number M   Y Chassis number/VIN M   Y Country of registration M   Y Make M (D.1 (5)) e.g. Ford, Opel, Renault etc. Y Commercial type of the vehicle M (D.3) e.g. Focus, Astra, Megane Y EU Category Code M (J) mopeds, motorbikes, cars etc. Y

1.2.2.2

Fullständig uppsättning uppgifter Item M/O (6) Remarks Prüm Y/N Data relating to holders of the vehicle   (C.1 (7)) The data refer to the holder of the specific registration certificate.   Registration holders’ (company) name M (C.1.1.) separate fields will be used for surname, infixes, titles etc., and the name in printable format will be communicated Y First name M (C.1.2) separate fields for first name(s) and initials will be used, and the name in printable format will be communicated Y Address M (C.1.3) separate fields will be used for Street, House number and Annex, Zip code, Place of residence, Country of residence etc., and the Address in printable format will be communicated Y Gender M Male, female Y Date of birth M   Y Legal entity M individual, association, company, firm etc. Y Place of Birth O   Y ID Number O An identifier that uniquely identifies the person or the company. N Type of ID Number O The type of ID Number (e.g. passport number). N Start date holdership O Start date of the holdership of the car. This date will often be the same as printed under (I) on the registration certificate of the vehicle. N End date holdership O End data of the holdership of the car. N Type of holder O If there is no owner of the vehicle (C.2) the reference to the fact that the holder of the registration certificate: — is the vehicle owner — is not the vehicle owner — is not identified by the registration certificate as being the vehicle owner N Data relating to owners of the vehicle   (C.2)   Owners' (company) name M (C.2.1) Y First name M (C.2.2) Y Address M (C.2.3) Y Gender M male, female Y Date of birth M   Y Legal entity M individual, association, company, firm etc. Y Place of Birth O   Y ID Number O An identifier that uniquely identifies the person or the company. N Type of ID Number O The type of ID Number (e.g. passport number). N Start date ownership O Start date of the ownership of the car. N End date ownership O End data of the ownership of the car. N Data relating to vehicles       Licence number M   Y Chassis number/VIN M   Y Country of registration M   Y Make M (D.1) e.g. Ford, Opel, Renault etc. Y Commercial type of the vehicle M (D.3) e.g. Focus, Astra, Megane Y Nature of the vehicle/EU Category Code M (J) mopeds, motorbikes, cars etc. Y Date of first registration M (B) date of first registration of the vehicle somewhere in the world Y Start date (actual) registration M (I) Date of the registration to which the specific certificate of the vehicle refers Y End date registration M End data of the registration to which the specific certificate of the vehicle refers. It is possible this date indicates the period of validity as printed on the document if not unlimited (document abbreviation = H). Y Status M scrapped, stolen, exported etc. Y Start date status M   Y End date status O   N kW O (P.2) Y Capacity O (P.1) Y Type of licence number O regular, transito etc. Y Vehicle document id 1 O The first unique document ID as printed on the vehicle document Y Vehicle document id 2 (8) O A second document ID as printed on the vehicle document. Y Data relating to insurances       Insurance company name O   Y Begin date insurance O   Y End date insurance O   Y Address O   Y Insurance number O   Y ID Number O An identifier that uniquely identifies the company. N Type of ID Number O The type of ID Number (e.g. number of the Chamber of Commerce) N

2.   Datasäkerhet

2.1   Översikt

Eucaris programapplikation används för säker kommunikation med övriga medlemsstater och kommunicerar med medlemsstaternas äldre back-end-system med hjälp av XML. Medlemsstaterna utbyter meddelanden genom att sända dem direkt till mottagaren. Varje medlemsstats datacentral är ansluten till EU:s Testa-nät.

De XML-meddelanden som sänds via nätet krypteras med krypteringstekniken SSL. De meddelanden som sänds till back-end-systemen är XML-meddelanden i klartext eftersom anslutningen mellan applikationen och back-end-systemen ska vara i en skyddad miljö.

Det tillhandahålls en klientapplikation som kan användas inom en medlemsstat för att söka i dess eget register eller i en annan medlemsstats register. Klienterna identifieras med hjälp av användar-ID/lösenord eller ett klientcertifikat. Anslutningen till en användare kan krypteras, men detta är varje enskild medlemsstats ansvar.

2.2   Säkerhetsfunktioner i samband med meddelandeutbytet

Säkerhetssystemet är baserat på en kombination av HTTPS och XML-signatur. Med detta alternativ används XML-signatur för att signera alla meddelanden som sänds till servern, och den som sänder meddelandet kan autentiseras genom att signaturen kontrolleras. Enkelsidig SSL (enbart ett servercertifikat) används för att skydda meddelandets konfidentialitet och integritet under överföringen och skyddar mot raderings-/replay- och insättningsattacker. Istället för skräddarsydd programvaruutveckling för att tillämpa dubbelsidig SSL, tillämpas XML-signatur. Användningen av XML-signatur ligger närmare färdplanen för webbtjänstgränssnitt än dubbelsidig SSL och är därför mer strategisk.

XML-signatur kan tillämpas på flera sätt men man har valt att använda tekniken som en del av Web Services Security (WSS). WSS anger hur XML-signatur ska användas. Eftersom WSS bygger på Soap-standarden är det logiskt att följa denna standard så långt det är möjligt.

2.3   Säkerhetsfunktioner utan samband med meddelandeutbytet

2.3.1   Autentisering av användare

Användare av Eucaris webbapplikation kan autentisera sig med hjälp av användarnamn och lösenord. Eftersom man använder Windows standardautentisering kan medlemsstaterna vid behov höja autentiseringsnivån för användarna genom att använda klientcertifikat.

2.3.2   Användarroller

Eucaris är anpassad till olika användarroller. Varje grupp av tjänster har en egen behörighetstilldelning. Användare som enbart har behörighet att använda ”Eucarisavtalsfunktionen” får exempelvis inte använda ”Prümfunktionen”. Administratörstjänsterna är avskilda från de vanliga slutanvändarrollerna.

2.3.3   Loggning och spårning av meddelandeutbytet

Eucaris möjliggör loggning av alla typer av meddelanden. Genom en administratörsfunktion kan den nationella administratören bestämma vilka meddelanden som ska loggas: begäranden från slutanvändare, inkommande begäranden från andra medlemsstater, uppgifter som hämtats från de nationella registren osv.

Applikationen kan konfigureras så att den använder en intern databas eller en extern (Oracle) databas för denna loggning. Vilka meddelanden som måste loggas beror naturligtvis på loggningsmöjligheterna i andra delar av de äldre systemen och de anslutna klientapplikationerna.

Rubriken till varje meddelande innehåller information om den begärande medlemsstaten, den begärande organisationen inom den medlemsstaten och den berörda användaren. Skälet till begäran anges också.

Det är möjligt att spåra ett fullständigt meddelandeutbyte (t.ex. på begäran av den berörda medborgaren) med hjälp av den kombinerade loggningen i den begärande och tillfrågade medlemsstaten.

Loggningen konfigureras genom Eucaris webbklient (menu Administration, Logging configuration). Loggningsfunktionen utförs av grundsystemet. När loggningen är aktiverad lagras hela meddelandet (rubriken och meddelandetexten) i en loggningspost. Loggningsnivån kan ställas in enligt angiven tjänst eller enligt den meddelandetyp som passerar genom grundsystemet.

Loggningsnivåer

Följande loggningsnivåer är möjliga:

Privat – meddelandet loggas: Loggen är inte tillgänglig för sökning av loggningar, utan är endast tillgänglig på nationell nivå för revision och problemlösning.

Ingen – meddelandet loggas inte alls.

Typer av meddelanden

Informationsutbytet mellan medlemsstaterna består av flera meddelanden, som illustreras schematiskt i figuren nedan.

De möjliga meddelandetyperna (som i figuren visas för Eucaris grundsystem i medlemsstat X) är följande:

1.	Begäran till grundsystemet_meddelande med begäran från klienten

2.	Begäran till annan medlemsstat_meddelande med begäran från denna medlemsstats grundsystem

3.	Begäran till denna medlemsstats grundsystem_meddelande med begäran från en annan medlemsstats grundsystem

4.	Begäran till register i det äldre systemet_meddelande med begäran från grundsystemet

5.	Begäran till grundsystemet_meddelande med begäran från register i det äldre systemet

6.	Svar från grundsystemet_meddelande med begäran från klienten

7.	Svar från annan medlemsstat_meddelande med begäran från denna medlemsstats grundsystem

8.	Svar från denna medlemsstats grundsystem_meddelande med begäran från den andra medlemsstaten

9.	Svar från register i det äldre systemet_meddelande med begäran från grundsystemet

10.

Svar från grundsystemet_meddelande med begäran från register i det äldre systemet Följande typer av informationsutbyte visas i figuren: — Begäran om information från medlemsstat X till medlemsstat Y – blå pilar. Denna begäran och svaret består av meddelandetyperna 1, 2, 7 respektive 6. — Begäran om information från medlemsstat Z till medlemsstat X – röda pilar. Denna begäran och svaret består av meddelandetyperna 3, 4, 9 respektive 8. — Begäran om information från registret i det äldre systemet till dess grundsystem (detta inkluderar även en begäran från en specialklient bakom registret i det äldre systemet) – gröna pilar. Denna typ av begäran består av meddelandetyperna 5 och 10.

Figur: Meddelandetyper för loggning

2.3.4   Säkerhetsmodul i maskinvara

Ingen säkerhetsmodul används i maskinvaran.

En säkerhetsmodul i maskinvaran (HSM, Hardware Security Model) ger ett gott skydd av den nyckel som används för att signera meddelanden och identifiera servrar. Detta bidrar till den allmänna säkerhetsnivån, men kostnaden är hög för inköp/underhåll av en HSM, och det finns inga krav på att använda en HSM som uppfyller nivå 2 eller 3 enligt FIPS-standarden 140-2. Eftersom man använder ett slutet nät som effektivt skyddar mot hot har man beslutat att inledningsvis inte använda någon HSM. Om en HSM blir nödvändig, t.ex. för att ackreditering, kan arkitekturen kompletteras med detta.

3.   Tekniska villkor för informationsutbytet

3.1   Allmän beskrivning av Eucaris-applikationen

3.1.1   Översikt

Eucaris-applikationen kopplar samman alla medlemsstater i ett meshnät där varje medlemsstat kommunicerar direkt med en annan medlemsstat. Ingen central komponent behövs för att etablera kommunikationen. Eucaris-applikationen hanterar säker kommunikation till de andra medlemsstaterna och kommunicerar med back-end-delen i äldre system hos medlemsstater som använder XML. Följande bild visualiserar denna arkitektur.

Medlemsstaterna utbyter meddelanden genom att sända dem direkt till mottagaren. En medlemsstats datacentral är kopplad till det nät som används för utbyte av meddelanden (Testa). För åtkomst av Testa-nätet ansluter sig medlemsstaterna till Testa via sin nationella nätport. En brandvägg ska användas för anslutning till nätet och en router ansluter Eucaris-applikationen till brandväggen. Beroende på vilket alternativ som väljs för att skydda meddelandena, används ett certifikat antingen av routern eller av Eucaris-applikationen.

En klientapplikation tillhandahålls som kan användas inom en medlemsstat för att söka i dess eget register eller andra medlemsstaters register. Klientapplikationen är ansluten till Eucaris. Klienterna identifieras med hjälp av användarID/lösenord eller ett klientcertifikat. Anslutningen till en användare i en extern organisation (t.ex. polisen) kan krypteras men detta är varje enskild medlemsstats ansvar.

3.1.2   Systemets tillämpningsområde

Eucaris-systemets tillämpningsområde är begränsat till processer som används i informationsutbytet mellan registreringsmyndigheterna i medlemsstaterna och en grundläggande presentation av denna information. Förfaranden och automatiserade processer i vilka informationen ska användas faller utanför systemets tillämpningsområde.

Medlemsstater kan välja att antingen använda Eucaris klientfunktion eller skapa sin egen skräddarsydda klientapplikation. I tabellen nedan anges vilka aspekter av Eucaris-systemet som obligatoriskt måste användas och/eller föreskrivs och vilka aspekter som är frivilliga och/eller som medlemsstaterna fritt kan fastställa.

EUCARIS aspects	M/O (9)	Remark
Network concept	M	The concept is an ”any-to-any” communication.
Physical network	M	TESTA
Core application	M	The core application of EUCARIS has to be used to connect to the other Member States. The following functionality is offered by the core: — Encrypting and signing of the messages; — Checking of the identity of the sender; — Authorization of Member States and local users; — Routing of messages; — Queuing of asynchronous messages if the recipient service is temporally unavailable; — Multiple country inquiry functionality; — Logging of the exchange of messages; — Storage of incoming messages
Client application	O	In addition to the core application the EUCARIS II client application can be used by a Member State. When applicable, the core and client application are modified under auspices of the EUCARIS organisation.
Security concept	M	The concept is based on XML-signing by means of client certificates and SSL-encryption by means of service certificates.
Message specifications	M	Every Member State has to comply with the message specifications as set by the EUCARIS organisation and this Council Decision. The specifications can only be changed by the EUCARIS organisation in consultation with the Member States.
Operation and Support	M	The acceptance of new Member States or a new functionality is under auspices of the EUCARIS organisation. Monitoring and help desk functions are managed centrally by an appointed Member State.

3.2   Funktionella och icke funktionella krav

3.2.1   Generisk funktionalitet

I detta avsnitt har de huvudsakliga generiska funktionerna beskrivits i allmänna termer

Nr	Beskrivning
1.	Systemet gör det möjligt för medlemsstaternas registreringsmyndigheter att utbyta begäranden och svar på ett interaktivt sätt.
2.	Systemet innehåller en klientapplikation som möjliggör för slutanvändare att översända sina begäranden och presentera svarsinformationen för manuell behandling.
3.	Systemet underlättar ”rundsändning”, vilket gör att en medlemsstat kan översända en begäran till alla de övriga medlemsstaterna. De inkommande svaren konsolideras genom grundapplikationen i ett svarsmeddelande till klientapplikationen (denna funktionalitet kallas ”Multiple Country Inquiry”).
4.	Systemet kan hantera olika slags meddelanden. Användarroll, behörighetstilldelning, routing, signering och loggning definieras alla per specifik tjänst.
5.	Systemet gör det möjligt för medlemsstaterna att utbyta meddelanden satsvis eller meddelanden som innehåller ett stort antal begäranden eller svar. Dessa meddelanden behandlas asynkront.
6.	Systemet lägger asynkrona meddelanden i väntekö om den mottagande medlemsstaten tillfälligt inte är tillgänglig och garanterar leveransen så snart som mottagaren är uppkopplad igen.
7.	Systemet lagrar inkommande asynkrona meddelanden tills de kan behandlas.
8.	Systemet ger endast åtkomst till andra medlemsstaters Eucaris-applikationer, inte till individuella organisationer inom dessa andra medlemsstater, vilket innebär att varje registreringsmyndighet agerar som den enda nätporten mellan dess nationella slutanvändare och motsvarande myndigheter i de andra medlemsstaterna.
9.	Det är möjligt att definiera användare från olika medlemsstater på en enda Eucaris-server och att ge dem behörighet i enlighet med gällande bestämmelser i den medlemsstaten.
10.	Meddelandena innehåller också information om den begärande medlemsstaten, organisationen och slutanvändaren.
11.	Systemet underlättar loggning av utbytet av meddelanden mellan de olika medlemsstaterna och mellan huvudapplikationen och de nationella registreringssystemen.
12.	Systemet tillåter att en särskild sekreterare, som är en organisation eller en medlemsstat som explicit har utsetts att sköta denna uppgift, samlar in loggad information om meddelanden som sänts eller mottagits av samtliga deltagande medlemsstater i syfte att sammanställa statistikrapporter.
13.	Varje medlemsstat anger själv vilken loggad information som ska göras tillgänglig för sekreteraren och vilken information som är ”privat”.
14.	Systemet tillåter varje medlemsstats nationella administratörer att ta fram utdrag ur användbar statistik.
15.	Systemet möjliggör tillägg av nya medlemsstater genom enkla administrativa åtgärder.

3.2.2   Användbarhet

Nr	Beskrivning
16.	Systemet tillhandahåller ett gränssnitt för automatiserad behandling av meddelanden med hjälp av back-end-delen i äldre system och möjliggör integration av användargränssnittet i dessa system (skräddarsytt användargränssnitt).
17.	Systemet är lätt att lära sig, självförklarande och innehåller hjälptext.
18.	Systemet är dokumenterat för att bistå medlemsstaterna i fråga om integrering, operativa aktiviteter och framtida underhåll (t.ex. referensmanual, funktionell/operativ dokumentation, användarmanual, ...).
19.	Användargränssnittet är flerspråkigt och erbjuder möjligheter för slutanvändaren att välja ett favoritspråk.
20.	Användargränssnittet tillhandahåller redskap med hjälp av vilka den lokala administratören kan översätta både skärmbildsobjekt och kodad information till det nationella språket.

3.2.3   Tillförlitlighet

Nr	Beskrivning
21.	Systemet är utformat som ett robust och pålitligt operativsystem som tolererar fel som operatören begår och som klarar strömavbrott eller andra olyckor. Det måste vara möjligt att starta om systemet med ingen eller minimal förlust av data.
22.	Systemet måste ge stabila och reproducerbara resultat.
23.	Systemet är utformat så att det fungerar pålitligt. Det är möjligt att implementera systemet i en konfiguration som garanterar 98 % tillgänglighet (genom redundans, användning av backup-servrar, osv.) i all bilateral kommunikation.
24.	Det är möjligt att använda delar av systemet även när några komponenter inte fungerar (om medlemsstat C ligger nere kan fortfarande medlemsstaterna A och B kommunicera). Antalet enskilda felställen i informationskedjan bör minimeras.
25.	Återhämtningstiden efter ett allvarligt haveri bör vara mindre än en dag. Det bör vara möjligt att minimera den tid systemet ligger nere genom användning av fjärrstöd, t.ex. en central servicedesk.

3.2.4   Prestanda

Nr	Beskrivning
26.	Systemet kan användas 24x7. Detta tidsfönster (24x7) krävs då också av medlemsstaternas äldre system.
27.	Systemet reagerar snabbt på en användarbegäran oavsett bakgrundsaktivitet. Detta krävs också av parternas äldre system för att säkerställa en godtagbar svarstid. En total svarstid om maximalt 10 sekunder för en enstaka begäran är godtagbar.
28.	Systemet har utformats som ett fleranvändarsystem och på ett sådant sätt att bakgrundsaktivitet kan fortsätta medan användaren utför förgrundsaktivitet.
29.	Systemet har utformats så att det är skalbart i syfte att klara en potentiell ökning av antalet meddelanden när ny funktionalitet läggs till eller nya organisationer eller medlemsstater ansluter sig.

3.2.5   Säkerhet

Nr	Beskrivning
30.	Systemet lämpar sig (t.ex. beträffande dess säkerhetsåtgärder) för utbyte av meddelanden som innehåller integritetskänslig information (t.ex. bilägare/innehavare) som klassificeras som EU RESTREINT.
31.	Systemet upprätthålls på ett sådant sätt att obehörig åtkomst av information förhindras.
32.	Systemet innehåller en tjänst för hantering av de nationella slutanvändarnas rättigheter och tillstånd.
33.	Medlemsstaterna kan kontrollera sändarens identitet (på medlemsstatsnivå) genom XML-signering.
34.	Medlemsstater måste uttryckligen ge andra medlemsstater behörighet för att de ska kunna begära särskild information.
35.	Systemet tillhandahåller på applikationsnivå en fullständig säkerhets- och krypteringspolicy som är kompatibel med den säkerhetsnivå som krävs i sådana situationer. Informationens exklusivitet och integritet garanteras genom användning av XML-signering och kryptering genom SSL-tunnling.
36.	Allt informationsutbyte kan spåras genom loggning.
37.	Skydd mot raderingsattacker tillhandahålls (en tredje part raderar ett meddelande) och replay- eller insättningsattacker (en tredje part spelar upp eller sätter in ett meddelande).
38.	Systemet använder sig av TTP-certifikat (Trusted Third Party).
39.	Systemet kan hantera olika certifikat per medlemsstat beroende på typen av meddelande eller tjänst.
40.	Säkerhetsåtgärderna på applikationsnivå är tillräckliga för att tillåta användning av icke ackrediterade nät.
41.	Systemet är förberett för användning av ny säkerhetsteknik såsom en XML-brandvägg.

3.2.6   Anpassbarhet

Nr	Beskrivning
42.	Systemet kan utökas med nya meddelanden och ny funktionalitet. Anpassningskostnaderna är minimala beroende på den centraliserade utvecklingen av applikationskomponenter.
43.	Medlemsstaterna kan definiera nya meddelandetyper för bilateral användning. Det krävs inte av alla medlemsstater att de ska kunna klara av alla typer av meddelanden.

3.2.7   Stöd och underhåll

Nr	Beskrivning
44.	Systemet tillhandahåller övervakningsfaciliteter för en central servicedesk och/eller operatörer när det gäller nätet och servrar i de olika medlemsstaterna.
45.	Systemet tillhandahåller faciliteter för fjärrstöd genom en central servicedesk.
46.	Systemet tillhandahåller faciliteter för problemanalys.
47.	Systemet kan utsträckas till att omfatta nya medlemsstater.
48.	Applikationen kan enkelt installeras av personal med ett minimum av IT-kvalifikationer och erfarenhet. Installationsproceduren ska så långt som möjligt vara automatiserad.
49.	Systemet tillhandahåller en permanent test- och acceptansmiljö.
50.	De årliga kostnaderna för underhåll och stöd har minimerats genom anslutning till marknadsstandarder och genom att utforma applikationen så att så lite stöd som möjligt krävs från en central servicedesk.

3.2.8   Krav på utformningen

Nr	Beskrivning
51.	Systemet är utformat och dokumenterat för en operativ livslängd på många år.
52.	Systemet har utformats så att det är oberoende av nätleverantören.
53.	Systemet står i överensstämmelse med existerande HW/SW i medlemsstaterna genom att interagera med de registreringssystem som använder öppna standarder för webbtjänstteknik (XML, XSD, Soap, WSDL, HTTP(s), webbtjänster, WSS, X.509, osv.).

3.2.9   Tillämpliga standarder

Nr	Beskrivning
54.	Systemet uppfyller dataskyddskraven i förordning (EG) nr 45/2001 (artiklarna 21, 22 och 23) och direktiv 95/46/EG.
55.	Systemet uppfyller IDA-standarderna.
56.	Systemet är anpassat för UTF8.

KAPITEL 4: Utvärdering

1.   Utvärderingsförfarande i enlighet med artikel 20 (förberedelse av beslut enligt artikel 25.2 i beslut 2008/615/RIF)

1.1   Frågeformulär

Den berörda rådsarbetsgruppen ska utarbeta ett frågeformulär beträffande vart och ett av de automatiserade utbytena av information i kapitel 2 i beslut 2008/615/RIF.

Så snart som en medlemsstat anser sig uppfylla de nödvändiga förutsättningarna för att dela information i de relevanta informationskategorierna ska den besvara det relevanta frågeformuläret.

1.2   Testkörning

I syfte att utvärdera resultatet av frågeformuläret ska de medlemsstater som vill börja dela information genomföra en testkörning tillsammans med en eller flera andra medlemsstater som redan delar information enligt rådsbeslutet. Testkörningen ska äga rum före eller kort tid efter utvärderingsbesöket.

Villkoren och arrangemangen kring denna testkörning ska fastställas av den berörda rådsarbetsgruppen och grunda sig på en i förväg träffad separat överenskommelse med den berörda medlemsstaten. De medlemsstater som deltar i testkörningen beslutar själva om de praktiska detaljerna.

1.3   Utvärderingsbesök

I syfte att utvärdera resultatet av frågeformuläret ska ett utvärderingsbesök äga rum i den medlemsstat som vill börja dela information.

Villkoren och arrangemangen kring denna testkörning kommer att fastställas av den berörda rådsarbetsgruppen och grunda sig på en i förväg träffad separat överenskommelse mellan den berörda medlemsstaten och utvärderingsteamet. Den berörda medlemsstaten ska ge utvärderingsteamet möjlighet att kontrollera det automatiserade informationsutbytet i den eller de informationskategorier som ska utvärderas, bland annat genom att organisera ett program för besöket som beaktar de önskemål som utvärderingsteamet framfört.

Inom en månad ska utvärderingsteamet sammanställa en rapport om utvärderingsbesöket och överlämna den till berörda medlemsstater för kommentarer. I förekommande fall ska utvärderingsgruppen revidera denna rapport på grundval av medlemsstaternas kommentarer.

Utvärderingsteamet ska bestå av högst tre experter, utsedda av de medlemsstater som deltar i det automatiserade informationsutbytet i de informationskategorier som ska utvärderas, som har erfarenhet beträffande den berörda informationskategorin, som har genomgått lämplig nationell säkerhetskontroll för att få handha dessa frågor och som är villiga att delta i åtminstone ett utvärderingsbesök i en annan medlemsstat.

Medlemmarna i utvärderingsteamet ska respektera den inhämtade informationens konfidentiella natur i samband med att de utför sin uppgift.

1.4   Rapport till rådet

En övergripande utvärderingsrapport som sammanfattar resultatet av frågeformulären, utvärderingsbesöket och testkörningen kommer att läggas fram för rådet för beslut i enlighet med artikel 25.2 i beslut 2008/615/RIF.

2.   Utvärderingsförfarande enligt artikel 21

2.1   Statistik och rapport

Varje medlemsstat ska samla in statistik över resultatet av det automatiserade informationsutbytet. I syfte att säkerställa jämförbarhet kommer statistikmodellen att fastställas av den berörda rådsarbetsgruppen.

Dessa statistikuppgifter kommer årligen att läggas fram för rådet, som ska göra en övergripande sammanfattning av det gångna året, och för kommissionen.

Dessutom kommer medlemsstaterna regelbundet att anmodas att inte underlåta att en gång per år tillhandahålla sådana ytterligare uppgifter om det administrativa, tekniska och finansiella genomförandet av automatiserat utbyte av information som behövs för analys och förbättringar av processen. På grundval av denna information kommer en rapport att sammanställas för rådet.

2.2   Revidering

Inom rimlig tid kommer rådet att granska den utvärderingsmekanism som beskrivs här och vid behov revidera den.

3.    Expertmöten

Inom den berörda rådsarbetsgruppen kommer experter regelbundet att träffas för att organisera och genomföra de ovannämnda utvärderingsförfarandena samt dela med sig av sina erfarenheter och diskutera möjliga förbättringar. I tillämpliga fall kommer resultatet av dessa expertdiskussioner att införlivas med den rapport som det hänvisas till i punkt 2.1 ovan.

---

(1)  ”Fullständigt angivna” betyder att hantering av ovanliga alleler inkluderas.

(2)  Detta är positionen enligt definitionen i ASCII-standarden.

(3)  M = mandatory when available in national register, O = optional.

(4)  All the attributes specifically allocated by the Member States are indicated with Y.

(5)  Harmonised document abbreviation, see Council Directive 1999/37/EC of 29.4.1999.

(6)  M = mandatory when available in national register, O = optional.

(7)  Harmonised document abbreviation, see Council Directive 1999/37/EC of 29.4.1999.

(8)  In Luxembourg two separate vehicle registration document ID's are used.

(9)  M = mandatory to use or to comply with O = optional to use or to comply with.