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 de proporcionar el factor de conocimiento correcto.
Autor: Shabsi Walfish
Fecha de la versión: 6/3/2018
Nota: Este documento aún está 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 el uso de 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. Con la disponibilidad actual de potencia de procesamiento, un requisito razonable de entropía mínima 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 forma confiable contraseñas o 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 deja un problema desafiante: ¿cómo podemos proteger los datos privados con tecnología de encriptación si queremos que el secreto sea un “factor de conocimiento” que muy probablemente el usuario recuerde? Por diversas razones, este problema es tan difícil de resolver que los servicios de Cloud Storage solo suelen encriptar datos 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 reducir la brecha entre los requisitos de los secretos criptográficos y los que sean fáciles de recordar por humanos es usar un servicio de Cloud Key Vault (CKV) a fin de almacenar una "clave de recuperación" de alta entropía, que está protegida por un secreto de baja entropía que una persona pueda recordar. El servicio de CKV liberará la clave de recuperación solo a quien demuestre que tiene conocimiento del secreto correcto que una persona puede memorizar. El servicio de CKV puede frustrar los ataques de fuerza bruta contra los secretos que pueda memorizar una persona, lo que impondrá un límite absoluto en la cantidad de intentos fallidos de probar el conocimiento del secreto. La clave de recuperación en sí es una clave criptográfica simétrica estándar, adecuada para usarse con un esquema de encriptación (autenticado) que puede encriptar fácilmente un gran volumen de datos (como una copia de seguridad de un disco) y almacenarse de forma 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 la pantalla de bloqueo (LSKF) del usuario: el PIN secreto, la contraseña o el patrón de desbloqueo que se usa para desbloquear los smartphones. Los seres humanos pueden recordar de forma confiable su LSKF. Al mismo tiempo, esos secretos del LSKF suelen tener la entropía justa para resistir a un atacante con un número muy limitado de intentos, lo que los convierte en un buen candidato para el servicio de CKV.
La primera aplicación de nuestro servicio de Cloud Key Vault consistirá en habilitar las copias de seguridad de Android encriptadas por el cliente. Anteriormente, 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 habilita la protección de pantalla de bloqueo también 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 desencriptarlas.
Conceptos principales
En un principio, 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 especialmente designados que tienen un chip Titan2 adicional instalado. El chip Titan diseñado por Google funciona como el componente de hardware de nuestro módulo de hardware confiable y lo aprovisionamos en especial con un bootloader y un firmware personalizados que implementan nuestros protocolos y mecanismos de aplicación de 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 del hardware (p.ej., chips quemados) o experimentar interrupciones prolongadas debido al mantenimiento del centro de datos. Por esta razón, los servidores con los chips Titan se organizan en cohortes, en las que cada cohorte consta de varios THM independientes que contienen una copia del mismo material de la clave. Se distribuirá una cohorte determinada en centros de datos físicamente dispares en distintas zonas de mantenimiento, a fin de 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): Es un secreto que una persona puede recordar, como un PIN corto, un patrón de deslizamiento sobre una cuadrícula de 3 × 3 puntos o una contraseña. 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 local del dispositivo del usuario.
Cliente: Un dispositivo de usuario final que ejecuta el sistema operativo Android 9 Pie y los Servicios de Google Play, o software compatible equivalente.
-
Framework de Android: Usamos este término genérico (o solo el framework) para hacer referencia a las API en Android 9 Pie o versiones posteriores, y no pretendemos hacer referencia a versiones anteriores.
Servicios de Google Play: Es un conjunto de servicios y apps que se ejecutan 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 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 los mensajes de protocolo que involucren el 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 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 en cuanto el cliente termine de usarla para encriptar datos.
Servicio Cloud Key Vault (CKV): Es un servicio de Internet que permite que los dispositivos cliente almacenen claves criptográficas protegidas por un LSKF que se pueda recordar.
-
Cohorte: Es un conjunto de THM o servidores de Vault que pueden funcionar como réplicas redundantes entre sí.
Clave pública de cohorte: la clave pública de un par de claves generado 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 poder generar o almacenar claves secretas, y mantener un estado en evolución no volátil (de modo que pueda evitar ataques que impliquen el restablecimiento a un estado anterior).
Vault: Es una entrada específica 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: 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
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 manera que requiera la participación de varios empleados para que puedan firmar con ella. La clave pública para 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 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, 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 cohorte de la lista para que se use en la fase de creación del Vault.
Creación del Vault
Después de ayudar al framework 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 framework que cree un nuevo Vault. La próxima vez que el usuario ingrese el LSKF, el framework 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 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 en un dispositivo nuevo necesita obtener acceso a la clave de recuperación que está almacenada en un Vault específico, primero le solicitará al usuario que ingrese el LSKF del dispositivo original que creó el Vault. A continuación, el agente de recuperación le pedirá al marco de trabajo que cree una reclamación de recuperación con ese LSKF. El framework generará una clave de solicitante nueva y la encriptará junto con el hash del LSKF reclamado, con la misma clave pública de cohorte con la que se encriptó 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, 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. Luego, el THM en los servidores de Vault desencripta la reclamación de recuperación y trata de extraer la clave de recuperación del Vault original con 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 de Vault y volverá a encriptarla 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 rechazará el procesamiento de 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 Vault hasta el marco de trabajo. El marco de trabajo usa su copia de la clave 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 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 Lock Screen Knowledge Factor (LSKF) normalmente se almacena y protege en el dispositivo a través de una variedad de métodos que varían según el OEM. Por ejemplo, los dispositivos Pixel 2 de Google utilizan 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 a la validación del LSKF. Las nuevas APIs de framework que se introducen 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 este 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 CKV están marcadas como @SystemApi y requieren permisos especiales, que garantizan que solo estén disponibles para apps del sistema aprobadas por 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 fueron certificadas por una raíz de confianza. El OEM integra la raíz de confianza en el framework cuando se envía y no puede cambiarse sin una actualización del SO. Esto proporciona la confianza de que el LSKF solo se utiliza para crear Vaults que aplicarán correctamente las protecciones de fuerza bruta basadas en hardware. Al confiar 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 cualquier 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 brevemente 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 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 proporcionamos 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 framework debería ver esos elementos del lado del cliente, lo que dificultaría mucho aprovecharse 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 traspaso 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 Vault, 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.4 Sin embargo, la implementación del agente de recuperación "olvida" el LSKF reclamado apenas el marco de trabajo toma el control de 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 una entropía alta (p.ej., si es una buena contraseña de alta entropía), almacenar el Vault es estrictamente mejor que almacenar un hash de contraseña y, en este caso, puede proporcionar una medida de seguridad independiente de la seguridad de los THM. Por esta razón, sí admitimos el hash con sal "uso de memoria" 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 sea actualizada.
Dado que la clave de recuperación se genera de nuevo en cada creación de Vault, implementamos la rotación de claves mediante el reemplazo de una entrada de Vault existente por un Vault recién creado. La dirección para el contador de intentos fallidos que usa Vault se selecciona durante su creación, y el framework garantiza que la dirección del contador que se use para cualquier Vault posterior 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 puede realizarse sin dañar la protección de fuerza bruta para el LSKF.
Seguridad del servidor para el servicio de Cloud Key Vault
El servidor se implementa mediante una combinación de software que se ejecuta en un 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 lado del 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 de Vault y mantener un contador de intentos fallidos por 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 ejecutado por el firmware del chip Titan del CKV.
Dado que la seguridad del servidor deriva de la lógica del firmware de los chips Titan, debemos asegurarnos de que la lógica no cambie de modo que permita a los chips filtrar secretos o ignorar los límites del contador. Para lograr este objetivo, también modificamos el cargador de arranque Titan para garantizar que los datos almacenados del chip (como la clave privada de 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 cohorte certificadas y migrar gradualmente a todos los usuarios a la lista nueva. Para mitigar este riesgo, tratamos de mantener la base de código del firmware en una cantidad mínima y la auditamos de forma cuidadosa para detectar cualquier posible problema de seguridad.
Protecciones de software
Además de los límites de fallas fijas por Vault que imponen 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 agotar 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 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 de protocolo detallada 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
- "Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX". 1 de agosto de 2014: https://www.usenix.org/node/184458. ∂
- “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. ∂
- "Google anunció que hay 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. ∂
- 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). ↩