Architetture e standard per le intercettazioni legali

Transcript

Architetture e standard
per le intercettazioni legali
white paper
novembre 2009
© M3S srl
11/2009
per intercettazioni legali
Indice
1 Architettura RFC 3924 ....................................................................................... 4 1.1 Parti dell’architettura: ........................................................................................ 5 1.2 Descrizione delle interfacce tra le diverse parti dell’architettura.............................. 6 1.3 Intercettazione voce .......................................................................................... 6 1.4 Prodotti Cisco .................................................................................................... 7 2 Standard ETSI TS 101 671 ................................................................................ 8 2.1 Identificatori per la Lawful Interception ............................................................... 8 2.2 Handover Interface port 1 (HI1) ......................................................................... 9 2.3 Handover Interface port 2 (HI2) ........................................................................10 2.4 Handover Interface port 3 (HI3) ........................................................................12 3 Un sistema di Lawful Interception basato su componenti free-software.............. 13 Attività co-finanziata dal programma
POR-CRO 2007-13 della Regione Liguria
© 2009 M3S srl
2
Sommario
Con il termine anglosassone “Lawful Interception” (LI) si intende l’intercettazione legale di
comunicazioni private su rete pubblica a seguito di una decisione dell’autorità giudiziaria
(LEA = Law Enforcement Agency).
Nella relazione verrà trattata l’intercettazione dei contenuti trasmessi su reti IP, sia che si
tratti di voce (VoIP), sia che si tratti di dati (Web, E-mail, Instant Messaging, ecc.).
Si terranno in maggior considerazione i prodotti Cisco Systems, per i quali verranno
analizzate sia le capacità di intercettazione dei contenuti trasmessi, sia le capacità di
acquisizione/intercettazione delle informazioni legate alla trasmissione/ricezione di contenuti
posti sotto controllo (IRI = Intercept Related Information). Un esempio di IRI può essere il
numero telefonico (corredato di timestamp), che viene chiamato da un utente di un servizio
VoIP, posto sotto sorveglianza.
Come architettura di riferimento per la LI si utilizzerà quella descritta, solo a scopo
divulgativo, dalla stessa Cisco nell’RFC 3924 dell’ottobre 2004, e si darà una descrizione
della stessa.
Verranno segnalati i riferimenti di altri produttori, oltre Cisco, che forniscono parti
dell’architettura descritta dall’RFC 3924, non prodotte direttamente dalla Cisco.
Verrà trattato lo standard europeo ETSI TS 101 671 (del gennaio 2006) per le interfacce
HI1, HI2, HI3 (da e per il LEA), utile per la realizzazione di un sistema di telecomunicazioni
basato su IP, che supporti appieno la LI.
Infine verrà illustrata una possibile implementazione di un sistema di lawful interception, con
l’utilizzo di prodotti free-software.
© 2009 M3S srl
3
1 Architettura RFC 3924
L’architettura descritta nell’RFC 3924 e proposta da CISCO è in grado di soddisfare i requisiti
imposti da tutti i paesi che possiedono una o più leggi riguardanti la Lawful Interception.
Questi requisiti sono:
-
l’intercettazione non deve essere rilevabile da parte di chi viene intercettato;
-
devono essere presenti meccanismi che impediscano a persone non autorizzate di
effettuare intercettazioni o di venire a conoscenza di esse;
-
si deve poter mantenere separati gli IRI dal contenuto delle intercettazioni;
-
le IRI devono essere recapitate separatamente dai contenuti, e ci deve essere la
possibilità di correlare le IRI con i contenuti;
-
le informazioni cifrate dal provider devono essere spedite al LEA già decifrate, oppure
deve essere fornita al LEA la chiave per decifrarle;
-
se le informazioni sono cifrate dal soggetto posto sotto sorveglianza utilizzando delle
chiavi note al provider, il provider deve fornirle al LEA;
-
se più di una LEA sta effettuando intercettazioni su di un singolo soggetto, a ciascuna
LEA deve essere trasparente il fatto che il soggetto sia già sotto sorveglianza elettronica
da parte di un’altra LEA;
-
il service provider non deve trasmettere nessuna informazione non autorizzata al LEA.
La figura seguente rappresenta l’architettura di riferimento specificata dall’RFC 3924:
+--------------------+
+-----+
| LI Administration |
HI1(a)
|
|
|
Function
|<----------------|
|
+--------------------+
|
|
|
|
|
| MD Provisioning
|
|
| Interface(b)
| LEA |
v
|
|
+-----------+
+--------------------+
|
|
|
|<---(c)----|
|
|
|
| IRI IAP |--IRI(e)-->|
Mediation
|----HI2(g)----->|
|
|
|
|
Device (MD)
|
|
|
+-----------+
|
|----HI3(h)----->|
|
+--------------------+
+-----+
|
^
Intercept |
| Intercepted
Forza dell’Ordine
Request(d) |
| Content(f)
v
|
+--------------------+
User |
Content
| User
------->|
IAP
|------->
Content +--------------------+ Content
Access Provider
© 2009 M3S srl
4
1.1 Parti dell’architettura:
1) LEA (Law Enforcement Agency) è una particolare forza dell’ordine che richiede
l’intercettazione, fornendo l’obbiettivo da intercettare tramite l’interfaccia (a) e
ricevendo le informazioni dell’intercettazione tramite le interfacce (g) (h).
2) LI Administration Function è l’entità che amministra il Mediation Device ed è di
proprietà del provider. Questa parte del sistema riceve la richiesta di intercettazione
da parte del LEA tramite l’interfaccia (a) e configura il Mediation Device tramite
l’interfaccia (b).
3) Mediation Device (MD), è un entità hardware e/o software in grado di effettuare in
tempo reale la configurazione dell’opportuno/i Content-IAP necessario/i ad effettuare
l’intercettazione richiesta. La richiesta di intercettazione viene ricevuta tramite
l’interfaccia (b) e, solo dopo aver richiesto e ottenuto le informazioni necessarie
sull’obbiettivo da intercettare tramite le interfacce (c) ed (e), il MD può configurare i
Content-IAP e far sì che l’intercettazione possa partire. Le IRI e i contenuti delle
intercettazioni sono acquisite dal MD rispettivamente tramite le interfacce (e) ed (f), e
mandati al LEA tramite le rispettive interfacce (g) ed (h).
Nota: Cisco come Mediation Device raccomanda l’SS8 Xcipio, prodotto dalla SS8
Networks (http://www.ss8.com/).
4) Intercept Related Information Intercept Access Point (IRI-IAP). Questa parte del
sistema può essere costituita o da un H.323 gatekeeper, o da un SIP Proxy o da un
Media Gateway Controller, ai quali viene richiesto l’indirizzo IP e la porta utilizzati da
un cliente posto sotto indagine. Questo nel caso si vogliano intercettare telefonate
VoIP. Nel caso invece si vogliano intercettare flussi di dati, questa parte del sistema
può essere costituita da un DHCP server, al quale si richiede l’IP assegnato a un
particolare cliente posto sotto sorveglianza. Un altro tipo di IRI-IAP può essere un
server di autenticazione RADIUS. Se l’IRI-IAP utilizzato non prevede la possibilità di
essere interrogato da un MD, bisognerà dotare l’MD di uno sniffer (sulle interfacce (c)
ed (e)), che tenga traccia dell’attività dell’IRI-IAP.
5) Content Intercept Access Point (Content-IAP) è un componente solitamente
costituito da un router o da una scheda installabile su di un particolare apparato di
rete, che è in grado di duplicare il traffico che soddisfa una particolare regola
(Source/Destination IP, Source/Destination Port, ecc.). Questa regola (nei prodotti
Cisco) viene impostata tramite il protocollo SNMPv3 (interfaccia (d)), che possiede
autenticazione. I contenuti intercettati (nei prodotti Cisco) vengono poi spediti al MD
(interfaccia (f)) tramite il protocollo PacketCable UDP. Questo quando non c’è
bisogno di garanzia di recapito del contenuto; quando invece bisogna garantire il
recapito del contenuto si utilizza il protocollo RTP-NOR (RealTime Transfer Protocol
– Nack Oriented Retransmission). Sia che si utilizzi il protocollo PacketCable UDP,
sia che si utilizzi l’RTP-NOR, il flusso di pacchetti intercettato viene criptato mediante
IPsec, per garantire l’integrità, l’autenticità e la sicurezza delle informazioni trasmesse
dal Content-IAP al MD.
© 2009 M3S srl
5
1.2 Descrizione delle
dell’architettura
interfacce
tra
le
diverse
parti
a) Handover Interface 1 (HI1) è l’interfaccia tramite la quale l’autorità giudiziaria (LEA)
fornisce al service provider le informazioni relative all’obbiettivo dell’intercettazione.
b) Mediation Device provisioning interface è l’interfaccia dalla quale vengono forniti
al Mediation Device (in un opportuno formato) i parametri relativi all’intercettazione,
quali identificatore di chi deve essere intercettato, durata dell’intercettazione, tipo
dell’intercettazione, ecc.
c) IRI-IAP Provisioning è l’interfaccia tramite la quale vengono forniti all’entità IRI-IAP i
dati dell’obbiettivo dell’intercettazione (identificatore dell’intercettato, durata, ecc.).
d) Content Intercept Provisioning è l’interfaccia attraverso cui vengono forniti al
Content-IAP i parametri necessari alla costruzione della regola, che, se viene
soddisfatta da un pacchetto, provoca la duplicazione di quest’ultimo e l’invio al
Mediation Device tramite l’interfaccia (f).
e) IRI Interface è l’interfaccia tramite la quale l’IRI relativo alla richiesta effettuata
attraverso l’interfaccia (c) viene recapitato al Mediation Device.
f)
Intercepted Content Interface è l’interfaccia attraverso cui vengono inviati al
Mediation Device i pacchetti intercettati e duplicati dal Content-IAP.
g) Handover Interface 2 (HI2). Per mezzo di questa interfaccia vengono inviati alle
forze dell’ordine (LEA) le IRI intercettate. L’implementazione di questa interfaccia può
variare a seconda del paese in cui viene impiegata.
h) Handover Interface 3 (HI3). Tramite questa interfaccia vengono inviate al LEA i
contenuti delle intercettazioni attivate. L’implementazione di questa interfaccia può
variare a seconda del paese in cui viene impiegata.
Si noti che gli IRI e i contenuti delle intercettazioni vengono recapitati al LEA mediante 2
interfacce distinte ((g) e (h)). Questa scelta è stata fatta in modo che l’autorità giudiziaria
possa predisporre l’intercettazione o delle sole IRI, o dei soli contenuti, oppure di entrambi.
1.3 Intercettazione voce
Vediamo ora, a scopo esemplificativo, le fasi di intercettazione del traffico voce su rete ip,
utilizzando un’implementazione dell’architettura specificata da Cisco nell’RFC 3924.
1) il LEA fa una richiesta di intercettazione al provider attraverso l’interfaccia HI1;
2) il provider predispone l’intercettazione attraverso il MD tramite l’interfaccia (b); a
questo punto il MD istruisce (attraverso l’interfaccia (c)), il gatekeeper (IRI-IAP) a
passargli le IRI relative al soggetto posto sotto sorveglianza (tramite l’interfaccia (e));
3) il soggetto posto sotto intercettazione viene chiamato, utilizzando un certo protocollo
di segnalazione (es. H.323), tramite il gatekeeper (l’IRI-IAP). Il gatekeeper passa le
IRI (indirizzo IP di destinazione e porta di destinazione) al MD tramite l’interfaccia (e).
Il MD scopre così la “posizione” del soggetto intercettato all’interno della rete;
4) il MD a questo punto può sapere su quale router (Content-IAP) della rete predisporre
l’intercettazione, e la predispone mediante l’interfaccia (d);
5) a questo punto il MD può inviare i dati acquisiti tramite le interfacce (e) ed (f) al LEA,
per mezzo delle rispettive interfacce HI2 e HI3.
© 2009 M3S srl
6
1.4 Prodotti Cisco
Le famiglie di prodotti Cisco, che supportano la LI, da noi visionate sono principalmente 3:
- Router Serie 10000
- Router Serie 12000
- Universal Gateway Serie AS5000.
Un altro prodotto molto interessante di Cisco è il Content Service Gateway (CSG).
Il CSG è una scheda aggiuntiva per i prodotti Switch Catalyst® Serie 6500 e Router Serie
7600. Questo prodotto è nato per fare attività di billing, in base al tipo di contenuti che
vengono fruiti dall’utente finale, ma supporta anche la LI, ed è in grado di effettuare
intercettazioni in 2 modi:
- Duplicazione del traffico
- SMTP e POP3 data mining (intercettazione del traffico mail di un particolare indirizzo)
Tutti questi apparati per gestire le intercettazioni fanno uso del modulo
Cisco – TAP – MIB.
Tale modulo contiene gli SNMP management objects per controllare intercettazioni e tramite
esso il MD può configurare il router per duplicare l’opportuno traffico.
Per compiere le intercettazioni il TAP – MIB crea all’interno della memoria del router le
seguenti tabelle:
-
cTapMediationTable: è una tabella che contiene le informazioni riguardanti i MD che
stanno compiendo intercettazioni attraverso questo router. Ogni entry della tabella
contiene le informazioni necessarie per comunicare con un certo MD, che sono
l’indirizzo dell’MD, le interfacce fisiche attraverso le quali mandare i dati intercettati e
il protocollo da utilizzare per inviare questi ultimi;
-
cTapStreamIpTable: è una tabella che contiene le informazioni usate per identificare
il traffico da intercettare. Ciascuna entry della tabella contiene un puntatore ad un
filtro, che è utilizzato per identificare il traffico posto sotto sorveglianza. Una volta
identificato il traffico, viene duplicato e inviato all’opportuno MD, il cui riferimento è
contenuto
nell’oggetto
cTapMediationContentId,
che
insieme
all’oggetto
cTapStreamIpIndex sono indice della tabella;
-
cTapDebugTable: è una tabella che contiene le entry riguardanti gli errori, generati
dal sottosistema di lawful interception del router.
L’amministratore del sistema di sorveglianza per predisporre un’intercettazione deve eseguire
le seguenti operazioni:
1) creare una entry nella tabella cTapMediationTable, per definire come il router deve
comunicare con il MD al fine di inviargli il traffico intercettato;
2) creare una entry nella tabella cTapStreamIpTable per identificare il traffico da
intercettare;
3) settare il valore dell’oggetto booleano cTapStreamIpInterceptEnable a true per
iniziare l’intercettazione. Il router provvederà ad intercettare il traffico finché
l’intercettazione non andrà in timeout. Il valore di timeout è specificato dall’oggetto
cTapMediationTimeout.
© 2009 M3S srl
7
2 Standard ETSI TS 101 671
Lo standard, che si prenderà in esame, è quello europeo ETSI TS 101 671.
Esso prevede come debbano essere realizzate le tre Handover Interfaces (HI1, HI2, HI3), a
seconda del tipo di rete su cui si vogliono effettuare intercettazioni legali.
Le tipologie di reti, a cui si farà riferimento, sono le reti basate sul protocollo IP, anche se
parte dello standard dedicato a queste reti è ancora in via di definizione .
Questo standard però non definisce le altre interfacce indicate dalla Cisco nell’RFC 3924, che
sono indicate con la sigla INI (Internal Network Interface).
Le parti ancora in via di definizione dello standard sono le seguenti:
-
B.3.2 – Exception Handling
-
B.3.3 – Security aspects
-
B.4 – HI3: interface port for Content of Communication.
Le specifiche che seguiranno, dovranno essere utili all’implementazione di un sistema per la
lawful interception su reti IP, che funzioni sotto Linux. La specifiche del sistema da
implementare saranno definite all’interno di questo documento.
Per ogni interfaccia (soprattutto quelle elettroniche HI2 e HI3) si deve garantire:
-
riservatezza
-
integrità
-
autenticazione
-
disponibilità
I primi 3 punti sono facili da soddisfare, usando ad esempio una distribuzione free-software
di SSL. Per la disponibilità invece si deve stipulare un contratto di servizio tra le LEAs e il
gestore di rete, oppure si deve provvedere con una normativa nazionale.
2.1 Identificatori per la Lawful Interception
In questo paragrafo verranno definiti tutti gli identificatori usati all’interno del sistema per la
Lawful Interception, utili per la progettazione del Database e le applicazioni del sistema.
Per ogni soggetto sottoposto ad intercettazione, l’operatore di rete in accordo con il LEA
assegna un identificatore univoco (LIID = Lawful Interception IDentifier), che verrà
successivamente utilizzato come parametro all’interno dei pacchetti (inviati tramite le porte
HI), che riguarderanno il soggetto posto sotto sorveglianza elettronica.
Il LIID è una sequenza non vuota di caratteri alfanumerici, che può contenere ad esempio il
numero e la data dell’autorizzazione all’intercettazione, la scadenza dell’intercettazione, ecc.
Utilizzando questo LIID, si garantisce che l’informazione, riguardante l’identità
dell’intercettato, resti circoscritta agli operatori autorizzati del gestore di rete, e agli agenti
del LEA interessati all’indagine.
Il LIID è necessario per correlare gli IRI inviati tramite l’interfaccia HI2 e i CC (Comunication
Content) inviati tramite la HI3.
Il gestore della rete autorizzato ad assegnare gli LIID può assegnarne uno per ogni
© 2009 M3S srl
8
intercettazione attiva, o, se previsto da un regolamento nazionale, assegnarne uno unico,
che identifichi persona (fisica o giuridica) posta sotto sorveglianza, indipendentemente da
quali entità si debbano intercettare, che nello standard sono chiamate “target identities” (es.
stesso LIID per telefono fisso, cellulare e e-mail).
Se più di una LEA sta effettuando intercettazioni su una stessa entità (es. stesso telefono, o
stesso pc), l’entità dovrà avere un unico LIID assegnato. Questo vincolo mette in evidenza la
necessità che gli LIID vengano assegnati o da un solo operatore (es. l’ex incumbent) oppure
da una autorità centrale.
Per ogni attività rilevante effettuata dall’entità posta sotto sorveglianza, deve essere
generato un CID (Comunication IDentifier), che identifica la specifica attività e il tipo di
attività. Un esempio può essere una particolare telefonata, una particolare e-mail, un
particolare SMS, o altro.
Il CID è utilizzato per correlare i records IRI con i CC. Il formato del CID è specificato
nell’appendice D dello standard.
IL CID è composto da due parti:
-
Network Identifier (NID);
-
Comunication Identity Number (CIN): questa parte è opzionale.
Il NID è a sua volta composto da 2 parti:
-
NWO/AP/SvP – identifier, parte obbligatoria che identifica univocamente il particolare
operatore di rete, access provider o service provider;
-
Network Element IDentifier (NEID), parte opzionale, che identifica l’elemento di rete
che sta effettuando le operazioni di intercettazione; questo identificatore nel caso di
reti basate su protocollo IP è l’indirizzo IP dell’interfaccia dell’apparato.
Il CIN è l’identificatore che permette di raggruppare tutte le comunicazioni effettuate
all’interno della stessa sessione, da una certa entità posta sotto sorveglianza.
Il CIN si rende obbligatorio quando si intercettano gli IRI, nel caso in cui si vogliano riportare
gli eventi di una comunicazione orientata alla connessione (es. comunicazioni su rete
commutata).
2.2 Handover Interface port 1 (HI1)
In questo paragrafo verranno date le specifiche tecniche e di funzionamento dell’interfaccia
HI1.
Questa interfaccia è tipicamente di tipo bi-direzionale e può essere sia di tipo “manuale”, che
di tipo elettronico, essa è necessaria in quanto è richiesta una completa separazione tra la
parte amministrativa (HI1) e la parte tecnica (INI). Quindi il LEMF (Law Enforcement
Monitoring Facility) non ha mai la possibilità di configurare direttamente il Mediation Device
del provider, al fine di attuare una o più intercettazioni senza che il provider ne venga a
conoscenza.
Il LEA deve inviare al Network Manager del provider, tramite l’interfaccia HI1, le seguenti
informazioni:
-
© 2009 M3S srl
identificativo dell’entità da intercettare (es. numero di telefono, indirizzo, dati
anagrafici, ecc.)
9
-
identificativo dell’intercettazione concordato (LIID)
-
inizio e fine (o durata) dell’intercettazione
-
tipo di informazioni da intercettare (IRI, IRI e contenuti)
-
indirizzo di destinazione dei dati inviati tramite l’interfaccia HI2, ossia dove mandare i
record-IRI (se applicabile).
-
indirizzo di destinazione dei dati inviati tramite l’interfaccia HI3, ossia dove mandare i
contenuti dell’intercettazione (CC)
-
altri parametri dipendenti dalla rete (es. sistemi di recapito usati dalle interfacce HI2
e HI3)
-
autorizzazione per procedere all’intercettazione (firma del magistrato)
-
un contatto tecnico da utilizzare in caso di problemi riguardanti l’avvio e l’esecuzione
dell’intercettazione
-
altre informazioni richieste.
Nel caso l’interfaccia sia di tipo “manuale”, il LEA deve mandare al centro di amministrazione
del provider la richiesta di intercettazione via posta o via fax. Gli addetti alla gestione della
Lawful Interception del provider provvederanno quindi all’attivazione dell’intercettazione. Una
volta attivata l’intercettazione, il LEMF riceverà una notifica riguardo l’attivazione attraverso
l’interfaccia HI2 e si predisporrà a ricevere gli IRI sempre attraverso l’interfaccia HI2 e i
contenuti attraverso l’interfaccia HI3.
Nel caso l’interfaccia sia di tipo elettronico, il Network Manager del provider dovrà sempre
dare un suo consenso all’attivazione dell’intercettazione; implementando in questo modo la
HI1 si riducono notevolmente le possibilità di errore umano, sia da parte degli addetti del
LEMF, sia da parte degli addetti alla rete del provider.
Il provider è tenuto, tramite l’interfaccia HI2, a notificare al LEMF i seguenti eventi:
-
attivazione di un’intercettazione
-
disattivazione di un’intercettazione
-
modifica di un’intercettazione attiva
-
occorrenza di situazioni eccezionali
Il formato dei messaggi di notifica, se viene utilizzato il protocollo ROSE, è specificato
nell’appendice D.4 dello standard, codificato nei linguaggi ASN.1 e BER.
In questo paragrafo verranno date le specifiche tecniche e di funzionamento dell’interfaccia
HI2.
Attraverso questa interfaccia vengono spediti gli IRI (es. informazioni provenienti da
signaling) al LEMF.
La trasmissione delle informazioni deve essere fatta attraverso metodi di comunicazione
adeguati alla mole di dati da trasmettere, utilizzando protocolli standard o già ampliamente
usati nel mondo delle telecomunicazioni (es. TCP/IP). Nessun vincolo è posto per i livelli più
bassi di comunicazione, che devono essere stabiliti dal provider in accordo con le LEAs.
Come protocolli applicativi lo standard specifica utilizzare, per questa porta, o il ROSE o l’FTP
© 2009 M3S srl
10
(appendice C), mentre per il livello di presentazione le BER.
Ciascun parametro che compone l’IRI deve essere codificato usando l’ASN.1 e le BER. Il
formato dei valori dei parametri deve essere basato, se possibile, sugli standard di
comunicazione esistenti, dove questi parametri sono utilizzati. Tipicamente questi parametri
standard sono definiti come stringhe di ottetti.
Gli IRI devono essere mandati, uno ad uno, non appena possibile al LEMF (rispettando i
vincoli imposti dalle normative nazionali). Solo in caso di problemi di comunicazione sulla
porta HI2 può essere fatto il “buffering” degli IRI, per mandarli successivamente in forma
aggregata.
Gli IRI records devono contenere le informazioni messe a disposizione dalle normali reti e
dalle normali procedure di rete; ad esempio le informazioni messe a disposizione dai
protocolli di signaling, dal protocollo DHCP, da un server RADIUS, dai log dei routers, ecc; a
queste informazioni devono essere aggiunte quelle per l’identificazione (CID) e il controllo dei
dati (sicurezza), richiesti dalla porta HI2.
Non è quindi necessario specificare l’apparato che fornisce le informazioni, perché non è
possibile richiedere informazioni extra, che non siano già state messe a disposizione dai
protocolli di segnalazione o da altri protocolli.
Gli IRI possono essere convogliati al LEMF tramite messaggi (ROSE) o IRI data records
(FTP).
Sono definiti quattro tipi di IRI records:
1) IRI-BEGIN record, che viene generato al primo evento di un tentativo di connessione,
aprendo la transazione IRI (es. composizione dei un numero telefonico o apertura di
un socket);
2) IRI-END record, che viene generato alla fine di una comunicazione o di un tentativo
di comunicazione, chiudendo la transazione IRI (es. riaggancio della cornetta o
chiusura di un socket);
3) IRI-CONTINUE record, che viene sempre generato durante la comunicazione o il
tentativo di comunicazione, all’interno di una transazione IRI;
4) IRI-REPORT record, che viene generato durante gli eventi di non-comunicazione,
come gli SCI (Subscriber Controlled Input) (es. attivazione del call-forwarding,
attivazione di altri servizi da parte dell’utente, ecc.).
Questi tipi di records sono stati definiti indipendentemente dal tipo di eventi di
comunicazione che saranno generati, e quindi indipendentemente da cosa si dovrà
intercettare (es. telefonata, e-mail, instant messaging, ecc.).
La parte B.3 dello standard definisce, per le reti a commutazione di pacchetto, in quali fasi
della trasmissione da intercettare debbano essere disponibili le IRI.
Queste fasi sono:
1) il tentativo di connessione, quando cioè l’entità da intercettare diventa attiva, sia che
generi o non generi pacchetti (richiesta al DHCP dell’indirizzo IP, ecc.);
2) la chiusura della connessione, quando cioè l’entità da intercettare diventa inattiva;
3) la disponibilità, ad un certo istante, di informazioni rilevanti (es. assegnamento di un
nuovo IP, ecc. ).
In più devono essere generati degli IRI record per gli eventi di non trasmissione (es. SCI),
© 2009 M3S srl
11
generati dall’entità posta sotto sorveglianza.
Infine gli IRI possono essere divisi in 2 categorie:
1) Informazioni di controllo per HI2 (es. LIID, CID, ecc.);
2) Informazioni basilari per la trasmissione di dati tra due parti, di cui una è posta sotto
sorveglianza (es. numero di telefono chiamato/chiamante, source/destination IP, ecc).
In questo paragrafo si cercherà di fornire le specifiche dell’interfaccia HI3, anche se lo
standard attuale non copre la presente interfaccia per le reti a commutazione di pacchetto.
Si cercherà quindi di trovare una soluzione di semplice soluzione al problema, al fine di
fornire delle specifiche utili all’implementazione del sistema di lawful interception su
piattaforma Linux. Per la scrittura della specifiche si prenderà spunto da ciò che lo standard
definisce a riguardo della porta HI3 per il GPRS (Appendice F).
Lo standard definisce che i contenuti dell’intercettazione (CC) devono essere inviati al LEMF,
come una copia del flusso di dati, che l’entità posta sotto sorveglianza invia al suo
interlocutore; questo flusso, se cifrato dal provider, o deve essere decifrato prima di essere
spedito al LEMF, oppure devono essere fornite al LEA le chiavi per decifrare il contenuti
intercettati.
Qui si pone subito un interrogativo, in quanto, se si intercetta il traffico IP proveniente da un
personal computer collegato a internet, non si avranno tutti i mezzi per decifrare i pacchetti
cifrati direttamente dal soggetto posto sotto sorveglianza. Basti pensare al traffico cifrato con
SSL e al traffico Skype (protocollo proprietario cifrato), per capire perché lo standard attuale
non copra completamente il tipo di reti su cui può girare il protocollo IP.
Secondo lo standard l’implementazione della porta HI3 deve essere adeguata al tipo di
contenuti da intercettare.
Quindi, se si vuole intercettare del traffico internet, una connessione ethernet a 100 mbit/s
con protocollo IP, verso il LEMF, dovrebbe essere sufficiente a gestire il traffico generato da
5 o 6 utenze a 10 mbit/s, su cui si vuole fare intercettazione dei CC.
Per rendere possibile la correlazione dei CC con gli IRI la specifica suggerisce (per il GPRS) di
aggiungere il seguente header al pacchetto originale (detto GLIC header):
Octets
1
2
3-4
5-6
7-8
9
10
11
12
13-20
8
7
6
Version ("0 0 0")
5
"1"
Bits
4
Spare
"1"
3
GSN
type
2
1
DIR
"0"
Message Type (value 255)
Length (lunghezza pacchetto incapsulato)
Sequence Number
not used (value 0)
not used (value 255)
correlation number
DIR = 0, se il pacchetto è diretto all’intercettato; 1 , se il pacchetto è mandato dall’intercettato
Nota: I campi che vengono usati nel GPRS e che non verrebbero utilizzati nelle reti IP sono
stati barrati
© 2009 M3S srl
12
Nell’implementazione il correlation number potrebbe essere eliminato in quanto la
correlazione tra i CC e gli IRI, in una rete basata su IP, è già garantita dagli headers del
protocollo utilizzati sopra l’IP. Il Message Type invece di essere fisso a 255, potrebbe essere
utilizzato per indicare il protocollo applicativo che si sta intercettando.
Tutto questo traffico così etichettato verrebbe poi inviato al LEMF attraverso UDP oppure
TCP, a seconda della normativa nazionale e/o dei requisiti delle diverse LEAs.
Qui si evidenzia il fatto che su di una rete basata su IP, il numero di protocolli, che si
utilizzano sopra IP per trasporto, sessione e applicazione, può essere anche molto grande.
Ne deriva la necessità di un’architettura di tipo modulare per l’implementazione del sistema,
suddivisa per protocollo applicativo (http, ftp, dns, smtp, ecc).
Dalla parte del LEA si dovrebbe provvedere a decodificare il contenuto dei pacchetti
intercettati, utilizzando il modulo specifico per un certo protocollo applicativo. Si dovranno
quindi memorizzare i contenuti in un’opportuna struttura per il salvataggio dei dati; se ad
esempio si intercetta del traffico http, si possono immagazzinare tutte le stringe delle URL
visitate dal soggetto posto sotto sorveglianza, in un’opportuna tabella di un database
relazionale, corredata magari di due campi clob dove memorizzare i contenuti della pagina e
la richiesta inviata dall’intercettato (cosa necessaria quando si intercettano pagine
dinamiche).
In caso di disservizio sul canale di comunicazione verso il LEMF, si potrebbe attuare una
politica non eccessivamente onerosa per il gestore di rete (come suggerito dallo standard a
riguardo del GPRS), ossia si potrebbe “bufferare” il contenuto delle intercettazioni per un
certo tempo, dopo il quale, se il canale di comunicazione non avesse ripreso a funzionare,
buttare via i dati provenienti dalle intercettazioni in atto.
3 Un sistema di Lawful Interception basato su
componenti free-software
Questo paragrafo si rende necessario, in quanto non si sono trovati progetti OpenSource,
che implementino una valida infrastruttura per attuare la Lawful Interception. Si è trovato
però un sito internet (http://www.opentap.org/), dove viene proposta l’idea di realizzare
un’infrastruttura di Lawful Interception OpenSource per gli ISP olandesi. L’attività del sito
risulta però ferma alla fine del 2002.
Si è trovato un discreto numero di fornitori di Mediation Device (MD). I riferimenti di queste
aziende e dei loro prodotti specifici per la Lawful Interception sono stati tratti dal sito
http://www.gliif.org/.
Si farà ora una sommaria descrizione dei componenti del sistema da sviluppare, con i relativi
riferimenti ai progetti OpenSource utilizzabili per rendere più veloce l’implementazione del
sistema. Si seguirà l’architettura indicata da Cisco nell’RFC 3924.
Content – IAP:
Questo componente può essere facilmente realizzato mediante una macchina Linux con due
o più interfacce di rete, e con hardware adeguato al traffico che deve gestire. Come software
per il routing si può utilizzare NetFilter, con il quale si può effettuare anche la duplicazione
del traffico.
Su questa macchina si dovrà provvedere a installare un demone SNMPv3, che gestisca le
richieste di duplicazione del traffico (che in seguito chiameremo “di creazione del TAP”)
provenienti dal MD. Per quanto riguarda il demone SNMPv3, se ne può scegliere
© 2009 M3S srl
13
l’implementazione opportuna all’indirizzo
http://www.ibr.cs.tu-bs.de/projects/snmpv3/, queste implementazioni sono sia a pagamento,
sia free.
Si dovrà poi provvedere, una volta ricevuti i messaggi SNMP, a istruire NetFilter con la regola
opportuna per intercettare e duplicare il traffico posto sotto sorveglianza. Una volta
intercettato e duplicato il traffico, si dovrà provvedere a incapsularlo all’interno di un
datagram UDP, e inviarlo al Mediation Device .
Tutto questo dovrà avvenire per un arco temporale specificato dalla richiesta di
intercettazione, che viene inviata al provider dal LEA attraverso HI1.
IRI – IAP:
Questo componente, come già detto, può essere un server DNS, o un gatekeeper, o un
server DHCP, o un server RADIUS, ecc.
Questo componente dovrà essere configurabile dal MD, e, nel caso non lo fosse, il Mediation
Device (con l’opportuno modulo) dovrà tenere traccia delle richieste verso l’IRI-IAP. Tutto
questo dovrà avvenire per un arco temporale specificato dalla richiesta di intercettazione,
che viene inviata al provider dal LEA attraverso HI1.
Se l’IRI-IAP è configurabile dal MD, in maniera da riportare le informazioni richieste al MD
non appena disponibili (es. richiesta DNS eseguita da un particolare cliente posto sotto
sorveglianza), si riesce ad evitare al MD un continuo lavoro di analisi del traffico verso l’IRIIAP, permettendo così al MD di poter gestire un numero di intercettazioni maggiore.
Si rende necessaria, in questo caso, una personalizzazione dei prodotti OpenSource per
renderli utilizzabili dal MD; operazione non particolarmente lunga e complessa, vista la
disponibilità dei codici sorgenti.
Di seguito sono riportati alcuni possibili server OpenSource utilizzabili e i relativi riferimenti.
Nome Progetto
Tipo di Server
Sito Internet
Radius
OpenRADIUS
http://www.openradius.org/
DNS
BIND
http://www.isc.org/index.pl?/sw/bind/
DHCP
DHCP (Internet Systems Consortium)
http://www.isc.org/index.pl?/sw/dhcp/
Gatekeeper
H.323
OpenH323 Gatekeeper
Gatekeeper
http://www.gnugk.org/
-
The
GNU
Mediation Device:
Questo è il componente chiave di tutto il sistema, esso determina la capacità del sistema di
compiere o meno un determinato tipo di intercettazione.
Come già detto nel paragrafo precedente, questo componente deve essere realizzato per
moduli, ognuno dei quali conferisce ad esso la capacità di intercettare un determinato
protocollo applicativo.
Ciascun modulo dovrà provvedere alle seguenti funzioni:
-
© 2009 M3S srl
ad una richiesta dell’amministratore riguardo ad una nuova intercettazione, il MD
deve generare l’opportuna regola, da mandare via SNMPv3 all’apparato che si trova
sul percorso dei dati, e che sia in grado di effettuare la duplicazione del flusso di
pacchetti utile all’indagine;
14
-
interrogare o monitorare l’opportuno IRI-IAP;
-
inviare i dati opportunamente impacchettati e “taggati” al/ai LEMF(s), secondo le
specifiche sopra riportate per le porte HI2 e HI3.
Riferimenti
© 2009 M3S srl
1.
Handover Interface for the Lawful Interception of Telecommunications Traffic, ETSI ES-201-671,
under Lawful Interception, Telecommunications Security, version 3.1.1, May 2007.
2.
Handover Specification for IP delivery, ETSI TS-102-232-1, under Lawful Interception,
Telecommunications Security, version 2.1.1, December 2006.
3.
Lawfully Authorized Electronic Surveillance, T1P1/T1S1 joint standard, document number J-STD025B, December 2003.
4.
3rd Generation Partnership Project, Technical Specification 3GPP TS 33.106 V5.1.0 (2002-09),
“Lawful Interception Requirements (Release 5),” September 2003.
5.
“Lawful interception architecture and functions (Release 6),” September 2003.
6.
“Handover interface for Lawful Interception (Release 6),” September 2003.
7.
PacketCable Electronic Surveillance Specification, PKT-SP-ESP-I03-040113, Cable Television
Laboratories Inc., 13 January 2004.
8.
T1.678, Lawfully Authorized Electronic Surveillance (LAES) for Voice over Packet Technologies in
Wireline Telecommunications Networks.
9.
RFC 2924, Cisco Architecture for Lawful Intercept in IP Networks
15

Architetture e standard per le intercettazioni legali

Transcript

Documenti analoghi

Attento! Il cellulare ti spia

Testo Regolamento Modalità tecniche di esecuzione delle

Figura 1-6: Immagine dell`interfaccia del Norton Antivirus, in questa

IL PROGRESSO SCIENTIFICO-TECNOLOGICO NEL PANORAMA

Product datasheet

Idra u lic a 174 Dighe SCARICHI SOTTO BATTENTE Introduzione

l`INDICE del volume

ultimo numero il 10 luglio

Introduzione a Wireshark

Permettere ad utenti non esperti di eseguire procedure di STATA