Visão geral da segurança do Confidential Space

Neste documento, descrevemos os controles de segurança do Confidential Space e como o sistema é projetado para proteger contra uma ampla variedade de ameaças. O Confidential Space foi criado para permitir que as partes compartilhem dados confidenciais (por exemplo, dados regulamentados ou informações de identificação pessoal (PII)) com uma carga de trabalho, mantendo a confidencialidade e a propriedade dos dados. O Confidential Space ajuda a criar isolamento para que os dados fiquem visíveis apenas para a carga de trabalho e os proprietários originais dos dados.

Use o Confidential Space em cenários em que não é possível estabelecer confiança com o operador da carga de trabalho ou entre as partes originais que criaram os dados confidenciais. Por exemplo, instituições financeiras podem usar o Confidential Space para colaborar entre si e identificar fraudes ou analisar atividades de lavagem de dinheiro. Esse ambiente permite a análise em todos os conjuntos de dados do cliente, mantendo a privacidade do identidade do cliente.

Componentes de um sistema do Confidential Space

O Confidential Space usa um ambiente de execução confiável (TEE) projetado para liberar secrets somente para cargas de trabalho autorizadas. Um processo de atestado e uma imagem do SO reforçada ajudam a proteger a carga de trabalho e os dados que ela processa vindos de um operador não confiável.

Um sistema de Confidential Space tem três componentes principais:

  • Uma carga de trabalho: uma imagem conteinerizada com um SO reforçado, executada em um TEE baseado na nuvem. Use a Computação confidencial como o TEE que oferece isolamento de hardware e recursos de atestado remoto.
  • Um serviço de atestado: um provedor de token OpenID Connect (OIDC). Use esse serviço para verificar as cotas de atestado para o TEE e liberar tokens de autenticação. Os tokens contêm atributos de identificação para a carga de trabalho.
  • Um recurso protegido: um recurso de nuvem gerenciado, como uma chave do Cloud Key Management Service ou um bucket do Cloud Storage. O recurso é protegido por uma política de permissão que concede acesso a tokens de identidade federados autorizados. Uma etapa intermediária, usando pools da Identidade da carga de trabalho, transforma os tokens OIDC em tokens de identidade federados que o IAM pode consumir.

O sistema ajuda a garantir que o acesso a recursos protegidos seja concedido apenas a cargas de trabalho autorizadas. Além disso, o Confidential Space ajuda a proteger a carga de trabalho contra inspeção e adulteração, antes e depois da atestado.

Em um sistema do Confidential Space, há três partes:

  • O autor da carga de trabalho, que cria uma imagem conteinerizada que inclui um aplicativo com acesso aos recursos protegidos. O autor não tem acesso aos dados ou resultados. Além disso, o autor não controla o acesso aos dados ou aos resultados.
  • O operador de carga de trabalho, que executa a carga de trabalho em um projeto do Google Cloud. O operador normalmente tem privilégios administrativos totais no projeto. O operador pode gerenciar recursos do Google Cloud, como instâncias do Compute Engine, discos e regras de rede, além de interagir com qualquer API Google Cloud que funcione neles. O operador não tem acesso aos dados ou aos resultados e não pode influenciar ou modificar o código ou o ambiente de execução. Além disso, o operador não controla o acesso aos dados ou aos resultados.
  • Os proprietários de recursos (ou colaboradores de dados), que são proprietários do recurso protegido. Um proprietário de recursos pode acessar os próprios dados, definir permissões nos próprios dados e acessar os resultados. Eles não podem acessar os dados de outros proprietários de recursos nem modificar o código por conta própria.

O Confidential Space é compatível com um modelo de confiança em que o autor da carga de trabalho, o operador da carga de trabalho e os proprietários dos recursos são partes separadas e mutuamente confiáveis.

O diagrama a seguir mostra os componentes e as partes do sistema. A carga de trabalho está localizada em um projeto separado do recurso protegido.

Sistema e componentes do Confidential Space

Exemplos de processamento de dados seguro

O Confidential Space ajuda a preservar a privacidade de um usuário ao compartilhar dados. A tabela a seguir descreve três casos de uso de exemplo.

Caso de uso Exemplo
Modelo de criptografia funcional Em um modelo de criptografia funcional, Alice quer compartilhar o resultado dos dados confidenciais com Bob, sem revelar todo o conjunto de dados. A Alice criptografa o conjunto de dados e protege a chave de criptografia de dados (DEK, na sigla em inglês) no Cloud KMS no projeto. Alice grava um programa que implementa a carga de trabalho e compartilha o binário com Bob. Alice configura o KMS para conceder ao programa acesso à DEK. A carga de trabalho é executada no Confidential Space de Bob, descriptografa e processa o conjunto de dados de Alice e grava o resultado no Cloud Storage de Bob.
Computação em várias partes Na computação com várias partes, Alice e Bob querem compartilhar o resultado entre si, preservando a confidencialidade dos conjuntos de dados de entrada. Assim como o modelo de criptografia funcional, Alice e Bob criptografam os respectivos conjuntos de dados e protegem as DEKs nas instâncias do Cloud KMS nos projetos. Eles são co-autores de um programa que determina os resultados e o executam em um Confidential Space. Alice e Bob configuram o KMS para dar ao programa acesso às DEKs. O programa lê e processa os dois conjuntos de dados e grava o resultado em um bucket compartilhado do Cloud Storage.
Compartilhamentos de chaves Um esquema mais complexo usa a ideia de compartilhamentos de chaves. Um compartilhamento de chaves é uma chave privada dividida entre Alice, Bob e outros proprietários, de modo que o conhecimento de compartilhamentos individuais não concede acesso ao conjunto de dados criptografado. Nesse esquema, a confiança é dividida em vários proprietários. A chave privada é montada somente em um TEE restrito, por uma carga de trabalho autorizada.

Nesses exemplos, apenas a carga de trabalho tem acesso ao conjunto de dados criptografado e pode processá-lo. O Confidential Space ajuda a garantir que uma pessoa não poderá realizar operações não auditadas em dados que não pertençam a ela. Os proprietários de dados controlam como os próprios dados são usados e quais cargas de trabalho têm autorização para agir com base neles.

Como proteger a integridade e a confidencialidade de uma carga de trabalho

Para ajudar a proteger a carga de trabalho de um operador não confiável, o Confidential Space implementa os seguintes controles de segurança:

  • Um processo de atestado detecta modificações na imagem da carga de trabalho ou no TEE dela. Esse controle ajuda a proteger a integridade da carga de trabalho antes do atestado.
  • Uma imagem de base reforçada ajuda a reduzir a superfície de ataque e impede que o operador da carga de trabalho acesse ou comprometa a instância no momento da execução. Esse controle ajuda a proteger a integridade e a confidencialidade de uma carga de trabalho após o atestado. Juntos, esses controles de segurança ajudam a proteger a carga de trabalho, os secrets e os dados que ela processa.

Processo de atestado

O processo de atestado é baseado na medida da VM protegida da inicialização e na execução estendida. Esse processo captura as medidas de sequência de inicialização em um registro protegido e somente de extensão no dispositivo virtual Platform Trusted Module (vTPM).

As medições abrangem os componentes de inicialização antecipada, o kernel carregado e a imagem do contêiner. Além disso, elas incluem propriedades de ambiente, como uma sinalização que indica que a instância é uma VM confidencial. O vTPM assina ou mede essas medições usando uma chave de atestado certificada que é confiável para o serviço de atestado.

O diagrama a seguir mostra os componentes de um sistema de Confidential Space e como cada componente participa do processo de atestado.

Os componentes e partes do sistema no processo de atestado.

O processo de atestado depende dos seguintes componentes:

  • Firmware convidado: um componente imutável que é uma parte confiável do Google Cloud.
  • Imagem do Confidential Space atestada: uma imagem reforçada com base no Container-Optimized OS, lida do disco de inicialização anexado.
  • Componentes de inicialização antecipados: carregadores de inicialização e kernels que interagem com o vTPM para medir os componentes de inicialização em um registro de configuração de plataforma (PCR, na sigla em inglês).

  • Acesso rápido: um componente que faz o download do binário da carga de trabalho pelo repositório de imagens e mede o contêiner e a configuração dele em um PCR. O inicializador lê a configuração do servidor de metadados da instância.

  • Código de manipulação de atestado: código responsável por preparar uma cota de PCR e retornar a cota da vTPM, a chave de atestado e o log de eventos completo.

  • O serviço de atestado: um serviço que verifica a cota, reproduz o log de eventos, emite o token OIDC e retorna o token com os atributos para a política de acesso à carga de trabalho.

Imagem reforçada

A imagem do Confidential Space é um SO mínimo com uma única finalidade. A imagem executa o inicializador de contêineres, que por sua vez inicia um único contêiner. A imagem do Confidential Space é baseada nas melhorias atuais de segurança do Container-Optimized OS e adiciona os seguintes benefícios:

  • Partições de disco criptografadas com proteção de integridade: a imagem do Confidential Space inclui as seguintes partições:
    • Uma partição root-fs e uma partição de OEM que inclui o binário do inicializador. Essas partições são imutáveis e protegidas por dm-verity.
    • Uma partição gravável temporária que armazena o binário da carga de trabalho transferido por download. dm-crypt criptografa e protege a integridade dessa partição.
    • Uma partição tmp-fs que é mapeada para RAM. Em um TEE da VM confidencial, a memória da VM é criptografada. Além disso, o sistema swap-fs está desativado, o que ajuda a impedir que um sistema operacional configurado incorretamente armazene dados no disco.
  • Conexões de rede autenticadas e criptografadas: a tela de início usa a TLS para autenticar o serviço de atestado e proteger os links de comunicação.
  • Várias medidas de inicialização: incluem os argumentos de linha de comando do kernel, a configuração dm-verity do root-fs e o binário da carga de trabalho.

  • Acesso remoto desativado e ferramentas específicas da nuvem: essas ferramentas incluem sshd e Login do SO.

  • Transições de estado reduzidas: or exemplo, o inicializador executa um único contêiner e é encerrado.

Modelo de ameaças e mitigações

Esta seção descreve os modelos de ameaça que o Confidential Space ajuda a mitigar e os novos riscos introduzidos por ele.

Os seguintes ataques estão fora do escopo deste documento:

  • Ataques de cadeia de suprimentos de software que se aplicam ao firmware da Interface unificada de firmware unificada (UEFI, na sigla em inglês) convidado, ao carregador de inicialização e ao kernel da imagem do Confidential Space, ao ambiente de execução do contêiner e às dependências de terceiros da carga de trabalho. Os colaboradores de dados presumem que os proprietários dos recursos revisaram e auditaram a imagem do contêiner antes que esses proprietários os compartilhassem com uma política de permissão.
  • Ataques no Google Cloud, como escapes de VM.

Possíveis ataques

O Confidential Space foi projetado para oferecer proteção contra três possíveis ataques:

  • Um operador malicioso de carga de trabalho: esse tipo de ataque visa modificar o conteúdo do disco, interceptar conexões de rede e tentar comprometer o TEE no ambiente de execução. Um operador malicioso pode expandir a superfície de ataque ou restringir o ambiente de execução. Por exemplo, ele pode adicionar um console serial para introduzir novos vetores de ataque. Outro exemplo: um operador malicioso pode restringir recursos, como limitar o tamanho da memória e mudar o espaço em disco de um convidado ou mudar as regras de firewall. Essas restrições podem acionar erros de E/S que podem levar a casos de erro testados incorretamente.
  • Um cliente malicioso de atestado: esse invasor se conecta ao serviço de atestado e envia mensagens de registro de evento assinadas, porém malformadas.
  • Proprietário malicioso de recursos: esse tipo de invasor tem controle total sobre o conjunto de dados criptografado que a carga de trabalho consome. Ele pode exibir entradas malformadas ou dados distorcidos e tentar acionar vulnerabilidades de análise na carga de trabalho ou tentar burlar os controles de privacidade.

Plataformas de ataque

A tabela a seguir descreve as plataformas de ataque disponíveis para invasores.

invasor Objetivo Plataforma de ataque Riscos
Operador de carga de trabalho TEE, carga de trabalho Leituras de disco

Tudo que é lido no disco está sob o controle do invasor.

Serviços como discos permanentes de vários gravadores e anexos dinâmicos de discos significam que um invasor pode modificar o conteúdo do disco dinamicamente e a qualquer momento.
Operador de carga de trabalho TEE, carga de trabalho Gravações de disco Tudo que é gravado no disco fica visível para um invasor. Veja os recursos de snapshots do disco e importação.
Operador de carga de trabalho TEE, carga de trabalho Servidor de metadados Os atributos da instância lidos no servidor de metadados estão sob o controle do invasor, incluindo o script de inicialização e as variáveis de ambiente.
Operador de carga de trabalho TEE, carga de trabalho Rede Conexões de rede externas ao repositório de imagens ou serviço de atestado podem ser interceptadas. Esse ataque é feito usando uma VPC particular com uma instância do Cloud Router voltada para o público.
Cliente de atestado Serviço de atestado Log de eventos e mensagens de atestado O serviço de atestado tem uma lógica complexa e com criptografia cuja defesa é difícil de escrever.
Proprietário do recurso Carga de trabalho Conjunto de dados criptografado

Um invasor pode envenenar os conjuntos de dados de entrada da carga de trabalho, o que significa que os dados criptografados não são necessariamente confiáveis.

Infraestrutura do Google Cloud

O Google Cloud inclui o hipervisor do Compute Engine, o vTPM para a VM confidencial, o firmware UEFI de convidado e um serviço de atestado hospedado. Materials confidenciais de chaves, como chaves de assinatura vTPM e OIDC, são projetados para serem protegidos com segurança.

A infraestrutura do Google é projetada para isolar logicamente os dados de cada cliente dos dados de outros clientes e usuários, mesmo quando armazenados no mesmo servidor físico. O acesso administrativo à equipe de suporte e aos engenheiros é limitado, auditado e transparente para os clientes. Além disso, a criptografia de memória in-line em VMs confidenciais ajuda a proteger a confidencialidade da memória da instância. A criptografia de memória in-line torna a inspeção direta ou a geração de registros de memória acidental (registro de falhas do kernel) ineficazes. Para mais informações sobre como protegemos nossa plataforma, consulte a Visão geral de segurança do Google.

Ameaças e mitigações

Um sistema de arquivos criptografado com proteção de integridade foi projetado para reduzir os riscos de ataques ao disco. Além disso, quando o código é lido do disco, ele é medido e os dados nunca são lidos novamente do disco. As chaves secretas nunca são divulgadas em formato de texto simples para o disco ou para qualquer dispositivo externo, como um console serial.

Os riscos dos ataques de rede são minimizados com canais criptografados autenticados de ponta a ponta. O acesso de rede externo, como o SSH, está desativado na imagem. Um protocolo de atestado ajuda a proteger a sequência de inicialização e qualquer configuração lida do servidor de metadados. Por fim, as cargas de trabalho do Confidential Space precisam usar controles de privacidade diferencial para reduzir os riscos de conjuntos de dados distorcidos.

As tabelas a seguir descrevem as ameaças e as mitigações:

Ataques no processo de inicialização medida

Esta tabela descreve possíveis ameaças e estratégias de mitigação relacionadas ao processo de inicialização medida.

Ameaça Mitigação Implementação da mitigação

Um invasor inicializa uma VM protegida com um firmware antigo que não é compatível com a inicialização medida.

Se for bem-sucedido, um invasor poderá reproduzir medições arbitrárias e anular o atestado remoto.

Essa ameaça é reduzida pelo plano de controle do Google Cloud.

O Confidential Space adiciona um dispositivo vTPM e um firmware UEFI atualizado. Além disso, o Confidential Space permite a inicialização medida, que não pode ser desativada.

 Na infraestrutura do Google Cloud

Um invasor substitui o firmware UEFI na memória física do convidado, reinicializa o convidado, redefine os registros vTPM e executa o firmware modificado.

Se for bem-sucedido, um invasor poderá reproduzir medições arbitrárias e anular o atestado remoto.

 Essa ameaça é mitigada pelo hipervisor. Na reinicialização do convidado, o hipervisor carrega uma cópia limpa do firmware UEFI para a memória do convidado. As modificações anteriores na memória do convidado são descartadas. Além disso, a reinicialização do convidado é o único evento que redefine o vTPM. No Google Cloud e por você ao ativar a Computação confidencial
Um invasor modifica arquivos de configuração não medidos, o que afeta negativamente a execução do programa.

Essa ameaça é mitigada pelo processo de atestado. Todos os binários executáveis e os respectivos arquivos de configuração são totalmente medidos antes da execução.

Em particular, as variáveis de inicialização segura, a configuração do grub e os argumentos da linha de comando do kernel são medidos.

A análise de segurança descobriu que nenhuma medição foi perdida no processo de atestado.

 Na imagem do Confidential Space
Um invasor aciona vulnerabilidades de corrupção de memória em componentes da inicialização antecipada e ganha a execução do código.

Os componentes da inicialização antecipada são escritos na linguagem C. Esses componentes processam dados não confiáveis dos usuários e podem estar vulneráveis a problemas de corrupção de memória. Para ver um exemplo recente, consulte BootHole.

Esse risco é mitigado pelo processo de atestado: os componentes da inicialização antecipada precisam medir todos os dados controlados pelo usuário antes de processá-los. Um ataque BootHole usa um grub.cfg modificado para conseguir a execução do código e impedir a inicialização segura.

No entanto, em um sistema do Confidential Space, esse ataque não transmite o atestado, já que as medidas de grub.cfg não correspondem à configuração esperada.

Um risco relacionado vem da lógica complexa do sistema de arquivos. Vulnerabilidades anteriores, como a Sequoia, demonstram que os drivers do sistema de arquivos processam estruturas de dados complexas e podem ser vulneráveis a problemas de corrupção de memória.

Esse risco é mitificado usando a proteção de integridade dm-verity e dm-crypt de nível de bloco, além de desativar as montagens automáticas.

Na imagem do Confidential Space
Um invasor modifica os binários de inicialização antecipada no disco depois de serem lidos e medidos, antes de serem lidos e executados (disco TOCTOU).

Os componentes de inicialização antecipada foram criados para máquinas bare metal e podem não esperar pelo ambiente dinâmico da nuvem. Os componentes de inicialização podem presumir que o conteúdo do disco não pode mudar durante a execução, o que é uma suposição incorreta para ambientes de nuvem.

Esse risco é minimizado com o uso da programação defensiva: o conteúdo do disco é lido apenas uma vez usando o padrão de leitura, medição e execução.

A análise de segurança da imagem do Confidential Space não identificou problemas TOCTOU nos componentes de inicialização antecipada, como UEFI, Shim ou GNU GRUB.

 Na imagem do Confidential Space
Um invasor modifica drivers de dispositivo e serviços de modo do usuário no disco após o carregamento do kernel.

Essa ameaça é reduzida por um sistema de arquivos raiz com proteção de integridade.

Root-fs na imagem do Confidential Space tem a integridade protegida por dm-verity. A configuração (root-hash) é transmitida em um argumento de comando do kernel e medida e atestada pelo serviço de atestado.

 Na imagem do Confidential Space

Ataques no inicializador do contêiner

Esta tabela descreve possíveis ameaças e estratégias de mitigação relacionadas ao inicializador.

Ameaça Mitigação Implementação da mitigação
Um invasor intercepta a conexão de rede do inicializador ou do repositório de imagens.

A conexão com o repositório de imagens é protegida por uma conexão TLS criptografada e autenticada.

Um invasor pode alterar o URL da imagem e controlar o binário da carga de trabalho. Porém, essas ações são refletidas no registro de atestado.

O repositório de imagens não é controlado por uma lista de acesso. Portanto, a imagem é considerada visível por todos. Verifique se a imagem do contêiner da carga de trabalho não contém secrets.

 Na imagem do Confidential Space
Um invasor modifica a imagem da carga de trabalho no disco após o download e a medição dela.

Essa ameaça é mitigada por uma partição gravável criptografada e com integridade protegida.

A imagem da carga de trabalho e os dados temporários dela são protegidos por dm-crypt usando chaves temporárias por inicialização.

O processo de criptografia de disco dm-crypt permite ataques de reversão, em que um invasor substitui o conteúdo do disco por tags e textos criptografados vistos anteriormente. Esses ataques são considerados altamente complexos nas configurações do Confidential Space.

 Na imagem do Confidential Space
Um invasor modifica a configuração do inicializador no servidor de metadados e controla o URL do repositório de imagens. O processo de atestado detecta configurações não seguras que carregam imagens não autênticas. No serviço de atestado

Ataques no serviço de atestado

Esta tabela descreve possíveis ameaças e estratégias de mitigação relacionados ao serviço de atestado.

Ameaça Mitigação Implementação da mitigação
Um invasor intercepta a conexão de rede do inicializador ou do serviço de atestado e lê o token secreto do fio.

Essa ameaça é mitigada com uma conexão TLS criptografada e autenticada. Essa conexão ajuda a proteger o token contra espionagem passiva.

Um invasor não pode representar o serviço porque não tem a chave TLS. Mesmo que seja bem-sucedido, o invasor não pode criar tokens OIDC válidos.

Um invasor não pode representar um cliente válido porque a identidade do cliente é garantida pelo protocolo de atestado.

 Na rede entre a carga de trabalho e o serviço de atestado.
Um invasor explora as discrepâncias de análise, o que leva a alterações não detectadas no processo de atestado.

Essa ameaça pode ocorrer porque o registro de eventos de medições é serializado e enviado para o serviço de atestado, em que é analisado e processado.

Uma discrepância de análise acontece quando o serviço e o SO do ambiente de execução não concordam com a semântica do registro.

Por exemplo, se o campo cmdline tiver uma lista de argumentos separados por uma vírgula, uma string como a=1, b=2 c='3,d=e' (observe o ,d na substring de valor) pode ser analisada de forma diferente pelo kernel e pelo serviço.

Esse risco é minimizado com um mecanismo de análise que reflete corretamente o comportamento do SO. Em particular, o cmdline é processado como uma string inteira e não é dividido em pares de chave-valor.

 Na imagem do Confidential Space
Um invasor usa todos os recursos de serviço, o que coloca o serviço em um ataque de negação de serviço (DoS). O serviço é interrompido para outros usuários do Confidential Space.

Esse risco de confiabilidade é mitigado com um serviço distribuído e elástico que pode ser facilmente replicado e escalonado horizontalmente conforme necessário.

O código impede o esgotamento de recursos por clientes maliciosos.

 Na carga de trabalho

Ataques em cargas de trabalho

Esta tabela descreve possíveis ameaças e estratégias de mitigação relacionadas a cargas de trabalho.

Ameaça Mitigação Implementação da mitigação
Um invasor lê os secrets do ambiente de execução a partir da partição gravável.

Essa ameaça é mitigada com um sistema de arquivos criptografado. O sistema de arquivos gravável é ativado usando dm-crypt. A troca está desativada, e o conteúdo da memória não é paginado no disco.

Como técnica de defesa profunda, os tokens OIDC têm escopo e curta duração.

 Na imagem do Confidential Space
O invasor lê os secrets do ambiente de execução no console serial. Essa ameaça é reduzida na imagem do Confidential Space porque as credenciais e os tokens nunca são impressos no console serial. Além disso, o Cloud Logging está desativado. Na imagem do Confidential Space
Um invasor atualiza as chaves SSH autorizadas usando o pacote OSLogin e se conecta à instância em execução. Essa ameaça é mitigada na imagem do Confidential Space porque os serviços systemd padrão são mascarados, incluindo sshd. Na imagem do Confidential Space
Um invasor atualiza os scripts de inicialização no servidor de metadados, que são carregados automaticamente pelo agente convidado. Essa ameaça é mitigada na imagem do Confidential Space porque o pacote do agente convidado está desativado. Na imagem do Confidential Space
Um invasor envia pacotes inválidos para a VM usando o agente de configuração do SO. Essa ameaça é reduzida na imagem do Confidential Space porque o agente de configuração do SO está desativado. Na imagem do Confidential Space
Um invasor transmite um conjunto de dados criptografado e malformado para a carga de trabalho. Essa ameaça é mitigada ao ter um código de análise defensivo na carga de trabalho. Na carga de trabalho
Um invasor transmite um conjunto de dados distorcido ou envenenado para a carga de trabalho e tenta aprender informações sobre os conjuntos de dados de outras partes. Essa ameaça é mitigada com a implementação de controles de privacidade diferencial na carga de trabalho. Na carga de trabalho

Testes de segurança

O Confidential Space passou por um processo abrangente de análise de segurança no Google. Esse processo de análise de segurança incluía os seguintes testes e auditorias:

  • Testes de integração completos de fluxo negativo

    Esses testes verificaram se o atestado falha em medições incorretas, por exemplo, quando o código é executado em um ambiente TEE inesperado ou inicia um contêiner de carga de trabalho modificado.

  • Auditoria manual do processo de inicialização medida

    Essa revisão se concentra na identificação de medições ausentes e de bugs de leitura dupla. Os testes verificaram se o código foi escrito com as práticas recomendadas de segurança e, em caso de falha, encerraram (desligaram) o código.

  • Auditoria manual do processo de compilação da imagem do Confidential Space e da lógica da tela do inicializador:

    Esta revisão se concentrou na remoção de pacotes e na redução da superfície de ataque.

  • Auditoria manual do serviço de atestado

    Essa revisão se concentrou na implementação do protocolo de atestado correto e em evitar problemas de análise.

  • Análise criptográfica por especialistas em segurança cibernética

    Esta revisão se concentrou no protocolo de atestado, na criptografia do sistema de arquivos e nas soluções de integridade.

  • Análise de privacidade feita por especialistas

    O foco dessa revisão são os controles de privacidade diferencial em cargas de trabalho criadas pelo Google.

  • Testes de fuzz contínuos

    Esses testes abordaram componentes críticos de segurança, como o vTPM e o serviço de atestado.

O NCC Group, uma organização externa de pentesting, realizou testes de penetração no sistema. O NCC analisou o Confidential Space como uma plataforma de computação segura.

A seguir