Apple suele ser muy opaca a la hora de explicar cómo funciona su sistema operativo móvil, iOS. Por eso resulta curioso ver toda la información que comparten en un paper sobre la seguridad en iOS, que expone los sistemas que usan para proteger los datos de sus usuarios.
Quizás esta publicación tenga algo que ver con el fallo de SSL de hace unos días. Sea como sea, el documento es una lectura recomendada si tenéis curiosidad por la criptografía y seguridad, aunque es bastante técnico. Por eso, en Genbeta vamos a desgranar las claves y a explicarlas, empezando por la seguridad del propio sistema y Secure Enclave.
Arranque y actualización del sistema
Apple pretende que el sistema sea seguro desde el primer momento. ¿Cómo lograr eso? Con una cadena de confianza que empieza en la ROM de arranque. Este segmento de memoria es sólo de lectura y se crea durante la fabricación del teléfono. Entre otras cosas, contiene la clave pública del certificado raíz de Apple.
Como vimos cuando explicamos la firma digital y como comentaban nuestros compañeros de Genbeta Dev, con la clave pública podemos verificar la firma y asegurarnos que los datos firmados no han variado absolutamente nada desde que Apple los creó y firmó con su clave privada.
De esta forma, el cargador de arranque verifica la firma del LLB (Low Level Bootloader). Este a su vez comprobará la firma de la siguiente etapa de arranque, iBoot, que finalmente verificará la firma del núcleo de iOS.
Esta cadena de confianza asegura que todo lo que se está ejecutando en el dispositivo está firmado por Apple. Teóricamente, no podríamos crear un SO alternativo y cargarlo en un iPhone: la verificación fallaría al cargar el núcleo y nos aparecería la pantalla de “Conectar a iTunes” para restaurar el teléfono.
Cupertino también tiene preparado un sistema de verificación para evitar los downgrades, instalación de versiones antiguas del sistema. La razón es impedir a posibles atacantes instalar versiones antiguas que tengan fallos de seguridad.
1: Apple habla de “mediciones criptográficas” de partes de la instalación (núcleo, cargador de arranque…) y no especifica en qué consisten. Probablemente sean hashes creados de alguna forma peculiar.
El proceso se llama System Software Authorization: se crea una especie de “firma”1 del sistema que se envía a Apple junto con un ID del dispositivo y un código (nonce) único para cada verificación.
Los servidores de Apple verifican que efectivamente esa versión de iOS se puede instalar y devuelve una autorización firmada al dispositivo. Al incluir el ID y el nonce, Apple se asegura de dos cosas respectivamente: que no estás reutilizando una autorización para otro dispositivo (por ejemplo, puedes instalar iOS 6 en un iPhone 3GS, pero no en un iPhone 5) y que no estás reutilizando autorizaciones que ya fueron usadas.
Secure Enclave y criptografía hardware
En el iPhone 5S, Apple incluyó el Secure Enclave, una “zona segura” del teléfono. Hasta ahora no había compartido más información sobre este tema. Hoy tenemos bastantes datos sobre ello.
La seguridad de Secure Enclave comienza en el momento en el que se arranca el sistema por primera vez. Durante la fabricación, se “imprime” en el chip un ID único (UID), que Apple dice no conocer y que no es accesible por ninguna otra parte del sistema. Ese UID se combina con una clave temporal para generar la clave de cifrado de la memoria de Secure Enclave, de tal forma que lo que se guarde ahí no podrá ser leído (teóricamente, como siempre) por nadie más.
Secure Enclave no es la única parte del sistema que cuenta con criptografía directamente en hardware. iOS cuenta con Data Protection, una característica para cifrar todos los datos sensibles, activada por defecto para todas las aplicaciones en iOS 7 cuando el usuario crea una contraseña de bloqueo.
Para poder cifrar esos archivos, Apple usa un sistema de criptografía hardware que se interpone entre la memoria del sistema y el disco de datos. Cuando leemos un archivo (por poner dos ejemplos, un ejecutable de una aplicación o un correo), pasa por el procesador criptográfico que cifra y descifra los archivos según corresponda, usando AES 256. Las claves de cifrado están de nuevo embebidas en el procesador, y ni el software ni el firmware pueden acceder a ellas.
Touch ID y contraseñas de bloqueo
Una de las características estrella del iPhone 5S es Touch ID. En este paper se profundiza más en cómo funciona el sistema, que está muy vinculado con las contraseñas de bloqueo del teléfono.
Al configurar tu huella dactilar, se escanea tu dedo y se guarda en la memoria de Secure Enclave. Tras ser analizada para obtener los rasgos que la identifican, la imagen de tu huella se elimina del teléfono. Los rasgos se guardan en el sistema de archivos del iPhone cifrados por Secure Enclave. Según Apple, esos datos cifrados no se envían a ningún servidor, ni se guardan en iCloud o iTunes.
El bloqueo del teléfono no es sólo una pantalla: los archivos protegidos dejan de estar accesibles y el sistema se “para”
¿Cómo funciona el proceso de bloqueo y desbloqueo? Mientras iOS está funcionando, los archivos que usen se descifran con una clave que está en memoria. Al bloquearse, esas claves se agrupan y se cifran con una clave que almacena el sistema Touch ID. En ese momento los archivos protegidos, como tus correos, aplicaciones o datos confidenciales de tus cuentas, se vuelven inaccesibles. Sin clave no hay ficheros, y sin ficheros no puedes hacer nada.
Así, cuando el teléfono está bloqueado, se mete en su caparazón, por así decirlo. Uno pensaría que bloquear el teléfono es sólo superficial y sólo sirve para evitar que tus amigos cambien los nombres de tus contactos cuando tú no miras. La realidad es que la protección es mucho más profunda. El teléfono está realmente bloqueado y no puede seguir funcionando porque no tiene acceso a los archivos cifrados.
Al desbloquear el iPhone con la huella dactilar o con la contraseña, se recuperan las claves y el sistema sigue funcionando normalmente accediendo a los ficheros protegidos.
Seguridad en iMessage: quizás no tan seguro
El paper de Apple también explica cómo funciona la seguridad en iMessage. El sistema usa cifrado de punto a punto, de tal forma que (en teoría, como veremos más adelante) los de Cupertino no pueden ver qué mensajes estás enviando.
2: Lectura recomendada: Criptografía asimétrica en Genbeta Dev.
Cuando vinculas un dispositivo con tu cuenta de iMessage, se crean dos pares de clave pública/privada2: uno para cifrar y otro para firmar. Las claves privadas se quedan en tu dispositivo y las públicas se envían al IDS, el directorio de usuarios de iMessage almacenado en los servidores de Apple.
¿Cómo se envían los mensajes? Supongamos que Alicia quiere enviar un mensaje a Bernardo, que es todo un fan de Apple y tiene un iPhone, un iPad, un Macbook y un iMac. Alicia escribe el mensaje en iMessage y le da a enviar. Entonces, la aplicación se conecta a IDS y mira los registros de Bernardo. Ve que tiene varios dispositivos y se descarga las claves públicas de cada uno de ellos junto con la dirección a la que enviarles el mensaje.
El iMessage de Alicia cifra el mensaje con la clave pública del iPhone de Bernardo, de tal forma que sólo ese dispositivo podrá descifrarlo con su clave privada, y lo envía a la dirección correspondiente. Hace lo mismo con cada uno de los dispositivos de Bernardo, enviando un mensaje cifrado a cada uno.
Si el mensaje incluye adjuntos, el iMessage de Alicia subirá cada adjunto cifrado a iCloud. El mensaje que se envíe a Bernardo contendrá información para descargar y descifrar el archivo desde iCloud.
El problema de iMessage es que no sabemos realmente a quién estamos enviando los mensajes
Sin embargo, este esquema tiene fallos, tal y como explica un usuario en Hacker News. Decíamos que en el directorio se guardan las claves públicas de los dispositivos de Bernardo. Ahora bien, ¿cómo sabemos que esos dispositivos son realmente de Bernardo? ¿Qué pasa si Bartolo, el hermano gemelo malvado de Bernardo, entra en los servidores de Apple e inserta la clave pública y dirección de su iPhone? A Bartolo le llegarían todos los mensajes de Bernardo, y Alicia no tendría forma de detectarlo.
Ese es el fallo del esquema de iMessage. Y es que no hace falta que sea Bartolo el superhacker quien entre a los servidores. Pensando mal, podríamos imaginarnos que Apple podría colocar claves públicas a petición de la NSA para espiar a ciertos usuarios. O quizás, si tu iPhone no ha sido actualizado, alguien podría manipular las respuestas del servidor IDS de Apple e introducir claves públicas adicionales para ver los mensajes que envías.
iCloud Keychain, contraseñas en la nube
Para acabar, repasemos cómo funciona iCloud Keychain, el servicio de Apple que permite sincronizar contraseñas en varios dispositivos.
La idea del Keychain de iCloud es, curiosamente, que las contraseñas no se almacenan en iCloud, al menos no de forma permanente. Lo que se almacena es un círculo de confianza que incluye las identidades de cada uno tus dispositivos.
Al activar Keychain por primera vez en tu cuenta, tu teléfono crea un par de clave pública y clave privada. La clave pública se almacena en el círculo de confianza, que se firma con la clave privada y con una clave derivada de tu contraseña de iCloud.
iCloud Keychain es como un club al que sólo puedes entrar si todos sus miembros te dejan.
Cuando añades otro dispositivo a iCloud Keychain, este crea su par de claves y, al detectar que ya hay otros dispositivos vinculados, crea una petición de vinculación. Esa petición o ticket contiene la clave pública del dispositivo, y está firmada con la clave derivada de la contraseña de iCloud. La petición se envía a iCloud.
En ese momento tienes que usar el teléfono en el que ya esté configurado iCloud Keychain, que habrá detectado que hay una petición pendiente y te preguntará con un popup si quieres añadir la nueva identidad. Si aceptas e introduces tu contraseña de iCloud, se verifica la firma y se añade la clave pública al círculo de confianza. De nuevo, el círculo se firma con la clave privada y la clave derivada. El nuevo dispositivo también firma el círculo con su clave privada.
El funcionamiento puede parecer bastante lioso (de hecho, lo es). Hagamos una analogía. iCloud Keychain es un club elitista del cual tú eres el presidente. Si alguien quiere entrar, primero tiene que preguntarte a ti el santo y seña. Después va al club y les dice a los miembros que quiere entrar, y les da el santo y seña. Ellos te preguntan si el santo y seña es válido. Si lo es, el nuevo miembro es bienvenido al club.
A la hora de enviar los datos, se hace entre los clientes. Si creas una nueva contraseña en tu iPhone y hay que sincronizarla en tu Macbook, el iPhone cifra la nueva entrada con la clave pública del Macbook y se la envía directamente a través de iCloud.
De esta forma, tus contraseñas se guardan en tus dispostivos. Se transmiten de tal forma que nadie más que el dispositivo destino puede descifrarlas.
Por otra parte, cada dispositivo envía una copia de seguridad de tus contraseñas a los servidores de Apple. Ahí se guarda cifrada con tu código de seguridad de iCloud, de tal forma que si pierdes tu dispositivo puedes recuperar las contraseñas. Las copias de seguridad están almacenadas en un cluster de servidores seguros, que cifran las copias de nuevo con una clave única para cada servidor. A la hora de recuperar la copia, se verifica que el usuario conoce el código de seguridad de iCloud sin pedirlo directamente (no sale del teléfono). Si todo sale bien, se envía la copia al usuario y se recuperan las contraseñas.
Como medida de seguridad adicional, el firmware de esos servidores borra automáticamente los registros si se tratan de desbloquear 10 veces sin éxito o si se intenta modificar el propio software de los servidores.
Estos son los aspectos más destacados del paper de Apple. Desde luego, es muy de agradecer tener tantas explicaciones sobre un aspecto en el que Apple es normalmente muy opaca. De nuevo, si tenéis curiosidad, en el PDF hay más datos y más técnicos, como por ejemplo el sistema de cifrado de archivos o cómo ejecutan sólo aplicaciones autorizadas en el teléfono.
Más información | iOS Security
