immuni-documentation
immuni-documentation copied to clipboard
immuni-app
Replay attacks
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.
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.
@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.
@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.
@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.
@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.
@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 [email protected].
@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?
- Lo standard Apple/Google è soggetto all'attacco indicato
- 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 ([email protected])
- 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
@48656c6c6f20576f726c64 quindi pensi ci sia un problema di REPLAY attack che induce i falsi positivi?
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 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?
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 ([email protected]) 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).
@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
@ivanvisconti, quale delle seguenti affermazioni rispecchia il tuo pensiero?
- Lo standard Apple/Google è soggetto all'attacco indicato
- Lo standard Apple/Google NON è soggetto all'attacco indicato, ma il team di Immuni ha fatto scelte che rendono possibile l'attacco indicato
@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.
@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 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?
- Lo standard Apple/Google è soggetto all'attacco indicato
- 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.
@48656c6c6f20576f726c64 allora ti faccio la domanda diretta: lavori per Bending Spoons?
@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.
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
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 [email protected].
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.
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
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 [email protected].
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...
@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 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
@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 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 ;)
