---

PRÍLOHA

OBSAH
KAPITOLA 1:	Výmena údajov o DNA
1.	Súdne otázky týkajúce sa DNA, pravidlá zhodnosti a algoritmy
1.1.	Vlastnosti profilov DNA
1.2.	Pravidlá zhodnosti
1.3.	Pravidlá oznamovania
2.	Tabuľka kódov členských štátov
3.	Funkčná analýza
3.1.	Dostupnosť systému
3.2.	Druhý krok
4.	Dokument o riadení prepojenia pre DNA
4.1.	Úvod
4.2.	Vymedzenie štruktúry XML
5.	Aplikačná, bezpečnostná a komunikačná architektúra
5.1.	Prehľad
5.2.	Architektúra vyššieho stupňa
5.3.	Bezpečnostné normy a ochrana údajov
5.4.	Protokoly a normy na použitie v šifrovacích mechanizmoch: sMIME a súvisiace balíky
5.5.	Aplikačná architektúra
5.6.	Protokoly a normy na použitie v aplikačnej architektúre
5.7.	Komunikačné prostredie
KAPITOLA 2:	Výmena daktyloskopických údajov (dokument o riadení prepojenia)
1.	Prehľad obsahu súboru
2.	Formát záznamu
3.	Logický záznam typu 1: Hlavička súboru
4.	Logický záznam typu 2: Opisný text
5.	Logický záznam typu 4: Obrázok v odtieňoch šedej s vysokým rozlíšením
6.	Logický záznam typu 9: Záznam o markantoch
7.	Logický záznam typu 13: Skrytý obrázok s rôznym rozlíšením
8.	Logický záznam typu 15: Odtlačok dlane s rôznym rozlíšením
9.	Dodatky ku kapitole 2 (výmena daktyloskopických údajov)
9.1.	Oddeľovacie kódy ASCII
9.2.	Výpočet alfanumerických kontrolných znakov
9.3.	Znakové kódy
9.4.	Súhrn transkacií
9.5.	Vymedzenia záznamov typu 1
9.6.	Vymedzenia záznamov typu 2
9.7.	Kódy na kompresiu odtieňov šedej
9.8.	Špecifikácia pošty
KAPITOLA 3:	Výmena údajov z evidencie vozidiel
1.	Spoločný súbor údajov na automatizované vyhľadávanie údajov z evidencie vozidiel
1.1.	Vymedzenie pojmov
1.2.	Vyhľadávanie podľa vozidla/vlastníka/držiteľa
2.	Bezpečnosť údajov
2.1.	Prehľad
2.2.	Bezpečnostné prvky výmeny správ
2.3.	Bezpečnostné prvky, ktoré sa netýkajú výmeny správ
3.	Technické podmienky výmeny údajov
3.1.	Všeobecný opis aplikácie EUCARIS
3.2.	Požiadavky na funkčnosť a požiadavky, ktoré sa netýkajú funkčnosti
KAPITOLA 4:	Hodnotenie
1.	Hodnotiaci postup podľa článku 20 (príprava rozhodnutí podľa článku 25 ods. 2 rozhodnutia 2008/615/SVV)
1.1.	Dotazník
1.2.	Skúšobná prevádzka
1.3.	Hodnotiaca návšteva
1.4.	Správa Rade
2.	Hodnotiaci postup podľa článku 21
2.1.	Štatistika a správa
2.2.	Revízia
3.	Stretnutia expertov

Kapitola 1: Výmena údajov o DNA

1.   Súdne otázky týkajúce sa DNA, pravidlá zhodnosti a algoritmy

1.1.   Vlastnosti profilov DNA

Profil DNA môže obsahovať 24 párov čísiel, ktoré predstavujú alely na 24 lokusoch a ktoré sa používajú aj v postupoch Interpolu týkajúcich sa DNA. Názvy uvedených lokusov sa nachádzajú v nasledujúcej tabuľke:

Sedem šedých miest v hornom riadku predstavuje aj súčasný európsky štandardný súbor lokusov (ESS) aj štandardný súbor lokusov DNA Interpolu (ISSOL).

Pravidlá začlenenia:

Profily DNA, ktoré členské štáty sprístupnia na účely vyhľadávania a porovnávania, ako aj profily DNA, ktoré sa odošlú na vyhľadávanie a porovnávania, musia obsahovať aspoň 6 úplných vymedzených ( 1 ) lokusov a v závislosti od dostupnosti môžu obsahovať dodatočné vymedzené lokusy alebo úseky mimo vymedzeného profilu. Referenčné profily DNA musia obsahovať aspoň 6 zo siedmich lokusov európskeho štandardného súboru. V záujme zvýšenia presnosti zhodných výsledkov sa do indexovanej databázy profilov DNA uložia všetky dostupné alely a budú sa využívať na vyhľadávanie a porovnávanie. Každý členský štát by hneď, ako to bude prakticky možné, mal implementovať všetky nové ESS lokusov, ktoré prijme EÚ.

Nepovoľujú sa zmiešané profily, aby alelová hodnota každého lokusu pozostávala len z dvoch čísiel, ktoré môžu byť v prípade homozygotov na rovnakom lokuse rovnaké.

Pre zástupný znak a mikrosatelity platia tieto pravidlá:

1.2.   Pravidlá zhodnosti

Porovnávanie dvoch profilov DNA sa uskutoční na základe tých lokusov, pri ktorých je v oboch profiloch dostupný alelový pár. Na oznámenie pozitívnej lustrácie sa v oboch profiloch DNA musí zhodovať aspoň 6 úplných vymedzených lokusov (okrem amelogenínu).

Úplná zhoda (prvá úroveň kvality) sa definuje ako zhoda v prípade, keď sú rovnaké všetky alely porovnávaných spoločných lokusov v oboch porovnávaných profiloch DNA. Čiastočná zhoda sa definuje ako zhoda v prípade, ak sa v oboch profiloch DNA medzi porovnávanými alelami vyskytuje len jedna nerovnaká alela (druhá, tretia a štvrtá úroveň kvality). Čiastočná zhoda sa akceptuje, len ak sa v dvoch porovnávaných profiloch vyskytuje aspoň 6 úplných vymedzených zhodných lokusov.

Dôvodom čiastočnej zhody môže byť:

1.3.   Pravidlá oznamovania

Oznamovať sa budú úplné zhody, čiastočné zhody a „negatívna lustrácia“.

Oznámenie o zhode sa zašle žiadajúcemu národnému kontaktnému bodu a sprístupní sa aj dožadovanému národnému kontaktnému bodu (aby mohlo odhadnúť charakter a počet možných následných žiadostí o ďalšie dostupné osobné údaje a iné informácie spojené s profilom DNA, ktorý zodpovedá pozitívnemu výsledku vyhľadávania, v súlade s článkami 5 a 10 rozhodnutia 2008/615/SVV).

2.   Tabuľka kódov členských štátov

V súlade s rozhodnutím 2008/615/SVV sa na vytvorenie názvov domén a ďalších konfiguračných parametrov, ktoré sa pri uzavretej sieti vyžadujú v prümských aplikáciách pri výmene údajov o DNA, používajú dvojpísmenové kódy zo zoznamu ISO 3166-1 alpha-2.

Pri členských štátoch sa používajú tieto dvojpísmenové kódy zo zoznamu ISO 3166-1 alpha-2:

3.   Funkčná analýza

3.1.   Dostupnosť systému

Žiadosti podľa článku 3 rozhodnutia 2008/615/SVV by sa do cieľovej databázy mali dostať v chronologickom poradí podľa odoslania a odpoveď by sa mala žiadajúcemu členskému štátu zaslať tak, aby ju dostal do 15 minút od doručenia žiadosti.

3.2.   Druhý krok

Keď členský štát dostane oznámenie o zhode, jeho národný kontaktný bod zodpovedá za porovnanie hodnôt predloženého profilu s hodnotami v prijatej odpovedi (profiloch) s cieľom overiť a skontrolovať dôkaznú hodnotu profilu. Národné kontaktné body sa na účely overovania môžu vzájomne kontaktovať priamo.

Postupy právnej pomoci sa začínajú po overení existujúcej zhody medzi dvoma profilmi na základe „úplnej zhody“ alebo „čiastočnej zhody“ získanej počas automatizovanej fázy vyhľadávania.

4.   Dokument o riadení prepojenia pre DNA

4.1.   Úvod

4.1.1.    Ciele

V tejto kapitole sa vymedzujú požiadavky na výmenu informácií o profiloch DNA medzi databázovými systémami všetkých členských štátov. Polia v hlavičkách sa definujú špecificky pre prümskú výmenu informácií o DNA, dátová časť vychádza z dátovej časti DNA profilu vo formáte XML vymedzenom pre bránu Interpolu na výmenu informácií o DNA.

Údaje sa vymieňajú prostredníctvom protokolu SMTP (Simple Mail Transfer Protocol) a iných moderných technológií, pomocou centrálneho poštového relay servera od poskytovateľa sieťových služieb. Súbor XML sa prenáša ako telo správy.

4.1.2.    Rozsah

V tomto dokumente o riadení prepojenia (ICD – Interface Control Document) sa vymedzuje len obsah (poštovej) správy. Všetky témy týkajúce sa špecificky siete alebo pošty sa definujú jednotne, aby sa zabezpečila spoločná technická báza na výmenu údajov o DNA.

Rieši sa:

4.1.3.    Štruktúra a zásady formátu XML

Správa vo formáte XML sa delí na

Na žiadosť i odpoveď sa využíva rovnaká schéma XML.

Na účely úplnej kontroly neidentifikovaných profilov DNA (článok 4 rozhodnutia 2008/615/SVV) sa musí dať v jednej správe zaslať súbor profilov. Musí sa vymedziť i maximálny počet profilov v rámci jednej správy. Tento počet závisí od maximálnej povolenej veľkosti správy v elektronickej pošte a vymedzí sa po výbere poštového servera.

Príklad správy vo formáte XML:

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

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

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

<header>

(...)

</header>

</datas>

(...)

</datas>

[<datas> (....) v prípade, že sa prostredníctvom jedinej správy SMTP zasiela viacero profilov, štruktúra „datas“ sa opakuje; toto je možné len v prípadoch podľa článku 4

</datas>]

</PRUEMDNA>

4.2.   Vymedzenie štruktúry XML

Nasledujúce definície sú len na dokumentačné účely a kvôli lepšej čitateľnosti, ozajstné záväzné informácie sa nachádzajú v súbore so schémou vo formáte XML (PRUEM DNA.xsd).

4.2.1.    Schéma PRUEMDNAx

Obsahuje tieto polia:

4.2.2.    Obsah štruktúry hlavičky

Touto štruktúrou sa opisuje hlavička súboru vo formáte XML. Obsahuje tieto polia:

Typ údajov obsiahnutých v správe, hodnota môže byť:

Štruktúra na opis členského štátu, obsahuje aj dátum/čas správy. Obsahuje tieto polia:

4.2.3.    Obsah údajov v profile PRUEM

Touto štruktúrou sa opisuje dátová časť súboru vo formáte XML. Obsahuje tieto polia:

Typ údajov obsiahnutých v správe, hodnota môže byť:

Typ údajov obsiahnutých v správe, hodnota môže byť:

Typ údajov obsiahnutých v správe, hodnota môže byť:

Štruktúra, ktorou sa opisuje profil DNA. Obsahuje tieto polia:

Štruktúra, ktorá obsahuje lokusy ISSOL (štandardná skupina lokusov Interpolu). Obsahuje tieto polia:

Štruktúra, ktorá obsahuje iné lokusy. Obsahuje tieto polia:

Štruktúra, prostredníctvom ktorej sa opisuje lokus. Obsahuje tieto polia:

5.   Aplikačná, bezpečnostná a komunikačná architektúra

5.1.   Prehľad

Pri realizácii žiadostí o výmenu údajov o DNA v rámci rozhodnutia 2008/615/SVV sa používa spoločná komunikačná sieť, ktorá bude medzi členskými štátmi logicky uzavretá. Na účinnejšie využitie tejto spoločnej komunikačnej infraštruktúry, ktorá zahŕňa zasielanie žiadostí a získavanie odpovedí, sa prijal asynchrónny mechanizmus na prenos žiadostí o údaje DNA a daktyloskopické údaje v správe elektronickej pošty v protokole SMTP. Aby sa vyriešili bezpečnostné obavy a s cieľom vytvoriť ozajstný bezpečný tunel z jedného konca siete na druhý, bude sa používať mechanizmus sMIME ako rozšírenie protokolu SMTP.

Ako komunikačná sieť na výmenu údajov medzi členskými štátmi sa používa funkčná TESTA (Trans European Services for Telematics between Administrations – transeurópska komunikačná sieť telematických služieb medzi orgánmi štátnej správy). Za sieť TESTA v súčasnosti zodpovedá Európska komisia. Vzhľadom na skutočnosť, že vnútroštátne databázy DNA a súčasné vnútroštátne prístupové miesta do siete TESTA sa môžu v členských štátoch nachádzať na iných lokalitách, prístup do siete TESTA sa môže zriadiť buď:

Protokoly a normy, ktoré sa využívajú pri realizácii žiadostí na základe rozhodnutia 2008/615/SVV, sú v súlade s otvorenými normami a spĺňajú požiadavky uložené tvorcami vnútroštátnych bezpečnostných politík členských štátov.

5.2.   Architektúra vyššieho stupňa

Každý členský štát sprístupní iným členským štátom svoje údaje DNA na výmenu a vyhľadávanie v súlade so štandardným spoločným formátom údajov v rozsahu pôsobnosti rozhodnutia 2008/615/SVV. Architektúra vychádza z komunikačného modelu „každý s každým“. Na uchovávanie profilov DNA neexistuje ani centrálny počítačový server, ani centralizovaná databáza.

Obrázok 1: Topológia výmeny údajov o DNA

Okrem súladu s vnútroštátnymi právnymi predpismi na lokalitách členských štátov sa každý z týchto štátov môže rozhodnúť, aký hardvér a softvér by mal na svojich lokalitách využiť na konfiguráciu, aby boli splnené požiadavky vyplývajúce z rozhodnutia 2008/615/SVV.

5.3.   Bezpečnostné normy a ochrana údajov

Posúdili a zaviedli sa tri úrovne bezpečnosti.

5.3.1.    Dátová úroveň

Údaje v profile DNA, ktoré poskytnú jednotlivé členské štáty, sa musia pripraviť v súlade so spoločnými normami ochrany údajov tak, aby žiadajúci členský štát dostal odpoveď, v ktorej sa uvádza najmä, či ide o POZITÍVNY alebo NEGATÍVNY výsledok vyhľadávania; ak je výsledok vyhľadávania POZITÍVNY, v odpovedi sa bude nachádzať identifikačné číslo, ale žiadne osobné údaje. Ďalšie vyšetrovanie po oznámení, že výsledok vyhľadávania bol POZITÍVNY, sa vykoná na dvojstrannej úrovni podľa existujúcich vnútroštátnych právnych a organizačných predpisov, ktoré sa vzťahujú na lokality jednotlivých členských štátov.

5.3.2.    Komunikačná úroveň

Správy, v ktorých sa nachádzajú informácie o profiloch DNA (od žiadajúceho i dožadovaného členského štátu) sa zašifrujú najmodernejším mechanizmom zodpovedajúcim otvoreným normám, ako napríklad sMIME, ešte pred tým, ako sa odošlú na lokality iných členských štátov.

5.3.3.    Prenosová úroveň

Všetky zašifrované správy, v ktorých sa nachádzajú informácie o profile DNA, sa budú zasielať do systémov iných členských štátov prostredníctvom privátneho virtuálneho tunelového systému, ktorý spravuje dôveryhodný poskytovateľ siete na medzinárodnej úrovni a prostredníctvom bezpečných liniek k tomuto tunelovému systému pod vnútroštátnou zodpovednosťou. Tento súkromný virtuálny tunelový systém nemá žiadny spoločný bod s verejným internetom.

5.4.   Protokoly a normy na použitie v šifrovacích mechanizmoch: sMIME a súvisiace balíky

Na šifrovanie správ obsahujúcich informácie o profiloch DNA sa použije otvorená norma sMIME ako rozšírenie v podstate štandardného protokolu elektronickej pošty SMTP. Protokol sMIME (V3) umožňuje podpísané potvrdenia, bezpečnostné nálepky a bezpečné zoznamy adresátov na základe syntaxe kryptografických správ (CMS – Cryptographic Message Syntax), špecifikácie osobitnej skupiny pre internetové inžinierstvo (IETF – Internet Engineering Task Force) pre kryptograficky chránené správy. Môže sa využiť na digitálne podpisovanie, spracovanie, overovanie alebo šifrovanie akejkoľvek formy digitálnych údajov.

Základný certifikát, ktorý využíva mechanizmus sMIME, musí byť v súlade s normou X.509. S cieľom zabezpečiť súlad spoločných noriem a postupov s inými prümskými aplikáciami platia pre operácie šifrovania s mechanizmom sMIME alebo na uplatnenie v rámci rôznych aplikačných a užívateľských softvérov (COTS – Commercial Products of the Shelves) tieto pravidlá spracovania:

Funkcia sMIME je zabudovaná do obrovskej väčšiny moderných balíkov softvéru pre elektronickú poštu vrátane aplikácií Outlook, Mozilla Mail a Netscape Communicator 4.x a funguje pri ich prepojení.

Pretože sMIME sa ľahko integruje do vnútroštátnej informačnej infraštruktúry na lokalitách všetkých členských štátov, vybral sa ako životaschopný mechanizmus na realizáciu komunikačnej úrovne bezpečnosti. Na efektívnejšie splnenie cieľa získania „dôkazu vhodnosti koncepcie“ a zníženie nákladov sa však na prvotnú výmenu údajov o DNA vybralo otvorené štandardné rozhranie na programovanie aplikácií (API – Application Programming Interface) JavaMail. Rozhranie JavaMail poskytuje jednoduché šifrovanie a dešifrovanie emailov pomocou mechanizmov s/MIME a/alebo OpenPGP. Zámerom je poskytnúť jediné a jednoduché rozhranie API klientom elektronickej pošty, ktorí si želajú odosielať a prijímať zašifrovanú poštu v jednom z dvoch najrozšírenejších emailových šifrovacích formátov. Preto budú na splnenie požiadaviek ustanovených v rozhodnutí 2008/615/SVV postačovať akékoľvek moderné implementácie rozhrania JavaMail, ako napríklad produkt spoločnosti Bouncy Castle JCE (Java Cryptographic Extension), ktorý sa použije na zavedenie protokolu sMIME na prvotnú výmenu údajov o DNA medzi členskými štátmi.

5.5.   Aplikačná architektúra

Každý členský štát poskytne ostatným členským štátom súbor štandardizovaných údajov o profiloch DNA, ktoré zodpovedajú platnému spoločnému ICD. Môže tak urobiť buď prostredníctvom poskytnutia logického prehľadu jednotlivých vnútroštátnych databáz, alebo vytvorenia fyzicky exportovateľnej databázy (indexovanej databázy).

Pomocou štyroch hlavných zložiek – emailového servera sMIME, aplikačného servera, oblasti štruktúrovania dát na získavanie/vkladanie údajov a evidenciu prichádzajúcich/odchádzajúcich správ a vyhľadávača zhodných profilov – sa celá aplikačná logika realizuje nezávisle od produktu.

Na uľahčenie integrácie uvedených komponentov do príslušných vnútroštátnych lokalít členských štátov sa určené spoločné funkcie implementovali prostredníctvom „open source“ komponentov, ktoré si každý členský štát môže vybrať na základe svojej vnútroštátnej politiky a vnútroštátnych predpisov v oblasti informačných technológií. Pretože na účely získania prístupu do indexovaných databáz, v ktorých sa nachádzajú profily DNA začlenené v rozhodnutí 2008/615/SVV, sa majú zaviesť uvedené nezávislé mechanizmy, každý členský štát má voľný výber hardvérovej a softvérovej platformy vrátane databázy a operačných systémov.

V rámci existujúcej spoločnej siete sa vytvoril a úspešne odskúšal prototyp výmeny údajov o DNA. Vo funkčnom prostredí sa zaviedla verzia 1.0 a používa sa v každodennej prevádzke. Členské štáty môžu využívať uvedený spoločný produkt, ale môžu si vytvoriť aj vlastné. Komponenty spoločného produktu sa budú udržiavať, prispôsobovať a naďalej rozvíjať podľa meniacich sa požiadaviek IT, súdneho lekárstva alebo operačných požiadaviek polície.

Obrázok 2: Prehľad aplikačnej topológie

5.6.   Protokoly a normy na použitie v aplikačnej architektúre

5.6.1.    XML

Pri výmene údajov o DNA sa naplno využije schéma XML ako príloha k poštovým správam vo formáte SMTP. Rozšíriteľný značkovací jazyk (XML – eXtensible Markup Language) je všeobecným značkovacím jazykom odporúčaným konzorciom W3C na vytváranie značkovacích jazykov na konkrétne účely, v ktorom je možné opísať mnoho rôznych druhov údajov. Profil DNA, ktorý je vhodný na výmenu medzi členskými štátmi, sa prostredníctvom jazyka XML a schémy XML opísal v dokumente ICD.

5.6.2.    ODBC

Databázové rozhranie ODBC (Open DataBase Connectivity) poskytuje štandardnú softvérovú API metódu na prístup do riadiacich systémov databáz nezávisle od programovacích jazykov a databázových a operačných systémov. ODBC má však niekoľko nedostatkov. Správa väčšieho počtu klientských zariadení si môže vyžadovať rôzne ovládače a knižnice DLL. Takáto komplexnosť môže zvýšiť réžiu správy systému.

5.6.3.    JDBC

Rozhranie JDBC (Java DataBase Connectivity) je API pre programovací jazyk Java, v ktorom sa vymedzujú spôsoby prístupu do databázy zo strany klienta. Na rozdiel od ODBC si JDBC nevyžaduje použitie určitého súboru miestnych knižníc DLL na ploche.

Aplikačná logika spracovania žiadostí o profil DNA a odpovedí na lokalite každého členského štátu sa opisuje v nasledujúcom diagrame. Spracovanie žiadostí i odpovedí sa prekrýva s neutrálnou dátovou oblasťou, v ktorej sa nachádzajú rôzne skupiny údajov so spoločnou dátovou štruktúrou.

Obrázok 3: Schéma fungovania aplikácie na lokalite každého členského štátu

5.7.   Komunikačné prostredie

5.7.1.    Spoločná komunikačná sieť: TESTA a ďalšia infraštruktúra

Aplikácia výmena údajov o DNA bude využívať asynchrónny mechanizmus elektronickej pošty na zasielanie žiadostí a prijímanie odpovedí medzi členskými štátmi. Keďže všetky členské štáty majú aspoň jedno vnútroštátne prístupové miesto do siete TESTA, výmena údajov o DNA bude fungovať v rámci tejto siete. TESTA poskytuje prostredníctvom svojho emailového prenosu niekoľko služieb s pridanou hodnotou. Okrem prevádzkovania a spravovania špecifických emailových schránok pre sieť TESTA sa prostredníctvom uvedenej infraštruktúry realizujú aj zoznamy adresátov pošty a postupy presmerovania. Toto umožňuje, aby sa TESTA využívala ako spracovateľské stredisko pre správy adresované štátnym orgánom prepojeným s celoeurópskymi doménami. Zaviesť sa môže aj mechanizmus antivírusovej kontroly.

Prenos poštových správ v rámci siete TESTA je postavený na vysoko dostupnej hardvérovej platforme umiestnenej v centrálnych aplikačných priestoroch siete TESTA a chránenej bránou firewall. Systém správy doménových mien (DNS – Domain Name Services) v rámci siete TESTA preloží informácie z vyhľadávačov zdroja na IP adresy a skryje informácie o adrese pred používateľom a aplikáciami.

5.7.2.    Bezpečnostné otázky

V rámci siete TESTA sa realizovala koncepcia virtuálnej privátnej siete (VPN – Virtual Private Network). Štítkovacia technológia použitá na vytvorenie uvedenej VPN sa bude ďalej vyvíjať, aby podporovala štandard MPLS (Multi-Protocol Label Switching), ktorý vytvorila osobitná skupina IETF.

MPLS spája výhody smerovania protokolu tretej vrstvy a prepínania protokolu druhej vrstvy. Pretože počas prechodu cez chrbticovú sieť sa nevyhodnocujú IP adresy, v štandarde MPLS nie sú žiadne obmedzenia týkajúce sa týchto adries.

Okrem toho budú emailové správy v sieti TESTA II chránené šifrovacím mechanizmom na základe sMIME. Bez poznania kľúča a bez správneho certifikátu sa nikomu v sieti nepodarí správy dešifrovať.

5.7.3.    Protokoly a normy, ktoré sa budú využívať v rámci komunikačnej siete

Protokol SMTP (Simple Mail Transfer Protocol) je vlastne štandardným protokolom na prenos elektronickej pošty cez Internet. SMTP je relatívne jednoduchým textovým protokolom, v ktorom sa špecifikuje jeden alebo viac príjemcov správ a následne sa odošle text správy. SMTP využíva TCP port 25 podľa špecifikácie IETF. Na určenie servera SMTP pre príslušný názov domény sa využíva záznam MX (Mail eXchange) DNS (Domain Name Systems).

Keďže tento protokol bol vytvorený ako čistý textový protokol na základe tabuľky ASCII, prácu s binárnymi súbormi nezvládal. Na zakódovanie binárnych súborov na účely prenosu prostredníctvom SMTP sa vytvorili normy typu MIME. V súčasnosti väčšina serverov SMTP podporuje rozšírenia 8BITMIME a sMIME, ktoré umožňujú prenos binárnych súborov s ľahkosťou čistého textu. Postupy spracovania pre operácie s/MIME sa opisujú v oddiele s/MIME (pozri kapitolu 5.4).

SMTP je protokolom typu „push“, ktorý neumožňuje používateľovi stiahnuť si správy zo vzdialeného servera na žiadosť. Na to musí klient elektronickej pošty využívať protokoly POP3 alebo IMAP. V rámci realizácie výmeny údajov o DNA sa rozhodlo, že sa bude využívať protokol POP3.

Miestni klienti elektronickej pošty využívajú na stiahnutie pošty zo vzdialeného servera cez spojenie TCP/IP tretiu verziu protokolu POP (Post Office Protocol), štandardný internetový protokol aplikačnej vrstvy. Klienti elektronickej pošty posielajú správy cez Internet alebo sieť spoločnosti prostredníctvom profilu SMTP Submit protokolu SMTP. Normou pre prílohy a text, ktorý nie je vytvorený pomocou znakov ASCII, je MIME. Hoci ani POP3, ani SMTP nevyžaduje email formátovaný cez protokol MIME, internetová elektronická pošta prichádza v takomto formáte, a preto klienti služby POP musia MIME chápať a používať. V celom komunikačnom prostredí podľa rozhodnutia 2008/615/SVV sa preto budú nachádzať zložky protokolu POP.

5.7.4.    Pridelenie sieťovej adresy

Operačné prostredie

Sieti TESTA pridelil Európsky úrad na registráciu IP adries (RIPE) vymedzený blok podsiete triedy C. V prípade potreby sa v budúcnosti sieti TESTA môžu prideliť ďalšie bloky adries. Prideľovanie IP adries členským štátom sa zakladá na geografickej schéme Európy. Výmena údajov medzi členskými štátmi v rámci rozhodnutia 2008/615/SVV sa prevádzkuje cez celoeurópsku, logicky uzavretú sieť IP.

Testovacie prostredie

Na zabezpečenie hladko fungujúceho prostredia každodennej prevádzky vo všetkých pripojených členských štátoch je potrebné v rámci uzavretej siete vytvoriť testovacie prostredie pre nové členské štáty, ktoré sa pripravujú na pripojenie. Vymedzil sa zoznam parametrov, ktorý obsahuje IP adresy, nastavenia siete, emailové domény a účty používateľa aplikácií, a tieto parametre sa nastavia na zodpovedajúcej lokalite príslušného členského štátu. Okrem toho sa na skúšobné účely vytvoril súbor pseudoprofilov DNA.

5.7.5.    Konfiguračné parametre

Vytvoril sa bezpečný systém elektronickej pošty, ktorý využíva doménu eu-admin.net. K tejto doméne a pridruženým adresám nebude existovať prístup z lokalít, ktoré sa nenachádzajú na celoeurópskej doméne TESTA, pretože príslušné mená pozná len centrálny DNS server TESTA, ktorý je chránený pred prístupom z internetu.

Mapovanie uvedených adries lokalít (doménových mien) na ich IP adresy sa vykonáva prostredníctvom služby DNS siete TESTA. Ku každej miestnej doméne sa na uvedenom centrálnom serveri DNS pre sieť TESTA pridá poštová položka, čím sa zabezpečí presmerovanie všetkých emailov odoslaných na miestne domény siete TESTA na centrálny poštový relay server siete TESTA. Tento relay server siete TESTA potom správy presmeruje na špecifický poštový server miestnej domény pomocou emailových adries miestnych domén. Prostredníctvom takéhoto prenosu elektronickej pošty sa zabezpečí, že zásadné informácie obsiahnuté v emailoch sa budú pohybovať len cez celoeurópsku uzavretú sieťovú infraštruktúru, a nie cez málo bezpečný internet.

Na lokalitách všetkých členských štátov je preto potrebné vytvoriť subdomény ( tučná kurzíva ) s takouto syntaxou:

„ typ-aplikácie.pruem.kód-členského štátu. eu-admin.net“, kde:

„kód-členského-štátu“ je dvojpísmenovým kódom členského štátu (napr. AT, BE atď.),

„ typ-aplikácie “ je buď DNA, alebo FP.

V nasledujúcej tabuľke sa nachádzajú subdomény členských štátov vytvorené na základe uvedenej syntaxe:

Kapitola 2: Výmena daktyloskopických údajov (dokument o riadení prepojenia)

Cieľom tohto dokumentu o riadení prepojenia je vymedziť požiadavky na výmenu daktyloskopických informácií medzi automatickými systémami na identifikáciu odtlačkov prstov (AFIS – Automated Fingerprint Identification Systems) v jednotlivých členských štátoch. Vychádza z vykonávania normy ANSI/NIST-ITL 1-2000 (INT-I, verzia 4.22b) zo strany Interpolu.

Táto verzia zahŕňa všetky základné definície logických záznamov typu 1, 2, 4, 9, 13 a 15, ktoré sa vyžadujú na daktyloskopické spracovanie založené na obrázku alebo charakteristických individuálnych znakoch (markantoch).

1.   Prehľad obsahu súboru

Daktyloskopický súbor pozostáva z viacerých logických záznamov. V pôvodnej norme ANSI/NIST-ITL 1-2000 je vymedzených šestnásť typov záznamov. Medzi každým záznamom a poliami a subpoliami v rámci záznamov sa používajú príslušné oddeľovacie znaky podľa tabuľky ASCII.

Na výmenu informácií medzi agentúrou pôvodu a určenia sa používa len 6 typov záznamov:

1.1.   Typ 1 – Hlavička súboru

Tento záznam obsahuje informácie o smerovaní a informácie opisujúce štruktúru zvyšku súboru. V tomto type záznamu sa tiež vymedzujú typy operácií, ktoré patria do nasledujúcich širších kategórií:

1.2.   Typ 2 – Opisný text

Tento záznam obsahuje textové informácie, ktoré môžu byť zaujímavé pre odosielajúcu a prijímajúcu agentúru.

1.3.   Typ 4 – Obrázok v odtieňoch šedej s vysokým rozlíšením

Tento záznam sa používa na výmenu daktyloskopických obrázkov v odtieňoch šedej (s 8 bitovým kódovaním) s vysokým rozlíšením 500 pixelov na palec. Daktyloskopické obrázky sa komprimujú pomocou algoritmu WSQ (Wavelet/Scalar Quantization) s kompresným pomerom nepresahujúcim 15 : 1. Nesmú sa využívať iné kompresné algoritmy ani nekomprimované obrázky.

1.4.   Typ 9 – Záznam o markantoch

Záznamy typu 9 sa používajú na výmenu údajov o papilárnych líniách alebo markantoch. Ich účelom je čiastočne sa vyhnúť nepotrebnému zdvojeniu kódovacích procesov AFIS a čiastočne umožniť prenos kódov AFIS, ktoré obsahujú menej údajov ako zodpovedajúce obrázky.

1.5.   Typ 13 – Záznam latentného obrázku s rôznym rozlíšením

Tento záznam sa používa na výmenu skrytých obrázkov odtlačkov prstov a dlaní s rôznym rozlíšením spolu s alfanumerickou informáciou o textúre. Skenovacie rozlíšenie obrázkov je 500 pixelov na palec pri 256 odtieňoch šedej. V prípade dostatočnej kvality sa skrytý obrázok komprimuje pomocou algoritmu WSQ. V prípade potreby sa rozlíšenie obrázkov na základe dvojstrannej dohody môže zvýšiť na viac ako 500 pixelov na palec pri viac než 256 odtieňoch šedej. V tomto prípade sa dôsledne odporúča využiť formát JPEG 2000 (pozri dodatok 7).

1.6.   Typ 15 – Záznam odtlačku dlane s rôznym rozlíšením

Záznamy obrázkov s označením polí typu 15 sa používajú na výmenu obrázkov odtlačkov dlane s rôznym rozlíšením spolu s alfanumerickou informáciou o textúre. Skenovacie rozlíšenie obrázkov je 500 pixelov na palec pri 256 odtieňoch šedej. Kvôli minimalizácii objemu údajov sa všetky obrázky odtlačkov dlane komprimujú pomocou algoritmu WSQ. V prípade potreby sa rozlíšenie obrázkov na základe dvojstrannej dohody môže zvýšiť na viac ako 500 pixelov na palec pri viac než 256 odtieňoch šedej. V tomto prípade sa dôsledne odporúča využiť formát JPEG 2000 (pozri dodatok 7).

2.   Formát záznamu

Prenášaný súbor sa skladá z jedného alebo viacerých logických záznamov. Pri každom logickom zázname v súbore sa nachádza niekoľko informačných polí, ktoré k takémuto záznamu prináležia. Každé informačné pole môže obsahovať jeden alebo viacero základných informačných prvkov s jedinou hodnotou. Tieto prvky sa spoločne používajú na prenos rôznych aspektov údajov, ktoré sa v danom poli nachádzajú. Informačné pole môže pozostávať aj z jedného alebo viacerých zoskupených informačných prvkov, ktoré sa v danom poli niekoľkokrát opakujú. Takéto zoskupenie informačných prvkov sa nazýva podpole. Informačné pole preto pozostáva z jedného alebo viacerých podpolí obsahujúcich informačné prvky.

2.1.   Separátory informácií

V logických záznamoch ohraničených tagmi sa mechanizmy na ohraničenie informácií uplatňujú vo forme štyroch separátorov informácií ASCII. Ohraničené informácie môžu byť prvkami v rámci poľa alebo podpoľa, poliami v rámci logických záznamov alebo viackrát sa vyskytujúcimi podpoliami. Uvedené separátory informácií sa vymedzujú v norme ANSI X3.4. Sú to znaky, ktoré sa používajú na oddelenie a zatriedenie informácií v logickom zmysle. V rámci hierarchických vzťahov je najinkluzívnejším znakom separátor súboru „FS“, po ňom separátor skupiny „GS“, separátor záznamu „RS“ a nakoniec separátor jednotky „US“. V tabuľke 1 sa nachádza zoznam týchto separátorov a opis ich použitia v rámci uvedenej normy.

Z funkčného hľadiska by sa mali separátory informácií považovať za označenie typu údajov, ktoré po nich nasledujú. Znak „US“ oddeľuje jednotlivé informácie v poli či podpoli. Signalizuje, že ďalšia informácia bude údaj, ktorý sa týka daného poľa či podpoľa. Viaceré podpolia v poli oddelenom pomocou znaku „RS“ naznačujú začiatok ďalšej skupiny opakovaných informácií. Separátor „GS“ použitý medzi informačnými poliami signalizuje začiatok nového poľa, ktoré predchádza poľu identifikovanému zobrazeným číslom. Podobne by aj výskyt separátora „FS“ mal znamenať začiatok nového logického záznamu.

Tieto štyri znaky majú význam len v prípade, ak sa použijú ako separátory jednotlivých údajov v poliach textových záznamov ASCII. V binárnych obrázkoch či v binárnych poliach nemajú tieto znaky žiaden osobitný význam – sú len súčasťou vymieňaných údajov.

Za bežných okolností by sa nemali vyskytovať prázdne polia ani nulové informácie, a preto by sa medzi akýmikoľvek dvoma údajmi mal objavovať len jeden separátor. Výnimkou z tohto pravidla sú prípady, keď nie sú údaje v poliach alebo informáciách v rámci transakcie dostupné, ak chýbajú alebo sú nepovinné, a ak priebeh transakcie nezávisí od prítomnosti takýchto údajov. V takýchto prípadoch sa namiesto vkladania „vaty“ medzi separátory môžu spolu objaviť viaceré priľahlé separátory.

Pri definovaní poľa, ktoré sa skladá z troch informácií, platia tieto pravidlá. Ak chýba druhá informácia, medzi prvou a treťou informáciou sa objavia dva znaky „US“ vedľa seba. Ak by chýbala druhá i tretia informácia, mali by sa použiť tri separátory – dva znaky „US“ a separátor uzatvárajúci pole či podpole. Vo všeobecnosti platí, že ak pre pole alebo podpole nie je dostupná jedna povinná alebo nepovinná informácia, alebo viacero takýchto informácií, mal by sa vložiť zodpovedajúci počet separátorov.

Je možné, aby vedľa seba existovali kombinácie dvoch alebo viacerých zo štyroch dostupných separátorov. Ak pri informačných položkách, podpoliach alebo poliach chýbajú údaje alebo ak nie sú dostupné, počet použitých separátorov musí byť o jeden nižší, ako počet vyžadovaných informácií, podpolí alebo polí.

2.2.   Rozvrhnutie záznamu

V logických záznamoch označených tagmi sa každé použité informačné pole očísluje v súlade s touto normou. Formát pre každé pole pozostáva z čísla typu logického záznamu, po ktorom nasleduje bodka „.“, a z čísla poľa, po ktorom nasleduje dvojbodka „:“; po nich nasledujú príslušné informácie pre dané pole. Číslo poľa ohraničeného tagmi môže byť akékoľvek číslo pozostávajúce z jednej až deviatich číslic medzi bodkou a dvojbodkou. Vykladá sa ako nezáporný celočíselný kód poľa. Z toho vyplýva, že číslo poľa „2.123:“ je rovnocenné a malo by sa vykladať rovnakým spôsobom ako číslo poľa „2.000000123:“.

Na účely objasnenia sa v tomto dokumente na výpočet polí obsiahnutých v každom z opísaných logických záznamov ohraničených tagmi používa číslo pozostávajúce z troch číslic. Čísla polí budú mať formát „TT.xxx:“, pričom „TT“ bude typ záznamu pozostávajúci z jedného alebo dvoch znakov, po ktorých nasleduje bodka. Ďalšie tri znaky označujú príslušné číslo poľa a nasleduje po nich dvojbodka. Za dvojbodkou sa nachádzajú opisné informácie vo formáte ASCII alebo údaje o obrázku.

V logických záznamoch typu 1 a 2 sa môžu nachádzať len textové dátové polia vo formáte ASCII. V každom type takéhoto záznamu sa ako prvé pole vo formáte ASCII zaznamená úplná dĺžka záznamu (vrátane čísiel polí, bodkočiarok a separátorov). Kontrolný znak separátora ASCII poľa „FS“ (ktorý znamená koniec logického záznamu alebo transakcie) nasleduje po poslednom bajte informácie vo formáte ASCII a zahrnie sa do dĺžky záznamu.

Na rozdiel od konceptu poľa ohraničeného tagmi obsahuje záznam typu 4 len binárne údaje zaznamenané ako usporiadané binárne polia s pevnou dĺžkou. Celá dĺžka záznamu sa zaznamená v prvom štvorbajtovom binárnom poli každého záznamu. Pri tomto binárnom zázname sa nezaznamenáva ani číslo záznamu s bodkou, ani číslo identifikátora poľa a nasledujúca dvojbodka. Okrem toho v dôsledku skutočnosti, že všetky polia v tomto zázname majú buď pevnú, alebo vymedzenú dĺžku, sa každý zo štyroch separátorov (US, RS, GS ani FS) môže interpretovať len ako binárny údaj. Znak FS sa pri binárnom zázname nesmie použiť ako separátor ani ako označenie ukončenia transakcie.

3.   Logický záznam typu 1: Hlavička súboru

Prostredníctvom tohto záznamu sa opisuje štruktúra súboru, jeho typ a iné dôležité informácie. Súbor znakov používaných pre polia typu 1 obsahuje len 7-bitový ANSI kód na výmenu informácií.

3.1.   Polia pre logický záznam typu 1

3.1.1    Pole 1.001: Dĺžka logického záznamu (LEN – Logical Record Length)

Toto pole obsahuje informáciu o celkovom počte bajtov v celom logickom zázname typu 1. Pole sa začína kódom „1.001:“, po ktorom nasleduje celková dĺžka záznamu vrátane každého znaku každého poľa a separátorov informácií.

3.1.2.    Pole 1.002: Číslo verzie (VER – Version Number)

Toto štvorbajtové pole konkretizuje číslo verzie normy ANSI/NIST, ktorú použil softvér alebo systém, pomocou ktorého sa vytvoril predmetný súbor, aby sa zabezpečilo, že používatelia vedia, ktorá verzia uvedenej normy sa používa. Prvé dva bajty špecifikujú referenčné číslo hlavnej verzie, druhé dva číslo jej menšej revízie. Napríklad pôvodná norma z roku 1986 sa považuje za prvú verziu a dostane označenie „0100“, zatiaľ čo súčasná norma ANSI/NIST-ITL 1-2000 sa označuje „0300“.

3.1.3.    Pole 1.003: Obsah poľa (CNT – File Content)

V tomto poli sa nachádza zoznam záznamov v súbore usporiadaný podľa typu a poradia, v ktorom sa tieto záznamy v logickom súbore objavujú. Pozostáva z jedného alebo viacerých podpolí, z ktorých každé naopak obsahuje dve informácie opisujúce jeden logický záznam, ktorý sa nachádza v danom súbore. Takéto podpolia sa vkladajú v rovnakom poradí, v akom sa záznamy zaznamenávajú a prenášajú.

Prvá informácia v prvom podpoli je „1“ a odkazuje na to, že ide o záznam typu 1. Nasleduje za ňou druhá informácia, ktorá pozostáva z počtu ďalších záznamov v danom súbore. Tento počet sa rovná počtu ostávajúcich podpolí poľa 1.003.

Každé z ostávajúcich podpolí sa spája s jedným záznamom v súbore a poradie podpolí zodpovedá poradiu záznamov. Každé podpole obsahuje dve informácie. Prvou je identifikácia typu záznamu, druhou IDC záznamu. Na oddelenie týchto informácií sa používa separátor „US“.

3.1.4.    Pole 1.004: Typ transakcie (TOT – Type of Transaction)

Toto pole obsahuje trojpísmenovú skratku, ktorou sa označuje typ transakcie. Tieto kódy sa môžu líšiť od kódov, ktoré sa používajú pri inom uplatňovaní normy ANSI/NIST.

CPS: vyhľadávanie odtlačkov súvisiacich s trestnou činnosťou (Criminal Print-to-Print Search). Táto transakcia je žiadosťou o vyhľadanie záznamu, ktorý sa týka trestného činu, v rámci databázy odtlačkov. Odtlačky sa v súbore musia nachádzať ako obrázok komprimovaný algoritmom WSQ.

V prípade NEGATÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

V prípade POZITÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

Typ transakcie CPS je zhrnutý v tabuľke A.6.1 (v dodatku 6).

PMS: vyhľadávanie v databáze skrytých obrazcov (Print-to-Latent Search). Táto transakcia sa použije v prípade, ak sa súbor odtlačkov pri vyhľadávaní porovnáva s databázou neidentifikovaných skrytých obrazcov. Odpoveď bude obsahovať pozitívny/negatívny výsledok vyhľadávania v cieľovom automatizovanom systéme identifikácie odtlačkov. Ak sa nájde viac neidentifikovaných skrytých obrazcov, vráti sa niekoľko transakcií SRE, pričom v každej sa bude nachádzať jeden obrázok. Odtlačky sa v súbore musia nachádzať ako obrázok komprimovaný algoritmom WSQ.

V prípade NEGATÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

V prípade POZITÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

Typ transakcie PMS je zhrnutý v tabuľke A.6.1 (v dodatku 6).

MPS: vyhľadávanie skrytých obrazcov v databáze odtlačkov (Latent-to-Print Search). Táto transakcia sa používa pri vyhľadávaní latentného obrazca v databáze odtlačkov prstov. V súbore sa musia nachádzať informácie o markantoch latentného obrazca a obrázok (komprimovaný algoritmom WSQ).

V prípade NEGATÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

V prípade POZITÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

Typ transakcie MPS je zhrnutý v tabuľke A.6.4 (v dodatku 6).

MMS: vyhľadávanie skrytých obrazcov v databáze skrytých obrazcov (Latent-to-Latent Search). Pri tejto transakcii sa v súbore nachádza skrytý obrazec, ktorý sa má porovnávať s databázou neidentifikovaných skrytých obrazcov, aby sa zistila spojitosť medzi rôznymi miestami činu. V súbore sa musia nachádzať informácie o markantoch latentného obrazca a obrázok (komprimovaný algoritmom WSQ).

V prípade NEGATÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

V prípade POZITÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

Typ transakcie MMS je zhrnutý v tabuľke A.6.4 (v dodatku 6).

SRE: Túto transakciu vracia agentúra určenia ako reakciu na daktyloskopické informácie. Odpoveď bude obsahovať pozitívny/negatívny výsledok vyhľadávania v cieľovom automatizovanom systéme identifikácie odtlačkov. Ak sa nájde viac kandidátov, vráti sa niekoľko transakcií SRE, pričom v každej sa bude nachádzať jeden kandidát.

Typ transakcie SRE je zhrnutý v tabuľke A.6.2 (v dodatku 6).

ERR: Túto transakciu vracia cieľový AFIS ako označenie chyby v transakcii. Obsahuje pole so správou (ERM), v ktorej sa oznamuje zistená chyba. Vrátia sa tieto logické záznamy:

Typ transakcie ERR je zhrnutý v tabuľke A.6.3 (v dodatku 6).

Kľúč:

M

=

povinné (Mandatory),

M*

=

môže sa použiť len jeden z dvoch typov záznamov,

O

=

nepovinné (Optional),

C

=

závisí od dostupnosti údajov (Conditional),

–

=

nie je povolené,

1*

=

závisí od pôvodných systémov.

3.1.5.    Pole 1.005: Dátum transakcie (DAT – Date of Transaction)

Toto pole označuje dátum začatia transakcie a musí zodpovedať štandardnému tvaru ISO: RRRRMMDD,

v ktorom RRRR je rok, MM je mesiac a DD je deň v mesiaci. Pri dátumoch s jednou číslicou sa používa úvodná nula. Napríklad tvar „19931004“ znamená 4. októbra 1993.

3.1.6.    Pole 1.006: Priorita (PRY – Priority)

V tomto nepovinnom poli sa určuje priorita žiadosti na stupnici od 1 po 9. Číslom 1 sa označuje najvyššia priorita, číslom 9 najnižšia. Transakcie s prioritou 1 sa spracúvajú bezodkladne.

3.1.7.    Pole 1.007: Identifikátor agentúry určenia (DAI – Destination Agency Identifier)

V tomto poli sa pre transakciu špecifikuje agentúra určenia.

Pozostáva z dvoch informácií v tomto formáte: CC/agency.

Prvá informácia obsahuje kód krajiny (Country Code) vymedzený v norme ISO 3166, ktorý pozostáva z dvoch alfanumerických znakov. Druhá informácia, agency (agentúra), je voliteľný text na identifikáciu agentúry obsahujúci najviac 32 alfanumerických znakov.

3.1.8.    Pole 1.008: Identifikátor agentúry pôvodu (ORI – Originating Agency Identifier)

V tomto poli sa špecifikuje pôvodca súboru, a to v rovnakom formáte ako DAI (pole 1.007).

3.1.9.    Pole 1.009: Kontrolné číslo transakcie (TCN – Transaction Control Number)

Kontrolné číslo na referenčné účely. Mal by ho generovať počítač a malo by mať tento formát: RRSSSSSSSSA,

kde RR je rok transakcie, SSSSSSSS je osemmiestne sériové číslo a A je kontrolný znak vytvorený podľa postupu v dodatku 2.

Ak TCN neexistuje, pole RRSSSSSSSS sa vyplní nulami a kontrolný znak sa vytvorí postupom opísaným vyššie.

3.1.10.    Pole 1.010: Kontrolná odpoveď transakcie (TCR – Transaction Control Response)

Ak je predmetný súbor odpoveďou na žiadosť, toto nepovinné pole bude obsahovať kontrolné číslo transakcie žiadosti. Preto má rovnaký formát ako TCN (pole 1.009).

3.1.11.    Pole 1.011: Pôvodné skenovacie rozlíšenie (NSR – Native Scanning Resolution)

V tomto poli sa špecifikuje bežné skenovacie rozlíšenie systému, ktorý podporuje pôvodca transakcie. Rozlíšenie sa vymedzuje vo formáte dve číslice, desatinná čiarka a ďalšie dve číslice.

Pri všetkých transakciách podľa rozhodnutia 2008/615/SVV by mal byť pomer pri rozlíšení vzoriek 500 pixelov/palec alebo 19,68 pixelu/mm.

3.1.12.    Pole 1.012: Nominálne rozlíšenie pri prenose (NTR – Nominal Transmitting Resolution)

V tomto päťbajtovom poli sa špecifikuje nominálne rozlíšenie prenášaných obrázkov. Rozlíšenie sa vyjadruje v pixeloch/mm v rovnakom formáte ako pri NSR (pole 1.011).

3.1.13.    Pole 1.013: Názov domény (DOM – Domain name)

V tomto povinnom poli sa určuje názov domény na implementáciu logických záznamov typu 2, ktoré definuje používateľ. Obsahuje dve informácie a má formát „INT-I{US}4.22{GS}“.

3.1.14.    Pole 1.014: Greenwichský čas (GMT – Greenwich Mean Time)

Toto povinné pole poskytuje mechanizmus na vyjadrenie dátumu a času v univerzálnych jednotkách stredného greenwichského času (GMT). V prípade použitia obsahuje pole GMT univerzálny dátum, ktorý bude doplnkom miestneho dátumu uvedeného v poli 1.005 (DAT). Využitím poľa GMT sa odstránia nezrovnalosti v miestnych časoch, ktoré sa vyskytujú v prípade, ak sa transakcia a odpoveď prenášajú medzi dvoma miestami oddelenými niekoľkými časovými pásmami. Pole GMT poskytuje univerzálny dátum a 24-hodinový svetový čas nezávisle od časových pásiem. Funguje vo formáte „CCRRMMDDHHMMSSZ“, pričom tento 15-znakový reťazec je vytvorený spojením dátumu a GMT a zakončený písmenom Z, Znaky „CCRR“ predstavujú rok transakcie, „MM“ desiatkové a jednotkové hodnoty mesiaca, „DD“ rovnaké hodnoty dňa, „HH“ zastupujú hodinu, „MM“ minútu a „SS“ sekundu. Úplný dátum nesmie byť neskorší, ako je aktuálny dátum.

4.   Logický záznam typu 2: Opisný text

Štruktúra väčšiny tohto záznamu sa v pôvodnej norme ANSI/NIST nedefinuje. Obsahuje informácie, ktoré môžu byť konkrétne zaujímavé pre odosielajúcu a prijímajúcu agentúru. Na zabezpečenie kompatibilnosti komunikujúcich daktyloskopických systémov sa vyžaduje, aby sa v záznamoch nachádzali iba polia, ktoré sú uvedené nižšie. V tomto dokumente sa upresňuje, ktoré polia sú povinné a ktoré nepovinné, a vymedzuje sa v ňom štruktúra jednotlivých polí.

4.1.   Polia pre logický záznam typu 2

4.1.1.    Pole 2.001: Dĺžka logického záznamu (LEN – Logical Record Length)

V tomto povinnom poli sa uvádza dĺžka daného záznamu typu 2 a celkový počet bajtov vrátane každého znaku každého poľa v zázname a separátorov informácií.

4.1.2.    Pole 2.002: Znak označenia obrázku (IDC – Image Designation Character)

IDC v tomto povinnom poli je zobrazením IDC definovaného v poli obsah súboru (CNT) záznamu typu 1 (pole 1.003), a to vo formáte ASCII.

4.1.3.    Pole 2.003: Systémové informácie (SYS – System Information)

Toto pole je povinné a obsahuje štyri bajty, ktoré označujú verziu INT-I, s ktorou je daný záznam typu 2 v súlade.

Prvé dva bajty špecifikujú číslo hlavnej verzie, druhé dva číslo jej menšej revízie. Napríklad, táto implementácia vychádza z verzie 4 revízie 22 INT-I, a preto bude označená kódom „0422“.

4.1.4.    Pole 2.007: Číslo prípadu (CNO – Case Number)

Číslo, ktoré miestny daktyloskopický úrad pridelil zbierke skrytých obrazcov nájdených na mieste činu. Prijal sa tento formát: CC/number,

kde CC je kód krajiny v databáze Interpolu s dĺžkou dvoch alfanumerických znakov a number (číslo) sa riadi podľa príslušných miestnych usmernení, pričom môže mať až 32 alfanumerických znakov.

Toto pole umožňuje systému identifikovať latentné obrazce spojené s konkrétnym trestným činom.

4.1.5.    Pole 2.008: Číslo sekvencie (SQN – Sequence Number)

Toto číslo špecifikuje každú sekvenciu skrytých obrazcov v rámci prípadu a môže byť až štvormiestne. Sekvencia je skrytý obrazec alebo súbor skrytých obrazcov, ktoré sú spojené na účely archivácie a/alebo vyhľadávania. Z tejto definície vyplýva, že číslo sekvencie treba prideliť každému jednotlivému latentnému obrazcu.

Toto pole sa spolu s MID (pole 2.009) môže využiť na identifikáciu konkrétneho latentného obrazca v rámci sekvencie.

4.1.6.    Pole 2.009: Identifikátor latentného obrazca (MID – Latent Identifier)

Toto pole špecifikuje jednotlivé latentné obrazce v rámci sekvencie. Jeho hodnota je jedno alebo dve písmená, pričom „A“ sa prideľuje prvému latentnému obrazcu, „B“ druhému a tak ďalej až po „ZZ“. Toto pole sa využíva analogicky ako číslo sekvencie pri skrytých obrazcoch uvedené v opise poľa SQN (pole 2.008).

4.1.7.    Pole 2.010: Trestné referenčné číslo (CRN)

Toto jedinečné referenčné číslo prideľuje vnútroštátna agentúra osobe, ktorá je po prvýkrát obvinená zo spáchania trestného činu. V jednej krajine nemôže mať tá istá osoba viac CRN, a taktiež nesmie mať rovnaké CRN ako iná osoba. Rovnaká osoba však môže mať rôzne trestné referenčné čísla v iných krajinách, pričom na ich rozlíšenie slúži kód krajiny.

Pre pole CRN sa prijal tento formát: CC/number,

kde CC je kód krajiny v norme ISO 3166 s dĺžkou dvoch alfanumerických znakov a number (číslo) sa riadi podľa príslušných vnútroštátnych usmernení agentúry pôvodu, pričom môže mať až 32 alfanumerických znakov.

Pri transakciách v súlade s rozhodnutím 2008/615/SVV sa bude toto pole používať na zapísanie vnútroštátneho trestného referenčného čísla agentúry pôvodu, ktoré je spojené s obrázkami v záznamoch typu 4 alebo typu 15.

4.1.8.    Pole 2.012: Neurčené identifikačné číslo (MN1 – Miscellaneous Identification Number)

Toto pole obsahuje CRN (pole 2.010) prenesené prostredníctvom transakcie CPS alebo PMS bez úvodného kódu krajiny.

4.1.9.    Pole 2.013: Neurčené identifikačné číslo (MN2 – Miscellaneous Identification Number)

Toto pole obsahuje CNO (pole 2.007) prenesené prostredníctvom transakcie MPS alebo MMS bez úvodného kódu krajiny.

4.1.10.    Pole 2.014: Neurčené identifikačné číslo (MN3 – Miscellaneous Identification Number)

Toto pole obsahuje SQN (pole 2.008) prenesené prostredníctvom transakcie MPS alebo MMS

4.1.11.    Pole 2.015: Neurčené identifikačné číslo (MN4 – Miscellaneous Identification Number)

Toto pole obsahuje MID (pole 2.009) prenesené prostredníctvom transakcie MPS alebo MMS

4.1.12.    Pole 2.063: Ďalšie informácie (INF – Additional Information)

V prípade transakcie SRE na základe žiadosti PMS sa v tomto poli nachádzajú informácie o prste, ktorý znamenal POZITÍVNY výsledok vyhľadávania. Formát poľa je:

NN, kde NN je dvojmiestny numerický kód pozície prsta podľa definície v tabuľke 5.

Vo všetkých ostatných prípadoch je toto pole nepovinné. Pozostáva z 32 alfanumerických znakov a môže poskytovať dodatočné informácie týkajúce sa žiadosti.

4.1.13.    Pole 2.064: Zoznam respondentov (RLS – Respondents List)

Toto pole obsahuje aspoň dve podpolia. Prvé z nich opisuje typ vykonaného vyhľadávania, a to pomocou trojpísmenovej skratky, ktorou sa špecifikuje typ transakcie v poli TOT (pole 1.004). Druhé podpole obsahuje jeden znak. Znak „I“ sa používa na označenie POZITÍVNEHO výsledku vyhľadávania, zatiaľ čo v opačnom prípade (NEGATÍVNY výsledok vyhľadávania) sa použije znak „N“. Tretie podpole obsahuje identifikátor sekvencie pre výsledky kandidátov a celkový počet kandidátov, pričom tieto dve informácie sú oddelené lomkou. V prípade viacerých kandidátov sa vráti viac správ.

V prípade potenciálneho POZITÍVNEHO výsledku vyhľadávania obsahuje štvrté podpole reťazec z najviac šiestich číslic. Ak sa POZITÍVNY výsledok vyhľadávania overil, hodnota tohto poľa sa definuje ako „999999“.

Príklad: „CPS{RS}I{RS}001/001{RS}999999{GS}“.

Ak vzdialený AFIS neprideľuje skóre, na príslušnom mieste sa zapíše nula.

4.1.14.    Pole 2.074: Pole správy o stave/chybe (ERM)

Toto pole obsahuje chybové správy vyplývajúce z transakcií, ktoré sa budú zasielať späť žiadateľovi ako súčasť chybových transakcií.

Chybové správy od 100 do 199:

Tieto chybové správy sa týkajú overenia záznamov ANSI/NIST a sú definované ako:

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

<error_code 2>: IDC <idc_number 2> FIELD <field_id 2> <dynamic text 2>...

kde

Príklad:

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

Toto pole je pre chybové transakcie povinné.

4.1.15.    Pole 2.320: Očakávaný počet kandidátov (ENC – Expected Number of Candidates)

Toto pole obsahuje najvyšší počet kandidátov na overenie, ktorý očakáva žiadajúca agentúra. Hodnota ENC nesmie prekročiť hodnoty vymedzené v tabuľke 11.

5.   Logický záznam typu 4: Obrázok v odtieňoch šedej s vysokým rozlíšením

Malo by sa pripomenúť, že záznamy typu 4 sú vo svojej podstate skôr binárne než ASCII. Preto má každé pole v zázname pridelenú konkrétnu pozíciu, z čoho vyplýva, že všetky polia sú povinné.

Norma umožňuje, aby sa v rámci záznamu špecifikovala veľkosť i rozlíšenie obrázku. Vyžaduje si, aby logické záznamy typu 4 obsahovali údaje o daktyloskopických obrázkoch, ktoré sa prenášajú pri nominálnej hustote od 500 do 520 pixelov na palec. Uprednostňovaný pomer pri nových obrázkoch je 500 pixelov na palec alebo 19,68 pixelu na milimeter. Hustota vymedzená v INT-I je 500 pixelov na palec, ale podobné systémy môžu medzi sebou komunikovať pri inom pomere, v rámci rozmedzia od 500 do 520 pixelov na palec.

5.1.   Polia pre logický záznam typu 4

5.1.1.    Pole 4.001: Dĺžka logického záznamu (LEN – Logical Record Length)

V tomto štvorbajtovom poli sa uvádza dĺžka daného záznamu typu 4 a celkový počet bajtov vrátane každého bajtu každého poľa v zázname.

5.1.2.    Pole 4.002: Znak označenia obrázku (IDC – Image Designation Character)

Binárna forma čísla IDC v hlavičke s veľkosťou jedného bajtu.

5.1.3.    Pole 4.003: Typ zobrazenia (IMP – Impression Type)

Typ zobrazenia je pole s veľkosťou jedného bajtu, ktoré sa nachádza na šiestom bajte záznamu.

5.1.4.    Pole 4.004: Poloha prsta (FGP – Finger Position)

Toto pole s pevnou dĺžkou šiestich bajtov sa nachádza na siedmom až dvanástom bajte záznamu typu 4. Obsahuje možné polohy prstov začínajúc od bajtu najviac vľavo (siedmy bajt záznamu). Známa alebo najpravdepodobnejšia poloha prsta sa vyberá z tabuľky 5. Vložením polohy ďalších prstov v rovnakom formáte sa v rámci ostávajúcich piatich bajtov môže odkázať až na ďalších päť prstov. Ak sa má použiť odkaz na menej než päť polôh prsta, nevyužité bajty sa vyplnia binárnym číslom 255. Na neznámu polohu prsta sa pri všetkých prstoch používa kód 0.

Pre latentné obrázky z miesta činu sa používajú len kódy 0 až 10.

5.1.5.    Pole 4.005: Rozlíšenie skenovaného obrázku (ISR – Image Scanning Resolution)

Toto jednobajtové pole sa nachádza na 13. bajte záznamu typu 4. Ak obsahuje nulu („0“), potom sa vzorka skenovala pri uprednostňovanom skenovacom pomere 19,68 pixelu/mm (500 pixelov na palec). Ak obsahuje jednotku („1“), potom sa vzorka skenovala pri alternatívnom skenovacom pomere vymedzenom pri zázname typu 1.

5.1.6.    Pole 4.006: Dĺžka horizontálnej línie (HLL – Horizontal Line Length)

Toto pole sa nachádza na 14. a 15. bajte záznamu typu 4. Uvádza počet pixelov na každej skenovacej línii. Najdôležitejší bude prvý bajt.

5.1.7.    Pole 4.007: Dĺžka vertikálnej línie (VLL – Vertical Line Length)

Toto pole sa nachádza na 16. a 17. bajte a zaznamenáva sa v ňom počet skenovaných línií na obrázku. Najdôležitejší je prvý bajt.

5.1.8.    Pole 4.008: Algoritmus kompresie odtieňov šedej (GCA – Gray-scale Compression Algorithm)

Toto jednobajtové pole špecifikuje algoritmus kompresie odtieňov šedej, ktorý sa použil na šifrovanie údajov o obrázku. Binárny kód 1 znamená (na účely tejto aplikácie), že sa použila kompresia WSQ (dodatok 7).

5.1.9.    Pole 4.009: Obrázok

Toto pole obsahuje bajtový tok, ktorý predstavuje obrázok. Jeho štruktúra bude zjavne závisieť od použitého kompresného algoritmu.

6.   Logický záznam typu 9: Záznam o markantoch

Záznamy typu 9 obsahujú text vo formáte ASCII, ktorým sa opisujú markanty a súvisiace informácie odšifrované zo latentného obrazca. Pri vyhľadávaní medzi skrytými obrázkami je počet takýchto záznamov v súbore neobmedzený, pričom každý záznam sa musí týkať iného pohľadu alebo obrazca.

6.1.   Výber markantov

6.1.1.    Identifikácia typu markanta

Touto normou sa definujú tri identifikačné čísla, ktoré sa používajú na opis typu markanta. Uvádzajú sa v tabuľke 6. Koniec papilárnej línie sa označí ako typ 1. Rozdvojenie sa označí ako typ 2. Ak sa markant nedá jasne začleniť medzi tieto dva typy, označí sa ako „iné“, čiže typ 0.

6.1.2.    Umiestnenie a typ markanta

Kvôli dodržaniu súladu šablón s oddielom 5 normy ANSI INCITS 378-2004 sa na určenie umiestnenia (polohy a smeru uhla) jednotlivých markantov použije nasledujúca metóda, ktorou sa rozširuje platná norma INCITS 378-2004.

Poloha alebo umiestnenie markantu, ktorým je zakončenie papilárnej línie, je miesto rozvetvenia centrálneho skeletu priestoru papilárnej brázdy presne pred zakončením danej línie. Ak by sa tri vetvy papilárnej brázdy zúžili na skelet so šírkou jedného pixelu, polohou markantu je bod ich rozvetvenia. Podobne sa aj poloha markantu pri rozdvojení určí ako bod rozvetvenia centrálneho skeletu papilárnej línie. Ak by sa tri vetvy papilárnej línie zúžili na skelet so šírkou jedného pixelu, polohou markantu je bod ich rozvetvenia.

Po konverzii všetkých zakončení papilárnych línií na rozdvojenia sú všetky markanty daktyloskopického obrazca zastúpené ako rozdvojenia. Súradnice bodu rozvetvenia troch vetiev každého markantu na osi x a y (v pixeloch) sa dajú priamo formátovať. Z každého rozdvojenia skeletu sa dá priamo určiť smer markantu. Tri vetvy každého rozdvojenia skeletu sa musia preskúmať v bode zakončenia každej určenej vetvy. Na obrázku 6.1.2 sú zobrazené tri použité metódy na určenie konca vetvy pri skenovacom rozlíšení 500 ppi.

Zakončenie sa určuje podľa následnosti udalostí. Počet pixelov vychádza z rozlíšenia 500 ppi. Z iných rozlíšení bude vyplývať iný počet pixelov.

Obrázok 6.1.2

Uhol markantu sa určuje na základe vytvorenia troch virtuálnych lúčov vybiehajúcich z bodu rozdvojenia smerom k zakončeniu každej z vetiev. Najmenší z troch uhlov, ktoré tieto lúče vytvoria, sa rozdelia na polovicu, čím sa určí smer markantu.

6.1.3.    Súradnicový systém

Na vyjadrenie polohy markanta sa použije karteziánsky súradnicový systém. Polohu markantov zastupujú ich súradnice na osi x a y. Stred súradnicového systému sa nachádza v ľavom hornom rohu pôvodného obrázku, pričom kladná časť osi x smeruje vpravo a osi y nadol. Súradnice markanta na osi x aj y sú vyjadrené vo vzdialenosti od stredu v pixeloch. Malo by sa poznamenať, že poloha stredu a meracie jednotky nie sú v súlade s dohovorom použitým pri definíciách typu 9 v norme ANSI/NIST-ITL 1-2000.

6.1.4.    Smer markantov

Uhly sa vyjadrujú v štandardnom matematickom formáte s nulou vpravo a uhlom rastúcim proti smeru hodinových ručičiek. Zaznamenané uhly sú pri zakončení papilárnej línie v smere dozadu od jej konca a popri nej a pri rozdvojení smerom k stredu papilárnej brázdy. Tento dohovor sa od dohovoru o uhloch vo vymedzeniach pre typ 9 normy ANSI/NIST-ITL 1-2000 líši o 180 stupňov.

6.2.   Polia pre logický záznam typu 9 vo formáte INCITS-378

Všetky polia v záznamoch typu 9 sa zaznamenajú ako text ASCII. V týchto záznamoch polí označených tagmi nie sú povolené žiadne binárne polia.

6.2.1.    Pole 9.001: Dĺžka logického záznamu (LEN – Logical Record Length)

V tomto povinnom poli vo formáte ASCII sa uvádza dĺžka logického záznamu s celkovým počtom bajtov vrátane každého znaku každého poľa v zázname.

6.2.2.    Pole 9.002: Znak označenia obrázku (IDC – Image Designation Character)

Toto povinné dvojbajtové pole sa používa na identifikáciu a určenie polohy údajov o markantoch. Znak označenia obrázku v tomto poli je rovnaký ako IDC v poli obsah súboru v zázname typu 1.

6.2.3.    Pole 9.003: Typ zobrazenia (IMP – Impression Type)

Týmto povinným jednobajtovým poľom sa opisuje spôsob, akým sa získala informácia vo forme daktyloskopického obrázku. Vloží sa doň hodnota ASCII príslušného kódu z tabuľky 4, ktorá vyjadruje typ zobrazenia.

6.2.4.    Pole 9.004: Formát markanta (FMT – Minutiæ Format)

Toto pole obsahuje znak „U“, aby sa uviedlo, že markanty sa formátujú podľa normy M1-378. Napriek tomu, že informácie môžu byť zašifrované v súlade s uvedenou normou, všetky dátové polia záznamu typu 9 musia ostať vo formáte textových polí ASCII.

6.2.5.    Pole 9.126: Informácie CBEFF (Common Biometric Exchange File Format)

Toto pole obsahuje tri informácie. Prvá položka obsahuje hodnotu „27“ (0x1B). Táto hodnota vyjadruje totožnosť vlastníka formátu CBEFF, ktorú pridelilo Medzinárodné združenie biometrických odvetví (IBIA) technickému výboru M1 INCITS. Kódom <US> sa táto položka oddeľuje od typu formátu CBEFF, ktorý má hodnotu „513“ (0x0201) na označenie, že tento záznam obsahuje len údaje o polohe a smere uhla bez informácií v rozšírenom dátovom bloku. Kódom <US> sa táto informácia oddelí aj od identifikátora produktu CBEFF (PID), ktorým sa určuje „vlastník“ šifrovacieho vybavenia. Túto hodnotu určí predajca. V prípade, že bola zverejnená, sa dá zistiť na webovej stránke IBIA (www.ibia.org).

6.2.6.    Pole 9.127: Identifikácia vybavenia na odber vzoriek

Toto pole obsahuje dve informácie oddelené separátorom <US>. Prvé obsahuje kód „APPF“ v prípade, že pôvodne použité vybavenie na získanie obrázku malo osvedčenie zhody potvrdzujúce súlad s dodatkom F (IAFIS Image Quality Specification, 29. januára 1999) špecifikácie FBI na elektronický prenos odtlačkov prstov CJIS-RS-0010. Ak takéto osvedčenie neexistovalo, pole bude obsahovať hodnotu „NONE“. Druhá informácia obsahuje identifikačné číslo vybavenia na odber vzoriek, čo je evidenčné číslo vybavenia, ktoré prideľuje predajca. Hodnota „0“ znamená, že identifikačné číslo nebolo nahlásené.

6.2.7.    Pole 9.128: Dĺžka horizontálnej línie (HLL – Horizontal Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet pixelov na jednej horizontálnej línii prenášaného obrázku. Maximálna horizontálna veľkosť je obmedzená na 65 534 pixelov.

6.2.8.    Pole 9.129: Dĺžka vertikálnej línie (VLL – Vertical Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet horizontálnych línií na prenášanom obrázku. Maximálna vertikálna veľkosť je obmedzená na 65 534 pixelov.

6.2.9.    Pole 9.130: Jednotky zobrazenia (SLC – Scale Units)

Toto povinné pole vo formáte ASCII obsahuje jednotky, v ktorých sa opisuje vzorkovacia frekvencia obrázku (hustota pixelov). Jednotka („1“) v tomto poli znamená pixely na palec, zatiaľ čo dvojka („2“) označuje pixely na centimeter. Nula („0“) v tomto poli označuje, že sa nezadala žiadna stupnica. V tomto prípade sa zobrazovací pomer v pixeloch udáva na základe podielu HPS/VPS.

6.2.10.    Pole 9.131: Horizontálny rozsah v pixeloch (HPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov v horizontálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje horizontálnu zložku pomeru zobrazenia v pixeloch.

6.2.11.    Pole 9.132: Vertikálny rozsah v pixeloch (VPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov vo vertikálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje vertikálnu zložku pomeru zobrazenia v pixeloch.

6.2.12.    Pole 9.133: Zobrazenie odtlačku prsta

Toto povinné pole obsahuje číslo zobrazenia odtlačku prsta spojeného s údajmi v tomto zázname. Číslo zobrazenia začína nulou („0“) a rastie po jednej až do „15“.

6.2.13.    Pole 9.134: Poloha prsta (FGP – Finger Position)

Toto pole obsahuje kód, ktorým sa označuje poloha prsta, z ktorej vyplynuli informácie v danom zázname typu 9. Na označenie tejto polohy prsta alebo dlane sa zvolí kód medzi 1 a 10 z tabuľky 5 alebo príslušný kód dlane z tabuľky 10.

6.2.14.    Pole 9.135: Kvalita odtlačku prsta

Pole uvádza celkovú kvalitu údajov o markantoch a jeho hodnota je od 0 do 100. Toto číslo vyjadruje celkovú kvalitu záznamu odtlačku prsta a spája kvalitu pôvodného obrázku, výberu markantov a všetkých dodatočných operácií, ktoré mohli ovplyvniť záznam o markantoch.

6.2.15.    Pole 9.136: Počet markantov

Toto povinné pole obsahuje výpočet markantov v predmetnom logickom zázname.

6.2.16.    Pole 9.137: Údaje o markantoch odtlačku

Toto povinné pole obsahuje šesť informácií oddelených separátorom <US>. Pozostáva z niekoľkých podpolí, pričom každé z nich obsahuje podrobnosti o jednom markante. Celkový počet podpolí s markantmi musí zodpovedať počtu v poli 136. Prvá informácia je indexový počet markantov, ktorý začína číslom „1“ a rastie o „1“ pri každom ďalšom markante na odtlačku prsta. Druhou a treťou informáciou sú súradnice znaku v pixeloch na osi x a y. Štvrtá informácia vyjadruje uhol markanta v v jednotkách s dvojstupňovým rozlíšením. Táto hodnota je nezáporné číslo od 0 do 179. Piatou informáciou je typ markanta. Hodnota „0“ zastupuje markant typu „INÉ“, hodnota „1“ je zakončenie papilárnej línie a hodnota „2“ je rozdvojenie papilárnej línie. Šiestou informáciou je kvalita každého markanta. Táto hodnota je v rozmedzí od 1 (najnižšia kvalita) do 100 (najvyššia kvalita). Hodnota „0“ znamená, že informácia o kvalite nie je dostupná. Každé podpole musí byť od ďalšieho oddelené separátorom <RS>.

6.2.17.    Pole 9.138: Informácia o počte papilárnych línií

Toto pole je zložené zo súboru podpolí, z ktorých každé obsahuje tri informácie. Prvá informácia prvého podpoľa označuje metódu počítania papilárnych línií. Nula („0“) znamená, že nie je možné zistiť metódu sčítania papilárnych línií ani ich poradie v zázname. Číslica „1“ znamená že pri každom centrálnom markante sa údaje o počte papilárnych línií zisťovali smerom k susednému markantu v štyroch kvadrantoch a údaje za centrálny markant sa uvádzajú spoločne. Číslica „2“ znamená že pri každom centrálnom markante sa údaje o počte papilárnych línií zisťovali smerom k susednému markantu v ôsmich oktantoch a údaje za centrálny markant sa uvádzajú spoločne. Zvyšné dve informácie prvého podpoľa obsahujú obe nulu („0“). Informácie sa oddeľujú separátorom <US>. Následné podpolia budú obsahovať indexový počet centrálnych markantov ako prvú informáciu, indexový počet susediacich markantov ako druhú informáciu a počet prekrížených papilárnych línií ako tretiu informáciu. Podpolia sa oddeľujú separátorom <RS>.

6.2.18.    Pole 9.139: Informácie o jadre

Toto pole pozostáva z jedného podpoľa pre každé jadro, ktoré sa nachádza v pôvodnom obrázku. Každé podpole obsahuje tri informácie. Prvé dve informácie obsahujú súradnice na osi x a y v pixeloch. Tretia informácia obsahuje uhol jadra v dvojstupňových jednotkách. Táto hodnota je nezáporné číslo od 0 do 179. Viaceré jadrá sa oddelia separátorom <RS>.

6.2.19.    Pole 9.140: Informácie o delte

Toto pole pozostáva z jedného podpoľa pre každú deltu, ktorá sa nachádza v pôvodnom obrázku. Každé podpole obsahuje tri informácie. Prvé dve informácie obsahujú súradnice na osi x a y v pixeloch. Tretia informácia obsahuje uhol delty v dvojstupňových jednotkách. Táto hodnota je nezáporné číslo od 0 do 179. Viaceré jadrá sa oddelia separátorom <RS>.

7.   Logický záznam typu 13: Skrytý obrázok s rôznym rozlíšením

Logický záznam typu 13 s poliami ohraničenými tagmi obsahuje údaje vo forme obrázkov získané zo skrytých obrazcov. Tieto obrázky sú určené na prenos do agentúr, v ktorých sa z nich automaticky alebo prostredníctvom ľudského zásahu a spracovania získajú potrebné informácie.

Informácie, ktoré sa týkajú použitého skenovacieho rozlíšenia, veľkosti obrázku a iných parametrov vyžadovaných na spracovanie obrázku, sa v rámci záznamu nachádzajú vo forme polí ohraničených tagmi.

Kľúč k typu znakov: N = numerický, A = abecedný, AN = alfanumerický, B = binárny.

7.1.   Polia pre logický záznam typu 13

V nasledujúcich odsekoch sa opisujú údaje obsiahnuté v každom poli logického záznamu typu 13.

V rámci logických záznamov typu 13 sa vstupy robia do číslovaných polí. Vyžaduje sa usporiadanie prvých dvoch polí záznamu a pole obsahujúce údaje vo forme obrázku musí byť posledným fyzickým poľom v zázname. V tabuľke 7 sa pre každé pole v zázname typu 13 nachádza „stavový kód“ (buď „M“ označujúce povinné pole, alebo „O“ označujúce pole nepovinné), číslo poľa, typ znaku, veľkosť poľa a obmedzenie výskytu. V poslednom stĺpci sa nachádza maximálna veľkosť v bajtoch, ktorá vychádza z trojmiestneho čísla poľa. Ak sa v čísle poľa nachádza viac číslic, zvýši sa aj maximálny počet bajtov. Dve položky v stĺpci „veľkosť poľa pri každom výskyte“ zahŕňajú všetky separátory, ktoré sú v poli použité. Údaj v stĺpci „maximálny počet bajtov“ zahŕňa číslo poľa, informáciu a všetky separátory vrátane separátora „GS“.

7.1.1.    Pole 13.001: Dĺžka logického záznamu (LEN – Logical Record Length)

Toto povinné pole vo formáte ASCII obsahuje informáciu o celkovom počte bajtov v logickom zázname typu 13. Pole 13.001 špecifikuje dĺžku záznamu vrátane každého znaku každého poľa v zázname a separátorov.

7.1.2.    Pole 13.002: Znak označenia obrázku (IDC – Image Designation Character)

Toto povinné pole vo formáte ASCII sa používa na identifikáciu údajov vo forme latentného obrázku, ktoré sa nachádzajú v zázname. Tento IDC je rovnaký ako IDC v poli obsah súboru (CNT) v zázname typu 1.

7.1.3.    Pole 13.003: Typ zobrazenia (IMP – Impression Type)

Týmto povinným jednobajtovým alebo dvojbajtovým poľom vo formáte ASCII sa opisuje spôsob, akým sa získala informácia vo forme latentného obrázku. Do tohto poľa sa vloží príslušný kód latentného obrázku z tabuľky 4 (pri odtlačkoch prstov) alebo z tabuľky 9 (odtlačok dlane).

7.1.4.    Pole 13.004: Agentúra pôvodu/ORI (SRC – Source Agency)

Toto povinné pole vo formáte ASCII obsahuje totožnosť správneho orgánu alebo organizácie, ktorá pôvodne získala obrázok v zázname. Za bežných okolností sa v tomto poli uvedie identifikátor agentúry pôvodu (ORI – Originating Agency Identifier) agentúry, ktorá získala obrázok. Pozostáva z dvoch informácií v tomto formáte: CC/agency.

Prvá informácia obsahuje kód krajiny v databáze Interpolu, ktorý pozostáva z dvoch alfanumerických znakov. Druhá informácia, agency (agentúra), je voliteľný text na identifikáciu agentúry obsahujúci najviac 32 alfanumerických znakov.

7.1.5.    Pole 13.005: Dátum získania latentného obrázku (LCD – Latent Capture Date)

V tomto povinnom poli vo formáte ASCII sa uvádza dátum získania latentného obrázku, ktorý sa nachádza v zázname. Tento dátum sa uvádza ako osem číslic vo formáte CCRRMMDD. CCRR je rok získania obrázku; znaky MM sú desiatkové a jednotkové hodnoty mesiaca a znaky DD zastupujú rovnaké hodnoty pri dni v danom mesiaci. Napríklad, dátum 20000229 znamená 29. februára 2000. Úplný dátum musí skutočne existovať.

7.1.6.    Pole 13.006: Dĺžka horizontálnej línie (HLL – Horizontal Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet pixelov na jednej horizontálnej línii prenášaného obrázku.

7.1.7.    Pole 13.007: Dĺžka vertikálnej línie (VLL – Vertical Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet horizontálnych línií na prenášanom obrázku.

7.1.8.    Pole 13.008: Jednotky zobrazenia (SLC – Scale Units)

Toto povinné pole vo formáte ASCII obsahuje jednotky, v ktorých sa opisuje vzorkovacia frekvencia obrázku (hustota pixelov). Jednotka („1“) v tomto poli znamená pixely na palec, zatiaľ čo dvojka („2“) označuje pixely na centimeter. Nula („0“) v tomto poli označuje, že sa nezadala žiadna škála. V tomto prípade sa zobrazovací pomer v pixeloch udáva na základe podielu HPS/VPS.

7.1.9.    Pole 13.009: Horizontálny rozsah v pixeloch (HPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov v horizontálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje horizontálnu zložku pomeru zobrazenia v pixeloch.

7.1.10.    Pole 13.010: Vertikálny rozsah v pixeloch (VPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov vo vertikálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje vertikálnu zložku pomeru zobrazenia v pixeloch.

7.1.11.    Pole 13.011: Kompresný algoritmus (CGA – Compression Algorithm)

V tomto povinnom poli ASCII sa špecifikuje algoritmus, ktorý sa používa na kompresiu obrázkov v odtieňoch šedej. Kompresné kódy sa nachádzajú v dodatku 7.

7.1.12.    Pole 13.012: Bity na pixel (BPX)

Toto povinné pole vo formáte ASCII obsahuje počet bitov, ktoré predstavujú jeden pixel. Pri bežných hodnotách odtieňov šedej v škále od „0“ do „255“ sa v ňom nachádza číslica „8“. Ak sa v tomto poli nachádza číslica vyššia ako „8“, predstavuje pixel v odtieni šedej s vyššou presnosťou.

7.1.13.    Pole 13.013: Poloha prsta/dlane (FGP – Finger/Palm Position)

V tomto povinnom poli označenom tagmi sa uvádza jedna alebo viac polôh prsta alebo dlane, ktoré sa môžu zhodovať so skrytým obrázkom. Číslo v desiatkovej sústave, ktoré zodpovedá známej alebo najpravdepodobnejšej polohe prsta, sa vyberie z tabuľky 5, alebo ktoré zodpovedá najpravdepodobnejšej polohe dlane, sa vyberie z tabuľky 10 a vloží sa ako jednomiestne alebo dvojmiestne podpole vo formáte ASCII. Na ďalšie polohy prstov alebo dlaní sa môže odkázať vložením alternatívnych kódov polôh vo forme podpolí oddelených separátorom „RS“. Kód „0“ pre „neznámy prst“ sa použije pri odkaze na ktorúkoľvek polohu prsta od 1 do 10. Pri odkaze na všetky polohy dlane v zozname sa použije kód „20“ pre „neznámu dlaň“.

7.1.14.    Polia 13.014 – 13.019: Rezervované na vymedzenie v budúcnosti (RSV – Reserved for future definition)

Tieto polia sú rezervované na zahrnutie do budúcich revízií tejto normy. Žiadne z nich sa nepoužije na tejto úrovni revízie. Ak sa predsa len vyskytnú, majú sa ignorovať.

7.1.15.    Pole 13.020: Poznámka (COM – Comment)

Toto nepovinné pole sa môže použiť na vloženie poznámok alebo iných textových informácií vo formáte ASCII s údajmi o skrytom obrázku.

7.1.16.    Polia 13.021 – 13.199: Rezervované na vymedzenie v budúcnosti (RSV – Reserved for future definition)

Tieto polia sú rezervované na zahrnutie do budúcich revízií tejto normy. Žiadne z nich sa nepoužije na tejto úrovni revízie. Ak sa predsa len vyskytnú, majú sa ignorovať.

7.1.17.    Polia 13.200 – 13.998: Polia vymedzené používateľmi (UDF – User-defined Fields)

Tieto polia vymedzuje používateľ a využijú sa v budúcnosti. Používateľ definuje aj ich veľkosť a obsah, a to v súlade s požiadavkami agentúry určenia. Ak existujú, musia obsahovať textové informácie vo formáte ASCII.

7.1.18.    Pole 13.999: Údaje z obrázku (DAT – Image Data)

Toto pole obsahuje všetky údaje zo získaného latentného obrázku. Jeho číslo je vždy 999 a musí byť posledným fyzickým poľom v zázname. Napríklad, po poli „13.999:“ nasleduje údaj vo forme obrázku zastúpený binárnymi znakmi.

Každý pixel nekomprimovaného údaju v odtieňoch šedej je vyjadrený ôsmimi bitmi (pri 256 odtieňoch šedej) obsiahnutými v jednom bajte. Ak je údaj v poli BPX 13.012 vyšší alebo nižší ako „8“, počet bajtov na pixel bude iný. Ak sa použije kompresia, údaje v pixeloch sa skomprimujú v súlade s technikou špecifikovanou v poli CGA.

7.2.   Koniec logického záznamu typu 13: Skrytý obrázok s rôznym rozlíšením

Kvôli konzistentnosti sa po poslednom bajte údaju z poľa 13.999 použije separátor „FS“ na oddelenie poľa od nasledujúceho logického záznamu. Tento separátor sa musí použiť aj v poli „dĺžka“ logického záznamu typu 13.

8.   Logický záznam typu 15: Odtlačok dlane s rôznym rozlíšením

Logický záznam typu 15 obsahujúci polia ohraničené tagmi obsahuje údaje z obrázku s odtlačkom dlane spolu so súvisiacimi pevnými textovými poliami a poliami definovanými používateľmi a používa sa na výmenu takýchto údajov. Informácie, ktoré sa týkajú použitého skenovacieho rozlíšenia, veľkosti obrázku a iných parametrov alebo poznámok vyžadovaných na spracovanie obrázku, sa v rámci záznamu nachádzajú vo forme polí ohraničených tagmi. Obrázky odtlačkov dlaní poskytnuté iným agentúram spracujú agentúry určenia tak, aby z nich získali potrebné informácie na účely zistenia zhody.

Údaje vo forme obrázku sa získavajú priamo od dotknutej osoby pomocou zariadenia na biometrické skenovanie alebo z karty z odtlačkom dlane alebo iného média, na ktorom sú uložené odtlačky dlane dotknutej osoby.

Každá metóda použitá na získanie obrázkov odtlačkov dlane by mala umožniť získanie súboru obrázkov z každej ruky. Tento súbor by mal obsahovať dlaň dominantnej ruky vo forme jedného naskenovaného obrázku a oblasť celej dlane od zápästia až po končeky prstov na jednom alebo dvoch naskenovaných obrázkoch. Ak sa na celú dlaň použijú dva obrázky, spodný obrázok by mal zahŕňať oblasť od zápästia až po vrch medziprstovej oblasti (tretí prstový kĺb) vrátane oblasti palcovej a malíčkovej podušky. Vrchný obrázok by mal zahŕňať priestor od spodku medziprstovej oblasti až po končeky prstov. Takéto rozdelenie poskytuje dostatočné prekrytie oboch obrázkov, keďže oba zahŕňajú medziprstovú oblasť dlane. Porovnaním štruktúry a podrobných znakov papilárnych línií v tejto spoločnej oblasti môže osoba, ktorá obrázok skúma, presvedčivo vyhlásiť, že oba obrázky pochádzajú z rovnakej dlane.

Keďže sa odtlačok dlane môže použiť na rôzne účely, môže obsahovať jednu alebo viac jedinečných zobrazených oblastí získaných z dlane alebo prsta. Úplný súbor záznamov odtlačkov dlane jednotlivca bude za bežných okolností obsahovať dlaň dominantnej ruky a úplný obrázok alebo úplné obrázky odtlačkov dlaní oboch rúk. Keďže logický záznam obrázku vo forme polí označených tagmi môže obsahovať len jedno binárne pole, pre každú dlaň dominantnej ruky sa bude vyžadovať jeden záznam typu 15, zatiaľ čo pre úplný odtlačok dlane bude potrebný jeden alebo dva takéto záznamy. Preto pri bežnej transakcii s odtlačkami dlaní sa na zobrazenie odtlačkov dlaní dotknutej osoby budú vyžadovať štyri až šesť záznamov typu 15.

8.1.   Polia pre logický záznam typu 15

V nasledujúcich odsekoch sa opisujú údaje obsiahnuté v každom poli logického záznamu typu 15.

V rámci logických záznamov typu 15 sa vstupy robia do číslovaných polí. Vyžaduje sa usporiadanie prvých dvoch polí záznamu a pole obsahujúce údaje vo forme obrázku musí byť posledným fyzickým poľom v zázname. V tabuľke 8 sa pre každé pole v zázname typu 15 nachádza „stavový kód“ (buď „M“ označujúce povinné pole alebo „O“ označujúce pole nepovinné), číslo poľa, typ znaku, veľkosť poľa a obmedzenie výskytu. V poslednom stĺpci sa nachádza maximálna veľkosť v bajtoch, ktorá vychádza z trojmiestneho čísla poľa. Ak sa v čísle poľa nachádza viac číslic, zvýši sa aj maximálny počet bajtov. Dve položky v stĺpci „veľkosť poľa pri každom výskyte“ zahŕňajú všetky separátory, ktoré sú v poli použité. Údaj v stĺpci „maximálny počet bajtov“ zahŕňa číslo poľa, informáciu a všetky separátory vrátane separátora „GS“.

8.1.1.    Pole 15.001: Dĺžka logického záznamu (LEN – Logical Record Length)

Toto povinné pole vo formáte ASCII obsahuje informáciu o celkovom počte bajtov v logickom zázname typu 15. Pole 15.001 špecifikuje dĺžku záznamu vrátane každého znaku každého poľa v zázname a separátorov.

8.1.2.    Pole 15.002: Znak označenia obrázku (IDC – Image Designation Character)

Toto povinné pole vo formáte ASCII sa používa na identifikáciu údajov vo forme obrázku odtlačku dlane, ktoré sa nachádzajú v zázname. Tento IDC je rovnaký ako IDC v poli obsah súboru (CNT) v zázname typu 1.

8.1.3.    Pole 15.003: Typ zobrazenia (IMP – Impression Type)

Týmto povinným jednobajtovým poľom vo formáte ASCII sa uvádza spôsob, akým sa získala informácia vo forme obrázku odtlačku dlane. Do tohto poľa sa vpíše vhodný kód vybraný z tabuľky 9.

8.1.4.    Pole 15.004: Agentúra pôvodu/ORI (SRC – Source Agency)

Toto povinné pole vo formáte ASCII obsahuje totožnosť správneho orgánu alebo organizácie, ktorá pôvodne získala obrázok v zázname. Za bežných okolností sa v tomto poli uvedie identifikátor agentúry pôvodu (ORI – Originating Agency Identifier) agentúry, ktorá získala obrázok. Pozostáva z dvoch informácií v tomto formáte: CC/agency.

Prvá informácia obsahuje kód krajiny v databáze Interpolu, ktorý pozostáva z dvoch alfanumerických znakov. Druhá informácia, agency (agentúra), je voliteľný text na identifikáciu agentúry obsahujúci najviac 32 alfanumerických znakov.

8.1.5.    Pole 15.005: Dátum získania odtlačku dlane (PCD – Palmprint Capture Date)

Toto povinné pole vo formáte ASCII obsahuje dátum získania obrázku odtlačku dlane. Tento dátum sa uvádza ako osem číslic vo formáte CCRRMMDD. CCRR je rok získania obrázku; znaky MM sú desiatkové a jednotkové hodnoty mesiaca a znaky DD zastupujú rovnaké hodnoty pri dni v danom mesiaci. Napríklad, dátum 20000229 znamená 29. februára 2000. Úplný dátum musí skutočne existovať.

8.1.6.    Pole 15.006: Dĺžka horizontálnej línie (HLL – Horizontal Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet pixelov na jednej horizontálnej línii prenášaného obrázku.

8.1.7.    Pole 15.007: Dĺžka vertikálnej línie (VLL – Vertical Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet horizontálnych línií na prenášanom obrázku.

8.1.8.    Pole 15.008: Jednotky zobrazenia (SLC – Scale Units)

Toto povinné pole vo formáte ASCII obsahuje jednotky, v ktorých sa opisuje vzorkovacia frekvencia obrázku (hustota pixelov). Jednotka („1“) v tomto poli znamená pixely na palec, zatiaľ čo dvojka („2“) označuje pixely na centimeter. Nula („0“) v tomto poli označuje, že sa nezadala žiadna škála. V tomto prípade sa zobrazovací pomer v pixeloch udáva na základe podielu HPS/VPS.

8.1.9.    Pole 15.009: Horizontálny rozsah v pixeloch (HPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov v horizontálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje horizontálnu zložku pomeru zobrazenia v pixeloch.

8.1.10.    Pole 15.010: Vertikálny rozsah v pixeloch (VPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov vo vertikálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje vertikálnu zložku pomeru zobrazenia v pixeloch.

8.1.11.    Pole 15.011: Kompresný algoritmus (CGA – Compression Algorithm)

V tomto povinnom poli ASCII sa špecifikuje algoritmus, ktorý sa používa na kompresiu obrázkov v odtieňoch šedej. Údaj „NONE“ v tomto poli znamená, že údaje v zázname nie sú komprimované. Pri obrázkoch, ktoré sa majú komprimovať, sa v tomto poli uvedie uprednostňovaná metóda kompresie obrázkov s odtlačkami všetkých desiatich prstov. Platné kompresné kódy sa uvádzajú v dodatku 7.

8.1.12.    Pole 15.012: Bity na pixel (BPX)

Toto povinné pole vo formáte ASCII obsahuje počet bitov, ktoré predstavujú jeden pixel. Pri bežných hodnotách odtieňov šedej v škále od „0“ do „255“ sa v ňom nachádza číslica „8“. Ak sa v tomto poli nachádza číslica vyššia alebo nižšia ako „8“, predstavuje pixel v odtieni šedej s vyššou alebo nižšou presnosťou.

8.1.13.    Pole 15.013: Poloha odtlačku dlane (PLP – Palmprint Position)

Toto povinné pole vo formáte ASCII obsahuje polohu odtlačku dlane, ktorá zodpovedá obrázku odtlačku dlane. Číselný kód v desiatkovej sústave zodpovedajúci známej alebo najpravdepodobnejšej polohe odtlačku dlane sa vyberie z tabuľky 10 a vloží ako dvojmiestne podpole vo formáte ASCII. V tabuľke 10 sa vymedzujú aj maximálne veľkosti a rozmery pri každej z možných polôh odtlačku dlane.

8.1.14.    Polia 15.014 – 15.019: Rezervované pre budúce vymedzenie (RSV – Reserved for future definition)

Tieto polia sú rezervované na zahrnutie do budúcich revízií tejto normy. Žiadne z nich sa nepoužije na tejto úrovni revízie. Ak sa predsa len vyskytnú, majú sa ignorovať.

8.1.15.    Pole 15.020: Poznámka (COM – Comment)

Toto nepovinné pole sa môže použiť na vloženie poznámok alebo iných textových informácií vo formáte ASCII s údajmi o obrázku odtlačku dlane.

8.1.16.    Polia 15.021 – 15.199: Rezervované pre budúce vymedzenie (RSV – Reserved for future definition)

Tieto polia sú rezervované na zahrnutie do budúcich revízií tejto normy. Žiadne z nich sa nepoužije na tejto úrovni revízie. Ak sa predsa len vyskytnú, majú sa ignorovať.

8.1.17.    Polia 15.200 – 15.998: Polia vymedzené používateľmi (UDF – User-defined Fields)

Tieto polia vymedzuje používateľ a využijú sa v budúcnosti. Používateľ definuje aj ich veľkosť a obsah, a to v súlade s požiadavkami agentúry určenia. Ak existujú, musia obsahovať textové informácie vo formáte ASCII.

8.1.18.    Pole 15.999: Údaje z obrázku (DAT – Image Data)

Toto pole obsahuje všetky údaje zo získaného obrázku odtlačku dlane. Jeho číslo je vždy 999 a musí byť posledným fyzickým poľom v zázname. Napríklad, po poli „15.999:“ nasleduje údaj vo forme obrázku zastúpený binárnymi znakmi. Každý pixel nekomprimovaného údaju v stupňoch šedej je vyjadrený ôsmimi bitmi (pri 256 odtieňoch šedej) obsiahnutými v jednom bajte. Ak je údaj v poli BPX 15.012 vyšší alebo nižší ako „8“, počet bajtov na pixel bude iný. Ak sa použije kompresia, údaje v pixeloch sa skomprimujú v súlade s technikou špecifikovanou v poli CGA.

8.2.   Koniec logického záznamu typu 15: Odtlačok dlane s rôznym rozlíšením

Kvôli konzistentnosti sa po poslednom bajte údaju z poľa 15.999 použije separátor „FS“ na oddelenie poľa od nasledujúceho logického záznamu. Tento separátor sa musí použiť aj v poli „dĺžka“ logického záznamu typu 15.

8.3.   Ďalšie logické záznamy typu 15: Odtlačok dlane s rôznym rozlíšením

Do súboru sa môžu vložiť ďalšie záznamy typu 15. Pre každý ďalší odtlačok dlane sa vyžaduje úplný logický záznam typu 15 spolu so separátorom „FS“.

Typy vyhľadávaní:

9.   Dodatky ku kapitole 2 (výmena daktyloskopických údajov)

9.1.   Dodatok 1: Oddeľovacie kódy ASCII

9.2.   Dodatok 2: Výpočet alfanumerických kontrolných znakov

Pre TCN a TCR (polia 1.09 a 1.10):

Číslo zodpovedajúce kontrolnému znaku sa vytvorí na základe tohto vzorca:

(RR * 108 + SSSSSSSS) Modulo 23,

kde RR sú posledné dve číslice roka a SSSSSSSS je sériové číslo.

Kontrolný znak sa potom vytvorí na základe kontrolnej tabuľky, ktorá sa nachádza nižšie.

Pre CRO (pole 2.010)

Číslo zodpovedajúce kontrolnému znaku sa vytvorí na základe tohto vzorca:

(RR * 106 + NNNNNN) Modulo 23,

kde RR sú posledné dve číslice roka a NNNNNN je sériové číslo.

Kontrolný znak sa potom vytvorí na základe kontrolnej tabuľky, ktorá sa nachádza nižšie.

9.3.   Dodatok 3: Znakové kódy

9.4.   Dodatok 4: Súhrn transakcií

V stĺpci s podmienečnosťou:

O = nepovinné (optional), M = povinné (mandatory), C = s podmienkou, že transakcia je odpoveďou pre agentúru pôvodu (conditional).

V stĺpci s podmienečnosťou:

O = nepovinné (optional), M = povinné (mandatory), C = s podmienkou, že sú dostupné údaje (conditional).

*

=

ak je prenos údajov v súlade s vnútroštátnymi právnymi predpismi (nepatrí do rozhodnutia 2008/615/SVV).

9.5.   Dodatok 5: Vymedzenia záznamov typu 1

V stĺpci s podmienečnosťou: O = nepovinné (optional), M = povinné (mandatory), C = s podmienkou (conditional).

V stĺpci s typom znaku: A = abecedný, N = numerický, B = binárny.

1* Povolené znaky pre názov agentúry sú [„0..9“, „A..Z“, „a..z“, „_“, „.“, „ “, „-“].

9.6.   Dodatok 6: Vymedzenia záznamov typu 2

V stĺpci s podmienečnosťou: O = nepovinné (optional), M = povinné (mandatory), C = s podmienkou (conditional).

V stĺpci s typom znaku: A = abecedný, N = numerický, B = binárny.

1* Povolené znaky sú [„0..9“, „A..Z“, „a..z“, „_“, „.“, „ “, „-“].

9.7.   Dodatok 7: Kódy na kompresiu odtieňov šedej

Kompresné kódy

9.8.   Dodatok 8: Špecifikácia pošty

S cieľom zlepšiť vnútorný rozvrh práce sa do predmetu poštovej správy pri transakcii typu PRUEM napíše kód krajiny (CC) členského štátu, ktorý správu odosiela a typ transakcie (TOT, pole 1.004).

Formát: CC/type of transaction

Príklad: „DE/CPS“.

Telo správy môže ostať prázdne.

Kapitola 3: Výmena údajov z evidencie vozidiel

1.   Spoločný súbor údajov na automatizované vyhľadávanie údajov z evidencie vozidiel

1.1.   Vymedzenie pojmov

Povinné a nepovinné prvky údajov ustanovené v článku 16 ods. 4 sú vymedzené takto:

Povinné (M)

Tento prvok sa musí oznámiť v prípade, že sa informácia nachádza vo vnútroštátnom registri členského štátu. Preto v prípade dostupnosti informácie existuje povinnosť jej výmeny.

Nepovinné (O)

Tento prvok sa môže oznámiť v prípade, že sa informácia nachádza vo vnútroštátnom registri členského štátu. Preto neexistuje povinnosť výmeny informácie ani v prípade, ak je dostupná.

Ak sa prvok v súbore údajov identifikuje ako osobitne dôležitý vzhľadom na rozhodnutie 2008/615/SVV, označí sa (znakom Y).

1.2.   Vyhľadávanie podľa vozidla/vlastníka/držiteľa

1.2.1.    Spúšťacie mechanizmy vyhľadávania

Existujú dva spôsoby vyhľadávania informácií, ktoré sa vymedzujú v ďalšom odseku:

Na základe týchto kritérií vyhľadávania sa ako výsledok vrátia informácie týkajúce sa jedného alebo viacerých vozidiel. Ak sa musí vrátiť informácia o len jednom vozidle, všetky jej prvky sa vrátia v rámci jednej odpovede. Ak sa nájde viac než jedno vozidlo, informácie, ktoré sa vrátia, určí samotný dožiadaný členský štát; budú to buď všetky informácie, alebo len informácie potrebné na rozšírenie vyhľadávania (napr. z dôvodu ochrany súkromia alebo z dôvodu výkonu vyhľadávača).

Informácie potrebné na rozšírenie vyhľadávania sa uvádzajú v odseku 1.2.2.1. V odseku 1.2.2.2 sa uvádza kompletný súbor informácií.

Pri vyhľadávaní podľa čísla karosérie a referenčného dátumu a času sa môže vyhľadávať v databázach jedného alebo všetkých zúčastnených členských štátov.

Ak sa vyhľadáva podľa poznávacej značky a referenčného dátumu a času, musí sa vyhľadávať v databáze konkrétneho členského štátu.

Bežne sa vyhľadáva s použitím skutočného času a dátumu, ale je možné použiť aj referenčný dátum a čas v minulosti. Ak sa vyhľadáva s referenčným dátumom a časom v minulosti a informácie z minulosti nie sú v registri členského štátu dostupné, pretože jednoducho vôbec neexistujú, ako odpoveď sa môžu poskytnúť aktuálne informácie, pričom sa táto skutočnosť výslovne uvedie.

1.2.2.    Súbor údajov

2.   Bezpečnosť údajov

2.1.   Prehľad

Softvérová aplikácia Eucaris umožňuje bezpečnú komunikáciu s inými členskými štátmi a s podpornými (back-end) pôvodnými systémami členských štátov pomocou protokolu XML. Členské štáty si vymieňajú správy prostredníctvom ich priameho odosielania prijímateľovi. Dátové stredisko členského štátu je napojené na sieť Európskej únie TESTA.

Správy vo formáte XML, ktoré sa cez sieť posielajú, sú šifrované. Na šifrovanie sa používa technika SSL. Správy, ktoré sa zasielajú podporným aplikáciám, sú čisto textové správy XML, keďže spojenie medzi klientskou a podpornou aplikáciou by malo byť v chránenom prostredí.

Poskytne sa klientská aplikácia, ktorá sa v rámci členského štátu môže použiť na vyhľadávanie vo vlastnom registri alebo v registri ostatných členských štátov. Títo klienti sa identifikujú prostredníctvom prihlasovacieho mena/hesla alebo klientského certifikátu. Spojenie s používateľom môže byť šifrované, pričom je to v zodpovednosti každého jednotlivého členského štátu.

2.2.   Bezpečnostné prvky výmeny správ

Bezpečnostný dizajn sa zakladá na kombinácii podpisu HTTPS a XML. V tejto alternatíve sa na podpísanie všetkých správ zaslaných na server používa podpis XML, pričom sa prostredníctvom kontroly tohto podpisu dá overiť odosielateľ správy. Na ochranu dôvernosti a celistvosti správy pri prenose sa používa jednostranné zabezpečené spojenie SSL (len s certifikátom servera), ktorým sa poskytuje ochrana proti vymazaniu/opakovaniu a vkladaniu údajov. Namiesto vývoja softvéru na mieru, ktorý by realizoval obojstranné spojenie SSL, sa zaviedol podpis XML. Používanie tohto podpisu je bližšie k plánu webových služieb ako obojstranné spojenie SSL, a preto je aj strategickejšie.

Podpis XML sa môže implementovať rôznymi spôsobmi, pričom zvolený spôsob je v tomto prípade využitie tohto podpisu ako časti špecifikácie Web Services Security (WSS). V tejto špecifikácii sa vymedzuje spôsob použitia podpisu XML. Keďže WSS je postavená na štandarde SOAP, je logické, že SOAP sa bude dodržiavať v čo najväčšej možnej miere.

2.3.   Bezpečnostné prvky, ktoré sa netýkajú výmeny správ

2.3.1.    Autorizácia používateľov

Používatelia webovej aplikácie sa autorizujú sami pomocou používateľského mena a hesla. Keďže sa pritom využíva štandardná autorizácia systému Windows, členské štáty môžu úroveň autorizácie v prípade potreby zvýšiť prostredníctvom využitia klientských certifikátov.

2.3.2.    Úlohy používateľov

Softvérová aplikácia Eucaris podporuje rôzne úlohy používateľov. Každý súbor služieb má vlastnú autorizáciu. Napríklad (výhradní) používatelia funkcie „Treaty of Eucaris“ nemôžu používať funkciu „Prüm“. Služby administrátorov sú od bežných úloh koncových používateľov oddelené.

2.3.3.    Zaznamenávanie a vyhľadávanie údajov o výmene správ

Softvérová aplikácia Eucaris uľahčuje zaznamenávanie všetkých typov informácií. Funkcia správcu umožňuje správcovi vnútroštátneho systému, aby určil, ktoré správy sa zaznamenávajú: žiadosti koncových používateľov, prichádzajúce žiadosti členských štátov, poskytnuté informácie z vnútroštátnych registrov atď.

Aplikácia sa môže nakonfigurovať tak, aby na zaznamenávanie používala vnútornú databázu alebo vonkajšiu databázu (Oracle). Rozhodnutie o tom, ktoré správy sa budú zaznamenávať, jasne závisí od zariadení na zaznamenávanie v pôvodných systémoch a pripojených klientských aplikáciách.

V hlavičke každej správy sa nachádza informácia o žiadajúcom členskom štáte, žiadajúcej organizácii a zúčastnenom používateľovi. Uvádza sa aj dôvod žiadosti.

Prostredníctvom kombinovaného zaznamenávania v žiadajúcom a odpovedajúcom členskom štáte je možné vyhľadať údaje o akejkoľvek výmene správ (napr. na základe žiadosti zúčastneného občana).

Zaznamenávanie sa konfiguruje prostredníctvom webového klienta (menu Administration, Logging configuration). Funkciu zaznamenávania vykonáva Core System. Po umožnení zaznamenávania sa v jednom zázname uloží úplná správa (hlavička aj telo). Úroveň zaznamenávania sa dá nastaviť v súvislosti s definovanou službou a typom správy, ktorá prechádza cez Core System.

Úrovne zaznamenávania

Možné sú tieto úrovne zaznamenávania:

Private (súkromná) – správa sa zaznamenáva: zaznamenávanie NIE je dostupné pre službu „extract logging“, ale je dostupné len na vnútroštátnej úrovni, a to na účely auditu a riešenia problémov.

None (žiadna) – správa sa vôbec nezaznamenáva.

Typy správ

Výmena informácií medzi členskými štátmi pozostáva z niekoľkých správ, ktoré schematicky predstavuje obrázok nachádzajúci sa nižšie.

Existujú tieto typy správ (na obrázku sa uvádzajú pre Core System aplikácie Eucaris členského štátu X):

Obrázok: Typy správ na zaznamenávanie

2.3.4.    Hardvérový bezpečnostný modul

Hardvérový bezpečnostný modul sa nepoužíva.

Hardvérový bezpečnostný modul (HSM – Hardware Security Module) poskytuje kvalitnú ochranu pre kľúč, ktorý sa používa na podpisovanie správ a identifikáciu serverov. Hoci prispieva k celkovej úrovni bezpečnosti, jeho kúpa/údržba je nákladnou záležitosťou a neexistujú žiadne požiadavky na rozhodovanie medzi druhou a treťou úrovňou bezpečnosti HSM FIPS 140-2. Keďže sa používa uzavretá sieť, ktorá účinne znižuje ohrozenie, rozhodlo sa, že HSM sa pre začiatok nepoužije. Ak bude HSM nevyhnutný napr. na získanie akreditácie, môže sa do architektúry systému pridať.

3.   Technické podmienky výmeny údajov

3.1.   Všeobecný opis aplikácie EUCARIS

3.1.1.    Prehľad

Aplikácia Eucaris pripája všetky zúčastnené členské štáty do viaccestnej siete, v ktorej každý členský štát komunikuje priamo s iným členským štátom. Na vytvorenie spojenia nie je potrebný žiadny centrálny komponent. Aplikácia Eucaris umožňuje bezpečnú komunikáciu s inými členskými štátmi a s koncovými pôvodnými systémami členských štátov pomocou protokolu XML. Túto architektúru znázorňuje nasledujúci obrázok.

Členské štáty si vymieňajú správy prostredníctvom ich priameho odosielania prijímateľovi. Dátové stredisko členského štátu je napojené na sieť používanú na výmenu správ (TESTA). Členský štát sa do siete TESTA pripája cez vlastnú vnútroštátnu bránu. Na pripojenie k sieti sa používa brána firewall, ku ktorej je aplikácia Eucaris pripojená pomocou smerovača. V závislosti od alternatívy, ktorá sa zvolí na ochranu správ, používa certifikát buď smerovač alebo samotná aplikácia Eucaris.

Poskytne sa klientská aplikácia, ktorá sa v rámci členského štátu môže použiť na vyhľadávanie vo vlastnom registri alebo v registri ostatných členských štátov. Klientská aplikácia sa pripája k aplikácii Eucaris. Títo klienti sa identifikujú prostredníctvom prihlasovacieho mena/hesla alebo klientského certifikátu. Spojenie s používateľom v externej organizácii (napr. polícii) môže byť šifrované, pričom je to v zodpovednosti každého jednotlivého členského štátu.

3.1.2.    Rozsah funkčnosti systému

Rozsah systému Eucaris je obmedzený na procesy v rámci výmeny informácií medzi orgánmi zodpovednými za evidenciu v členských štátoch a základnou prezentáciou týchto informácií. Postupy a automatizované procesy, pri ktorých sa tieto informácie používajú, sú mimo rozsahu funkčnosti systému.

Členské štáty sa môžu rozhodnúť, či budú využívať klientskú aplikáciu Eucaris alebo si vytvoria vlastnú prispôsobenú klientskú aplikáciu. V tabuľke pod týmto textom sa opisuje, ktoré aspekty systému Eucaris sa používajú povinne a/alebo sú predpísané a ktoré sú nepovinné a/alebo na voľnom zvážení zo strany členských štátov.

3.2.   Požiadavky na funkčnosť a požiadavky, ktoré sa netýkajú funkčnosti

3.2.1.    Generické funkcie

V tomto oddiele sa vo všeobecnosti opisujú hlavné generické funkcie.

3.2.2.    Používanie

3.2.3.    Spoľahlivosť

3.2.4.    Výkon

3.2.5.    Bezpečnosť

3.2.6.    Prispôsobivosť

3.2.7.    Podpora a údržba

3.2.8.    Požiadavky na dizajn

3.2.9.    Uplatniteľné normy

Kapitola 4: Hodnotenie

1.   Hodnotiaci postup podľa článku 20 (príprava rozhodnutí podľa článku 25 ods. 2 rozhodnutia 2008/615/SVV)

1.1.   Dotazník

Príslušná pracovná skupina Rady vypracuje dotazník týkajúci sa každej z automatizovaných výmen údajov ustanovených v kapitole 2 rozhodnutia 2008/615/SVV.

Hneď ako bude členský štát presvedčený, že spĺňa predpoklady na výmenu údajov v relevantnej kategórii, vyplní príslušný dotazník.

1.2.   Skúšobná prevádzka

S cieľom vyhodnotiť výsledky dotazníka uskutoční členský štát, ktorý si želá začať výmenu údajov, skúšobnú prevádzku spolu s jedným alebo viacerými členskými štátmi, ktoré si už vymieňajú údaje podľa predmetného rozhodnutia Rady. Skúšobná prevádzka sa uskutoční krátko pred hodnotiacou návštevou alebo krátko po nej.

Podmienky a pravidlá tejto skúšobnej prevádzky určí príslušná pracovná skupina Rady, pričom budú vychádzať z predchádzajúcej samostatnej dohody s dotknutým členským štátom. O jej praktických podrobnostiach rozhodnú členské štáty, ktoré sa na tejto skúšobnej prevádzke zúčastňujú.

1.3.   Hodnotiaca návšteva

V členskom štáte, ktorý si želá začať výmenu údajov, sa uskutoční hodnotiaca návšteva s cieľom vyhodnotiť výsledky dotazníka.

Podmienky a pravidlá tejto návštevy určí príslušná pracovná skupina Rady, pričom budú vychádzať z predchádzajúcej samostatnej dohody medzi dotknutým členským štátom a hodnotiacim tímom. Dotknutý členský štát umožní hodnotiacemu tímu, aby skontroloval automatizovanú výmenu údajov v kategórii alebo kategóriách údajov, ktoré sa majú hodnotiť, a to najmä prostredníctvom organizácie programu návštevy, v ktorom sa zohľadnia požiadavky hodnotiaceho tímu.

Hodnotiaci tím pripraví do jedného mesiaca správu o hodnotiacej návšteve, ktorú postúpi dotknutému členskému štátu na pripomienkovanie. V prípade potreby hodnotiaci tím správu na základe pripomienok členského štátu zreviduje.

Hodnotiaci tím pozostáva z najviac troch členov, ktorých vymenujú členské štáty, ktoré sa zúčastňujú na automatizovanej výmene údajov v hodnotených kategóriách; títo členovia musia mať skúsenosti s dotknutou kategóriou údajov, musia mať príslušnú vnútroštátnu bezpečnostnú previerku na tieto záležitosti a musia byť ochotní zúčastniť sa na najmenej jednej hodnotiacej návšteve v inom členskom štáte. Komisia sa vyzve, aby sa k hodnotiacemu tímu pridala ako pozorovateľ.

Členovia hodnotiaceho tímu budú dodržiavať dôverný charakter informácií, ktoré získajú pri výkone svojich úloh.

1.4.   Správa Rade

Rade sa na rozhodnutie podľa článku 25 ods. 2 rozhodnutia 2008/615/SVV predloží celková hodnotiaca správa, v ktorej sa zhrnú výsledky dotazníkov, hodnotiacej návštevy a skúšobnej prevádzky.

2.   Hodnotiaci postup podľa článku 21

2.1.   Štatistika a správa

Každý členský štát zostaví štatistiku o výsledkoch automatizovanej výmeny údajov. V záujme zabezpečenia porovnateľnosti, zostaví vzor takejto štatistiky príslušná pracovná skupina Rady.

Štatistika sa každý rok postúpi Komisii a generálnemu sekretariátu, ktorý vypracuje všeobecný prehľad za ukončený rok.

Okrem toho sa členské štáty požiadajú, aby pravidelne, ale nie viac ako raz ročne, zasielali ďalšie informácie o administratívnej, technickej a finančnej realizácii automatizovanej výmeny údajov, ktoré sú potrebné na analýzu a skvalitnenie procesu. Na základe týchto informácií sa pre Radu pripraví správa.

2.2.   Revízia

Rada v primeranom časovom horizonte preskúma uvedený mechanizmus hodnotenia a v prípade potreby ho zreviduje.

3.    Stretnutia expertov

Experti sa budú pravidelne stretávať v rámci príslušnej pracovnej skupiny Rady, aby organizovali a realizovali uvedené postupy hodnotenia, vymieňali si skúsenosti a rokovali o možných zlepšeniach. Ak je to možné, výsledky týchto rokovaní sa začlenia do správy uvedenej v bode 2.1.