Este conteúdo foi atualizado pela última vez em outubro de 2023 e representa o estado do momento em que foi escrito. Os sistemas e as políticas de segurança do Google podem mudar no futuro, à medida que a proteção dos clientes é aprimorada.
Neste documento, descrevemos os controles de infraestrutura que o Google usa para garantir a integridade do processo de inicialização em máquinas de produção. Esses controles, criados com base em um processo de inicialização medida, ajudam a garantir que o Google recupere as máquinas de data center de vulnerabilidades por toda a pilha de inicialização e as retorne da inicialização para configurações válidas.
Introdução
A postura de segurança de uma máquina de data center é estabelecida no momento da inicialização. O processo de inicialização configura o hardware da máquina e inicializa o sistema operacional dela, mantendo a máquina segura para ser executada no ambiente de produção do Google.
Em cada etapa do processo de inicialização, o Google implementa controles líderes do setor para ajudar a aplicar o estado de inicialização esperado e manter os dados do cliente seguros. Esses controles ajudam a garantir que nossas máquinas sejam inicializadas no software pretendido, permitindo a remoção de vulnerabilidades que possam comprometer a postura inicial de segurança da máquina.
Neste documento, descrevemos o processo de inicialização e demonstramos como nossos controles funcionam em cada etapa do fluxo de inicialização.
Experiência
Esta seção define e fornece contexto para os termos credenciais da máquina, raiz de confiança de hardware, credenciais seladas e bloqueio criptográfico.
Credenciais da máquina
Um dos componentes centrais do sistema de gerenciamento de máquinas do Google é a nossa infraestrutura de credenciais, que consiste em uma autoridade de certificação (CA, na sigla em inglês) interna e outros elementos do plano de controle responsáveis por coordenar os fluxos de rotação de credenciais.
As máquinas da frota de produção do Google realizam autenticação mútua ao estabelecer canais seguros. Para realizar a autenticação mútua, cada máquina possui as chaves públicas da CA do Google. Cada máquina também possui o próprio par de chaves públicas/privadas, além de um certificado para esse par.
O par de chaves pública/privada de cada máquina, junto com o certificado assinado pela CA, é conhecido como credencial da máquina, usada para se autenticar em outras máquinas da frota. Dentro da rede de produção, as máquinas verificam se as chaves públicas de outras máquinas são certificadas pela CA do Google antes de trocar o tráfego.
Raízes de confiança de hardware e bloqueio criptográfico
À medida que os dispositivos de computação ficam mais sofisticados, a superfície de ataque de cada dispositivo também cresce. Por isso, os dispositivos têm cada vez mais raízes de confiança de hardware (RoTs, na sigla em inglês), que são ambientes de execução pequenos e confiáveis que protegem dados confidenciais da máquina. As RoTs também aparecem em dispositivos móveis, como laptops ou celulares, e em dispositivos mais convencionais, como computadores desktop.
As máquinas dos data centers do Google apresentam raízes de confiança de hardware personalizadas projetadas pelo Google e integradas às camadas mais profundas de cada máquina, conhecidas como Titan. Usamos o Titan com um mecanismo chamado bloqueio criptográfico para garantir que cada máquina esteja executando a configuração e as versões de software esperadas.
A selagem criptográfica é semelhante à vedação com um Módulo de plataforma confiável (TPM, na sigla em inglês), uma especificação que foi publicada pelo Grupo de computação confiável, mas o bloqueio criptográfico tem algumas vantagens adicionais. O Titan oferece uma capacidade melhor de medir e atestar para o firmware de baixo nível.
O bloqueio criptográfico abrange os dois controles a seguir:
- Criptografia de dados confidenciais
- Política que precisa ser satisfeita antes que os dados possam ser descriptografados
Credenciais seladas
A infraestrutura de credenciais do Google usa bloqueio criptográfico para criptografar credenciais de máquina em repouso com uma chave controlada pela raiz de confiança de hardware da máquina. A chave privada da credencial criptografada e o certificado correspondente são conhecidos como credencial selada. Além das credenciais de máquina, o Google também usa esse mecanismo de bloqueio para proteger outros dados confidenciais.
Cada máquina só poderá descriptografar e acessar a credencial da máquina se atender a uma política de descriptografia que especifique o software que precisa ter sido inicializado. Por exemplo, o fechamento da credencial de uma máquina para uma política que especifica a versão desejada do kernel do sistema operacional garante que a máquina não possa participar do cluster da máquina, a menos que tenha inicializado a versão necessária do kernel.
A política de descriptografia é aplicada com um processo chamado inicialização medida. Cada camada mede a próxima camada, e a máquina atesta essa cadeia de medidas no final da inicialização. Essa medição geralmente é um hash criptográfico.
Processo de bloqueio de credenciais
Nesta seção, descrevemos o processo de bloqueio de credenciais e de inicialização medida usado pelas máquinas do Google. Veja esse fluxo no diagrama a seguir.
Para selar as credenciais de uma máquina a uma política de inicialização específica, são realizadas as seguintes etapas:
- A infraestrutura de automação da máquina do Google inicia uma atualização de software na máquina. Ela transmite as versões de software pretendidas para a infraestrutura de credenciais.
- A infraestrutura de credenciais do Google solicita uma chave de bloqueio do Titan, vinculada à política, para que o Titan a use somente se a máquina for inicializada no software pretendido.
- A infraestrutura de credenciais compara a política da chave retornada com a intent comunicada pela infraestrutura de automação da máquina. Se a infraestrutura de credenciais estiver satisfeita de que a política corresponde à intent, ela emitirá uma credencial de máquina certificada para a máquina.
- A infraestrutura de credenciais criptografa essa credencial usando a chave de bloqueio adquirida na etapa 2.
- A credencial criptografada é armazenada no disco para descriptografia por Titan nas inicializações subsequentes.
Processo de Inicialização medida
A pilha de inicialização das máquinas do Google consiste em quatro camadas, que são mostradas no diagrama a seguir.
As camadas são as seguintes:
- Espaço do usuário: aplicativos como daemons ou cargas de trabalho
- Software do sistema: um hipervisor ou kernel. O nível mais baixo de software que fornece uma abstração sobre recursos de hardware, como rede, sistema de arquivos ou memória virtual para o espaço do usuário.
- Firmware de inicialização: o firmware que inicializa o kernel, como um BIOS e um carregador de inicialização.
- Raiz de confiança de hardware: nas máquinas do Google, um chip Titan que mede criptograficamente o firmware e outros serviços de CPU de baixo nível.
Durante a inicialização, cada camada mede a próxima camada antes de passar o controle para ela. A credencial selada da máquina só será disponibilizada para o sistema operacional se todas as medições capturadas durante a inicialização estiverem em conformidade com a política de descriptografia da credencial selada, conforme especificado pela infraestrutura de credenciais do Google. Portanto, se a máquina puder executar operações com as credenciais seladas, isso é uma evidência de que a máquina atendeu à política de inicialização medida. Esse processo é uma forma de atestado implícito.
Se uma máquina inicializar um software que desvia do estado pretendido, ela não poderá descriptografar e executar operações com as credenciais necessárias para operar na frota. Essas máquinas não podem participar da programação de carga de trabalho até que a infraestrutura de gerenciamento de máquina acione ações de reparo automatizadas.
Como se recuperar de vulnerabilidades no kernel
Suponha que uma máquina esteja executando a versão A do kernel, mas os pesquisadores de segurança vão descobrir que essa versão do kernel tem uma vulnerabilidade. Nesses cenários, o Google corrige a vulnerabilidade e implanta uma versão atualizada do kernel B para a frota.
Além de corrigir a vulnerabilidade, o Google também emite novas credenciais para cada máquina na frota. Conforme descrito em Processo de bloqueio de credenciais, as novas credenciais de máquina são vinculadas a uma política de descriptografia que será satisfeita apenas se a versão B do kernel for inicializada na máquina. As máquinas que não estiverem executando o kernel pretendido não poderão descriptografar as novas credenciais da máquina, já que as medições do firmware de inicialização não atendem à política de inicialização da máquina. Como parte desse processo, as credenciais de máquina antiga também são revogadas.
Como resultado, essas máquinas não podem participar do cluster da máquina até que o kernel seja atualizado para estar em conformidade com a intent do plano de controle. Esses controles ajudam a garantir que as máquinas que executam a versão A do kernel vulnerável não recebam jobs ou dados do usuário até que sejam atualizadas para a versão B do kernel.
Como se recuperar de vulnerabilidades no firmware de inicialização
Suponha que haja uma vulnerabilidade no firmware de inicialização, em vez do kernel do sistema operacional. Os mesmos controles descritos em Recuperação de vulnerabilidades no kernel ajudam o Google a se recuperar dessa vulnerabilidade.
O chip Titan do Google mede o firmware de inicialização de uma máquina antes da execução para determinar se ele atende à política de inicialização da credencial da máquina. Qualquer máquina que não esteja executando o firmware de inicialização pretendido não poderá receber novas credenciais de máquina e essa máquina não poderá participar do cluster de máquina até que o firmware de inicialização esteja em conformidade com a intent do plano de controle.
Como se recuperar de vulnerabilidades no firmware da raiz de confiança
As RoTs não são imunes a vulnerabilidades, mas os controles de inicialização do Google permitem a recuperação de bugs mesmo nessa camada da pilha de inicialização, dentro do próprio código mutável da RoT.
A pilha de inicialização do Titan implementa um fluxo de inicialização seguro e medido próprio. Quando um chip Titan é ligado, o hardware dele mede criptograficamente o carregador de inicialização do Titan, que, por sua vez, mede o firmware do Titan. Assim como o kernel e o firmware de inicialização da máquina, o firmware Titan é assinado criptograficamente com um número de versão. O carregador de inicialização do Titan valida a assinatura e extrai o número da versão do firmware Titan, alimentando o número da versão para o subsistema de derivação de chaves do Titan.
O subsistema de hardware do Titan implementa um esquema de derivação de chaves com controle de versão, em que o firmware do Titan com a versão X pode receber chaves exclusivas do chip vinculadas a todas as versões menores ou iguais a X. O hardware Titan permite que o firmware com a versão X acesse chaves vinculadas a versões menores ou iguais a X, mas que não são maiores que X. Todos os secrets selados para o Titan, incluindo a credencial da máquina, são criptografados usando uma chave com controle de versão.
As chaves de atestado e selação são exclusivas para cada chip Titan. As chaves exclusivas permitem que o Google confie apenas nos chips Titan que precisam ser executados em um data center do Google.
O diagrama a seguir mostra o Titan com chaves de versão. A chave da versão X+1 não pode ser acessada pelo firmware da versão X, mas todas as chaves mais antigas podem ser acessadas.
No caso de uma vulnerabilidade grave no firmware do Titan, o Google implementa um patch com um número de versão maior e, em seguida, emite novas credenciais de máquina que estão vinculadas à versão mais recente do firmware do Titan. Qualquer firmware Titan mais antigo e vulnerável não consegue descriptografar essas novas credenciais. Portanto, se uma máquina executar operações com as novas credenciais em produção, o Google pode declarar com confiança que o chip Titan da máquina está executando o firmware Titan atualizado.
Garantia de autenticidade de confiança
Os controles descritos neste documento dependem da funcionalidade do RoT de hardware. A infraestrutura de credenciais do Google depende de assinaturas emitidas por esses RoTs para saber se a máquina está executando o software pretendido.
Portanto, é fundamental que a infraestrutura da credencial possa determinar se um RoT de hardware é autêntico e se ele está executando firmware atualizado.
Quando cada chip Titan é fabricado, ele é programado com entropia exclusiva. A rotina de inicialização de baixo nível do Titan transforma essa entropia em uma chave exclusiva do dispositivo. Um elemento de segurança na linha de fabricação Titan endossa essa chave exclusiva para que o Google a reconheça como um chip Titan legítimo.
O diagrama a seguir ilustra esse processo de endosso.
Durante a produção, o Titan usa a chave exclusiva do dispositivo para endossar qualquer assinatura emitida, usando um fluxo semelhante ao Mecanismo de composição do identificador do dispositivo (DICE, na sigla em inglês). A recomendação inclui informações sobre a versão do firmware do Titan. Esse atestado ajuda a evitar que um invasor falsifique a identidade de uma assinatura emitida por um chip Titan e volte para o firmware Titan mais antigo e falsifique a identidade dele. Esses controles ajudam o Google a verificar se as assinaturas recebidas do Titan foram emitidas pelo hardware da marca Titan que executa o firmware verdadeiro.
Como aproveitar a integridade da inicialização
Neste artigo, descrevemos os mecanismos para garantir que os processadores de aplicativos das máquinas inicializem o código pretendido. Esses mecanismos dependem de um fluxo de inicialização medido, com um chip de raiz de confiança de hardware.
O modelo de ameaças do Google inclui invasores que podem se interpor fisicamente no ônibus entre a CPU e o RoT, com o objetivo de conseguir a credencial descriptografada da máquina. Para minimizar esse risco, o Google está conduzindo o desenvolvimento de uma abordagem baseada em padrões para derrotar interferências ativas, reunindo as APIs TPM e DPE do Trusted Computing Group e raiz de confiança integrada Caliptra.
A seguir
- Para informações sobre como o Google ajuda a garantir a integridade de pilhas de inicialização de máquinas desagregadas complexas, consulte Atestado remoto de máquinas desagregadas.
- Para informações gerais sobre a infraestrutura de segurança do Google, consulte Visão geral do design de segurança da infraestrutura do Google.
- Para saber mais sobre como o Google está contribuindo com soluções de segurança Titan para os padrões do setor, consulte a palestra Inicialização atestada do TPM em ambientes grandes e distribuídos no canal do YouTube do Open Compute Project.
- Consulte os artigos sobre segurança para mais informações.
Autores: Jeff Andersen, Kevin Plybon