You are on page 1of 43

PROJEKT 21 kwietnia 2011 r. ROZPORZDZENIE RADY MINISTRW z dnia .. 2010 r.

w sprawie wymaga technicznych i eksploatacyjnych dla interfejsw umoliwiajcych wykonywanie zada i obowizkw na rzecz obronnoci, bezpieczestwa pastwa oraz bezpieczestwa i porzdku publicznego Na podstawie art. 182 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800 z pn. zm.1)) zarzdza si, co nastpuje: 1. 1. Rozporzdzenie okrela wymagania techniczne i eksploatacyjne dla interfejsw, o ktrych mowa w art. 179 ust. 4a ust. 1 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne, umoliwiajcych wykonywanie zada i obowizkw na rzecz obronnoci, bezpieczestwa pastwa oraz bezpieczestwa i porzdku publicznego, o ktrych mowa w art. 179 ust. 3 i w art. 180d ust. 1 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne. 2. Wymagania, o ktrych mowa w ust. 1, okrelaj zaczniki do rozporzdzenia. 2. Rozporzdzenie wchodzi w ycie po upywie 6 miesicy od dnia ogoszenia.

Zmiany wymienionej ustawy zostay ogoszone w Dz. U. z 2004 r. Nr 273, poz. 2703, z 2005 r. Nr 163, poz. 1362 i Nr 267, poz. 2258, z 2006 r. Nr 12, poz. 66, Nr 104, poz. 708 i 711, Nr 170, poz. 1217, Nr 220, poz. 1600, Nr 235, poz. 1700 i Nr 249, poz. 1834, z 2007 r. Nr 23, poz. 137, Nr 50, poz. 331 i Nr 82 poz. 556, z 2008 r. Nr 17, poz. 101 i Nr 227, poz. 1505 oraz z 2009 r. Nr 11, poz. 59, Nr 18, poz. 97 i Nr 85, poz. 716.
1

1)

UZASADNIENIE Projekt rozporzdzenia jest wykonaniem upowanienia zawartego w art. 182 ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne (Dz. U. Nr 171, poz. 1800, z pn. zm.), zwanej dalej ustaw. Powysza delegacja ustawowa uprawnia Rad Ministrw do okrelenia wymaga technicznych i eksploatacyjnych dla interfejsw, o ktrych mowa w art. 179 ust. 4a ustawy, umoliwiajcych wykonywanie zada i obowizkw na rzecz obronnoci, bezpieczestwa pastwa oraz bezpieczestwa i porzdku publicznego, o ktrych mowa w art. 179 ust. 3 i w art. 180d ustawy. Zagadnienia objte zakresem regulacji projektowanego rozporzdzenia maj zosta unormowane z zastosowaniem zasady minimalizacji nakadw przedsibiorcy telekomunikacyjnego i podmiotw uprawnionych. Zgodnie z art. 179 ust. 4a ustawy zastosowanie rozwizania technicznego opartego o interfejs, jest tylko jedn z moliwoci wykonywania przez przedsibiorcw telekomunikacyjnych zada i obowizkw na rzecz obronnoci i bezpieczestwa pastwa oraz bezpieczestwa, porzdku publicznego. Nie jest natomiast obligatoryjnym wymogiem ustawodawcy. Zastosowanie interfejsu powinno wynika z zasady minimalizacji nakadw przedsibiorcy telekomunikacyjnego, podmiotw uprawnionych i mie miejsce tylko w tym przypadku, kiedy przyniesie to obu zainteresowanym stronom wymierne korzyci. Ewentualny wybr przez przedsibiorc telekomunikacyjnego tej metody realizacji jego ustawowych obowizkw jest wic uzaleniony nie tylko od jego chci, ale take od wyraenia zgody przez uprawnione podmioty. W chwili obecnej nie ma adnego aktu prawnego regulujcego standardy dla realizacji interfejsw. Unormowanie prawne przedmiotowej kwestii jest konieczne dla zapewnienia odpowiednim subom, waciwych warunkw dla realizacji ich zada zwizanych z prac operacyjn. Stosowane aktualnie rozwizania opieraj si na metodach przyjtych w sieciach operatorw GSM (Polkomtel, PTC, PTK Centertel), okrelonych w dokumencie pt: Specyfikacja Interfejsu LI HI na styku midzy systemem operatora telefonii ruchomej umoliwiajcym realizacj dostpu do wybranych treci przekazw telekomunikacyjnych (ADMF/DF), a systemem uprawnionego podmiotu umoliwiajcym dostp do wybranych treci przekazw telekomunikacyjnych (LEMF). Rozwizania interfejsw LI HI s stosowane tylko u operatorw telefonii mobilnej. Nie s obecnie uywane w sieci adnego z innych operatorw (telefonia stacjonarna, dostp do internetu). Interfejs dla retencji HI A-B rwnie nie jest stosowany w sieci adnego z krajowych operatorw. Zastosowanie interfejsw zmierza do stopniowego wprowadzenia elektronicznego dostpu do danych telekomunikacyjnych bdcych w posiadaniu przedsibiorcy telekomunikacyjnego. Z uwagi na fakt, e dane te bd niejednokrotnie obejmowa tysice pojedynczych rekordw, konieczne jest aby dane te przekazywane byy w postaci elektronicznej. Posta elektroniczna przekazywanych danych niesie ze sob wiele korzyci. S to miedzy innymi, atwo archiwizacji danych, atwe przeszukiwanie i analiza danych (z wykorzystaniem systemw informatycznych), atwo przesyania danych. Dlatego istnieje konieczno wskazania jednolitego dla wszystkich przedsibiorcw telekomunikacyjnych formatu danych, ktry mgby by wykorzystywany do tego celu. Dodatkowo powinny istnie oglnodostpne narzdzia umoliwiajce konwersje przesyanych przez operatora danych do wymaganego formatu oraz pozwalajce na tworzenie podmiotom uprawnionym aplikacji analizujcych dane otrzymane w tym formacie. Formatem speniajcym powysze wymagania jest ASN 1. Jest on wspierany przez wiele systemw baz danych oraz istnieje wiele komercyjnych i darmowych narzdzi do jego generowania, weryfikowania i analizy. Dokumenty ASN 1 pozwalaj takie na szybkie zweryfikowanie ich poprawnoci. Rozwizanie to wymusza na
2

przedsibiorcach telekomunikacyjnych digitalizacj wszystkich posiadanych danych (w tym danych, o ktrych mowa w art. 161 ustawy), co jednake biorc pod uwag charakter wykonywanej dziaalnoci nie powinno za sob nie nadmiernych kosztw ani powodowa trudnoci technicznych. Przy konstruowaniu projektu rozporzdzenia przyjto generaln zasad odwoa do istniejcych midzynarodowych zalece oraz dokumentw normalizacyjnych, gwnie Europejskiego Instytutu Norm Telekomunikacyjnych ETSI. Uwzgldniono rwnie - celem minimalizacji kosztw - uwarunkowania istniejce w Polsce, w tym cechy charakterystyczne krajowych rozwiza interfejsw. W przypadku gdy rozwizania krajowe wymagaj specyficznego podejcia, dokonano szczegowego wskazania wymaga technicznych. W sytuacji gdy normy midzynarodowe nie odnosz si do konkretnego rozwizania oraz w Polsce jeszcze go nie wykorzystywano (np. w przypadku przechwytywania strumieni wideo), zaproponowano stosowne zapisy. Wymagania techniczne i eksploatacyjne dla interfejsw, o ktrych mowa w art. 179 ust. 4a ustawy zostay okrelone w zacznikach do projektowanego rozporzdzenia. Proponowane rozwizania maj na celu umoliwienie podmiotom uprawnionym, ktrymi s: Policja, Stra Graniczna, Agencja Bezpieczestwa Wewntrznego, Suba Kontrwywiadu Wojskowego, andarmeria Wojskowa, Centralne Biuro Antykorupcyjne i wywiad skarbowy, dostpu do: przekazw telekomunikacyjnych, nadawanych lub odbieranych przez uytkownika kocowego lub telekomunikacyjne urzdzenie kocowe oraz posiadanych przez przedsibiorc danych zwizanych z przekazami telekomunikacyjnymi oraz dostpu do zatrzymywanych danych, ktre s generowane lub przetwarzane w sieci telekomunikacyjnej. Szczeglnego wyjanienia wymaga odwoanie si w definicji obiektu monitorowanego do zarzdze organw uprawnionego podmiotu wydanych na podstawie odrbnych przepisw. Tymi przepisami s ustawy kompetencyjne poszczeglnych uprawnionych podmiotw: ustawa o Policji, ustawa o Stray Granicznej, ustawa o kontroli skarbowej, ustawa o andarmerii Wojskowej i wojskowych organach porzdkowych, ustawa o Agencji Bezpieczestwa Wewntrznego oraz Agencji Wywiadu, ustawa o Centralnym Biurze Antykorupcyjnym, ustawa o Subie Kontrwywiadu Wojskowego oraz Subie Wywiadu Wojskowego.

W powyszych ustawach zawarty zosta przepis, ktry mwi, e w przypadkach niecierpicych zwoki, jeeli mogoby to spowodowa utrat informacji lub zatarcie albo zniszczenie dowodw przestpstwa, organ uprawnionego podmiotu moe zarzdzi, po uzyskaniu pisemnej zgody prokuratora, kontrol operacyjn, zwracajc si jednoczenie do waciwego sdu, z wnioskiem o wydanie postanowienia w tej sprawie. Projekt rozporzdzenia przewiduje okres 6 miesicy na wejcie w ycie proponowanych rozwiza, co ma na celu umoliwienie podmiotom objtym zakresem regulacji dostosowanie si do przyjtych wymaga. Przedmiotowy projekt nie podlega notyfikacji zgodnie z trybem przewidzianym w przepisach dotyczcych sposobu funkcjonowania krajowego systemu notyfikacji norm i aktw prawnych.

Projekt zosta opublikowany na stronach Biuletynu Informacji Publicznej Ministerstwa Infrastruktury zgodnie z przepisami ustawy z dnia 7 lipca 2005 r. o dziaalnoci lobbingowej w procesie tworzenia prawa (Dz. U. Nr 169, poz. 1414). Przedmiot projektowanego aktu prawnego nie jest objty prawem Unii Europejskiej.

OCENA SKUTKW REGULACJI I. Podmioty, na ktre oddziauje rozporzdzenie. Do podmiotw, na ktre oddziauje projektowane rozporzdzenie nale:
1) 2)

przedsibiorcy telekomunikacyjni wpisani do rejestru prowadzonego przez Urzd Komunikacji Elektronicznej, organy administracji rzdowej oraz podmioty uprawnione w rozumieniu ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne: Policja, Stra Graniczna, Agencja Bezpieczestwa Wewntrznego, Agencja Wywiadu, Centralne Biuro Antykorupcyjne, Suba Kontrwywiadu Wojskowego, Suba Wywiadu Wojskowego, andarmeria Wojskowa, organy kontroli skarbowej.

II. Konsultacje spoeczne. W ramach konsultacji spoecznych projekt zosta przedstawiony do zaopiniowania branowym izbom zrzeszajcym przedsibiorcw telekomunikacyjnych. III. Wpyw na sektor finansw publicznych, w tym na budet pastwa i budet jednostek samorzdu terytorialnego oraz przychody i wydatki przedsibiorcw. Wpyw na sektor finansw publicznych, w tym na budet pastwa Zastosowanie interfejsw dla prowadzenia kontroli operacyjnej przez uprawnione podmioty wie si z koniecznoci ponoszenia przez podmioty uprawnione, kosztw budowy i eksploatacji czci systemu uprawnionego monitoringu, znajdujcego si po ich strome i spowoduje dodatkowe skutki finansowe dla budetu pastwa. Koszty te mona podzieli na dwie zasadnicze grupy: I. Koszty budowy i instalacji systemw, w skad ktrych wchodz:
1)

koszt zakupu i instalacji samego systemu monitoringu, tj. urzdze sucych do rejestracji i przechowywania uzyskanych z systemu przedsibiorcy telekomunikacyjnego treci przekazw telekomunikacyjnych i powizanych z nimi danych telekomunikacyjnych, koszt zakupu i instalacji urzdze sucych do ochrony przekazywanych za pomoc sieci telekomunikacyjnych uzyskanych z systemu przedsibiorcy i telekomunikacyjnego treci przekazw telekomunikacyjnych i powizanych z nimi danych telekomunikacyjnych na trasie przedsibiorca telekomunikacyjny uprawniony podmiot oraz pomidzy rozproszonymi elementami systemu uprawnionego podmiotu (szyfratory), koszt budowy lub dzierawy sieci telekomunikacyjnych sucych do transmisji uzyskanych z systemu przedsibiorcy telekomunikacyjnego treci przekazw telekomunikacyjnych i powizanych z nimi danych i telekomunikacyjnych na trasie przedsibiorca telekomunikacyjny uprawniony podmiot oraz pomidzy rozproszonymi elementami systemu uprawnionego podmiotu, koszty budowy lub modernizacji infrastruktury budowlanej niezbdnej dla zapewnienia waciwych warunkw eksploatacji systemu.

2)

3)

II. Koszty eksploatacji i modernizacji poszczeglnych elementw interfejsu:


1)

koszty serwisu firmy - producenta systemu. Jest to koszt stay stanowicy okrelony procent kosztu zakupu systemu ponoszony corocznie (okoo 10% sumy kontraktu). Na wysoko tej opaty wpywa wymg natychmiastowej reakcji serwisu na wszelkie objawy nieprawidowego dziaania systemu (wymagana jest caodobowa gotowo serwisu do podjcia dziaa) oraz wynikajce z ustawy o ochronie informacji niejawnych wymagania w stosunku do producenta systemu i personelu serwisujcego. Obejmuj one koszty likwidacji ewentualnych awarii i usterek systemu oraz aktualizacj zastosowanego oprogramowania, koszty modernizacji systemu - ze wzgldu na szybki postp technologiczny w dziedzinie telekomunikacji, pojawianie si wci nowych publicznie dostpnych usug telekomunikacyjnych, systemy uprawnionego monitoringu (zarwno po stronie przedsibiorcy telekomunikacyjnego, jak i uprawnionego podmiotu) wymagaj staej rozbudowy i modernizacji. Zgodnie z art. 179 ust. 3a przedsibiorca telekomunikacyjny jest obowizany zapewni warunki dostpu i utrwalania w zakresie wszystkich wiadczonych usug telekomunikacyjnych od dnia rozpoczcia dziaalnoci telekomunikacyjnej, a w przypadku rozpoczcia wiadczenia nowej usugi telekomunikacyjnej od dnia jej uruchomienia. Zapis ten obliguje przedsibiorc telekomunikacyjnego do staej modernizacji i unowoczeniania raz zbudowanego systemu, a tym samym uwzgldniania w kosztach uruchomienia nowej usugi telekomunikacyjnej, take kosztw zwizanych z jego obowizkami na rzecz obronnoci i bezpieczestwa pastwa oraz porzdku publicznego. Dziaanie takie ma zapewni uprawnionym podmiotom moliwo stosowania kontroli operacyjnej nawet w stosunku do uytkownikw najnowszych i najbardziej zaawansowanych technicznie usug telekomunikacyjnych. Warunkiem skutecznej realizacji tych celw jest jednak staa modernizacja i rozbudowa systemw monitoringu uprawnionych podmiotw tak, aby byy one w stanie przechwyci i przetworzy uzyskane od przedsibiorcy telekomunikacyjnego treci przekazw telekomunikacyjnych, przesyanych przy pomocy nowych usug telekomunikacyjnych. Koszty takich prac s jednak trudne do oszacowania, gdy na ich wysoko wpywa bezporednio szybko i zakres zmian nastpujcych na rynku usug telekomunikacyjnych. koszty eksploatacji i modernizacji urzdze szyfrujcych przekaz informacji pomidzy przedsibiorc telekomunikacyjnym i uprawnionym podmiotem oraz pomidzy elementami systemu uprawnionego podmiotu. Ze wzgldu na stay rozwj technik dekryptau niezbdnym jest systematyczne zmienianie kluczy szyfrujcych stosowanych w tych urzdzeniach oraz modernizacja lub wymiana samych urzdze szyfrujcych tak, aby speniay one wymagania DBTI Agencji Bezpieczestwa Wewntrznego, a tym samym posiaday aktualny certyfikat do okrelonej klauzuli niejawnoci (zalenej od stosujcego je uprawnionego podmiotu).

2)

3)

Wielko wymienionych grup kosztw w odniesieniu do konkretnego uprawnionego podmiotu zaley w duym stopniu od zakresu jego ustawowych uprawnie, jego struktury organizacyjnej oraz iloci spraw, w ktrych niezbdne jest wykorzystanie kontroli operacyjnej (lub iloci zapyta o dane telekomunikacyjne w przypadku interfejsu HI A-B). W zalenoci od wymienionych wyej czynnikw wielko kosztw budowy

interfejsu po strome uprawnionego podmiotu moe si waha od kilku do kilkudziesiciu milionw zotych. Wpyw na przychody i wydatki przedsibiorcw telekomunikacyjnych Przyjcie uregulowa prawnych zaproponowanych w przedmiotowego rozporzdzenia wpynie na realne obnienie kosztw funkcjonowania przedsibiorcw telekomunikacyjnych w porwnaniu z aktualnym stanem prawnym. W chwili obecnej przedsibiorca telekomunikacyjny jest obowizany do ponoszenia kosztw a nastpnie eksploatacji kompleksowego rozwizania technicznego umoliwiajcego uprawnionym podmiotom wykonywanie ich ustawowych zada. Zastosowanie rozwizania opartego o interfejs spowoduje, e cz kosztw przeniesiona zostaje na podmioty uprawnione, a porozumienia (umowy) ksztatuj faktyczny podzia kosztw pniejszej eksploatacji. Zastosowanie przez przedsibiorc telekomunikacyjnego rozwizania interfejsowego pozwala mu te na skuteczne skorzystanie z dobrodziejstw art. 179 ust. 4c tj. wykonywania swych obowizkw na rzecz obronnoci i bezpieczestwa pastwa oraz bezpieczestwa, porzdku publicznego na zasadach outsourcingu, wsplnie z innym przedsibiorc telekomunikacyjnym. Wsplna budowa interfejsu przez kilku przedsibiorcw telekomunikacyjnych bdzie niewtpliwie wpywaa na obnienie kosztw inwestycji i pniejszej eksploatacji (w tym take koszty osobowe), a w zwizku z powyszym sprawi, e nawet stosunkowo niewielcy przedsibiorcy telekomunikacyjni mog by zainteresowani zastosowaniem takiego rozwizania. Fakt ten moe take spowodowa powstanie grupy wyspecjalizowanych w tej dziedzinie przedsibiorcw telekomunikacyjnych, ich gwnym rdem dochodu bd pobierane od innych przedsibiorcw telekomunikacyjnych opaty za wykonywanie powierzonych zada na zasadach okrelonych w art. 179 ust. 7. W zwizku z powyszym regulacje te bd dziaa stymulujco na rozwj przedsibiorczoci telekomunikacyjnej. Proponowane regulacje nie maj wpywu na konkurencyjno gospodarki w zakresie rynku telekomunikacyjnego. Przedsibiorcy telekomunikacyjni oraz podmioty uprawnione w wietle projektowanych zapisw prawa telekomunikacyjnego mog na podstawie odrbnych umw okreli, i warunki dostpu i utrwalania zapewnia si za pomoc interfejsw zlokalizowanych w miejscach obejmowanych przez sie przedsibiorcy telekomunikacyjnego. Umowa moe okrela wspudzia stron w kosztach zastosowania interfejsw. Biorc pod uwag autonomiczno woli stron przy ksztatowaniu zobowiza umownych, nie ma praktycznych moliwoci wskazania kosztw realizacji zapisw rozporzdzenia. Ewentualn podstaw do dokonania takich szacunkw powinny by dane uzyskane od producentw/dostawcw tego typu urzdze/systemw z uwzgldnieniem zmian jakie naley dokona w zwizku ze specyficznymi wymogami ustawy - Prawo telekomunikacyjne. Wysoko realnie ponoszonych kosztw przez poszczeglnych przedsibiorcw telekomunikacyjnych jest trudna do oszacowania. W duym stopniu zaley ona nie tylko od wielkoci i obszaru dziaania danego podmiotu ale te od poziomu zaawansowania technologicznego: eksploatowanej przez niego infrastruktury i wiadczonych usug telekomunikacyjnych. Istotnym czynnikiem wpywajcym na wysoko tych wydatkw jest take sposb w jaki przedsibiorca telekomunikacyjny dotychczas realizowa swe obowizki wynikajce z art. 179 ust. 3 i 180d ustawy - Prawo telekomunikacyjne. W przypadku przedsibiorcw, ktrzy systematycznie rozwijali systemy teleinformatyczne zapewniajce realizacj ustawowych obowizkw i wspdziaay w tym zakresie z uprawnionymi podmiotami zastosowanie interfejsu bdzie wymagao stosunkowo niewielkich nakadw i krtkiego czasu. W sytuacji gdy przedsibiorca
7

telekomunikacyjny nie przykada znaczenia przedmiotowej problematyce, a swoje dotychczasowe dziaania w tej dziedzinie stara si ograniczy do minimum nie uwzgldniajc tych potrzeb przy zakupie nowego sprztu centralowego oraz pomijajc uwagi i sugestie uprawnionych podmiotw (w stopniu nie speniajcym podstawowych wymaga ustawowych podmiotw), koszt penego wdroenia przedmiotowych interfejsw moe si wiza z powanymi wydatkami i wymaga cakowitej modernizacji posiadanej infrastruktury telekomunikacyjnej. Majc jednak na uwadze fakt, e deklaracja zastosowania interfejsu jest przejawem wolnej woli przedsibiorcy telekomunikacyjnego naley uzna, e rozwizanie takie przyjmie on tylko wwczas, gdy zwizane z tym wydatki i nakad prac bdzie znaczco mniejsze ni realizacja ustawowych obowizkw w inny sposb, zgodny z wymaganiami zawartymi w rozporzdzeniu, o ktrym mowa w art. 179 ust. 12 ustawy - Prawo telekomunikacyjne. IV. Wpyw regulacji na rynek pracy. Wejcie w ycie rozporzdzenia nie bdzie miao wpywu na rynek pracy. V. Wpyw regulacji na konkurencyjno wewntrzn i zewntrzn gospodarki. Wejcie w ycie rozporzdzenia nie bdzie miao wpywu na konkurencyjno wewntrzn i zewntrzn gospodarki. VI. Wpyw regulacji na sytuacj i rozwj regionalny. Wejcie w ycie rozporzdzenia nie bdzie miao wpywu na sytuacj i rozwj regionalny.

Zacznik nr 1 do rozporzdzenia Rady Ministrw z dnia 2011 r. WYMAGANIA TECHNICZNE I EKSPLOATACYJNE


dla interfejsw umoliwiajcych wykonywanie zada i obowizkw na rzecz obronnoci, bezpieczestwa pastwa oraz bezpieczestwa i porzdku publicznego

I. Normy i dokumenty powoane 1. Wykaz norm i dokumentw powoanych: [1] ETSI ES 201 671v3.1.1 Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic [2] ETSI TS 102 232-1 V2.5.1 Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 1: Handover specification for IP delivery [3] ETSI TS 102 232-3 V2.2.1 Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 3: Service-specific details for internet access services [4] ETSI TS 102 232-5 V2.5.1 Lawful Interception (LI); Handover Interface and Service-Specific Details (SSD) for IP delivery; Part 5: Service-specific details for IP Multimedia Services [5] ETSI TS 102 232-6 V2.3.1 Lawful Interception (LI);Handover Interface and Service-Specific Details (SSD) for IP delivery;Part 6: Service-specific details for PSTN/ISDN services [6] ETSI TS 102 657 V1.7.1 Lawful Interception (LI); Retained handling;Handover interface for the request and delivery of retained data data

[7] ETSI ETS 300 927 Digital cellular telecommunications system (Phase 2+)(GSM); Numbering, addressing and identification (GSM 03.03 version 5.2.1 Release 1996) [8] ETSI TS 102 280 X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons" V1.1.1 (2004-03) [9] 802.3ab-1999 - IEEE Standard for Local and Metropolitan Area Networks - Part 3 Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Physical Layer Parameters and Specifications for 1000 Mb/s Operation over 4 pair of Category 5 Balanced Copper Cabling, Type 1000BASE-T [10] IETF RFC 0791 Internet Protocol [11] IETF RFC 0959 File Transfer Protocol [12] IETF RFC 1889 RTP: A Transport Protocol for Real-Time Applications [13] IETF RFC 3852 Cryptographic Message Syntax (CMS)

[14] IETF RFC 3261 SIP: Session Initiation Protocol [15] ITU-T X.680 Abstract Syntax Notation One (ASN.1): Specification of basic notation [16] ITU-T X.681 Abstract Syntax Notation One (ASN.1): Information object specification [17] ITU-T X.682 Abstract Syntax Notation One (ASN.1): Constrain specification [18] ITU-T X.683 Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications [19] ITU-T X.683 Abstract Syntax Notation One (ASN.1): Specification of Packed Encoding Rules (PER) [20] W3C Extensible Markup Language (XML) 1.0 [21] IETF RFC 0793 Transmission Control Protocol 2. Dokumenty, o ktrych mowa w jednostkach redakcyjnych [1][8], s dostpne na stronach Europejskiego Instytutu Norm Telekomunikacyjnych ETSI (www.etsi.org). 3. Dokument, o ktrych mowa w jednostce redakcyjnej [9], jest dostpny na stronach Instytutu Inynierw Elektrykw i Elektronikw IEEE (www.ieee.org). 4. Dokumenty, o ktrych mowa w jednostkach redakcyjnych [10]-[14], s dostpne na stronach zespou inynierw ustanawiajcych standardy techniczne i organizacyjne w Internecie IETF (www.ietf.org). 5. Dokumenty, o ktrych mowa w jednostkach redakcyjnych [15]-[19], s dostpne na stronach Midzynarodowego Zwizku Telekomunikacyjnego ITU (www.itu.int). 6. Dokument, o ktrych mowa w jednostce redakcyjnej [20], jest dostpny na stronach World Wide Web Consortium W3C (www.w3c.org). II. Stosowane skrty 3GPP - wsplny projekt kilku organizacji normalizacyjnych majcy na celu rozwj systemw telefonii komrkowej trzeciej generacji 3G (3rd Generation Partnership Project) - system przedsibiorcy telekomunikacyjnego umoliwiajcy realizacj dostpu do wybranych treci przekazw telekomunikacyjnych (Administration Function) - zestandaryzowana notacja stosowana do opisu struktur danych przenoszonych przez wiadomoci wymieniane pomidzy komunikujcymi si elementami systemu, zdefiniowana w zaleceniach ITU-T X.680 [15], ITU-T X.681 [16], ITU-T X.682 [17], ITU-T X.683 [18] (Abstract Syntax Notation One) - sposb kodowania informacji zapisanej przy uyciu notacji ASN.1 do postaci transmitowanej w sieciach telekomunikacyjnych, zgodny z zaleceniem ITU-T X.690 [19] (Basic Encoding Rules) - hurtowa usuga dostpu do szerokopasmowej transmisji danych z wykorzystaniem czy oraz wzw sieci operatora udostpniajcego (Bitstream Access)

ADMF

ASN.1

BER

BSA

10

CC CSD CS DER ESN

- tre przekazu telekomunikacyjnego (Content of Communication) - transmisja danych z wykorzystaniem komutacji czy (Circuit Switched Data) - komutacja kanaw (Circuit Switched) - format binarny okrelony w dokumencie [13] (Distinguished Encoding Rules) - indywidualny numer identyfikujcy telekomunikacyjne urzdzenie kocowe uywane w ruchomej publicznej sieci telefonicznej wykorzystujcej technologi CDMA (Code Division Multiple Access) (Electronic Serial Number) - protok transferu plikw, zdefiniowany w dokumencie IETF RFC 0959 [11] (File Transfer Protocol) - mechanizm przekazywania treci monitorowanej komunikacji do LEMF, dotyczcy monitorowania transmisji danych pakietowych GPRS (GPRS LI Correlation) - usuga pakietowej transmisji danych w sieciach mobilnych (General Packet Radio Service) - standard telefonii komrkowej drugiej generacji (Global System for Mobile Communications) - indywidualny midzynarodowy numer identyfikacyjny telekomunikacyjne urzdzenie kocowe uywane w ruchomej publicznej sieci telefonicznej (International Mobile Equipment Identity) - (International Mobile Subscriber Identity) midzynarodowy numer przydzielony karcie identyfikujcej uytkownika w ruchomej publicznej sieci telefonicznej - informacje zwizane z przekazem telekomunikacyjnym (Intercept Related Information) - sie cyfrowa z integracj usug (Integrated Services Digital Network) - podmiot uprawniony do monitorowania (Law Enforcement Agency) - system uprawnionego podmiotu umoliwiajcy dostp do wybranych treci przekazw telekomunikacyjnych (Law Enforcement Monitoring Facility) - interfejs pomidzy systemem uprawnionego podmiotu a systemem przedsibiorcy telekomunikacyjnego, wykorzystywany na potrzeby uprawnionego monitorowania (Lawful Interception Handover Interface) - nazwa uytkownika logujcego si do sieci, uywana w procesie jego uwierzytelnienia - unikalny numer identyfikujcy telekomunikacyjne urzdzenie kocowe uywane w ruchomej publicznej sieci telefonicznej wykorzystujcej technologi CDMA, zastpujcy ESN (Mobile Equipment Identifier)

FTP GLIC

GPRS GSM IMEI

IMSI

IRI ISDN LEA LEMF

LI HI

LOGIN MEID

11

MSISDN - numer przydzielony uytkownikowi kocowemu ruchomej publicznej sieci telefonicznej (Mobile Subscriber Integrated Services Digital Network) PKI PSTN RTP - Infrastruktura Klucza Publicznego (Public Key Infrastructure) - publiczna komutowana sie telefoniczna (Public Switched Telephone Network) - protok transportowy przeznaczony do transmisji danych multimedialnych w czasie rzeczywistym, zdefiniowany w dokumencie IETF RFC 1889 [12] (Real - time Transport Protocol) - protok sygnalizacyjny warstwy aplikacyjnej wykorzystywany do inicjowania, zarzdzania oraz zakaczania sesji (poczenia telefonii internetowej, konferencji multimedialnej), zdefiniowany w dokumencie IETF RFC 3261 [14] (Session Initiation Protocol) - protok komunikacji w sieci komputerowej, zdefiniowany dokumencie IETF RFC 0793 [21]. (Transmission Control Protocol) w

SIP

TCP ULIC

- mechanizm przekazywania treci monitorowanej komunikacji do LEMF, dotyczcy monitorowania transmisji danych pakietowych UMTS (UMTS LI Correlation) - Uniwersalny System Telekomunikacji Ruchomej (Universal Mobile Telecommunications System) - uniwersalny jzyk formalny przeznaczony do opisu rnego typu danych, opracowany przez World Wide Web Consortium (W3C), ktrego specyfikacja jest zawarta w dokumencie XML 1.0 [20] (Extensible Markup Language)

UMTS XML

III. Okrelenia uyte w zacznikach oznaczaj: 1. Interfejs LI HI elektroniczny, zdalny, oparty na protokole komunikacyjnym IP, interfejs midzy systemem przedsibiorcy telekomunikacyjnego, a systemem uprawnionego podmiotu, umoliwiajcy realizacj dostpu do wybranych treci przekazw telekomunikacyjnych, w skad ktrego wchodz: a) interfejs HI1 styk umoliwiajcy dwukierunkow wymian wiadomoci midzy LEMF a ADMF. Wykorzystywany jest przez LEMF do przesyania da, natomiast ADMF przesya gwnie notyfikacje zdarze/stanu realizacji da. Ponadto realizuje funkcje administracyjne. b) interfejs HI2 styk umoliwiajcy jednokierunkowe, w kierunku do LEMF, przesyanie informacji zwizanych z objtymi monitorowaniem, c) interfejs HI3 styk umoliwiajcy jednokierunkowe, w kierunku do LEMF, przesyanie treci monitorowanych. 2. Interfejs HI A-B - elektroniczny, zdalny, oparty na protokole komunikacyjnym IP, interfejs sucy do dostarczania przez przedsibiorc telekomunikacyjnego uprawnionemu podmiotowi danych, o ktrych mowa w art. 180d ustawy - Prawo telekomunikacyjne, w skad ktrego wchodz:

12

a) interfejs HI A styk sucy do realizowania funkcji administracyjnych polegajcych na przesyaniu i obsudze wiadomoci przekazywanych w obu kierunkach midzy uprawnionym podmiotem a przedsibiorc telekomunikacyjnym, b) interfejs HI B styk sucy do przekazywania przez przedsibiorc telekomunikacyjnego wynikw zapyta skadanych za porednictwem HI A. 3. Obiekt monitorowany telekomunikacyjne urzdzenie kocowe, uytkownik lub abonent wskazany w postanowieniu sdu wydanym na podstawie wniosku albo zarzdzenia organu uprawnionego podmiotu wydanego na podstawie odrbnych przepisw. 4. Bufor zesp urzdze przedsibiorcy telekomunikacyjnego odpowiedzialny za magazynowanie danych do czasu ich przekazania do systemu teleinformatycznego uprawnionego podmiotu. 5. Monitorowanie dostp do przekazw telekomunikacyjnych i zwizanych z nimi danych, o ktrych mowa w art. 179 ust. 3 pkt 1 lit. a ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne. 6. Sie mobilna sie w rozumieniu art. 2 pkt 33 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne. 7. Sie stacjonarna sie w rozumieniu art. 2 pkt 38 ustawy z dnia 16 lipca 2004 r. Prawo telekomunikacyjne. IV. Interfejs LI HI 1. Wymagania oglne 1.1. W warstwie fizycznej stosowany jest interfejs standardu Ethernet 1000BASE-T zgodny z IEEE 802.3ab [9]. Do obsugi kadego z uprawnionych podmiotw przewidziany jest oddzielny port w standardzie Ethernet, z zastrzeeniem pkt 1.9. 1.2. Protokoem warstwy sieciowej interfejsu LI HI jest protok IPv4 zgodny z IETF RFC 0791[10]. Wymagane jest stosowanie publicznych adresw IP. 1.3. Sie pomidzy ADMF a LEMF jest sieci wydzielon (sie WAN), za ktr odpowiada LEA. Wybr protokou, dostosowanie przesyanych informacji oraz szyfrowanie sygnau na czach WAN ley w gestii LEA. 1.4. Szyfrowanie transmisji realizuje si poza interfejsem LI HI na poziomie warstwy cza danych lub warstwy sieciowej. 1.5. W celu identyfikacji obiektw monitorowanych wykorzystuje si niepowtarzalny dla kadego obiektu numer LIID. 1.6. Numer LIID dla danego kryterium wyboru obejmuje tylko jedn usug podlegajc monitorowaniu. W przypadku monitorowania wikszej liczby usug, nadaje si nastpne numery LIID dla tego samego kryterium wyboru. 1.7. System LEMF w wiadomociach interfejsu LI HI uywa poniej zdefiniowanego formatu LIID. Numer LIID skada si z dwch czonw: LEAID + SEQ (kolejny niepowtarzalny numer). LIID jest prezentowane za pomoc 17 znakw numeryczny ASCII 0 - 9, 2 cyfry okrelajce LEAID oraz 15 cyfr wskazujcych numer SEQ

13

(zgodnie z tabel nr 1). Warto LEAID jest przydzielona kademu LEA, zgodnie z tabel nr 2. Tabela nr 1 LIID LEAID + SEQ 2 cyfry + 15 cyfr Np.: 01000300056043015 Tabela nr 2 LEAID Warto 00 01 02 03 04 05 06 07

LEA LEMF Operatora ABW POLICJA SKW ZW SG MF CBA

Opis Przedsibiorca telekomunikacyjny Agencja Bezpieczestwa Wewntrznego Policja Suba Kontrwywiadu Wojskowego
andarmeria Wojskowa

Stra Graniczna Ministerstwo Finansw Centralne Biuro Antykorupcyjne

1.8. W przypadku wystpienia awarii powodujcej brak transmisji pomidzy ADMF i LEMF, system monitoringu przedsibiorcy telekomunikacyjnego umoliwia gromadzenie treci komunikatw i informacji zwizanych z obiektem monitorowanym w buforze zapewniajcym ich przechowywanie przez co najmniej 72 godziny. 1.9. Dopuszcza si wykorzystanie jednego portu do obsugi wicej ni jednego uprawnionego podmiotu. Wykorzystanie takiego rozwizania uzgadnia si na etapie uzgadniania zasad wsppracy poprzez interfejs pomidzy przedsibiorc telekomunikacyjnym i zainteresowanymi LEA. 2. Wymagania na modu HI1: 2.1 interfejs HI1 zapewnia: a) przekazywanie do ADMF zlece w zakresie wczania, modyfikacji i wyczania monitorowania obiektw oraz zapyta o status obserwacji, b) przekazywanie od ADMF do LEMF informacji o statusie realizacji zlece, zapyta oraz wystpowaniu awarii, c) moliwo realizacji podstawowych testw diagnostycznych tego interfejsu d) w peni automatyczn realizacj zlece przekazywanych od LEMF, bez udziau pracownikw przedsibiorcy telekomunikacyjnego, z zastrzeeniem pkt 2.15.

14

2.2

W celu aktywacji kadego zlecenia monitoringu, LEA okrela: a) numer LIID, b) obiekt obserwacji (target), c) monitorowan usug, d) zakres monitorowania.

2.3

Interfejs HI1 zapewnia nastpujce kryteria wyboru obiektu obserwacji w sieciach telekomunikacyjnych, stosownie do rodzaju sieci: a) numer abonenta PSTN/ISDN/MSISDN, b) IMSI, c) numer IMEI o dugoci 15 cyfr, zgodnie z ETSI ETS 300 927 [7], d) LOGIN, e) adres IP, f) adres MAC, g) ESN/MEID.

2.4

Interfejs HI1 zapewnia nastpujce kryteria wyboru monitorowanych usug, stosownie do rodzaju sieci: a) z komutacj kanaw, w tym poczenia gosowe, poczenia wideo, przesyanie faksw, krtkich wiadomoci tekstowych SMS, CSD; b) transmisji pakietowej w sieciach mobilnych; c) dostpu do internetu; d) telefonii internetowej (VoIP).

2.5

Poprzez zakres monitorowania LEA wskazuje jeden z dwch zakresw: a) przesyanie informacji zwizanych z objtymi monitorowaniem przekazami telekomunikacyjnymi oraz treci krtkich wiadomoci tekstowych SMS (IRI), b) przesyanie informacji zwizanych z objtymi monitorowaniem przekazami telekomunikacyjnymi oraz treci monitorowanych przekazw telekomunikacyjnych (IRI+CC).

2.6

Wysyanie zlece aktywacji nastpuje w chwili rzeczywistego uruchamiania monitoringu. Dopuszcza si moliwo wysyania zlece aktywacji z wyprzedzeniem. Maksymalne wyprzedzenie uzgadnia si na etapie uzgadniania zasad wsppracy poprzez interfejs. W zleceniu aktywacji okrela si czas zakoczenia monitorowania. Zlecenie modyfikacji monitorowania obejmuje: a) czas jej wyczenia, b) wczenia/wyczenia trybu online w odniesieniu do usug sieci mobilnych.

2.7

2.8

System monitoringu przedsibiorcy telekomunikacyjnego przesya do systemu LEMF informacj o czasie faktycznego wykonania polecenia aktywacji, deaktywacji albo modyfikacji monitorowania. W przypadku bdu w trakcie

15

wykonywania polecenia, przesya informacj o fakcie pojawienia si bdu lub braku moliwoci wykonania polecenia. 2.9 W przypadku awarii elementw sieci operatora system monitoringu przedsibiorcy telekomunikacyjnego wysya do systemw LEMF uprawnionych podmiotw informacj o wystpieniu awarii wraz z okreleniem jej zasigu, poprzez podanie numerw central objtych awari, przesyajc jednoczenie do kadego z uprawnionych podmiotw informacje o objtych awari numerach LIID, ktre znajduj si w jego dyspozycji.

2.10 Po usuniciu awarii, system monitoringu przedsibiorcy telekomunikacyjnego niezwocznie przesya do systemu LEMF uprawnionego podmiotu informacje o czasie trwania przerwy w monitorowaniu. 2.11 ADMF w odpowiedzi na pytanie o status obserwacji nie przesya adnych danych identyfikujcych obiekt poza LIID. 2.12 Zlecenia wystawiane przez uytkownika LEMF, za wyjtkiem wczenia/wyczenia trybu online oraz weryfikacji stanu obserwacji, s podpisywane elektronicznie. 2.13 Formatem stosowanego podpisu elektronicznego da HI1 jest CMS (Cryptographics Message Syntax) zdefiniowany w dokumencie IETF RFC 3852 [13]. Na potrzeby stosowania podpisu elektronicznego wykorzystywane s certyfikaty okrelone w dokumencie ETSI TS 102 280 [8] (z uwzgldnieniem wymaga technicznych zawartych w rozporzdzeniu wykonawczym do ustawy o podpisie elektronicznym) oraz PKI. 2.14 Szczegowa specyfikacja interfejsu HI1 przedstawiona jest w zaczniku nr 2. 2.15 Za zgod uprawnionego podmiotu dopuszcza si prac interfejsu HI1 w trybie pautomatycznym, w ktrym pracownik przedsibiorcy telekomunikacyjnego speniajcy wymagania okrelone w art. 179 ust. 4b ustawy, po odebraniu zlecenia od LEMF wykonuje prace niezbdne do przygotowania sieci przedsibiorcy telekomunikacyjnego do realizacji zlecenia. 3. Wymagania na interfejs HI2 3.1 Informacje zwizane z objtymi monitorowaniem przekazami telekomunikacyjnymi przekazywane s do LEMF w czasie do 10 minut od zakoczenia przekazu. Raporty dotyczce zdarze wystpujcych w danej sesji komunikacyjnej powinny by wysyane w kolejnoci wystpienia tych zdarze. Przesyanie do LEMF informacji zwizanych z objtymi monitorowaniem przekazami telekomunikacyjnymi odbywa si z wykorzystaniem protokou FTP zdefiniowanym w dokumencie IETF RFC 959 [11] na zasadach okrelonym w normie ETSI ES 201 671[1]. Sesje FTP s nawizywane tylko w kierunku od ADMF do LEMF w trybie pasywnym. Do nazewnictwa plikw wykorzystuje si Metod A zdefiniowan w standardzie ETSI ES 201 671 [1] Annex C pkt C.2.2 . Zgodnie z t metod nazwa pliku ma posta: <LIID>_<seq>.<ext>. Nazwa przesyanego pliku jest zmieniana na docelow po udanym nagraniu. Plik tymczasowy posiada dodatkowe rozszerzenie .tmp (LIID_seq.ext_tmp).

3.2

3.3 3.4

3.5

16

3.6

Zawartoci plikw (dane IRI) kodowane s w formacie ASN.1/BER zgodnie z: a) ETSI ES 201 671[1] w odniesieniu do usug sieci mobilnych oraz usug transmisji pakietowej w sieciach mobilnych; b) ETSI TS 102 232-1[2] i ETSI TS 102 232-6[5] w odniesieniu do usug sieci telefonii stacjonarnej; c) ETSI TS 102 232-1[2] i ETSI TS 102 232-3[3] w odniesieniu do usug dostpu do Internetu; d) ETSI TS 102 232-1[2] i ETSI TS 102 232-5[4] w odniesieniu do usug telefonii internetowej.

3.7

Specyfikacja interfejsu HI2 jest rozszerzona o parametr ExtendedPartyIdentity. Specyfikacja struktur danych w notacji ASN.1 opisujcych ten parametr znajduje si w zaczniku nr 2. Przesyany plik moe zawiera wiele pojedynczych rekordw IRI pod warunkiem, e dotycz one tego samego LIID. Nie stosuje si agregacji wielu rekordw IRI w jednej strukturze ASN.1.

3.8 3.9

3.10 Wartoci parametrw IRI definiuje si w formatach zalecanych przez normy telekomunikacyjne, ktre ich dotycz (np. ISDN user part, DSS1, MAP, IP). 3.11 Po skutecznym przekazaniu rekordw IRI, system monitoringu przedsibiorcy telekomunikacyjnego usuwa zwizane z nimi dane ze swoich zasobw. 3.12 Interfejs HI2 nie wymaga stosowania podpisu elektronicznego. 4. Wymagania na interfejs HI3 4.1 4.2 Rozpoczcie przekazywania do LEMF treci objtych monitorowaniem nastpuje w czasie do 10 min. od zakoczenia przekazu. Korelacja pomidzy rekordami IRI (HI2) a przekazywan treci komunikacji CC (HI3) odbywa si z wykorzystaniem parametru LIID, a w przypadku usug sieci z komutacj kanaw rwnie parametru CIN. Do przekazywania treci komunikacji objtych monitorowaniem, dla usug sieci mobilnych stosuje si: protok FTP zdefiniowany w dokumencie IETF RFC 959 [11] na zasadach okrelonych w standardzie ETSI ES 201 671[1]. w przypadku pocze gosowych zapis treci przekazw moe by realizowany na dwa sposoby. W pierwszym dla kadego z kierunkw (w kierunku od i do obiektu monitorowanego) tworzony jest odrbny plik (trybu stereo). Drugi sposb przewiduj e oba kierunki transmisji zapisywane s w ramach jednego pliku (trybu mono). tre przesyana za porednictwem HI3 jest zapisywana w plikach o nazwie zgodnej ze schematem: <LIID>_<cin>.<ext>, gdzie: LIID identyfikator celu LIID cin communication-Identity-Number

4.3

a) dla trybu offline:

17

Ext rodzaj zawartej informacji, 2 tre CC (od monitorowanego obiektu); 4 tre CC (do monitorowanego obiektu); 6 tre CC (do i od monitorowanego obiektu); nazwa przesyanego pliku jest zmieniana na docelow po udanym nagraniu; plik tymczasowy posiada dodatkowe rozszerzenie .tmp (LIID_cin.ext_tmp). pliki audio powinny by kodowane w formacie wave: PCM, 8 kHz, 16 bitw, mono.2 pliki wideo powinny by kodowane w formacie H.263 lub H.264. b) dla trybu online: przekazy telekomunikacyjne wysyane i odbierane przez monitorowany obiekt ADMF przesya do LEMF w czasie rzeczywistym; do przesyania przekazw stosuje si protok SIP zgodny z dokumentem IETF RFC 3261[14]; format pola Call-ID w nagwku SIP przyjmuje posta: LIID_cin; dla pocze gosowych stosowany jest kodek G.711A ( 8kHz); dla pocze wideo stosowany jest kodek H.263 lub H.264; Adres docelowy SIP okrelany jest na podstawie forwardingAddress, ktry LEA okrela za pomoc interfejsu HI1. 4.4 parametru

W przypadku usug transmisji pakietowej w sieci mobilnej, do przekazywania treci komunikacji objtych monitorowaniem stosuje si protok GLIC/ULIC z zastosowaniem zasad okrelonych w normie ETSI ES 201 671[1]. Przekazywanie treci komunikacji objtej monitorowaniem w sieci stacjonarnej jest realizowane zgodnie zasadami okrelonymi w normach ETSI TS 102 2321[2] i ETSI TS 102 232-6[5] W przypadku usug dostpu do Internetu, przekazywanie treci komunikacji objtej monitorowaniem jest realizowane zgodnie zasadami okrelonymi w normach ETSI TS 102 232-1[2] i ETSI TS 102 232-3[3]. W przypadku usug telefonii internetowej, przekazywanie treci komunikacji objtej monitorowaniem jest realizowane zgodnie zasadami okrelonymi w normach ETSI TS 102 232-1[2] i ETSI TS 102 232-5[4]. Po skutecznym przekazaniu treci komunikatw system przedsibiorcy telekomunikacyjnego usuwa je ze swoich zasobw. Interfejs HI3 nie wymaga stosowania podpisu elektronicznego. monitoringu

4.5

4.6

4.7

4.8 4.9

V. Interfejs HI A-B 1.1


2

Interfejs systemu monitoringu przedsibiorcy telekomunikacyjnego dostpny jest w jednym punkcie (lokalizacji) dla wszystkich uprawnionych podmiotw. Do

Parametry kodeka PCM odpowiadaj parametrom kodeka G.711A, ktry jest wykorzystywany w sieci z komutacj kanaw dla realizacji pocze gosowych, faksowych, czy modemowych.

18

obsugi kadego z uprawnionych podmiotw przewidziany jest oddzielny port w standardzie Ethernet. 1.2 1.3 W warstwie fizycznej stosowany jest interfejs standardu Ethernet 1000BASE-T zgodny z dokumentem IEEE 802.3ab [9]. Protokoem warstwy sieciowej interfejsu LI HI jest protok IPv4 zgodny z dokumentem IETF RFC 0791[10]. Wymagane jest stosowanie publicznych adresw IP. Stosuje si mechanizm podpisu elektronicznego. Realizacja interfejsu HI A-B jest zgodna ze norm ETSI TS 102 657[1]. Dla realizacji komunikacji w interfejsie HI A-B stosuje si wariant okrelony w punkcie 7.3 [1] tj. a) w warstwie transportowej stosowany jest protok TCP, b) stosowane jest ASN.1/BER. 1.7 1.8 1.9 kodowanie elementw informacyjnych w formacie

1.4 1.5 1.6

Warto parametru cSPID odpowiada identyfikatorowi przypisanemu danemu przedsibiorcy w Rejestrze przedsibiorcw telekomunikacyjnych. Pole countryCode w parametrze RequestID przyjmuje warto PL. Pole authorisedOrganisationID w parametrze RequestID przyjmuje warto zgodnie z przypisaniem LEAID. LEAID Warto 00 01 02 03 04 05 06 07 LEA LEMF Operatora ABW POLICJA SKW ZW SG MF CBA Opis Przedsibiorca telekomunikacyjny Agencja Bezpieczestwa Wewntrznego Policja Suba Kontrwywiadu Wojskowego andarmeria Wojskowa Stra Graniczna Ministerstwo Finansw Centralne Biuro Antykorupcyjne

1.10 Nie stosuje si niej wymienionych rozwiza opcjonalnych: a) priorytetw dla obsugi da skierowanych przez LEA (RequestPriority punkt A.2.2.1w dokumencie ETSI TS 102 657 [1] ) b) mechanizm multi-part delivery (zgodnie z punktem 5.1.7 1w dokumencie ETSI TS 102 657 [1]). c) trybu Authorized-Organization-initiated (zgodnie z punktem 5.3 w dokumencie ETSI TS 102 657 [1]). 1.11 Niewykorzystywane s elementy informacyjne wymienione w tabeli nr 3.

19

Tabela nr 3 Punkt w ETSI TS 102 657 [1] Nazwa pola dateOfBirth gender Table IndividualInfo parameters A.12: identificationNumber authenticationInfo Profession subscriberID serviceID Table TelephonyBillingDetails parameters B.3: billingAddress billingIdentifier billingRecords Time Place Table BillingRecords parameters B.4: amount currency method Table Location parameters B.11: postalLocation extendedLocation subscriberID serviceID Table D.3: billingAddress MultimediaBillingDetails parameters billingIdentifier billingRecords Time Place Table D.4: amount MultimedaBillingRecords parameters currency method Table NAserviceUsage parameters Table NABillingDetails parameters E.3: octetsDownloaded octetsUploaded billingAddress E.8: billingIdentifier billingRecords

20

Zacznik nr 2 do rozporzdzenia Rady Ministrw z dnia 2011 r. Specyfikacja elementw interfejsu HI1 oraz format parametru ExtendedPartyIdentity

1. Struktura interfejsu HI1 1.1 Warstwa transportowa 1.1.1 Stosowany jest protok TCP. 1.1.2 Zestawiane s poczenia TCP w kierunkach: ADMF/MF/DF LEMF (HI1LEMFOperations), LEMF ADMF/MF/DF (HI1ADMFOperations). 1.1.3 W ramach jednego poczenia TCP wysyana jest jedna wiadomo warstwy aplikacyjnej (tj. danie, alarm), ktra jest potwierdzania przez drug stron (potwierdzenie otrzymania dania, alarmu). 1.2 Warstwa aplikacyjna Wiadomoci wysyane w warstwie aplikacyjnej zostay zdefiniowane w notacji ASN.1 i s kodowane w standardzie BER. 1.2.1 Opis 1.2.1.1 Przeznaczenie: aktywacje, dezaktywacje i modyfikacje zapytania o dedykacje, alarmy, raporty, status interfejsu. 1.2.1.2 Stosowane s dwa protokoy zdefiniowane w ASN.1: HI1LEMFOperations operacje inicjowane przez LEMF, HI1ADMFOperations alarmy i powiadomienia wysyane przez ADMF. dedykacji,

1.2.1.3 Operacje, o ktrych mowa w pkt 1.2.1.2, s cakowicie od siebie niezalene. 1.2.1.4 Kada operacja/zapytanie to jedna sesja TCP. 1.2.1.5 Kade zapytanie jest potwierdzane przez drug stron. 1.2.2 HI1LEMFOperations 1.2.2.1 Operacje wykonywane przez LEMF: Zapytanie proste: Hello ListRequest RTRequest danie wczenia lub wyczenia trybu online (dotycz tylko obserwacji rozpocztych) Zapytania podpisane:

Activate Modificate, z wyczeniem w odniesieniu do wczania/ wyczania trybu online Deactivate

Rysunek 1: Schemat operacji 1.2.2.2 Kada wiadomo (Request) wysana przez LEMF musi zosta potwierdzona przez ADMF wiadomo (Respond), 1.2.2.3 LEMF czeka na odpowied 10 sek. Po tym czasie uznaje wysan wiadomo za utracon. 1.2.2.4 Nad harmonogramem aktywacji i dezaktywacji czuwa LEMF. Dopuszcza si wysanie zlecenia aktywacji z pewnym wyprzedzeniem. Zlecenie aktywacji musi mie okrelony czas zakoczenia obserwacji. Przesunicie momentu zakoczenia obserwacji ponad ten czas wymaga zlecenia modyfikacji. 1.2.2.5 System monitoringu przedsibiorcy telekomunikacyjnego nie przesya do LEMF dodatkowych raportw o zaoeniu, zdjciu obserwacji w elementach sieci przedsibiorcy telekomunikacyjnego 1.2.2.6 LEMF ma moliwo zadania zapytania (ListRequest) sucego do weryfikacji stanu obserwacji. 1.2.2.7 Zlecenie dezaktywacji oznacza niezwoczne zakoczenie wskazanej obserwacji. W przypadku obserwacji, ktra si jeszcze nie rozpocza oznacza to, e w ogle nie zostanie zrealizowana. Fakt jej zaoenia ma jednak zosta ze wszystkimi tego konsekwencjami odnotowany w logach systemu. 1.2.2.8 Modyfikacji podlegaj jedynie zlecenia, ktre nie zakoczyy si. Modyfikowa mona czasy zakoczenia obserwacji oraz typ monitoringu (wczenie/wyczenie online). Wczenie/wyczenie obserwacji w trybie online nie powoduje zmian (zakce) transmisji w trybie offline. Po rozpoczciu obserwacji czas startu nie moe by ju modyfikowany.

RTRequest +llid:LawfulInterceptionIdentifier + action: ENUMERATED

Rysunek 2: Struktura HI1LEMFPDU 1.2.2.9 Wiadomoci s podzielone na dwie grupy: Request definujce zapytania wysyane przez LEMF Respond odpowiedzi ADMFa na wysane dania LEMFa 1.2.2.10 Dopuszczalne s nastpujce interakcje pomidzy LEMF a ADMF Zapytanie LEMF SignedRequest HelloRequest ListRequest RTRequest Odpowied ADMF GeneralRespond GeneralRespond ListRespond GeneralRespond GeneralRespond Alternatywna odpowied

1.2.2.11 Zapytania podpisane (SignedRequest) Sposb tworzenia i weryfikacji wiadomoci podpisanych za pomoc diagramw aktywnoci przedstawiony jest na rys. 3 i rys. 4.

Rysunek 3: Tworzenie podpisanego zapytania

Rysunek 4: Weryfikacja podpisanego zapytania 1.2.2.12 Uwagi: CMS (Cryptographic Message Syntax 2004): format binarny DER dokumentu z podpisem stanowi podzbir CMS. Dokadna specyfikacja przedstawiona jest w dokumencie IETF RFC3852 [13]. OID definiujcy standard w notacji ASN.1: OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms2004(24) } UnsignedRequestDetail: Struktura opisujca szczegy zapytania aktywacji, modyfikacji i deaktywacji dedykacji. Po zakodowaniu do postaci DER jest podpisywana zgodnie ze specyfikacj przedstawion w dokumencie RFC2315. Struktura UnsignedRequestDetail przedstawiona jest na rys. 5. Service: Obiekt reprezentujcy usugi wiadczone przez operatora.
5

W aktualnej wersji przewidziano monitorowanie nastpujcych usug: CS Circuit Switched PS PacketSwitched InternetAccess InternetTelephony
UnsignedRequestDetail +time: TimeStamp

Command

Activate +liid: LawfullInterceptionIdentifier +startDate: TimeStamp +stopDate: TimeStamp +warrantID: UTF8String

Modificate +liid: LawfullInterceptionIdentifier +stopDate: TimeStamp +warrantID: UTF8String

Deactivate +liid: LawfullInterceptionIdentifier +warrantID: UTF8String

Service

CircuitSwitched +target: Target +monitoringType: MonitoringType +forwardingAddress: ForwardingAddress +stereo: Stereo InternetTelephony +target: Target +monitoringType: MonitoringType

InternetAccess PacketSwitched +target: Target +monitoringType: MonitoringType +target: Target +monitoringType: MonitoringType

Rysunek 5: Struktura UnsignedRequestDetail

1.2.3

HI1ADMFOperations

Rysunek 6: Schemat Operacji 1.2.3.1 Operacje wykonywane przez ADMF: Alarmy Notyfikacje

1.2.3.2 Wiadomoci s podzielone na dwie grupy: InfoIndicator - definiujce alarmy i notyfikacje wysyane przez ADMF Acknowledge - potwierdzenia otrzymania wiadomoci przez ADMF

1.2.3.3 Dopuszczalne s nastpujce interakcje pomidzy ADMF a LEMF Wiadomo ADMF HelloRequest AlarmIndicator NotificationIndicator 1.2.3.4 Uwagi: Wyrnia si dwa typy wiadomoci wysyanych przez ADMF: alarmy i notyfikacje. Kady wysana wiadomo (InfoIndicator) musi zosta potwierdzona przez LEMF (Acknowledge). Potwierdzenie musi zosta zrealizowane w czasie 5 sek.
7

Odpowied LEMF GeneralRespond GeneralRespond GeneralRespond

Alarmy posiadaj dwa stany: wczony, wyczony (pole status). Wiadomo wyczajca alarm moe zawiera tylko jego identyfikator (identity).

Rysunek 7: Struktura HI1ADMFPDU

1.3 HI1LEMFPDU
HI1LEMFOperations DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS LawfulInterceptionIdentifier, TimeStamp FROM UnsignedRequestDetail;

HI1LEMFPDU ::= SEQUENCE { version [0] Version, content [1] Content, operator [2] UTF8String OPTIONAL, ... }

Version ::= ENUMERATED { version1 (1), ... }

Content ::= CHOICE { request [1] Request, respond [2] Respond, ... }

SignedRequest ::= SEQUENCE { version [1] SignedRequestVersion, signStandard [2] OBJECT IDENTIFIER, -- CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) cmsDERSignedRequest [3] OCTET STRING,

-- cmsDERSignedRequest [3] ANY DEFINED BY signStandard ... }

Request ::= CHOICE { simpleRequest [1] SimpleRequest, signedRequest [2] SignedRequest, ... }

SimpleRequest ::= CHOICE { helloRequest [1] HelloRequest, listRequest [2] ListRequest, rtRequest [3] RTRequest, - danie wczenia lub wyczenia trybu online (dotycz tylko obserwacji rozpocztych) dla obserwacji aktywnych ... } RTRequest ::= SEQUENCE { liid [1] LawfulInterceptionIdentifier, action [2] ENUMERATED { start(0), - Wczenie odsuchu online stop(1) - Wyczenie odsuchu online }, }

SignedRequestVersion ::= ENUMERATED { v1 (0), ... }

HelloRequest ::= SEQUENCE { message [1] UTF8String, ... }

Respond ::= CHOICE { generalRespond [1] GeneralRespond, listRespond [2] ListRespond, ... }

10

GeneralRespond ::= SEQUENCE { result [1] Result, message [2] UTF8String OPTIONAL, -- return Hello request message ... }

Result ::= ENUMERATED { ok (1), missing-parameter (2), unknown-parameter (3), unknown-parameter-value (4), incorrect-BER (5), badSignature (6), certificateExpired (7), unknownError (10), unsupportedService (11), ... }

CheckRespond ::= SEQUENCE { liid [1] LawfulInterceptionIdentifier, checkStatus [2] CheckStatus, message [3] UTF8String OPTIONAL, ... }

CheckStatus ::= ENUMERATED { notFound (0), waiting (1), -- zaoone przez lemf, nie ma w cn (czeka na zatwierdzenie lub )

cnActivated (2), -- jest w cn unknown (3), deActivated (4), -- po deaktywowaniu w cn ... }

ListRequest ::= SEQUENCE {

11

type [1] ListType, liid [2] LawfulInterceptionIdentifier OPTIONAL, ... }

ListRespond ::= SET OF CheckRespond

ListType ::= ENUMERATED { all (1), specific (2), ... }

END

1.4 UnsignedRequestDetail
UnsignedRequestDetail DEFINITIONS AUTOMATIC TAGS ::= BEGIN

UnsignedRequestDetail ::= SEQUENCE { time [1] TimeStamp, command [2] Command, operator [2] UTF8String OPTIONAL, ... }

Command ::= CHOICE { activate [1] Activate, deactivate [2] Deactivate, modificate [3] Modificate, ... }

Activate ::= SEQUENCE { lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, startTimestamp [2] TimeStamp, stopTimestap [3] TimeStamp, service [4] Service,

12

warrantID [5] UTF8String, ... }

Modificate ::= SEQUENCE { lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, stopTimestap [3] TimeStamp, warrantID [5] UTF8String, ... }

Deactivate ::= SEQUENCE { lawfulInterceptionIdentifier [1] LawfulInterceptionIdentifier, warrantID [5] UTF8String OPTIONAL, ... }

Service ::= CHOICE { circuitSwitched [1] CircuitSwitched, packetSwitched [2] PacketSwitched, wifi [3] WIFI, -- not used xdsl [4] XDSL, -- not used internetAccess [5] InternetAccess, internetTelephony [6] InternetTelephony, ... }

CircuitSwitched ::= SEQUENCE { target [1] Target, monitoringType [2] MonitoringType, onlineMonitoring [3] BOOLEAN, -- offline - warto domylna, -- online, forwardingAddress [4] ForwardingAddress, stereo [5] Stereo, ... }

Stereo ::= ENUMERATED

13

{ off (0), on (1) }

PacketSwitched ::= SEQUENCE { target [1] Target, monitoringType [2] MonitoringType, ... }

WIFI ::= SEQUENCE { target [1] Target, ... }

XDSL ::= SEQUENCE { target [1] Target, ... }

InternetAccess::= SEQUENCE { target [1] Target, monitoringType [2] MonitoringType, ... } InternetTelephony ::= SEQUENCE { target [1] Target, monitoringType [2] MonitoringType ... }

Target ::= CHOICE { mSISDN [1] MSISDN, -- wykorzystywany rwnie jako numer abonenta ISDN/PSTN lub telefonii internetowej(o ile jest to numer zgodny z E.164) iMSI [2] IMSI, iMEI [3] IMEI,

14

login [4] Login, iPAddress [5] IPAddress, mAC [6] MAC, eSN [7] ESN, ... }

MSISDN ::= OCTET STRING (SIZE (1..9)) IMSI ::= OCTET STRING (SIZE (3..8)) IMEI ::= OCTET STRING (SIZE (8)) Login ::= OCTET STRING (SIZE (1..120)) IPAddress ::= OCTET STRING (SIZE (4)) MAC ::= OCTET STRING (SIZE (6)) ESN ::= OCTET STRING (SIZE (8))

ForwardingAddress ::= SEQUENCE { sipUrl [1] SIPURL, ... }

SIPURL ::= UTF8String

MonitoringType ::= ENUMERATED { iri (1), iriCC (2), ... }

LawfulInterceptionIdentifier ::= OCTET STRING (SIZE (1..25)) -- It is recommended to use ASCII characters in " "0""9". -- For subaddress option only "0"..."9" shall be used. -- 17 znakow numerycznych ASCII -- format: LEAID + TARGET(SEQ) -- TARGET - (15 znakow) nadawany sekwencyjnie dla kazdego LEAID -- LEAID -(2 znaki) 00 LEMF operatora, 01 - ABW, 02 - Policja, 03 - SKW, 04 - ZW, 05 - SG, 06 MF, 07 - CBA

TimeStamp ::= CHOICE { -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and

15

-- is expressed with a definite number of decimal digits or bits. localTime [0] LocalTimeStamp,

utcTime [1] UTCTime }

LocalTimeStamp ::= SEQUENCE { generalizedTime [0] GeneralizedTime, -- The minimum resolution required is one second. -- "Resolution" is the smallest incremental change that can be measured for time and -- is expressed with a definite number of decimal digits or bits.

winterSummerIndication [1] ENUMERATED { notProvided(0), winterTime(1), summerTime(2), ... } } END

1.5 HI1ADMFPDU
HI1ADMFOperations DEFINITIONS AUTOMATIC TAGS ::= BEGIN

IMPORTS LawfulInterceptionIdentifier, TimeStamp FROM UnsignedRequestDetail; HI1ADMFPDU ::= SEQUENCE { version [0] Version, content [1] Content operator [2] UTF8String OPTIONAL, }

Version ::= ENUMERATED { version1 (1),

16

... }

Content ::= CHOICE { info [0] InfoIndicator, acknowledge [1] Acknowledge, ... }

InfoIndicator ::= CHOICE { helloRequest [1] HelloRequest, alarm [2] AlarmIndicator,

notification [3] NotificationIndicator, ... }

HelloRequest ::= SEQUENCE { message [1] UTF8String, ... }

AlarmIndicator ::= SEQUENCE { identity [0] INTEGER, razem z timestamp-on alarmID [1] AlarmID, -- dodatkowe informacje, opis, kod bdu -- czas -- czas wystpienia alarmowanego -- czas wystpienia zdarzenia -- powstanie/ustanie -- numer pozwalajcy na jednoznaczn identyfikacje alarmu

description [2] UTF8String OPTIONAL, (np. z alarmu z MSC), tzw. powd timestamp [3] TimeStamp, wysania alarmu timestamp-on [4] TimeStamp OPTIONAL, zdarzenia timestamp-off [5] TimeStamp OPTIONAL, odwrotnego do zdarzenia alarmowanego status [6] AlarmStatus OPTIONAL, alarmu

-- podobne nature-Of-The-intercepted-call z HI2 (jeeli bd globalny to wszystkie service) nature-of-alarm [7] Nature-Of-The-intercepted-call OPTIONAL,

range-of-alarm [8] NetPartType OPTIONAL, -- dotyczy caej sieci CN czy tylko jej czci (np.: tylko jeden GGSN, jedna centrala) targettype [9] TargetType OPTIONAL, sesji albo wszystkich obserwacji -- dotyczy konkretnego LIID lub konkretnej

17

liid [10] LawfulInterceptionIdentifier OPTIONAL, cid [11] UTF8String OPTIONAL, lub sesji) -- z HI2 (chodzi o wskazanie konkretnej rozmowy -- z HI2 (chodzi o wskazanie

cid-GPRS [12] GPRSCorrelationNumber OPTIONAL, konkretnej rozmowy lub sesji) ... }

Nature-Of-The-intercepted-call ::= ENUMERATED { -- Nature of the intercepted "call": gSM-ISDN-PSTN-circuit-call(0), -- the possible UUS content is sent through the HI2 or HI3 "data" interface -- the possible call content call is established through the HI3 "circuit" interface gSM-SMS-Message(1), -- the SMS content is sent through the HI2 or HI3 "data" interface uUS4-Messages(2), -- the UUS content is sent through the HI2 or HI3 "data" interface tETRA-circuit-call(3), -- the possible call content call is established through the HI3 "circuit" interface -- the possible data are sent through the HI3 "data" interface teTRA-Packet-Data(4), -- the data are sent through the HI3 "data" interface gPRS-Packet-Data(5), -- the data are sent through the HI3 "data" interface uMTS-circuit-call(6), -- the possible call content call is established through the HI3 "circuit" interface -- the possible data are sent through the HI3 "data" interface wIFI (11), -- not used xDSL [12], -- not used internetAccess [13], internetTelephony [14], ... }

NotificationIndicator ::= SEQUENCE { identity [0] INTEGER, identyfikacje alarmu razem z timestamp-on notificationID [1] NotificationID, description [2] UTF8String OPTIONAL, bdu (np. z MSC), tzw. powd timestamp [3] TimeStamp, -- dodatkowe informacje, opis, kod -- czas wysania powiadomienia -- numer pozwalajcy na jednoznaczn

18

timestampEvent [4] TimeStamp, dotyczy powiadomienie

-- czas wystpienia zdarzenia, ktrego

liid [5] LawfulInterceptionIdentifier OPTIONAL, ... }

AlarmID ::= ENUMERATED { sm-buffer-overflow (0), -- bufory wyjciowe w kierunku LEMF przepenine => IRI i/lub CC tracone (operator) lemf-hi3-online-delivery-failure (1), (LEMF) lemf-hi3-delivery-failure (2), lemf-hi2-delivery-failure (3), lemf-hi1-delivery-failure (4), sm-hi1-failure (5), interfejsie HI1 (SM operatora) sm-hi2-failure (6), interfejsie HI2 (SM operatora) sm-hi3-failure (7), interfejsie HI3 (SM operatora) sm-hi3-online-failure (8), interfejsie HI3 (SM operatora) -- problem z monitoringiem online -- problem z zapisywaniem danych HI3 (LEMF) -- problem z zapisywaniem danych HI2 (LEMF) -- problem z monitoringiem online (LEMF) -- brak lub przecienie komunikacji z CN na -- brak lub przecienie komunikacji z CN na -- brak lub przecienie komunikacji z CN na -- brak lub przecienie komunikacji z CN na

major-system-failure (9), -- powane uszkodzenie SM => konieczne sprawdzenie spjnoci BD (SM operatora) -- zarzdzanie obserwacjami prawidowe, ale inne funkcje SM mog nie dziaa (np. cz obserwacji stracona) (SM operatora) minor-system-failure (10), cn-activation-error (11), ni (LIID obowizkowy) (SM operatora) cn-deactivation-error (12), ni (LIID obowizkowy) (SM operatora) -- obserwacja nie zaoona w CN a czas na -- obserwacja nie usunieta z CN a czas na

major-cn-li-failure (13), -- po stronie CN LI cakowicie nie funkcjonowao, BD obserwacji odbudowane w CN (SM operatora) minor-cn-li-failure (14), dziaay (SM operatora) -- po stronie CN pewne funkcje LI nie

manual-system-failure (15), -- informacja wprowadzana rcznie: uszkodzenie w CN lub SM (SM operatora) manual-system-maintenance (20), -- informacja wprowadzana rcznie o pracach planowych w systemie SM operatora (SM operatora) ... }

AlarmStatus ::= ENUMERATED { off (0), on (1), ... }

19

NetPartType ::= ENUMERATED { whole (1), part (2), ... }

TargetType ::= ENUMERATED { all (1), specific (2), ... }

NotificationID ::= ENUMERATED { target-activated (0), target-deactivated (1), target-modificated (2), ... }

Acknowledge ::= CHOICE { respond ... } [0] GeneralRespond,

GeneralRespond ::= SEQUENCE { result message ... } [1] Result, [2] UTF8String OPTIONAL,

Result ::= ENUMERATED { ok (1), missing-parameter (2), unknown-parameter (3), unknown-parameter-value (4), incorrect-BER (5),

20

badSignature (6), certificateExpired (7), unknownError (10), ... }

GPRSCorrelationNumber ::= OCTET STRING (SIZE(8..20))

END

21

2. Format parametru ExtendedPartyIdentity


PartyInformation ::= SEQUENCE { ... partyExtendedIdentity [PRIVATE 1] PartyExtendedIdentity OPTIONAL, ... }

PartyExtendedIdentity ::= SEQUENCE { subscriptionType [1] ENUMERATED { postpaid (0), prepaid ... } OPTIONAL, (1),

activationDate [2] TimeStamp OPTIONAL, deactivationDate [3] TimeStamp OPTIONAL, subscriber [4] Subscriber OPTIONAL, postalAddress [5] PostalAddress OPTIONAL, mailAddress [6] MailAddress OPTIONAL, ... }

Subscriber ::= CHOICE { company [1] Company, person [2] Person, ... }

Company ::= SEQUENCE { name [0] UTF8String, regon [1] OCTET STRING (SIZE (5)),

-- BCD coded 9 digits -- F digit not used ... }

22

Person ::= SEQUENCE { firstName [0] UTF8String, surname [1] UTF8String, pesel [2] OCTET STRING (SIZE (6)) OPTIONAL,

-- BCD coded 11 digits -- F digit not used passportNumber [3] OCTET STRING (SIZE (7..14)) OPTIONAL, -- ASCII coded ... }

PostalAddress ::= SEQUENCE { street [1] UTF8String OPTIONAL, buildingNumber [2] OCTET STRING (SIZE (1..10)) OPTIONAL, -- ASCII coded: 10 char apartmentNumber [3] OCTET STRING (SIZE (1..10)) OPTIONAL, -- ASCII coded: 10 char postcode [4] OCTET STRING (SIZE (1..8)) OPTIONAL, city [5] UTF8String OPTIONAL, country [6] UTF8String OPTIONAL }

23

You might also like