Como a Google aplica a integridade de arranque em máquinas de produção

Este conteúdo foi atualizado pela última vez em maio de 2024 e representa o status quo no momento em que foi escrito. As políticas e os sistemas de segurança da Google podem mudar no futuro, à medida que melhoramos continuamente a proteção dos nossos clientes.

Este documento descreve os controlos de infraestrutura que a Google usa para aplicar a integridade do processo de arranque em máquinas de produção equipadas com Titan. Estes controlos, criados com base num processo de arranque medido, ajudam a garantir que a Google pode recuperar as máquinas do respetivo centro de dados de vulnerabilidades em toda a respetiva pilha de arranque e devolver as máquinas de estados de arranque arbitrários para configurações boas conhecidas.

Introdução

A postura de segurança de uma máquina de centro de dados depende muito da configuração da máquina no momento do arranque. O processo de arranque da máquina configura o hardware da máquina e inicializa o respetivo sistema operativo, ao mesmo tempo que mantém a máquina segura para execução no ambiente de produção da Google.

Em cada passo do processo de arranque, a Google implementa controlos líderes da indústria para ajudar a aplicar o estado de arranque esperado e ajudar a manter os dados dos clientes seguros. Estes controlos ajudam a garantir que as nossas máquinas são iniciadas no software pretendido, o que nos permite remover vulnerabilidades que possam comprometer a postura de segurança inicial da máquina.

Este documento descreve o processo de arranque e demonstra como os nossos controlos funcionam durante o fluxo de arranque. Os principais objetivos dos nossos controlos são os seguintes:

Contexto

Esta secção define e fornece contexto para os termos credenciais do computador, raiz de confiança de hardware, credenciais seladas e selagem criptográfica.

Credenciais da máquina

Um dos componentes centrais no sistema de gestão de máquinas da Google é a nossa infraestrutura de credenciais, que consiste numa autoridade de certificação (AC) interna e noutros elementos do plano de controlo responsáveis por coordenar os fluxos de rotação de credenciais.

As máquinas na frota de produção da Google realizam a autenticação mútua quando estabelecem canais seguros. Para realizar a autenticação mútua, cada máquina possui as chaves públicas da AC da Google. Cada máquina também possui o seu próprio par de chaves públicas/privadas, bem como um certificado para esse par de chaves.

O par de chaves pública/privada de cada máquina, juntamente com o certificado assinado pela AC, é conhecido como uma credencial da máquina, que a máquina usa para se autenticar junto de outras máquinas na frota. Na rede de produção, as máquinas verificam se as chaves públicas de outras máquinas estão certificadas pela AC da Google antes de trocarem tráfego.

Raízes de confiança de hardware e vedação criptográfica

À medida que os dispositivos de computação se tornam mais sofisticados, a superfície de ataque de cada dispositivo também aumenta. Para ter isto em conta, os dispositivos incluem cada vez mais raízes de confiança (RoTs) de hardware, que são pequenos ambientes de execução fiáveis que salvaguardam os dados confidenciais para a máquina. Os RoTs também aparecem em dispositivos móveis, como portáteis ou telemóveis, e em dispositivos mais convencionais, como PCs de mesa.

As máquinas dos centros de dados da Google incluem raízes de confiança de hardware personalizadas e concebidas pela Google, integradas nas camadas mais profundas de cada máquina, conhecidas como Titan. Usamos o Titan, juntamente com um mecanismo denominado selagem criptográfica, para garantir que cada máquina está a executar as versões de configuração e software que esperamos.

A selagem criptográfica é um serviço oferecido pelo Titan que é usado para salvaguardar segredos. As capacidades de selagem do Titan são semelhantes às encontradas na especificação do Trusted Platform Module (TPM) publicada pelo Trusted Computing Group. A selagem criptográfica do Titan tem uma vantagem adicional, uma vez que o Titan oferece uma melhor capacidade de medir e atestar o firmware de baixo nível.

A selagem criptográfica compreende os seguintes dois controlos:

  • Encriptação de dados confidenciais
  • Uma política que tem de ser cumprida antes de os dados poderem ser desencriptados

Credenciais seladas

A infraestrutura de credenciais da Google usa a selagem criptográfica para encriptar as credenciais da máquina em repouso com uma chave controlada pela raiz de confiança de hardware da máquina. A chave privada da credencial encriptada e o certificado correspondente são conhecidos como uma credencial selada. Além das credenciais da máquina, a Google usa este mecanismo de selagem para proteger também outras partes de dados confidenciais.

Cada máquina só pode desencriptar e aceder às respetivas credenciais da máquina se conseguir satisfazer uma política de desencriptação que especifique o software com o qual a máquina tem de ter arrancado. Por exemplo, selar a credencial de uma máquina a uma política que especifica a versão pretendida do kernel do sistema operativo ajuda a garantir que a máquina não pode participar no respetivo cluster de máquinas, a menos que tenha iniciado a versão pretendida do kernel.

A política de desencriptação é aplicada através de um processo denominado arranque medido. Todas as camadas na pilha de arranque medem a camada seguinte e a máquina atesta esta cadeia de medições no final do arranque. Esta medição é frequentemente um hash criptográfico.

Processo de selagem de credenciais

Esta secção descreve a selagem de credenciais e o processo de arranque medido usado pelas máquinas Google. O diagrama seguinte ilustra este fluxo.

O fluxo de selagem de credenciais.

Para selar as credenciais de uma máquina a uma política de arranque específica, são realizados os seguintes passos:

  1. A infraestrutura de automatização de máquinas da Google inicia uma atualização de software na máquina. Transmite as versões de software pretendidas à infraestrutura de credenciais.
  2. A infraestrutura de credenciais da Google pede uma chave de selagem ao Titan, limitada por políticas de modo que o Titan só a usa se a máquina arrancar no respetivo software destinado.
  3. A infraestrutura de credenciais compara a política da chave devolvida com a intenção comunicada à mesma pela infraestrutura de automatização de máquinas. Se a infraestrutura de credenciais considerar que a política corresponde à intenção, emite uma credencial de máquina certificada para a máquina.
  4. A infraestrutura de credenciais encripta esta credencial através da chave de selagem obtida no passo 2.
  5. A credencial encriptada é armazenada no disco para desencriptação pelo Titan em arrancamentos subsequentes.

Processo de inicialização medida

A pilha de arranque das máquinas da Google consiste em quatro camadas, que são visualizadas no diagrama seguinte.

As quatro camadas do processo de inicialização medida.

As camadas são as seguintes:

  • Espaço do utilizador: aplicações como daemons ou cargas de trabalho.
  • Software do sistema: um hipervisor ou um kernel. O nível mais baixo do software que fornece uma abstração sobre funcionalidades de hardware, como redes, o sistema de ficheiros ou a memória virtual para o espaço do utilizador.
  • Firmware de arranque: o firmware que inicializa o kernel, como uma BIOS e um carregador de arranque.
  • Raiz de confiança de hardware: em máquinas Google, um chip Titan que mede criptograficamente o firmware e outros serviços de CPU de baixo nível.

Durante o arranque, cada camada mede a camada seguinte antes de passar o controlo para essa camada. A credencial selada da máquina só é disponibilizada ao sistema operativo se todas as medições capturadas durante o arranque estiverem em conformidade com a política de desencriptação da credencial selada, conforme especificado pela infraestrutura de credenciais da Google. Por conseguinte, se a máquina puder realizar operações com as respetivas credenciais seladas, isso é uma prova de que a máquina cumpriu a respetiva política de arranque medido. Este processo é uma forma de atestação implícita.

Se uma máquina arrancar software que se desvia do estado pretendido, a máquina não pode desencriptar nem realizar operações com as credenciais de que precisa para operar na frota. Estas máquinas não podem participar no agendamento de cargas de trabalho até que a infraestrutura de gestão de máquinas acione ações de reparação automatizadas.

Recuperar de vulnerabilidades no kernel

Suponhamos que uma máquina está a executar a versão A do kernel, mas os investigadores de segurança descobrem que esta versão do kernel tem uma vulnerabilidade. Nestes cenários, a Google corrige a vulnerabilidade e implementa uma versão B do kernel atualizada na frota.

Além de corrigir a vulnerabilidade, a Google também emite novas credenciais de máquina para cada máquina na frota. Conforme descrito no Processo de selagem de credenciais, as novas credenciais da máquina estão associadas a uma política de descifragem que só é satisfeita se a versão B do kernel for iniciada na máquina. Qualquer máquina que não esteja a executar o respetivo kernel pretendido não consegue desencriptar as novas credenciais da máquina, uma vez que as medições do firmware de arranque não satisfazem a política de arranque da máquina. No âmbito deste processo, as credenciais da máquina antiga também são revogadas.

Como resultado, estas máquinas não podem participar no respetivo cluster de máquinas até que o respetivo kernel seja atualizado para estar em conformidade com a intenção do plano de controlo. Estes controlos ajudam a garantir que as máquinas que executam a versão A do kernel vulnerável não podem receber tarefas nem dados do utilizador até serem atualizadas para a versão B do kernel.

Recuperação de vulnerabilidades no firmware de arranque

Suponhamos que existe uma vulnerabilidade no firmware de arranque, em vez do kernel do sistema operativo. Os mesmos controlos descritos no artigo Recuperar de vulnerabilidades no kernel ajudam a Google a recuperar de uma vulnerabilidade deste tipo.

O chip Titan da Google mede o firmware de arranque de uma máquina antes de ser executado, para que o Titan possa determinar se o firmware de arranque cumpre a política de arranque das credenciais da máquina. Qualquer máquina que não esteja a executar o firmware de arranque pretendido não pode obter novas credenciais da máquina e não pode participar no respetivo cluster de máquinas até que o firmware de arranque esteja em conformidade com a intenção do plano de controlo.

Recuperação de vulnerabilidades no firmware de raiz fidedigna

Os RoTs não são imunes a vulnerabilidades, mas os controlos de arranque da Google permitem a recuperação de erros, mesmo nesta camada da pilha de arranque, no código mutável do próprio RoT.

A pilha de arranque do Titan implementa um fluxo de arranque seguro e medido próprio. Quando um chip Titan é ligado, o respetivo hardware mede criptograficamente o carregador de arranque do Titan, que, por sua vez, mede o firmware do Titan. Tal como o kernel e o firmware de arranque da máquina, o firmware do Titan é assinado criptograficamente com um número de versão. O carregador de arranque do Titan valida a assinatura e extrai o número da versão do firmware do Titan, transmitindo o número da versão para o subsistema de derivação de chaves baseado em hardware do Titan.

O subsistema de hardware do Titan implementa um esquema de derivação de chaves com versões, em que o firmware do Titan com a versão X pode obter chaves únicas do chip associadas a todas as versões inferiores ou iguais a X. O hardware Titan permite que o firmware com a versão X aceda a chaves associadas a versões inferiores ou iguais a X, mas não superiores a X. Todos os segredos selados para o Titan, incluindo as credenciais da máquina, são encriptados através de uma chave com controlo de versões.

As chaves de atestação e selagem são exclusivas de cada chip Titan. As chaves únicas permitem que a Google confie apenas nos chips Titan que se espera que estejam a ser executados num centro de dados da Google.

O diagrama seguinte mostra o Titan com chaves de versão. A chave da versão X+1 não pode ser acedida pelo firmware da versão X, mas todas as chaves anteriores são acessíveis.

Versões do Titã.

Em caso de uma vulnerabilidade grave no firmware do Titan, a Google implementa um patch com um número de versão superior e, em seguida, emite novas credenciais da máquina associadas à versão superior do firmware do Titan. Qualquer firmware Titan antigo e vulnerável não consegue desencriptar estas novas credenciais. Por conseguinte, se uma máquina realizar operações com as suas novas credenciais em produção, a Google pode afirmar com confiança que o chip Titan da máquina foi iniciado com o firmware Titan atualizado.

Garantir a autenticidade da raiz de fidedignidade

Os controlos descritos neste documento baseiam-se todos na funcionalidade da própria RoT de hardware. A infraestrutura de credenciais da Google baseia-se em assinaturas emitidas por estes RoTs para saber se a máquina está a executar o software pretendido.

Por conseguinte, é fundamental que a infraestrutura de credenciais possa determinar se uma RoT de hardware é autêntica e se a RoT está a executar firmware atualizado.

Quando cada chip Titan é fabricado, é programado com entropia única. A rotina de arranque de baixo nível do Titan transforma essa entropia numa chave única do dispositivo. Um elemento seguro na linha de fabrico do Titan aprova esta chave exclusiva do chip, de modo que a Google a reconhece como um chip Titan legítimo.

O diagrama seguinte ilustra este processo de recomendação.

O processo de aprovação do Titan.

Quando em produção, o Titan usa a respetiva chave exclusiva do dispositivo para validar qualquer assinatura que emita. Os chips Titan usam um fluxo semelhante ao do Device Identifier Composition Engine (DICE). A validação inclui as informações da versão do firmware do Titan. Esta atestação ajuda a impedir que um atacante se faça passar por uma assinatura emitida por um chip Titan e que reverta para um firmware Titan mais antigo e se faça passar por um firmware Titan mais recente. Estes controlos ajudam a Google a verificar se as assinaturas recebidas do Titan foram emitidas por hardware Titan autêntico com firmware Titan autêntico.

Tirar partido da integridade de arranque

Este documento descreveu mecanismos para garantir que os processadores de aplicações das máquinas iniciam o código pretendido. Estes mecanismos baseiam-se num fluxo de arranque medido, juntamente com um chip de raiz de confiança de hardware.

O modelo de ameaças da Google inclui atacantes que podem interpor-se fisicamente no barramento entre a CPU e a RoT, com o objetivo de obter indevidamente a credencial descifrada da máquina. Para ajudar a minimizar este risco, a Google está a impulsionar o desenvolvimento de uma abordagem baseada em normas para derrotar os interpositores ativos, reunindo as APIs TPM e DPE do Trusted Computing Group e a raiz de confiança integrada Caliptra.

O que se segue?