Negli ultimi due mesi mi sono state poste molte domande che riguardano i cosiddetti “tabulati telefonici” e la loro analisi. Come d’abitudine, riporto qui di seguito il poco che so di questo argomento, in modo da non dover rispondere singolarmente ad ogni domanda. Se avete qualcosa da aggiungere, o se vedete errori da correggere, usate il sistema dei commenti qui sotto.

Cos’è un “tabulato telefonico”?

L’oggetto che in Italia viene chiamato “tabulato telefonico” è noto in tutto il resto del mondo (e nel settore dell’analisi forense) con il nome di CDR: Call Detail Records (“Registrazione dei Dettagli delle Chiamate”). Lo trovate descritto qui:

https://secure.wikimedia.org/wikipedia/en/wiki/Call_detail_record

Questo oggetto è, in buona sostanza, un documento che contiene l’elenco di tutte le chiamate effettuate da un certo telefono in un certo arco di tempo. In generale, contiene queste informazioni:

Il numero chiamante
Il numero chiamato
Data ed ora (secondi compresi) dell’inizio della conversazione
Durata della conversazione
L’identificativo della centrale telefonica che ha registrato l’evento
Un numero che identifica l’evento (cioè la connessione)
Il risultato della chiamata (numero occupato, connessione stabilità, connessione rifiutata, mancata risposta, etc.)
L’identificativo della “torre” radio di ingresso
L’identificativo della “torre” radio di uscita
Il tipo di chiamata (voce, SMS, etc.)

In Italia questo documento si chiama ancora “tabulato” in memoria di quando si trattava effettivamente di un documento cartaceo diviso in righe e colonne e cioè, appunto, “tabulato”. Al giorno d’oggi si tratta quasi sempre un file che viene inviato per posta elettronica o piazzato su qualche tipo di supporto (CD, chiavetta USB, etc.).

I “campi” del tabulato

Non esiste nessuno standard, né de jure né de facto, che definisca quanti e quali campi (“colonne”) devono essere presenti in un tabulato telefonico e cosa debbano contenere. Quelli che ho nominato sopra sono solo un esempio molto generico. L’unico modo di sapere quali campi sono presenti e cosa significano consiste nel chiederlo a chi ha generato il file (l’impiegato della compagnia telefonica).

Il campo che subisce più maltrattamenti è probabilmente quello degli identificatori di cella. In Italia, quasi tutti gli operatori identificano le singole celle (le “torri radio”, “stazioni radio” o, in inglese, “radio base station”) con un nome descrittivo come “origgio” o “pastorano”. Ne potete vedere una lista abbastanza rappresentativa qui:

http://www.towerco.it/locator/lista_siti.html

Non mancano però casi di aziende telefoniche che preferiscono usare identificativi numerici in sequenza (288, 289, etc.) o codici di altro tipo (AD987, TR345, etc.). In alcune nazioni, caratterizzate da grandi distese semideserte, come gli Stati Uniti, la Russia e la Cina, alcune compagnie telefoniche preferiscono addirittura inserire nei tabulati direttamente le coordinate geografiche della torre (28° 29′ 20″ N, 80° 34′ 40″ W).

In generale, quindi, oltre al tabulato telefonico, è necessario possedere anche un elenco delle celle telefoniche e delle loro posizioni geografiche (che va richiesto ai gestori…).

Tabulati telefonici e Bollette

Una variante del CDR è lo SMDR:

https://secure.wikimedia.org/wikipedia/en/wiki/SMDR

La principale differenza tra questi due tipi di documento è il loro impiego: il CDR viene utilizzato internamente dalle compagnie telefoniche e contiene tutti (o quasi) i dati disponibili. Lo SMDR, invece, è destinato agli utilizzatori finali e contiene solo le informazioni che essi possono comprendere e che possono essere utili per analizzare la bolletta. Insomma: il documento che ricevete per posta dalla compagnia telefonica insieme alla bolletta è un SMDR. Il “tabulato telefonico” che usa la Polizia per le indagini è un CDR.

BAF ed EBAF

Sempre sotto il nome di “tabulato telefonico” può succedere di imbattersi in altri due tipi di documento, il BAF (Billing AMA Format) e l’EBAF (Extended Billing AMA Format). Entrambi questi tipi di documento sono in realtà degli SMDR usati per emettere le bollette e derivano in vari modi da un comune formato noto come AMA (Automatic Message Accounting):

https://secure.wikimedia.org/wikipedia/en/wiki/Automatic_Message_Accounting

Gran bella cosa gli standard…

A questo punto avrete già capito che in questo particolare ramo del business telefonico regna il più totale CASINO. Non esiste uno standard de jure o de facto che definisca il formato dei CDR. Ogni operatore (Telecom, Vodafone, etc.) e persino ogni impiegato fa quello che ritiene più opportuno.

Non solo: i CDR non vengono quasi mai rilasciati al pubblico (nemmeno alla Polizia) nel loro formato nativo. Piuttosto, vengono scambiati tra macchine, tra reti e tra operatori attraverso un complesso meccanismo chiamato “mediazione”. Solo alla fine di questo lungo processo vengono trasformati in qualcosa che possa risultare comprensibile al software usato dalla Polizia.

CSV, TSV, Excel, MDB, SQL ed altre bestie

Quasi sempre, questo “qualcosa” è un file in formato CVS (Comma Separated Values) o qualcosa di simile. Tra gli altri formati usati per questo scopo si possono citare:

TSV (Tab Separated Values)

.XSL (il formato nativo di MS Excel)

.MDB (il formato nativo di MS Access/Jet)

.TXT (un “non formato” fonte di interminabili casini)

XML (non lo usa quasi nessuno)

SQL (cioè il “dump” di un database in formato SQL)

La fantasia (ed il sadismo) degli impiegati delle TelCo però non si ferma certo a questo. Mi hanno raccontato persino di un “tabulato telefonico” passato al perito della difesa sotto forma di immagine grafica bitmap in formato MS .BMP (oltre 40 Mb di roba…). Evidentemente si trattava del risultato della (goffa) acquisizione da scanner di qualche documento cartaceo…

Martello, scalpello e SQL

Il risultato finale è che il tecnico incaricato delle indagini (di solito un Agente od un Sottufficiale di Polizia) ed il perito della difesa devono “smazzarsela” a suon di SQL e/o di “convertitori” fatti a mano in Perl, Python, Ruby o Basic.

Si cerca di convertire (in un modo o nell’altro) il “tabulato” ad un formato che sia comprensibile a qualche programma di largo impiego, come MS Access o MS Excel, e poi lo si esamina usando quel programma. Per poterlo fare, bisogna riuscire a produrre (od a farsi fornire) un file .CSV, .XLS o .MDB. Può andar bene (anzi: benissimo) anche un “dump” SQL ma è raro essere così fortunati.

A cosa serve l’analisi dei tabulati?

L’analisi dei tabulati telefonici serve essenzialmente a due cose: stabilire (a grandi linee) dove si trovava una persona in un certo momento e capire con chi aveva a che fare.

Come ho già detto, il “tabulato” contiene l’ID della torre radio di ingresso e di quella di uscita. Di conseguenza, dal tabulato è sempre possibile capire se una persona di nome “Mario Rossi” si trovava a Roma nel momento in cui ha chiamato il “Signor Filippo Verdi” a Napoli. Ovviamente, se entrambe queste persone si trovavano nell’area di copertura della stessa cella, ad esempio alla Garbatella di Roma, può essere difficile (od impossibile) capire a che distanza si trovavano l’uno dall’altro. L’area coperta da ogni cella, infatti, va da qualche centinaio di metri (nelle gallerie, nei centri commerciali e nelle aree urbane ad alta densità abitativa) a diversi chilometri. Non è quindi possibile stabilire la posizione di un telefono cellulare con una precisione sufficiente a dirimere certi dubbi investigativi.

Inoltre, dai tabulati telefonici è possibile capire che il Senatore Gianni MicaTeLoDoGratis è in contatto con il boss mafioso Saverio MaIoLoPago. Questa è la ragione per cui anche la semplice analisi dei tabulati (oltre alle intercettazioni audio) sta così antipatica ai politici ed agli affaristi.

La questione della localizzazione

Sui tabulati telefonici tradizionali NON è presente nessuna informazione che permetta di stabilire dove si trovava al momento della chiamata un certo telefono cellulare con una precisione superiore al raggio di copertura della cella (da 400 – 500 metri a 5 – 10 km). Insomma, si può capire se, al momento della chiamata, il telefono si trovava a Modena od a Bologna (che distano tra loro circa 40 km) ma non se si trovava a Casalecchio od a Borgo Panigale (che distano tra loro meno di 5 km in linea d’aria).

Questo va detto con chiarezza. Tuttavia, la questione non è così semplice e, soprattutto, non è destinata a restare così in eterno.

Triangolazione Radio

A certe, ben precise condizioni, che si verificano abbastanza raramente, è possibile stabilire la posizione del numero chiamante (e di quello chiamato) con una precisione di qualche decina o qualche centinaio di metri. Questo è possibile grazie alla cosiddetta “triangolazione radio”:

http://www.visivagroup.it/showthread.php?t=25043

In generale, però, questo è possibile solo se le “torri radio” sono state attrezzate e configurate in precedenza per svolgere questa funzione e questo avviene solo se c’è stata una richiesta da parte di un Magistrato. Diversamente questo dato non viene rilevato al momento della chiamata e non può quindi essere incluso nel CDR. Non si può fare la triangolazione radio “a posteriori”, cioè sui dati dei tabulati. Bisogna farla al momento della chiamata, agendo sui segnali radio mentre la chiamata è in corso.

Il 112 Europeo

In realtà, esiste una direttiva europea, già recepita dall’Italia, che prevede che le torri radio (le “celle”) debbano essere in grado di effettuare la triangolazione radio e di rilevare la posizione del telefono chiamante con una precisione piuttosto buona. Questa è stata una delle conseguenze della creazione di un numero unico europeo per le chiamate di emergenza (il numero telefonico “112”, già assegnato ai Carabinieri in Italia). Tutte le chiamate al 112, infatti, dovrebbero registrare automaticamente anche la posizione del numero chiamante, rilevata (almeno in teoria) anche con tecniche di triangolazione radio. Di conseguenza, tutte le torri radio dovrebbero essere configurate (sin dal 2006…) per svolgere anche questa funzione. Questa la teoria… La pratica è che siamo in Italia e non ci sono soldi neanche per la benzina delle Gazzelle…

I GPS

Il 112 europeo ancora non definisce nessun meccanismo per ottenere e registrare la posizione del telefono chiamante basandosi su un eventuale sistema GPS presente nello smartphone usato per la chiamata. Questo è dovuto al fatto che, più in generale, i telefoni di questa generazione e le centrali telefoniche esistenti non definiscono ancora nessun modo per raccogliere e registrare questi dati in modo automatico.

In questo momento, per far sapere a vostro padre dove vi trovate, dovete spedirgli manualmente un SMS che contiene le vostre coordinate, raccolte dal sistema GPS del vostro smartphone. Non c’è nessun sistema standard, e nessun sistema automatico, che possa farlo per voi al momento di una chiamata.

Questa situazione è però destinata a cambiare in futuro. Ci sono già diversi studi e diverse proposte che riguardano la creazione di un sistema di geolocalizzazione globale automatica delle chiamate telefoniche.

La geolocalizzazione (Google Latitude e simili)

I servizi di Geolocalizzazione come Google Latitude, ad esempio, si basano su una tecnica che potrebbe facilmente venir adottata anche da sistemi pubblici, come il 112 europeo, ma attualmente sono usati solo da aziende private come Google e Foursquare. Potete trovare una descrizione (in inglese) del funzionamento di Google latitude qui:

http://www.computerworld.com/s/article/9127462/FAQ_How_Google_Latitude_locates_you_

L’elemento chiave della questione è che deve esistere un server in grado di ricevere le informazioni geografiche dal telefono e di elaborarle (un server che, in questo momento, non esiste presso le grandi compagnie telefoniche). Inoltre, nei sistemi come Google Latitude è necessario avere una connessione UMTS o simili verso Internet contabilizzata a traffico, non a tempo, perché ogni pochi secondi il telefono deve contattare il server e passargli le informazioni necessarie alla localizzazione. Questo traffico lo paga il possessore del telefono.

La Cell Site Analysis

I tabulati telefonici normali (i CDR) contengono solo l’elenco delle chiamate effettivamente effettuate (anche non risposte) e degli SMS effettivamente inviati (anche se è fallita la consegna). Se il telefono resta inattivo (non effettua e non riceve chiamate, ma è acceso) risulta invisibile.

Esiste però un’altra tecnica, nota come “cell site analysis” che permette di “vedere” un telefono anche quando non fa e non riceve chiamate ed SMS. Questa tecnica si basa sul fatto che quando un telefono cellulare si sposta da una cella (una “torre radio”) alla successiva deve rinegoziare la connessione con la rete telefonica e quindi diventa visibile anche se non effettua nessuna chiamata. Non solo: ogni sei minuti (360 secondi) il telefono rinegozia la connessione anche se resta all’interno della stessa cella (questo perché la centrale telefonica deve sapere dove recapitare le richieste di connessione e gli SMS).

Basandosi sui “log file” delle celle è quindi possibile seguire gli spostamenti di un telefono anche se non fa e non riceve chiamate (alle sole condizioni che sia acceso e che ci sia la SIM inserita).

In Italia, però, la registrazione di questi log file normalmente è disattivata. Si tratta di un processo pesante per l’hardware e che produce quantità impressionanti di dati per cui gli operatori solitamente non effettuano queste registrazioni. La registrazione di questi dati avviene solo se c’è stata una richiesta di un Magistrato in precedenza (al fine di pedinare qualcuno usando il suo cellulare come dispositivo tracciante).

I telefoni fissi

Va da sé che la posizione di un telefono fisso è sempre nota con una precisione millimetrica: il telefono sicuramente si trova nel locale in cui il tecnico Telecom a suo tempo ha piazzato la “borchia” telefonica od in uno dei locali attigui…

Tutti i discorsi che abbiamo fatto sulla localizzazione del telefono chiamante (e chiamato) sono superflui in questo caso.

Come si effettua l’analisi dei tabulati?

Ed adesso veniamo al cuore del problema. Come si analizza un “tabulato telefonico”?

Come ho già spiegato, di solito lo si “carica” all’interno di un programma per la gestione dei database, come MS Access (e MS Jet, che è il “motore” che MS Access usa dietro le quinte) e lo si analizza sfruttando gli strumenti di questo programma. Ci sono però alcune cose da sapere.

La prima è che, salvo casi particolari, non è una bella idea usare un programma di calcolo (cioè uno “spredasheet”) come MS Excel, OpenOffice Calc, Lotus 1,2,3 e cose simili per analizzare un tabulato telefonico. La ragione è che i fogli elettronici di questo tipo di solito possono trattare al massimo 65.000 righe (cioè “record”). Possono sembrare molte ma è tutt’altro che raro imbattersi in analisi che richiedono di trattare molti più record di questi. I veri database, come SQL Server, Jet o MySQL, non soffrono di questo limite.

Un’altra cosa da sapere è che solitamente gli eventi (i “record”) sono identificati da un numero progressivo. Quando si “fondono” più tabulati telefonici (più file CVS) in un unico file, questi ID si sovrappongono e vanno in collisione tra loro. Può sembrare un problema da poco ma non lo è. Una cosa del genere può rendere impossibile l’operazione di “fusione” e l’intera analisi. Per questo è meglio rimuovere questi ID o sostituirli con altri che non possano creare collisioni (come gli UUID o GUID).

Risultati ottenibili

Il primo e più importante risultato che si può ottenere dall’analisi dei tabulati consiste nel capire dove si trovava una certa persona (od il suo telefono…) al momento della chiamata. Come ho già detto, il CDR contiene due appositi campi per l’ID delle celle di ingresso e di uscita della chiamata. I telefoni (chiamante e chiamato) devono per forza trovarsi a meno di 5 – 10 km da quelle torri radio.

Per ottenere questo risultato basta leggere i campi “cella ingresso” e “cella uscita” del tabulato e verificare la posizione geografica delle celle sull’elenco fornito dalla compagnia telefonica.

L’altro risultato è molto meno facile da ottenere e richiede spesso una complessa elaborazione di centinaia o di migliaia di righe. Solo in questo modo, infatti, è possibile ricostruire la rete di relazioni della persona (o delle persone) su cui si indaga.

Più in dettaglio, si tratta di caricare in un unico database (che poi, in realtà, di solito è una sola tabella) diversi tabulati telefonici, relativi a diverse persone, e vedere se i relativi telefoni sono entrati in contatto tra loro ed in quale modo. Quest’analisi può essere tutt’altro che semplice.

Ad esempio, può succedere che il boss mafioso Carmelo O’Nimale abbia telefonato ad una donna chiamata Bocca di Rosa e che questa signora, a sua volta, abbia recapitato un suo messaggio al boss camorrista Angelo Nero usando un telefono cellulare diverso da quello su cui ha ricevuto la chiamata originale. Insomma, si tratta di ricostruire una complessa rete di relazioni in cui entrano in gioco diverse persone, molti telefoni e qualche portavoce.

Software per l’analisi

Esistono anche alcuni programmi commerciali per l’analisi dei tabulati telefonici. In Italia, uno dei pochi presenti è lo ATPS2000 di Pegaso SRL:

http://www.pegasoservizi.net/software.htm

ATPS2000 è una applicazione creata sulla base di MS Access ed è fornita di molti servizi che risultano indispensabili per questo tipo di analisi.

Un altro è Analyst’s Notebook di Orasis:

http://www.intelligence.orasis.it/analysts_notebook_-_tetras.html

Potete vedere di cosa si tratta dai video che trovate sul loro sito.

Un altro ancora è CDR Resolved:

http://wn.com/call_detail_record

di cui, però, non sono riuscito a trovare altre informazioni.

Sappiate però che, in genere, chi tratta questa roba per lavoro tende ad usare strumenti molto più potenti e che richiedono una certa competenza, come gli RDBMS PostgreSQL, MySQL, Oracle e vari sistemi per la creazione dei front-end, come MS Access, Kexi, Filemaker e roba simile.

Grafi di relazione

Se guardate questo filmato, relativo a CDR Resolved, potete vedere anche cosa vuol dire ricostruire la rete di relazioni esistenti tra numeri telefonici:

http://wn.com/CDR_Analysis_Softwarewmv

Come potete vedere, verso il minuto 6 del filmato, viene creato un grafico che rappresenta le relazioni tra i numeri (e quindi tra i loro utilizzatori).

Sappiate che è abbastanza semplice creare grafici di questi tipo in modo automatico, semiautomatico o manuale usando programmi come OpenOffice Base ed OpenOffice Draw.