I pericoli del tracciamento digitale dei contatti: app derivate, pressione sociale e sicurezza

di Enrico Nardelli e Isabella Corradini

(english version here)

Si sta discutendo in questi giorni di come gestire il ritorno alla "normalità" abolendo le misure di distanziamento sociale ma assicurando il controllo della situazione sanitaria. A tal scopo è stato proposto il cosiddetto tracciamento digitale dei contatti, ovvero tenere traccia degli incontri tra le persone in modo tale da poter rapidamente risalire, nel caso in cui una persona venga trovata positiva al test, ai suoi contatti dei giorni precedenti e bloccare ulteriori contagi.

È bene chiarire che il tracciamento dei contatti è una procedura standard dell'OMS per le malattie infettive e viene usualmente condotta in modo manuale dal personale sanitario intervistando la persona infetta. Si sostiene però che nel caso di grandi numeri di infetti la procedura manuale è insufficiente e serve un approccio "automatico" basato appunto sulla tecnologia digitale.

Sfatiamo subito l'idea che la tecnologia possa fare tutto da sola. Lo dice il responsabile dell'unica soluzione di tracciamento dei contatti effettivamente realizzata e che ha funzionato. «Nessun sistema di tracciamento digitale dei contatti può rimpiazzare quello manuale» ha scritto il responsabile del sistema usato a Singapore. Serve comunque dotare il sistema sanitario nazionale di adeguate risorse che sinora non si sono viste e, anzi, nel decennio passato sono state tolte.

Ricordiamo poi che tracciare i contatti vuol dire entrare nella sfera dei dati personali, violare la zona di riservatezza personale garantita da leggi italiane ed europee. Si dice che sia possibile farlo senza violare la privacy. È davvero possibile? Esaminiamo la faccenda dal un punto di vista tecnico, a grandi linee per rendere l'esposizione comprensibile a tutti.

Tracciare automaticamente con cui una persona entra in contatto si può fare in due modi: assoluto e relativo. Si fa in modo "assoluto" appoggiandosi sul gestore della rete di telefonia mobile, che sa costantemente dove sia ogni dispositivo: grossolanamente, se il GPS è spento, con precisione se il GPS è attivo. Mentre in assenza del GPS è in generale difficile stabilire con certezza se il "contatto" sia avvenuto in modo che abbia senso sanitario (se due persone sono a 1 o 10 metri di distanza è epidemiologicamente molto diverso) col GPS questi problemi sono superati. Il gestore potrebbe quindi per ogni numero di telefono registrare l'elenco dei contatti, con durata e posizione. Il problema di questa soluzione è che chiunque viene in possesso di questa lista possiede un controllo sociale enorme, anche in assenza di infezioni. Non è un caso che il tracciamento digitale delle persone, in tutti i paesi democratici, richiede che le forze di polizia debbano preventivamente ottenere, caso per caso, l'autorizzazione della magistratura sulla base di circostanziate evidenze. Autorizzarle per l'intera popolazione vorrebbe mettere in discussione le fondamenta della società democratica.

Vediamo allora la soluzione "relativa". In questa, utilizzando uno dei sensori di comunicazione disponibili sullo smartphone ed un'opportuna app, è ogni dispositivo a registrare localmente l'elenco dei suoi contatti, con durata e posizione. In tal caso nessun soggetto ottiene questo controllo sociale e, si dice, l'app può essere realizzata in modo tale che ogni contatto venga registrato usando un identificativo anonimo e non riconducibile al proprietario. Ma se non li possiamo individuare come potremmo avvisarli di essere stati in contatto con un infetto? Perché sarebbe ogni telefono a determinarlo localmente, utilizzando gli identificativi anonimi degli infetti, che verrebbero distribuiti a tutti da un servizio centralizzato che li ottiene da chi, a seguito dei test, comunica volontariamente di essere infetto.

Però, come molte organizzazioni per la protezione dei diritti civili hanno sottolineato, un'app di questo genere dovrebbe esser realizzata in modo "aperto", ovvero le regole del suo scambio dati con le altre app e tutte le istruzioni che esegue sullo smartphone per tener traccia dei contatti dovrebbero poter essere liberamente esaminate, in modo tale che nessuno corra il rischio di trovare sul suo telefono un'app che fa cose diverse. Però, se l'app è aperta, è in grado di comunicare con ogni altra app che segue le stesse regole.

Allora, immaginate di aver scoperto che siete stati in contatto con un infetto per la prima volta 3 giorni fa. Se quella persona l'avete incontrata anche in tutti i giorni successivi, nella vostra storia locale vi saranno altrettante segnalazioni di persone infette in tutti quei giorni. La app ufficiale magari non dirà niente di tutto questo, ma solo di rivolgersi ad una struttura sanitaria per un controllo. Si può però facilmente immaginare che possa nascere un mercato di app "derivate" che vi offrono queste informazioni (vedi, p.es., un'analisi tecnica). Un'app "derivata" vi dirà, per ogni giorno, quante volte in un quel giorno avete incontrato un certo infetto e se in uno stesso giorno ne avete incontrato uno solo o più di uno. Questa app "derivata" non potrà dirvi se gli incontri dei giorni diversi si riferiscono alle stesse persone ma, considerando che in una situazione di normalità ognuno di noi ha una certa regolarità di incontri e ci sono relativamente pochi infetti in giro, queste informazioni combinate con il ricordo di ciò che avete fatto vi permetterebbero di dedurre parecchio.

Alla nascita di app "derivate" possono contribuire anche motivazioni di natura psicologica e sociale. Da un lato, infatti, il desiderio di sapere, quello che chiamiamo curiosità umana, è una molla potentissima, alla quale pochi sfuggono. Ma c’è in ballo anche la combinazione tra il bisogno di preservare la propria salute e quella delle persone care. Inoltre, il bombardamento quotidiano su regole e comportanti da seguire per tutelare la salute di tutti finisce per sviluppare comportamenti di diffidenza nei confronti dell’ “altro”, talvolta al limite della paranoia. Basta vedere come in questo periodo, camminando per strada, si tende ad aumentare le distanze dagli altri, arrivando persino a cambiare marciapiede. È facile da questo scivolare in un clima di sospetto generalizzato, di cui le cronache quotidiane di vicini e runner denunciati ci hanno già fornito numerosi esempi.

Oltre al problema effettivo di una possibile violazione della privacy, quindi, questo clima di sospetto genera altre considerazioni. Sappiamo, infatti, che la soluzione "relativa" per il tracciamento digitale dei contatti sopra accennata richiede di essere usata da almeno il 60% delle persone, per essere utile. È chiaro quindi che entrerebbe in gioco una fortissima pressione sociale per spingere ad omologarsi nel suo uso e creando pregiudizi nei confronti di chi, per qualunque motivo, decide di non farne uso.

Come ovviare a queste criticità?

(Foto di Gerd Altmann - Pixabay)

L'unica possibilità che intravediamo è quella di usare applicazioni "ufficiali" che "parlano" solo con altre applicazioni ufficiali. Per garantire questo bisognerebbe far sì che le applicazioni ufficiali siano realizzate dalle società internazionali che attualmente hanno il monopolio dei sistemi operativi per la telefonia cellulare (Android e iOS). In un mondo in cui i dati delle persone sono il nuovo petrolio, affidare il controllo della nostra privacy in mano ad aziende che perseguono un obiettivo di business ed hanno un potere economico superiore a quello di molti stati non sembra una mossa vantaggiosa per i cittadini. Non a caso le relative società si sono già mosse in questa direzione. Siamo noi che non dovremmo cedere quei dati digitali che sono ormai parte integrante del nostro essere.

Per completare poi il quadro, va spesa qualche parola sulla sicurezza della tecnologia di base che potrebbe essere usata. Qui le scelte possibili sono solo due: il WiFi e il Bluetooth. Purtroppo, entrambe, nella modalità che dovrebbero essere usate per il tracciamento dei contatti, offrono il fianco a vulnerabilità che potrebbero compromettere l'integrità dei dispositivi digitali mobili.

Richiedere infatti che tutti i cittadini vadano in giro con il Bluetooth (o altra tecnologia) costantemente disponibile per comunicare è di fatto equivalente a chiedere loro di non chiudere a chiave la porta di casa perché deve passare il dottore per una visita medica. Nel mondo reale equivarrebbe ad esporre le case di tutti i cittadini ad un elevato rischio di intrusione. Lo stesso accadrebbe nel mondo digitale, con la differenze che qui tutto accade senza la nostra percezione. I dispositivi di tutti si troverebbero sottoposti a scansioni a tappeto da parte dei "cattivi" che, ormai, non hanno bisogno di essere hacker di professione, dal momento che le cassette degli attrezzi per scardinare le "case digitali" si trovano sul mercato a prezzi abbordabili.

Una volta entrati, il problema non sarebbe più tanto quello relativo ai dati dell'app di tracciamento dei contatti ma quello, più grave, di avere un intruso ostile all'interno di ciò che è ormai strettamente integrato nella nostra esistenza, lo smartphone, depositario di tutti i nostri segreti, personali e professionali. L'unica contro-misura sarebbe aggiornare costantemente il proprio telefono. Ma quanti di noi lo fanno? Vogliamo davvero poggiare la privacy dei cittadini sulla certezza (!?) che abbiano tutti aggiornato il proprio smartphone?

Nelle discussioni in corso si dà per scontato che le soluzioni digitali siano comunque utili, nonostante chi le abbia usate estensivamente perché le aveva già a disposizione, Singapore, abbia dovuto poi mettere il paese in quarantena. Nonostante le organizzazioni internazionali sopra citate abbiano sottolineato la necessità, per misure di questo genere, di effettuare preventivamente valutazioni costi-benefici dei potenziali risultati ottenibili. Dove sono tali analisi?

Gli stati di necessità, cioè quelle situazioni in cui qualche circostanza imprevista costringe ad affrontare problemi eccezionali, sono un terreno privilegiato per il soluzionismo digitale, dal momento che la ristrettezza di risorse e la necessità di “fare presto” premono per accorciare i tempi della decisione. L’emergenza sanitaria che stiamo vivendo è esemplare da questo punto di vista. Basare una soluzione di massa (che ha comunque bisogno per funzionare di tutta di una serie di misure di contorno - come hanno osservato sia il Garante Italiano della Privacy che le varie organizzazioni internazionali) su una tecnologia che ha dimostrato nel corso degli anni di non avere le spalle robuste rispetto alla sicurezza mi sembra una scelta che, anche se "tecnicamente" interessante, sia da rigettare dal punto di vista sociale e politico.

Il problema è analogo a quello di molti altri casi: le soluzioni tecnologiche (ormai sempre più digitali) non sono mai risolutive a meno che non siano compatibili con lo scenario socio-organizzativo, dotate di adeguate risorse finanziarie e materiali, e supportate dalla volontà politica.

Se questi elementi mancano, rimangono solo la distruzione delle relazioni sociali e la svendita della nostra libertà, quindi della democrazia.

On contact tracing apps: the ill-posed question of choosing between health and privacy

by Enrico Nardelli

(versione in italiano qua)

A few days ago I described one of the approaches based on digital technology that is being developed to combat COVID-19, DP-3T, highlighting some elements that should be improved to protect privacy.

I develop here a more general reflection on the impact of technological choices relating to the use of digital solutions for the management of the emergency health situation and the possible return to normality.

The European Commission has published a recommendation in this regard which, in my opinion, is not sufficiently precise in terms of security requirements. In fact, the need for adequate measures to ensure security of collected data is recalled:

• (p.6) «effective cybersecurity and data security measures are essential to protect the availability, authenticity integrity and confidentiality of data»;
• (p.10) «effective cybersecurity requirements to protect the availability, authenticity, integrity and confidentiality of data»;

but nothing is said about the need to guarantee the "basic" security of the technologies used in this data collection process

What's the point? The point is that tracing contacts through apps installed on the smartphone, to ensure precision and privacy, must be based on decentralized solutions where smartphones exchange properly anonymized data which are locally stored.

However, the use of this decentralized approach requires, for its implementation in the current health emergency, to use the only mechanisms to carry out these local communications that are currently installed on almost all smartphones: WiFi and Bluetooth.

Which are the problems? We have been using WiFi for many years now in the "infrastructure" mode to connect us to a local "hot spot": the security of this mode has been extensively tested and appears technologically robust as long as, like any other technological solution, it is not hampered by human shortcomings such as using a weak password to protect access. The "ad hoc" mode, which should instead be used for the interaction of two neighbouring smartphones, has been used - and therefore verified with respect to security - to a largely lower degree. It therefore does not seem to offer, in practice, significantly higher guarantees than Bluetooth's with respect to robustness towards attacks.

Bluetooth is highly vulnerable, as it has long been known. Its use in "local" systems such as the home and the car is tolerable (even if it still poses security challenges) because it is a signal that in smartphones (especially when used in the Low Energy, BLE version) after a few meters has practically disappeared, unlike WiFi. In fact, it consumes much less battery. [Thanks to Francesco Palmieri for an illuminating discussion on these issues.]

Contact tracing using Bluetooth requires citizens to go around with Bluetooth constantly available to communicate: in my opinion this is the equivalent of asking them not to lock their home's door because a doctor is arriving for a medical examination. In the real world, this would amount to exposing the homes of all citizens to a high risk of intrusion. The same would happen in the digital world, with the difference that what happens here is outside our senses' perception. Everyone's devices would be subjected to scanning by the "bad guys" who currently do not need to be professional hackers, since toolboxes for unhinging "digital houses" are available at affordable prices.

Once "bad guys" are inside, the problem would no longer regard contact tracing data but having a hostile intruder within what is now closely integrated into our existence, the smartphone, the custodian of all our secrets, personal and professional.

I have not seen an analysis of these aspects in the ongoing discussions regarding the use of contact tracing apps. They assume digital solutions are still useful. But as observed by the Italian Data Protection Authority in the hearing of 8 April at the Chamber of Deputies regarding contact tracing apps: «Firstly, in assessing the expected effectiveness of a measure one should not fail to consider those supplementary measures, that is to say, the measures envisaged for the reasonably subsequent stage when the individuals identified via data tracing as potentially infected will have to undergo medical tests.
     Indeed, one may well collect all possible information on potential virus carriers (whether in good health or not), but if there are not enough resources (or reagents) to establish whether those carriers do test positive to the virus, then one will not go very far.» (Bold is mine).

It would therefore be desirable that these security aspects related to Bluetooth (or any other technology on which the solutions are to be based) are explicitly analyzed in the evaluation of opportunities on the use of a digital contact tracking system. The same Italian Data Protection Authority observed that is «difficult to impose a general obligation for everyone to use those devices» and therefore «relying on approaches that are based on the voluntary acceptance of the individuals allowing their locations to be traced» is advisable. They added that «the effectiveness of this solution for diagnostic purposes is related to the support received from citizens» and that «it is estimated that at least 60% of the population should give their consent in order to achieve effectiveness» (bold is mine). For Italy (but in general, I think, for each European country) «raising adequate awareness of the advisability of this approach» will therefore be necessary.

It seems clear to me that in the presence of the security problems I have discussed above it will be difficult to convince many people.

Many international associations have in the past few weeks taken stance underlining the importance of carrying out an accurate overall cost/benefits evaluation of the adoption of digital solutions for the management of this health emergency. Here is a non-exahustive list:

• Electronic Frontier Foundation
• European Digital Rights
• Algorithm Watch
• Informatics Europe
• Computer Chaos Club
• American Civil Liberties Union

I really hope that democratic governments realize that asking their citizens to choose between privacy and health, as Yuval Noah Harai wrote, is an ill-posed question.

How the new version - April 10 - of DP-3T works and some reflections on privacy

by Enrico Nardelli

(versione in italiano qua)

The group of researchers who developed the DP-3T protocol for contact tracing in a decentralized way that I recently described has released an update of their documentation.

Now the protocol is presented in two versions. I make reference to the April 10 version of their White Paper.

Version 1 (defined as " low-cost decentralized" ) is substantially equivalent to what I described in the previous post I refer to for shortness. I list here only the changes of some significance:

• the random key SK₀ and the SK_t generated on each subsequent day are locally stored on the device together with the relevant day, to provide an absolute time reference
• the coarse time window stored locally for each encountered device now is only the day
• the authorization code to alert the central server of being infected is given, inactive, to the person at the time of the test. The health authority activates it only when the test result is positive and the patient is notified of the result and the possibility of alerting the server;
• if the person chooses to alert then the app sends to the server all the pairs [SK_t ; day] in the contagious window
• at page 10 of the white paper they write the contagious window starts up «to 3 days before the onset of symptoms» but then at page 16 they write the average width of the contagious windows is 5 days
• the server distributes to all the registered apps all the pairs [SK_t ; day] of the devices of infected people for every day of the contagious window

Since the server continues to distribute directly to all the registered apps the keys allowing them to reconstruct the EphIDs, a device can connect all the EphIDs of the same infected person (which would otherwise be unlinkable) and derive the temporal profile of meetings with this person.


As I observed in my previous post, this could allow, in the case of people who are met with some regularity, to identify who they are. This doesn't require the owner of the device to be a hacker, because I'm sure that if this were the solution used at mass scale, "somebody" would make low cost apps available that can offer this "help" to understand who, of those you encountered, is infected.
     We should always consider that human nature is still the same, despite digital technology advances, and curiousity and self-protection are powerful drivers of human actions.

Version 2 (defined as "unlinkable decentralized") has the same overall structure of version 1 with significant changes to some elements, which are the only ones I describe below, referring to the previous post for an understanding of the overall structure:

• An initial SK₀ key is no longer generated upon installation
• the key SK_t+1 of the following day is no longer calculated applying a predefined hash function H on the key of the previous day SK_t
• instead, a fully new SK_t key is generated every day, which is a random number of 32 bytes
• SK_t is used to derive, using H with argument SK_t, a single EphID_t to be used on that day t during the exchange of contact information with other devices encountered
• the EphID_t of the devices encountered on a certain day t are stored locally in encrypted form KE_t, always using H with arguments both EphID_t and t : in this way it is possible to avoid the direct recording the EphID_t and also to prevent an EphID generated in a different day but accidentally equal to that of day t leads to a "false positive"
• the infected person who decides to send to the central server their pairs [SK_t ; t] can choose for which days / periods to send them, thus obtaining a greater privacy control
• the central server no longer distributes all the pairs [SK_t ; t] of the devices of infected people for every day of the contagious window
• instead, the central server uses the received pairs [SK_t ; t] to compute the KE_t encrypted values ​​corresponding to infected people's devices
• all these KE_t referring to the same day are inserted in a set called ""Cuckoo filter" (CF) which is distributed to all the registered apps
• CF uses very little space and allows to verify with high efficiency whether one of the KE_t that a device has stored in its local contact history belongs to CF or not, that is, corresponds to an infected person or not
• when a device receives CF it checks, for each of the KE_t stored in its local history, if it is included in CF. If not, the answer is definitive, if yes this could be a false positive (i.e., the filter answers "yes" but the truth is "no"), the probability of which can however be made as low as required by means of an a priori tuning of a specific filter parameter

The solution described in this version 2 decreases the probability of identification of an infected person, but does not eliminate it, since if a device X encounters another device Y several times a day, the KE_t of Y appears as many times in the local history of X of his daily meetings (and vice versa).

Also, imagine that you discovered that you were in contact with an infected person for the first time 3 days ago. If you met the same person in all the following days, in your local history there will be as many reports of infected people in all those days.

The official app may not disclose anything of this to you, but only advise you to contact a health facility for a check. However, one can easily imagine that a market of "ancillary" apps offering to compute this data for you could develop. An "ancillary" app will then tell you how many times in a certain day you have met a certain device and if in the same day you have met only one device (of those signalled by the central server as belonging to an infected person) or more than one.

Moreover, while the official app only record the day of the encounter this "ancillary" app might record each encounter with the exact time of the day and will provide similar information for the subsequent days. It will not be able to tell you if the meetings of the different days refer to the same device(s) but, considering the return to normality, where you have a certain regularity of encounters/meetings and there are relatively few infected persons around, this information combined with remembering/reconstructing what you have done would allow you to link devices to people.

Considering that these contact tracing solutions are thought to be used more when people will return to normal life than in the current lockdwon situation the problem is not secondary. With the return to normality, regular daily activities, where we tend to regularly meet people we know, will begin again. And it is precisely in these situations of regular/repeated encounters/meetings that the approach of recording contacts shows its weakness with respect to privacy. I repeat my previous comment: curiousity and self-protection are powerful drivers of human actions.

I close with a couple of reflections.

The first is that for the assumptions in the documentation on the temporal width of the contagious window references to scientific literature are not provided. Furthermore, the fact that they are inconsistent with each other is not comforting.

The second is a side remark that gave me a lot to think about. Speaking of the probability that the "Cuckoo filter" makes a mistake, it is specified that the parameters can be tuned so as to «allow extensive use of the system without errors for several years» (bold is mine) ...

Come funziona la nuova versione di DP-3T, la proposta di tracciamento dei contatti per il COVID-19

di Enrico Nardelli

(per favore consultare anche gli aggiornamenti alla fine del post - english version here)

Il gruppo di ricercatori che ha elaborato il protocollo DP-3T per il tracciamento dei contatti in modo decentralizzato di cui ho recentemente scritto ha rilasciato un aggiornamento della loro documentazione.

Adesso il protocollo viene presentato in due versioni.

La versione 1 (definita "decentralizzata a basso costo", low-cost decentralized) è sostanzialmente equivalente a quanto ho descritto nel post precedente, cui rimando per esigenze di brevità. Elenco solo i cambiamenti di una qualche significatività:

• la chiave casuale SK₀ e quelle SK_t generate in ogni giorno successivo vengono memorizzate sul dispositivo insieme al giorno, per avere un riferimento temporale assoluto;
• il codice di autorizzazione per l'invio dei dati di contatto al server centrale avvisare il server centrale di essere infetta viene comunque consegnato, inattivo, alla persona al momento del test. Solo se il risultato del test è positivo l'autorità sanitaria lo attiva ed avvisa il paziente del risultato e della possibilità di inviare i dati;
• l'app invia al server tutte le coppie [SK_t; giorno] nella finestra di possibile contagiosità;
• si afferma (a pag.8 del "white paper") che tale finestra di possibile contagiosità arriva al massimo a 3 giorni prima di quello di rilevamento dei sintomi ma poi (a pag.14) si parla di finestra di possibile contagiosità di larghezza media di 5 giorni;
• il server distribuisce a tutte le app tutte le coppie [SK_t; giorno] dei dispositivi delle persone infette per tutti i giorni della finestra di possibile contagiosità;

Dal momento che il server continua a distribuire a tutte le app direttamente le chiavi che permettono di ricostruire gli EphIDs, un dispositivo può "rimettere insieme" gli EphIDs di una stessa persona infetta (che sarebbero altrimenti non collegabili) e derivare il profilo temporale degli incontri con questa persona.

Come osservavo nel mio post precedente, questo potrebbe consentire, nel caso di persone che si incontrano con una qualche regolarità, di identificare di chi si tratta. Non c'è bisogno che il possessore del dispositivo sia un hacker, perché sono sicuro che se questa fosse la soluzione utilizzata, comincerebbero a circolare a costi abbordabilissimi app in grado di offrire questo "aiuto" per capire chi, di quelli che in qualche modo si conosce, è infetto.
     Bisogna sempre tener presente che la natura umana è rimasta sempre la stessa, nonostante gli avanzamenti della tecnologia digitale.

La versione 2 (definita "decentralizzata non collegabile", unlinkable decentralized) mantiene l'impianto generale cambiando significativamente alcuni elementi, che sono i soli che descrivo nel seguito, rimandando al precedente post per una comprensione dell'impianto generale:

• NON viene più generata, all'atto dell'installazione, una chiave iniziale SK₀
• la chiave SK_t+1 del giorno successivo NON viene più calcolata mediante una funzione hash H predefinita dalla chiave del giorno precedente SK_t
• ogni giorno viene invece generata una chiave totalmente nuova SK_t, che è un numero casuale di 32 byte
• SK_t viene usata per derivare, usando H con argomento SK_t, un unico EphID_t da usare in quel giorno t durante lo scambio delle informazioni di contatto con altri dispositivi incontrati
• gli EphID_t dei dispositivi incontrati in un certo giorno t vengono memorizzati localmente in forma crittografata KE_t, usando sempre H con argomento EphID_t e t: in tal modo si evita di registrare direttamente gli EphID_t e si evita anche che un EphID generato in un giorno diverso ma accidentalmente coincidente con quello del giorno t conduca ad un "falso positivo"
• il paziente infetto che ha deciso di inviare al server centrale la storia dei suoi contatti le sue coppie [SK_t; t] durante la finestra di contagiosità può scegliere per quali giorni/periodi vuole inviare i dati: questo assicura alla persona un maggior controllo sulla sua privacy
• il server centrale NON distribuisce più a tutte le app tutte le coppie [SK_t; t] dei dispositivi delle persone infette per tutti i giorni della finestra di possibile contagiosità
• il server centrale invece calcola con le coppie [SK_t; t] ricevute dai dispositivi degli infetti i valori crittografati KE_t
• tutti questi KE_t dello stesso giorno sono inseriti in un insieme chiamato "Cuckoo filter" (CF, letteralmente "filtro del cuculo") che viene distribuito a tutte le app
• il CF ha la proprietà di occupare pochissimo spazio e permettere di verificare con elevata efficienza se uno dei KE_t che un dispositivo ha memorizzato nella sua storia locale dei contatti appartiene o meno al CF stesso, cioè corrisponde ad un infetto o meno
• quando un dispositivo riceve il CF controlla, per ognuno dei KE_t che ha incontrato, se è incluso in CF. Se no, la risposta è definitiva, se sì potrebbe esserci un errore, la cui probabilità può però essere abbassata a piacere mediante una regolazione a priori di un apposito parametro

La soluzione descritta in questa versione 2 diminuisce la probabilità di identificazione di un infetto, ma non la elimina, dal momento che se un dispositivo X incontra un altro dispositivo Y più volte al giorno il KE_t di Y compare altrettante volte nella storia locale di X dei suoi incontri giornalieri (e viceversa).

Inoltre, immaginate di aver scoperto che siete stati in contatto con un infetto per la prima volta 3 giorni fa. Se quella persona l'avete incontrata anche in tutti i giorni successivi, nella vostra storia locale vi saranno altrettante segnalazioni di persone infette in tutti quei giorni.

La app ufficiale magari non dirà niente di tutto questo, ma solo di rivolgersi ad una struttura sanitaria per un controllo. Si può però facilmente immaginare che possa nascere un mercato di app "derivate" che vi offrono queste informazioni. Un'app "derivata" vi dirà quindi quante volte in un certo giorno avete incontrato un certo infetto e se in uno stesso giorno ne avete incontrato uno solo o più di uno. Per i giorni successivi vi dirà analogamente se e quanti ne avete incontrati. Questa app "derivata" non potrà dirvi se gli incontri dei giorni diversi si riferiscono alle stesse persone ma, considerando lo scenario di ritorno alla normalità, in cui avete una certa regolarità di incontri e ci sono relativamente pochi infetti in giro, queste informazioni combinate con il ricordo di ciò che avete fatto vi permetterebbero di dedurre parecchio.

Considerando che queste soluzioni di tracciamento dei contatti sono pensate appunto più per la fase di ritorno alla vita normale che per l'attuale fase di quarantena collettiva il problema non è secondario. Con il ritorno alla normalità ricominceranno le regolari attività giornaliere nelle quali tendiamo a incontrare con regolarità persone che conosciamo. Ed è proprio in queste situazioni di incontri regolari/ripetuti che l'approccio di registrare i contatti manifesta la sua debolezza rispetto alla privacy.

Concludo con un paio di riflessioni.

La prima è che le assunzioni che ho letto nella documentazione sulla larghezza temporale della finestra di contagiosità non sono supportate da riferimenti a letteratura scientifica. Inoltre, il fatto che siano tra loro inconsistenti non è confortante.

La seconda è che una nota di passaggio mi ha dato molto da pensare. Parlando della probabilità che il "Cuckoo filter" commetta un errore, viene specificato che i parametri possono essere dimensionati per «permettere un uso estensivo del sistema senza errori per diversi anni» (grassetto mio). A pensar male si fa peccato...

Addendum (11 aprile 14:30 CET): quella descritta in questo post è la versione del 7 aprile. Il 10 aprile è stata rilasciata una nuova versione del "white paper" con una sola modifica rilevante rispetto a quanto descritto nella versione del 7, il fatto che nella storia locale dei contatti si registra solo il giorno del contatto e non una grossolana finestra temporale.

NB: nella prima versione pubblicata veniva erroneamente indicato che la persona infetta inviava la storia dei suoi contatti al server centrale.

Problematiche del tracciamento dei contatti: non dobbiamo scegliere tra privacy e salute

di Enrico Nardelli

(english version here)

Qualche giorno fa ho descritto uno degli approcci basati sulla tecnologia digitale che sta venendo sviluppato per combattere il COVID-19, il DP-3T, sottolineando alcuni elementi che dovrebbero essere migliorati a tutela della privacy. Il gruppo di ricercatori che l'ha elaborato ha rilasciato nuova documentazione e ne darò conto a breve in un successivo post.

Sviluppo invece qui alcune riflessioni più generali sull'impatto delle scelte tecnologiche relative all'uso di soluzioni digitali per la gestione della situazione di emergenza sanitaria e l'eventuale ritorno alla normalità.

La Commissione Europea ha pubblicato una raccomandazione in proposito che, secondo me, non è sufficientemente chiara in termini di requisiti di sicurezza. Viene infatti richiamata la necessità di adeguate misure per garantire la sicurezza dei dati raccolti:

• (p.6) efficaci misure di sicurezza dei dati e di cybersecurity sono essenziali per proteggere la disponibilità, autenticità, integrità e confidenzialità dei dati. («Effective cybersecurity and data security measures are essential to protect the availability, authenticity integrity and confidentiality of data»);
• (p.10) efficaci requisiti di cybersecurity per proteggere la disponibilità, autenticità, integrità e confidenzialità dei dati («effective cybersecurity requirements to protect the availability, authenticity integrity, and confidentiality of data»);

ma non si dice niente sulla necessità di garantire la sicurezza "di base" delle tecnologie che verrano usate.

Qual è il punto? È che il tracciamento dei contatti mediante app installate sullo smartphone, per assicurare precisione e privacy, deve essere basato su soluzioni decentralizzate in cui gli smartphone si scambiano localmente delle informazioni opportunamente anonimizzate.

Ma l'uso di questo approccio richiede, per poter essere attuato durante l'attuale emergenza sanitaria, di usare i soli meccanismi per effettuare tali comunicazioni locali che sono installati al momento su pressoché tutti gli smartphone: il WiFi e il Bluetooth.

Quali sono i problemi? Il WiFi viene, da molti anni ormai, usato in modalità "infrastructure" per connetterci localmente a un "hot spot": la sua sicurezza è stata ampiamente testata ed appare tecnologicamente robusta purché, come tutte le soluzioni tecnologiche, non venga vanificata da mancanze umane tipo l'usare una password debole per proteggerne l'accesso. La modalità "ad hoc", con cui invece esso dovrebbe essere usato per far interagire due smartphone in prossimità, è stata utilizzata - e quindi verificata rispetto alla sicurezza - ad un livello enormemente inferiore. Non sembra quindi offrire, in pratica, garanzie - per quando riguarda la robustezza nei confronti di attacchi - significativamente superiori a quelle del Bluetooth.

Il Bluetooth è fortemente vulnerabile, come da molto tempo è noto. Il suo utilizzo in sistemi "locali" quali la casa e l'auto è tollerabile perché è un segnale che negli smartphone (soprattutto quando usato nella versione Low Energy, BLE), diversamente dal WiFi, a distanza di qualche metro è praticamente scomparso. Infatti consuma molto di meno la batteria. [Ringrazio Francesco Palmieri per un'illuminante discussione su questi temi.]

Pretendere però che tutti i cittadini vadano in giro con il Bluetooth (o altra tecnologia) costantemente disponibile per comunicare è secondo me equivalente a chiedere loro di non chiudere a chiave la porta di casa perchè deve passare il dottore per una visita medica. Nel mondo reale equivarrebbe ad esporre le case di tutti i cittadini ad un elevato rischio di intrusione. Lo stesso accadrebbe nel mondo digitale, con la differenze che qui tutto accade senza la nostra percezione. I dispositivi di tutti si troverebbero sottoposti a scansioni a tappeto da parte dei "cattivi" che, ormai, non hanno bisogno di essere hacker di professione, dal momento che le cassette degli attrezzi per scardinare le "case digitali" si trovano sul mercato a prezzi abbordabili.

Una volta entrati, il problema non sarebbe più tanto quello relativo ai dati dell'app di tracciamento dei contatti ma quello, più grave, di avere un intruso ostile all'interno di ciò che è ormai strettamente integrato nella nostra esistenza, lo smartphone, depositario di tutti i nostri segreti, personali e professionali.

Non mi pare di aver visto nelle discussioni in corso un'analisi di questi aspetti. Si assume che le soluzioni digitali siano comunque utili. Ma come ha osservato il Garante della Privacy nell'audizione dell'8 aprile presso la Camera dei Deputati a proposito delle applicazioni per il tracciamento dei contatti: «In primo luogo, la valutazione dell’efficacia attesa dalla misura non può prescindere da un’analisi inerente le azioni complementari e, dunque, la fase - che dovrebbe ragionevolmente conseguirne - dell’accertamento sanitario dei soggetti individuati, tramite data tracing, quali potenziali contagiati.
    Si possono raccogliere, infatti, tutti i dati possibili sui potenziali portatori (sani o meno che siano), ma se poi non si hanno le risorse (e persino i reagenti!) per accertarne l’effettiva positività, non si va molto lontano.» (Il grassetto è mio).

Sarebbe quindi auspicabile che questi aspetti di sicurezza relativi a Bluetooth (o a qualunque altra tecnologia sulla quale si vogliano basare le soluzioni) siano esplicitamente analizzati nelle valutazioni di opportunità sull'utilizzo di un sistema di tracciamento digitale dei contatti. Lo stesso Garante della Privacy ha osservato è «problematica l'imposizione di un obbligo generalizzato di uso di tali sistemi» e vanno quindi usati «sistemi fondati sulla volontaria adesione dei singoli». Ha aggiunto che «l’efficacia diagnostica di tale soluzione dipende, in ogni caso, dal grado di adesione che essa incontra tra i cittadini» e che «la percentuale minima per l’efficacia è stimata nell’ordine del 60%» Per il nostro Paese (ma in generale, penso, per ogni paese europeo) sarà quindi necessaria «un’adeguata sensibilizzazione sull’opportunità di ricorrere a tale tecnica».

A me sembra lampante che in presenza dei problemi di sicurezza che ho sopra discusso sarà difficile convincere molte persone.

Le numerose prese di posizioni che vi sono state nei giorni passati a livello internazionale da parte delle associazioni di difesa dei diritti civili sull'utilizzo delle tecnologie digitale per la gestione di questa emergenza sanitaria hanno TUTTE sottolineato l'importanza di effettuare un'accurata valutazione costi-benefici complessiva della loro adozione. Ecco un elenco non esaustivo di tali documenti:

• Electronic Frontier Foundation
• European Digital Rights
• Algorithm Watch
• Informatics Europe
• Computer Chaos Club
• American Civil Liberties Union

Spero davvero che i governi democratici si rendano conto che dover scegliere tra la privacy e la salute, come ha scritto Yuval Noah Harai, è una questione mal posta.

Digital transformation and political action

by Enrico Nardelli

(versione italiana qua)

The emergency we are living through is bringing to a head a series of issues that were never properly addressed in previous years regarding "digital transformation." This term has for some time become fashionable, especially among politicians, the vast majority of whom have no idea what it actually means or how it is genuinely achieved.

The problem is first and foremost a cultural one, because digital technology is different from all the technologies that preceded it. The revolution brought about by informatics — the science that makes the digital possible — is unlike any previous revolution. "Digital machines" are amplifiers of people's rational cognitive capacities and are therefore radically different from all the machines previously built by human beings, which only augment physical capabilities. After centuries of technological progress, this revolution has swept through society within the short span of two decades — too rapidly for the ruling class to grasp its true scope.

The most important aspect is this: whereas in "physical" automation there is always a human being who remains in command of the machine and helps it interpret the surrounding reality, when "cognitive" automation — that of digital machines — was introduced, the mistaken belief took hold that computing systems could completely replace people and "do everything on their own." This is impossible, because every human being is capable of learning from experience and adapting to changed operational conditions — a general ability that is innate in human beings but entirely unknown to digital machines. Every time something changes, the system needs to be reworked. Since change is the only certainty in life, disasters are guaranteed. Manufacturers of consumer devices — smartphones, for example — get around this through planned obsolescence, which "gently" induces users to replace them every two or three years. But the computing systems that are now indispensable to the functioning of any organisation cannot be renewed in this way.

In the 1990s, the digitisation of public administration concerned mainly internal processes, and so the problems remained on the whole hidden from the general public — one could, so to speak, keep dirty laundry behind closed doors. From the following decade onwards, however, with the pervasive spread of the Web through society, the situation became explosive.

It was not understood that, faced with a revolution of far more dramatic social scope than those brought about by television or the automobile, a serious programme of digital literacy for Italians needed to be launched. Conference after conference was held on the theme of "It's Never Too Late 2.0," without investing real resources in this education — on the assumption that all the necessary information was in any case available online.

A necessary condition for the success of any digital transformation is: "no digitalization without end-user representation." I have written this in English to invoke explicitly one of the eighteenth-century slogans that underpinned the revolution of the English colonies against the mother country: "no taxation without representation." In our context, it means that if the end user is not involved — and on the web the end user is everyone, from the scholar to the factory worker, both united by having been overtaken by a technological revolution that happened too fast for them to assimilate it — the system works badly. I am sure each of us has a favourite example of a web system that demands an enormous amount of patience and self-control to complete operations that, when speaking to a counter clerk, would have been done in half the time and with no stress whatsoever.

The approach that followed was to draw up magnificent plans for the digital "something" — where "something" might be "schools" or "healthcare" or "justice" (or whatever happened to be of interest to the government of the day) — without reflecting that an epochal change of this kind cannot be implemented quickly, because it requires thorough training of people. Only in the films of Matrix does one plug in a cartridge and instantly become an expert: human beings, by contrast, need time to learn, especially when they are simultaneously continuing to do their jobs and live their lives.

It was not understood that before digitising a work process, one must have analysed it in depth and understood how its automation will affect the organisation of work, internal power relationships, and external ones. Instead, the belief took hold that IT services could be outsourced, thereby saving on staffing — only to discover that one ended up spending more to adapt the outsourced services to every minor change in the surrounding reality, changes that any employee or middle manager would have handled in a fraction of the time.

There was not the humility to understand that one had to start from the fundamentals — from those infrastructures that are the equivalent, for an organisation, of what a skeletal or nervous system is for a mammal. I was struck, in these days when we have all been compelled to make intensive use of digital devices and systems, to see that in 2020 the decrees of the President of the Council of Ministers are being circulated via SlideShare, his speeches broadcast on Facebook, and schools conducting lessons on Google and Microsoft platforms — to give just a few examples. I have nothing against digital multinationals, let me be clear: they are companies doing their job. I am not happy, however, about the fact that our politics over the past two decades has been unable to build its own basic infrastructure for a digital country.

There is no point in thinking we can turn back. Society will become increasingly digital. What we can still recover is control over the indispensable infrastructure — which must be in our hands if our country is not to become a colony. The digital is an integral part of our society and must be managed in the national interest. We must also maintain control over citizens' digital data, which in the digital world is the equivalent of the citizens themselves. "What would we call rulers who sold their own citizens to foreign powers?" I asked some time ago. Given that across Europe and beyond there is currently discussion of implementing "individual tracking" measures to monitor the spread of the epidemic, and considering that data is the new oil, it is clear that if we do not want to end up like the Third World countries bled dry by the "seven sisters," we need to change our approach.

And yet this should not be so difficult for those in politics. Technology has always been at the service of politics in order to implement this or that decision. In every era and country, those who have sought to bring technicians into government — presenting them as priests of impartiality — have always in reality sought to strip from the people (the "demos") the power (the "cratos") to hold government to account. They have thus acted in an anti-democratic manner. Digital technology is no exception to this. Computing systems are not inherently neutral. Digital transformation is not an absolute guarantee of efficiency and effectiveness.

Politics must decide how to govern it, in full awareness that epochal changes of this magnitude are not achieved within the few years of a parliamentary term or through unrealistic plans. For this reason, once the emergency has passed, a cross-party agreement on a plan for the country's digital development will be needed — one that commands broad consensus, at least on some fundamental guiding principles. What is required, therefore, are politicians who genuinely care about democracy and the future of our country, who are capable of listening to what technology has to offer, of understanding the possible social impacts, and of forging a synthesis of the needs of different social classes in the interest of all.

I am convinced that in every party there are people of goodwill and great political ability.

--
The original version (in italian) has been published by "Key4Biz" on 6 April 2020.

Trasformazione digitale e azione politica

di Enrico Nardelli

(english version here)

La situazione di emergenza che stiamo vivendo sta facendo venire al pettine una serie di nodi mai affrontati negli anni passati a proposito di “trasformazione digitale”. Questo termine da un po’ di tempo a questa parte è diventato di moda, soprattutto tra i politici, che però in grandissima maggioranza non hanno idea di cosa voglia dire e di come si realizzi davvero.

Il problema è prima di tutto culturale, perché quella digitale è una tecnologia diversa da tutte le altre che l’hanno preceduta. La rivoluzione prodotta dall’informatica (la scienza che rende possibile il digitale) è diversa da ogni precedente rivoluzione. Le “macchine digitali” sono amplificatori delle capacità cognitive razionali delle persone e quindi radicalmente differenti da tutte le macchine precedentemente realizzate dall’uomo, che ne potenziano solo le capacità fisiche. Dopo secoli di progresso tecnologico, questa rivoluzione è dilagata nella società nel breve intervallo di un ventennio, quindi troppo velocemente perché la classe dirigente riuscisse a comprenderne la portata.

L’aspetto più importante è che mentre nell’automazione “fisica” c’è sempre un essere umano che rimane al comando della macchina e che la aiuta nell’interpretazione della realtà circostante, quando si è introdotta l’automazione “cognitiva” (quella delle macchine digitali) si è erroneamente creduto che i sistemi informatici potessero completamente sostituire le persone e “fare tutto da soli”. Impossibile, perché ogni essere umano è in grado di apprendere dall’esperienza ed adattarsi a mutate condizioni dello scenario operativo, mentre questa generale abilità, che è innata nell’essere umano, è sconosciuta alle macchine digitali. Ogni volta che cambia qualcosa, bisogna rimettere le mani sul sistema. Siccome l’unica certezza della vita è il cambiamento, le catastrofi sono assicurate. I venditori di dispositivi per l’utente finale (p.es., gli smartphone) se la cavano mediante l’obsolescenza programmata, per cui ogni due o tre anni siete “gentilmente” indotti a cambiarlo. Ma i sistemi informatici che sono ormai indispensabili al funzionamento di ogni organizzazione non possono essere rinnovati in tal modo.

Negli anni 90 l’informatizzazione della Pubblica Amministrazione ha riguardato soprattutto processi interni e, quindi, i problemi rimanevano tutto sommato nascosti al grande pubblico e, per così dire, si potevano “lavare i panni sporchi in casa”. A partire dal decennio scorso, però, con la capillare diffusione del Web nella società la situazione è diventata esplosiva.

Non si è capito che, a fronte di una rivoluzione di portata ben più drammatica, dal punto di vista sociale, di quelle causate dalla televisione o dall’automobile, andava fatto partire un serio programma di alfabetizzazione digitale degli italiani. Si sono riempiti convegni su convegni sul tema “Non è mai troppo tardi 2.0” senza investire risorse reali su questa istruzione, ritenendo che tanto tutte le informazioni necessarie fossero disponibili sulla Rete.

Un requisito necessario per il successo di ogni trasformazione digitale è: “no digitalization without end-user representation”. L’ho scritto in inglese per richiamare in modo esplicito uno dei motti del Settecento che sono stati alla base della rivoluzione delle colonie inglesi contro la madrepatria: “no taxation without representation”. Nel nostro caso vuol dire che se non si coinvolge l’utente finale, che sul web è chiunque, dal letterato all’operaio, entrambi accomunati dall’essere stati investiti da una rivoluzione tecnologica avvenuta troppo in fretta perché potessero assimilarla, il sistema funziona male. Son sicuro che ognuno di noi ha il suo esempio favorito di sistema web che richiede un enorme dose di pazienza ed autocontrollo per riuscire a portare a termine operazioni che, parlando con un addetto allo sportello, si sarebbero completate in metà del tempo e stress nullo.

Si è poi proseguito elaborando bellissimi piani per la “cosa” digitale, dove “cosa” poteva essere “scuola” o “sanità” o “giustizia” (o qualunque nome di interesse per il governo di turno) senza riflettere che un cambiamento epocale di questo tipo non si attua in poco tempo, perché richiede un’approfondita formazione delle persone. Solo nei film di “Matrix” ci si innesta l’apposita cartuccia e si diventa subito esperti: gli esseri umani hanno invece bisogno di tempo per apprendere, soprattutto se contemporaneamente stanno continuando a fare il loro lavoro e vivere la loro vita.

Non si è capito che prima di informatizzare un processo lavorativo bisogna averlo analizzato in profondità ed aver compreso come la sua automazione impatti sull’organizzazione del lavoro, sui rapporti di potere interni e su quelli esterni. Si è invece pensato che si potessero esternalizzare i servizi informatici, risparmiando sul personale, salvo poi scoprire che si finiva con lo spendere di più per adattare i servizi esternalizzati ad ogni minimo cambiamento della realtà circostante, che qualunque impiegato o quadro avrebbe saputo gestire in una frazione del tempo.

Non si è avuto l’umiltà di capire che bisognava cominciare dagli elementi fondamentali, da quelle infrastrutture che costituiscono l’equivalente, per un’organizzazione, di quello che è un sistema scheletrico o nervoso per un mammifero. Sono rimasto colpito, in questi giorni in cui siamo stati tutti costretti ad usare intensamente dispositivi e sistemi digitali, dal vedere come nel 2020 i decreti del Presidente del Consiglio dei Ministri vengano diffusi mediante SlideShare, i suoi discorsi trasmessi su FaceBook, le scuole facciano didattica su piattaforme Google e Microsoft, solo per fare alcuni esempi. Non ho niente contro le multinazionali del digitale, sia ben chiaro, sono aziende che fanno il loro mestiere. Non sono però contento del fatto che la nostra politica in questo ventennio non sia stata in grado di realizzare proprie infrastrutture di base per un Paese digitale.

È inutile pensare di poter tornare indietro. La società diventerà sempre più digitale. Quello che possiamo ancora recuperare è il controllo sulle infrastrutture indispensabili, che deve essere in nostre mani affinché il nostro Paese non diventi una colonia. Il digitale è parte integrante della nostra società e deve essere curato nell’interesse nazionale. Dobbiamo inoltre mantenere il controllo sui dati digitali dei cittadini, che nel mondo digitale sono l’equivalente dei cittadini stessi. Come chiameremmo quei governanti che vendessero i propri cittadini a poteri stranieri? chiedevo qualche tempo fa. Dato che in questi giorni in tutta Europa (e non solo) si sta discutendo di realizzare misure di “tracciamento individuale” per tenere sotto controllo la diffusione dell’epidemia e considerando che i dati sono il nuovo petrolio, è chiaro che se non vogliamo fare la fine dei paesi del Terzo Mondo svenati dalle “sette sorelle” dobbiamo cambiare approccio.

Eppure non dovrebbe essere così difficile, per chi fa politica. La tecnica è sempre stata al servizio della politica per poter implementare questa o quella decisione. In ogni epoca e paese, chi ha voluto portare i tecnici al governo, presentandoli come sacerdoti dell’imparzialità, ha sempre in realtà voluto sottrarre al popolo (al “demos”) il potere (il “cratos”) di controllare l’operato del governo. Si è mosso quindi in modo anti-democratico. La tecnica digitale non fa eccezione a questo. I sistemi informatici non sono intrinsecamente asettici. La trasformazione digitale non è garanzia assoluta di efficienza ed efficacia.

La politica deve decidere come governarla ben sapendo che cambiamenti epocali di questa portata non si realizzano nei pochi anni di una legislatura e con piani irrealistici. Per questo sarà necessario, una volta superata l’emergenza, un accordo trasversale su un disegno di sviluppo digitale del Paese che trovi tutti concordi, per lo meno su alcune linee guida fondamentali. Servono dunque politici che abbiano a cuore la democrazia ed il futuro del nostro Paese, che siano in grado di ascoltare cosa la tecnica ha da offrire, di capire quale siano i possibili impatti sociali, e di comporre una sintesi delle esigenze delle diverse classi sociali nell’interesse di tutti.

Io sono convinto che, in tutti i partiti, ci siano persone di buona volontà e grande capacità politica.

--
Versione originale pubblicata su "Key4Biz" il 6 aprile 2020.

How DP-3T, a solution aiming at fighting COVID-19 through privacy-preserving proximity tracing, works (as far as I've understood)

by Enrico Nardelli

(please read also updates at the end and the description of the April 10 version)

Here I describe what I have understood – on the basis of documents published until yesterday - about how the proposed solution for fighting the spread of COVID_19 by privacy-preserving tracking proximity contacts (PEPP-PT: Pan-European Privacy Preserving Proximity Tracing, also indicated known as DP-3T: Decentralized Privacy-Preserving Proximity Tracing works. I might have misunderstood some elements, and should this be the case, I’ll update this post.

In my previous post I have discussed some of the other non-technical issues of technical solutions based on contact tracing. I add here only one consideration that I would like to stress (and was stressed also in many documents cited in my previous post – most notably the Algorithm Watch's one). Knowing whom someone has been in contact with, during the days leading up to the day they were found infected, is only useful if the diagnosis arrives early enough to notify their contacts BEFORE they contact other people. If an average person comes in contact with 10 others during a day (note that being in contact does not mean being close and chatting, but having been in the same office, shop, premises, means of transport, etc.), an infected person generates at the second day 100 potential infected ones, 1,000 at the third one and 10,000 at the fourth. If only today one realizes that 5 days ago a person was infected, then one has to test 10,000 people TODAY (or ask 10,000 people to self-isolate) to avoid having tomorrow 100,000 potentially infected person. Not impossible, if a country is prepared, but it is not something that can be arranged in some days or a few weeks. It is no coincidence that in China, where this approach has been successfully used, it is since the SARS epidemic of 2003 that they are working on this.

The basic idea of PEPP-PT DP3-T is to install, on the smartphone of those who decide to participate, an app using Bluetooth to interact with other smartphones nearby, recording anonymously that they have been in contact each other. A central server periodically updates all the apps with anonymous information about who has been infected, allowing each smartphone to find out if it has been close to an infected person, but without allowing it to find out who is.

Let's discuss now the most relevant technical aspects, as I’ve understood them and assuming my understanding is correct. I’ll gladly correct any mistake I might have done. I don't discuss all the details for space reasons. The reader wishing to know more can consult their technical documentation.

Upon installation, the app generates a key, which is a 32-bit random SK₀ number, and registers with a central server with an ID different from SK₀ and used by the server only to contact all registered apps for periodic updates related to infected people. Each app renews its key every day, calculating a new 32-bit random number SK_{t + 1} using a predefined hash function H1 having SK_t as its argument. The use of H1 ensures that, given the random number used in a day, it is not possible to calculate the one used the day before. The app stores the last 14 SK_t used, because 14 days are considered necessary for the infection to develop. Such value can be changed if health authorities deem it appropriate.

Each day the app uses SK_t to generate, through a different hash function H2, a certain number of "ephemeral identifiers" EphIDs that will be used only that day to record the contacts of that day only. When two phones, through Bluetooth, understand that they are close, then the two apps exchange their EphIDs. They are stored locally together with a coarse time indication (the documentation is not explicit, let's say a 4 hour time window), together with the strength of the Bluetooth signal received (which is an indicator of the distance between the devices) and the time spent in proximity. Again, the use of H2 does not allow to derive from received EphIDs the SK_t used to generate them, not even knowing all the EphIDs used during the same day by the same device, nor does it allow to understand if two EphIDs received on the same day are generated by the same SK_t.

Every day the app erases data older than 14 days, both the SK_t and the EphIDs of the phones it has been close to, together with the data associated with the received EphIDs.

When a person is found out infected by a medical test, he receives an authorization code from the health authority, which he can use – if he chooses to do so – to alert the central server. In such a case, the app uses this authorization code to securely send the SK_t used in the presumed initial day of the infection, let's say that of 14 days ago or the oldest on record. To prevent the mere happening of this communication discloses to external observers that the person is infected, it is done in the context of communications the app send to the server several times during the day at regular intervals. They are indistinguishable from an external viewpoint, but only one of them contains the SK_t. When the app communicates to the central server the device owner is infected, it simultaneously generates a new initial key, that is, a new 32-bit random SK₀ number, which will be used from that moment on in the contact tracing mechanism.

When the server receives an infection report, the SK_t received is broadcasted, as part of the periodic updates, to all smartphones that have the app installed. Each app then locally calculates for each received SK_t, corresponding to the device of an infected person, both the EphIDs of that day (using the hash H2 function) and the SK_t of the subsequent days up to the current day (using the hash function H1) together with their corresponding EphIDs. All the EphIDs locally calculated by the app in this way are used to search in the stored data if the device have been in contact with that of an infected person. In this case, on the basis of the data (distance and duration) stored with EphIDs an algorithm present in the app (using parameters that can be adjusted by the health authority) can calculate a risk index for the smartphone owner who is therefore, on the basis of this index, advised on what to do.

This element of distributing SK_t of devices owned by an infected person is in my opinion a weak point with respect to privacy. In fact, when an app receives an SK_t of an infected person, by calculating through H1 the SK_t of the following days and through H2 the corresponding EphIDs, could discover the identity of the person, because it can relate different EphIDs, which are otherwise unrelated, to the same original SK_t. This is not difficult to do, especially in the case of people who are regularly met or for whom, perhaps for work reasons, meeting have been recorded in one’s own agenda. The server should instead broadcast directly the EphIDs, given the increase in transmitted data appears not to be able to significantly worsen overall performances.
     In addition, the central server stores the received SK_t. This also seems to me a weak point because, even if all those smartphones have changed keys, their stored SK_t could be used (in case of data breach) to relate EphIDs that are otherwise unrelated to the same device.

Another element of perplexity, not regarding the mechanism per se but technologies it is based on, is the fact that the Bluetooth protocol is known to be not so robust against attackers (thanks to Francesco Palmieri for pointing it out). Adopting the described mechanism on millions of devices would imply forcing them into a vulnerable situation.

Addendum (April 6th, 17:10 CET). Michael Vaele, one of the researchers of the DP-3T team (wrongly called DPT in the first edition of this post) pointed me on Twitter that «the DP-3T protocol is not PEPP-PT. PEPP-PT is an empty shell, to be filled. We try to fill with decentralised.» I have therefore updated the initial paragraph and the title, making now reference just to DP-3T. My analysis stays the same, since it is the documentation from DP-3T (link on the first line of this post) what I analyzed. Also, I would like to point out that the description of PEPP-PT on their site coincides with the high-level-description of DP-3T protocol and IS decentralized (see picture below).

Addendum (April 9th, 19:00 CET). DP-3T has released a new version of their white paper (which I'm currentl analyzing), a clarification of the relations between DP-3T and PEPP-PT, and a set of answers to issues raised (by me and other researchers) in this FAQ. My issue about broadcasting SK_t of devices owned by an infected person is (I think) covered in FAQ P6. I've written "I think" given the actual title of P6 is «Why do infected people upload a seed (which enables recreating EphIDs) instead of their individual EphIDs?»

In itself uploading the seed does not give away anonymity of the infected person, given this seed was randomly generated when the app was installed. The problem I signalled lies in the fact that the backend server brodcasts this seed instead of the derived EphIDs. The answer given in the FAQ discuss anyhow the issue using performances argument, which I find reasonable, in principle. But given privacy is involved here, I remain convinced the protocol SHOULD NOT broadcast the seed but only the the EphIDs.

So the title should be «Why do the backend broadcasts the seeds of infected persons (which enables recreating EphIDs) instead of their individual EphIDs?». I've asked them for clarification and I'll update you on the issue.

Come funziona DP-3T, la soluzione che vuole combattere il COVID-19 col tracciamento dei contatti

di Enrico Nardelli

(per favore consultare anche gli aggiornamenti alla fine del post e la descrizione della nuova versione)

Ecco quello che ho capito di come funziona la soluzione proposta per il tracciamento dei contatti di prossimità rispettosa della privacy (PEPP-PT: Pan-European Privacy Preserving Proximity Tracing, descritta anche nota come DP-3T: Decentralized Privacy-Preserving Proximity Tracing) che sta venendo proposta in questi giorni come la soluzione necessaria per combattere la diffusione del COVID-19.

Nel mio post precedente ho discusso alcune delle altre problematiche non tecniche di una tale soluzione.

Aggiungo qui una sola considerazione che richiede di essere sottolineata. Sapere con chi è stata in contatto una persona infetta nei giorni precedenti quello in cui è stata diagnosticata serve soltanto se la diagnosi arriva abbastanza presto per avvisare i suoi contatti PRIMA che essi contattino altre persone. Se una persona mediamente viene in contatto con altre 10 durante un giorno (attenzione che essere in contatto non vuol dire fermarsi a parlare, ma essere stati nello stesso ufficio, negozio, locale, mezzo di trasporto, etc), un infetto genera al secondo giorno 100 potenziali infetti, al terzo 1.000 e 10.000 al quarto. Se mi accorgo solo oggi che 5 giorni fa quella persona era infetta devo fare OGGI 10.000 tamponi (o chiedere a 10.000 persone di auto-isolarsi) per evitare di trovarmi domani con 100.000 potenziali infetti. Non impossibile, se ci si è preparati, ma non è qualcosa che si organizza in qualche giorno o in poche settimane. Non è un caso che in Cina è dall'epidemia di SARS del 2003 che stanno lavorando su questo.

L'idea di base di PEPP-PT DP-3T è installare su ogni smartphone di chi vuole partecipare un'app che usa il Bluetooth per interagire con altri smarthpone nelle vicinanze registrando reciprocamente che si è stati in contatto. Il tutto mantenendo l'anonimato. Un server centrale periodicamente aggiorna tutte le app con informazioni anonime relative a chi è stato infettato, permettendo ad ogni smartphone di scoprire se è stato vicino ad un infettato, ma senza consentirgli di scoprire chi sia.

Andiamo agli aspetti tecnici più rilevanti. Non discuto tutti i dettagli per motivi di spazio. Chi volesse approfondire può consultare la loro documentazione tecnica.

All'atto dell'installazione l'app genera una chiave, che è un numero casuale SK₀ di 32 byte, e si registra presso un server centrale, cui però non invia SK₀ ma un'altro ID che il server centrale usa solo per gli aggiornamenti periodici relativi agli infetti. A partire da quando è stata installata l'app, ogni giorno la chiave viene rinnovata, calcolando un nuovo numero casuale di 32 byte SK_t+1 mediante una funzione hash H1 predefinita che ha come argomento SK_t. L'uso di H1 garantisce che dato il numero casuale di un giorno non sia possibile calcolare quello del giorno prima. L'app memorizza le ultime 14 SK_t usate, perchè 14 giorni sono ritenuti il tempo necessario per l'infezione per svilupparsi. Il valore 14 può essere modificato se le autorità sanitarie lo ritengono opportuno.

Il numero casuale di ogni giorno SK_t viene usato per generare, attraverso una diversa funzione hash H2, un certo numero di "identificatori effimeri" EphID che saranno usati solo quel giorno per registrare i contatti avuti durante solo quel giorno. Quando due telefoni, attraverso il Bluetooth, capiscono di essere vicini allora le due app si scambiano gli EphID che vengono memorizzati localmente insieme ad un'indicazione temporale grossolana (la documentazione non è esplicita, diciamo una finestra temporale di 4 ore), alla forza del segnale Bluetooth ricevuto (che è un'indicatore della distanza tra i dispositivi) e al tempo di vicinanza. Di nuovo, l'uso di H2 non consente di risalire dagli EphID al SK_t usato per generarli, neanche conoscendo tutti gli EphID usati durante una stessa giornata, né permette di capire se due EphID ricevuti nello stesso giorno sono relativi ad uno stesso SK_t.

Ogni giorno l'app cancella i dati più vecchi dei 14 giorni, sia gli SK_t che gli EphID dei telefoni cui è stato vicino, che i dati associati agli EphID ricevuti.

Quando una persona scopre da un controllo medico di essere infetta riceve un codice di autorizzazione dall'autorità sanitaria, che può scegliere di usare per avvisare il server centrale di essere infetta. In tal caso l'app utilizza il codice per inviare in modo sicuro lo SK_t relativo al presumibile giorno di inizio dell'infezione, diciamo che sia il più vecchio che conserva, quello di 14 giorni fa. Per evitare che la semplice esistenza di tale comunicazione sveli ad osservatori esterni che la persona è infetta, essa viene fatta nell'ambito di comunicazioni che la app fa al server più volte durante il giorno a intervalli regolari. Esse ad un esame esterno sono indistinguibili, ma solo una di esse contiene lo SK_t. Quando la app effettua la comunicazione al server centrale relativa all'infezione essa contestualmente genera un nuova chiave iniziale, cioè un nuovo numero casuale SK₀ di 32 byte, che verrà usato dal quel momento in avanti nel meccanismo di tracciamento dei contatti.

Quando il server riceve una comunicazione di infezione, lo SK_t ricevuto viene, nell'ambito degli aggiornamenti periodici, inviato a tutti gli smartphone che hanno l'app installata. Ogni app quindi calcola per ogni SK_t ricevuto, che corrisponde ad un infetto, sia gli EphID di quel giorno (usando la funzione hash H2), che gli SK_t dei giorni successivi fino al giorno corrente (usando la funzione hash H1) e i loro corrispondenti EphID. Tutti gli EphID calcolati in questo modo vengono usati per cercare nei contatti memorizzati se si è stati in contatto con qualche infetto. In tal caso, sulla base dei dati di contatto (distanza e durata) un algoritmo presente sull'app (che usa parametri aggiustabili dall'autorità sanitaria) può calcolare un'indice di rischio per il possessore dello smartphone che viene quindi, sulla base di tale indice, consigliato su cosa fare.

Quest'ultimo elemento della distribuzione degli SK_t è secondo me un punto debole rispetto alla privacy. Infatti, quando un app riceve un SK_t di un infetto può, calcolando mediante H1 gli SK_t dei giorni successivi e mediante H2 gli EphID corrispondenti, arrivare a scoprire l'identità della persona, perché può ricondurre diversi EphID, che sono intrinsecamente scorrelati, ad uno stesso SK_t originale. Ciò è vero ovviamente soprattutto nel caso di persone che si incontrano con una qualche regolarità o per le quali, magari per ragioni di lavoro, si sono annotati nella propria agenda gli appuntamenti svolti.
     Inoltre, il server centrale memorizza gli SK_t ricevuti. Anche questo mi sembra un punto debole perché, anche se tutti quegli smartphone hanno cambiato chiave, i loro SK_t possono essere usati per ricondurre ad uno stesso dispositivo degli EphID che sono altrimenti scorrelati.

Ho chiesto chiarimenti su questi elementi al team che ha messo a punto lo schema e pubblicherò quanto riceverò.

Addendum delle 20:50 CET: Francesco Palmieri mi ha segnalato che il protocollo Bluetooth è noto per essere abbastanza vulnerabile. Avere la soluzione sopra descritta installata su milioni di dispositivi con Bluetooth costantemente attivo vorrebbe quindi dire avere milioni di dispositivi esposti ad attacchi.

Addendum del 6 aprile 17:30 CET: Michael Vaele, uno dei ricercatori del team DP-3T (erroneamente chiamato DPT nella prima versione di questo post) mi ha scritto su Twitter che «the DP-3T protocol is not PEPP-PT. PEPP-PT is an empty shell, to be filled. We try to fill with decentralised.» Ho quindi aggiornato il paragrafo iniziale e il titolo, facendo adesso solo riferimento a DP-3T. La mia analisi non cambia, dal momento che era comunque la documentazione del DP-3T (link sulla prima linea di questo post) quella che avevo analizzato. Inoltre, desidero precisare che la descrizione di PEPP-PT presente sul loro sito coincide con la descrizione di alto livello di DP-3T e INCLUDE la decentralizzazione (vedi figura sotto).

Addendum (April 9th, 19:20 CET). DP-3T ha rilasciato una nuova versione della specifica del protocollo (che sto analizzando), una spiegazione delle relazioni tra DP-3T e PEPP-PT, e un insieme di risposte sollevate (da me ed altri ricercatori) in questa FAQ. La mia osservazione relativa alla distribuzione degli SK_t dei dispositivi delle persone infette viene (credo) discussa al punto P6. Ho scritto "credo" dal momento che il titolo attuale di P6 è «Why do infected people upload a seed (which enables recreating EphIDs) instead of their individual EphIDs?» [Perché le persone infette inviano al server la chiave iniziale (che rende possibile ricreare gli EphIDs) invece dei loro singoli EphIDs?].

Da solo, l'invio al server della chiave iniziale non compromette l'anonimità della persona infetta, dal momento che viene generata casualmente quando l'app viene installata. Il problema che avevo segnalato io è nel fatto che poi il server invia direttamente a tutti queste chiavi iniziali di chi è infetto invece di inviare gli EphIDs che si possono calcolare da essi. La risposta fornita nelle FAQ discute il problema in termini di prestazioni, che in linea di principio è un argomento ragionevole. Ma dal momento che il punto riguarda la privacy delle persone, io rimango convinto che il protocollo NON DOVREBBE inviare le chiavi iniziali degli infetti ma solo gli EphIDs derivati.

Quindi il titolo di P6 dovrebbe essere «Why do the backend broadcast the seeds of infected persons (which enables recreating EphIDs) instead of their individual EphIDs?» [Perché il server invia le chiavi iniziali delle persone infette (che permette di ricreare gli EphIDs) invece dei singoli EphIDs?]. Ho chiesto spiegazioni e vi aggiornerò su quanto ricevo.

NB: nella prima versione pubblicata le chiavi venivano erroneamente descritte come a 32 bit invece che a 32 byte.

L’emergenza del soluzionismo digitale

di Enrico Nardelli

(english version here)

Il termine “soluzionismo digitale” è stato introdotto nel 2013 da Evgenj Morozov per indicare un approccio col quale si sostiene l’utilizzo e la diffusione di sistemi e applicazioni digitali come strumento risolutivo di problemi che sono essenzialmente sociali ed hanno bisogno in realtà di una risposta prima di tutto politica. Ovviamente, tali soluzioni vengono proposte – di solito con l’accompagnamento di una sapiente strategia comunicativa – perché qualche attore, cui certo non mancano le risorse necessarie per influenzare l’opinione pubblica, ne trae vantaggio, economico o di altra natura. Il comune cittadino, che soprattutto in materia di digitale è mediamente abbastanza sprovveduto, si fa convincere, salvo poi accorgersi dopo un po’ di tempo che quello che pensava fosse un futuro di libertà assomiglia di più ad una gabbia, neanche dorata.

Gli stati di necessità, cioè quelle situazioni in cui qualche circostanza imprevista costringe ad affrontare problemi eccezionali, sono un terreno privilegiato per il soluzionismo digitale, dal momento che la ristrettezza di risorse e la necessità di “fare presto” premono per accorciare i tempi della decisione.

L’emergenza sanitaria che stiamo vivendo è esemplare da questo punto di vista. Da un po’ di tempo si sta parlando sempre più intensamente di dispiegare sui telefoni dei cittadini app di tracciamento dei contatti che permettano rapidamente di risalire a chi è stato in contatto con coloro che sono stati colpiti dal virus.

Poiché il tracciamento degli spostamenti delle persone è un’azione fortemente invasiva della privacy, le istituzioni più attente alle libertà civili ed alla democrazia hanno subito alzato barriere protettive. A livello internazionale, la Electronic Frontier Foundation ha elencato una serie di princìpi che vanno rispettati per difendere i diritti civili durante le crisi sanitarie. In Europa, la European Digital Rights ha richiamato i governi al rispetto dei diritti fondamentali nella gestione del COVID-19. Inoltre, il garante Europeo per la privacy (European Data Protection Board) ha rilasciato una dichiarazione sull’utilizzo dei dati personali nel contesto dell’epidemia di COVID-19. Infine l’associazione non governativa Algorithm Watch ha ricordato le cautele da adottare nell’uso di sistemi automatici di decisione per combattere il COVID-19.

Anche l’associazione europea dei dipartimenti universitari e centri di ricerca in informatica di cui sono presidente, Informatics Europe, ha pubblicato una raccomandazione con linee guida sull’uso delle tecnologie digitali per il controllo dell’infezione da COVID-19.

Tutte queste prese di posizione sottolineano la delicatezza e la cautela che sono necessarie per intervenire in questo ambito. Sono state richiamate, in particolare, le previsioni della Convenzione Europea sui Diritti Umani ed il Regolamento Generale per la Protezione dei Dati dell’Unione Europea (GDPR). Il primo di questi richiede che ogni restrizione dei diritti fondamentali sia “temporanea, limitata, e controllata”, mentre il GDPR consente eccezioni nel trattamento dei dati personali soltanto per “misure necessarie, appropriate e proporzionali”.

Si tratta di interventi estremamente necessari dal momento che, oltre quanto in Oriente già si sta facendo da tempo in tema di controllo sociale mediante infrastrutture digitali – ma in una cultura basata su princìpi diversi da quelli occidentali, proprio in questi giorni in Europa si sono intensificate le dichiarazioni che invocano l’utilizzo di tali soluzioni e le danno già per pronte. E in Italia la Commissione Trasporti e Telecomunicazioni della Camera dei Deputati avvierà delle audizioni in proposito.

Il punto fondamentale non è infatti tanto la fattibilità tecnica delle soluzioni, per le quali la ricerca informatica nell’ambito della crittografia offre un vero e proprio arsenale di sofisticati strumenti. Va comunque sottolineato che finora, delle soluzioni di cui si è parlato sui media, non sono noti sufficienti dettagli tecnici per poter garantirne la correttezza.

Lo snodo critico è la necessità, affinché esse siano davvero efficaci, di coniugarle con adeguate scelte di politica sanitaria. Va sottolineato che in Oriente, dove approcci di questo tipo sono stati usati con successo, è stato fondamentale l’essersi preparati, avendo fatto esperienza nel corso delle precedenti epidemie di SARS, e l’avere predisposto in anticipo misure e risorse per rispondere adeguatamente all’infezione. È una problematica analoga a quella di molti altri casi: le soluzioni tecnologiche (ormai sempre più digitali) non sono mai risolutive a meno che non siano compatibili con lo scenario socio-organizzativo, dotate di adeguate risorse finanziarie e materiali, e supportate dalla volontà politica.

Se questi elementi mancano, rimane solo la svendita dei nostri dati personali, quindi della nostra libertà, quindi della democrazia.