Un approfondimento tecnico nell'app di monitoraggio dei contatti NHS COVID-19
La beta di traccia dei contatti di NHS COVID-19 è ora open source sia per iOS che per Android , insieme ad alcuni documenti . In seguito al nostro post " Restare vivi ", abbiamo fatto un tuffo nel codice sorgente. È piacevolmente sorprendente trovarlo concesso in licenza in base al MIT, indicando un impegno NHSX per la trasparenza e la qualità.
Nel corso degli ultimi due giorni, alcuni ingegneri hanno esaminato l'app per scoprire se - e come! - è in grado di rimanere in vita. Comprenderlo ha richiesto una comprensione più approfondita del framework CoreBluetooth
pertinente rispetto alla maggior parte degli sviluppatori. Non è un framework in cui gli ingegneri in genere devono approfondire.
Abbastanza presto, abbiamo individuato e segnalato come funzionava il trucco per i dispositivi Android. Stasera condividiamo proprio quello che sta succedendo su iOS. Facciamo un passo avanti.
Lancio iniziale
Al primo avvio, l'app PUT
una richiesta PUT
a https://api.svc-covid19.nhs.uk/api/devices/registrations
con un codice di attivazione, un token di notifica push e la prima metà dell'utente inserito codice postale. In risposta, il server risponde con un linkingId
memorizzato nelle impostazioni dell'app. L'app richiede anche notifiche push e autorizzazioni Bluetooth, come ci si aspetterebbe. Non richiede permessi di localizzazione e come tale non convalida il codice postale dell'utente. Sono necessarie solo le prime cifre di un codice postale.
È stato affermato che l'app per Android accede ai dati sulla posizione, poiché il prompt per l'accesso all'API Bluetooth sui dispositivi Android sembra richiedere autorizzazioni per la posizione. Tuttavia, lo abbiamo smascherato ieri: questa è una conseguenza di come Android gestisce le richieste di autorizzazioni Bluetooth .
Mantenersi in vita su Android
Impedire a un'app di dormire in background è banale su Android, poiché le API di serie supportano questa funzionalità, offrendo agli ingegneri un accesso di basso livello all'hardware Bluetooth.
Tuttavia, su iOS la storia non è così semplice. Quando le app sono in background su iOS, la loro funzionalità è notevolmente ridotta. Questo è anche il caso di CoreBluetooth
, il framework Apple che consente agli sviluppatori di accedere al Bluetooth. A corto di un workound intelligente, questo rende sostanzialmente più difficile per l'app rilevare iPhone che potrebbero essere in esecuzione in modalità background. Abbiamo testato con diversi dispositivi iOS lasciati soli nel corso di diverse ore e abbiamo notato che il polling si verificava meno frequentemente, ma che i dispositivi continuavano a comunicare durante la notte.
Utilizzo di Android per riattivare iPhone
Yesterday we also reported that when backgrounded, iOS apps continue to broadcast Bluetooth advertisements, but in a different way that’s specific to Apple. We believed the NHSX / Pivotal engineers had reverse-engineered this, and added support for it to the Android app. We can confirm that this is the case, and their technical details about it can be found here. What this means is that in addition to iOS devices being able to keep the app backgrounded, Android devices can wake a “sleeping” iOS device up regardless of how long it has been backgrounded for.
Quindi quali sono le implicazioni di questo? Bene, significa che affinché l'app funzioni, un iPhone deve trovarsi nel raggio di un dispositivo Android abbastanza spesso, quindi può inviare keepalive per mantenersi in background. Di per sé potrebbe non essere una soluzione praticabile, ma ...
Utilizzo dei dispositivi iOS per riattivare ... altri dispositivi iOS
Nel post di " Restare vivi " di ieri, abbiamo riferito che credevamo che l'app per iOS stesse usando "keepalive" per aggirare le restrizioni sullo sfondo. Dopo aver esaminato il codice sorgente dell'app iOS, abbiamo concluso che è proprio così. Come funzionano esattamente, però?
In poche parole, un keepalive - in questo contesto - è un'idea che gli sviluppatori dell'app hanno escogitato: è una notifica inviata tra due dispositivi iOS che eseguono l'app per mantenere viva la connessione tra i dispositivi. La cosa interessante di questo è che ha anche l'effetto di consentire all'app di rimanere sveglia per un tempo significativamente più lungo, poiché quando un dispositivo riceve un keepalive, iOS consente all'app di rimanere sveglia per eseguire ulteriori elaborazioni.
Da un punto di vista pratico, ciò significa che l'app sarà in grado di mantenere il suo stato di vita dato che è in prossimità di altri dispositivi. Questo, in un certo senso, è la logica del progetto di tracciamento COVID-19: anche senza questo trucco tecnico, una massa critica di utenti dovrà eseguire l'app di tracciamento per ottenere un buon risultato di sicurezza pubblica.
Indipendentemente da ciò, l'app non si addormenta immediatamente ed entra in uno stato sospeso quando è in background. La domanda diventa quindi se la maggior parte degli utenti disporrà di un numero sufficiente di dispositivi iOS o Android per rendere possibili le soluzioni alternative. La nostra opinione è che ciò sembra probabile, tanto più per gli utenti che si trovano più regolarmente nelle aree popolate. Il Bluetooth ha un raggio d'azione decente.
Alcuni osservatori hanno suggerito che la capacità dell'app di ricevere notifiche silenziose significava che stava usando queste funzionalità per svegliarsi da remoto. Tuttavia, queste funzionalità vengono semplicemente utilizzate per informare l'utente sul fatto che siano state vicine a chiunque abbia contratto COVID-19. L'app utilizza anche le notifiche locali che rilevano quando l'app viene uccisa dal sistema, che indica agli utenti di riaprirla. Una notifica simile viene utilizzata quando l'utente disabilita il Bluetooth.
Il CEO di Reincubate, Aidan Fitzpatrick, afferma:
Sì, è il caso che il prossimo framework Apple
ExposureNotification
in iOS 13.5 ovvi alla necessità di questi keepalive. Tuttavia, vale la pena notare che:
- iOS 13.5 non è stato rilasciato e potrebbe non esserlo per alcune settimane
- Prima di ieri, l'ultima versione beta di iOS 13.5 presentava un grave difetto di sicurezza , suggerendo che il team di ingegneri di Apple stava eseguendo operazioni di sollevamento pesanti
- Una volta rilasciato, probabilmente ci vorranno mesi prima che la maggior parte degli utenti iOS lo installi (insolitamente, l'adozione equivalente di Android potrebbe essere più rapida )
- I dispositivi iOS meno recenti, come l'iPhone 6, non possono eseguire iOS 13 e non potranno utilizzare la tecnica Apple
- Non vi è alcun motivo per cui l'app NHS COVID-19 non sarà in grado di passare automaticamente in futuro all'utilizzo del framework di Apple - o persino alla doppia esecuzione di entrambi i meccanismi
L'app diventerà sempre più efficace man mano che più persone la usano e il beneficio dell'adozione di massa creerà un effetto volano in questo senso. L'app COVIDSafe australiana ha faticato perché non supportava il rilevamento di dispositivi iOS in background da un dispositivo Android e non aveva questo intelligente meccanismo keepalive da iOS a iOS.
È importante riflettere su quali circostanze fanno uso di tecnologie come questa appropriate. Se la tracciabilità dei contatti ha successo nel salvare vite umane, quali criteri dovrebbero essere valutati se si applica alle malattie future? Una volta stabilito il precedente, c'è un argomento secondo cui questa tecnologia potrebbe essere utilizzata per combattere malattie infettive preesistenti ? È prevedibile che diverse società valuteranno i compromessi in modo diverso.
Tutela della privacy
Mentre scrivere un'analisi dettagliata della matematica dietro il protocollo è un po 'fuori portata per questo post, abbiamo dato un'occhiata alle garanzie sulla privacy. L'app sembra rispettare rigorosamente il documento rilasciato dall'NCSC . Possiamo confermare che nessun dato chiave lascia il dispositivo dell'utente fino a quando non segnalano i sintomi, e solo allora eseguono le chiavi anonime dei dispositivi che è stato nelle immediate vicinanze per lasciare il dispositivo. La prima metà del codice postale inserito dall'utente viene inviata all'API come parte del servizio di registrazione.
In definitiva, il codice suggerisce che c'è poco rischio tecnico sulla privacy dall'uso dell'app fino a quando un utente non segnala i sintomi e contatta il SSN per organizzare un test. A quel punto, il loro risultato del test sarebbe gestito dal SSN, anche se questo non è diverso con o senza l'app . Tuttavia, nel momento in cui più utenti entrano in contatto, segnalano i sintomi e organizzano i test utilizzando l'identificatore fornito dall'app , può essere o meno possibile collegarli centralmente. Questa è una domanda di back-end e, come afferma NHSX nel loro rapporto sulla privacy delle app, il codice è la verità in questo senso.
Proteggendosi da falsi rapporti
Poiché il back-end del sistema non è stato open source, non è possibile confermarlo, ma sembra che nessuna notifica push venga inviata ad altri dispositivi fino a quando i cittadini non risultano positivi per COVID-19. Una volta che un utente segnala sintomi, viene assegnato un codice di riferimento che può essere utilizzato per prenotare un test. (Questo codice sembra essere uguale al linkingId
abbiamo descritto nella sezione di registrazione.)
di Joseph
The termination notification seems unreliable in my testing of the production app. Might be that the app sometimes terminates before the notification has been scheduled.
They probably need to always have one scheduled a few minutes ahead and keep updating it further into the future on a timer while the app is running. That way when the app dies or is killed the notification is already scheduled.