Servicio de Cloud Key Vault de Google

Describimos un servicio en la nube que usa hardware seguro para almacenar claves criptográficas, de modo que el acceso a ellas está protegido por un factor de conocimiento de baja entropía (p.ej., un PIN de pantalla de bloqueo). El hardware seguro está diseñado para evitar ataques de fuerza bruta, ya que hace que las claves criptográficas almacenadas sean irrecuperables de forma permanente después de demasiados intentos fallidos para proporcionar el factor de conocimiento correcto.

Autor: Shabsi Walfish
Fecha de la versión: 6 de marzo de 2018

Nota: Este documento aún se encuentra en desarrollo y los detalles de la implementación aún se están definiendo. A medida que el sistema se estabilice y se pueda producir más documentación, actualizaremos este informe con información más detallada (en particular, junto con versiones de código abierto relevantes).

Descripción general

Tradicionalmente, la encriptación (que se usa para garantizar la privacidad de los datos) requiere secretos que tengan alta entropía desde la perspectiva del atacante. Se requiere una entropía alta porque el esquema de encriptación debe resistir ataques de fuerza bruta que exploren el espacio de todos los secretos probables hasta que se encuentre el correcto. Dada la disponibilidad actual de potencia de procesamiento, un requisito de entropía mínimo razonable para los secretos criptográficos podría ser de entre 70 y 80 bits. Lamentablemente, a los seres humanos les resulta muy difícil memorizar y recordar de manera confiable contraseñas u otros secretos con esa cantidad de entropía1, en especial si se usan con poca frecuencia (pero el uso frecuente de contraseñas con alta entropía es difícil y tedioso). Esto nos genera un problema desafiante: ¿cómo podemos proteger los datos privados con la tecnología de encriptación si queremos que el secreto sea un “factor de conocimiento” que el usuario pueda recordar? Por diversas razones, este problema es tan difícil de resolver que los servicios de Cloud Storage suelen encriptar datos solo con secretos administrados por el proveedor de almacenamiento en la nube, en lugar de depender de que el usuario recuerde su propio secreto.

Un enfoque para cerrar la brecha entre los requisitos de los secretos criptográficos y los secretos memorables por humanos es usar un servicio de Cloud Key Vault (CKV) para almacenar una "clave de recuperación" de alta entropía, protegida por un secreto de baja entropía que una persona pueda recordar. El servicio de CKV liberará la clave de recuperación solo para una parte que demuestre que tiene conocimiento del secreto correcto que una persona pueda memorizar. El servicio CKV puede frustrar los ataques de fuerza bruta contra los secretos que pueda memorizar una persona, lo que aplicará un límite absoluto en la cantidad de intentos fallidos para probar que se conoce el secreto. La clave de recuperación en sí es una clave criptográfica simétrica estándar adecuada para su uso con un esquema de encriptación (autenticado) que puede encriptar con facilidad un gran volumen de datos (como una copia de seguridad de un disco) que se pueden almacenar de manera segura en cualquier lugar. Estos datos encriptados son inútiles para cualquiera que no pueda obtener la clave de recuperación.

En este informe, se describe nuestro enfoque para la construcción de un servicio de Cloud Key Vault con módulos de hardware confiables (THM). Nuestra primera implementación del servicio de CKV se diseñó para proteger las claves de recuperación con el factor de conocimiento de pantalla de bloqueo (LSKF), que es el PIN secreto, la contraseña o el patrón de deslizamiento que se usa para desbloquear los smartphones. Los seres humanos pueden recordar con confianza su LSKF. Al mismo tiempo, esos secretos del LSKF suelen tener la entropía justa para resistirse a un atacante que tiene una cantidad muy limitada de intentos, lo que los convierte en buenos candidatos para el servicio de CKV.

La primera aplicación de nuestro servicio Cloud Key Vault consistirá en habilitar copias de seguridad de Android con encriptación del cliente. Antes, los archivos encriptados localmente en el dispositivo Android usaban una clave protegida con el LSKF del usuario, pero las copias de seguridad de esos archivos almacenados (y encriptados) en la nube no estaban protegidas por el LSKF. Por primera vez, Cloud Key Vault también habilita la protección de pantalla de bloqueo para las copias de seguridad de Android almacenadas en la nube. Esto significa que los servidores de Google no tienen la capacidad de acceder al contenido de las copias de seguridad encriptadas ni restablecerlo. Solo un dispositivo con el LSKF del usuario puede desencriptar las copias de seguridad.

Conceptos principales

Inicialmente, la única plataforma cliente compatible con el servicio de Cloud Key Vault es el sistema operativo Android 9 Pie. Cuando nos referimos al cliente en este informe, nos referimos a un dispositivo que ejecuta el sistema operativo Android 9 Pie con los Servicios de Google Play. Nuestra implementación del servidor se ejecuta en servidores de Google específicamente designados que tienen instalado un chip Titan2 adicional. El chip Titan diseñado por Google sirve como componente de hardware en nuestro módulo de hardware confiable, y lo aprovisionamos de manera especial con un bootloader y un firmware personalizados que implementan nuestros protocolos y mecanismos de cumplimiento de la seguridad (como se describe en este documento). Usamos técnicas de certificación de hardware para asegurarnos de que nuestro protocolo realmente se ejecute en el hardware Titan.

El servicio de CKV debe escalar para manejar el tráfico de miles de millones3 de dispositivos Android sin perder una cantidad significativa de datos del usuario debido a fallas de hardware (p.ej., chips quemados) ni experimentar interrupciones prolongadas debido al mantenimiento del centro de datos. Por esta razón, los servidores que tienen los chips Titan se organizan en cohortes, y cada cohorte consta de varios THM independientes, cada uno de los cuales contiene una copia del mismo material de la clave. Una cohorte determinada se distribuirá en centros de datos físicamente dispares en diferentes zonas de mantenimiento, para garantizar que el sistema pueda cumplir con sus objetivos de disponibilidad y confiabilidad. Para la escalabilidad, los clientes se fragmentarán en varias cohortes diferentes, de modo que podamos ajustar la capacidad del servicio con solo agregar más servidores para aumentar la cantidad de cohortes disponibles.

Ahora estamos listos para enumerar los componentes principales de la arquitectura del servicio de Cloud Key Vault.

Componentes de arquitectura y glosario

Factor de conocimiento de pantalla de bloqueo (LSKF): Un secreto que puede recordar una persona, como un PIN corto, un patrón de deslizamiento sobre una cuadrícula de 3 x 3 puntos o una contraseña. Este secreto se usa para proteger la capacidad de desbloquear el dispositivo de forma local y se considera un factor de autenticación principal (o "fuerte") para el bloqueo de pantalla del dispositivo local del usuario.

Cliente: Es un dispositivo de usuario final que ejecuta el sistema operativo Android 9 Pie y los Servicios de Google Play, o un software compatible equivalente.

Framework de Android: usamos este término genérico (o solo el framework) para hacer referencia a las APIs en Android 9 Pie o versiones posteriores, y no pretende hacer referencia a versiones anteriores.

Servicios de Google Play: Es un conjunto de servicios y apps que se ejecuta en el dispositivo del usuario final, lo que le permite funcionar con el sistema de cuentas de Google y las APIs personalizadas del servidor.

Agente de recuperación: Es una aplicación del sistema que se ejecuta como parte de los Servicios de Google Play en el espacio del usuario en un dispositivo con Android 9 Pie (o similar). El agente de recuperación es responsable de ejecutar el lado del cliente de diversos protocolos y de interactuar con el sistema operativo Android según sea necesario para crear cualquier mensaje de protocolo que involucre al LSKF.

Reclamación de recuperación: cuando el usuario desea recuperar la clave de recuperación, debe crear una reclamación de recuperación, que tiene una copia encriptada del LSKF que el usuario afirma conocer. Por lo general, se le pedirá al usuario que ingrese el LSKF de su dispositivo anterior en un dispositivo nuevo que intente acceder a la clave de recuperación del anterior.

Clave de recuperación: es una clave secreta criptográfica que está protegida por el servicio de Cloud Key Vault y que se usa para encriptar (y autenticar) datos en el dispositivo cliente. Una vez que la clave de recuperación se coloca en un Vault (consulta a continuación), la copia local se puede borrar en cuanto el cliente termina de usarla para encriptar datos.

Servicio Cloud Key Vault (CKV): Un servicio de Internet que permite que los dispositivos cliente almacenen claves criptográficas protegidas por un LSKF que una persona puede recordar.

Cohorte: Es una colección de servidores o THM de Vault que pueden funcionar como réplicas redundantes entre sí.

Clave pública de cohorte: Es la clave pública de un par de claves generada por una cohorte de THM específica. La clave privada correspondiente solo está disponible dentro de los THM que estaban en la cohorte en el momento de la generación de la clave.

Módulo de hardware confiable (THM): Es un módulo de seguridad dedicado (microcontrolador) diseñado para proporcionar un entorno de computación mínimo y confiable. Como mínimo, el elemento seguro debe ser capaz de generar o almacenar claves secretas y mantener un estado en evolución no volátil (para poder evitar ataques que involucren el restablecimiento a un estado anterior).

Vault: Es una entrada particular en la base de datos del servicio de CKV que contiene la clave de recuperación protegida por LSKF de un solo dispositivo. Un usuario final puede tener varios Vaults registrados, cada uno correspondiente a un dispositivo o LSKF diferente. Solo el THM de un servidor de Vault puede examinar o extraer el contenido de un almacén.

Servidor Vault: Es una máquina de uso general que funciona en un centro de datos de Google que se actualizó de manera especial para agregar un módulo de hardware confiable (THM).

Diseño de protocolo

El protocolo de CKV consta de varias fases:

Inicialización

A fin de inicializar el sistema, Google proporcionará una clave pública para una “raíz de confianza” que el framework usará para verificar las certificaciones de hardware de Google. La clave de firma de esta raíz de confianza se almacena sin conexión y se protege cuidadosamente de manera que requiera la participación de varios empleados para firmar con ella. La clave pública de esta raíz de confianza se integra en el SO Android y solo se puede cambiar mediante una actualización del SO.

Google también publica de forma periódica una lista de claves públicas para cada cohorte de THM, junto con una certificación en la lista. La certificación de la lista usa una firma que se vincula a la raíz de confianza. Cada actualización de la lista publicada también contiene un número de secuencia, por lo que es posible evitar reversiones. El agente de recuperación recuperará la lista publicada más reciente de claves públicas de la cohorte y la proporcionará al marco de trabajo. Luego, el framework verifica la certificación y selecciona de forma aleatoria una clave pública de la cohorte de la lista que se usará en la fase de creación del Vault.

Creación del Vault

Después de ayudar al marco de trabajo a completar la inicialización mediante la recuperación de la lista de claves públicas de la cohorte, el agente de recuperación solicitará al marco de trabajo que cree un Vault nuevo. Cada vez que el usuario ingrese el LSKF, el marco de trabajo generará una clave de recuperación nueva y la encriptará primero con una clave derivada de un hash del LSKF y, luego, con la clave pública de la cohorte que seleccionó el framework durante la inicialización. El BLOB encriptado resultante es el Vault que el framework pasa al agente de recuperación, que luego lo sube al servicio de CKV de Google.

Apertura del Vault

Cuando el agente de recuperación del dispositivo nuevo necesita obtener acceso a la clave de recuperación que está almacenada en un Vault determinado, primero le pedirá al usuario que ingrese el LSKF del dispositivo original que creó el Vault. El agente de recuperación le pedirá al marco de trabajo que cree una reclamación de recuperación con ese LSKF. El marco de trabajo generará una clave del solicitante nueva y la encriptará junto con el hash del LSKF reclamado, con la misma clave pública de la cohorte con la que se encriptó Vault originalmente. El BLOB encriptado resultante se denomina reclamación de recuperación, y el framework la pasa al agente de recuperación, que luego la presenta al servicio de CKV.

El CKV enruta la reclamación de recuperación (y su Vault correspondiente) a los servidores de Vault que forman parte de la cohorte correcta. El THM en los servidores de Vault luego desencripta la reclamación de recuperación y, luego, intenta extraer la clave de recuperación del Vault original mediante el hash del LSKF reclamado (para derivar la clave de encriptación interna). Si el hash del LSKF original y el hash del LSKF reclamado coinciden, el THM extraerá la clave de recuperación del Vault y la volverá a encriptar con la clave del solicitante que estaba en la reclamación de recuperación. Si no coinciden, el THM transmitirá un contador de intento fallido. Una vez que el contador de intentos fallidos alcance su límite, el THM se negará a procesar las reclamaciones de recuperación posteriores para este Vault.

Por último, si todo sale bien, la clave de recuperación que se volvió a encriptar (que ahora está encriptada en la clave del solicitante) se envía desde el servidor de Vault hasta el marco de trabajo. El marco de trabajo usa su copia de la clave del solicitante para desencriptar la clave de recuperación, y el protocolo ahora está completo.

Medidas de seguridad

El sistema Cloud Key Vault tiene como objetivo proporcionar una “defensa en profundidad” mediante la inclusión de protecciones de seguridad en varios niveles de nuestra pila. Para dar una idea de cómo funcionan estas protecciones, comenzaremos con la descripción del cliente y avanzaremos por la pila hasta el servicio de Cloud Key Vault.

Seguridad del cliente

Según el OEM y el dispositivo en particular, el Lock Screen Knowledge Factor (LSKF) normalmente se almacena y protege en el dispositivo con una variedad de métodos que varían según el OEM. Por ejemplo, los dispositivos Pixel 2 de Google usan un módulo de seguridad de hardware resistente a alteraciones para almacenar el LSKF en reposo y aplicar límites de frecuencia basados en hardware en la validación del LSKF. Las nuevas APIs de framework que se presentan para habilitar el uso de Cloud Key Vault están diseñadas para preservar las garantías de seguridad existentes en la mayor medida posible, incluso cuando el dispositivo usa ese módulo de seguridad de hardware para proteger el almacenamiento del LSKF.

En esta sección, nos enfocaremos específicamente en los problemas de seguridad y las protecciones relevantes que afectan a la nueva función de Cloud Key Vault, en lugar de intentar proporcionar un panorama completo de todos los mecanismos de seguridad asociados con el LSKF.

Protección de las API del marco de trabajo

Las nuevas APIs de framework que se agregaron para admitir el servicio de CKV se marcan como @SystemApi y requieren permisos especiales, que garantizan que solo estén disponibles para apps del sistema aprobadas por el OEM, como los Servicios de Google Play. Esto quita en gran medida cualquier superficie de ataque directo que pueda exponerse a las apps que el usuario instala en el dispositivo.

Las APIs del framework también garantizan que los Vaults solo se creen para las claves públicas de la cohorte que una raíz de confianza haya atestado. El OEM prepara la raíz de confianza en el marco de trabajo cuando se envía y no puede cambiarse sin una actualización del SO. Esto garantiza la confianza de que el LSKF solo se usa para crear Vaults que aplicarán adecuadamente las protecciones de fuerza bruta basadas en hardware. Si nos apoyamos en los THM del servicio de Cloud Key Vault para la protección por fuerza bruta del LSKF, podemos lograr una seguridad comparable con el uso de hardware seguro en el dispositivo para lo mismo (como lo hacen los dispositivos Google Pixel 2).

Dado que no suponemos que el LSKF se almacenará en ningún lugar del dispositivo fuera del hardware seguro, solo se puede crear un Vault nuevo inmediatamente después del desbloqueo del dispositivo. Cuando el usuario ingresa el LSKF para desbloquear el dispositivo, se pone el LSKF por poco tiempo a disposición del framework en la RAM. Ese es el momento en el que lo usa la nueva API destinada a crear el Vault. No es posible crear un nuevo Vault protegido con el LSKF mientras el dispositivo está bloqueado, ya que el LSKF no está disponible.

Protección del agente de recuperación

La protección de seguridad principal que ofrecemos en el agente de recuperación es que el protocolo está diseñado para evitar que el agente de recuperación vea el LSKF del dispositivo actual o cualquier clave de recuperación. Solo el marco de trabajo debería ver esos elementos del lado del cliente, lo que dificulta mucho la explotación de posibles errores o vulnerabilidades de seguridad en el agente de recuperación. El agente de recuperación se usa principalmente para administrar eventos de ciclo de vida y la transferencia de datos entre la nube y el framework. La única excepción a esto ocurre durante una recuperación justo antes del protocolo de apertura del Vault, cuando el usuario debe ingresar el LSKF del dispositivo anterior: la IU que reúne el LSKF reclamado para el dispositivo anterior se implementa en el agente de recuperación.4 Sin embargo, la implementación del agente de recuperación "olvida" el LSKF reclamado en cuanto el framework asume la construcción de la reclamación de recuperación.

Características de seguridad del protocolo

Si bien no se incluye un análisis completo del protocolo en este documento, queremos destacar algunas de las protecciones integradas en el protocolo. En particular, el protocolo solo usa el hash del LSKF en todo momento. Esto significa que, si el LSKF tiene alta entropía (p.ej., si es una buena contraseña de entropía alta), almacenar el Vault es estrictamente mejor que almacenar un hash de contraseña y, en este caso, el hash de contraseña puede proporcionar una medida de seguridad independiente de la seguridad de los THM. Por este motivo, admitimos el hashing con “memoria rígida” salada del LSKF como parte del protocolo. También vinculamos de manera criptográfica el Vault a un identificador para el dispositivo que lo creó y vinculamos la reclamación de recuperación a un nonce que se usa como desafío durante el protocolo de apertura del Vault para garantizar que la reclamación de recuperación esté actualizada.

Dado que la clave de recuperación se genera de nuevo en cada creación de Vault, implementamos la rotación de claves reemplazando una entrada de Vault existente por un Vault recién creado. La dirección del contador de intentos fallidos que usa Vault se selecciona durante la creación del Vault, y el marco de trabajo garantiza que la dirección del contador que se use para los Vaults posteriores no cambiará, a menos que se haya cambiado el LSKF o que haya una nueva lista atestada de claves públicas de la cohorte. Por lo tanto, la rotación de la clave de recuperación se puede realizar sin dañar la protección contra ataques de fuerza bruta del LSKF.

Seguridad del servidor para el servicio de Cloud Key Vault

El servidor se implementa con una combinación de software que se ejecuta en hardware común de servidores y firmware que se ejecuta en hardware especializado (chip Titan). Describiremos las protecciones que se ofrecen en cada capa.

Protecciones de hardware

La protección de seguridad principal implementada en el servidor del servicio de CKV son los módulos de hardware confiables (THM) que se compilan con chips Titan de diseño personalizado de Google. Los chips ejecutan firmware que expone las APIs necesarias para implementar los protocolos de CKV. En particular, pueden generar y compartir de forma segura un par de claves con otros miembros de su cohorte, de modo que la lógica del firmware proteja la clave privada para que no se filtre fuera de los chips Titan en la cohorte. También pueden realizar la operación de apertura del Vault y mantener un contador de intentos fallidos por cada Vault que aumente estrictamente (en el que el contador está respaldado por el estado almacenado dentro del chip Titan). En una versión futura de este documento, se proporcionará una descripción más detallada del protocolo que ejecuta el firmware del chip Titan para el CKV.

Dado que la seguridad del servidor deriva de la lógica del firmware de los chips Titan, debemos asegurarnos de que esta no cambie de modo que permita que los chips filtren secretos o ignoren los límites del contador. Para lograr este objetivo, también modificamos el cargador de inicio Titan a fin de garantizar que los datos almacenados del chip (como la clave privada para la cohorte) se limpien por completo antes de que se aplique cualquier actualización. La desventaja de esta protección es que no podemos aplicar parches a los errores del firmware sin experimentar cierta pérdida de datos. Actualizar el firmware equivale a destruir el hardware existente y reemplazarlo por chips nuevos. En el caso de que se requiera un parche de firmware crítico, Google deberá producir y publicar una lista completamente nueva de claves públicas de la cohorte certificadas y migrar gradualmente todos los usuarios a la lista nueva. Para mitigar este riesgo, intentamos mantener la base de código del firmware en un nivel mínimo y auditarla cuidadosamente en busca de posibles problemas de seguridad.

Protecciones de software

Además de los límites de fallas estrictos por Vault impuestos por los THM, el servicio de CKV también implementa límites de frecuencia basados en software. El límite de frecuencia está diseñado para evitar que un pirata acceda a la cuenta de un usuario y agote rápidamente su límite de intentos de recuperación fallidos, lo que bloquea de manera efectiva el acceso del usuario real a sus claves de recuperación. De manera similar a los retrasos que impone el dispositivo del usuario después de demasiados intentos fallidos para desbloquear la pantalla, el servicio de CKV aplicará un retraso de tiempo creciente después de cada solicitud posterior de apertura del Vault fallida.

También implementamos medidas de seguridad estándar para los servicios en la nube que alojan datos del usuario, incluidos controles de acceso estrictos, supervisión y auditorías.

Especificación detallada de protocolo

La especificación detallada del protocolo todavía está en curso. Más adelante este año, se actualizará este documento para incluir esos detalles junto con la publicación del código de cliente en el Proyecto de código abierto de Android.

Notas

  1. “Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX”. 1 de agosto de 2014: https://www.usenix.org/node/184458. CompanyName
  2. "Blog de Google Cloud Platform: Titan in depth: Security in plaintext". 24 de agosto de 2017, https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html. CompanyName
  3. "Google anuncia más de 2,000 millones de dispositivos activos por mes en Android..." 17 de mayo de 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users. CompanyName
  4. Esto nos permite proporcionar IU flexibles para ingresar el LSKF de otro dispositivo (es posible que el framework del dispositivo actual no tenga una IU adecuada para ingresar el LSKF del dispositivo anterior).