Primavera 2020: il sogno e l'incubo di praticamente tutto il mondo occidentale è: Come e quando ripartire dopo il lockdown imposto a seguito dell'epidemia di COVID-19.

Le idee certo non mancano, sono molte e, a dire il vero, molto confuse. Il fatto che il virus sia abbastanza pericoloso, di rapido contagio e sintomatologia variabile non aiuta a chiarirle.

Ma per fortuna c'è un concetto che mette davvero tutti d'accordo, Cinesi e Americani, Destra e Sinistra, governi e opposizioni: la ripartenza si deve basare su una App per cellulare che tracci i contatti tra i cittadini.

L'applicazione va soltanto pensata, realizzata in qualche modo, fatta utilizzare dalla quasi totalità della popolazione e poi... e poi il resto si vedrà, si incaricherà un consulente.

Come effetto, praticamente ogni nazione nel mondo sta cercando di risolvere questo problema. Con risultati altalenanti e più di una perplessità.

Concentrandoci sull'Europa (dell'Italia parleremo più in dettaglio), ci si è subito adoperati per una risposta comune. Peccato che gli stati siano oltre quaranta, e le idee differenti almeno altrettante.

Risultato: ha iniziato il consorzio DP3T (Decentralized Privacy-Preserving Proximity Tracing), durato lo spazio di pochi giorni prima di essere rimosso senza preavviso dal sito dell'Unione Europea. A "fargli le scarpe" dovrebbe essere stato il consorzio concorrente, il PEPP-PT (Pan-European Privacy-Preserving Proximity Tracing), come riportato anche qui. Putroppo, sin dalla sua nascita, il PEPP-PT e' divorato da una brutale faida interna: offre infatti due modalità di funzionamento, diametralmente opposte: centralizzata e decentrata. Poiché il DP3T, che aveva come cavallo di battaglia la decentralizzazione non ha fatto una bella fine, è ragionevole affermare che un possibile approccio europeo potrebbe essere: PEPP-PT-Centralized. Ma anche no ...

La differenza tra le due modalità è minima solo in apparenza, ha gigantesche implicazioni sulla privacy ed è oggetto di aspri dibattiti. Approccio centralizzato significa che la App dialoga frequentemente ed in maniera bidirezionale con un server centrale. In pratica, condivide in tempo reale i dati che raccoglie. Viceversa, approccio decentrato significa che ogni App conserva i propri dati solo localmente, senza alcuna condivisione. L'unico scambio con l'esterno è in caso di positività al contagio, per caricare su un server tale informazione (fortemente anonimizzata) o per scaricare i dati (ugualmente, anonimizzati) degli altri utenti positivi al contagio.

È lampante che la modalità decentrata offra intrinsecamente maggiore privacy, e sia naturalmente più resiliente ad eventuali attacchi. Tutto il contrario della centralizzata.

Ma nel pieno di questo dibattito, il colpo di scena. Con un comunicato congiunto già entrato nei libri di storia e rimbalzato su qualsiasi piattaforma social della galassia, Apple e Google hanno annunciato il loro impegno per sviluppare un Framework completo per la gestione del Contact Tracing, basato su una totale decentralizzazione e orientato al massimo rispetto della privacy.

In pratica Apple e Google si sono impegnati ad aggiungere all'interno dei loro sistemi operativi un insieme di interfacce (API) per semplificare al massimo, e nel contempo standardizzare, lo sviluppo di queste famose App di Contact Tracing. App di cui ormai parlano - mantenendo una distanza di almeno un metro - anche le anziane signore nella fila per entrare al supermercato.

Spiegandolo in un altro modo, un'applicazione destinata a decine di milioni di persone (una nazione europea, ad esempio) potrebbe essere scritta anche da qualcuno poco esperto in tematiche di sicurezza e privacy, cosa che purtroppo succede spesso, componendo, come con i LEGO, queste nuove interfacce "sicure" offerte dal sistema operativo.

Ad oggi, i due sistemi operativi IOS e Android non sono stati ancora aggiornati con patch contenenti le nuove interfacce. Ma tutti i documenti tecnici (sono quattro, l'ultima versione mentre scrivo è la 1.2) sono stati rilasciati al pubblico, in modo da permettere agli sviluppatori di App designati dai vari governi di prenderne confidenza.

Poiché le interfacce sono descritte in dettaglio, ed il loro obiettivo non va oltre offrire un accesso semplificato a servizi crittografici "aperti" e perfettamente noti, già oggi sarebbe possibile scrivere una App esattamente come previsto dal Framework di Apple e Google. Quando poi fossero rilasciate le nuove versioni dei sistemi operativi, l'applicazione potrebbe essere facilmente integrate ad esse.

Noi i documenti li abbiamo letti. In questo articolo proveremo ad illustrare cosa prevede questo nuovo ambiente per lo sviluppo di una App di Contact Tracing che sia davvero sensibile alle tematiche di sicurezza e privacy. Rimarremo generici ma entreremo abbastanza nel dettaglio per permettere ai lettori con un po' di conoscenze di programmazione di scrivere il loro prototipo funzionante di App (su PC o cellulare): The AppIsInTheAir.

Due risorse utili per i programmatori:

• Il repository dei documenti di specifica Apple/Google è: https://www.apple.com/covid19/contacttracing
• L'Appendice di questo articolo contiene tutte le funzioni utilizzate nel calcolo delle chiavi crittografiche e numerosi suggerimenti implementativi.
  

  The AppIsInTheAir: Aderire al protocollo di Apple & Google

  Immagine tratta da questo documento

   

  Il protocollo congiunto Apple/Google è relativamente semplice e, come accade in questi casi, estremamente elegante.

  Riducendolo ai minimi termini, supponiamo che due utenti con attivate sia la stessa App che il Bluetooth (condizioni necessarie) si incontrino. Il terminale di un utente emette via Bluetooth una chiave numerica anonimizzata, contenente un suo identificativo (specifico per quell'incontro) ed una stima della distanza dalla controparte. Il terminale dell'altro utente fa esattamente lo stesso. Avvenuto questo rapido scambio di credenziali, ciascun terminale archivia la chiave ricevuta su un database nella propria memoria.

  Se, in tempi successivi allo scambio di chiavi, un utente venisse dichiarato a rischio sanitario, la sua chiave (assieme ad un fattore di contagiosità ma senza altre informazioni) verrebbe caricata dai sanitari su un server pubblico dedicato a questo scopo. Queste chiavi vengono periodicamente scaricate da tutti gli utilizzatori della App. Sarebbe quindi il loro terminale, che ha memorizzato localmente le chiavi prossimali ricevute, ad informarli di un'eventuale contatto positivo, assieme ad un Livello di Rischio Sanitario, un numero da 1 a 8 di cui il fattore di contagiosità è una componente.

  Questa è l'idea. Nella pratica, l'implementazione è un pochino più complessa. Specificatamente, moltissima attenzione è stata dedicata ad evitare che un sistema di monitoraggio del rischio sanitario possa invece essere utilizzato per il tracciamento dei movimenti degli utenti. Dichiaratamente, lo User tracking non è lo scopo di questo protocollo di Contact Tracing.

  Il punto critico è che coloro che decidessero di utilizzare l'applicazione avrebbero al loro fianco un trasmettitore costantemente attivo: sarebbe quindi molto semplice per chiunque tracciarne in modo univoco i movimenti. E sarebbe ancora più semplice da parte di un governo autoritario ! Quest'ultimo potrebbe senza fatica "acquisire" tutti i contatti raccolti dalle numerose celle Bluetooth già posizionate nel territorio: nei parchi, alle fermate dei mezzi pubblici, persino nelle decine di migliaia di lampioni per l'illuminazione (cosiddetti) smart. Potremmo chiamarlo effetto (o rischio) transponder. Ricordiamo che il transponder è un trasmettitore montato a bordo di aerei ed imbarcazioni che, inviando continuamente un codice identificativo noto e costante, ne permette il tracciamento da parte delle autorità preposte al controllo del traffico.

  L'unica tecnica per limitare fortemente il rischio transponder è quello di cambiare continuamente ed impredicibilmente la chiave inviata dal trasmettitore: in effetti il protocollo che implementeremo altro non è che un elaborato "incastro" di chiavi in continua mutazione, di cui solo l'utente che le ha emesse conosce la sequenza. Sarà proprio quest'ultimo, in caso di diagnosi positiva, ad informare i sanitari di avere installato la App, autorizzando l'invio sul server dedicato delle proprie chiavi giornaliere limitatamente al suo periodo di contagiosità.

  Per spiegare con un esempio il funzionamento della App, immagineremo uno scenario con tre utenti: Nicola, Nadia e Piero. Tutti e tre installano l'applicazione AppIsInTheAir. Tutti sono inizialmente negativi al contagio ma, ad un certo punto, Piero diventerà positivo.

  I tre utenti attivano l'applicazione AppIsInTheAir. Al primo avvio e poi allo scoccare della mezzanotte di ogni giorno, l'applicazione genera sul dispositivo una nuova master-key casuale, valida solo per quel giorno. La Temporary Exposure Key TEK:

  TEK = CNPRNG₁₂₈()

  L'applicazione non chiede mai nessun dato personale e, soprattutto, non comunica a nessuno la chiave giornaliera TEK. Al contrario, dovrebbe custodirla in modo che non possa mai lasciare il dispositivo (vedi il rischio transponder descritto sopra). Inoltre distrugge le chiavi più vecchie di 14 giorni, limitando i rischi nel malaugurato caso di un accesso non autorizzato.

  Contestualmente alla chiave giornaliera, vengono derivate altre due chiavi crittografiche, con validita' limitata allo stesso giorno: la chiave Rolling Proximity Identifier Key, RPIK e la chiave Associated Encrypted Metadata Key, AEMK. Entrambe sono derivate in modo crittograficamente sicuro tramite la funzione HKDF:

  RPIK = HKDF₁₂₈(TEK, "EN-RPIK")

  AEMK = HKDF₁₂₈(TEK, "EN-AEMK")

  Queste chiavi gestiscono le due componenti del messaggio effettivamente trasmesso dall'utente via Bluetooth. Godono di identiche proprietà e per ora ci concentreremo sulla prima chiave, RPIK:

  • La chiave è stata derivata in modo crittograficamente sicuro e può essere distribuita all'esterno senza compromettere la riservatezza della master key giornaliera TEK.
  • Nello stesso giorno, due utenti non potranno mai avere la stessa RPIK (la chiave generatrice TEK è estratta in maniera totalmente casuale da un insieme di 2¹²⁸ elementi).
  • In giorni diversi, lo stesso utente produce una chiave TEK (e quindi RPIK) totalmente differente.

  L'ultima proprietà è il punto nodale dell'intero algoritmo: se, in caso di positività, un utente dovesse diffondere una chiave costante che non cambia nel tempo (diciamo il suo user-id, seppure offuscato per garantirgli la privacy), risulterebbe contagioso da sempre e per sempre ...!

  Invece, come sappiamo, le "interferenze" tra gli utenti sono critiche solo entro specifici periodi (diciamo, dall'inizio alla fine del periodo in cui un utente sia contagioso) -- ed infatti per ciascun giorno le chiavi di ogni utente sono totalmente differenti ed incorrelate l'una dall'altra.

  A questo punto, la chiave giornaliera RPIK sarebbe necessaria e sufficiente per creare un'applicazione che raggiunge i due obiettivi richiesti: tracciamento a posteriori degli eventuali contatti prossimali e assoluta anonimità degli stessi. Ma rimarrebbe irrisolto il problema introdotto precedentemente: il rischio del tracking mediante la chiave giornaliera. Infatti un utente emetterebbe via Bluetooth la stessa identica chiave RPIK dalle 00:00 alle 23:59, rendendosi identificabile univocamente nell'arco dell'intera giornata.

  Forse con poca fantasia, ma con assoluta efficacia tecnica, il problema si risolve introducendo ulteriori identificativi che variano con frequenza... oraria !

  Più precisamente questi identificativi, che sono quelli realmente emessi dal trasmettitore Bluetooth e che vengono chiamati Rolling Proximity Indentifier, RPI sono ricalcolati ogni 10 minuti.

  I motivi di questa scelta sono due. Il primo è che una minore durata dei messaggi riduce in proporzione il rischio del tracking. Il secondo è che tutti messaggi trasmessi attraverso il Bluetooth dispongono comunque di una intestazione (Advertising) generata dal trasmettitore che da alcuni anni si è scelto di cambiare randomicamente ogni 10 (o 15) minuti. Difatti se l'intestazione rimanesse costante, il tracking si potrebbe fare banalmente sull'Advertising del messaggio, anziché sul messaggio stesso ...!

  Per riassumere, ciò che accade è che ogni 10 minuti c'è un cambio radicale del pacchetto inviato via Bluetooth da uno stesso terminale: sia il messaggio contenente la chiave RPI che la sua intestazione vengono rigenerati. Questo rende impossibile ad un attaccante che non abbia "assistito" alla transizione scoprire il legame tra due messaggi consecutivi (o, a maggior ragione, non consecutivi).

  Dopo aver introdotto le proprietà del Rolling Proximity Identifier, descriviamone l'algoritmo di calcolo:

  RPI = AES₁₂₈(RPIK, "EN-RPI"||000000000000||ENIN)

  Dove ENIN, descritto in Appendice, è l'ora corrente arrotondata a multipli di 10 minuti.

  A partire dalla versione 1.2 dell'algoritmo di Apple & Google (29 Aprile 2020) è stato associato al messaggio Bluetooth inviato da ogni terminale un metadato cifrato, chiamato AEM (Associated Encrypted Metadata), contenente una stima della distanza tra i due terminali durante lo scambio di chiavi. Questo, assieme ad altri parametri, permette di calcolare il Livello di Rischio che appare sui messaggi di notifica.

  Il metadato AEM contiene semplicemente un numero, il valore della potenza emessa del trasmettitore Bluetooth durante lo scambio di credenziali con la controparte. La potenza è espressa in mW, ed è rappresentata in scala logaritmica (dBm) nel range -127, +128. Il metadato e' cifrato con algoritmo AES₁₂₈ mediante la chiave AEMK derivata per questo scopo dalla master key giornaliera TEK.

  L'approccio per la stima della distanza è assai minimalista (dovendo funzionare sull'intero "parco" di dispositivi), il che ne compromette l'efficacia. Nei dispositivi mobili il trasmettitore Bluetooth deve cercare di risparmiare energia quando possibile, limitando la potenza allo stretto necessario. In condizioni di elevata prossimità la potenza emessa è la minima possibile. Viceversa, una potenza molto alta è sintomo di una distanza maggiore o di un ostacolo (un muro, l'abitacolo di un'auto). In generale, dunque, un contatto avvenuto ad una potenza (leggi: distanza) minore si assume essere più rischioso di uno con un indice di potenza maggiore.

  Riassumendo, il payload (è così che vengono chiamati i messaggi che l'utente invia su un certo canale) inviato sul Bluetooth ad ogni "incontro tra utenti" è la concatenazione delle due informazioni: identificativo dell'utente prossimale (RPI) e distanza della prossimità (AEM):

  Bluetooth Payload = RPI||AEM

  Il livello di rischio (novità introdotta dalla versione 1.2)

  Introducendo il metadato associato al messaggio Bluetooth ("potenza impiegata del trasmettitore") abbiamo accennato al Livello di Rischio prossimale. Vediamolo più in dettaglio.

  Il Livello di Rischio prossimale (Exposure Risk Level) è la nuova componente fondamentale degli avvisi emessi dalla nostra Contact Tracing Application, a valle di un contatto con un utente diagnosticato positivo.

  E' un numero compreso tra 1 e 8, ed è la media pesata di quattro fattori:

  ERL = (α_T Transmission + α_Dur Duration + α_Days Days + α_A Attenuation)

  Dove α rappresenta il peso di ciascun parametro nella formula (vale 1/4 se non specificato altrimenti dal creatore della App). Anche i quattro parametri, presi individualmente, assumono valori compresi tra 1 e 8:

  • Transmission è un fattore di contagiosità del paziente, stabilito dai sanitari che ne hanno constatato la positivà, e viene inserito sul server assieme alla sua chiave giornaliera TEK. Quest'indice assumerà valori minori (es. 1, 2) per un paziente scarsamente sintomatico e valori maggiori (es. 7, 8) per un paziente con forti sintomi respiratori e/o con una professione svolta a stretto contatto con il pubblico, come tassista o operatore sanitario.
  • Duration è un fattore di durata, calcolato dalla App confrontando le chiavi scaricate dal server con i propri contatti prossimali. A contatti prossimali di durata minore corrisponde un indice inferiore, e viceversa. Il calcolo e' svolto a multipli di 5 minuti, e a contatti con durate superiori ai 30' corrisponde l'indice massimo, 8.
  • Days è un fattore di tempo, calcolato dalla App. Rappresenta il numero di giorni trascorsi dal contatto prossimale. Se sono trascorsi molti giorni dal contatto (es. oltre 10), l'indice è minore (es. 1, 2). Viceversa, se il contatto è appena avvenuto, l'indice è maggiore (7, 8).
  • Attenuation è un fattore di prossimità, calcolato dalla App semplicemente decodificando il messaggio AEM contenente la potenza impiegata dal trasmettitore Bluetooth. Ricordo che tale messaggio è archiviato nella memoria del terminale (non su un server) assieme all'identificativo dell'utente, e può essere decodificato quando diventi nota la sua chiave giornaliera TEK. Il che avviene in caso di diagnosi positiva. Per calcolare questo fattore si normalizza il livello di potenza in dBm (es. da +100 a 0) nella scala 1-8.

  La nostra App ... in azione !

  Abbiamo introdotto tutte le chiavi necessarie e descritto il contenuto del messaggio (payload) inviato via Bluetooth, contenente l'identificativo dell'utente (validità: 10 minuti) ed una stima della distanza dalla controparte. A questo punto mostreremo come funziona in pratica il nostro applicativo AppIsInTheAir facendoci aiutare dai nostri tre utilizzatori.

  • Nadia, Piero e Nicola abitano nella stessa città. Nadia e Piero sono vicini di casa e Piero utilizza il treno per andare ogni mattina al lavoro. Come anche fa Nicola.
  • I tre, a partire dal 10 Maggio, scaricano la App e la tengono sempre attiva. La App ogni pochi secondi trasmette via Bluetooth il payload dell'utente e simmetricamente riceve sullo stesso canale i payload con i messaggi (la coppia RPI e AEM) prodotti dagli utenti prossimali. La App dispone di un semplice database locale dove memorizza ogni messaggio ricevuto, assieme a data ed ora con risoluzione ridotta a multipli di 10 minuti.
  • Il 15 Maggio Piero si sente poco bene e, applicando i protocolli sanitari del caso (non oggetto di questo articolo) viene visitato da un medico e diagnosticato positivo. Gli stessi sanitari stabiliscono inoltre che Piero sia contagioso da almeno due giorni (quindi, dal 13 Maggio) e che il suo livello di contagiosità sia medio (5 su 8).
  • Piero, in accordo con i sanitari (la modalità precisa non è ancora nota), interagisce con la sua App segnalando la sua positività a partire dalla data del 13 Maggio, con un livello di contagiosità 5.
  • La App di Piero carica su un server pubblico, dedicato a questo scopo, le sue tre master key TEK relative ai giorni 13, 14 e 15 Maggio. Poiché per definizione le chiavi caricate su questo server sono sempre associate ad una diagnosi positiva, le chiavi TEK caricate sul server vengono ribattezzate Diagnosis Keys, DK, e corrispondentemente il server pubblico si chiama Diagnosis Server, DS. Ciascuna chiave DK è corredata dal giorno di riferimento e dal livello di contagiosità attribuito a Piero.
  • Ogni giorno le App di Nadia e Nicola si collegano al DS e scaricano le chiavi diagnostiche, DK, aggiunte sul server rispetto al loro ultimo collegamento. Il numero di nuove chiavi da scaricare è Σ_i=1..N M_i, dove N è il numero di nuovi utenti positivi ed M è, per ciascun utente positivo, il numero di giorni trascorsi tra la data di contagio e la data di diagnosi. Ingegneristicamente è dell'ordine di ≈ 10⋅N
  • Scaricate tutte le nuove chiavi DK, le App di Nadia e Nicola derivano, calcolandole da queste, prima le due chiavi RPIK e AEMK e poi le numerose chiavi di prossimità RPI, 144 per ogni giorno, realmente trasmesse via Bluetooth da ogni paziente positivo. Utilizzando lo stesso algoritmo che utilizzano per calcolare le proprie, soltanto partendo dalle chiavi diagnosticate positive DK anziché dalle proprie chiavi giornaliere TEK. Questo punto è particolarmente interessante e, da un certo punto di vista, affascinante. Abbiamo visto che, per massimizzare la privacy, ogni utente cambia chiave ogni 10 minuti. Pertanto, in caso di positività, ci si sarebbe aspettato che lo stesso utente avrebbe dovuto trasmettere al server DS 144 chiavi prossimali per ogni giorno di ritardo della diagnosi. Un numero non banale. Altrettanto non banale sarebbe stato il numero totale di chiavi da scaricare su ogni terminale che aggiornasse la sua lista-chiavi.
  • Grazie allo stratagemma sopra descritto, il numero di chiavi da scaricare rimane minino, una per utente per giorno, e da ciascuna le App di Nadia e Nicola calcoleranno autonomamente le 144 chiavi di prossimità RPI associate ad ogni DK.
  • Se almeno una delle 144 chiavi appena calcolate venisse trovata nel proprio database locale alla stessa data, significa che è avvenuto un contatto con un paziente diagnosticato positivo.
  • Al rilevarsi di un eventuale contatto, la App dell'utente calcola autonomamente e mostra su una notifica il Livello di Rischio prossimale ERL a cui l'utente è stato esposto. Ricordiamo che il rischio ERL è la media pesata dei quattro parametri: Transmission (che noi abbiamo chiamato contagiosità e in questo esempio vale 5), Duration, Days, Attenuation.
  • Da questo confronto tra le chiavi, Nadia riceverà un avviso (lei non ne conosce il motivo, ma ha parlato brevemente di COVID-19 con Piero nell'androne del loro palazzo il 13 Maggio tra le 8 e le 8:10). La App di Nadia assume che la durata dell'incontro, minima, abbia rischio 2, che il fatto che siano passati pochissimi giorni dall'incontro produca un rischio elevato, 8, e che anche alla forte prossimità, un metro o meno, sia associato il rischio massimo 8. Il Livello di Rischio sperimentato da Nadia è dunque 6 su 8 (la media di 5,2,8,8).
  • Allo stesso modo Nicola e tutti gli altri passeggeri della carrozza del treno che hanno preso assieme a Piero, il 14 Maggio tra le 18:40 e le 19:30, riceveranno un avviso dalla loro App. Nicola era seduto a 4 sedili di distanza da Piero, 2 metri circa. La sua App attribuisce alla distanza un rischio basso, 2. Ma alla durata del viaggio in treno, oltre 30 minuti, e al fatto che il contatto sia avvenuto da pochi giorni viene attribuito il rischio massimo 8. Anche nel caso di Nicola, il suo Livello totale di Rischio e' 6 su 8 (la media di 5,8,8,2).
  • Poiché sia il confronto tra le chiavi che la notifica con il livello di rischio sono avvenuti all'interno dell'applicazione, nessun altro, nemmeno chi controlla il server, può essere a conoscenza di questa informazione. Ricevuta la notifica da parte della propria App, Nicola e Nadia agiranno di conseguenza, in ottemperanza alla loro coscienza e ad apposite direttive sanitarie (per ora non note).
  • Infine, per risparmiare memoria e aumentare la privacy, tutte le chiavi diagnostiche DK ricevute (e le relative chiavi prossimali derivate da queste) vengono rimosse immediatamente dopo il confronto con il database locale. Analogamente, sia il database locale che il server dovrebbero essere periodicamente liberati dalle chiavi più vecchie di alcune decine di giorni (ad esempio, un mese), divenuti ormai inutili ai fini della prevenzione del contagio.

  • Esempi di avvisi generati dalle Tracing App. Le informazioni verranno
    regolamentate dall'Autorità per la Privacy.

  I rischi... connessi

  Dopo aver letto il protocollo di Apple & Google, le iniziali preoccupazioni per la sicurezza e privacy si attenuano significativamente.

  Anzi, probabilmente l'adozione integrale del protocollo poterebbe ad un rischio di tracking dell'utente trascurabile... soprattutto se paragonato a ben altri rischi.

  Proveremo a chiederci quali sono i rischi intrinseci all'adozione globale delle Bluetooth Contact Tracing Applications.

  1. L'incertezza sul reale distanziamento... sociale

  Come è noto ai più, la propagazione delle onde radio e quelle di un virus raramente coincidono.

  Nominalmente, il Bluetooth LTE (BTLE) installato sui nostri smartphone ha un range di circa 10/20 metri in ambiente aperto. Eventuali ostacoli, ancor più della distanza, portano ad una rapida degradazione del segnale. In generale, comunque, la portata del segnale supera sempre il "metro circa" che è il distanziamento sanitario richiesto.

  Vi è poi una vasta serie di scenari di "falsa prossimità": stanze o interi appartamenti separati da pareti sottili, due automobili affiancate al semaforo o le famose "cabine di plexiglass" che dovrebbero essere utilizzate da bar, ristoranti e persino stabilimenti balneari. In tutti questi casi la propagazione Bluetooth procederebbe sostanziamente indisturbata, ma non quella del virus.

  Per mitigare quest'incertezza, dalla versione 1.2 del protocollo di Apple & Google viene associato al messaggio trasmesso via Bluetooth un Metadato (AEM), contenente la potenza in mW del trasmettitore durante la scambio di credenziali. Sebbene ci sia una ovvia correlazione-inversa tra la potenza di trasmissione e la distanza tra due terminali, l'indeterminazione rimane elevatissima. E' esperienza comune che due cellulari differenti "aggancino" dallo stesso punto della casa la medesima cella dell'operatore (es. "Tim #5423 a Corso Francia") con risultati ben diversi: "due tacche scarse" vs. "quattro tacche piene". Il motivo è unicamente legato all'hardware dei dispositivi: antenne più grandi ed efficienti, amplificatori di pessima qualità e rumorosi, posizionamento dell'antenna "dentro" la batteria per diminuire lo spessore ...

  Come esempio dell'indeterminazione, si può immaginare che l'ultimo modello di iPad con schermo da 25'', un'antenna Bluetooth grande quanto un foglio A4 e cablature in argento/grafene si connetta tranquillamente ad una controparte al di là di un muro spesso 20 cm con appena 1 mW di potenza. E che un terminale economico del 2012, dimensione schermo 4x8 cm, in cui un'antenna Bluetooth mignon è utilizzata anche come dissipatore di calore dalla CPU fatichi a connettersi oltre il metro anche erogando 5 mW. Rimango quindi estremamente perplesso che la sola informazione numerica associata "5 dBm" (3 mW) sia dirimente, essendo riferita ad un generico terminale di milioni esistenti ...

  2. Attacchi al Bluetooth

  Non è stato possibile trovare una stima del numero di vulnerabilità note legate al Bluetooth.

  I differenti attacchi possibili sono comunque molte migliaia, in quanto ogni singola vulnerabilità origina decine di attacchi, specializzati sui differenti apparati mobili. Un numero elevatissimo di questi attacchi viene svolto semplicemente iniziando la connessione Bluetooth sul cellulare del malcapitato utente, colpevole soltanto di tenere costantemente "aperto" il suo ricevitore Bluetooth.

  Come esempio dei rischi inerenti, descriveremo SweynTooth, una vulnerabilità scoperta a Marzo 2020, basandoci sull'analisi riportata in questo articolo pubblicato dal Singapore Computer Emergency Response Team (SingCERT).

  La vulnerabilità SweynTooth risiede direttamente nel chipset del ricevitore Bluetooth, posto sulla scheda madre del cellulare. Un attaccante, solo iniziando (o fingendo di iniziare) il pairing, potrebbe mandare in crash un modulo del chip, bypassare lo strato che verifica l'autorizzazione alla connessione ed effettuare un pairing non autorizzato (pairing = condivisione di dati e risorse).

  Altri dettagli qui: https://asset-group.github.io/disclosures/sweyntooth.

  E' necessario evidenziare che molte delle vulnerabilità che affliggono il Bluetooth sono a livello hardware, sul chipset. Non è generalmente possibile alcuna mitigazione via software. Il produttore del circuito elettronico dovrebbe effettuare la modifica direttamente in fabbrica, distribunedo successivamente il componente modificato ai fabbricanti di nuovi telefoni cellulari.

  Tempo totale per la propagazione di una "patch hardware": da alcuni mesi ad alcuni anni.

  Per fortuna, molte altre vulnerabilità sono a livello software, e vengono periodicamente corrette dalle patch integrate nei frequenti aggiornamenti del sistema operativo.

  O, almeno, questo è ciò che dovrebbe succedere ...

  Lo scorso Marzo 2020, ZDNET ha pubblicato uno studio secondo cui "Almeno il 40% degli smartphone dotati di sistema operativo Android non ricevono più aggiornamenti di sicurezza".

  Il numero corrispondente a questa percentuale è impressionante, circa un miliardo di devices sparsi per il mondo.

  Sul fronte IOS i numeri sono un po' più incoraggianti. Ma occorre ricordare che anche in questo caso gli iPhone più obsoleti non ricevono alcun aggiornamento di sicurezza. Ed inoltre nulla si può fare sulle vulnerabilità a livello di chipset.

  Con gli scenari sopra descritti, è prevedibile attendersi nei prossimi mesi un sensibile incremento degli attacchi computi via Bluetooth ai perennemente-connessi ed orgogliosi utilizzatori delle future Contact Tracing App.

  3. Errore nell'implementazione del Framework da parte di Apple & Google.

  I programmatori di Apple o Google (l'interfaccia è identica, ma poi ciascuna compagnia lo implementerà per conto proprio) potrebbero aver commesso qualche errore, che, sfruttato, potrebbe compromettere la sicurezza del Framework. I rischi peggiori sono: il furto della Tracing Key TK e la disabilitazione del rolling delle chiavi (effetto trasponder già descritto).

  Probabilità: relativamente bassa, specie dopo la inevitabile serie di patch che seguiranno la prima versione della piattaforma ...

  4. Mancata futura adesione delle App nazionali al protocollo di Apple & Google.

  "Ormai l'applicazione Turkmenistan Contact Tracing è già scritta e funziona così bene ..."

  Probabilità: N/D

  5. Errore di implementazione nella App.

  Il programmatore incaricato dal proprio governo potrebbe aver commesso qualche errore implementativo, indebolendo un protocollo che, sulla carta, è sicuro ed attento alla privacy.

  Questo punto è tanto più probabile quante sono le aggiunte che vengono fatte alla App, non previste dal protocollo. Vedi il prossimo punto.

  6. Aggiunta di funzionalità non previste dal protocollo.

  I programmatori della App, o il loro committente, dovrebbero astenersi dall'aggiungere all'applicazione qualsiasi funzionalità gli venga in mente: dall'accesso al GPS "per colorare di rosso le zone a rischio" alla possibilità di pagare via App le multe per le violazioni del contenimento, a ricevere il Tweet feed dei commissari per l'emergenza.

  Dietro ciascuna funzionalità aggiunta potrebbe annidarsi un errore di programmazione, quando non direttamente di design. Favorendo eventuali Hacker. Vedi anche il prossimo punto.

  Probabilità: N/D, ma a mio personale avviso piuttosto alta.

  7. Attacco "Hacker" all'infrastruttura.

  È la spina nel fianco di qualsiasi piattaforma disponibile su Internet 24/7. Si va dal semplice (per così dire) tentativo di blocco degli accessi (DOS/DOA, Denial Of Service, Denial Of Availability), al furto dei dati di prossimità, fino a "scalare" ed accedere all'intero contenuto del cellulare (vedi anche gli attacchi via Bluetooth descritti sopra).

  Probabilità (di provarci): esattamente il 100%.
  Probabilità (di riuscirci): dipende dalla perizia di chi ha realizzato l'intera infrastruttra, client, server, autenticazioni... Ed è proprio su questo punto che pagheranno, e non poco, le decisioni prese inerenti al design del sistema e alla minimizzazione dei dati raccolti.

  8. Aggiunta ad una App nazionale di Contact Tracing di una funzionalità non dichiarata di "User Tracking".

  Probabilità: dipende dalla nazione ...

  "Immuni": Il Contact Tracing in salsa italiana

  Spostiamoci nel nostro paese. Per ora la piattaforma di Apple & Google ancora non è disponibile per gli sviluppatori. Intanto, l'azienda milanese Bending Spoons è stata già incaricata dal Governo Italiano di produrre l'applicazione nazionale di Contact Tracing. Per ora se ne conosce il nome, "Immuni", e si sa che farà uso del Bluetooth ma non del GPS e che probilmente aderirà al consorzio PEPP-PT con modalità centralizzata. Ma nulla è certo.

  Dal suo sito Internet, sappiamo che l'azienda è specializzata nello sviluppo di App per lo Yoga ed il fitness indoor. Il sito ufficiale descrive nel dettaglio queste applicazioni mediante foto di modelle in una posa del saluto al sole. Gli esercizi hanno il titolo (o l'ambientazione) di città, ad esempio: "Budapest", "Foggia" o "Mineralnye Vody" (Russia meridionale).

  Immagine tratta dal sito: https://bendingspoons.com/products.html

  Infine, hanno anche un sito consociato, https://30dayfitness.app, che suggerisce esercizi e ricette per "migliorare la propria salute in 30 giorni". In effetti il loro Gazpacho vegano sembra delizioso. Forniscono anche numerosi altri consigli sulla salute, ad esempio sulle proprietà dell'aglio, ma non ho approfondito ...

  Non proprio applicazioni tipiche da paladini di sicurezza informatica e privacy, dunque. Ma non si deve mai giudicare dalle apparenze. Oltre al fatto che l'esperienza maturata nel settore della sensoristica BTLE di fitness è un asset strategico.

  A complicare le cose ci sono altre due considerazioni.

  La prima è che necessariamente la loro App non si basa sul Framework di Apple & Google. Ad oggi tale Framework esiste solo sulla carta, e solo i lettori di questo blog possono creare sul computer di casa il loro prototipo di AppIsInTheAir Occorrerà dunque vedere se la App "Immuni" verrà mai modificata compatibilmente agli aggiornamenti dei sistemi operativi.

  La seconda è che, come già evidenziato, chi sviluppa queste App ha dei requisiti aggiuntivi richiesti dal committente. Tra questi ci potrebbe essere l'approccio centralizzato (gli utenti comunicano ad un server centrale i loro dati in tempo reale, o quasi). In ogni caso ogni complessità aggiunta, specie se non necessaria, contribuisce all'indebolimento della sicurezza e privacy.

  Open source e (falsa) sicurezza

  Si sente spesso la frase per aumentare la sicurezza, tutti i software dovrebbero essere Open source.

  Verissimo. Un software Open source può essere analizzato da esperti e ricercatori, che possono verificare l'assenza di vulnerabilità.

  Queste potrebbero essere state aggiunte di proposito dagli sviluppatori. Esempio: le chiavi crittografiche generate dagli utenti vengono trasmesse al di fuori del proprio terminale (ad un entità di sicurezza nazionale ?)

  Oppure potrebbero essere non intenzionali: per un errore (bug informatico) di un programmatore frettoloso, un attaccante potrebbe inviare dei dati non attesi al programma, che malfunzionerebbe permettendogli l'accesso a dati riservati. Notare che per l'utente finale il risultato nei due casi è un indebolimento della privacy.

  Quello che viene detto meno spesso del dovuto è che il codice sorgente "aperto" non è sufficiente a garantire sicurezza se poi non si ha accesso all'intera supply chain di generazione del programma eseguibile (includendo anche le fasi di compilazione e linking).

  Durante la generazione dell'eseguibile, i sorgenti aperti o chiusi vengono "cuciti" e trasformati nell'App che scarichiamo dal nostro store online. Dal punto di vista della sicurezza, sono fasi non meno critiche dell'analisi dei sorgenti. Anzi, proprio in queste fasi finali potrebbero annidarsi delle vere "trappole". Ad esempio si potrebbe decidere volontariamente di sostituire la componente innocua utilizzata da un programma: "copia un dato in memoria" con una che in realtà "copia un dato in memoria e lo trasferisce a sitomaligno.net".
  Quella descritta qui sopra sarebbe una modifica in fase di linking, e non emergerebbe dall'analisi dei sorgenti.

  Chi volesse approfondire l'argomento può leggersi le vicissitudini dell'azienda russa Kaspersky Lab, produttore di un noto antivirus utilizzato dai governi di mezzo mondo. Poiché il prodotto non è Open source, la Kaspersky Lab si è dovuta "volontariamente" (...) sottoporre ad un audit di sicurezza (SOC-2). Nell'audit, l'ente certificatore Big Four ne ha esaminato l'intera supply chain: sorgenti, linking e compilazione non rilevando particolari problemi.

  Quando un'intera catena di generazione di un applicativo è garantita e riproducibile da terze parti, a partire da zero, dai programmi di base installati sul computer in cui il software viene "impacchettato", si parla di Chain of Trust.

  In conclusione, in assenza di una Chain of Trust riproducibile da chiunque su Internet, o almeno da un ente terzo certificatore, qualsiasi software, anche Open source, è da considerarsi non sicuro.
  Questa osservazione, che è sempre vera, lo è soprattutto in questo momento. Ogni giorni centinaia di applicazioni per PC fisso, App per dispositivi mobili, moduli aggiuntivi e add-on (ad es. per il browser) vengono rilasciati in tutto il mondo con il suffisso "COVID-19". Si parla di un bacino superiore ai quattro miliardi di utenti.

  Conclusioni

  Come illustrato nei precedenti paragrafi, i rischi connessi all'utilizzo globale delle Contact Tracing Applications non sono pochi. Ad oggi, e con così poche certezze, è davvero difficile dire "se il gioco valga la candela".

  Rimanendo in Italia, attendiamo informazioni più dettagliate sul funzionamento della App "Immuni". Se verrà aggiornata o meno per utilizzare il futuro Framework di Apple & Google. Se agirà nell'ottica di assicurare ai suoi milioni di utenti la maggior sicurezza e privacy possibile: approccio rigorosamente decentrato, trasparenza sulla raccolta e conservazione dei dati, sorgenti aperti, Chain of Trust ...

  Come dicevamo all'inizio, i dubbi sono molti. Rimanete sintonizzati.

  Ma soprattutto... rimanete a casa !!

  #mathisintheair

  #iorestoacasa

  ---

  Appendice

  In questa appendice descriviamo alcune primitive crittografiche e due funzioni di utilità che andremo ad utilizzare per la certosina gestione della chiavi del protocollo Apple & Google

  CSPRNG_n()

  CSPRNG: Cryptographically Secure Pseudo-Random Number Generator. Generatore di numeri causali su n-bit, non predicibili.

  Se possibile il generatore dovrebbe essere implementato in hardware, su un apposito chip. Per quanto possa sembrare banale, la generazione di un identificativo casuale è la parte più critica (e quindi meno sicura) di molti sistemi in cui deve essere garantita la privacy.

  Implementazioni:

  • Python: A partire da Python 3.6 è disponibile nella standard library un generatore di numeri casuali affidabili.
  • C/C++: Fare riferimento alla funzione OpenSSL::rand

  HMAC(key, info)

  HMAC: Keyed-Hash Message Authentication Code. Basato sulla specifica IETF RFC 2104.
  Parametri: Funzione di HASH utilizzata: SHA-256.

  Basato su una funzione di hashing (in questo caso: SHA-256), l'HMAC è in grado di offuscare un'informazione a partire da una chiave, compattandola in una versione abbreviata e crittograficamente sicura, il cosiddetto digest.
  Tra le proprietà dell'HMAC, ne ricordiamo due rilevanti in questo contesto:

  • Impossibilità di risalire all'informazione originale a partire dal digest, persino disponendo della chiave.
  • Ripetibilità del processo: disponendo del contenuto informativo originale e della chiave (assunta quindi come chiave pubblica) si riottiene sempre lo stesso digest.

  Viene generalmente utilizzato per la verifica dell'integrità di un contenuto (esempio: firma digitale a chiave simmetrica).

  Implementazioni:

  • Python: A partire dalla versione 2, la libreria di sistema di Python dispone già di un'implementazione di HMAC.
  • C/C++: Fare riferimento alla funzione OpenSSL::HMAC

  HKDF_n(key, info)

  HKDF: Key Derivation Function based on HMAC. Basata sulla specifica IETF RFC 5869.
  Parametri: Risultato troncato su n bit. Funzione di HASH utilizzata: SHA-256. Salt opzionale non utilizzato.

  La derivazione di una chiave crittograficamente sicura a partire da una chiave a bassa entropia e ad un contenuto informativo user-defined è necessaria al fine di rendere il sistema finale meno soggetto ad attacchi di forza bruta. L'utilizzo è quello di derivare le due chiavi RPIK e AEMK, a loro volta utilizzate per ottenere gli identificativi RPI, trasmessi dal terminale.

  Implementazioni:

  • Python: Questa pagina contiene sia un calcolatore di HKDF accessibile via web che i sorgenti dell'implementazione in Python. Ricordare che l'algoritmo di hashing deve essere cambiato da sha512 a sha256 e che il salt non viene utilizzato. Anche wikipedia contiene un'implementazione Python.
  • C/C++: Fare riferimento alla funzione OpenSSL::EVP_KDF-HKDF

  AES₁₂₈(key, data)

  AES₁₂₈_CBC(key, IV, data)

  AES₁₂₈: Block Cipher AES (o Rijndael). Basato sulla specifica ISO-IEC 18033-3.

  AES₁₂₈_CBC: Block Cipher AES₁₂₈ utilizzato in configurazione CBC.

  Parametri: Dimensione del blocco e della chiave: 128 bit.

  Il protocollo sfrutta elegantemente due delle proprietà di un cifratore a blocchi. La prima è che, per chi non ne conosce la chiave, l'output generato dall'algoritmo è pseudorandomico. Pertanto, alimentato con un nonce che non si ripete (un contatore, ad esempio), può essere utilizzato per generare o derivare delle chiavi casuali. La seconda proprietà, ovvia, è che una volta che sia nota la chiave è possibile per qualsiasi controparte decifrare un contenuto cifrato in precedenza.

  La prima proprietà è utilizzata per generare i 144 identificativi giornalieri trasmessi via Bluetooth, RPI, a partire dalla singola chiave giornaliera RPIK. E' una semplice derivazione di una chiave a partire da un'altra, utilizzando come nonce il tempo di validità della chiave creata (10 minuti).

  La seconda proprietà è utilizzata per cifrare in configurazione CBC il Metadato Associato, contenente la potenza del trasmettitore. Se un utente risultasse positivo, alcune sue chiavi giornaliere verrebbero diffuse, permettendo ai suoi contatti la decifrazione di tale metadato ed il calcolo del proprio Livello di Rischio. Come chiave è utilizzata AEMK e come IV l'identificativo RPI, valido solo per 10 minuti.

  Implementazioni:

  • Python: Questa pagina contiene alcuni casi d'uso del block cypher AES in modalità CBC
  • C/C++: Fare riferimento alla funzione OpenSSL::EVP_aes_128_cbc

  ||_m+n

  Operatore di concatenazione || su m+n bit

  Come suggerito dal nome, esegue semplicemente la concatenazione tra due sequenze di m ed n bit.
  La sua implementazione specifica dipende dalla rappresentazione in memoria del tipo dato (es. buffer di bytes, stringhe contenenti le sequenze esadecimali, tipo "57bd", ecc.)

  Esempio: 0000be||ef = 0000beef (in decimale risulterebbe: 190||239 = 48879).

  epoch_time()

  Secondi trascorsi dal 01-01-1970 (contando da 0).

  Unità di tempo un po' "strana". Motivata dal fatto che tutti i linguaggi di programmazione offrono una funzione in grado di restituire il numero di secondi trascorsi dallo scoccare del giorno 01-01-1970. Questa grandezza è chiamata epoch timestamp (o anche: unix time) e convenzionalmente chiameremo questa funzione epoch_time().

  Questo sito web restituisce l'epoch time per qualsiasi data, assieme a numerosi esempi implementativi.

  ENIN()

  Epoch time espresso con una risoluzione degradata a 10 minuti.

  Al fine di ridurre la risoluzione ottenibile dalla App a multipli interi di 10 minuti, aumentando la privacy dell'utente, tutti i calcoli temporali vengono svolti utilizzando il tempo ENIntervalNumber (ENIN). E' semplicemente un contatore convenzionale, ottenuto dalla divisione intera tra l'epoch_time ed i secondi contenuti in 10 minuti (600).

  Esempio: ENIN(2020-05-10 16:32) = 2648547. ENIN(2020-05-10 16:39) = 2648547. ENIN(2020-05-10 16:46) = 2648548.

  Implementazione: ENIN() = (epoch_time() / 600). Essendo / la divisione intera