Encriptado en reposo predeterminado

Este contenido se actualizó por última vez en mayo del 2024 y representa la situación en el momento en que se redactó. Es posible que los sistemas y las políticas de seguridad de Google cambien a medida que mejoramos la protección de nuestros clientes.

En Google, nuestra estrategia de seguridad integral incluye el cifrado en reposo, que ayuda a proteger los datos de los clientes frente a los atacantes. Encriptamos todo el contenido de los clientes de Google en reposo, sin que tengas que hacer nada, mediante uno o varios mecanismos de cifrado. En este documento se describe nuestro enfoque para el cifrado en reposo predeterminado de la infraestructura de Google y Google Cloud, así como la forma en que lo usamos para proteger el contenido de los clientes.

Este documento está dirigido a arquitectos y equipos de seguridad que usen o se planteen utilizar Google. En este documento se presupone que el lector tiene conocimientos básicos sobre encriptado y primitivas criptográficas. Para obtener más información sobre la criptografía, consulta Introduction to Modern Cryptography.

El cifrado en reposo es el que se usa para proteger los datos almacenados en un disco (incluidas las unidades de estado sólido) o en un soporte de copia de seguridad. Todos los datos que almacena Google se cifran en la capa de almacenamiento mediante el algoritmo estándar de cifrado avanzado (AES), AES-256. Utilizamos una biblioteca criptográfica común, Tink, que incluye nuestro módulo validado FIPS 140-2 (llamado BoringCrypto) para implementar el cifrado de forma coherente en Google Cloud.

Somos los propietarios y los administradores de las claves que se usan en el cifrado predeterminado en reposo. Si utilizasGoogle Cloud, Cloud Key Management Service te permite crear tus propias claves de encriptado, que puedes usar para añadir encriptado de envolvente a tus datos. Con Cloud KMS, puedes crear, rotar, monitorizar y eliminar claves. Para obtener más información, consulta el artículo Información pormenorizada sobre Cloud Key Management Service.

Teclas en Google Cloud

En la siguiente tabla se describen las diferentes propiedades de las claves de Google Cloud.

Tipo de clave	Autokey de Cloud KMS	Cloud KMS gestionado por el cliente (manual)	Google-owned and Google-managed encryption key (cifrado predeterminado de Google)
Puede ver metadatos clave	Sí	Sí	No
Propiedad de las claves^1	Cliente	Cliente	Google
Puede gestionar^2 y controlar^3 claves	La creación y la asignación de claves se automatizan. Se admite el control manual por parte del cliente.	Solo control manual por parte del cliente	Google
Cumple los requisitos normativos de las claves gestionadas por el cliente	Sí	Sí	No
Compartir llaves	Exclusivo de un cliente	Exclusivo de un cliente	Los datos de varios clientes suelen estar protegidos por claves de encriptado de claves (KEKs) compartidas.
Control de la rotación de claves	Sí	Sí	No
Políticas de organización de CMEK	Sí	Sí	No
Registrar el acceso administrativo y de datos a las claves de cifrado	Sí	Sí	No
Separación lógica de datos mediante cifrado	Sí	Sí	No
Precios	Varía	Varía	Gratis

¹ El propietario de la clave indica quién tiene los derechos de la clave. Google tiene un acceso muy restringido o nulo a las claves que te pertenecen.

La gestión de claves ² incluye las siguientes tareas:

• Crea claves.
• Elige el nivel de protección de las llaves.
• Asigna la autoridad para gestionar las claves.
• Controlar el acceso a las claves.
• Controlar el uso de las llaves.
• Definir y modificar el periodo de rotación de las claves o activar la rotación de las claves.
• Cambiar el estado de la clave.
• Eliminar versiones de clave.

³ El control de las claves implica establecer controles sobre el tipo de claves y cómo se usan, detectar variaciones y planificar medidas correctivas si es necesario. Puedes controlar tus llaves, pero delegar la gestión de las llaves en un tercero.

Cómo ayuda el cifrado en reposo a proteger los datos

El encriptado en reposo es una de las piezas de una estrategia de seguridad más amplia. El cifrado tiene las siguientes ventajas:

• Ayuda a garantizar que, si los datos caen en manos de un atacante, este no pueda leerlos si no tiene acceso a las claves de cifrado. Aunque los atacantes obtengan los dispositivos de almacenamiento que contienen datos de clientes, no podrán comprenderlos ni descifrarlos.
• Ayuda a reducir la superficie de ataque al eliminar las capas inferiores de la pila de hardware y software.
• Actúa como un cuello de botella, ya que las claves de cifrado gestionadas de forma centralizada crean un único lugar desde donde acceder a los datos, que además se puede auditar.
• Ayuda a reducir la superficie de ataque, ya que, en lugar de tener que proteger todos los datos, las empresas pueden centrar sus estrategias de protección en las claves de cifrado.
• Proporciona un mecanismo de privacidad importante para nuestros clientes. Cuando los datos se cifran en reposo, se limita el acceso que tienen los sistemas y los ingenieros a los datos.

¿Qué son los datos de clientes?

Tal y como se definen en los Google Cloud Términos del Servicio, los datos del cliente son los datos que los clientes o los usuarios finales proporcionan a Google a través de los servicios de su cuenta.

El contenido del cliente son los datos que usted genera o nos proporciona, como los datos almacenados en segmentos de Cloud Storage, volúmenes de disco persistente y capturas de disco usadas por Compute Engine. Este documento se centra en el cifrado en reposo predeterminado de este tipo de datos de clientes.

Los metadatos del cliente son datos sobre el contenido del cliente e incluyen números de proyecto generados automáticamente, marcas de tiempo, direcciones IP, el tamaño en bytes de un objeto de Cloud Storage o el tipo de máquina de Compute Engine. Los metadatos de los clientes cuentan con un grado de protección razonable que permite garantizar un buen rendimiento y la continuidad de las operaciones. Este documento no se centra en las protecciones de los metadatos.

El contenido y los metadatos del cliente constituyen los datos del cliente.

Cifrado predeterminado de datos en reposo

Google encripta mediante uno o varios mecanismos el contenido de los clientes que se almacena en reposo, sin que usted tenga que realizar ninguna acción. En las siguientes secciones se describen los mecanismos que usamos para cifrar el contenido de los clientes.

Capas de encriptado

En Google utilizamos varias capas de encriptado para proteger los datos. El uso de varias capas de encriptado aporta una protección de datos redundante y nos permite elegir el enfoque más adecuado en función de los requisitos de cada aplicación.

En el siguiente diagrama se muestran las distintas capas de cifrado que se suelen usar para proteger los datos de los usuarios en los centros de datos de producción de Google. Se implementa, o bien el encriptado de sistemas de archivos distribuidos, o bien el encriptado de almacenamiento en base de datos y archivos para todos los datos de los usuarios. Además, se utiliza el encriptado de dispositivos de almacenamiento para todos los datos de los centros de datos de producción de Google.

Encriptado en la capa de infraestructura

Todos los sistemas de almacenamiento de Google usan una arquitectura de cifrado similar, aunque los detalles de la implementación varían de un sistema a otro. Para poder almacenar los datos, se dividen en fragmentos lógicos; cada fragmento puede tener un tamaño de varios gigabytes. Cada fragmento se cifra a nivel de almacenamiento con una clave de cifrado de datos (DEK) única. Por tanto, dos fragmentos diferentes nunca podrán tener la misma DEK, aunque pertenezcan al mismo cliente o se almacenen en la misma máquina.

Si se actualiza un fragmento de datos, se encripta con una clave nueva en lugar de reutilizar la clave anterior. Esta partición de datos, en la que cada fragmento usa una clave diferente, limita el riesgo de que se vea comprometida una clave de cifrado de datos a ese fragmento de datos.

Google cifra los datos antes de que se escriban en un sistema de almacenamiento de bases de datos o en un disco de hardware. El cifrado es inherente a todos nuestros sistemas de almacenamiento, no un paso que se añade a posteriori.

Cada fragmento de datos lógico tiene un identificador único. Las listas de control de acceso (LCAs) ayudan a garantizar que cada fragmento se pueda desencriptar únicamente mediante los servicios de Google que operan con roles autorizados, a los que se concede acceso solo en ese momento. Esta limitación del acceso ayuda a evitar que se acceda a los datos sin autorización, lo que refuerza su seguridad y privacidad.

Cada fragmento se distribuye a través de nuestros sistemas de almacenamiento y se replica en su forma encriptada para la realización de copias de seguridad y la recuperación tras fallos. Un atacante que quiera acceder a los datos de los clientes deberá conocer y tener acceso a dos cosas: todos los fragmentos de almacenamiento correspondientes a los datos que quiere obtener y todas las claves de cifrado correspondientes a los fragmentos.

En el siguiente diagrama se muestra cómo se suben los datos a nuestra infraestructura y, a continuación, se dividen en fragmentos encriptados para almacenarlos.

Usamos el algoritmo AES para encriptar los datos en reposo. Todos los datos del nivel de almacenamiento se encriptan con DEKs, que usan AES-256 de forma predeterminada, a excepción de un número reducido de discos persistentes que se crearon antes del 2015 y que usan AES-128. AES está muy extendido porque el Instituto Nacional de Estándares y Tecnología (NIST) recomienda AES-256 y AES-128 para su uso en el almacenamiento a largo plazo, y AES a menudo forma parte de los requisitos de cumplimiento de los clientes.

Un fragmento de datos lógico puede contener los datos de varios clientes. Si quieres conseguir una separación lógica de los datos mediante el cifrado, debes habilitar Cloud Key Management Service.

Encriptado en la capa del dispositivo de almacenamiento

Además del cifrado a nivel del sistema de almacenamiento, los datos también se cifran a nivel del dispositivo de almacenamiento con AES-256 en las unidades de disco duro (HDD) y las unidades de estado sólido (SSD), mediante una clave independiente a nivel de dispositivo (que es diferente de la clave utilizada para cifrar los datos a nivel de almacenamiento). Un número reducido de HDD antiguos usan AES-128. Las SSD que utiliza Google implementan AES-256 exclusivamente para los datos de usuario.

Encriptado de las copias de seguridad

Nuestro sistema de copias de seguridad garantiza que los datos permanezcan encriptados durante todo el proceso de copia de seguridad. Este enfoque evita que los datos de texto sin formato se expongan de forma innecesaria.

Además, el sistema de copias de seguridad cifra la mayoría de los archivos de copia de seguridad de forma independiente con su propia DEK. La DEK se deriva de una clave almacenada en el almacén de claves y de una semilla por archivo generada de forma aleatoria al crear la copia de seguridad. Para todos los metadatos de las copias de seguridad se utiliza otra DEK, que también se almacena en Keystore.

Cumplimiento del estándar FIPS para los datos en reposo

Google utiliza un módulo de encriptado FIPS 140-2(certificado 4407) en nuestro entorno de producción.

Gestión de claves

Debido al gran volumen de claves que tenemos en Google y a la necesidad de ofrecer una latencia baja y una disponibilidad alta, las DEKs se almacenan cerca de los datos que cifran. Las DEKs se cifran (se encapsulan) con una clave de cifrado de claves (KEK) mediante una técnica conocida como cifrado envolvente. Estas KEKs no son específicas de los clientes, sino que cada servicio tiene una o varias KEKs.

Estas KEK se almacenan de forma centralizada en Keystore, un repositorio creado específicamente para almacenar claves. La existencia de un menor número de KEKs que de DEKs y el uso de un almacén de claves centralizado posibilita el almacenamiento y el cifrado de datos a nuestra escala, y nos permite monitorizar y controlar el acceso a los datos desde un punto central.

Nota: Keystore antes se conocía como servicio de gestión de claves de Google. Es diferente de Cloud KMS, que gestiona las claves de encriptado de losGoogle Cloud clientes y les ayuda a crear sus claves de inquilino.

En Google Cloud, cada cliente puede tener recursos compartidos y no compartidos. Un ejemplo de recurso compartido es una imagen base compartida en Compute Engine. En el caso de los recursos compartidos, varios clientes se remiten a una sola copia, que está cifrada con una única DEK. Los recursos no compartidos se dividen en fragmentos de datos y se encriptan con claves distintas a las que se utilizan con otros clientes. Estas claves son incluso independientes de las que protegen otras partes de los mismos datos que pertenecen al mismo cliente. Hay excepciones (por ejemplo, Datastore, App Engine o Pub/Sub) en las que los datos de más de un cliente pueden estar cifrados con la misma DEK.

Generar DEKs

El sistema de almacenamiento genera las DEK mediante la biblioteca criptográfica común de Google. Por lo general, las DEKs se envían a Keystore para encapsularlas con la KEK de ese sistema de almacenamiento y, luego, las DEKs encapsuladas se reenvían al sistema de almacenamiento para guardarlas con los fragmentos de datos. Cuando un sistema de almacenamiento necesita acceder a datos encriptados, obtiene la DEK encapsulada y la envía a Keystore. A continuación, Keystore verifica que el servicio tiene autorización para usar la KEK y, si es así, desencapsula la DEK y se la devuelve al servicio en forma de texto sin formato. A continuación, el servicio usa la DEK para desencriptar el fragmento de datos convirtiéndolo en texto sin formato y verificar su integridad.

Todos los sistemas de almacenamiento se ajustan a este modelo de gestión de claves, pero la mayoría también implementan niveles adicionales de KEKs del lado del almacenamiento para crear una jerarquía de claves. Google Cloud De esta forma, los sistemas pueden ofrecer una latencia baja y, al mismo tiempo, usar la KEK de nivel más alto (almacenada en Keystore) como raíz de confianza.

Generar KEKs

La mayoría de las KEK que se utilizan para encriptar fragmentos de datos se generan dentro de Keystore, y el resto, dentro de los servicios de almacenamiento. Por motivos de coherencia, todas las KEK se crean a través de la biblioteca criptográfica común de Google, mediante un generador de números aleatorios (RNG) diseñado por Google. Este RNG se basa en NIST 800-90Ar1 CTR-DRBG y genera una KEK en AES-256. (Antes, era AES-128 y algunas de estas claves siguen activas para descifrar datos).

En el caso de los procesadores Intel y AMD, el RNG se deriva de la instrucción RDRAND y del RNG del kernel de Linux. A su vez, el RNG del kernel de Linux se deriva de varias fuentes de entropía independientes, como RDRAND y eventos entrópicos del entorno del centro de datos (por ejemplo, mediciones detalladas de búsqueda de discos y tiempos de llegada entre paquetes). En el caso de los procesadores Arm, el RNG se deriva del RNG del kernel de Linux.

Las DEKs se encapsulan con KEKs mediante AES-256 o AES-128, en función del servicio deGoogle Cloud . Actualmente, estamos actualizando todas las KEK para los servicios deGoogle Cloud a AES-256.

Gestión de KEKs

Keystore se creó exclusivamente con el objetivo de gestionar las KEK. Por diseño, las KEKs que usan los sistemas de almacenamiento no se pueden exportar desde el almacén de claves; todo el cifrado y descifrado con estas claves se debe realizar dentro del almacén de claves. Esto ayuda a evitar que se produzcan filtraciones y que se haga un uso inadecuado de ellas, y permite que Keystore cree un registro de auditoría cuando se utilizan claves.

Keystore puede rotar las KEKs automáticamente en intervalos de tiempo periódicos a través de la biblioteca criptográfica común de Google para generar nuevas claves. Aunque a menudo hacemos alusión a una sola clave, lo que realmente queremos decir es que los datos se protegen mediante el uso de un conjunto de claves: una clave activa para el encriptado y un conjunto de claves históricas activas para el desencriptado. El número de claves históricas se determina según la programación de rotación de claves. Con fines de recuperación tras fallos, se crea una copia de seguridad de las KEKs. De este modo, pueden recuperarse indefinidamente.

El uso de las KEKs se gestiona mediante LCAs en Keystore para cada clave, y se aplica una política a cada clave. Solo los usuarios y servicios de Google autorizados tienen acceso a las claves. El uso de cada clave se monitoriza a nivel de la operación concreta que requiere dicha clave. Así, cada vez que un usuario utiliza una clave, se autentica y registra. Para cumplir con las políticas de seguridad y privacidad generales de Google, todos los accesos de los usuarios a los datos son auditables.

Proceso para acceder a los fragmentos de datos cifrados

Cuando un servicio de Google accede a un fragmento de datos encriptado, ocurre lo siguiente:

1. El servicio hace una llamada al sistema de almacenamiento para obtener los datos que necesita.
2. El sistema de almacenamiento identifica los fragmentos en los que se almacenan dichos datos (los ID de los fragmentos) y el lugar en que se almacenan.
3. A continuación, el sistema de almacenamiento extrae la DEK encapsulada que se ha almacenado con cada fragmento (en algunos casos, el propio servicio se encarga de realizar esta operación) y la envía a Keystore para desencapsularla.
4. El sistema de almacenamiento verifica que la tarea identificada tiene permiso para acceder al fragmento de datos; para ello, comprueba el identificador de la tarea y el ID del fragmento. Keystore verifica que el sistema de almacenamiento tiene autorización para usar la KEK asociada al servicio y para desencapsular esa DEK en particular.
5. El almacén de claves realiza una de las siguientes acciones:
   • Devuelve la DEK desencapsulada al sistema de almacenamiento, el cual desencripta el fragmento de datos y lo envía al servicio.
   • En algunos casos excepcionales, envía la DEK desencapsulada al servicio. El sistema de almacenamiento envía el fragmento de datos encriptado al servicio, el cual desencripta el fragmento de datos y lo utiliza.

Este proceso es distinto en los dispositivos de almacenamiento especializados, donde el dispositivo gestiona y protege la DEK de nivel de dispositivo.

En el siguiente diagrama se muestra este proceso. Para desencriptar un fragmento de datos, el servicio de almacenamiento llama a Keystore para acceder a la DEK desencapsulada de dicho fragmento de datos.

Jerarquía de las claves de encriptado y raíz de confianza

El almacén de claves está protegido por una clave raíz llamada clave maestra del almacén de claves, que encapsula todas las KEK del almacén de claves. Esta clave maestra del almacén de claves utiliza el estándar AES-256 y se almacena en otro servicio de gestión de claves, denominado Root Keystore. Antes, la clave maestra del almacén de claves era AES-128 y algunas de estas claves siguen activas para desencriptar datos. Para ofrecer una mayor seguridad, Root Keystore no se ejecuta en máquinas de producción general, sino que lo hace únicamente en máquinas especializadas de cada centro de datos de Google.

A su vez, Root Keystore tiene su propia clave raíz, llamada clave maestra de Root Keystore, que también utiliza el estándar AES-256 y se almacena en una infraestructura entre pares, denominada distribuidor de claves maestras de Root Keystore, que replica estas claves en todo el mundo. Antes, la clave maestra del almacén de claves raíz era AES-128 y algunas de estas claves siguen activas para descifrar datos. El distribuidor de claves maestras del almacén de claves raíz solo tiene las claves en la RAM de las mismas máquinas especializadas que el almacén de claves raíz y utiliza registros para verificar que se hace un uso adecuado.

Cuando se inicia una nueva instancia del distribuidor de claves maestras del almacén de claves raíz, se configura con una lista de nombres de host de instancias de distribuidor que ya están en ejecución. De este modo, las instancias de distribuidor pueden obtener la clave maestra del almacén de claves raíz a partir de otras instancias en ejecución. Aparte de los mecanismos de recuperación tras fallos que se describen en Disponibilidad y replicación globales, la clave maestra del almacén de claves raíz solo existe en la RAM en un número limitado de máquinas especialmente protegidas.

Para abordar una situación en la que todas las instancias del distribuidor de claves maestras del almacén de claves raíz de una región se reinicien simultáneamente, se crea una copia de seguridad de la clave maestra del almacén de claves raíz en los dispositivos de hardware seguros almacenados en cajas fuertes físicas, situados en zonas altamente protegidas de varias ubicaciones distribuidas geográficamente. Esta copia de seguridad solo sería necesaria si todas las instancias de distribuidor de una región se desactivaran a la vez. Solo unos pocos empleados de Google pueden acceder a estas cajas fuertes.

En el siguiente diagrama se muestra la jerarquía de claves de cifrado. La jerarquía de las claves de encriptado protege un fragmento de datos con una DEK, encapsulada con una KEK en Keystore, que a su vez está protegida por Root Keystore y el distribuidor de claves maestras de Root Keystore.

Resumen de la gestión de claves

En la siguiente lista se resume la gestión de claves en Google:

• Los datos se fragmentan y se encriptan con DEKs.
• Las DEK se encriptan con KEKs.
• Las KEKs se almacenan en el almacén de claves.
• Keystore se ejecuta en varias máquinas en centros de datos de todo el mundo.
• Las claves del almacén de claves se encapsulan con la clave maestra del almacén de claves, que se almacena en Root Keystore.
• Root Keystore es mucho más pequeño que Keystore y solo se ejecuta en máquinas especializadas de cada centro de datos.
• Las claves de Root Keystore se encapsulan con la clave maestra de Root Keystore, que se almacena en el distribuidor de claves maestras de Root Keystore.
• El distribuidor de claves maestras de Root Keystore es una infraestructura entre pares que se ejecuta simultáneamente en la memoria RAM de máquinas especializadas situadas en distintos lugares del mundo. Cada máquina obtiene su material de claves de otras instancias en ejecución de la región.
• En caso de que todas las instancias del distribuidor de una región se desactivaran, hay una clave maestra almacenada en un hardware seguro diferente, en cajas fuertes físicas de unos pocos centros de Google.

Disponibilidad mundial y replicación

En todos los niveles, la alta disponibilidad, la baja latencia y el acceso mundial a las claves son fundamentales. Estas características son esenciales para que los servicios de gestión de claves se puedan usar en Google.

Por este motivo, Keystore es muy escalable y se replica miles de veces en nuestros centros de datos de todo el mundo. Se ejecuta en máquinas normales de nuestro equipo de producción, y hay instancias de Keystore ejecutándose en diferentes lugares del planeta para posibilitar las operaciones de Google. Por tanto, la latencia de todas las operaciones de claves es muy baja.

Root Keystore se ejecuta en varias máquinas especializadas en realizar operaciones de seguridad en cada centro de datos. El distribuidor de claves maestras de Root Keystore se ejecuta en estas mismas máquinas, en relación de uno a uno con Root Keystore. El distribuidor de claves maestras de Root Keystore proporciona un mecanismo de distribución mediante un protocolo Gossip. En un intervalo de tiempo fijo, cada instancia del distribuidor elige otra instancia de forma aleatoria para comparar sus claves y conciliar las diferencias con las versiones de claves. En este modelo, nuestra infraestructura no depende de un nodo central. Este método de distribución nos permite mantener y proteger el material de claves con alta disponibilidad.

Biblioteca criptográfica común de Google

La biblioteca criptográfica común de Google se llama Tink e incorpora BoringCrypto, nuestro módulo validado FIPS 140-2. Todos los desarrolladores de Google pueden utilizar Tink. El uso coherente de una biblioteca común significa que solo hace falta un equipo reducido de criptógrafos para implementar y mantener este código estrictamente controlado y revisado. De este modo, no es necesario que cada equipo de Google desarrolle su propia criptografía. Un equipo especial de seguridad de Google es responsable de mantener esta biblioteca criptográfica común para todos los productos.

La biblioteca de cifrado Tink es compatible con una amplia gama de tipos y modos de claves de cifrado que se revisan periódicamente para garantizar que estén protegidos contra los ataques más recientes.

Nota: Google también usa otra biblioteca llamada Keymaster. Keymaster comparte código de criptografía más reciente con Tink, pero utiliza una implementación de versiones de clave diferente y es compatible con una gama más amplia de algoritmos antiguos.

Actualmente, usamos los siguientes algoritmos de cifrado para el cifrado en reposo de las DEK y KEK. Dichos algoritmos de encriptado pueden cambiar a medida que mejoramos nuestras funcionalidades y la seguridad.

Primitiva criptográfica	Protocolos preferidos	Otros protocolos compatibles
Encriptado simétrico	AES‑GCM (256 bits)	AES‑CBC y AES‑CTR (128 y 256 bits) AES‑EAX (128 y 256 bits)
Firmas simétricas (cuando se usan con los AES-CBC y AES-CTR anteriores para la autenticación)	HMAC‑SHA256	HMAC‑SHA512 HMAC‑SHA1

En la biblioteca hay otros protocolos criptográficos que fueron compatibles anteriormente, pero en esta tabla se tratan los principales usos en Google.

Investigación e innovación en criptografía

Para mantenernos al día en materia de avances del cifrado, contamos con un equipo de ingenieros de seguridad de primer orden dedicados a analizar, desarrollar y mejorar la tecnología de cifrado. Nuestros ingenieros se encargan de los procesos de estandarización y del mantenimiento del software de encriptado de uso más generalizado. Realizamos publicaciones periódicas sobre nuestras investigaciones en el campo del cifrado para que todo el mundo, incluido el público en general, pueda beneficiarse de nuestros conocimientos.

Por ejemplo, en la investigación de criptografía poscuántica, estamos trabajando en las siguientes áreas:

• Estandarización: hemos diseñado conjuntamente el esquema de firma digital sin estado basado en hash que se ha estandarizado como FIPS 205. Somos editores del estándar de la Organización Internacional de Normalización (ISO) sobre firmas basadas en hash de criptografía poscuántica y hemos contribuido a la guía sobre gestión de estados para firmas basadas en hash en el IETF.

• Habilitación: hemos implementado la criptografía poscuántica en nuestro protocolo interno de seguridad de la capa de transporte. Hemos habilitado la compatibilidad con la criptografía poscuántica en Chrome. Hemos añadido varios algoritmos de criptografía poscuántica a nuestra biblioteca criptográfica Tink. Este código es experimental y se ha diseñado para informar a la comunidad sobre cada enfoque.

• Publicaciones: hemos publicado el artículo Transitioning organizations to post-quantum cryptography (Transición de las organizaciones a la criptografía poscuántica) en Nature. En este documento se ofrece una descripción general de los retos de la migración a la criptografía poscuántica. También hemos publicado un documento de investigación sobre la criptografía postcuántica en nuestras llaves de seguridad.

Ten en cuenta que el cifrado simétrico (con AES-128 o versiones posteriores) sigue siendo resistente a los ataques cuánticos.

Siguientes pasos

• Para obtener información sobre cómo usar tus propias claves de cifrado enGoogle Cloud, consulta Claves de cifrado gestionadas por el cliente (CMEK).

• Para obtener información general sobre la seguridad de Google Cloud , consulta la sección "Seguridad" del sitio web de Google Cloud .

• Para obtener información sobre el Google Cloud cumplimiento y las certificaciones de cumplimiento, consulta la sección Cumplimiento del Google Cloud sitio web, donde se incluye el informe público de auditoría SOC3 de Google.

• Para obtener información sobre el cifrado y la gestión de claves de Google Workspace, consulta el artículo Cómo usa Google Workspace el cifrado para proteger tus datos, que abarca gran parte del contenido incluido aquí, pero se centra únicamente en Google Workspace.