Con quantità sempre maggiori di dati di valore archiviate nel cloud, è ancora più importante che siano protetti in modo solido. Misure di sicurezza efficaci attorno ai servizi di dati cloud come iCloud giovano a tutti: agli utenti finali, ai fornitori di servizi cloud come Apple e alle piattaforme di ecosistema come Reincubate.
I meccanismi per proteggere questi dati assumono diverse forme, e i risultati di Apple nell’implementarli sono stati buoni. Questo articolo esamina alcune delle tecniche che Apple, e il team di Reincubate, hanno utilizzato.
Archivia meno, se possibile
Innanzitutto, archiviare meno anziché più paga. Ce ne sono esempi in cui i dati non sono mai stati archiviati su iCloud: i dati di riconoscimento facciale di Foto, per esempio, non vengono salvati nella Libreria foto di iCloud, ma tenuti in cache in locale. I dati di HealthKit, HomeKit e TouchID di Apple sono trattati in modo simile, così come i dati di riconoscimento facciale della schermata di blocco di Android. Naturalmente, spesso è un compromesso tra comodità e valore della sincronizzazione di quei dati tra i dispositivi. Alcuni sistemi adottano un approccio parziale. Per esempio, iMessage archivia nel cloud una quantità limitata di contenuti, ma si affida alla sincronizzazione diretta tra dispositivi per altri dati.
I sistemi di messaggistica sicura come Telegram o WhatsApp adottano un approccio completamente diverso. Poiché sui loro server non viene archiviato alcun dato (o comunque pochi), in qualsiasi backup di un dispositivo deve essere incluso un ricco insieme di dati, perché l’utente possa fare in modo sensato backup e ripristino. In un certo senso, per mantenere la sicurezza, quegli sviluppatori di app si lavano le mani della gestione di quei dati e la lasciano all’utente finale, che può scegliere di fare il backup dei propri dispositivi in locale o nel cloud.
Esistono quindi due estremi, e si può confrontare WhatsApp, con poco nel cloud e tutto nel backup, con Facebook Messenger, che non archivia nulla nel backup del dispositivo perché è già disponibile nel cloud, e deve esserlo affinché Facebook possa offrire la sua interfaccia web.
Qui non esiste una soluzione giusta, ma vale la pena rifletterci: usare un’app che ospita questi dati richiede che lo sviluppatore dell’app li gestisca in modo sicuro, spesso lasciando gli utenti all’oscuro di cosa viene archiviato e come. Usare un’app che non archivia i dati in modo centralizzato significa che l’utente finale deve assumersi la responsabilità della sicurezza dei propri dati di backup, a meno che non li lasci archiviati nel cloud della propria piattaforma, come avviene con i backup di iCloud e con i backup dei dispositivi Android 7.0+ di Google.
È interessante notare che, come nel grafico qui sotto, alcuni produttori di app occupano entrambi gli estremi di questa posizione. L’app Snapchat archivia quasi tutti i suoi dati nel cloud, mentre l’estensione fisica dell’app, gli Spectacles, archivia tutti i dati in locale sul dispositivo.
Diversi approcci alla sicurezza dei dati delle app
Anche se non ampiamente diffusi, gli Spectacles di Snapchat sono piuttosto insicuri: tenendo premuto il pulsante «snap» per sette secondi, un hacker può associarli a un nuovo telefono e ottenere tutti gli snap non cifrati che il legittimo proprietario vi aveva archiviato. Questo contrasta nettamente con i principi di sicurezza adottati per l’Apple Watch.
Cifratura forte
Questo ci porta alla seconda tecnica fondamentale: la cifratura forte, idealmente con archiviazione incompleta delle chiavi. Se i dati sono considerati troppo sensibili per essere salvati in un backup accessibile in caso di distruzione o sostituzione del dispositivo, esistono altre tecniche. Richiedendo l’uso di un dispositivo specifico, la funzione «Secret Conversations» di Facebook usa identificatori hardware per cifrare i contenuti. Se il dispositivo va perso, il contenuto diventa praticamente irrecuperabile.
Alcuni sistemi usano una tecnica simile, in cui si può creare un token specifico del dispositivo per garantire che solo un numero limitato di dispositivi alla volta possa accedere ai contenuti. Snapchat e WhatsApp ne usano ciascuno una variante. Quando si accede a Snapchat su un dispositivo, viene creato un token e condiviso tra i server di Snapchat e il dispositivo. Se lo stesso utente accede da un altro dispositivo, viene creato un nuovo token, che sostituisce quello presente prima nel cloud e costringe il primo dispositivo a uscire, perché non sarebbe in grado di decifrare i messaggi in arrivo. Questa tecnica ha un’ovvia vulnerabilità quando è usata su sistemi non sicuri: il token può essere copiato e usato altrove. Se serviva un argomento per capire perché usare un dispositivo Android con root o un dispositivo iOS con jailbreak è una pessima idea, eccolo, e spiega anche perché è improbabile che a breve ci sia un client web per Snapchat.
Un conto è rischiare di perdere dei messaggi segreti di Facebook, ma alcuni dati sono sia altamente sensibili sia di grande valore per il loro proprietario. Sembra controintuitivo, ma se il valore personale dei dati è abbastanza grande, spesso vengono archiviati in modo tale che esistano molti modi possibili per decifrarli o recuperarli. Questo bilancia la sicurezza con una minore impraticabilità. Per esempio, a iCloud e agli account Google è associata una massa di dati, tra cui, in entrambi i casi, una qualche forma di keychain cloud distribuito che archivia tutte le password dell’utente. Non solo: la promozione da parte di Google dei propri account come meccanismo di autenticazione su altri siti con OAuth fa sì che perdere in modo irrecuperabile l’accesso ad account come questi sarebbe un boccone molto amaro.
Dato che questi account sono considerati troppo preziosi per rischiarne facilmente la perdita definitiva, si usa una soluzione intermedia in cui i dati sono archiviati nel cloud, ma cifrati con un token o una password che solo l’utente conserva, e che non viene archiviata. Per questo, per esempio, quando si accede a una nuova installazione del browser Chrome di Google, le password archiviate nel cloud non sono disponibili finché nel browser non viene inserita una password di sincronizzazione secondaria.
Condividere l’onere della cifratura
Tim Cook di Apple, che è serio e fondamentalmente nel giusto in materia di sicurezza, ha attestato la sua fiducia in questa tecnica solo l’anno scorso:
For many years, we have used encryption to protect our customers’ personal data because we believe it’s the only way to keep their information safe. We have even put that data out of our own reach, because we believe the contents of your iPhone are none of our business.
— Tim Cook in «A Message to Our Customers»
Tra le altre cose, questo può aiutare i fornitori di servizi cloud a evitare di divulgare i dati completi degli utenti ad attori governativi. Se vi sono obbligati da un mandato dell’autorità, possono farlo senza esporre direttamente i dati dell’utente, poiché i dati richiedono un’ulteriore decifratura che può essere effettuata solo con una chiave in possesso esclusivamente dell’utente finale.
A volte, come nel caso dell’autenticazione a più fattori (MFA), dell’autenticazione a due fattori (2FA) o della verifica in due passaggi (2SV), questo significa che la chiave aggiuntiva può essere inviata o generata solo da un dispositivo specifico. Banche e VPN usano spesso lettori di carte fisici o generatori di seed sicuri, che sono forme di generatori di password monouso basate sul tempo (OTP o TOTP). Sia Google sia Apple offrono una semplice MFA via SMS oltre a sistemi 2FA completi, con quello di Google che usa HOTP/OATH e quello di Apple che è proprietario.
Quando le agenzie di sicurezza o le forze dell’ordine (LEA) hanno questi dati cifrati ma non la chiave dell’utente finale per decifrarli, possono tentare un attacco a forza bruta, usando macchine potenti per testare i dati con password generate automaticamente. Qui iOS di Apple ha un enorme vantaggio su Android di Google: poiché Apple controlla strettamente l’hardware dei propri dispositivi, può progettare tecniche di cifratura che solo il suo hardware esegue rapidamente e che altri dispositivi, come i computer desktop, eseguono lentamente. Quando Reincubate è diventata la prima azienda al mondo a supportare la decifratura dei dati da 10.2, il punto non era solo che l’azienda fosse la prima a capire come funzionasse 10.2: eravamo i primi a rendere scalabile la decifratura rapida dell’ingegnosa tecnica di Apple. Facendo sì che ogni tentativo di decifratura richieda diversi secondi su hardware convenzionale, la forza bruta è diventata impraticabile per hacker e LEA.
Sicurezza tramite segretezza
Non sarebbe giusto passare in rassegna queste tecniche senza trattarne una in cui Apple è particolarmente brava: la sicurezza tramite segretezza. Non rilasciando API pubbliche, documentazione dettagliata né comunicando molto su questi sistemi, l’azienda riesce a evitare di mettere gli hacker sulla pista di potenziali vettori di attacco. Per molto tempo l’argomento contro la segretezza è stato che la divulgazione e l’open source portassero a risultati migliori in termini di sicurezza, ma era prima della scoperta del 2014 che OpenSSL, una libreria di sicurezza open source fondamentale usata praticamente da tutto, era, e quasi sempre è stata, fondamentalmente insicura.
Contattaci se vuoi esplorare modi di lavorare con i dati delle app o del cloud, o se ti interessa capire meglio le dinamiche dei diversi approcci.
