Apple exposa les dades de seguretat de iOS

Ja heu sabut que Apple va anunciar un nou programa de recompensa d’errors a la recent conferència de Black Hat. En una aparença insòlita, Ivan Krstic, el cap d’enginyeria i arquitectura de seguretat d’Apple, va fer l’anunci ell mateix. Però això va ser només els darrers 10 minuts d’una presentació de 50 minuts. Durant els primers 40 minuts, Krstic va aprofundir sense precedents en tres components de seguretat d’iOS. I, a fons, vull dir banyisfèric.

El meu emport general va ser una sensació d'estranyar per la forma en què aquests sistemes protegeixen les dades dels usuaris, fins i tot des d'Apple mateix. Intentaré transmetre el que es va dir, sense arribar a ser massa tècnic.

Mapeig JIT endurit de WebKit

Ho sento, així es diu. JIT significa Just In Time i fa referència a la manera en què es recopila el codi Javascript a temps per a la seva execució. "Això és necessari per a JavaScript d'alt rendiment", va explicar Krstic. "Però s'ha de relaxar la política de signatura de codis. El compilador JIT emet un codi nou sense signar. Un atacant que gestionava un atac d'escriptura en qualsevol lloc podria permetre l'execució de codi arbitrari."

Per a una mica de fons, es poden marcar àrees de memòria amb permisos de lectura, escriptura i execució. Aquesta distinció, introduïda fa anys, va provocar atacs que van executar codi en àrees dedicades a les dades. Breument, la solució d'Apple inclou una tècnica que inclou el JavaScript compilat a una àrea de memòria que només permet l'execució. Els processos no poden llegir el que hi ha ni escriure noves dades. Hi ha una mica més que això, però aquest canvi, específic per a iOS 10, elimina tota una gamma de possibles atacs.

Processador d’enclavament segur

Les aplicacions d’un dispositiu Apple s’executen en una CPU anomenada Processador d’aplicacions o AP. Els moderns dispositius Apple tenen una CPU completament separada anomenada Secure Enclave Processor o SEP. "El SEP està protegit per una clau clau criptogràfica forta de la contrasenya de l'usuari", va dir Krstic. "L'atac fora de línia no és possible. Es contempla la superfície d'atac de l'AP, fins i tot quan l'AP ha estat compromesa. Arbitra tot l'accés de l'usuari i gestiona la seva memòria xifrada. A la primera inicialització, utilitza un veritable generador de números aleatoris per crear un únic clau del dispositiu dins del processador. No és exportable i es troba en una ROM segura immutable."

Krstic va explicar com el dispositiu utilitza quatre tipus de claus de seguretat internes amb característiques diferents. El tipus A només existeix quan es desbloqueja el dispositiu. El tipus B és una clau pública sempre present, a més d'una clau privada que existeix quan es desbloqueja el dispositiu. El tipus C comença a existir la primera vegada que es desbloqueja el dispositiu després de l’arrencada. I el tipus D sempre està disponible.

La presentació es va traslladar a diversos esquemes seriosament complicats. Una va recórrer el procés d’arrencada i desbloqueig del dispositiu, mostrant com es va crear i emmagatzemar cada tipus de clau. Cada fitxer del dispositiu té la seva única i única clau de xifrat; un altre diagrama mostrava la complexa dansa que permet al SEP autentificar i desxifrar aquest fitxer mantenint les claus de seguretat essencials dins de si mateix. Un altre va explicar el procés complex que permet triar "Actualitzar més endavant". I un altre es va dur a terme pel procés que permet desbloquejar mitjançant touch ID sense deixar visible la tecla mestra de cap manera.

El tret de sortida clau d'aquesta part de la xerrada és que Apple ha pensat realment a través del que és necessari per gestionar el xifrat completament dins del processador Secure Enclave, sense obligar l'usuari a passar molts problemes. Si voleu veure aquests diagrames per si mateix, consulteu la presentació completa de Krstic.

Sincronització de secrets

És molt convenient que pugueu sincronitzar les vostres dades entre diversos dispositius Apple. HomeKit us permet gestionar dispositius IoT, AutoUnlock desbloqueja el vostre Mac quan el vostre Apple Watch es troba a prop, les vostres fotos es sincronitzen mitjançant iCloud, etc. Però és segur que la sincronització és un problema.

"Els enfocaments tradicionals no són bons", va dir Krstic. "Una forma és fer que l'usuari introdueixi una forta clau de calaix en tots els dispositius; es perdi i es perd l'accés als secrets. L'altra manera és embolicar les dades en una clau derivada que deixa les dades exposades a proveïdor de comptes."

"Teníem diversos objectius aquí", va continuar Krstic. "Els secrets han d'estar disponibles en tots els dispositius, protegits per criptogrames forts. Els usuaris poden recuperar secrets fins i tot si perden tots els dispositius connectats. Les dades no estan exposades a Apple i no hi ha possibilitat que es produeixi un atac de força bruta".

L’autenticació al sistema bàsic iCloud Keychain és senzilla. Cada dispositiu té la seva pròpia parella de claus i, per afegir un dispositiu nou al cercle de sincronització, cal aprovar-lo des d’un dispositiu existent. El recolzament d'Apple no està implicat; no té cap privilegi. Si un usuari perd l'accés a tots els dispositius, es pot recuperar amb la clau de seguretat de iCloud i la contrasenya de iCloud.

Krstic va explicar amb tot detall com Apple gestiona aquest sistema sense deixar oberta la més mínima possibilitat que qualsevol, inclòs qualsevol persona d'Apple, pogués accedir a les dades des del fons. El sistema implica el que s’anomenen targetes d’administració, creades en el moment en què s’encarrega una nova flota de servidors crypto. "Les targetes d'administració es creen en una cerimònia segura quan s'ofereix la flota i s'emmagatzemen en caixa forta física separada a la custòdia de tres organitzacions diferents a Apple, en bosses de prova antinacció", va dir Krstic.

Aquesta situació només dura fins que la flota es posi en funcionament. Aleshores, va dir Krstic, "Vam posar les targetes d'administració mitjançant una nova funció de hash unidireccional". Arribant una batedora clarament usada des del podi, va continuar: "Sí, un viatge per la batedora". Una vegada que la flota de servidors crypto estigui activa, no pot ser actualitzada ni modificada de cap manera, ni tan sols per Apple, perquè les targetes d’administració s’han destruït. Si es produeix una actualització realment necessària, Apple ha de crear una nova flota i enviar una actualització de programari que fa que els dispositius dels usuaris es connectin a la nova flota.

"Per què fem això", va dir Krstic. "Per què fem aquest darrer pas que és extremadament inusual? Ens dirigim molt a enginyar els sistemes de seguretat per proporcionar confiança. Quan les dades surten del dispositiu, les apostes són encara més elevades. Cal mantenir aquesta confiança. Si mantenim possessió de Aquestes targetes d’administració hi ha la possibilitat que no sigui cert. Així de seriosament ens prenem la nostra missió sobre les dades d’usuari."

Va preguntar: "Ho heu fet a causa de les sol·licituds d'informació de l'FBI?" Krstic va respondre: "Sóc enginyer. Només puc respondre a preguntes sobre per què he presentat avui". D'acord, prou. Però crec que l’interrogant tenia raó. Fer un sistema autònom que ni tan sols es pot modificar és una manera molt bona d’evitar que algú altre faci canvis no desitjats.

Espero que hagi explicat el nivell de detall a la xerrada de Krstic sense fer que els ulls es vegin encongits. A jutjar per la xerrameca a mesura que el grup es va dispersar, els autèntics frikis de seguretat de nivell de byte a la sala van quedar molt impressionats.