Apple T2 Security Chip: ¿Se puede recuperar los datos de un SSD cifrado?

(Gracias Jaime) Me apunta Jaime que Apple ha dejado una puerta para poder recuperar los datos del SSD de un MMac en caso de que se estropee parte de la placa base. Como comentaba en Apple T2 Security Chip Overview, por defecto el chip T2 del Mac cifrará el contenido de la SSD aunque no se haya configurado FileVault. Bien, pues suponiendo que parte de la circuitería de la placa base funcione, especialmente la parte de Secure Enclave del T2 y el bus thunderbolt funcione, parece ser que Apple tiene un modo de funcionamiento que permitiría extraer los datos del SSD del ordenador.

Esto, sin embargo, presenta de nuevo un problema: Si te roban el portátil y no tienes activado FileVault, podrían extraer tus datos sin dificultad. En todo caso, el T2 lo que permitiría es evitar que alguien use la SSD en otro ordenador, atando esa SSD a un ordenador determinado.

El chip T2 está involucrado en el cifrado del disco (su motor de cifrado está en el bus que comunica la CPU/RAM con el SSD), lo que sería interesante ver es como la clave que se genera para cifrar el disco depende de las claves del T2 o es independiente.

Apple T2 Security Chip Overview

Apple acaba de publicar un informe sobre el chip T2 y las funciones que desempeña dentro de la plataforma Mac.

El chip tiene dos funciones bien diferenciadas:

• Implementa varios controladores que se encargan del sonido, procesado de imagen, controlar la SSD y el manejo del sistema
• Un coprocesador llamado Secure Enclave que se encargará de proporcionar seguridad a la plataforma y ser la raíz de confianza de todo el sistema de firma del sistema.

El documento de Apple se centra en la descripción de las funciones del Secure Enclave y como interactúa con el resto de los componetes de la plataforma, tanto de hardware como de software.

Según el documento publicado por Apple,este Secure Enclave incluido en el chip T2 va a ser el encargado de de dar soporte a todo lo relacionado con el cifrado y la gestión de las claves usadas en los procedimientos criptográficos que realice el ordenador. Además, se va a encargar de varias operaciones de cifrado sin que las claves usadas salgan del chip, ni siquiera a través de mecanismos de depuración como puede ser una interfaz JTAG.ve

El Secure Enclave contiene una clave AES, llamada UID, definida en la fabricación de cada chip. Esta clave nunca abandona dicho coprocesador y la única manera de obtenerla sería sacar el chip de la máquina y realizar una ingenieria inversa sobre el chip. Además, existe una segunda clave, llamada GID es común a todos los procesadores de una misma clase. Ambas claves se utilizan en un motor de cifrado que implementa el algoritmo AES implementado en el chip, de tal manera que el coprocesador cifrará los datos que se le pida y devolverá los resultados.

El Secure Enclave está situado entre el procesador y el acceso al almacenamiento SSD, de tal manera que es capaz de cifrar los datos de manera muy rápida cuando se almacenan en el SSD

Estas claves se utilizan para implementar una jerarquía de claves que se usará en las diferentes necesidades de cifrado que tenga el ordenador. Como estas claves depende de una única de cada dispositivo, una vez habilitado el cifrado de disco con FileVault, no podrá acceder a los datos ni siquiera cambiando la SSD de ordenador, ya que la clave de cifrado depende del chip T2. Esto nos deja una primera consecuencia importante: Si se te estropea el hardware del Mac, como no tengas una copia de seguridad externa, no vas a poder recuperar tus datos. Decir quie si no se ha activado FileVault, se usará la clave UID, con lo cual, tampoco se podrá sacar los chips y leerlo en otro ordenador.

Otra particularidad importante del Secure Enclave es que si fallamos demasiadas contraseñas, el chip ya no realizará más tareas de verificación de claves o intentos de descifrar el volumnen de datos:

To prevent malware from causing permanent data loss by trying to attack the user’s password, these limits are not enforced after the user has successfully logged into the Mac, but will be re-imposed after reboot. If the 30 attempts are exhausted, 10 more attempts are available after booting into macOS Recovery. And if those are also exhausted, then 30 more attempts are available for each enabled FileVault recovery mechanism (iCloud recovery, FileVault recovery key, and institutional key), for a maximum of 90 possible attempts. Once those attempts are exhausted, the Secure Enclave will no longer process any requests to decrypt the volume or verify the password

Otra misión que tiene el Secure Enclave es garantizar que los programas encargados de arrancar el Mac no han sido alterados. Para eso, se utiliza la firma digital de los mismos, apoyándose en la autoridad de certificación que está dentro del chip. Además, para evitar modificaciones, el primer código que se ejecuta no es actualizable, ya que se encuentra en una ROM dentro del propio chip T2. A partir de ahí, se irán verificando los diferentes componentes que forman la cadena de arranque.

Este chip también es el encargado de gestionar las huellas digitales que usa el sensor Touch Id y tiene incorporado un generador de números aleatorios para usar en las funciones criptográficas.

Este Secure Enclave no es algo nuevo: Apareció por primera vez en los iPhones que tenían sensor de huella digital. Y ha habido diversos intentos de ver como funciona o acceder a su firmware. Por ejemplo, la presentación de la BlackHat Demystifying the Secure Enclave Processor donde se analiza el firmware del mismo desde una de las actualizaciones de Apple. (también está disponible video de la charla, Demystifying the Secure Enclave Processor y el artículo con el mismo tema. Para los que os guste la ingeniería inversa, de obligada consulta.

Referencias

1. informe sobre el chip T2
2. Seguridad de iOS (iOS 11)
3. Demystifying the Secure Enclave Processor
4. Demystifying the Secure Enclave Processor, Diapositivas de la BlackHat

Cifrar un disco externo o un USB con MacOS X High Sierra

Supongamos que queremos cifrar un disco externo o un pincho USB por si se nos pierde nadie tenga acceso a los datos. Y el sistema operativo que estamos usando es MacOS X , en su última versión, High Sierra (10.13). Los pasos que hay que dar son los siguientes:

En primer lugar, un dispositivo que vaya a ser cifrado, debe de tener una tabla de particiones de tipo GUID Partition Table. Para que un dispositivo tenga esa tabla de particiones debe de borrarse y formatearse de acuerdo a este estándar de particiones. Esto se hace usando la Utilidad de discos. Lo ejecutamos , seleccionamos Mostrar todos los dispositivos en el menú de Visualización (si se pulsa comando-2) la vista cambia directamente. La utilidad de disco nos mostrará el siguiente menú:

En este caso se puede ver un disco, TDK LoR TF10 Media que va a ser el que vamos a cifrar. En este caso, al tener dicho disco un sistema de ficheros FAT, se puede ver el volumen y el disco. Procedemos a borrarlo y a crear una tabla de particiones de tipo GPT: Pulsamos boton derecho y elegimos borrar

La Utilidad de Discos desplegará un cuadro de diálogo donde debemos elegir el formato del sistema de ficheros, el nombre que le daremos al volumen y el tipo de tabla de particiones que se va a uar. La tabla de particiones debe ser Mapa de particiones GUID y el sistema de ficheros Mac OS Plus (con registro, encriptado) o APFS (encriptado) - bueno, cualquiera de los encriptados -. En el ejemplo, se ve que el volumen se va a llamar KEYS. Pulsamos en borrar para que el contenido se borre y se cree la nueva tabla de particiones. Como hemos elegido un sistema de ficheros encriptado, la Utilidad de Discos nos preguntará por la contraseña que se va usar para cifrar. Una vez introducida la contraseña, pulsamos en borrar y el sistema nos creará el sistema de ficheros encriptado

Si expulsamos el disco y lo volvemos a introducir, el sistema nos mostrará un cuadro de diálogo para que introduzcamos la contraseña del disco cifrado para poder acceder al mismo.

Yahoo analiza los correos de sus usuarios para las fuerzas de seguridad

En varios medios de comunicación se ha publicado la siguiente noticia:Yahoo analiza los correos de sus usuarios por encargado de varias agencias de seguridad de EEUU. Reconozco que no me sorprenda en absoluto, sobre todo desde que tuve conociendo de la existencia de Communications Assistance for Law Enforcement Act. Todos los gobiernos tienen diferentes leyes que le facultan a la intervención electrónica de las comunicaciones. No iba a ser distinto con el caso del correo electrónico.

Leyendo diferentes tweets sobre el tema, algunos sugieren cerrar la cuenta en Yahoo y usar otro servicio de correo. A mi esa respuesta me parece llena de ingenuidad: ¿De verdad pensamos que Google o Apple o Microsoft no se enfrentan a los mismos requerimientos legales que Yahoo en EEUU?. ¿Qué no ocurre lo mismo en los países europeos?. Desde mi punto de vista, lo que ocurre es que todavía nadie ha filtrado la información.

El que quiera preservar esa privacidad tendrá que usar sistemas extremo a extremo de cifrado como PGP o GPG y verificar las firmas que utiliza. ¿Qué tanto por ciento de personas usan esta solución?. La nube ha hecho realmente sencilla la monitorización de información de correo.

AMD SME/SEV: Cifrado de memoria en el microprocesador y máquinas virtuales

Una de las nuevas funciones que va a incluir AMD en su próxima microarquitectura (Zen) es la posibilidad de cifrar usando el algoritmo AES los datos antes de escribirlos en memoria con una clave que se generada dentro del chip. AMD ha publicado un artículo, AMD MEMORY ENCRYPTION donde se describe esta nueva funcionalidad así como una serie de parches para Linux que habilitan el cifrado

Cuando se activa el cifrado de memoria, existe un nuevo bit en las tablas que describen las páginas de memoria. Si ese bit está activo, cuando se escriban datos desde la CPU hacía la memoria física que describe ese marco de página, será cifrada internamente por la CPU y descifrada al leerla. El controlador de memoria integrado en la CPU es el encargado de gestionar el cifrado y descifrado de la misma. La clave de cifrado para AES es aleatoria y se genera en cada arranque de la CPU. Nunca es visible para los programas que ejecuta la CPU y se maneja desde el AMD Secure Processor, un procesador Cortex-A5 integrado en el SOC.Esta tecnología no sólo funciona con los accesos a RAM, sino que también puede usarse con los dispositivos que realizan transferencias DMA a la RAM del sistema.

Como puede verse, se necesita soporte desde el sistema operativo para que configure las tablas de páginas adecuadamente para usar el cifrado de memoria. Para los sistemas antiguos o que no tienen soporte para SME, AMD tiene un modo transparente que hace que todos los accesos a memorias sean cifrados y que puede activarse a través de la BIOS del sistema.

Este tipo de funcionalidad es útil en sistemas de virtualización, donde se quiere que las máquinas virtuales estén lo más aisladas posibles, y llegado el caso, se pueda parar ciertos ataques. Sin embargo, en un host donde se ejecutan varias máquinas virtuales bajo el control de un hipervisor, nada puede hacer que el administrador del hipervisor use sus privilegios para leer la RAM física de la máquina y por tanto obtener la información de las máquinas virtuales

Para esto AMD ha diseñado el sistema SEV: La idea es que las máquinas virtuales que corren bajo el hipervisor puedan verificar criptográficamente que están ejecutándose en un chip de AMD con estas funcionalidad y configurar el cifrado de memoria por ellas mismas,sin intervención del hipervisor, el cual no tiene acceso a ninguna de las claves de cifrado que usan las máquinas invitadas. Con este mecanismo se evita que un administrador poco honesto pueda aprovechar los privilegios del hipervisor para leer la memoria de las máquinas invitadas. Esto está implementado como una extensión a la arquitectura AMD-V

openssl: Codificaciones DER y PEM

A la hora de trabajar con openssl, podemos usar dos formatos para almacenar la información de las claves que generemos. El primero de ellos se conoce como PEM - derivado de las propuestas Privacy Enhanced Email -, un formato que codifica la información binaria en base64 - cuyo alfabeto de símbolos son todos caracteres ASCII imprimibles -. El segundo se conoce como DER, y no es más que una manera de codificar en binario estructuras expresadas a través de la notación ASN.1 - donde andarán mis apuntes de redes II ... -

La codificación PEM no es más que la información codificada en DER, transformada en base64 y con dos líneas que marcan el comienzo y el final de dichos datos en base64. Por ejemplo, un fichero con los parámetros para generar una clave DSA comienzan por -----BEGIN DSA PARAMETERS-----, en medio van las líneas codificadas en base64 y termina con -----END DSA PARAMETERS-----

A la hora de generar claves, se puede especificar el formato que se va a usar para almacenar la misma. Por defecto se usa PEM, pero puede controlarse el formato de salida y de entrada con ayuda de los parámetros -outform fmt e -inform fmt, pudiéndose respectivamente, donde fmt es PER o DER en función de la codificación que se desee usar.

Por ejemplo, si se quiere convertir una clave DSA en formato PEM a formato DER se utilizaría la orden:

openssl dsa -inform PEM -in private.pem -outform DER -out private.der

Curiosamente, aunque se puede generar los parámetros de las claves en formato DER o PEM, ni genrsa ni gendsa admiten éstos en formato DER, al menos en la versión que viene por defecto en MacOS X 10.7 "Lion". Mucho más interesante es ver como realizar estas operaciones a través de programación. Espero tener tiempo para escribir un par de entradas que sirvan de guía para programar con OpenSSL.

---

Technorati Tags: openssl, criptografía,cifrado

Notas rápidas sobre openssl y generación de claves para firmado

Estos dos últimos días he estado utilizando la herramienta de línea de comandos que tiene el toolkit de openssl para realizar varias tareas de firmado y generación de claves en un entorno de criptografía asimétrica, también conocida como criptografía de clave pública.

Quería probar la facilidad con la que se pueden generar claves para firmado y cifrado con el toolkit. Lo primero que hay que tener claro es que tipo de algoritmos de clave pública se quiere utilizar. En función de la versión del toolkit que se tenga instalada y las opciones que se hayan elegido a la hora de compilar el mismo, se dispondrán de algoritmos basados en curvas elípticas, DSA (Digital Signature Algorithm), extandar FIPS 186-3 , RSA ( Ron Rivest, Adi Shamir and Leonard Adleman) o claves para el intercambio usando el algoritmo de Diffie–Hellman. Lo primero que hay que hacer es elegir el algoritmo que se desea usar . Cada uno de los algoritmos tiene sus particularidades, para quien tenga curiosidad un buen libro que habla del tema es el Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition de Bruce Schneier.

Generación de claves

La secuencia de órdenes para generar un par de claves públicas y privadas para firmado es:

• Generar los parámetros para las claves en función del algoritmo que se desee usar (con la excepción de RSA)
• Generar la clave a partir de los parámetros del punto anterior y guardarlo en el formato que se desee.
• Extraer la información de la clave pública que se usa para las verificaciones.
• Realizar las correspondientes operaciones que se desee.

Si se desea realizar los pasos anteriores para una clava de tipo DSA, las órdenes que habría que introducir serían:

openssl dsaparam -outform PEM -out dsa.params.pem 4096
openssl gendsa -out private.pem dsa.params.pem
openssl dsa -in private.pem -outform PEM -out public.pem -pubout

Estas tres órdenes realizan la siguientes funciones

• Se genera un fichero de parámetros para poder generar una clave de tipo DSA de 4096 bits de longitud. Este fichero de parámetros se va almacenar en formato PEM (-outform PEM) con el nombre dsa.params (-out dsa.params). Con el formato elegido, el fichero dsa.params es un archivo de texto que puede verse en un editor fácilmente.
• Generamos la clave privada y pública DSA que se va a almacenar en el fichero private.pem (-out private.pem) a partir de la información que hay en dsa.params.pem. Decir que el fichero resultante, private.pem puede estar protegido cifrado usando el algoritmo DES (-des), tripe DES (-3des) o IDEA (-idea) o AES (-aes128,-aes192 o -aes256). Sino se especifica ninguno, no se cifrará. El fichero de parámetros debe de tener codificación PEM para que funcione correctamente esta orden.
• Se obtiene la clave pública (-pubout) desde el fichero que contiene ambas (-in private.pem), para almacenarla en formato PEM (-outform PEM) en el fichero public.pem (-out public.pem).

Firmado de un fichero

A la hora de firmar ficheros, se utiliza las opciones de dgst. Una particularidad es que con claves DSA, hay que usar el message digest dss1, lo que implica usar la opción -dss1. Para firmar es necesario la clave privada.

openssl dgst -dss1 -sign private.pem -out file.sign file

En este caso openssl generará una firma del fichero file, con el message digest dss1 (-dss1) usando la clave privada que está en private.pem (-sign private.pem) cuyo resultado almacenará en el fichero file.sign (-out file.sign)

Verificación de una firma

A la hora de verificar una firma se utiliza la clave pública que es pareja de la clave privada que se utilizó para firmar. Al igual que en el caso anterior, al estar usando claves DSA el message digest que hay que usar obligatoriamente es dss1

openssl dgst -dss1 -verify public.pem -signature file.sign file

Verificamos el fichero file cuya firma está contenida en el fichero file.sign (-signature file.sign) con la clave pública que está en public.pem (-verify public.pem), usando el message digest dss1 (-dss1). Decir que en este caso la opción -verify indica tanto el fichero de clave pública como que se va a proceder a realizar una verificación usando la misma.

Notas

Se que he dejado muchas cosas en el tintero, por ejemplo la necesidad de tener una fuente de entropía que se utiliza para calcular números aleatorios o la posibilidad de utilizar diversos motores para realizar las operaciones, que permitan descargar el procesador de las tareas de cálculo. He pasado de puntillas por los formatos de codificación que se pueden usar y no he hablado de como cifrar un fichero usando (se puede ver la página de manual de enc)

---

Technorati Tags: openssl,criptografía,cifrado

Playstation 3 y cifrado de disco duro

Una característica curiosa de la Playsation 3 es que cifra el contenido del disco duro interno que lleva con una clave única para cada consola. Por tanto, no se puede coger el disco de una consola y pasarla a otra. Esto hace que los únicos mecanismos oficialmente soportados por Sony que se existen para poder realizar el transvase de dicha información sea a través de los mecanismos de copia de seguridad o la transferencia de información a través de la ethernet. Hay ciertas limitaciones en el sistema de copias, sobre todo en lo referente a contenido protegido por alguna forma de gestión digital de derechos que no pueden transferirse entre máquinas a través de las copias de seguridad.

Por curiosidad, he buscando un poco de información sobre el tipo de cifrado que utiliza la consola en el disco duro De la web PS3 Developer wiki se puede sacar alguna información interesante:

• El algoritmo de cifrado que utiliza es XTS-AES-128, similar al usado en varios sistemas.
• El cifrado se realiza a través de un módulo hardware llamado ENCDEC. Entiendo que no hay ningún comando ATA que establece una password a nivel de protocolo ATA en el disco duro.
• Por lo que he leído en varios foros, hay gente que ha logrado volcar las claves usadas en este proceso de cifrado para de esta manera poder acceder al contenido de los archivos del disco duro de una PS3.
• Si se es capaz de volcar las claves, se puede usar Linux para montar el disco
  de la PS3 en un PC
• Más detalles de este proceso pueden verse en ENCDEC Device Reverse Engineering

---

Technorati Tags: ps3,cifrado