Arquitectura de procesamiento multipartita

Google Cloud La computación multipartita proporciona una infraestructura de confianza criptográfica para las operaciones institucionales con recursos digitales. Utiliza una arquitectura multiusuario única: cada instancia que creas es un entorno dedicado y aislado con su propia entrada de red, su propio almacenamiento y su propio procesamiento aislado por hardware para operaciones criptográficas.

Componentes centrales

Diagrama de arquitectura de Multi-party Compute

Cada instancia de procesamiento multipartita tiene tres componentes principales. La lógica de administración, el enrutamiento de solicitudes y los cálculos criptográficos se ejecutan en componentes separados.

API de MPC

La API de Multi-party Compute administra los siguientes recursos:

  • Usuarios y equipos: Son las identidades que tienen roles en la instancia y los grupos de firmantes a los que se refieren las políticas de claves.
  • Llaveros de claves y políticas de claves: Los llaveros de claves que agrupan claves, cada uno con la política de claves que decide qué equipos y usuarios tienen fragmentos de claves y cuántos de ellos deben aprobar una firma.
  • TransactionPolicies: Son las reglas de Cedar que permiten o prohíben las transacciones, y las aprobaciones del autor de la política que las activan o inhabilitan.
  • KeyLists: Son las listas con nombre de direcciones a las que pueden hacer referencia las políticas de transacciones.

La API de computación multipartita hace un seguimiento del estado de cada transacción y de las aprobaciones registradas en ella, y le pide al coordinador que organice la generación y la firma de claves. Spanner almacena las solicitudes y las aprobaciones firmadas. Los TEE de los trabajadores verifican las firmas de aprobación antes de actuar en función de ellas.

Coordinador

La API de Multi-party Compute conecta el controlador a los TEE de los participantes:

  • Detección de archivos compartidos de claves y enrutamiento de solicitudes: Asigna TEE en buen estado para que contengan nuevos archivos compartidos de claves durante la generación de claves y, luego, enruta la solicitud a los TEE adecuados.
  • Estado: Supervisa el estado de los TEE de los participantes y funciona como un balanceador de cargas para las solicitudes de firma.
  • Durabilidad: Administra el uso compartido cuando se debe reemplazar un recurso compartido de claves.

El coordinador no afecta la seguridad del protocolo. No contiene fragmentos de claves ni verifica aprobaciones o resultados de políticas; esa verificación se realiza dentro de los TEE de los participantes.

TEE de trabajadores

Cada trabajador es un TEE que se ejecuta en Confidential Space. Un TEE de trabajador ejecuta dos partes:

  • Motor criptográfico: Contiene los fragmentos de claves y ejecuta los protocolos de firma y generación de claves de umbral seguro con los otros TEE de trabajador.
  • Evaluador de políticas: Evalúa las transacciones en función del conjunto activo de políticas de transacciones.

Flujo de firma de transacciones

En Multi-party Compute, firmas una carga útil con una sola llamada a la API, CreateTransaction. La evaluación de la política de transacciones, las aprobaciones de los firmantes y la firma de umbral comienzan con esta llamada. Este es el flujo en un orden fijo:

  1. Solicitud. Un firmante llama a CreateTransaction en una clave. La solicitud incluye la aprobación del firmante, firmada con su clave de autorización. IAM verifica que el emisor pueda llamar al método, y la solicitud se registra en los Registros de auditoría de Cloud.
  2. Evaluación de políticas. La transacción se evalúa en función del conjunto activo de políticas de transacciones. La evaluación de la política produce un registro de auditoría duradero para cada veredicto, ya sea APPROVED o REJECTED.
  3. Aprobación del iniciador. Si solo la aprobación del iniciador cumple con los umbrales de la política de claves, CreateTransaction pasa al paso 5 de inmediato.
  4. Aprobaciones de firmantes. Si la aprobación del iniciador por sí sola no cumple con los umbrales de la política de claves, la transacción ingresa al estado PENDING_AUTHORIZATION. Otros firmantes que tienen partes de la clave aprueban o rechazan la transacción con la llamada RecordSignerDecision, cada una firmada con su clave de autorización. La transacción espera en el estado PENDING_AUTHORIZATION hasta que suficientes firmantes la aprueben para cumplir con los umbrales de la política de claves. Si suficientes firmantes la rechazan de modo que ya no se puedan cumplir los umbrales, la transacción pasa al estado REJECTED. Si no obtiene suficientes aprobaciones antes de su fecha de vencimiento, se EXPIRED.

  5. Firma de umbral. Cuando se cumplen los umbrales, los entornos de ejecución confiables (TEE) que contienen los fragmentos de la clave ejecutan el protocolo de firma de umbral y producen la firma en la transacción.

    Antes de que un TEE participante use su fragmento de clave, verifica que la carga útil exacta que se le solicita firmar se haya evaluado en función de tus políticas de transacciones. Ningún cliente, operador ni otro componente de servicio puede hacer que un participante firme una carga útil que no se evaluó.

Para conocer los recursos involucrados, como usuarios, equipos, llaveros de claves y políticas de transacciones, consulta la descripción general de la computación multipartita.

Modelo de seguridad

  • Claves compartidas fijadas en su TEE Solo el TEE que creó cada fragmento de clave puede leerlo. Los fragmentos de claves nunca salen de ese TEE de una forma que otro componente, incluidos el Coordinador, el Controlador o un operador de Google, puedan leer.
  • Custodia de claves del cliente. El cliente conserva la custodia total de sus claves de encriptación en todo momento con Cloud Key Management Service en la organización de Google Cloud del cliente.
  • Aislamiento de hardware. Los TEE de los participantes se ejecutan en Confidential Space, que usa la encriptación de memoria de hardware para proteger los datos en uso del host y de la infraestructura de Google. La certificación vincula cada TEE a una imagen de contenedor verificada.
  • Encriptación de extremo a extremo Los TEE de trabajador se comunican directamente a través de gRPC encriptado de extremo a extremo.
  • Aprobaciones firmadas. Los firmantes, los autores de políticas y los administradores firman sus aprobaciones con una clave de autorización cuya mitad privada nunca los abandona. Los TEE de los participantes verifican estas firmas antes de firmar una transacción, aceptar una política de transacciones o aceptar un cambio de rol de administrador o autor de políticas. Esto hace que las transacciones sean a prueba de manipulaciones y deja un registro de auditoría duradero.
  • Quórum de Policy Author. Una nueva política de transacciones, o una solicitud para inhabilitar una, solo entra en vigencia después de que la cantidad requerida de autores de políticas la apruebe.
  • Cuórum de administradores. El otorgamiento o la eliminación del rol de administrador o autor de políticas solo se aplica después de que la cantidad requerida de administradores lo apruebe. Para obtener más información, consulta Aprobación del administrador de los cambios de rol.

Hoja de ruta

Las siguientes funciones están previstas para versiones posteriores:

  • TEE externos: Son los fragmentos de claves que se conservan en los TEE que los clientes ejecutan fuera de Google Cloud, como AWS Nitro Enclaves.
  • Claves compartidas móviles: Son las claves compartidas que se guardan en los dispositivos móviles de los usuarios.
  • Uso compartido: Cambiar quién tiene los fragmentos de una clave existente o reemplazar un fragmento perdido sin cambiar la clave.

Propiedades del sistema

La infraestructura de confianza de la computación multipartita mantiene las siguientes propiedades del sistema.

Seguridad (solidez en un contexto criptográfico)

Bajo ninguna circunstancia, el sistema debe comportarse de una manera no permitida. Por ejemplo, ningún grupo de menos de k participantes, en virtud del protocolo DKLS23, puede falsificar firmas. Las definiciones de seguridad exactas se formalizan en el framework de composición universal de la literatura.

Cuando un sistema criptográfico se incorpora en una implementación práctica, se debe tener cuidado para evitar depender de suposiciones que socaven las propiedades de seguridad. Por ejemplo, cada parte del protocolo debe ser independiente: su susceptibilidad a verse comprometida debe ser independiente.

Para garantizar esta propiedad, la computación multipartita ejecuta a cada participante en un TEE certificado, y cada fragmento de clave se fija al TEE que lo creó. La vulneración de un participante en el protocolo no afecta a los demás participantes.

La literatura académica sobre la computación multipartita se enfoca casi exclusivamente en la solidez y asume un mundo simplista en el que el conjunto de partes es inmutable, todas las partes están siempre disponibles y se comunican usando canales autenticados punto a punto ideales y siempre disponibles. Para un producto del mundo real, se deben abordar varias inquietudes adicionales.

En funcionamiento

El sistema avanza con el tiempo. La propiedad de actividad más común es la ausencia de interbloqueo, que se cumple en el protocolo DKLS23. Se puede usar una clave de umbral para firmar, siempre y cuando haya suficientes TEE que contengan sus partes para cumplir con los umbrales de la política de claves. Por ejemplo, con una clave de 2 de 3, cualquiera de los 2 de los 3 fragmentos puede completar una firma.

Durabilidad

Las partes que fallan de forma permanente deben reemplazarse; de lo contrario, el sistema perderá el secreto compartido de forma permanente. Por ejemplo, cuando falla el hardware, se pierde el estado del participante que se ejecuta en ese hardware. Debido a que los fragmentos de claves se fijan a sus TEE, el Coordinador hace un seguimiento de qué TEE contienen los fragmentos de cada clave. En v1beta, una clave sigue siendo utilizable mientras queden suficientes de sus fragmentos para cumplir con los umbrales de la política de claves. Para reemplazar un recurso compartido perdido, se debe volver a compartir, lo que se planea para una versión posterior.

Cambios de configuración

Tanto las fallas de hardware (un TEE pierde datos) como los cambios organizacionales (una nueva contratación se une al protocolo con una parte de la clave secreta) requieren cambiar quién tiene las partes de una clave. La computación multipartita planea admitir esto con un protocolo de uso compartido seguro que preserve las propiedades de solidez de DKLS23: una nueva parte maliciosa que participe en el uso compartido, como máximo, filtrará un recurso compartido del secreto, al igual que cualquier otra parte maliciosa.