Arquitetura de computação multipartidária

Google Cloud A computação multipartidária oferece uma infraestrutura de confiança criptográfica para operações institucionais de ativos digitais. Ele usa uma arquitetura de locatário único múltiplo: cada instância criada é um ambiente dedicado e isolado com a própria entrada de rede, o próprio armazenamento e a própria computação isolada por hardware para operações criptográficas.

Principais componentes

Diagrama de arquitetura de computação multipartidária

Cada instância de computação multipartidária tem três componentes principais. A lógica de governança, o roteamento de solicitações e os cálculos criptográficos são executados em componentes separados.

API MPC

A API Multi-party Compute gerencia os seguintes recursos:

  • Usuários e equipes: as identidades que têm papéis na instância e os grupos de signatários aos quais as políticas de chaves se referem.
  • KeyRings e KeyPolicies: os KeyRings que agrupam chaves, cada um com a política de chave que decide quais equipes e usuários têm compartilhamentos de chaves e quantos deles precisam aprovar uma assinatura.
  • TransactionPolicies: as regras do Cedar que permitem ou proíbem transações e as aprovações do autor da política que as ativam ou desativam.
  • KeyLists: as listas nomeadas de endereços que as políticas de transação podem consultar.

A API de computação multipartidária rastreia o estado de cada transação e as aprovações registradas nela, além de pedir ao coordenador para organizar a geração e a assinatura de chaves. O Spanner armazena as solicitações e as aprovações assinadas. Os TEEs de worker verificam as assinaturas de aprovação antes de agir com base nelas.

Coordenador

A API de computação multipartidária conecta o controlador aos TEEs dos participantes:

  • Detecção de compartilhamento de chaves e roteamento de solicitações: atribui TEEs íntegros para armazenar novos compartilhamentos de chaves durante a geração de chaves e, em seguida, encaminha a solicitação para os TEEs apropriados.
  • Integridade: monitora a integridade dos TEEs dos participantes e funciona como um balanceador de carga para as solicitações de assinatura.
  • Durabilidade: gerencia o compartilhamento quando uma chave precisa ser substituída.

O coordenador não afeta a segurança do protocolo. Ele não contém compartilhamentos de chaves e não verifica aprovações ou resultados de políticas. Essa verificação acontece dentro dos TEEs dos participantes.

TEEs de worker

Cada worker é um TEE executado no Confidential Space. Um TEE de worker executa duas partes:

  • Mecanismo criptográfico: contém compartilhamentos de chaves e executa os protocolos de assinatura e geração de chaves de limite seguro com os outros TEEs de worker.
  • Avaliador de políticas: avalia as transações em relação ao conjunto ativo de políticas de transação.

Fluxo de assinatura de transações

Na computação multipartidária, você assina um payload com uma única chamada de API, CreateTransaction. A avaliação da política de transação, as aprovações do signatário e a assinatura de limite começam com essa chamada. Este é o fluxo em uma ordem fixa:

  1. Solicitação. Um Signer chama CreateTransaction em uma chave. A solicitação contém a aprovação do próprio Signatário, assinada com a chave de autorização dele. O IAM verifica se o autor da chamada pode chamar o método, e a solicitação é registrada nos Registros de auditoria do Cloud.
  2. Avaliação da política. A transação é avaliada em relação ao conjunto ativo de políticas de transação. A avaliação da política produz um registro de auditoria durável para cada veredito, seja APPROVED ou REJECTED.
  3. Aprovação do iniciador. Se a aprovação do iniciador atender aos limites da política de chaves, o CreateTransaction vai para a Etapa 5 imediatamente.
  4. Aprovações de signatários. Se a aprovação do iniciador não atender aos limites da política de chaves, a transação vai entrar no estado PENDING_AUTHORIZATION. Outros signatários que têm partes da chave aprovam ou negam a transação usando a chamada RecordSignerDecision, cada uma assinada com a chave de autorização deles. A transação aguarda no estado PENDING_AUTHORIZATION até que um número suficiente de Signatários aprove para atender aos limites da política de chaves. Se um número suficiente de Signatários negar a transação de modo que os limites não possam mais ser atingidos, ela será movida para o estado REJECTED. Se não receber aprovações suficientes antes do prazo de validade, ela será EXPIRED.

  5. Assinatura de limite. Quando os limites são atingidos, os ambientes de execução confiáveis (TEEs) que contêm as partes da chave executam o protocolo de assinatura de limite e produzem a assinatura na transação.

    Antes de um TEE participante usar o compartilhamento de chaves, ele verifica se o payload exato que precisa ser assinado foi avaliado de acordo com suas políticas de transação. Nenhum cliente, operador ou outro componente de serviço pode fazer com que um participante assine um payload que não foi avaliado.

Para os recursos envolvidos, como usuários, equipes, KeyRings e políticas de transação, consulte a visão geral da computação multipartidária.

Modelo de segurança

  • Compartilhamentos de chaves fixados no TEE. Cada compartilhamento de chave só pode ser lido somente leitura pelo TEE que o criou. As partes de chave nunca saem desse TEE em um formato que outro componente, incluindo o coordenador, o controlador ou um operador do Google, possa ler.
  • Custódia de chaves do cliente. O cliente mantém a custódia total das chaves de criptografia o tempo todo usando o Cloud Key Management Service na organização do Google Cloud cliente.
  • Isolamento de hardware. Os TEEs dos participantes são executados no Confidential Space, que usa criptografia de memória de hardware para proteger os dados em uso do host e da infraestrutura do Google. O atestado vincula cada TEE a uma imagem de contêiner verificada.
  • Criptografia de ponta a ponta. Os TEEs de worker se comunicam diretamente por gRPC criptografado de ponta a ponta.
  • Aprovações assinadas. Os signatários, autores de políticas e administradores assinam as aprovações com uma chave de autorização que tem uma metade privada que nunca sai do controle deles. Os TEEs dos participantes verificam essas assinaturas antes de assinar uma transação, aceitar uma política de transação ou aceitar uma mudança de função de administrador ou autor de política. Isso torna as transações à prova de adulteração e deixa um registro de auditoria durável.
  • Quórum do autor da política. Uma nova política de transação ou uma solicitação para desativar uma só entra em vigor depois que o número necessário de autores de política a aprova.
  • Quórum de administrador. A concessão ou remoção da função de administrador ou autor de políticas só entra em vigor depois que o número necessário de administradores a aprova. Para mais informações, consulte Aprovação do administrador para mudanças de função.

Roteiro

Os seguintes recursos estão planejados para versões futuras:

  • TEEs externos: compartilhamentos de chaves mantidos em TEEs que os clientes executam fora do Google Cloud, como os AWS Nitro Enclaves.
  • Compartilhamentos de chaves em dispositivos móveis: compartilhamentos de chaves mantidos nos dispositivos móveis dos usuários.
  • Recompartilhamento: mudar quem detém as partes de uma chave ou substituir uma parte perdida sem mudar a chave.

Propriedades do sistema

A infraestrutura de confiança da computação multipartidária mantém as seguintes propriedades do sistema.

Segurança (solidez em um contexto criptográfico)

Em todas as circunstâncias, o sistema não pode se comportar de maneira não permitida. Por exemplo, nenhum grupo com menos de k participantes, em virtude do protocolo DKLS23, é capaz de falsificar assinaturas. As definições exatas de segurança são formalizadas no framework Universal Composable na literatura.

Quando um sistema criptográfico é incorporado em uma implementação prática, é preciso tomar cuidado para não confiar em suposições que prejudiquem as propriedades de segurança. Por exemplo, cada parte no protocolo precisa ser independente: a suscetibilidade de cada uma a ser comprometida deve ser independente.

Para garantir essa propriedade, a computação multipartidária executa cada participante em um TEE atestado, e cada compartilhamento de chave é fixado no TEE que o criou. O comprometimento de um participante no protocolo não afeta os outros participantes.

A literatura acadêmica sobre computação multipartidária se concentra quase exclusivamente na integridade e pressupõe um mundo simplista em que o conjunto de partes é imutável, todas as partes estão sempre disponíveis e se comunicam usando canais autenticados ponto a ponto ideais e sempre disponíveis. Para um produto real, é preciso abordar várias outras questões.

Atividade

O sistema acaba progredindo. A propriedade de atividade mais comum é a ausência de deadlock, que é mantida no protocolo DKLS23. Uma chave de limite pode ser usada para assinatura, desde que um número suficiente de TEEs que contêm as partes dela esteja disponível para atender aos limites da política de chaves. Por exemplo, com uma chave de 2 de 3, qualquer 2 das 3 partes podem concluir uma assinatura.

Durabilidade

As partes que falham permanentemente precisam ser substituídas. Caso contrário, o sistema acaba perdendo a chave secreta compartilhada de forma permanente. Por exemplo, quando o hardware falha, o estado do participante em execução nesse hardware é perdido. Como as partes de chave são fixadas nos TEEs, o coordenador rastreia quais TEEs contêm as partes de cada chave. Na v1beta, uma chave permanece utilizável enquanto houver compartilhamentos suficientes para atender aos limites da política de chaves. Para substituir um compartilhamento perdido, é necessário compartilhar novamente, o que está planejado para uma versão futura.

Alterações de configuração

Tanto as falhas de hardware (um TEE perde dados) quanto as mudanças organizacionais (um novo funcionário entra no protocolo com uma parte da chave secreta) exigem a mudança de quem detém as partes de uma chave. A computação multipartidária planeja oferecer suporte a isso com um protocolo de recompartilhamento seguro que preserva as propriedades de integridade do DKLS23: uma nova parte mal-intencionada que se envolve no recompartilhamento vaza, no máximo, uma parte do segredo, assim como qualquer outra parte mal-intencionada.