Apple espone i dettagli di sicurezza di iOS

Ormai hai sentito che Apple ha annunciato un nuovo programma di ricompensa dei bug durante la recente conferenza di Black Hat. In un aspetto insolito, Ivan Krstic, capo dell'ingegneria e dell'architettura della sicurezza di Apple, ha fatto l'annuncio personalmente. Ma erano solo gli ultimi 10 minuti di una presentazione di 50 minuti. Per i primi 40 minuti, Krstic ha fatto un tuffo senza precedenti in tre componenti della sicurezza iOS. E per profondo, intendo batyspheric.

Il mio generale da asporto era un senso di timore reverenziale per quanto questi sistemi proteggessero i dati degli utenti, anche dalla stessa Apple. Proverò a trasmettere ciò che è stato detto, senza diventare troppo tecnico.

Mappatura JIT WebKit indurita

Scusa, è così che si chiama. JIT sta per Just In Time e si riferisce al modo in cui il codice Javascript viene compilato appena in tempo per la sua esecuzione. "Questo è necessario per JavaScript ad alte prestazioni", ha spiegato Krstic. "Ma la politica di firma del codice deve essere attenuata. Il compilatore JIT emette un nuovo codice non firmato. Un utente malintenzionato che ha gestito un attacco in scrittura ovunque potrebbe consentire l'esecuzione di codice arbitrario."

Per un piccolo sfondo, le aree di memoria possono essere contrassegnate con autorizzazioni di lettura, scrittura ed esecuzione. Quella distinzione, introdotta anni fa, annullò gli attacchi che eseguivano il codice in aree dedicate ai dati. In breve, la soluzione di Apple prevede una tecnica che mette JavaScript compilato in un'area di memoria che consente solo l' esecuzione. I processi non possono leggere cosa c'è o scrivere nuovi dati. C'è un po 'più di questo, ma questa modifica, specifica per iOS 10, cancella tutta una gamma di possibili attacchi.

Processore Secure Enclave

Le applicazioni su un dispositivo Apple vengono eseguite in una CPU denominata Application Processor o AP. I moderni dispositivi Apple hanno una CPU completamente separata chiamata Secure Enclave Processor o SEP. "Il SEP è protetto da una chiave master crittografica avanzata dal passcode dell'utente", ha affermato Krstic. "L'attacco offline non è possibile. Evita la superficie di attacco dell'AP, anche quando l'AP è stato compromesso. Arbitra su tutti gli accessi dell'utente e gestisce la propria memoria crittografata. Alla prima inizializzazione utilizza un vero generatore di numeri casuali per creare un unico chiave del dispositivo all'interno del processore. Non è esportabile ed è memorizzata nella ROM sicura immutabile."

Krstic ha continuato a spiegare come il dispositivo utilizza quattro tipi di chiavi di sicurezza interne con caratteristiche diverse. Il tipo A esiste solo quando il dispositivo è sbloccato. Il tipo B è una chiave pubblica sempre presente, oltre a una chiave privata che esiste quando il dispositivo è sbloccato. Il tipo C viene creato la prima volta che il dispositivo viene sbloccato dopo l'avvio. E il tipo D è sempre disponibile.

La presentazione è passata a una serie di diagrammi estremamente complessi. Uno ha seguito il processo di avvio e sblocco del dispositivo, mostrando come ogni tipo di chiave è stato creato e memorizzato. Ogni file sul tuo dispositivo ha una sua chiave di crittografia unica; un altro diagramma mostrava la complessa danza che consente al SEP di autenticare e decrittografare quel file mantenendo al contempo le chiavi di sicurezza essenziali al suo interno. Un altro ha spiegato il complesso processo che ti consente di scegliere "Aggiorna più tardi". E ancora un altro ha attraversato il processo che consente lo sblocco tramite touch ID senza mantenere la chiave principale visibile in alcun modo.

La chiave da asporto di questa parte del discorso è che Apple ha davvero, davvero riflettuto su ciò che è necessario per gestire la crittografia completamente all'interno del processore Secure Enclave, senza costringere l'utente ad affrontare molti problemi. Se desideri vedere questi schemi da solo, dai un'occhiata alla presentazione completa di Krstic.

Sincronizzare i segreti

È estremamente conveniente che puoi sincronizzare i tuoi dati tra più dispositivi Apple. HomeKit ti consente di gestire i dispositivi IoT, AutoUnlock sblocca il tuo Mac quando Apple Watch è nelle vicinanze, le tue foto si sincronizzano tramite iCloud e così via. Ma per quanto riguarda la sicurezza, la sincronizzazione è un problema.

"Gli approcci tradizionali non sono buoni", ha detto Krstic. "Un modo è far sì che l'utente inserisca una forte" chiave del calzino "su tutti i dispositivi; perderla e si perde l'accesso ai segreti. L'altro modo è avvolgere i dati in una chiave derivata che lascia i dati esposti al fornitore di account ".

"Avevamo un certo numero di obiettivi qui", ha continuato Krstic. "I segreti devono essere disponibili su tutti i dispositivi, protetti da una forte crittografia. Gli utenti possono recuperare i segreti anche se perdono tutti i dispositivi connessi. I dati non sono esposti ad Apple e non esiste la possibilità di un attacco a forza bruta."

L'autenticazione nel sistema portachiavi iCloud di base è semplice. Ogni dispositivo ha la propria coppia di chiavi e per aggiungere un nuovo dispositivo al cerchio di sincronizzazione, è necessario approvarlo da uno dei dispositivi esistenti. Il backend di Apple non è coinvolto; non ha privilegi. Se un utente perde l'accesso a tutti i dispositivi, l'accesso può essere recuperato utilizzando sia la chiave di sicurezza iCloud che la password iCloud.

Krstic ha spiegato in dettaglio come Apple gestisce questo sistema senza lasciare la minima possibilità che chiunque, incluso chiunque in Apple, possa accedere ai dati dal back-end. Il sistema coinvolge quelle che vengono chiamate carte admin, create al momento della messa in servizio di una nuova flotta di server crittografici. "Le schede di amministrazione vengono create in una cerimonia sicura quando viene commissionata la flotta e conservate in cassette di sicurezza fisiche separate in custodia di tre diverse organizzazioni presso Apple, in sacchetti per prove a prova di manomissione", ha affermato Krstic.

Tale situazione dura solo fino a quando la flotta non viene effettivamente messa in funzione. A quel tempo, disse Krstic, "Abbiamo messo le carte admin attraverso una nuova funzione hash unidirezionale". Tirando un frullatore chiaramente usato da sotto il podio, ha continuato, "Sì, un viaggio attraverso il frullatore". Una volta che la flotta di server crittografici è attiva, non può essere aggiornata o modificata in alcun modo, nemmeno da Apple, perché le schede di amministrazione sono state distrutte. Se succede che è davvero necessario un aggiornamento, Apple deve creare una nuova flotta e inviare un aggiornamento software che colleghi i dispositivi degli utenti alla nuova flotta.

"Perché lo facciamo", disse Krstic. "Perché facciamo questo ultimo passo che è estremamente insolito? Facciamo tutto il possibile per progettare i sistemi di sicurezza per fornire fiducia. Quando i dati lasciano il dispositivo, la posta in gioco è ancora più alta. Dobbiamo mantenere quella fiducia. Se manteniamo il possesso di quelle schede di amministrazione, c'è la possibilità che non sia vero. Ecco come prendiamo sul serio la nostra missione sui dati degli utenti ".

Alla domanda "Hai fatto questo a causa delle richieste di informazioni dell'FBI?" Krstic rispose: "Sono un ingegnere. Posso solo rispondere alle domande sul perché ho presentato oggi." OK, abbastanza giusto. Ma penso che l'interrogatore avesse ragione. Realizzare un sistema autonomo che non puoi nemmeno modificare da solo è un ottimo modo per impedire a qualcun altro di apportare modifiche indesiderate.

Spero di aver trasmesso il livello di dettaglio nei discorsi di Krstic senza far brillare gli occhi. A giudicare dalle chiacchiere mentre il gruppo si disperdeva, i veri fanatici della sicurezza a livello di byte nella stanza erano molto colpiti.