Fattori nella protezione dei dati di app e cloud
Con la crescente quantità di dati preziosi archiviati nel cloud è tanto più importante che sia protetto in modo robusto. Forti misure di sicurezza sui servizi di dati cloud come iCloud vanno a beneficio di tutti: utenti finali, provider di servizi cloud come Apple e piattaforme di ecosistema come Reincubate.
I meccanismi per proteggere questi dati prendono un certo numero di forme e il track record di Apple di implementarle è stato buono. Questo articolo esamina una serie di tecniche che loro - e il team di Reincubate - hanno usato.
Conserva meno, se possibile
In primo luogo, la memorizzazione di meno anziché di più paga. Esistono esempi in cui i dati non sono mai stati archiviati in iCloud, ad esempio dove i dati di riconoscimento facciale di Foto non sono archiviati nella Libreria fotografica di iCloud, ma vengono memorizzati nella cache locale. Gli artefatti dei dati di HealthKit, HomeKit e TouchID di Apple sono trattati allo stesso modo, così come i dati di riconoscimento facciale di Android su schermo bloccato. Naturalmente, questo è spesso un compromesso di convenienza e il valore della sincronizzazione di tali dati tra dispositivi. Alcuni sistemi usano un approccio parziale. Ad esempio, iMessage memorizza una quantità limitata di contenuto nel cloud, ma si basa su altri dati sincronizzati direttamente tra i dispositivi.
Sistemi di messaggistica sicuri come Telegram o WhatsApp adottano un approccio completamente diverso. Poiché nessun dato (o almeno non molto) è memorizzato sui loro server, è necessario includere un ricco set di dati in qualsiasi backup di un dispositivo affinché un utente possa essere in grado di eseguire il backup e il ripristino in modo significativo. In un certo senso, per mantenere la sicurezza, i venditori di app si stanno privando della gestione di tali dati e li lasciano all'utente finale, che può scegliere di eseguire il backup dei propri dispositivi localmente o nel cloud.
Quindi ci sono due estremi, e uno può contrastare WhatsApp - con poco nel cloud e tutto nel backup - su Facebook Messenger, che non memorizza nulla in un backup del dispositivo perché è facilmente disponibile nel cloud, e deve essere in Facebook per fornire la sua interfaccia web.
Non c'è una soluzione giusta qui, ma pensa a questo: l'uso di un'app che ospita questi dati richiede che il fornitore di app lo gestisca in modo sicuro, spesso gli utenti restano all'oscuro di ciò che viene memorizzato e in che modo. L'utilizzo di un'app che non memorizza i dati centralmente significa che l'utente finale deve assumersi la responsabilità della sicurezza dei propri dati di backup, a meno che non lo lascino archiviare nel cloud della loro piattaforma, come nel caso di iCloud Backups e Android di Google 7.0+ backup del dispositivo.
È interessante notare che, come nella tabella qui sotto, alcuni produttori di app occupano entrambi gli estremi di questa posizione. L'app Snapchat memorizza quasi tutti i suoi dati nel cloud, mentre l'estensione fisica dell'app - Spectacles - memorizza tutti i propri dati localmente sul dispositivo.
Gli Snapchat Spectacles sono piuttosto insicuri, anche se non sono ampiamente diffusi: tenendo premuto il pulsante "snap" per sette secondi, un hacker può abbinarli a un nuovo telefono e ottenere uno degli snap non crittografati che sono stati memorizzati dal legittimo proprietario. Ciò è in netto contrasto con i principi di sicurezza adottati per Apple Watch.
Forte crittografia
Questo ci porta alla seconda tecnica critica: crittografia forte , idealmente con l'archiviazione incompleta delle chiavi. Se i dati vengono ritenuti troppo sensibili per essere sottoposti a backup in un modo a cui è possibile accedere in caso di distruzione o sostituzione di un dispositivo, esistono altre tecniche che possono essere utilizzate. Richiedendo l'uso di un dispositivo specifico, la funzione " Conversazioni segrete " di Facebook utilizza identificatori hardware per crittografare il contenuto. Se il dispositivo viene perso, il contenuto diventa praticamente irrecuperabile.
Alcuni sistemi impiegano una tecnica simile in cui è possibile creare un token specifico per dispositivo per garantire che solo un numero limitato di dispositivi possa accedere al contenuto alla volta. Snapchat e WhatsApp usano ciascuna una variazione di questo. Quando si accede a Snapchat su un dispositivo, un token viene creato e condiviso tra i server di Snapchat e il dispositivo. Se lo stesso utente si collega a un dispositivo diverso, verrà creato un nuovo token, sostituendo ciò che era prima nel cloud e forzando la disconnessione del primo dispositivo in quanto non sarebbe in grado di decrittografare i messaggi in entrata. Esiste un'evidente vulnerabilità a questa tecnica quando viene utilizzata su sistemi non sicuri, ovvero che il token può essere copiato e utilizzato altrove. Se è stato necessario un argomento sul motivo per cui l'utilizzo di un dispositivo iOS con root o Android jailbroken è una pessima idea, è proprio questo, e spiega anche perché è improbabile che sia un client web per Snapchat in qualunque momento presto.
Anche se una cosa è potenzialmente perdere i messaggi segreti di Facebook, alcuni dati sono altamente sensibili e molto preziosi per il suo proprietario. Sembra contro-intuitivo, ma se il valore personale se i dati sono abbastanza grandi, è spesso memorizzato in modo tale che ci sono molti modi potenziali per decodificarlo o recuperarlo. Ciò compromette la sicurezza con una scarsa praticità. Ad esempio, c'è una massa di dati associati agli account iCloud e Google, inclusi - in entrambi i casi - una qualche forma di portachiavi cloud distribuito, che memorizza tutte le password di un utente. Non solo, ma la promozione da parte di Google dei loro account come meccanismo di autenticazione su altri siti con OAuth significa che perdere irrimediabilmente l'accesso a account come questi sarebbe una pillola amara da ingoiare.
Dato che questi account sono considerati troppo preziosi per rischiare prontamente la loro perdita permanente, viene utilizzata una soluzione intermedia in cui i dati vengono archiviati nel cloud, ma crittografati con un token o una password che solo l'utente conserva e che non viene memorizzata. Questo è il motivo per cui, ad esempio, quando si accede a una nuova installazione del browser Chrome di Google, le password memorizzate nel cloud non sono disponibili fino a quando nel browser non è stata immessa una password di sincronizzazione secondaria.
Condivisione del carico di crittografia
Tim Cook di Apple - che è serio e fondamentalmente sulla sicurezza - ha testimoniato la loro convinzione in questa tecnica solo l'anno scorso:
Per molti anni abbiamo utilizzato la crittografia per proteggere i dati personali dei nostri clienti perché riteniamo che sia l'unico modo per mantenere le loro informazioni al sicuro. Abbiamo persino messo questi dati fuori dalla nostra portata, perché crediamo che i contenuti del tuo iPhone non siano affari nostri.
- Tim Cook in " Un messaggio ai nostri clienti "
Oltre a tutto ciò, questo può aiutare i fornitori di cloud a evitare di rivelare i dati completi dell'utente agli attori governativi. Se sono costretti a fornirlo con un mandato, possono farlo senza esporre direttamente i dati di un utente, in quanto i dati richiedono un'ulteriore decrittazione che può essere eseguita solo con una chiave che solo l'utente finale ha.
A volte, come nel caso dell'autenticazione a più fattori (MFA), dell'autenticazione a due fattori (2FA) o della verifica in due passaggi (2SV), ciò significa che la chiave aggiuntiva può essere inviata o generata solo da un particolare dispositivo. Banche e VPN utilizzano spesso lettori di tessere fisiche o generatori di sementi sicuri , che sono forme di generatori di password monouso basati sul tempo (OTP o TOTP). Sia Google che Apple offrono semplici MFA basati su SMS e sistemi 2FA completi, mentre Google utilizza HOTP / OATH e Apple è proprietario.
Quando le agenzie per la sicurezza o le forze dell'ordine (LEA) hanno questi dati crittografati ma non la chiave dell'utente finale per decrittografarli, possono provare a forzare la forza usando macchine potenti per testare i dati con password indovinate automaticamente. L'iOS di Apple ha un enorme vantaggio rispetto ad Android di Google qui: poiché Apple controlla strettamente l'hardware nei propri dispositivi, è in grado di progettare tecniche di crittografia che solo l'hardware può eseguire rapidamente e che altri dispositivi come i computer desktop eseguono lentamente. Quando Reincubate è diventata la prima azienda al mondo a supportare la decrittografia dei dati da 10.2 , il significato non era solo il fatto che la società fosse prima a capire come funzionava 10.2: era il primo a ridimensionare rapidamente la decifrazione della tecnica intelligente di Apple. Facendo in modo che ogni tentativo di decifrazione richiedesse un certo numero di secondi sull'hardware convenzionale, divenne impraticabile per gli hacker o LEA per la forza bruta.
Sicurezza attraverso l'oscurità
Non farebbe rivedere queste tecniche senza coprirne una che Apple sia particolarmente brava in: sicurezza attraverso l'oscurità. Non rilasciando API pubbliche, documentazione dettagliata o persino comunicando molto su questi sistemi, la società è in grado di evitare di avvisare gli hacker di potenziali vettori di attacco. Per lungo tempo, l'argomentazione contro l'oscurità è stata che la divulgazione e l'Open Source hanno portato a risultati di sicurezza migliori, ma questo era prima della scoperta del 2014 che OpenSSL - una libreria di sicurezza Open Source critica che praticamente tutto utilizza - era ed è quasi sempre stato fondamentalmente insicuro .
Per favore contattaci se desideri esplorare i modi di lavorare con i dati delle app o del cloud o se sei interessato a capire meglio le dinamiche dei diversi approcci.
