Come stabilire se uno smartphone era in uso al momento di un incidente stradale

Nei procedimenti relativi a incidenti stradali gravi o a ipotesi di omicidio stradale, una delle domande che può assumere particolare rilevanza è stabilire se il conducente stesse utilizzando il proprio telefono nei secondi immediatamente precedenti all’impatto.

La risposta, tuttavia, raramente può essere ricavata da un singolo elemento. La presenza di una telefonata, di un messaggio o di una connessione di rete non dimostra automaticamente che il dispositivo fosse materialmente nelle mani del conducente.

L’attività forense consiste quindi nella costruzione di una timeline temporale estremamente precisa, ottenuta mettendo in relazione differenti artefatti del telefono con l’orario del sinistro e con le altre fonti disponibili: dati del veicolo, telecamere, testimonianze, tabulati, posizione GPS e dinamica dell’incidente.

La domanda corretta: il telefono era acceso, manipolato o utilizzato?

Prima di iniziare l’analisi è importante distinguere tre domande che potrebbero sembrare equivalenti ma che, dal punto di vista forense, sono profondamente differenti.

Un telefono può essere attivo senza che nessuno lo stia usando. Può ricevere una notifica, sincronizzare la posta elettronica, aggiornare la posizione o mantenere una connessione Bluetooth senza alcuna azione dell’utente.

Un secondo livello consiste nel dimostrare che il dispositivo sia stato fisicamente manipolato, ad esempio attraverso un evento di sblocco, un cambio di orientamento o l’attivazione di un’applicazione.

Un ulteriore passaggio consiste infine nell’attribuire quell’interazione proprio al conducente del veicolo. In presenza di altri occupanti, ad esempio, l’attività del telefono non dimostra automaticamente chi lo stesse utilizzando.

Il primo problema: determinare con precisione l’orario del sinistro

Prima ancora di analizzare il telefono è necessario stabilire, con la migliore precisione possibile, l’istante temporale dell’impatto.

Questo riferimento può provenire da differenti fonti:

• centralina o Event Data Recorder del veicolo;
• sistemi eCall;
• registrazioni di telecamere;
• dashcam;
• sistemi GPS del veicolo;
• registrazioni delle centrali operative;
• chiamate di emergenza;
• telemetria;
• fotografie o video realizzati sul posto;
• testimonianze tecnicamente verificabili.

L’obiettivo è ottenere un intervallo temporale sufficientemente ristretto, ad esempio:

14:32:23 - 14:32:25

sul quale concentrare l’analisi del dispositivo.

Attenzione ai timestamp

Quando si confrontano eventi provenienti da sorgenti differenti non è possibile limitarsi a leggere l’orario mostrato dal software.

È necessario verificare:

• se il timestamp è espresso in UTC o in ora locale;
• il fuso orario configurato sul dispositivo;
• l’applicazione dell’ora legale;
• il formato temporale utilizzato dal database;
• eventuali differenze tra Apple Epoch, Unix Epoch o altri sistemi;
• possibili errori o scostamenti dell’orologio del dispositivo;
• il modo in cui lo strumento forense converte e visualizza il timestamp.

Quali elementi cercare nello smartphone

Una volta determinata la finestra temporale di interesse, si possono ricercare tutti gli artefatti che documentano lo stato e l’attività del dispositivo.

1. Accensione e spegnimento dello schermo

Uno dei primi elementi da ricercare è lo stato del display.

Eventi che indicano:

• accensione dello schermo;
• spegnimento;
• passaggio a uno stato interattivo;
• attivazione del lock screen;
• uscita dal lock screen;

possono restringere notevolmente la finestra durante la quale il telefono potrebbe essere stato utilizzato.

L’accensione dello schermo, tuttavia, non significa automaticamente che il telefono sia stato toccato: una notifica o altri automatismi possono provocare l’attivazione del display.

2. Eventi di sblocco

Un evento di unlock è generalmente più significativo.

Se pochi secondi prima dell’incidente il dispositivo passa, ad esempio, dalla condizione:

LOCKED ? UNLOCKED

l’informazione costituisce un forte indizio di interazione con il dispositivo.

Anche in questo caso, però, è necessario conoscere il metodo di autenticazione:

• PIN;
• password;
• Face ID;
• Touch ID;
• Smart Lock o meccanismi equivalenti;
• dispositivo già precedentemente sbloccato.

La corretta interpretazione dipende quindi dal modello, dalla versione del sistema operativo e dalla configurazione del telefono.

3. Quale applicazione era in primo piano

Uno degli artefatti più interessanti consiste nell’individuare quale applicazione fosse in foreground nell’intervallo immediatamente precedente al sinistro.

Potrebbero emergere, ad esempio:

14:32:12  Device unlocked
14:32:15  WhatsApp foreground
14:32:21  Message sent
14:32:24  Estimated collision

Una sequenza di questo tipo è molto più significativa della semplice presenza di un messaggio con timestamp prossimo all’incidente.

Permette infatti di documentare una successione temporale coerente:

1. il dispositivo viene sbloccato;
2. l’applicazione viene portata in primo piano;
3. viene eseguita un’attività;
4. pochi secondi dopo si verifica l’incidente.

4. Messaggi inviati e ricevuti

Applicazioni come WhatsApp, Telegram, Signal, Messenger, SMS e altre piattaforme possono fornire timestamp relativi a:

• invio del messaggio;
• ricezione;
• consegna;
• lettura;
• modifica;
• allegati;
• messaggi vocali;
• eventuali reazioni.

È fondamentale distinguere questi eventi.

Un messaggio ricevuto non dimostra alcuna azione dell’utente.

Un messaggio inviato può invece essere molto più significativo, ma occorre comunque stabilire se:

• sia stato scritto manualmente;
• sia stato inviato tramite dettatura;
• sia stato inviato attraverso un assistente vocale;
• sia partito da un dispositivo collegato;
• sia stato inviato tramite una versione desktop o web;
• provenga da un altro dispositivo associato allo stesso account.

5. Messaggi vocali e dettatura

Un messaggio vocale inviato durante la guida non comporta necessariamente la stessa interazione richiesta dalla digitazione di un testo.

Allo stesso modo, un messaggio testuale potrebbe essere stato prodotto attraverso un sistema di dettatura o un assistente vocale.

La sola presenza del messaggio non permette quindi sempre di stabilire come sia stato generato.

È opportuno cercare ulteriori eventi relativi a:

• microfono;
• assistente vocale;
• interazione con Siri o Google Assistant;
• Bluetooth del veicolo;
• CarPlay;
• Android Auto.

6. Chiamate telefoniche

Anche il registro chiamate deve essere interpretato con attenzione.

Una telefonata in corso dimostra che il dispositivo era impegnato in una comunicazione, ma non necessariamente che fosse tenuto in mano.

Occorre verificare se la conversazione avvenisse attraverso:

• auricolare;
• Bluetooth;
• vivavoce;
• sistema infotainment del veicolo;
• CarPlay;
• Android Auto;
• telefono tenuto fisicamente vicino all’orecchio.

L’ultimo scenario non dovrebbe essere dedotto dalla sola presenza della chiamata.

7. Bluetooth e collegamento con il veicolo

La connessione Bluetooth può essere particolarmente utile.

Se il telefono risulta collegato all’automobile nell’intervallo temporale di interesse, questo dato può contribuire a stabilire:

• che il dispositivo si trovava probabilmente nel veicolo;
• che una telefonata poteva essere gestita dal vivavoce;
• che audio e notifiche potevano transitare attraverso l’infotainment;
• che determinate azioni potevano essere effettuate senza manipolare direttamente il telefono.

È però necessario verificare con attenzione tempi di connessione e disconnessione, nome e indirizzi dei dispositivi Bluetooth e possibili connessioni automatiche.

8. Apple CarPlay e Android Auto

La presenza di CarPlay o Android Auto modifica ulteriormente l’interpretazione dell’attività.

Un’applicazione può risultare utilizzata perché è stata controllata attraverso l’interfaccia dell’automobile, senza che il conducente abbia necessariamente preso in mano il telefono.

Per questo un evento relativo, ad esempio, a Maps, Spotify, Telefonia o Messaggi deve essere correlato con lo stato del collegamento al veicolo.

9. Orientamento fisico del telefono

Nei dispositivi iOS più recenti, alcuni eventi dei log di sistema possono permettere di ricostruire anche variazioni dell’orientamento fisico del dispositivo.

Potrebbero essere osservati passaggi come:

Face Up ? Portrait ? Landscape ? Face Up

Una variazione da Face Up a Portrait può essere coerente con un telefono che viene sollevato da una superficie e portato in posizione verticale.

Questo tipo di dato è particolarmente interessante perché può fornire indicazioni sulla manipolazione fisica del dispositivo anche quando altri artefatti sono limitati.

10. Posizione geografica

È inoltre necessario verificare se il dispositivo fosse effettivamente nella zona dell’incidente.

Le fonti possibili comprendono:

• GPS;
• cronologia delle applicazioni di navigazione;
• cache cartografiche;
• Wi-Fi;
• celle telefoniche;
• dati di localizzazione delle applicazioni;
• servizi di sistema;
• fotografie e relativi metadati;
• artefatti Find My o servizi equivalenti.

Anche qui bisogna distinguere precisione GPS da semplice localizzazione per cella, che può coprire un’area molto più ampia.

11. Dati di movimento e sensori

Accelerometro, giroscopio e altri sensori possono produrre artefatti utili alla ricostruzione.

In alcuni casi possono aiutare a comprendere:

• se il telefono fosse fermo;
• se fosse in movimento;
• se sia stato sollevato;
• se abbia subito un brusco movimento;
• se la dinamica temporale sia compatibile con l’impatto.

Questi dati non devono però essere confusi con una vera ricostruzione cinematica del veicolo: sono informazioni relative al dispositivo e devono essere interpretate all’interno del loro contesto.

12. Fotografie, video e fotocamera

Un evento di apertura della fotocamera, la creazione di una fotografia o l’inizio di una registrazione video a pochi secondi dall’incidente può rappresentare un elemento particolarmente significativo.

È opportuno esaminare:

• timestamp del file;
• metadati EXIF;
• eventuale posizione GPS;
• orientamento;
• data di creazione;
• data di modifica;
• artefatti della libreria fotografica;
• stato dell’applicazione Camera.

13. Navigazione web e ricerche

Lo stesso principio vale per browser e motori di ricerca.

Una ricerca eseguita esattamente nella finestra temporale precedente all’incidente può indicare un’attività dell’utente, specialmente se accompagnata da:

• sblocco del dispositivo;
• browser in foreground;
• caricamento della pagina;
• digitazione;
• successivo spegnimento del display.

iPhone: KnowledgeC, Biome e Unified Logs

Su iOS esistono differenti fonti particolarmente interessanti per ricostruire l’attività temporale del dispositivo.

KnowledgeC

Il database KnowledgeC è storicamente una delle sorgenti utilizzate per ricostruire il cosiddetto pattern of life del dispositivo.

Può contenere o permettere di ricostruire informazioni relative a:

• utilizzo delle applicazioni;
• stato dello schermo;
• lock e unlock;
• attività del dispositivo;
• alcune interazioni di sistema;
• orientamento dell’interfaccia;
• altri eventi temporali.

Biome

Nelle versioni più recenti di iOS, molte informazioni comportamentali possono essere memorizzate all’interno dei cosiddetti Biome streams.

A seconda della versione del sistema e dell’acquisizione possono emergere informazioni relative a:

• utilizzo delle applicazioni;
• attività del display;
• orientamento;
• messaggistica;
• eventi di sistema;
• ulteriori informazioni contestuali.

Unified Logs

Gli Unified Logs di iOS costituiscono un’ulteriore fonte estremamente ricca.

In determinati casi possono permettere una ricostruzione molto precisa di eventi che non sono immediatamente visibili nei normali database applicativi.

L’analisi può comprendere, ad esempio:

• eventi di sistema;
• attività delle applicazioni;
• stato del dispositivo;
• connessioni;
• orientamento fisico;
• altre informazioni registrate dai processi iOS.

Android: Usage Events e artefatti di sistema

Anche Android mantiene diversi artefatti relativi all’utilizzo del dispositivo.

A seconda della versione possono essere disponibili eventi concettualmente riconducibili a:

• SCREEN_INTERACTIVE;
• SCREEN_NON_INTERACTIVE;
• KEYGUARD_SHOWN;
• KEYGUARD_HIDDEN;
• ACTIVITY_RESUMED;
• ACTIVITY_PAUSED;
• applicazioni portate in foreground;
• attività dei servizi.

La presenza effettiva e la persistenza di questi dati dipendono dalla versione Android, dal produttore del dispositivo e dal tipo di acquisizione disponibile.

La timeline di Cellebrite

Strumenti come Cellebrite Physical Analyzer o Reader possono agevolare l’analisi aggregando eventi provenienti da differenti sorgenti all’interno di una timeline.

Per il caso di un incidente può essere utile filtrare, ad esempio, una finestra:

14:30:00 - 14:35:00

e successivamente restringerla progressivamente ai secondi precedenti all’impatto.

È comunque importante ricordare che la timeline del software è una rappresentazione derivata dai parser. Per eventi decisivi ai fini della relazione, può essere opportuno verificare anche l’artefatto sorgente.

Un esempio concreto

Supponiamo che l’urto venga collocato, attraverso i dati del veicolo e una telecamera, alle:

14:32:24 ± 1 secondo

Dall’acquisizione del telefono emergono:

14:32:09   Display interactive
14:32:12   Device unlocked
14:32:15   WhatsApp moved to foreground
14:32:17   Chat opened
14:32:21   Outgoing message
14:32:24   Collision
14:32:27   Device orientation change
14:32:31   Display off

Presi singolarmente, alcuni di questi eventi possono essere ambigui.

Considerati nel loro insieme, costituiscono invece una sequenza coerente con un’interazione sul dispositivo immediatamente precedente al sinistro.

La relazione dovrebbe però ancora verificare:

• chi fosse materialmente in possesso del telefono;
• se vi fossero passeggeri;
• se WhatsApp fosse utilizzato anche su altri dispositivi;
• se il messaggio fosse stato dettato;
• se il telefono fosse connesso a CarPlay o Android Auto;
• se l’orario del sinistro fosse sufficientemente preciso.

Il caso opposto: attività che non dimostra utilizzo

Supponiamo invece di trovare:

14:32:10   WhatsApp message received
14:32:11   Notification generated
14:32:24   Collision

Questa sequenza, da sola, non dimostra che il conducente abbia utilizzato il telefono.

Il messaggio può essere stato ricevuto automaticamente e la notifica generata senza alcuna interazione umana.

Un messaggio inviato è sufficiente?

È sicuramente un artefatto più rilevante, ma anche in questo caso la risposta è: non necessariamente.

Bisogna verificare se:

• l’invio è avvenuto dal telefono sequestrato;
• l’account disponeva di dispositivi collegati;
• esisteva una sessione WhatsApp Web;
• il messaggio è stato dettato;
• il sistema era collegato a CarPlay o Android Auto;
• altri eventi documentano un’interazione con lo schermo.

L’importanza delle fonti esterne al telefono

Una buona analisi non dovrebbe limitarsi allo smartphone.

La ricostruzione può essere molto più robusta quando viene confrontata con:

• Event Data Recorder del veicolo;
• centraline dell’automobile;
• infotainment;
• Bluetooth;
• GPS del mezzo;
• telecamere pubbliche o private;
• dashcam;
• tabulati telefonici;
• dati dell’operatore;
• testimonianze;
• fotografie del luogo;
• dati di eventuali smartwatch.

Smartwatch e altri dispositivi collegati

Anche Apple Watch, smartwatch Android e altri wearable possono assumere rilievo.

Un messaggio potrebbe essere stato:

• letto sull’orologio;
• risposto tramite dettatura;
• gestito senza toccare materialmente il telefono.

Ne consegue che la semplice attività dell’account non coincide necessariamente con l’utilizzo manuale dello smartphone.

Quanto deve essere ampia la finestra temporale?

In un caso di incidente stradale è generalmente utile non analizzare soltanto l’istante esatto dell’urto.

Può essere opportuno costruire almeno tre finestre:

La correlazione è più importante del singolo artefatto

Dal punto di vista probatorio, la situazione più significativa non è normalmente:

14:32:21 - messaggio WhatsApp

ma una sequenza convergente di elementi:

14:32:09  schermo acceso
14:32:12  sblocco
14:32:15  WhatsApp foreground
14:32:17  chat aperta
14:32:21  messaggio inviato
14:32:24  impatto

Più sorgenti indipendenti convergono sulla stessa ricostruzione, maggiore è la robustezza dell’interpretazione tecnica.

Attenzione alla causalità

Un altro passaggio fondamentale consiste nel distinguere:

• la prova che il telefono era utilizzato;
• la prova che fosse utilizzato dal conducente;
• la valutazione del rapporto tra tale utilizzo e la dinamica dell’incidente.

L’informatica forense può contribuire in modo molto preciso alle prime due domande.

Stabilire invece se l’utilizzo del telefono abbia avuto un ruolo causale nella produzione del sinistro richiede normalmente la correlazione con la ricostruzione cinematica e con gli altri accertamenti tecnici.

Come documentare l’analisi nella relazione peritale

Una relazione dovrebbe evitare conclusioni assolute non supportate dagli artefatti.

È preferibile distinguere chiaramente:

• il dato osservato;
• la sua sorgente;
• il timestamp originale;
• la conversione temporale applicata;
• l’interpretazione tecnica;
• il grado di certezza della conclusione.

Esempio di formulazione prudente

Cosa evitare nella relazione

Sono invece da evitare conclusioni come:

• “Il telefono era acceso, quindi il conducente lo stava usando”;
• “È arrivato un messaggio, quindi il conducente lo ha letto”;
• “Era in corso una telefonata, quindi teneva il telefono in mano”;
• “WhatsApp era attivo, quindi stava scrivendo”;
• “Il telefono si è mosso, quindi il conducente lo ha preso”;
• “Il messaggio è stato inviato dall’account, quindi è stato digitato sul telefono sequestrato”.

Queste affermazioni confondono il dato tecnico osservato con una conclusione ulteriore che richiede elementi di verifica.

Una possibile checklist operativa

In sintesi

Stabilire se uno smartphone fosse in uso al momento di un incidente stradale non significa semplicemente verificare se sia presente una telefonata o un messaggio.

L’analisi corretta consiste nel ricostruire il comportamento del dispositivo secondo per secondo, mettendo in relazione:

• stato dello schermo;
• lock e unlock;
• applicazioni in foreground;
• messaggi e chiamate;
• orientamento e movimento;
• posizione;
• Bluetooth e sistemi del veicolo;
• eventuali dispositivi collegati;
• fonti esterne indipendenti.

Il risultato più robusto nasce dalla convergenza di più artefatti temporalmente coerenti.