Servicio de Cloud Key Vault de Google

Describimos un servicio en la nube que usa hardware seguro para almacenar claves criptográficas, de tal forma que el acceso a ellas se encuentra protegido por un factor de conocimiento de baja entropía (p. ej., un PIN en la pantalla de bloqueo). El hardware seguro está diseñado para prevenir ataques por fuerza bruta, al imposibilitar la obtención de las claves criptográficas almacenadas tras una cantidad excesiva de 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 se encuentra en proceso de creación y los detalles de implementación todavía no se han concluido. A medida que el sistema se estabilice y que se pueda producir más documentación, actualizaremos este documento con información más detallada (en particular, junto con actualizaciones de código abierto pertinentes).

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 el punto de vista del atacante. Es necesario un nivel alto de entropía, ya que el esquema de encriptación debe resistir ataques por fuerza bruta que exploren el espacio de todos los secretos probables hasta que se encuentre el correcto. Dado el poder de procesamiento con el que contamos actualmente, un requisito mínimo razonable de entropía para secretos criptográficos debería rondar los 70 u 80 bits. Lamentablemente, a los seres humanos les resulta muy difícil memorizar y recordar correctamente las contraseñas u otros secretos con esos niveles de entropía¹, en especial si no se usan con frecuencia (pero el uso frecuente de contraseñas con alta entropía es complicado y tedioso). Esto nos presenta un problema que supone un reto: ¿cómo podemos proteger datos privados con tecnología de encriptación si deseamos que el secreto sea un “factor de conocimiento” que el usuario pueda recordar fácilmente? Por varias razones, este problema es tan difícil de resolver que los servicios de almacenamiento en la nube normalmente solo encriptan datos con secretos que gestiona el propio proveedor de servicios en la nube, en lugar de depender de que el usuario recuerde su propio secreto.

Una forma de reducir la brecha entre los requisitos para secretos criptográficos y los secretos que los humanos puedan memorizar consiste en usar un servicio Cloud Key Vault (CKV) para almacenar una “clave de recuperación” de alta entropía, protegida por un secreto de baja entropía que la persona pueda recordar. El servicio CKV proporcionará la clave de recuperación únicamente a quien pruebe tener conocimiento del secreto correcto que una persona pueda memorizar. El servicio CKV puede frustrar los ataques por fuerza bruta contra los secretos que pueda memorizar una persona, lo cual impondrá un límite absoluto en la cantidad de intentos fallidos de probar que se conoce el secreto. La clave de recuperación en sí misma es una clave criptográfica simétrica estándar apropiada para usarse con un esquema de encriptación (autenticado) que puede encriptar fácilmente una gran cantidad de datos (como una copia de seguridad de un disco) que puedan almacenarse de manera segura en cualquier lugar. Estos datos encriptados no tienen utilidad para quien no pueda obtener la clave de recuperación.

En este documento se describe nuestro enfoque de 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 está diseñada para proteger claves de recuperación con el factor de conocimiento de pantalla bloqueada (LSKF); el PIN, la contraseña o el patrón de desbloqueo secretos que se usan para desbloquear los smartphones. Los humanos pueden recordar su LSKF correctamente. Al mismo tiempo, estos secretos del LSKF normalmente tienen la entropía suficiente como para resistir las acciones de un atacante cuya cantidad de intentos sea muy limitada, lo que los convierte en buenos candidatos para el servicio CKV.

La primera aplicación de nuestro servicio Cloud Key Vault consistirá en habilitar copias de seguridad de Android encriptadas del lado del cliente. Antes, los archivos encriptados de manera local 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 la pantalla bloqueada. Por primera vez, Cloud Key Vault habilita la protección de pantalla bloqueada también para 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 o restaurarlo. Solo un dispositivo con el LSKF del usuario puede descifrar las copias de seguridad.

Conceptos principales

En un principio, la única plataforma cliente admitida para el servicio Cloud Key Vault será el próximo sistema operativo Android P, y cuando hacemos referencia al cliente en el documento nos referimos a un dispositivo con el sistema operativo Android P y con los servicios de Google Móvil. Nuestra implementación para servidores se ejecuta en servidores de Google específicamente designados que tienen instalado un chip Titan² 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 imposición de seguridad (como se describe en el presente documento). Usamos técnicas de atestación de hardware para asegurarnos de que nuestro protocolo realmente se ejecute en el hardware Titan.

El servicio de CKV debe modificarse en escala para controlar el tráfico de miles de millones³ de dispositivos Android, sin perder una cantidad significativa de datos de usuarios por fallas en el hardware (p. ej., chips quemados) ni experimentar cortes prolongados por tareas de mantenimiento en el centro de datos. Por ello, los servidores que no tienen chips Titan se organizan en cohortes y cada cohorte consiste en varios THM independientes que contienen, cada uno, 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 fiabilidad. Por motivos de escalabilidad, los clientes se fragmentan en varias cohortes diferentes, para que se pueda ajustar la capacidad del servicio 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 pantalla bloqueada (LSKF): secreto que puede recordar una persona, como un PIN corto, un patrón de desbloqueo 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 como un factor de autenticación principal (o “fuerte”) para el bloqueo de pantalla del dispositivo local del usuario.

Cliente: dispositivo de usuario final que cuenta con el sistema operativo Android P y los servicios de Google Móvil, o un software compatible equivalente.

Marco de trabajo de Android: usamos este término genérico para referirnos a las API de la próxima versión del sistema operativo Android (sucesora de la versión Oreo, que a la fecha de publicación de este documento aún no tiene nombre) o de una versión posterior, y no pretende hacer referencia a ninguna versión anterior.

Servicios de Google Móvil: conjunto de servicios y apps que se ejecutan en el dispositivo del usuario final y permiten trabajar con el sistema de cuentas de Google y API personalizadas del servidor.

Agente de recuperación: aplicación del sistema que se ejecuta como parte de Google Play Services en el espacio del usuario, en un dispositivo con Android P (o similar). El agente de recuperación es el responsable de ejecutar el lado del cliente de los diferentes protocolos, y de interactuar con el sistema operativo Android según sea necesario para formular los mensajes de protocolo que contemplen el LSKF.

Reclamación de recuperación: cuando los usuarios desean recuperar la clave de recuperación, deben crear una reclamación de recuperación; esta contiene una copia encriptada del LSKF que el usuario afirma conocer. Normalmente, se solicitará al usuario ingresar 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: clave criptográfica secreta que se encuentra protegida por el servicio se Cloud Key Vault y se usa para encriptar (y autenticar) datos en el dispositivo cliente. Una vez que se introduce la clave de recuperación en un Vault (ver a continuación), la copia local puede borrarse no bien el cliente termina de usarla para encriptar datos.

Servicio Cloud Key Vault (CKV): servicio de Internet que permite, en dispositivos clientes, el almacenamiento de claves criptográficas protegidas por un LSFK que una persona pueda recordar.

Cohorte: conjunto de servidores de Vault y THM que pueden emplearse como réplicas redundantes entre sí.

Clave pública de cohorte: clave pública de un par de claves generada por una cohorte de THM específica. La clave privada correspondiente solo se encuentra disponible dentro de los THM que se hallan en la cohorte al generarse la clave.

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

Vault: entrada particular en la base de datos del servicio de CKV que contiene la clave de recuperación protegida del 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 Vault.

Servidor Vault: máquina de uso general que funciona en un centro de datos de Google especialmente modificado de manera retroactiva para agregar un THM.

Diseño de protocolo

El protocolo de CKV consta de varias fases:

Inicialización

Para inicializar el sistema, Google provee una clave pública para una “raíz de confianza” que el marco de trabajo de Android aplicará a la verificación de las atestaciones de hardware de Google. La clave de firma para esta raíz de confianza se almacena sin conexión y se protege cuidadosamente, de tal modo que se requieren varios empleados para poder realizar firmas con ella. La clave de firma para esta raíz de confianza se integra en el SO Android y solo puede modificarse por medio de 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 atestación en la lista. La atestación en la lista usa una firma que se vincula con la raíz de confianza. Cada actualización de la lista publicada contiene también un número de secuencia, por lo que es posible evitar reversiones. El agente de recuperación obtendrá la lista publicada más reciente de claves públicas de la cohorte y la provee al marco de trabajo de Android. El marco de trabajo de Android verifica luego la atestación y selecciona, de manera aleatoria, una clave pública de la cohorte a partir de la lista que se usará en la etapa de creación del Vault.

Creación del Vault

Luego de ayudar al marco de trabajo a completar la inicialización al obtener la lista de claves públicas de la cohorte, el agente de recuperación solicitará al marco de trabajo de Android que cree un nuevo Vault. Cuando el usuario introduzca luego 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 seleccionada por el marco de trabajo durante la inicialización. El BLOB encriptado resultante será el Vault que el marco de trabajo pasará al agente de recuperación, el cual luego lo subirá al servicio CKV de Google.

Apertura del Vault

Cuando el agente de recuperación del dispositivo nuevo necesite obtener acceso a la clave de recuperación que esté almacenada en un Vault determinado, primero solicitará al usuario introducir el LSKF del dispositivo original que creó el Vault. El agente de recuperación solicitará luego al marco de trabajo que cree una reclamación de recuperación usando el LSKF. El marco de trabajo generará una clave de solicitante nueva y la encriptará junto con el hash del LSKF solicitado, con la misma clave pública de la cohorte con la que se encriptó el Vault en un principio. El BLOB encriptado resultante se denomina reclamación de recuperación, y el marco de trabajo la pasa al agente de recuperación, el cual la presenta al servicio de CKV.

El CKV direcciona la reclamación de recuperación (y su Vault correspondiente) a los servidores de Vault que forman parte de la cohorte correcta. El THM de los servidores Vault luego descifra la reclamación de recuperación e intenta extraer la clave de recuperación del Vault original usando el hash del LSKF solicitado (para obtener la clave de encriptación interna). Si el hash del LSKF original y el hash del LSKF solicitado coinciden, el THM extraerá la clave de recuperación del Vault y volverá a encriptarla con la clave solicitante que estaba en la reclamación de recuperación. Si no coinciden, el THM transmitirá un contador de intento fallido. Cuando el contador de intentos fallidos alcance su límite, el THM rechazará el procesamiento de las reclamaciones de recuperación para este Vault.

Finalmente, si todo funciona correctamente, la clave de recuperación que se volvió a encriptar (y ahora estará encriptada en la clave solicitante) se enviará de nuevo del servidor Vault al marco de trabajo. El marco de trabajo usará su copia de la clave solicitante para descifrar la clave de recuperación y el protocolo quedará completo.

Medidas de seguridad

El sistema Cloud Key Vault tiene el objetivo de proporcionar una “defensa en profundidad” al incluir protecciones de seguridad en varios niveles de nuestra pila. Para dar una idea de cómo funcionan estas protecciones, comenzaremos por describir el cliente y avanzaremos en sentido ascendente por la pila hasta el servicio de Cloud Key Vault.

Seguridad del cliente

Según cada OEM y dispositivo en particular, el Lock Screen Knowledge Factor (LSKF) normalmente se almacena y protege en el dispositivo usando varios métodos diferentes que varían por OEM. Por ejemplo, los dispositivos Pixel 2 de Google utilizan un módulo de seguridad de hardware resistente a la manipulación para almacenar el LSKF en reposo e imponer límites de intentos basados en el hardware para la validación del LSKF. Las nuevas API del marco de trabajo que se introducen a fin de permitir el uso de Cloud Key Vault están diseñadas para preservar las garantías de seguridad actuales en la mayor medida posible, incluso cuando el dispositivo usa este módulo de seguridad de hardware para proteger el almacenamiento del LSKF.

En esta sección, pondremos el foco especialmente en los problemas de seguridad y las protecciones pertinentes que afectan a la nueva característica Cloud Key Vault, en lugar de intentar brindar una visión completa de todos los mecanismos de seguridad asociados con el LSKF.

Protección de las API del marco de trabajo

Las nuevas API del marco de trabajo que se agregaron para admitir el servicio CKV se marcan como @SystemApi y requieren permisos especiales. Esto garantiza que solo estén disponibles para apps de sistema aprobadas por OEM, como Google Play Services. Esto elimina en gran medida cualquier superficie de ataque directo que pudiera estar expuesta para apps que el usuario instale en el dispositivo.

Las API del marco de trabajo también garantizan que los Vaults solo se creen para claves públicas de la cohorte que una raíz de confianza haya sometido a atestación. Cuando se envía, el OEM integra la raíz de confianza al marco de trabajo, la cual no puede cambiarse sin una actualización del SO. Esto transmite la confianza de que el LSKF solo se utiliza para crear Vaults que impongan correctamente protecciones ante ataques por fuerza bruta basadas en hardware. Al delegar la protección contra ataques por fuerza bruta para el LSKF a los THM del servicio de Cloud Key Vault, podemos obtener una seguridad comparable a usar hardware seguro en el dispositivo para el mismo propósito (como en el caso de los dispositivos Google Pixel 2).

Debido a que no suponemos que el LSKF se almacenará en ningún lugar del dispositivo fuera del hardware seguro, un Vault nuevo solo puede crearse inmediatamente después del desbloqueo del dispositivo. Cuando el usuario introduce el LSKF para desbloquear el dispositivo, el LSKF queda disponible por poco tiempo para el marco de trabajo 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 Vault nuevo protegido con LSKF mientras el dispositivo se encuentre bloqueado, ya que el 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 radica en que el protocolo está diseñado para evitar que el agente de recuperación detecte el LSKF del dispositivo actual o cualquier clave de recuperación. Solo el marco de trabajo deberá detectar esto en el cliente, lo cual hace mucho más difícil explotar errores posibles o vulnerabilidades de seguridad en el agente de recuperación. El agente de recuperación se usa principalmente para controlar los eventos de ciclo de vida y la transferencia de datos hacia un lado y otro entre la nube y el marco de trabajo. La única excepción a esto se produce durante una recuperación previa al protocolo de apertura del Vault, cuando el usuario debe introducir el LSKF del dispositivo anterior (la IU que reúne el LSKF solicitado 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 solicitado no bien el marco de trabajo queda a cargo de construir la reclamación de recuperación.

Características de seguridad del protocolo

Aunque un análisis completo del protocolo sobrepasa el alcance de este documento, queremos destacar algunas de las protecciones integradas al protocolo. En particular, el protocolo solo usa el hash del LSKF a lo largo del proceso. Esto significa que si el LSKF tiene alta entropía (p. ej., si es una buena contraseña con alto nivel de entropía), almacenar el Vault es, en términos estrictos, 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 ello, admitimos el hashing con “uso elevado de memoria” y aleatorizado del LSKF como parte del protocolo. También vinculamos de forma 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 una comprobación durante el protocolo de apertura del Vault para garantizar que la reclamación de recuperación sea nueva.

Debido a que la clave de recuperación se genera nuevamente en cada creación del Vault, implementamos la rotación de claves reemplazando una entrada de Vault existente por un Vault recién creado. La dirección para el contador de intento fallido que usa el Vault se selecciona durante la creación de este último, y el marco de trabajo de Android comprueba que no cambie la dirección del contador que se use para los Vaults siguientes, a menos que se haya modificado el LSKF o que exista una lista atestada nueva de claves públicas de la cohorte. De este modo, la rotación de la clave de recuperación puede hacerse sin dañar la protección contra ataques por fuerza bruta para el LSKF.

Seguridad del servidor para el servicio de Cloud Key Vault

Se implementa el servidor usando una combinación de software que funciona en hardware común de servidores y firmware que funciona 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 lado del servidor del servicio de CKV está integrada por los Trusted Hardware Modules (THM) que se crean usando los chips Titan diseñados a medida para Google. Los chips ejecutan firmware que expone las API necesarias para implementar los protocolos del 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 llevar a cabo la operación de apertura de Vault y mantener, por cada uno de estos, un contador de intentos fallidos que aumente estrictamente (el contador está respaldado por un estado almacenado dentro del chip Titan). En una versión futura de este documento se brindará una descripción más detallada del protocolo que ejecuta el firmware del chip Titan para el CKV.

Debido a que la seguridad del servidor deriva de la lógica del firmware de los chips Titan, debemos asegurarnos de que esa lógica no cambie de modo que permita a los chips filtrar secretos o ignorar los límites de los contadores. A fin de lograr este objetivo, también alteramos el bootloader del chip Titan para asegurarnos de que los datos almacenados del chip (como la clave privada para la cohorte) se eliminen totalmente antes de que se aplique cualquier actualización. La desventaja de esta protección es que no podemos aplicar parches para los errores en el firmware sin experimentar cierta pérdida de datos. Actualizar el firmware equivale, en términos funcionales, a destruir el hardware existente y reemplazarlo por chips nuevos. En caso de que se necesite un parche de firmware crítico, Google deberá producir y publicar una lista completamente nueva de claves públicas de la cohorte atestadas y realizar una migración gradual de todos los usuarios a la nueva lista. Para reducir este riesgo, intentamos mantener la base de código del firmware en valores mínimos y auditarla cuidadosamente en busca de posibles problemas de seguridad.

Protecciones de software

Además de los límites de errores no recuperables por Vault impuestos por los THM, el servicio de CKV también implementa limitaciones basadas en el software para la cantidad de intentos. La limitación de la cantidad de intentos está diseñada para evitar que un pirata acceda a la cuenta de un usuario y agotar rápidamente su límite de intentos fallidos de recuperación, mediante el bloqueo del acceso de los usuarios reales a sus claves de recuperación. En un caso similar al de los retrasos de tiempo que impone el dispositivo del usuario luego de demasiados intentos fallidos para desbloquear la pantalla, el servicio de CKV impondrá un retraso de tiempo en aumento luego de cada solicitud fallida de apertura del Vault posterior.

También implementamos medidas de seguridad estándares para servicios en la nube que alojan datos de usuarios; esto incluye supervisiones, auditorías y controles de acceso estrictos.

Especificación detallada de protocolo

La detallada especificación de protocolo todavía se encuentra en proceso, y este documento se actualizará posteriormente, durante el año, para incluir esos detalles junto con la publicación del código de cliente en el Proyecto de código abierto de Android.

Notas