Servicio de Cloud Key Vault de Google

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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 no se puedan recuperar de forma permanente después de demasiados intentos fallidos de proporcionar el factor de conocimiento correcto.

Autor: Shabsi Walfish
Fecha de la versión: 06/03/2018

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

Descripción general

Tradicionalmente, la encriptación (que se usa para garantizar la privacidad de los datos) requiere el uso de secretos que tengan una entropía alta desde la perspectiva del atacante. Se requiere una alta entropía porque el esquema de encriptación debe resistir los ataques de fuerza bruta que exploran el espacio de todos los secretos probables hasta que se encuentra 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 estar entre 70 y 80 bits. Lamentablemente, a los seres humanos les resulta muy difícil memorizar y recordar de forma confiable contraseñas o secretos con esa cantidad de entropía¹, en especial si rara vez se usan (pero el uso frecuente de una contraseña de alta entropía es difícil y tedioso). Esto nos deja con 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 es muy probable que el usuario recuerde? Por varios motivos, este problema es tan difícil de resolver que los servicios de almacenamiento en la nube suelen encriptar los datos solo con secretos que administra el propio proveedor de almacenamiento en la nube, en lugar de depender del usuario para que recuerde su propio secreto.

Un enfoque para cerrar la brecha entre los requisitos de los secretos criptográficos y los secretos fáciles de recordar 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 fácil de recordar por humanos de baja entropía. El servicio de CKV liberará la clave de recuperación solo a una parte que demuestre conocer el secreto mnemotécnico correcto. El servicio de CKV puede frustrar los ataques de fuerza bruta contra el secreto mnemotécnico humano, ya que aplicará un límite absoluto a la cantidad de intentos fallidos para demostrar el conocimiento del secreto. La clave de recuperación en sí es una clave simétrica criptográfica estándar, adecuada para usar con un esquema de encriptación (autenticado) que puede encriptar fácilmente un gran volumen de datos (como una copia de seguridad en disco) que se puede almacenar de forma segura en cualquier lugar. Estos datos encriptados son inútiles para cualquier persona que no pueda obtener la clave de recuperación.

En este documento, se describe nuestro enfoque para crear un servicio de Cloud Key Vault con módulos de hardware confiables (THM). Nuestra primera implementación del servicio de CKV está diseñada para proteger las claves de recuperación con el factor de conocimiento de la pantalla de bloqueo (LSKF) del usuario: el PIN secreto, la contraseña o el patrón de deslizamiento que se usa para desbloquear los smartphones. Los seres humanos pueden recordar de forma confiable su LSKF. Al mismo tiempo, esos secretos de LSKF suelen tener la entropía justa para resistir a un atacante que tiene una cantidad muy limitada de intentos, lo que los hace adecuados para el servicio de CKV.

La primera aplicación de nuestro servicio de Cloud Key Vault será habilitar las copias de seguridad de Android encriptadas del cliente. Anteriormente, los archivos encriptados de forma local en el dispositivo Android usaban una clave protegida con la LSKF del usuario, pero la LSKF no protegía las copias de seguridad de esos archivos almacenados (y encriptados) en la nube. Por primera vez, Cloud Key Vault habilita la protección de la pantalla de bloqueo para las copias de seguridad de Android almacenadas en la nube. Esto significa que los servidores de Google no pueden acceder al contenido de las copias de seguridad encriptadas ni restablecerlas. Solo un dispositivo con la LSKF del usuario puede desencriptarlas.

Conceptos principales

Inicialmente, la única plataforma de cliente compatible con el servicio de Cloud Key Vault es el sistema operativo Android 9 Pie. Cuando nos referimos al cliente en este documento, nos referimos a un dispositivo que ejecuta el sistema operativo Android 9 Pie con Servicios de Google Play. Nuestra implementación del servidor se ejecuta en servidores de Google designados especialmente que tienen un chip Titan² adicional instalado. El chip Titan diseñado por Google funciona como el componente de hardware de nuestro Módulo de Hardware de Confianza, y lo aprovisionamos de forma especial con un bootloader y un firmware personalizados que implementan nuestros protocolos y mecanismos de aplicación de seguridad (como se describe aquí). Usamos técnicas de certificación de hardware para obtener garantías de que nuestro protocolo realmente se ejecuta en el hardware de Titan.

El servicio de CKV debe escalar para controlar el tráfico de miles de millones³ de dispositivos Android, sin perder una cantidad significativa de datos del usuario debido a fallas de hardware (p.ej., chips quemados) o interrupciones prolongadas debido al mantenimiento del centro de datos. Por este motivo, los servidores con los chips Titan están organizados en cohortes, en las que cada cohorte consta de varios THM independientes que contienen una copia del mismo material de claves. 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 dividirán en varias cohortes diferentes, de modo que podamos ajustar la capacidad del servicio simplemente agregando 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 la pantalla de bloqueo (LSKF): Es un secreto que una persona puede recordar, como un PIN corto, un patrón de deslizamiento sobre una cuadrícula de puntos de 3 × 3 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: 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 referirnos a las APIs de Android 9 Pie o versiones posteriores, y no se refiere a versiones anteriores.

Servicios de Google Play: Es un conjunto de servicios y apps que se ejecutan en el dispositivo del usuario final y que le permiten funcionar con el sistema de cuentas de Google y las APIs de servidores personalizados.

Agente de recuperación: Es una aplicación del sistema que se ejecuta como parte de los Servicios de Google Play en el espacio de usuario en un dispositivo Android 9 Pie (o similar). El agente de recuperación es responsable de ejecutar el lado del cliente de los diversos protocolos y de interactuar con el sistema operativo Android según sea necesario para crear cualquier mensaje de protocolo que involucre a la 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 de la LSKF que el usuario afirma conocer. Por lo general, se le pedirá al usuario que ingrese la 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 protege el servicio de Cloud Key Vault y se usa para encriptar (y autenticar) datos en el dispositivo cliente. Una vez que la clave de recuperación se haya colocado en un Vault (consulta a continuación), la copia local se puede borrar cuando el cliente termine de usarla para encriptar datos.

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

Cohorte: Es un conjunto de servidores o THM de Vault que pueden funcionar como réplicas redundantes entre sí.

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

Módulo de hardware de confianza (THM): Es un módulo de seguridad dedicado (microcontrolador) diseñado para proporcionar un entorno de procesamiento mínimo y confiable. Como mínimo, el elemento seguro debe poder generar o almacenar claves secretas y mantener un estado evolutivo no volátil (para evitar ataques que impliquen restablecimientos a un estado anterior).

Vault: Es una entrada en particular de 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 en el archivo, cada uno de los cuales corresponde a un dispositivo o LSKF diferente. Solo el THM de un servidor de Vault puede examinar o extraer el contenido de un Vault.

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

Diseño de protocolo

El protocolo de CKV consta de varias fases:

Inicialización

Para 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 modo que requiere la participación de varios empleados para firmar con ella. La clave pública de esta raíz de confianza está integrada en el SO Android y solo se puede cambiar mediante una actualización del SO.

Google también publica periódicamente 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 para que sea posible evitar las reversiones. El agente de recuperación recuperará la lista publicada más reciente de las claves públicas de la cohorte y la proporcionará al framework. Luego, el Framework verifica la certificación y selecciona de forma aleatoria una clave pública de cohorte de la lista que se usará en la fase de creación de la bóveda.

Creación del Vault

Después de ayudar al Framework a completar la inicialización recuperando la lista de llaves públicas de cohorte, el agente de recuperación le solicitará al Framework que cree una nueva bóveda. Cada vez que el usuario ingrese la LSKF, el Framework generará una clave de recuperación nueva y la encriptará primero con una clave derivada de un hash de la LSKF y, luego, con la clave pública de cohorte que el Framework seleccione durante la inicialización. El blob encriptado resultante es la bóveda que el Framework le 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 en el dispositivo nuevo necesite acceder a la clave de recuperación que se almacena en una bóveda en particular, primero le pedirá al usuario que ingrese la LSKF del dispositivo original que creó la bóveda. Luego, el Agente de recuperación le pedirá al Framework que cree un Reclamo de recuperación con ese LSKF. El framework generará una clave de solicitante nueva y la encriptará, junto con el hash de la LSKF reclamada, con la misma clave pública de cohorte con la que se encriptó originalmente la bóveda. El BLOB encriptado resultante se denomina Recovery Claim, y el framework lo pasa al agente de recuperación, que luego lo presenta al servicio de CKV.

El CKV enruta el Recovery Claim (y su Vault correspondiente) a los servidores de Vault que forman parte de la cohorte correcta. Luego, el THM de los servidores de Vault desencripta el Recovery Claim y, con el hash de LSKF reclamado, intenta extraer la clave de recuperación de la Vault original (para derivar la clave de encriptación interna). Si el hash de LSKF original y el hash de LSKF reclamado coinciden, el THM extraerá la clave de recuperación de la bóveda y la volverá a encriptar con la clave del solicitante que estaba en el 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 cualquier Reclamación de recuperación posterior para esta Bóveda.

Por último, si todo salió bien, la clave de recuperación (que ahora está encriptada con la clave del solicitante) se vuelve a enviar desde el servidor de Vault hasta el Framework. El Framework usa su copia de la clave del solicitante para desencriptar la clave de recuperación, y el protocolo ya está completo.

Medidas de seguridad

El objetivo del sistema de Cloud Key Vault es proporcionar una "defensa en profundidad", ya que incluye protecciones de seguridad en varios niveles de nuestra pila. Para darte una idea de cómo funcionan estas protecciones, comenzaremos por describir el 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 factor de conocimiento de la pantalla de bloqueo (LSKF) se suele almacenar y proteger 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 la manipulación para almacenar la LSKF en reposo y aplicar límites de frecuencia basados en hardware en la validación de la LSKF. Las nuevas APIs de Framework que se presentan para permitir 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 un módulo de seguridad de hardware para proteger el almacenamiento de la LSKF.

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

Protección de las API del marco de trabajo

Las nuevas APIs de Framework que se agregaron para admitir el servicio de CKV están marcadas como @SystemApi y requieren permisos especiales, lo que garantiza que solo estén disponibles para las apps del sistema aprobadas por el OEM, como los Servicios de Google Play. Esto quita en gran medida cualquier superficie de ataque directa que podría exponerse a las apps que el usuario instala en el dispositivo.

Las APIs de Framework también garantizan que las bóvedas solo se creen para las claves públicas de cohorte que hayan sido certificadas por una raíz de confianza. El OEM integra la raíz de confianza en el Framework cuando se envía y no se puede cambiar sin una actualización del SO. Esto proporciona confianza en que la LSKF solo se usa para crear bóvedas que aplicarán correctamente las protecciones de fuerza bruta basadas en hardware. Si nos basamos en los THM del servicio de Cloud Key Vault para la protección contra ataques de fuerza bruta de la LSKF, podemos lograr una seguridad comparable al uso de hardware seguro en el dispositivo para lo mismo (como lo hacen los dispositivos Google Pixel 2).

Dado que no suponemos que la LSKF se almacenará en ningún lugar del dispositivo fuera del hardware seguro, solo se puede crear una nueva bóveda inmediatamente después de desbloquear el dispositivo. En el momento en que el usuario ingresa el LSKF para desbloquear el dispositivo, el LSKF se pone a disposición del Framework brevemente en la RAM. Ese es el momento en el que lo usa la nueva API destinada a crear el Vault. No es posible crear una nueva bóveda protegida por LSKF mientras el dispositivo está bloqueado, ya que la LSKF no está disponible.

Protección del agente de recuperación

La protección de seguridad principal que proporcionamos en el Agente de recuperación es que el protocolo está diseñado para evitar que el Agente de recuperación vea la LSKF del dispositivo actual ni ninguna clave de recuperación. Solo el Framework debería ver esos elementos del cliente, lo que dificulta mucho el uso 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 el paso 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 de la bóveda, cuando el usuario debe ingresar el LSKF del dispositivo anterior. La IU que recopila el LSKF reclamado para el dispositivo anterior se implementa en el agente de recuperación⁴. Sin embargo, la implementación del agente de recuperación “olvida” el LSKF reclamado en cuanto el Framework se hace cargo de la construcción del reclamo de recuperación.

Características de seguridad del protocolo

Si bien un análisis completo del protocolo está fuera del alcance de este documento, queremos destacar algunas de las protecciones integradas en el protocolo. En particular, el protocolo solo usa el hash de la LSKF en todo momento. Esto significa que, si la LSKF tiene una entropía alta (p.ej., si es una contraseña de alta entropía), almacenar la bóveda 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 hash salado “duro de memoria” de la LSKF como parte del protocolo. También vinculamos criptográficamente la bóveda a un identificador del dispositivo que la creó y vinculamos el reclamo de recuperación a un nonce que se usa como desafío durante el protocolo de apertura de la bóveda para garantizar que el reclamo de recuperación sea reciente.

Dado que la clave de recuperación se genera de forma nueva en cada creación de Vault, implementamos la rotación de claves reemplazando una entrada de Vault existente por una Vault recién creada. La dirección del contador de intentos fallidos que usa la bóveda se selecciona durante la creación de la bóveda, y el Framework se asegura de que la dirección del contador que se usa para las bóvedas posteriores no cambie, a menos que se haya cambiado la LSKF o haya una nueva lista certificada de claves públicas de 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 para la 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 de servidor ordinario y firmware que se ejecuta en hardware especializado (el 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 de confianza (THM) que se compilan con los chips Titan diseñados a medida de Google. Los chips ejecutan un 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 de filtraciones fuera de los chips Titan de la cohorte. También pueden realizar la operación de apertura de Vault y mantener un contador de intentos fallidos por Vault que aumenta de forma estricta (en el que el estado almacenado dentro del chip Titan respalda el contador). En una versión futura de este documento, se proporcionará una descripción más detallada del protocolo que ejecuta el firmware del chip CKV Titan.

Dado que la seguridad del servidor se deriva de la lógica del firmware en los chips Titan, debemos asegurarnos de que la lógica no cambie de una manera que permita que los chips filtren secretos o ignoren los límites del contador. Para lograr este objetivo, también alteramos el cargador de arranque de Titan para garantizar que los datos almacenados del chip (como la clave privada de la cohorte) se borren 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 una pérdida de datos. La actualización del firmware es funcionalmente equivalente a destruir el hardware existente y reemplazarlo por chips nuevos. En 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 cohorte certificadas y migrar gradualmente a todos los usuarios a la lista nueva. Para mitigar este riesgo, intentamos mantener la base de código del firmware bastante minimalista y auditarla cuidadosamente en busca de posibles problemas de seguridad.

Protecciones de software

Además de los límites de fallas duras por Vault que imponen los THM, el servicio de CKV también implementa un límite de frecuencia basado en software. El límite de frecuencia está diseñado para evitar que un pirata informático 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. Al igual que las demoras que impone el dispositivo del usuario después de demasiados intentos fallidos de desbloquear la pantalla, el servicio de CKV aplicará una demora creciente después de cada solicitud de apertura de la bóveda fallida posterior.

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

Especificación detallada de protocolo

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

Notas