AZ EURÓPAI UNIÓ TANÁCSA. Brüsszel, február 4. (26.02) (OR. en) 5660/08 CRIMORG 18 ENFOPOL 21 FELJEGYZÉS

Átírás

1 AZ EURÓPAI UNIÓ TANÁCSA Brüsszel, február 4. (26.02) (OR. en) 5660/08 CRIMORG 18 ENFOPOL 21 FELJEGYZÉS Küldi: Címzett: Tárgy: az elnökség a delegációk Tervezet A Tanács határozata a különösen a terrorizmus és a határokon átnyúló bőnözés elleni küzdelemre irányuló, határokon átnyúló együttmőködés megerısítésérıl szóló 2008/.../IB határozat végrehajtásáról: Melléklet - Újraszövegezési javaslat 1. A Tanács 2007 novemberében általános megközelítést fogadott el a fent említett tanácsi határozattervezet fı részére vonatkozóan. Ezt követıen az elnökség barátai csoport ülést tartott, amelyen megvitatta a határozattervezet mellékletét. 2. Az elnökség barátai csoport november 30-án, január 8-án és február 1-jén tartott ülésén részletesen megvitatta a mellékletet, részben a delegációktól érkezett írásbeli észrevételek alapján. E megbeszélések eredményei az alábbiak: 3. A csoport több kérdés pontosítása és/vagy helyesbítése érdekében apróbb szövegezési módosításokat végzett az 1. fejezetben. Az UK delegáció fenntartással élt e fejezet tekintetében, a szakértık által a meghatározott pontokra (1.1., 1.2., 3.1., , , , , , 5.4., 5.5. és 5.6. pont) vonatkozóan folytatott további megbeszélésekig. 5660/08 ea/zv/akn 1

2 4. Az UK delegáció által felvetett, még lezáratlan pontok között a fı kérdés a prümi határozat szerinti összehasonlításhoz szükséges lókuszok típusát és számát érinti. Egyértelmő, hogy a lókuszok nagyobb számban történı használata növeli az egyezések pontosságát, ezért az összehasonlítást a lehetı legtöbb lókusz alapján kell elvégezni. Ugyanakkor el kell kerülni azt, hogy a túl szigorú összehasonlítási szabályok megállapítása miatt néhány régi adatbázist kizárjanak az összehasonlításból. A cél az, hogy az összehasonlítást a technikailag lehetséges legnagyobb számú lókusz alapján végezzék el az érintett adatbázisok között, lehetıvé téve ugyanakkor alacsonyabb szintő kritériumok alkalmazását, amennyiben ezt a régebbi adatbázisokkal való összehasonlítás szükségessé teszi. 5. A delegációk felkérést kapnak az 1. fejezet 1.1., 1.2. és 3.1. pontjában foglalt szövegjavaslatok, valamint az ezen pontokhoz kapcsolódó lábjegyzetek megvizsgálására. Az UK felkérést kap az e fejezettel kapcsolatos fenntartása feloldására. 6. A delegációktól érkezett észrevételekre válaszul és/vagy a megszövegezés egyértelmővé tétele érdekében a 2. és a 3. fejezetben néhány apróbb, az UK vizsgálati fenntartására figyelemmel elfogadott módosítás és pontosítás elvégzésére került sor. 7. Az UK delegáció felkérést kap az e fejezetekkel kapcsolatos fenntartása feloldására. 8. A 4. fejezetet az eredeti értékelési mechanizmus (kérdıív, kísérleti adatcsere és értékelı látogatás) fenntartása mellett újrafogalmazták, így az egész folyamat kevésbé bürokratikus és erıforrás-intenzív. Ezenfelül a szakértıi találkozókról szóló rész átkerült egy új pontba, annak érdekében, hogy ezeken a találkozókon a szakértık a prümi határozat végrehajtásának az értékelésen kívüli aspektusaival is foglalkozni tudjanak. Nevezetesen a szakértık fogják meghatározni a mintastatisztikát. A fejezetet elfogadták. 9. Több helyen is hivatkozás történik az érintett tanácsi munkacsoport -ra. Nem szükséges és nem is hasznos e mellékletben meghatározni, hogy melyik munkacsoport az illetékes. Ez egy késıbbi szakaszban eldöntendı kérdés. 5660/08 ea/zv/akn 2

3 10. Az e fedılap 4. pontjában foglalt kérdés megoldásától, valamint a különbözı fenntartások feloldásától függıen a 36. cikk alapján létrehozott bizottság felkérést kap az alábbi mellékletre vonatkozó megállapodás megerısítésére. 5660/08 ea/zv/akn 3

4 MELLÉKLET TARTALOMJEGYZÉK 1. fejezet: DNS-adatok cseréje 1. DNS-sel kapcsolatos kriminalisztikai kérdések, egyezési szabályok és algoritmusok 1.1 A DNS-profilok jellemzıi 1.2 Egyezési szabályok 1.3 Jelentéstételi szabályok 2. Tagállami kódszámok táblázata 3. Funkcionális elemzés 3.1 A rendszer hozzáférhetısége 3.2 Második lépés 4. DNS interfészvezérlési dokumentáció 4.1 Bevezetı 4.2 Az XML struktúra meghatározása 5. Alkalmazási, biztonsági és kommunikációs architektúra 5.1 Áttekintés 5.2 Felsı szintő architektúra 5.3 Biztonsági szabványok és adatvédelem 5.4 A rejtjelezési mechanizmushoz használandó protokollok és szabványok 5.5 Alkalmazási architektúra 5.6 A rejtjelezési mechanizmushoz használandó protokollok és szabványok 5.7 Kommunikációs környezet 2. fejezet: A daktiloszkópiai adatok cseréje (interfészvezérlési dokumentáció) 1. Az állományok tartalmának áttekintése 2. Rekordformátum típusú logikai rekord: állományfejrész típusú logikai rekord: leíró szöveg típusú logikai rekord: nagy felbontású szürkeárnyalatos kép típusú logikai rekord: minuciarekord típusú változó felbontású látens kép rekord típusú változó felbontású látens kép rekord 9. Az adattovábbításonként ellenırzésre elfogadott kérelmek maximális száma 5660/08 ea/zv/akn 4

5 10. A 2. fejezet függelékei 10.1 ASCII elválasztó kódok 10.2 Az alfanumerikus ellenırzı karakter kiszámítása 10.3 Karakterkódok 10.4 Tranzakció-áttekintés típusú rekord definíciói típusú rekord definíciói 10.7 Szürkeskála tömörítési kódok 10.8 Levelezési elıírások 3. fejezet: A gépjármő-nyilvántartási adatok cseréje 1. A gépjármő-nyilvántartási adatok automatizált keresésekor használt közös adatkészlet 1.1 Fogalommeghatározások 1.2 Gépjármő/tulajdonos/üzemben tartó keresése 2. Adatbiztonság 2.1 Áttekintés 2.2 Az üzenetváltással kapcsolatos biztonsági jellemzık 2.3 Az üzenetváltáshoz nem kapcsolódó biztonsági jellemzık 2.4 Hardver biztonsági modul 3. Az adatcsere technikai feltételei 3.1 Az EUCARIS alkalmazás általános ismertetése 3.2 Funkcionális és nem funkcionális követelmények 4. fejezet: Értékelés 1. A végrehajtási javaslat 18b. cikke szerinti értékelési eljárás (a 2008/ /IB határozat 25. cikkének (2) bekezdése szerinti határozatok elıkészítése) 1.1 Eljárás 1.2 Kísérleti adatcsere 1.3 Értékelı látogatás 1.4 Jelentés a Tanács részére 2. A végrehajtási határozat 19. cikke szerinti értékelési eljárás 2.1 Statisztika és jelentés 2.2 Szakértıi értekezletek 2.3 Felülvizsgálat 2.4 Mintastatisztika 5660/08 ea/zv/akn 5

6 1. FEJEZET 1. fejezet: DNS-adatok cseréje 1. DNS-sel kapcsolatos kriminalisztikai kérdések, egyezési szabályok és algoritmusok 1.1 A DNS-profilok jellemzıi A DNS-profil 24 számpárt tartalmazhat, amelyek az Interpol DNS-eljárásaiban is használt 24 lókusz alléljait jelképezik. E lókuszok neveit az alábbi táblázat tartalmazza: VWA TH01 D21S11 FGA D8S1179 D3S1358 D18S51 Amelogenin TPOX CSF1P0 D13S317 D7S820 D5S818 D16S539 D2S1338 D19S433 Penta D Penta E FES F13A1 F13B SE33 CD4 GABA A felsı sorban szürke színnel jelzett hét lókusz alkotja jelenleg az Európai Lókuszszabványkészletet (European Standard Set of Loci, ESSOL). 1 Tartalmi szabályok: A tagállamok által keresés és összehasonlítás céljából rendelkezésre bocsátott, valamint a keresés és összehasonlítás céljából kiküldött DNS-profiloknak legalább hat lókuszt kell magukban foglalniuk, de tartalmazhatnak több lókuszt és szóközt is, amennyiben azok rendelkezésre állnak. A referencia DNS-profiloknak az európai szabvány részét képezı 7 lókusz közül legalább hatot tartalmazniuk kell. Az egyezések pontosságának javítása érdekében ajánlott, hogy valamennyi rendelkezésre álló allélt az indexelt DNS-profilok adatbázisában tárolják. 2 A vegyes profilok nem engedélyezettek, így az egyes lókuszok allélértékei kizárólag két számból fognak állni, amelyek homozigozitás esetében egy adott lókuszon meg is egyezhetnek. A helyettesítı karakterek és a mikrovariánsok az alábbi szabályok szerint kezelendık: Az amelogeninen kívül a profilban levı bármely nem numerikus értéket (pl. o, f, r, na, nr vagy un ) automatikusan helyettesítı karakterre (*) kell konvertálni az exportálás céljából, és keresést kell indítani az egész adatbázisban. A profilban található 0, 1 vagy 99 numerikus értékeket automatikusan helyettesítı karakterré (*) kell konvertálni az exportálás céljából, és keresést kell indítani az egész adatbázisban. 1 2 UK a következı mondat beillesztését javasolja: A lókuszok Interpol-szabványa (Interpol Standard Set of Loci (ISSOL)) magában foglalja az ESSOL-t és az amelogenint. UK a következı megfogalmazást javasolja: A tagállamok által keresés és összehasonlítás céljából rendelkezésre bocsátott, valamint a keresés és összehasonlítás céljából kiküldött DNS-profiloknak legalább hat teljes, kijelölt lókuszt kell magukban foglalniuk, de tartalmazhatnak további lókuszokat vagy szóközöket is, amennyiben azok rendelkezésre állnak. A referencia DNS-profiloknak az európai szabvány részét képezı 7 lókusz közül legalább hatot tartalmazniuk kell. Az egyezések pontosságának javítása érdekében valamennyi allélt tárolni kell az indexált DNS-profilok adatbázisában, és azokat keresés és összehasonlítás céljából használni kell. Valamennyi tagállamnak a lehetı leghamarabb végre kell hajtani minden elfogadott új Európai lókusz-szabványkészletet. 5660/08 ea/zv/akn 6

7 1. FEJEZET Amennyiben egy lókuszhoz három allél van megadva, az elsı allélt el kell fogadni, a másik kettıt azonban automatikusan helyettesítı karakterré (*) kell konvertálni az exportálás céljából, és keresést kell indítani az egész adatbázisban. Amennyiben az elsı vagy a második allélra helyettesítı karaktert adnak meg, a numerikus értéknek a lókuszra vonatkozó mindkét permutációja tekintetében keresést kell indítani (pl.: 12, *, ami egyezhet 12,14-el vagy 9,12-vel is). A pentanukleotid (Penta D, Penta E és CD4) mikrovariánsok az alábbiak szerint egyeznek: x.1 = x, x.1, x.2 x.2 = x.1, x.2, x.3 x.3 = x.2, x.3, x.4 x.4 = x.3, x.4, x+1 A tetranukleotid (az Interpol adatbázisában található többi lókusz tetranukleotid) mikrovariánsok az alábbiak szerint egyeznek: x.1 = x, x.1, x.2 x.2 = x.1, x.2, x.3 x.3 = x.2, x.3, x Egyezési szabályok Két DNS-profil összehasonlítása azon lókuszok alapján történik, amelyekhez mindkét DNSprofilban rendelkezésre áll egy allélpár. Legalább hat lókusznak (az amelogenin kivételével) egyeznie kell mindkét DNS-profilban. 3 A teljes egyezés (1. minıség) egyezésnek minısül, amennyiben az összehasonlított lókuszoknak a keresı és a lekért DNS-profilban egyaránt megtalálható valamennyi allélértéke megegyezik. A közeli egyezés egyezésnek minısül, amennyiben az összehasonlított allélok közül csupán egynek az értéke tér el a két DNS-profilban (2., 3. és 4. minıség). A közeli egyezés csak akkor fogadható el, ha a két összehasonlított DNS-profil legalább hat teljesen egyezı lókuszt tartalmaz UK a következı megfogalmazást javasolja: Két DNS-profil összehasonlítása azon lókuszok alapján történik, amelyekhez mindkét DNS-profilban rendelkezésre áll egy allélpár. Legalább hat teljes kijelölt lókusznak (az amelogeninen kívül) egyeznie kell mindkét DNS-profilban, mielıtt találati válasz érkezik. UK a következı megfogalmazást javasolja: A közeli egyezés csak akkor fogadható el, ha a két összehasonlított DNS-profil legalább hat teljesen egyezı kijelölt lókuszt tartalmaz. Az ENFSI vagy az EU által elfogadott bármely új egyezési szabályt a tagállamoknak összehangolt módon végre kell hajtaniuk. 5660/08 ea/zv/akn 7

8 1. FEJEZET A közeli egyezés okai az alábbiak lehetnek: Emberi tévesztés (gépelési hiba) az egyik DNS-profil bevitelénél a keresési kérelemben vagy a DNS-adatbázisban, a DNS-profil generálási eljárása során allél-meghatározási vagy allél-lehívási hiba. 1.3 Jelentéstételi szabályok A teljes és a közeli egyezésekrıl egyaránt jelentést kell tenni. Az egyezésrıl szóló jelentést a kérelmezı nemzeti kapcsolattartónak küldik meg, valamint hozzáférhetıvé teszik a megkeresett nemzeti kapcsolattartó számára is (annak érdekében, hogy megbecsülhesse a rendelkezésre álló további személyes adatok, valamint a találatnak megfelelı DNS-profillal kapcsolatos egyéb információk iránti, az egyezést követı lehetséges további kérelmek természetét és számát, a 2008/ /IB tanácsi határozat 5. és 10. cikkével összhangban). 2. Tagállami kódszámok táblázata A 2008/ /IB határozattal összhangban a doménnevek és a zárt hálózatban történı prümi DNSadatcsere alkalmazásokhoz szükséges egyéb konfigurációs paraméterek meghatározásához az ISO alpha-2 kódot használják. Az ISO alpha-2 kódok az alábbi, két betőbıl álló tagállami kódok. Tagállam Kód Tagállam Kód Belgium BE Luxemburg LU Bulgária BG Magyarország Cseh Köztársaság CZ Málta MT Dánia DK Hollandia NL Németország DE Ausztria AT Észtország EE Lengyelország PL Görögország EL Portugália PT Spanyolország ES Románia RO Franciaország FR Szlovákia SK Írország IE Szlovénia SI Olaszország IT Finnország FI Ciprus CY Svédország SE Lettország LV Egyesült Királyság UK Litvánia LT 5660/08 ea/zv/akn 8

9 1. FEJEZET 3. Funkcionális elemzés 3.1 A rendszer hozzáférhetısége A 2008/ /IB határozat 3. cikke szerinti kérelmeknek az érkezés kronológiai sorrendjében kell a céladatbázisba eljutniuk, míg a válaszoknak a kérelem megérkezését követı tizenöt percben kell a kérelmezı tagállamhoz eljutniuk Második lépés Amikor egy tagállam egyezésrıl szóló jelentést kap, nemzeti kapcsolattartójának feladata a kérdésként benyújtott profilban található értékeknek a válaszként kapott profilban/profilokban található értékekkel való összehasonlítása, valamint a profil bizonyító erejének hitelesítése és ellenırzése. Hitelesítési célokból a nemzeti kapcsolattartók közvetlenül is felvehetik egymással a kapcsolatot. A jogi segítségnyújtási eljárások a két profil közötti egyezés hitelesítését követıen kezdıdnek meg, az automatizált konzultációs szakasz során elért teljes vagy közeli egyezés alapján. 4. DNS interfészvezérlési dokumentáció 4.1 Bevezetı Célkitőzések Ez a fejezet a DNS-profilokban található információknak a tagállamok DNS-adatbázisrendszerei közötti cseréjéhez szükséges elıírásokat határozza meg. A fejrészmezıket kifejezetten a prümi DNS-adatcserére határozzák meg, az adatrész a DNS-csere Interpol-átjárójára meghatározott XMLsémában a DNS-profil adatrészére alapul. Az adatok cseréjére az SMTP-protokoll (egyszerő levéltovábbítási protokoll) és a legkorszerőbb egyéb technológiák felhasználásával kerül sor, a hálózatszolgáltató által biztosított központi levéltovábbító szerveren keresztül. Az XML-fájlt levéltörzsként továbbítják Alkalmazási kör Az ICD kizárólag az üzenet (levél) tartalmát határozza meg. Minden hálózatspecifikus és levélspecifikus témát egységesen határoznak meg, a DNS-adatcsere közös technikai alapja érdekében. 5 UK a következı megfogalmazást javasolja: A 2008/ /IB határozat 3. cikke szerinti kérelmeknek az egyes kérelmek elküldésének kronológiai sorrendjében kell a céladatbázisba eljutniuk, míg a válaszokat a kérelem kézhezvételét követı tizenöt percben kell a kérelmezı tagállam számára elküldeni, a hálózati teljesítményre is figyelemmel. SE támogatja a javaslatot. 5660/08 ea/zv/akn 9

10 1. FEJEZET Ez magában foglalja az alábbiakat: az üzenet tárgymezıjének formátuma, az üzenet automatizált feldolgozásának lehetıvé tétele/engedélyezése érdekében, szükséges-e tartalom rejtjelezése, és amennyiben igen, milyen módszerekkel, az üzenetek maximális hossza XML szerkezet és elvek Az XML üzenet a következı részekbıl áll: a továbbításra vonatkozó információt tartalmazó fejrész és a profilspecifikus információt, valamint magát a profilt tartalmazó adatrész. A kérelemre és a válaszra egyaránt ugyanazt az XML-sémát kell használni. A nem azonosított DNS-profilok teljes körő ellenırzése (a 2008/ /IB határozat 4. cikke) érdekében lehetıség lesz több profil egyetlen üzenetben való elküldésére is. Meg kell határozni az egy üzenetben küldhetı profilok maximális számát. A szám a legnagyobb engedélyezett levélmérettıl függ, meghatározására a levélkiszolgáló kiválasztását követıen kerül sor. XML példa: <?version="1.0" standalone="yes"?> <PRUEMDNAx xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:xsi=" <header> ( ) </header> <datas> ( ) </datas> [<datas> az adatszerkezetet meg kell ismételni, amennyiben több profilt küldenek (.) egyetlen SMTP-üzenetben, ami csak a 4. cikkben foglalt esetekben engedélyezett </datas> ] </PRUEMDNAx 4.2 Az XML szerkezet meghatározása Az alábbi meghatározások dokumentálási célokat és a jobb olvashatóságot szolgálják, a ténylegesen kötelezı információt egy XML-sémafájl tartalmazza (PRUEM DNA.xsd). 5660/08 ea/zv/akn 10

11 1. FEJEZET PRUEMDNAx séma A séma az alábbi mezıket tartalmazza: Fields Type Description header PRUEM_header Occurs: 1 datas PRUEM_datas Occurs: Fejrészstruktúra tartalma PRUEM fejrész Ez a struktúra az XML-fájl fejrészét írja le. Az alábbi mezıket tartalmazza: Fields Type Description direction PRUEM_header_dir Direction of message flow ref String Reference of the XML file generator String Generator of XML file schema_version String Version number of schema to use requesting PRUEM_header_info Requesting Member State info requested PRUEM_header_info Requested Member State info PRUEM_header dir Az üzenetben foglalt adatok típusa, értéke a következı lehet: Value Description R Request A Answer PRUEM fejrészre vonatkozó információk A tagállamot, valamint az üzenet idıpontját/idejét leíró struktúra. Az alábbi mezıket tartalmazza: Fields Type Description source_isocode String ISO code of the requesting Member State destination_isocode String ISO code of the requested Member State request_id String unique Identifier for a request date Date Date of creation of message time Time Time of creation of message 5660/08 ea/zv/akn 11

12 1. FEJEZET PRUEM profil adatainak tartalma PRUEM_datas Ez a struktúra az XML profil adatrészét írja le. Az alábbi mezıket tartalmazza: Fields Type Description reqtype PRUEM request type Type of request (Article 3 or 4) date Date Date profile stored type PRUEM_datas_type Type of profile result PRUEM_datas_result Result of request agency String Name of corresponding unit responsible for the profile profile_ident String Unique Member State profile ID message String Error Message, if result = E profile IPSG_DNA_profile If direction = A (Answer) AND result H (Hit) empty match_id String In case of a HIT PROFILE_ID of the requesting profile quality PRUEM_hitquality_type Quality of Hit hitcount Integer Count of matched Alleles rescount Integer Count of matched profiles. If direction = R (Request), then empty. If quality!=0 (the original requested profile), then empty PRUEM_request_type Az üzenetben foglalt adatok típusa, értéke a következı lehet: Value Description 3 Requests pursuant to Article 3 of Decision 2008/.../JHA 4 Requests pursuant to Article 4 of Decision 2008/.../JHA 5660/08 ea/zv/akn 12

13 1. FEJEZET PRUEM_hitquality_type Value Description 0 Referring original requesting profile: Case No Hit : original requesting profile sent back only; Case Hit : original requesting profile and matched profiles sent back. 1 Equal in all available alleles without wildcards 2 Equal in all available alleles with wildcards 3 Hit with Deviation (Microvariant) 4 Hit with mismatch PRUEM_data_type Az üzenetben foglalt adatok típusa, értéke a következı lehet: Value Description P Person profile S Stain PRUEM_data_result Az üzenetben foglalt adatok típusa, értéke a következı lehet: Value Description U Undefined, If direction = R (request) H Hit N No Hit E Error 5660/08 ea/zv/akn 13

14 1. FEJEZET IPSG_DNA_profile DNS-profilt leíró struktúra. Az alábbi mezıket tartalmazza: Fields Type Description IPSG_DNA_ISSOL Group of loci corresponding to the ISSOL ess_issol (standard group of Loci of Interpol) additional_loci IPSG_DNA_additional_loci Other loci marker String Method used to generate of DNA profile_id String Unique identifier for DNA profile IPSG_DNA_ISSOL Az ISSOL lókuszokat (lókuszok Interpol-szabványkészlete) tartalmazó struktúra. Az alábbi mezıket tartalmazza: Fields Type Description vwa IPSG_DNA_locus Locus vwa th01 IPSG_DNA_locus Locus th01 d21s11 IPSG_DNA_locus Locus d21s11 fga IPSG_DNA_locus Locus fga d8s1179 IPSG_DNA_locus Locus d8s1179 d3s1358 IPSG_DNA_locus Locus d3s1358 d18s51 IPSG_DNA_locus Locus d18s51 amelogenin IPSG_DNA_locus Locus amelogin 5660/08 ea/zv/akn 14

15 1. FEJEZET IPSG_DNA_additional_loci A többi lókuszt tartalmazó struktúra. Az alábbi mezıket tartalmazza: Fields Type Description tpox IPSG_DNA_locus Locus tpox csf1po IPSG_DNA_locus Locus csf1po d13s317 IPSG_DNA_locus Locus d13s317 d7s820 IPSG_DNA_locus Locus d7s820 d5s818 IPSG_DNA_locus Locus d5s818 d16s539 IPSG_DNA_locus Locus d16s539 d2s1338 IPSG_DNA_locus Locus d2s1338 d19s433 IPSG_DNA_locus Locus d19s433 penta_d IPSG_DNA_locus Locus penta_d penta_e IPSG_DNA_locus Locus penta_e fes IPSG_DNA_locus Locus fes f13a1 IPSG_DNA_locus Locus f13a1 f13b IPSG_DNA_locus Locus f13b se33 IPSG_DNA_locus Locus se33 cd4 IPSG_DNA_locus Locus cd4 gaba IPSG_DNA_locus Locus gaba IPSG_DNA_locus Lókuszt leíró struktúra. Az alábbi mezıket tartalmazza: Fields Type Description low_allele String Lowest value of an allele high_allele String Highest value of an allele 5660/08 ea/zv/akn 15

16 1. FEJEZET 5. Alkalmazási, biztonsági és kommunikációs architektúra 5.1 Áttekintés A 2008/ /IB határozat keretében folytatott DNS-adatcsere alkalmazásainak implementációja során közös kommunikációs hálózatot kell használni, amely logikusan zárt lesz a tagállamok között. E közös, a hatékonyabb kérelemküldésre és válaszfogadásra szolgáló kommunikációs infrastruktúra lehetıségeinek a kihasználása érdekében aszinkron mechanizmust fogadnak el a DNS- és daktiloszkópiai adatokra irányuló kérelmek becsomagolt SMTP üzenetben való továbbítása érdekében. Biztonsági megfontolásból a smime (biztonságos többcélú internet-levelezés bıvítmény) mechanizmusát mint az SMTP funkció kiterjesztését fogják felhasználni arra, hogy a hálózaton belül egy végpontok közötti biztonságos átjárót építsenek ki. A tagállamok közötti adatcserét szolgáló kommunikációs hálózat funkcióját az operatív TESTA (a közigazgatási rendszerek közötti transzeurópai telematikai szolgáltatás) tölti be. A TESTA az Európai Bizottság felelısségi körébe tartozik. Figyelembe véve, hogy a nemzeti DNS-adatbázisok és a TESTA jelenlegi nemzeti hozzáférési pontjai esetlegesen a tagállamok különbözı oldalain találhatók, a TESTA-hoz való hozzáférés kialakítható: 1) a meglevı nemzeti hozzáférési pont felhasználásával vagy új nemzeti TESTA hozzáférési pont létrehozásával vagy 2) biztonságos, az illetékes nemzeti ügynökség által irányított helyi kapcsolat kialakításával a DNS-adatbázisnak helyet adó oldal és a meglevı nemzeti TESTA hozzáférési pont között. A 2008/ /IB határozat szerinti alkalmazások végrehajtása során alkalmazott protokollok és szabványok megfelelnek a nyílt szabványoknak és teljesítik a tagállamok nemzeti biztonságpolitikai döntéshozói által elıírtakat. 5.2 Felsı szintő architektúra A 2008/ /IB határozat alkalmazási körében valamennyi tagállam hozzáférhetıvé teszi DNSadatait a más tagállamokkal való csere és/vagy a más tagállamok általi keresés céljából, az egységesített közös adatformátumnak megfelelıen. Az architektúra a bárkitıl bárkinek rendszer kommunikációs modelljére alapul. Nincs sem központi számítógépes szerver, sem pedig központosított adatbázis a DNS-profilok tárolására. 5660/08 ea/zv/akn 16

17 1. FEJEZET 1. ábra: A DNS-adatok cseréjének topológiája Indexed DNA DB Indexed DNA DB Indexed DNA DB Closed Network (VPN upon Open Standards) Indexed DNA DB Indexed DNA DB Indexed DNA DB Indexed DNA DB A tagállamok oldalaira vonatkozó nemzeti jogi korlátozások tiszteletben tartásán kívül minden tagállam maga dönthet arról, hogy milyen típusú hardvert és szoftvert alkalmaz a 2008/ /IB határozatban foglalt követelményeknek való megfeleléshez elvégzendı konfigurációhoz. 5.3 Biztonsági elıírások és adatvédelem A biztonsági vonatkozásoknak három szintjét vizsgálták meg és hajtották végre Adatszint Az egyes tagállamok által rendelkezésre bocsátott DNS-profilokat a közös adatvédelmi szabványoknak megfelelıen kell elkészíteni, úgy, hogy a kérelmezı tagállam által kézhez kapott válasz elsısorban a találatot (HIT), illetve a találat hiányát (NO HIT) jelezze, találat esetén az azonosítószámot is feltüntetve, és ne tartalmazzon semmilyen személyes információt. A találatról szóló értesítést követıen további vizsgálatokat folytatnak kétoldalú szinten, az érintett tagállami oldalakra vonatkozó meglevı nemzeti jogi és szervezeti szabályoknak megfelelıen Kommunikációs szint A DNS-profilokra vonatkozó információt tartalmazó üzeneteket (kérelmeket és válaszokat), mielıtt azokat más tagállamok oldalaira továbbítanák, a nyílt szabványoknak megfelelıen a legkorszerőbb módszerekkel, mint például a smime-el rejtjelezik. 5660/08 ea/zv/akn 17

18 1. FEJEZET Továbbítási szint A DNS-profilra vonatkozó információt tartalmazó összes rejtjelezett üzenetet nemzetközi szinten egy megbízható hálózati szolgáltató által igazgatott virtuális magán-átjárórendszeren keresztül, valamint az ezen átjáró-rendszerhez kapcsolódó, nemzeti felelısség alá tartozó biztonságos kapcsolatokon keresztül továbbítják a többi tagállam oldalaira. A virtuális magánátjárórendszernek nincs kapcsolódási pontja a nyilvános Internethez A titkosítási mechanizmusokhoz használandó protokollok és szabványok: smime és kapcsolódó csomagok A DNS-profilra vonatkozó információt tartalmazó üzenetek rejtjelezésére a smime nyílt szabványt mint az SMTP de facto szabvány kiterjesztését fogják alkalmazni. A smime protokoll (V3) lehetıvé teszi a levelek aláírását, a biztonsági címkézést és a biztonságos levelezılistákat; a protokoll a kriptográfiailag védett üzenetekre vonatkozó IETF-szabványra, a kriptográfiai üzenetszintaxisra (Cryptographic Message Syntax, CMS) épül. A digitális adatok bármely formájának digitális aláírására, kivonatolására, hitelesítésére és rejtjelezésére szolgál. A smime mechanizmus által használt tanúsítványnak meg kell felelnie az X.509 szabványnak. Az egyéb prümi alkalmazásokkal közös szabvány- és eljáráshasználat biztosítása érdekében a smime rejtjelezési mőveletekre vonatkozó, illetve a különbözı, kereskedelmi forgalomban kapható termékek (COTS) esetében alkalmazandó eljárási szabályok a következık: A mővelet sorrendje: elıször a rejtjelezés, majd az aláírás. A szimmetrikus rejtjelezéshez a 256 bites kulcsmérető AES (Advanced Encryption Standard), az asszimetrikus rejtjelezéshez pedig az 1024 bites kulcsmérető RSA rejtjelezı algoritmust kell alkalmazni. Az SHA-1 hash algoritmust kell alkalmazni. Az s/mime funkció a modern szoftvercsomagok közül a legtöbbe, így például az Outlook, a Mozilla Mail, valamint a Netscape Communicator 4.x szoftverbe már be van építve, és a legfıbb szoftvercsomagokkal kompatibilis. 5660/08 ea/zv/akn 18

19 1. FEJEZET Mivel a smime könnyen integrálható a nemzeti IT infrastruktúrákba valamennyi tagállam oldalán, a kommunikációs biztonsági szint implementációjára alkalmas mechanizmusnak bizonyul. A Proof of Concept céljának hatékonyabb módon történı elérése, valamint a költségek csökkentése érdekében a DNS-adatok cseréjének prototipizálására a JavaMail API nyílt szabványt választják. A JavaMail API a s/mime és/vagy az OpenPGP felhasználásával egyszerő rejtjelezést és visszafejtést biztosít. A cél egységes, egyszerően használható alkalmazásprogramozási interfész (API) biztosítása azon kliensek számára, akik a két legelterjedtebb -rejtjelezési formátum felhasználásával kívánnak t küdeni vagy kapni. Ezért a JavaMail API bármely korszerő implementációja megfelel a 2008/ /IB határozat követelményeinek, mint például a Bouncy Castle JCE terméke (Java Cryptographic Extension), amelyet a smime implementációjára fognak használni a DNS-adatok tagállamok közötti cseréjére vonatkozó prototípuskészítés érdekében. 5.5 Alkalmazási architektúra Minden tagállam egy az interfészvezérlési dokumentációval összhangban levı szabványosított DNS-profil adatcsomagot bocsát a többi tagállam rendelkezésére. Ez lehetséges az egyes nemzeti adatbázisok logikai nézetének biztosítása vagy fizikai exportált adatbázis létrehozása által. A négy fı komponens: kiszolgáló/smime, alkalmazáskiszolgáló, az adatlekérdezésre és - bevitelre, valamint a bejövı és kimenı üzenetek nyilvántartására szolgáló adatszerkezet, továbbá a teljes alkalmazási logika termékfüggetlen módon való implementációját szolgáló összehasonlító motor. Annak biztosítása érdekében, hogy a tagállamok könnyen integrálhassák a komponenseket saját nemzeti oldalaikra, a meghatározott közös funkciót a tagállamok által nemzeti IT politikájuktól és szabályaiktól függıen választható nyílt forráskódú komponensek útján implementálták. A 2008/ /IB határozat hatálya alá tartozó DNS-profilokat tartalmazó indexelt adatbázisokhoz való hozzáférés érdekében implementálandó független jellemzık miatt minden tagállam szabadon választhatja meg hardver- és szoftverplatformját, beleértve az adatbázis- és operációs rendszereket is. A meglevı közös hálózatban kifejlesztették és sikeresen tesztelték a DNS adatok cseréjének prototípusát. Az 1.0 verzió produktív környezetben való alkalmazása megkezdıdött, és azt a napi mőveletekben használják. A tagállamok használhatják a közösen kifejlesztett terméket, de kifejleszthetik saját termékeiket is. A közös termékkomponenseket az IT, valamint a kriminalisztikai és/vagy funkcionális rendırségi követelmények változásának megfelelıen fogják karbantartani, testre szabni és továbbfejleszteni. 5660/08 ea/zv/akn 19

20 1. FEJEZET 2. ábra: Alkalmazás-topológiai áttekintés Case 1 a logical view National Env. National Env. Case 2 a physical DB Index Profile Index DBMS Server/ smime Application Server Data Structure (protocol) Match Engine TESTA II 5.6. Az alkalmazási architektúrához használandó protokollok és szabványok XML A DNS-adatok cseréje teljes mértékben az XML-sémát mint az SMTP üzenetek csatolmányát aknázza ki. A Kiterjeszthetı Leíró Nyelv (XML) a W3C által ajánlott általános célú leíró nyelv, amely speciális célú leíró nyelvek létrehozására szolgál, és amely számos különbözı adattípus leírására képes. A DNS-profil valamennyi állam közötti cseréjére alkalmas leírása XML és XML-séma alkalmazásával történt az interfészvezérlési dokumentumban ODBC A nyílt adatbázis-kapcsolat (ODBC) szabványos szoftveres API metódust kínál az adatbázis-kezelı rendszerekhez való hozzáféréshez, és függetlenséget biztosít a programozási nyelvektıl, valamint az adatbázis- és operatív rendszerektıl. Az ODBC-nek ugyanakkor vannak hátrányai is. A nagy számú ügyfélgép kezelése különbözı eszközmeghajtókat és dinamikusan kapcsolódó könyvtárakat (DLL) jelenthet. Ez az összetettség rendszer-felügyeleti többletmunkát eredményezhet. 5660/08 ea/zv/akn 20