Replay attacks

[vbertola]

I am sorry to open this issue in the documentation section, but there is no other section available, and also no security assessment has been provided yet. In any case, I think it is useful to supply a link to this new study that describes how tracing apps could be subject to replay attacks:

https://down.dsg.cs.tcd.ie/tact/replay.pdf

It is impossible to say if Immuni is also subject to this, given the lack of information, but it will be possible to address or close this issue once the source code is actually available.

[ivanvisconti]

I agree with @vbertola. It's very bad to allow replay attacks. The effectiveness of such attacks has been discussed here: https://eprint.iacr.org/2020/399 and a solution is discussed here: https://eprint.iacr.org/2020/418 that however requires GPS location, which is bad for privacy. Moreover it is not compatible with Apple-Google API. It seems that Apple-Google are providing an API that allows to design systems with poor privacy and is insecure with respect to several attacks (replay, and others). I believe that Immuni should clarify the security and privacy limitations of their system, specifying which ones are due to the use of the Apple-Google API and which ones are due to their specific design. It is unfair to let citizens use their app without informing them on the security and privacy risks. Moreover the choice of using Apple-Google API should also be motivated since the are countries that are avoiding this API at the cost of having less smartphones active but with the benefit of having a system with properties that the use Apple-Google API does not allow to obtain.

[48656c6c6f20576f726c64]

@vbertola , @ivanvisconti, Immuni non si occupa della comunicazione Bluetooth. Tutta quella parte, come scritto ovunque e ribadito più volte, è completamente gestita dalle API di Apple/Google. Le specifiche Bluetooth di Apple/Google sono pubbliche (https://blog.google/documents/70/Exposure_Notification_-_Bluetooth_Specification_v1.2.2.pdf), quindi non capisco il senso delle vostre domande qui. Se non avete compreso le specifiche Bluetooth di Apple/Google dovreste chiedere a loro, non a chi ha realizzato Immuni.

[ivanvisconti]

@48656c6c6f20576f726c64 la scelta di usare le API non è obbligatoria visto quanto fatto in Francia e UK. Inoltre far notare il problema ed attendersi una risposta di conferma è lecito per informare meglio i cittadini che quindi possono più consapevolmente decidere se usare o meno l'app. Non so se hai capito il senso questa volta.

[48656c6c6f20576f726c64]

@ivanvisconti forse non hai compreso a cosa serve questo repository. Non siamo qui per decidere come realizzare un'app per contact tracing, quelle scelte sono state già fatte, quindi mettiti il cuore in pace. Siamo qui per migliorare quello che è stato fatto. Quindi, se hai un feedback tecnico puntuale su quello che è stato fatto magari può essere di grande aiuto, se invece sei qui solo per creare un dibattito sulla scelta che è stata fatta allora sei nel posto sbagliato e ti consiglio di utilizzare altre piattaforme come Facebook, Twitter, LinkedIn.

[ivanvisconti]

@48656c6c6f20576f726c64 ho dato un feedback tecnico puntuale, leggi sopra. Non capisco questa imposizione che l'app è fatta. C'è ampio margine di miglioramento. Se vi interessa cambiare i nomi alle variabili fate pure.

[48656c6c6f20576f726c64]

@ivanvisconti il tuo feedback tecnico è sullo standard Apple/Google, non su Immuni e questo è il repository di Immuni, non di Apple/Google. Se pensi che il tuo feedback tecnico sia valido, ti consiglio di farlo presente nel repository corretto: https://github.com/google/exposure-notifications-server

Issues and Questions You can open a GitHub Issue. Please be sure to include as much detail as you can to help aid in addressing your concern. If you wish to reach out privately, you can send an e-mail exposure-notifications-feedback@google.com.

[ivanvisconti]

@48656c6c6f20576f726c64 non sono d'accordo.

[48656c6c6f20576f726c64]

@48656c6c6f20576f726c64 non sono d'accordo.

@ivanvisconti, proviamo a seguire un semplice ragionamento che potrebbe aiutarti a fare luce su questa cosa.

STEP 1: Quale delle seguenti affermazioni rispecchia il tuo pensiero? 1) Lo standard Apple/Google è soggetto all'attacco indicato 2) Lo standard Apple/Google NON è soggetto all'attacco indicato, ma il team di Immuni ha fatto scelte che rendono possibile l'attacco indicato

STEP 2:

• Se allo STEP 1 hai scelto l'affermazione 1, sei nel posto sbagliato e devi contattare Apple/Google (exposure-notifications-feedback@google.com)
• Se allo STEP 1 hai scelto l'affermazione 2, sei pregato di indicare la scelta tecnica (errata) fatta dal team di Immuni che rende possibile l'attacco SOLO per Immuni e non per altri sistemi che utilizzano lo standard Apple/Google

[ivanvisconti]

@48656c6c6f20576f726c64 quindi pensi ci sia un problema di REPLAY attack che induce i falsi positivi?

[vbertola]

Scusate, ma stiamo scherzando? Cioé, uno fa un app (qualunque), si trovano o ipotizzano delle vulnerabilità (che so: le password sono memorizzate in chiaro), e la risposta è "ah beh, ma quello lo gestiscono le librerie che usiamo, quindi ce ne freghiamo"? Se una libreria è insicura, ovviamente se ne sceglie una diversa, o perlomeno si studiano delle contromisure alle sue vulnerabilità, o come minimo si passano le vulnerabilità upstream perché il team di sviluppo della libreria le corregga. Ma la responsabilità della scelta della libreria è del team di sviluppo e fa integralmente parte dell'applicazione! Non s'è mai sentito di un pentest o di una analisi di sicurezza che, come un impiegato del catasto, si limita a un pezzo dell'app perché il resto "non è di mia competenza"...

[48656c6c6f20576f726c64]

@48656c6c6f20576f726c64 quindi pensi ci sia un problema di REPLAY attack che induce i falsi positivi?

@ivanvisconti risolviamo un problema alla volta. Non mi è chiaro il tuo pensiero riguardo allo STEP 1: affermazione 1 o 2?

[48656c6c6f20576f726c64]

come minimo si passano le vulnerabilità upstream perché il team di sviluppo della libreria le corregga

@vbertola, nessuno ti impedisce di farlo, anzi, puoi contattare direttamente Apple/Google (exposure-notifications-feedback@google.com) e sono sicuro che apprezzeranno il tuo contributo (ovviamente solo nel caso in cui tu abbia una soluzione e non le 5 righe del tuo post).

[ivanvisconti]

@48656c6c6f20576f726c64 quindi pensi ci sia un problema di REPLAY attack che induce i falsi positivi?

@ivanvisconti risolviamo un problema alla volta. Non mi è chiaro il tuo pensiero riguardo allo STEP 1: affermazione 1 o 2?

mi proteggo da Sybil attack, e quindi ti chiedo qualche proof of work

[48656c6c6f20576f726c64]

@ivanvisconti, quale delle seguenti affermazioni rispecchia il tuo pensiero?

1. Lo standard Apple/Google è soggetto all'attacco indicato
2. Lo standard Apple/Google NON è soggetto all'attacco indicato, ma il team di Immuni ha fatto scelte che rendono possibile l'attacco indicato

[48656c6c6f20576f726c64]

@ivanvisconti, come volevasi dimostrare le tue affermazioni sono infondate e il tuo non saper rispondere ad una semplice domanda dimostra la tua inadeguata comprensione del sistema. Per il futuro, ti consiglio vivamente di utilizzare il tuo tempo per studiare quello di cui vorresti parlare, prima di lanciarti con affermazioni senza alcun fondamento e farti perdere qualsiasi credibilità. In caso contrario, ti consiglio piattaforme come Facebook su cui potresti trovarti più a tuo agio, con i tuoi simili, e discutere nello stesso modo di argomenti senza alcun fondamento. Direi che possiamo considerare l'issue chiuso.

[vbertola]

@48656c6c6f20576f726c64 scusa la domanda, ma chi sei tu per decidere se l'issue va chiuso o meno? Lo dovrebbe fare uno sviluppatore dell'applicativo. Io aspetto ancora che si presenti una persona titolata a parlare della questione, cioé qualcuno che lavori per Bending Spoons e gestisca questo spazio su github.

[48656c6c6f20576f726c64]

@48656c6c6f20576f726c64 scusa la domanda, ma chi sei tu per decidere se l'issue va chiuso o meno? Lo dovrebbe fare uno sviluppatore dell'applicativo. Io aspetto ancora che si presenti una persona titolata a parlare della questione, cioé qualcuno che lavori per Bending Spoons e gestisca questo spazio su github.

@vbertola, ti rivolgo la stessa domanda fatta a @ivanvisconti, vediamo se almeno tu riesci a rispondere: quale delle seguenti affermazioni rispecchia il tuo pensiero?

1. Lo standard Apple/Google è soggetto all'attacco indicato
2. Lo standard Apple/Google NON è soggetto all'attacco indicato, ma il team di Immuni ha fatto scelte che rendono possibile l'attacco indicato

Non è richiesto alcun giro di parole, basta scrivere 1 o 2. In caso di mancata risposta o in presenza di supercazzola è evidente che l'issue verrà chiusa, perché è la dimostrazione che non conosci a sufficienza come è stato realizzato il sistema e le varie parti che lo compongono e come fatto già notare da altri, questo non è un servizio per fare domande agli sviluppatori ed imparare qualcosa.

[vbertola]

@48656c6c6f20576f726c64 allora ti faccio la domanda diretta: lavori per Bending Spoons?

[48656c6c6f20576f726c64]

@48656c6c6f20576f726c64 allora ti faccio la domanda diretta: lavori per Bending Spoons?

Come volevasi dimostrare. Un altro che arrivato al dunque si tira indietro. Comunque siamo contenti che almeno siamo riusciti ad insegnare qualcosa a @ivanvisconti, che in una sua intervista dichiara (https://www.key4biz.it/immuni-ivan-visconti-univ-salerno-mette-in-guardia-sulla-privacy-dei-dati-raccolti-ed-inviati-e-sul-ruolo-di-akamai/308319/): "Il principale problema è che le API di Apple e Google offrono una funzionalità di contact tracing che permette di proteggere solo in parte la privacy e la sicurezza dei cittadini che le usano... Inoltre, le API non sembrano essere robuste rispetto ad attacchi di tipo REPLAY in cui ricevendo un codice in un luogo lo si potrebbe inoltrare in un luogo completamente diverso, innescando quindi dei falsi positivi." Finalmente ha capito che l'attacco indicato dipende dallo standard Apple/Google e non da scelte fatte dal team di Immuni. Se ce l'ha fatta lui puoi farcela anche tu, devi solo seguire il ragionamento.

[carloreggiani]

A dire la verità qui forse si voleva evidenziate un problema nel paradigma Security by Design che ovviamente comprende tutta la Software Supply Chain coinvolta nella realizzazione di una soluzione software. Provando poi ad andare a chiedere a Google emerge che le domande relative all'implementazione delle API per il contact tracing si scopre che possono farle solo gli organismi governativi coinvolti nello sviluppo delle applicazioni (vedi form Google): essendo solo voi titolati, avete avuto modo di interagire con Google/Apple sul tema Security e in particolare per questa vulnerabilità? Grazie per il chiarimento

[48656c6c6f20576f726c64]

A dire la verità qui forse si voleva evidenziate un problema nel paradigma Security by Design che ovviamente comprende tutta la Software Supply Chain coinvolta nella realizzazione di una soluzione software. Provando poi ad andare a chiedere a Google emerge che le domande relative all'implementazione delle API per il contact tracing si scopre che possono farle solo gli organismi governativi coinvolti nello sviluppo delle applicazioni (vedi form Google): essendo solo voi titolati, avete avuto modo di interagire con Google/Apple sul tema Security e in particolare per questa vulnerabilità? Grazie per il chiarimento

@carloreggiani chiunque può inviare feedback e consigli direttamente ad Apple/Google (https://github.com/google/exposure-notifications-server):

Issues and Questions You can open a GitHub Issue. Please be sure to include as much detail as you can to help aid in addressing your concern. If you wish to reach out privately, you can send an e-mail exposure-notifications-feedback@google.com.

Nessuno nega che ci siano potenziali falle utilizzando lo standard Apple/Google, ma il punto è che se quelle falle dipendono da Apple/Google, bisognerebbe aprire un issue lì e non qui.

[carloreggiani]

Nessuno nega che ci siano potenziali falle utilizzando lo standard Apple/Google, ma il punto è che se quelle falle dipendono da Apple/Google, bisognerebbe aprire un issue lì e non qui.

Quindi non avete chiesto nulla a Google/Apple su questo potenziale problema di security. Ok, per ora ci basta saperlo. Grazie

[thor486]

A dire la verità qui forse si voleva evidenziate un problema nel paradigma Security by Design che ovviamente comprende tutta la Software Supply Chain coinvolta nella realizzazione di una soluzione software. Provando poi ad andare a chiedere a Google emerge che le domande relative all'implementazione delle API per il contact tracing si scopre che possono farle solo gli organismi governativi coinvolti nello sviluppo delle applicazioni (vedi form Google): essendo solo voi titolati, avete avuto modo di interagire con Google/Apple sul tema Security e in particolare per questa vulnerabilità? Grazie per il chiarimento

@carloreggiani chiunque può inviare feedback e consigli direttamente ad Apple/Google (https://github.com/google/exposure-notifications-server):

Issues and Questions You can open a GitHub Issue. Please be sure to include as much detail as you can to help aid in addressing your concern. If you wish to reach out privately, you can send an e-mail exposure-notifications-feedback@google.com.

Nessuno nega che ci siano potenziali falle utilizzando lo standard Apple/Google, ma il punto è che se quelle falle dipendono da Apple/Google, bisognerebbe aprire un issue lì e non qui.

onestamente trovo allucinante una risposta del genere che denota una spocchia non da poco, se vuoi sviluppate un'app di utilità nazionale che dovrebbe mantenere la privacy non potete solo ignorare che un framework utilizzato abbia una falla di sicurezza...

[48656c6c6f20576f726c64]

@thor486 forse non ti è chiaro che non esistono sistemi "perfetti". Esistono sistemi che, date alcune specifiche di partenza, cercano di raggiungere un miglior compromesso tra aspetti positivi e aspetti negativi. Qui vedo molti professori che conoscono bene la teoria, ma non hanno mai scritto una riga di codice e non prendono in considerazione il fatto che non c'è completa carta bianca per progettare il sistema che si vuole. Per esempio, se sui dispositivi Apple il Bluetooth non funziona in modo affidabile con app in background e l'unico modo per ottenere l'affidabilità richiesta è utilizzare le nuove API di Apple/Google, capisci che è quasi una scelta obbligata, se si vuole coprire anche la popolazione che ha dispositivi Apple. Inoltre ribadisco che questo spazio è dedicato alla valutazione del codice e di eventuali soluzioni pratiche (= codice, che in questa issue e in molte altre è del tutto inesistente), non è dedicato alla pura teoria, per quella ci sono le università ed i professori possono continuare ad insegnarla in quella sede.

[thor486]

@thor486 forse non ti è chiaro che non esistono sistemi "perfetti". Esistono sistemi che, date alcune specifiche di partenza, cercano di raggiungere un miglior compromesso tra aspetti positivi e aspetti negativi. Qui vedo molti professori che conoscono bene la teoria, ma non hanno mai scritto una riga di codice e non prendono in considerazione il fatto che non c'è completa carta bianca per progettare il sistema che si vuole. Per esempio, se sui dispositivi Apple il Bluetooth non funziona in modo affidabile con app in background e l'unico modo per ottenere l'affidabilità richiesta è utilizzare le nuove API di Apple/Google, capisci che è quasi una scelta obbligata, se si vuole coprire anche la popolazione che ha dispositivi Apple. Inoltre ribadisco che questo spazio è dedicato alla valutazione del codice e di eventuali soluzioni pratiche (= codice, che in questa issue e in molte altre è del tutto inesistente), non è dedicato alla pura teoria, per quella ci sono le università ed i professori possono continuare ad insegnarla in quella sede.

Spero che questo account non sia gestito da bending spoons direttamente... altrimenti dovreste rivedere la comunicazione. Voi state usando un framework che ha una falla di sicurezza, nessuno vi sta accusando di niente ma almeno preoccuparsi della cosa invece di rispondere solo parlate con Google. Per quanto riguarda il codice scritto, probabilmente chi scrive è un ragazzino sottopagato che fa il programmatore da voi. Personalmente ho lavorato sul contact tracing per società di Londra come We are social e, una mia soluzione sul contact tracing, ha vinto l'italian mobile award qualche anno fa allo SMAU. Quindi più umiltà e trasparenza non guasterebbero e

[48656c6c6f20576f726c64]

@thor486 probabilmente non hai compreso che tutto quello che avete scritto è noto (anche ad Apple/Google), ma questa è la soluzione che raggiunge un miglior compromesso tra aspetti positivi e aspetti negativi. Visto che dici di avere una soluzione migliore, se gentilmente ci mandi il link del repository con il codice non vediamo l'ora di vederla e valutarla. In caso contrario, se sei qui solo per sfogare la tua frustrazione, hai scelto il posto sbagliato e puoi continuare a scrivere questi post sulla tua bacheca Facebook, perché qui non hanno nessuna utilità.

[thor486]

@thor486 probabilmente non hai compreso che tutto quello che avete scritto è noto (anche ad Apple/Google), ma questa è la soluzione che raggiunge un miglior compromesso tra aspetti positivi e aspetti negativi. Visto che dici di avere una soluzione migliore, se gentilmente ci mandi il link del repository con il codice non vediamo l'ora di vederla e valutarla. In caso contrario, se sei qui solo per sfogare la tua frustrazione, hai scelto il posto sbagliato e puoi continuare a scrivere questi post sulla tua bacheca Facebook, perché qui non hanno nessuna utilità.

Questa reazione spocchiosa da bambino delle elementari da un'agency che si proclama smart più altre fesserie milanesi sono uno dei motivi per cui tanti addetti ai lavori come me siano emigrati all'estero. Tanti saluti al vostro investitore Berlusconi ;)

[Alessandroinfo]

Italians 🤷‍♂️

[thor486]

Italians

Esattamente ;)

[adryx92]

Grandi raga, discussione creativa e piena di spunti

[pgiacomo69]

Credo che Apple e Google abbiano già da tempo letto questo studio, ed altri che sicuramente saranno stati fatti. Non ho letto le specifiche delle API Apple/Google, ma immagino che per i creatori di Immuni, o di qualsiasi altra App, non cambi nulla, dato che la validazione dei beacon e codifiche varie è fatta dai sistemi operativi, e non dalle App, se Google o Apple riterranno opportuno correggere il tiro, lo faranno con un OS update. Bending Spoons, o qualunque altro sviluppatore può scegliere solo se realizzare o no l'App, non quale API utilizzare, poichè sia Android che IOS pongono dei limiti all'utilizzo di BLE ed all'accesso a dati come Mac Address ed altro.

[Aerendir]

Quante cazzate che sto leggendo... framework, paper, paroloni altisonanti...

Ma fatemi il piacere...

Volete fare la politica? Fatela pure.

Ma questo è GitHub: qua si scrive di codice.

Andate a rompere le scatole da un’altra parte.

E fa bene la persona che sta scrivendo a rimanere anonima: con gente così in giro...

Tutti a criticare e parlare a vanvera.

Io ho fatto la soluzione ma non si può applicare, la Francia ha fatto questo, quell’altro ha detto quello...

E noi in Italia abbiamo fatto cosi.

Se non vi sta bene andatevene all’estero e se già ve ne siete andati rimaneteci e non ci venite a scocciare più di grazia.

[Tudor44]

Poi dici che la gente scappa all'estero... ci facciamo pure riconoscere su GitHub.

[Aerendir]

Per piacere, chiudete questo issue che è una vergogna.

[mpragliola]

Purtroppo ho avuto lo stesso pensiero: "italiani".

[Lasvando]

Mi vergogno di essere italiano ogni giorno di più, e non per colpa di Bending Spoons, invece di essere felici di non aver fatto come al solito sub-appaltando il lavoro a qualche azienda tedesca gli si da contro. Io boh. //TODO : REMOVE POST

[vbertola]

Io trovo allucinante che dopo quindici giorni non ci sia una persona del team di sviluppo che si presenta qui a dirci se hanno fatto una analisi di sicurezza completa del sistema e cosa hanno trovato a proposito di un potenziale attacco come quello dello studio, che incidentalmente viene da una lista IETF, e che sarà pure a livello di librerie di comunicazione, ma nel caso potrebbe tranquillamente essere mitigato a livello dell'applicazione (ad esempio con controlli di sensatezza sulla ripetizione dello stesso contatto). E se provi a sollevare il problema, salta fuori la gente a gridare che forza Italia che siamo tantissimi e meglio dei tedeschi...

[pgiacomo69]

Io trovo allucinante che dopo quindici giorni non ci sia una persona del team di sviluppo che si presenta qui a dirci se hanno fatto una analisi di sicurezza completa del sistema e cosa hanno trovato a proposito di un potenziale attacco come quello dello studio, che incidentalmente viene da una lista IETF, e che sarà pure a livello di librerie di comunicazione, ma nel caso potrebbe tranquillamente essere mitigato a livello dell'applicazione (ad esempio con controlli di sensatezza sulla ripetizione dello stesso contatto). E se provi a sollevare il problema, salta fuori la gente a gridare che forza Italia che siamo tantissimi e meglio dei tedeschi...

L'applicazione non può mitigare questo "attacco", non è un problema di ripetizioni dello stesso contatto. Il supposto attacco trasloca delle chiavi da un posto ad un altro, quando ricevi quei codici su un telefono non hai modo di sapere che sono stati "copiati" altrove e ripetuti dove ti trovi. Se hai una soluzione, correggi il codice e fai una PR, github esiste per questo.

Inoltre, siamo seri, al massimo questo tipo di attacco cosa può generare? Qualche falsa notifica di esposizione? Per un attacco del genere servono due Raspberry o device similari uno da piazzare dove sia probabile che ci sia un contagiato (la sala di attesa delle analisi, come specificato dall'articolo?), ed un'altro da piazzare dove ci siano abbastanza persone che possano ricevere il broadcast (un supermercato, una stazione della metro?), entrambi devono essere collegati ad Internet o una rete che li faccia comunicare tra di loro. Ci vogliono gli intelligentoni che lo facciano senza alcun guadagno personale, rischiando comunque sanzioni o galera. Chi si ci mette, tenendo conto che per come è concepito il sistema non sarà neanche bersaglio di Anonymous o similari, dato che non lede i diritti di nessuno? L'unica cosa positiva di questa issue (dovendone trovare una) è che fa parlare di questa App e conoscere meglio il funzionamento di questo sistema. Fossi io un gestore di questo repository, la avrei già chiusa come "Non Pertinente".

[vbertola]

Questa almeno è una risposta in topic, grazie. Ci voleva tanto? Bastava uno sviluppatore che dicesse: grazie per la segnalazione, abbiamo fatto l'analisi del problema, abbiamo concluso che è difficile mitigarlo a livello applicativo ma è anche un attacco complicato con un vantaggio limitato per l'attaccante, quindi abbiamo deciso che non fa parte del nostro threat model.

(Tuttavia sul fatto che un sistema così sensibile non sarà bersaglio di hacktivists non sarei così tranquillo; sono tante le persone nella comunità che obiettano al tracciamento governativo per principio, e ancora di più quelle che obiettano all'uso di una libreria controllata da Google e Apple. Anche solo bloccarne il funzionamento sarebbe già un obiettivo politicamente valido.)

[VMinute]

Just my two cents continuando su quanto detto da @pgiacomo69. Non sono un esperto di security, quindi sarei contentissimo di vedere se altri arrivano a conclusioni diverse (magari spiegandomi dove ho toppato). Ho fatto un ragionamento spero alla portata di tutti e due conticini. Visto che non è possibile "firmare" i pacchetti mandati via BLE (cadrebbe l'anonimato e sarebbe semplice tracciare le persone) è chiaro che questi possono essere catturati e riprodotti pari pari. É quello che succedeva, ad esempio, con i vecchi telecomandi di allarmi etc. senza rolling code. Catturavi un pacchetto e potevi "rispedirlo" (via radio o infrarossi) per aprire/disattivare quello che volevi. Nei sistemi piú recenti il codice viene generato in base a una chiave nota a trasmettitore e ricevitore, catturare il pacchetto non basta perchè ogni pacchetto è diverso e valido solo una volta. Ma nel caso di immuni il ricevitore non deve conoscere il trasmettitore, quindi il "trucco" non funziona. Ci sono peró una serie di fattori che mitigano il potenziale problema:

• il codice casuale viene rigenerato ogni 10' con chiavi (di nuovo casuali) cambiate giornalmente, quindi un pacchetto "catturato" puó essere usato solo per 10' (se quando si comunica la positività all'ID è associato lo slot temporale), qualcosa in piú tenendo conto di possibili imprecisioni nell'orario dei device (ma parliamo di poco, visto che gli orologi dei cellulari sono sincronizzati), ma non all'infinito.
• Il pacchetto viaggia su BLE e richiede una prossimità fisica rispetto al ricevitore. Inoltre il sistema verifica anche che la prossimità sia prolungata (non mi basta un solo pacchetto sparato una-tantum)
• la segnalazione di positività viene comunque verificata (mi serve uno davvero positivo al covid-19 per far partire la catena di notifiche) Ora facciamo finta che io sia supercattivone e voglia mettere in crisi il sistema generando tanti falsi positivi per mettere in crisi il sistema di tamponi/test (attacco DDOS). Cosa devo fare?

Mi servono tre cose:

• un telefono con l'app installata
• una persona che risulti positiva al test
• un modo per diffondere i pacchetti in posti affollati

Il primo requisito è semplice. Il secondo meno. Anche perchè per "infettare virtualmente" molte persone avró bisogno di tempo. Quindi dovrà essere una persona che risulti positiva tra N giorni (dove N dovrà essere quanto piú grande possibile, al massimo 15gg che il tempo per cui vengono conservati in locale i dati dei contatti). Passiamo al terzo. Per "sparare" i pacchetti falsi mi bastano dei telefonini o dei device con BLE (device). Dovró fare in modo di passargli i nuovi pacchetti generati prima possibile (abbiamo 10' di validità) e allo stesso tempo fare in modo che i device siano effettivamente in prossimità di quante piú persone possibile (non mi basta stare vicino a un tornello della metropolitana, quello non sarebbe registrato come contatto significativo, dovró stare vicino a una persona per un tempo prolungato). E' possibile estendere il range di BLE usando un trasmettitore piú potente? Immagino di sí (alla fine è un segnale radio), ma immagino anche che un simile device non possa essere certificato e non sia quindi facilmente reperibile in commercio, quindi lo escludiamo. A questo punto posso scegliere se piazzare i miei device in una locazione piú o meno fissa (sotto i tavoli di un ristorante, sotto un sedile della metro) o usare dei complici che girino tra la gente. La soluzione fissa ha il vantaggio di non richiedere altre persone coinvolte, limitando il rischio che qualcuno spifferi il piano di supercattivone. Per contro dovró piazzare parecchi device, assicurarmi che siano collegati alla mia rete (devono ricevere i nuovi pacchetti ogni 10') e che non siano facilmente individuabili. Inoltre dovró pensare a posizioni in cui il device sia vicino a molta gente per un periodo abbastanza lungo, quindi probabilmente posti affollati dove qualcuno potrebbe notarmi mentre nascondo qualcosa. Inoltre un tracking a posteriori dei falsi positivi potrebbe far scoprire che tutti prendono una certa linea della metro o hanno mangiato in un certo ristorante, rendendo i miei device a rischio di essere scoperti e ricondotti a me. Se uso dei complici questi potranno muoversi liberamente, "infettando" gente in posti diversi senza lasciare molte possibilità di tracking (a meno di non invadere pesantemente la privacy dei falsi positivi tracciandone a posteriori ogni movimento). Ogni complice in piú aumenta la portata dell'attacco, ma anche il rischio di essere tradito e scoperto. Ora facciamo due conti. Ho un arco temporale in cui realizzare l'attacco (il tempo per cui la persona che generà la prima segnalazione resterà positiva al test) di T giorni. Avró N device (con o senza complici). Ipotizziamo che ogni device possa "infettare" virtualmente una persona ogni 10' (sull'arco delle 24 ore, compensando momenti di affollamento con gli orari in cui non c'è nessuno e facendo una stima, secondo me, favorevole a supercattivone). Ogni device "infetterà" 144 persone al giorno (P). Il totale degli "infettati" (senza considerare eventuali duplicati) è: T P N. T è un valore che non posso controllare (assumiamo il massimo, ossia i 15g di validità degli ID, se non ho capito male). P è un valore che posso aumentare cercando luoghi affollati, ma non posso controllare completamente, solo stimare. N è un fattore sotto il mio controllo, ma ogni device (ed eventuale complice) in piú aumenta lo sforzo a livello economico/organizzativo e aumenta il rischio che il mio diabolico piano venga scoperto. Consideriamo 5 device. Posso probabilmente recuperare facilmente l'hardware e il tutto potrà essere gestito da una gang di amici intimi di supercattivone. 15 144 5=10800 falsi positivi In Italia, se non ho letto male i dati, si possono fare almeno 30k tamponi al giorno (a seconda dei giorni il numero cambia), un dato simile metterà in crisi il sistema per quanto tempo? 3-4 giorni? Consideriamo 100 device, che è un numero già molto alto (a 50€ a device parliamo di 5000€ di spesa e comprando tutto quel materiale in blocco potrei destare sospetti, inoltre dovró piazzarli o trovare molti complici, il rischio di essere scoperto aumenta tantissimo). Avremo 15 144 100=216000 falsi infetti. Per quanto tempo possono mettere in crisi il sistema (sempre che non ci sia modo di capire, magari con una modifica all'app, che tutti fanno capo agli stessi ID e quindi ripulire il sistema, prima o poi qualcuno si chiederà perchè appaiono cosí tante segnalazioni dall'app in zone dove non c'è un corrispondente aumento dei casi reali)? Probabilmente diversi giorni. Ma tutto questo presuppone un'organizzazione che si è vista solo in occasione di attentati terroristici. Esiste un'organizzazione interessata a compiere un'azione simile? Quale sarebbe il danno prodotto? Qualche giorno di lockdown? Calo della fiducia dei cittadini e ritorno della paura del virus? P.S. la discussione mi pare interessante, nonostante i toni a volte non propriamente urbani. P.S. del P.S. forse era meglio postare in inglese, vedró di tradurre appena ho tempo.

[thor486]

Quante cazzate che sto leggendo... framework, paper, paroloni altisonanti...

Ma fatemi il piacere...

Volete fare la politica? Fatela pure.

Ma questo è GitHub: qua si scrive di codice.

Andate a rompere le scatole da un’altra parte.

E fa bene la persona che sta scrivendo a rimanere anonima: con gente così in giro...

Tutti a criticare e parlare a vanvera.

Io ho fatto la soluzione ma non si può applicare, la Francia ha fatto questo, quell’altro ha detto quello...

E noi in Italia abbiamo fatto cosi.

Se non vi sta bene andatevene all’estero e se già ve ne siete andati rimaneteci e non ci venite a scocciare più di grazia.

quindi se uno fa una domanda ad un'agency che sta sviluppando un'app governativa a livello nazionale la risposta è noi facciamo così stacce? altrimenti vai fuori? sicuramente ci tornerò fuori

[pgiacomo69]

Just my two cents continuando su quanto detto da @pgiacomo69. Non sono un esperto di security, quindi sarei contentissimo di vedere se altri arrivano a conclusioni diverse (magari spiegandomi dove ho toppato). Ho fatto un ragionamento spero alla portata di tutti e due conticini. Visto che non è possibile "firmare" i pacchetti mandati via BLE (cadrebbe l'anonimato e sarebbe semplice tracciare le persone) è chiaro che questi possono essere catturati e riprodotti pari pari. É quello che succedeva, ad esempio, con i vecchi telecomandi di allarmi etc. senza rolling code. Catturavi un pacchetto e potevi "rispedirlo" (via radio o infrarossi) per aprire/disattivare quello che volevi. Nei sistemi piú recenti il codice viene generato in base a una chiave nota a trasmettitore e ricevitore, catturare il pacchetto non basta perchè ogni pacchetto è diverso e valido solo una volta. Ma nel caso di immuni il ricevitore non deve conoscere il trasmettitore, quindi il "trucco" non funziona. .................... Un po troppo catastrofica la stima, ma Bravissimo! Meglio di cosi non si poteva spiegarla!

[VMinute]

Un po troppo catastrofica la stima, ma Bravissimo! Meglio di cosi non si poteva spiegarla!

Alla fine si parla di "contatto" con un raggio di 1-2 metri (anche se la stima delle distanze è necessariamente approssimativa, visti i fattori che condizionano il segnale) per 15'. Ti serve un luogo affollato dove peró le persone restino per almeno 15', per quello pensavo al ristorante o al vagone della metro. Ovvio che il calcolo dei contatti giornalieri deve tener conto degli orari di servizio, dell'affollamento tra ore di punta e ore "morte" etc. E anche del fatto che non tutti (e non sappiamo ancora quanti) useranno l'app. Bisognerebbe fare degli esperimenti per avere dei valori su cui ragionare.

[Aerendir]

Tutti questi ragionamenti, sebbene giusti in teoria, non tengono conto di una cosa: per poter inviare la segnalazione serve qualcuno che sia davvero infetto: non basta avere 10, 100 o 1000 telefoni: servono anche 10, 100 o 1000 persone realmente infette che

1. Vadano in ospedale
2. Risultino positive
3. Diano il codice all'operatore sanitario che poi carica i dati sul sistema.

A questo punto le alternative sono 2:

1. Chi ha portato in giro i telefoni è realmente infetto, e allora l'applicazione fa davvero il suo lavoro;
2. Chi ha portato in giro il telefono non è infetto, ma lo ha semplicemente poi dato a chi è realmente infetto: in questo caso non c'è soluzione.

Questo replay attack mi pare qualcosa di molto molto teorico, quanto meno qualcosa che nel caso concreto di Immuni non può fare danni o, se ne può, fare, non ha margini di mitigazione a livello tecnico-informatico (mentre a livello tecnico-giuridico ne ha già).

[Aerendir]

Cioè, bello parlarne e anche avvincente, ma dobbiamo essere consapevoli che ne stiamo parlando tanto per parlare, cioè stiamo scambiando GitHub per Facebook.

[VMinute]

Tutti questi ragionamenti, sebbene giusti in teoria, non tengono conto di una cosa: per poter inviare la segnalazione serve qualcuno che sia davvero infetto: non basta avere 10, 100 o 1000 telefoni: servono anche 10, 100 o 1000 persone realmente infette che

1. Vadano in ospedale
2. Risultino positive
3. Diano il codice all'operatore sanitario che poi carica i dati sul sistema.

No. Visto che puoi duplicare i pacchetti di persona infetta te ne basta una. Il replay attack farà crescere a dismisura il numero dei suoi contatti.

[Aerendir]

Ok, si, ne basta 1, ma il succo non cambia.

Questa persona realmente infetta deve comunque andare in ospedale ed essere dichiarata positiva. Giusto?

A quel punto i telefoni “ingannati” riceveranno una notifica, giusto?

Le persone notificate andranno in ospedale, saranno dichiarate negative e il giro si blocca.

Il problema, in realtà, torna ad essere quello che è sempre stato: il sistema è in grado di assorbire queste 10, 100, 1000 persone in più?

Replay attack o non replay attack per come la vedo io il problema grosso non è nell’app ma nella capacità del sistema sanitario.

Per quanto esteso l’attacco, il sistema deve essere comunque in grado di assorbire il colpo, altrimenti anche senza replay attack, collassa comunque.

[VMinute]

Infatti non è un attacco alla app, è un attacco DDOS al sistema sanitario. Il sistema è fatto per assorbire un numero ragionevole di casi potenziali, oltre quello va in tilt e se collassa quello si rischia di tornare al lockdown. É lo stesso principio degli attacchi ai server. Se il tuo sito serve 100 utenti, tu lo disegni per un picco di 10mila e io te ne mando un milione quello collassa. Io qualche calcolo l'ho fatto (rileggiti il mio post), potenzialmente non sono numeri piccoli. E ho sottovalutato un aspetto. Se fai collassare per qualche giorno il sistema dei test con i falsi contatti, un side effect pericoloso è che, rallentando i tamponi degli infetti veri, avrai potenziali infetti in giro per un tempo piú alto, e quindi potenzialmente piú contagi veri.

[Aerendir]

@VMinute , infatti i numeri non sono piccoli...

Ma il problema è che non serve un replay attack per craccare il sistema: basta scambiare i telefoni e il gioco è fatto, senza informatica, senza sbattimenti e lo può fare chiunque.

[VMinute]

@VMinute , infatti i numeri non sono piccoli...

Ma il problema è che non serve un replay attack per craccare il sistema: basta scambiare i telefoni e il gioco è fatto, senza informatica, senza sbattimenti e lo può fare chiunque.

No. "scambiando i telefoni" hai il numero di contatti reali di una persona (al limite non quella infetta), col relay attack lo moltiplichi per un fattore N.