Application Layer Transport Security

Por Cesar Ghali, Adam Stubblefield, Ed Knapp, Jiangtao Li, Benedikt Schmidt e Julien Boeuf

O conteúdo apresentado aqui foi editado em dezembro de 2017. Este whitepaper representa o cenário corrente do momento em que foi escrito. Conforme nosso processo de melhoria contínua da proteção de nossos clientes, as políticas e os sistemas de segurança do Google Cloud podem ser alterados no futuro.

Resumo para CIOs

  • O ALTS (Application Layer Transport Security) do Google é um sistema de autenticação mútua e criptografia de transporte, desenvolvido pelo Google, normalmente usado para proteger as comunicações de chamada de procedimento remoto (RPC, na sigla em inglês) na infraestrutura do Google. O ALTS é semelhante em conceito ao TLS mutuamente autenticado, mas foi projetado e otimizado para atender às necessidades dos ambientes de data center do Google.
  • O modelo de confiança do ALTS foi adaptado para aplicativos em contêineres similares à nuvem. As identidades são vinculadas a entidades, em vez de a um nome de servidor ou host específico. Esse modelo de confiança facilita a replicação de microsserviços, o balanceamento de carga e a reprogramação de hosts. Tudo de modo perfeito e sem interrupções.
  • O ALTS depende de dois protocolos: o de handshake, com retomada da sessão, e o de registro. Esses protocolos é que regem como as sessões são estabelecidas, autenticadas, criptografadas e retomadas.
  • O ALTS é uma solução de protocolo Transport Layer Security personalizada que usamos no Google. Moldamos o ALTS de acordo com as necessidades do nosso ambiente de produção. Portanto, o ALTS apresenta algumas vantagens e desvantagens em comparação com o protocolo TLS, o padrão adotado pelo setor. Mais detalhes podem ser encontrados na seção Vantagens e desvantagens.

Introdução

Os sistemas de produção no Google consistem em uma constelação de microsserviços 1 que emitem coletivamente O(1010) chamadas de procedimento remoto (RPCs), por segundo. Por padrão, quando um engenheiro do Google programa uma carga de trabalho de produção2, todas as RPCs emitidas ou recebidas por ela são protegidas pelo ALTS. A proteção automática fornecida pelo sistema do Application Layer Transport Security (ALTS) do Google não requer nenhuma configuração. Além desse recurso, o ALTS também facilita a replicação de serviços, o balanceamento de carga e a reprogramação em diferentes máquinas de produção. Neste artigo, descrevemos o ALTS e exploramos a implantação dele na infraestrutura de produção do Google.

Público-alvo: este documento destina-se a profissionais de segurança de infraestruturas que têm curiosidade em saber como o Google cuida da segurança da autenticação e do transporte em grande escala.

Pré-requisitos: além do que descrevemos nesta introdução, supomos que o leitor tenha algum conhecimento sobre o gerenciamento de clusters no Google.

Segurança no nível do aplicativo e ALTS

Muitos aplicativos, como navegadores da Web ou VPNs, dependem de protocolos de comunicação seguros, como o Transport Layer Security (TLS) e o IPSec, para proteger dados em trânsito3. No Google, usamos o ALTS, um sistema criptográfico de autenticação mútua e de transporte que é executado na camada do aplicativo para proteger as comunicações de RPC. O uso da segurança em aplicativos permite a autenticação da identidade de pares remotos, podendo ser aplicada na implementação de políticas de autorização minuciosas.

Por que não usar o TLS?

Pode parecer incomum que o Google use uma solução de segurança personalizada como um ALTS quando a maioria do tráfego da internet hoje é criptografada usando TLS. O ALTS começou a ser desenvolvido no Google em 2007. Na época, o protocolo TLS vinha empacotado junto com o suporte para muitos protocolos legados que não satisfaziam a nossos padrões mínimos de segurança. Poderíamos ter projetado nossa solução de segurança adotando os componentes do TLS que precisávamos e implementando os que queríamos. Porém, as vantagens de criar do zero um sistema mais adequado ao Google superaram os benefícios de apenas aplicar patches a um sistema existente. Além disso, o ALTS é mais apropriado para nossas necessidades e historicamente mais seguro do que o TLS, que é um protocolo mais antigo. Abaixo estão as diferenças principais entre TLS e ALTS.

  • Há uma diferença significativa entre os modelos de confiança4 do TLS, com semânticas HTTPS e os do ALTS. No primeiro, as identidades do servidor estão ligadas a um esquema de nome específico e nomeação correspondente. No ALTS, uma mesma identidade pode ser usada com vários esquemas de nomeação. A ausência de uma correspondência direta proporciona mais flexibilidade e simplifica muito os processos de replicação de microsserviços, balanceamento de carga e reprogramação entre hosts.
  • Comparado ao TLS, o ALTS é mais simples em sua concepção e implementação. Como resultado, é mais fácil monitorar bugs e vulnerabilidades de segurança por meio da inspeção manual do código-fonte ou de um teste de fuzzing extensivo.
  • O ALTS usa buffer de protocolo para serializar certificados e mensagens de protocolo, enquanto o TLS usa certificados X.509 codificados com ASN.1. A maioria de nossos serviços de produção usa buffers de protocolo para a comunicação e, às vezes, o armazenamento. Isso faz do ALTS uma opção mais adequada ao ambiente do Google.

Design do ALTS

O ALTS foi projetado para ser um sistema altamente confiável, que permite a autenticação de serviço a serviço e proporciona segurança com um mínimo de envolvimento dos usuários. Para tanto, o design do ALTS conta com as propriedades abaixo:

  • Transparência: a configuração do ALTS é transparente para a camada do aplicativo. Por padrão, as RPCs de serviço são protegidas pelo ALTS. Assim, os desenvolvedores de aplicativos podem se concentrar na lógica funcional dos serviços, sem precisar se preocupar com o gerenciamento de credenciais ou as configurações de segurança. Durante o estabelecimento da conexão de serviço a serviço, o ALTS fornece aos aplicativos a autenticação de identidade de terminais remotos, que pode ser usada para verificações de autorização e auditorias minuciosas.
  • Criptografia de última geração: todas as primitivas criptográficas e protocolos usados pelo ALTS estão atualizados de acordo com os ataques mais recentes e conhecidos. O ALTS é executado em máquinas controladas pelo Google e, por isso, é fácil e rápido fazer o upgrade e implantar todos os protocolos criptográficos compatíveis.
  • Modelo de identidade: no ALTS, a autenticação é executada principalmente por meio da identidade e não pelo nome do host. No Google, todas as entidades de rede, por exemplo, um usuário corporativo, uma máquina física, um serviço de produção ou uma carga de trabalho, têm uma identidade associada. Todas as comunicações entre serviços são mutuamente autenticadas.
  • Distribuição de chaves: no ALTS, cada carga de trabalho precisa ter uma identidade, que é expressa como um conjunto de credenciais. Essas credenciais são implantadas em cada carga de trabalho durante a inicialização, sem o envolvimento do usuário. Paralelamente, uma raiz e uma cadeia de confiança dessas credenciais são estabelecidas para máquinas e cargas de trabalho. No sistema, é permitida a alternância e a revogação automática de certificados, sem o envolvimento dos desenvolvedores de aplicativos.
  • Escalonabilidade: o ALTS foi projetado para ser altamente escalonável e, com isso, dar suporte ao escalonamento de grande proporção da infraestrutura do Google. Esse requisito resultou no desenvolvimento de uma retomada de sessão eficiente.
  • Conexões de longa duração: as operações criptográficas de troca de chaves autenticadas são dispendiosas por consumirem muitos recursos computacionais. Para acomodar a escala da infraestrutura do Google, após um handshake inicial do ALTS, as conexões podem ser continuadas por mais tempo para melhorar o desempenho geral do sistema.
  • Simplicidade: por padrão, no TLS há suporte para versões de protocolo legadas e compatibilidade com versões anteriores. O ALTS é consideravelmente mais simples porque o Google controla os clientes e os servidores, criados para que sejam compatíveis nativamente com o ALTS.

Modelo de confiança do ALTS

O ALTS realiza a autenticação principalmente por meio da identidade, em vez de usar o host. No Google, todas as entidades de rede (por exemplo, um usuário corporativo, uma máquina física ou um serviço de produção) têm uma identidade associada. Essas identidades são incorporadas nos certificados do ALTS e usadas para autenticação de pares durante o estabelecimento da conexão segura. Buscamos um modelo em que nossos serviços de produção sejam executados como entidades de produção, gerenciadas pelos nossos "Engenheiros de confiabilidade do site" (SREs)5. As versões de desenvolvimento desses serviços de produção são executadas como entidades de teste que podem ser gerenciadas pelos SREs e desenvolvedores.

Por exemplo, vamos supor que temos um produto com dois serviços: service-frontend e service-backend. Os SREs podem lançar a versão de produção desses serviços: service-frontend-prod e service-backend-prod. Os desenvolvedores podem criar e lançar versões de desenvolvimento desses serviços, service-frontend-dev e service-backend-dev, para fins de testes. A configuração da autorização nos serviços de produção será definida para não confiar nas versões de desenvolvimento dos serviços.

Credenciais do ALTS

Há três tipos de credenciais do ALTS, todas expressas no formato de mensagem de buffer de protocolo.

  • Certificado mestre: assinado por um serviço de assinatura remoto e usado para verificar os certificados de handshake. O certificado mestre contém uma chave pública, associada a uma chave privada mestre, por exemplo, par de chaves RSA. Essa chave privada é usada para assinar os certificados de handshake. Esses certificados, quando exercidos em combinação com a política do ALTS discutida abaixo, são basicamente certificados intermediários restritos da autoridade de certificação (CA, na sigla em inglês). Os certificados mestres geralmente são emitidos para máquinas de produção e programadores de cargas de trabalho em contêineres, como o Borgmaster6
  • Certificado de handshake: criado e assinado localmente pela chave privada mestre. Esse certificado contém os parâmetros utilizados durante o handshake do ALTS, ou seja, quando uma conexão segura é estabelecida, como os parâmetros estáticos Diffie-Hellman (DH) e as criptografias de handshake por exemplo. Além disso, o certificado de handshake contém o certificado mestre que lhe deu origem, ou seja, o associado à chave particular mestre com que o certificado de handshake é assinado.
  • Chave de retomada: é uma chave secreta usada para criptografar os tíquetes de retomada. Essa chave é identificada por um identificador de retomada IDR que é único e compartilhado entre todas as cargas de trabalho da produção com a mesma identidade e na mesma célula de data center. Para obter mais detalhes sobre a retomada de sessão no ALTS, consulte Retomada de sessão.

A Figura 1 mostra a cadeia de certificados do ALTS, que consiste em uma chave de verificação do serviço de assinatura, um certificado mestre e um certificado de handshake. As chaves de verificação do serviço de assinatura são a raiz da confiança no ALTS e estão instaladas em todas as máquinas do Google que fazem parte de nossas redes corporativas e de produção.

Figura 1: cadeia de certificados do ALTS

No ALTS, um serviço de assinatura autentica os certificados mestres que, por sua vez, fazem o mesmo para os certificados de handshake. Como os certificados de handshake são criados com mais frequência do que os certificados mestres, essa arquitetura reduz a carga no serviço de assinatura. O Google sempre promove a alternância de certificados, especialmente os de handshake7. Esse procedimento compensa a troca de pares de chaves estáticas transportadas pelos certificados de handshake8.

Emissão de certificados

Para participar de um handshake seguro do ALTS, as entidades na rede precisam ser provisionadas com certificados de handshake. Primeiro, o emissor recebe um certificado mestre assinado pelo serviço de assinatura e, opcionalmente, o repassa para a entidade. Em seguida, um certificado de handshake é criado e assinado pela chave privada mestre associada.

Normalmente, o emissor é nossa autoridade de certificação (CA, na sigla em inglês) interna, quando os certificados são emitidos para máquinas e humanos, ou o Borgmaster, quando são emitidos para cargas de trabalho. No entanto, esse emissor pode ser qualquer outra entidade, por exemplo, um Borgmaster restrito para uma célula de data center de teste.

A Figura 2 mostra como o serviço de assinatura é usado para criar um certificado mestre. O processo consiste nas etapas a seguir.

Figura 2: emissão de certificados

  1. O emissor do certificado envia uma solicitação de assinatura de certificado (CSR, na sigla em inglês) ao serviço de assinatura. Esta solicitação pede ao serviço de assinatura que crie um certificado para a identidade A. Essa identidade pode ser, por exemplo, um usuário corporativo ou a identidade de um serviço de produção do Google.
  2. O serviço de assinatura define o emissor do certificado que está incluído no CSR para o solicitante, que é o emissor do certificado neste caso, e ele o assina. Lembre-se de que a chave pública, de verificação, correspondente do serviço de assinatura está instalada em todas as máquinas do Google.
  3. O serviço de assinatura envia de volta o certificado assinado.
  4. Um certificado de handshake é criado para a identidade A e assinado pela chave privada associada ao certificado mestre.

Como demonstrado no processo acima, com o ALTS, o emissor e o assinante do certificado são duas entidades lógicas diferentes. Nesse caso, o emissor é a entidade emissora do certificado e o assinante é o serviço de assinatura.

Há três categorias comuns de certificados no ALTS: humano, máquina e carga de trabalho. As seções a seguir descrevem como cada um desses tipos de certificados é criado e usado no ALTS.

Certificados para humanos

No Google, usamos o ALTS para proteger RPCs emitidas por usuários humanos aos serviços de produção. Para emitir uma RPC, é necessário que o usuário forneça um certificado de handshake válido. Por exemplo, se Alice quer usar um aplicativo para emitir uma RPC protegida pelo ALTS, ela pode receber a autenticação da nossa CA interna. Para tanto, ela precisa usar o nome de usuário, a senha e a autenticação de dois fatores. Como resultado dessa operação, Alice receberá um certificado de handshake com validade de 20 horas.

Certificados para máquinas

Cada máquina de produção nos data centers do Google tem um certificado mestre de máquina. Esse certificado é usado na criação de certificados de handshake para os aplicativos essenciais de uma determinada máquina, por exemplo, daemons de gerenciamento de máquinas. A identidade principal incorporada em um certificado de máquina refere-se à finalidade específica dela. Por exemplo, as máquinas usadas para executar diferentes tipos de cargas de trabalho de produção e desenvolvimento podem ter identidades distintas. Os certificados mestres são usados apenas pelas máquinas que executam pilhas de softwares verificados. Em alguns casos, essa confiança está enraizada no hardware de segurança personalizado9. Todos os certificados mestre de máquina de produção são emitidos pela CA e alternados a cada poucos meses. Além disso, todos os certificados de handshake são alternados a cada poucas horas.

Certificados para cargas de trabalho

Uma das principais vantagens do ALTS é o fato de que esse sistema opera com base no uso de identidade de carga de trabalho, o que facilita a replicação de serviços, o balanceamento de carga e a reprogramação entre máquinas. Em nossa rede de produção, usamos um sistema chamado Borg10 para gerenciar clusters e alocar recursos de máquinas em grande escala. A maneira como o Borg emite certificados faz parte da implementação de identidades de carga de trabalho independente da máquina realizada pelo ALTS.

Cada carga de trabalho em nossa rede de produção é executada em uma célula do Borg. Cada célula contém um controlador logicamente centralizado chamado Borgmaster, além de vários processos de agente chamados borglets que são executados em cada máquina da célula. As cargas de trabalho são inicializadas com os certificados de handshake de carga de trabalho associados, que foram emitidos pelo Borgmaster. A Figura 3 mostra o processo de certificação de cargas de trabalho no ALTS com o uso do Borg.

Figura 3: criação de um certificado de handshake na rede de produção do Google

Após esse processo, o Borgmaster estará pronto para programar as cargas de trabalho que precisam usar o ALTS. Abaixo, confira cada etapa que ocorre quando um cliente programa uma carga de trabalho para ser executada no Borg como uma determinada identidade.

  1. Cada Borgmaster vem pré-instalado com um certificado mestre de máquina e uma chave privada associada, não mostrada no diagrama.
  2. O ALTSd11 gera um certificado de handshake do Borgmaster e o assina usando a chave privada mestre da máquina. Com esse certificado de handshake, as RPCs protegidas pelo ALTS são emitidas pelo Borgmaster.
  3. São criados, pelo Borgmaster, um certificado mestre de carga de trabalho básico e a chave privada correspondente. Uma solicitação, que é uma RPC protegida do ALTS, é iniciada pelo Borgmaster para receber o certificado mestre de carga de trabalho básico, assinado pelo serviço de assinatura. Como resultado, o serviço de assinatura lista o Borgmaster como emissor no certificado.
  4. O Borgmaster verifica se o cliente está autorizado a executar cargas de trabalho como a identidade especificada na configuração da carga de trabalho. Em caso afirmativo, o Borgmaster programa a carga de trabalho do Borg no Borglet e emite um "Certificado de handshake" para a carga de trabalho e a chave privada correspondente. Esse certificado é derivado do certificado mestre de carga de trabalho básico. O "Certificado de handshake" da carga de trabalho e a chave privada correspondente são enviados com segurança para o Borglet por meio de um pipeline protegido do ALTS, com autenticação mútua entre o Borgmaster e o Borglet. A cada dois dias, o Borgmaster alterna o certificado mestre de carga de trabalho básico e emite novamente os "Certificados de handshake" para todas as cargas de trabalho em execução. Além disso, cada carga de trabalho executada como o mesmo usuário na mesma célula recebe a mesma chave de retomada e identificador (IDR) provisionado pelo Borgmaster.
  5. Sempre que for necessário que a carga de trabalho faça uma RPC protegida pelo ALTS, será usado o "Certificado de handshake" no protocolo de handshake. O IDR também é usado como parte do handshake para iniciar a retomada da sessão. Para obter mais informações sobre a retomada da sessão no ALTS, consulte Retomada da sessão.

Aplicação da política do ALTS

A política ALTS é um documento com a lista de emissores autorizados a emitir determinadas categorias de certificados e para quais identidades. Essa política é distribuída para todas as máquinas da nossa rede de produção. Por exemplo, seguindo a política do ALTS, a CA pode emitir certificados para máquinas e humanos, e o Borgmaster, para as cargas de trabalho.

Descobrimos que realizar a aplicação da política durante a verificação do certificado, e não na emissão, é uma abordagem mais flexível porque, assim, podemos aplicar políticas diferentes em tipos de implantações distintos. Por exemplo, se quisermos, podemos aplicar uma política mais permissiva a um cluster de testes e outra mais restritiva a um cluster de produção.

Na validação do certificado, durante o handshake do ALTS, também ocorre a verificação da política do ALTS. Com a política, temos a garantia de que o emissor listado está autorizado a emitir no certificado em validação. Caso contrário, o certificado será rejeitado e o processo de handshake falhará. A Figura 4 ilustra como funciona a aplicação de políticas no ALTS. Levando em consideração o mesmo cenário da Figura 2, em que supomos que Mallory (uma usuária corporativa que quer ampliar seus privilégios) quer emitir um certificado mestre para administrador de rede, uma identidade com amplos poderes para reconfigurar a rede. Porém, Mallory não está autorizada a realizar essa operação de acordo com a política do ALTS.

Figura 4: emissão e uso de certificados

  1. A Mallory emite um certificado mestre para a identidade de administrador de rede e o recebe assinado pelo serviço de assinatura. Esse processo é semelhante aos três primeiros passos na Figura 2.
  2. A Mallory cria e assina um certificado de handshake localmente para o papel de administrador de rede, usando a chave privada mestre associada ao certificado que ela criou.
  3. Se a Mallory tentar usar a identidade do administrador de rede com o certificado de handshake que ela criou, o implementador de políticas do ALTS, localizado no terminal com que ela está tentando se comunicar, bloqueará a operação.

Revogação de certificados

No Google, um certificado se torna inválido quando expira ou é incluído em nossa lista de revogação de certificado (CRL, na sigla em inglês). Nesta seção, apresentamos o design dos mecanismos internos de revogação de certificados do Google, que ainda estavam sendo submetidos a testes de implantação no momento em que este artigo foi redigido.

Todos os certificados emitidos para usuários corporativos humanos têm um carimbo de data/hora com validade diária, o que obriga os usuários a realizar uma nova autenticação todos os dias. Grande parte dos certificados emitidos para máquinas de produção não têm data e hora de validade. Evitamos confiar em carimbos de data/hora para a expiração dos certificados de produção porque isso pode resultar em interrupções causadas por problemas de sincronização do relógio. Em vez disso, usamos a CRL como nossa fonte de confiança para alternar certificados e gerenciar as respostas a incidentes. A Figura 5 mostra como funciona a CRL.

Figura 5: criação de um certificado mestre com um ID de revogação

  1. Assim que uma instância da nossa CA é inicializada12, ela entra em contato com o serviço da CRL e solicita um intervalo do ID de revogação. Um ID de revogação têm o tamanho de 64 bits e é formado por dois componentes: um certificado de uma determinada categoria, por exemplo, para humanos ou máquinas, de 8 bits e um identificador de certificado de 56 bits. Um intervalo para esses IDs é escolhido e enviado para a CA pelo serviço da CRL.
  2. Quando a CA recebe uma solicitação de criação de um certificado mestre, a solicitação é atendida e um dos IDs de revogação do intervalo é escolhido e incorporado.
  3. Paralelamente, a associação do novo certificado ao ID de revogação é feita pela CA e essas informações são enviadas para o serviço da CRL.
  4. A CA emite o certificado mestre.

Os IDs de revogação atribuídos aos certificados de handshake dependem da finalidade do certificado. Por exemplo, os certificados de handshake emitidos para usuários corporativos humanos herdam o ID de revogação do certificado mestre do usuário. Já no caso dos certificados de handshake emitidos para as cargas de trabalho do Borg, esse ID é atribuído de acordo com o intervalo de IDs de revogação do Borgmaster. Esse intervalo de IDs é atribuído ao Borgmaster pelo serviço da CRL, realizando um processo semelhante ao mostrado na Figura 5. Se houver outro terminal envolvido no handshake do ALTS, ele verificará a cópia local do arquivo da CRL para garantir que o certificado da parte remota não tenha sido revogado

O serviço da CRL compila todos os IDs de revogação em um único arquivo que pode ser enviado para todas as máquinas do Google que usam o ALTS. Enquanto o banco de dados da CRL é constituído por muitas centenas de megabytes, o arquivo da CRL é gerado por meio de várias técnicas de compactação e, portanto, tem poucos megabytes.

Protocolos do ALTS

O ALTS depende de dois protocolos: o de handshake, com retomada da sessão, e o de registro. Nesta seção, oferecemos uma visão geral de cada protocolo. As descrições aqui contidas não devem ser interpretadas como especificações detalhadas dos protocolos.

Protocolo de handshake

O protocolo de handshake do ALTS é um protocolo de troca de chaves autenticado com base em Diffie-Hellman. Ele é compatível com Perfect Forward Secrecy (PFS) e a retomada de sessão. A infraestrutura do ALTS foi desenvolvida para garantir que todos os clientes e servidores tenham um certificado com as respectivas identidades deles e uma chave Diffie-Hellman de curva elíptica (ECDH, na sigla em inglês), que está encadeada a uma chave de verificação de um serviço de assinatura confiável. No ALTS, o PFS não está ativado por padrão porque as chaves ECDH estáticas são atualizadas com frequência com o objetivo de renovar o sigilo do encaminhamento, mesmo quando o PFS não é usado no handshake. Durante o handshake, o cliente e o servidor negociam com segurança uma chave de criptografia de tráfego compartilhado e o protocolo de registro que tal chave protegerá. Por exemplo, o cliente e o servidor podem combinar uma chave de 128 bits que será usada para proteger uma sessão de RPC usando AES-GCM. O handshake consiste em quatro mensagens serializadas do buffer de protocolo, cuja visão geral pode ser vista na Figura 6.

Figura 6: mensagens do protocolo de handshake do ALTS

  1. O cliente inicia o handshake ao enviar uma mensagem ClientInit. Essa mensagem contém o "Certificado de handshake" do cliente e uma lista de códigos criptográficos relacionados ao handshake e aos protocolos de registro aceitos pelo cliente. Se o cliente estiver tentando retomar uma sessão encerrada, um identificador e um tíquete de servidor criptografado serão incluídos para essa operação.

  2. Ao receber a mensagem ClientInit, o servidor verifica o certificado do cliente. Se válido, o servidor escolhe um código criptográfico de handshake e um protocolo de registro na lista fornecida pelo cliente. O servidor usa uma combinação entre as informações contidas na mensagem ClientInit e as próprias informações locais para calcular o resultado da troca de chaves DH. Esse resultado é usado como entrada para as funções de derivação de chaves13, com a transcrição do protocolo para gerar as seguintes chaves secretas da sessão:

    • Uma chave secreta M de protocolo de registro a ser usada para criptografar e autenticar mensagens de payload.
    • Uma chave secreta R de retomada a ser usada em um tíquete de retomada em sessões futuras.
    • Uma chave secreta A de autenticador.

    O servidor envia uma mensagem ServerInit contendo o próprio certificado, o código criptográfico de handshake escolhido, o protocolo de registro e um tíquete de retomada criptografado opcional.

  3. O servidor envia uma mensagem ServerFinished contendo um autenticador de handshake14. O valor do autenticador é calculado usando um código de autenticação de mensagem baseado em hash (HMAC, na sigla em inglês) que, por sua vez, é calculado de acordo com uma string de bits predefinida e a chave secreta A de autenticador.

  4. Depois que o cliente recebe a mensagem ServerInit, o certificado do servidor é verificado, é calculado o resultado da troca de chaves DH, de maneira semelhante ao processo realizado pelo servidor e são derivadas as mesmas chaves secretas M, R e A. O cliente usa a chave secreta A derivada para verificar o valor do autenticador na mensagem ServerFinished recebida. Nesse momento do processo de handshake, o cliente pode começar a usar a chave secreta M para criptografar mensagens. Como o cliente agora é capaz de enviar mensagens criptografadas, podemos dizer que o ALTS tem um protocolo de handshake de RTT.

  5. No final do processo de handshake, o cliente envia uma mensagem ClientFinished com um valor de autenticador semelhante (veja a etapa 3), calculado com base em uma string de bits diferente predefinida. Se necessário, o cliente pode incluir um tíquete de retomada criptografado para sessões futuras. Após o servidor receber e verificar essa mensagem, o protocolo de handshake do ALTS será concluído e o servidor poderá usar a chave secreta M para criptografar e autenticar outras mensagens de payload.

O protocolo de handshake foi revisado por Thai Duong, da equipe de análise de segurança interna do Google e formalmente verificado com a ferramenta Proverif15 por Bruno Blanchet, com a assistência de Martin Abadi.

Protocolo de registro

Na seção Protocolo de handshake, descrevemos como usamos o protocolo mencionado para negociar uma chave secreta de protocolo de registro. Essa chave secreta de protocolo é usada para criptografar e autenticar o tráfego de rede. A camada da pilha que realiza essas operações é chamada de ALTS Record Protocol (ALTSRP).

O ALTSRP contém um conjunto de esquemas de criptografia com tamanhos de chaves e recursos de segurança variados. Durante o processo de handshake, o cliente envia a lista de esquemas preferenciais dele, classificados por ordem de preferência. O servidor escolhe o primeiro protocolo na lista do cliente que corresponda à configuração local desse servidor. Devido a esse método de seleção de esquema, clientes e servidores podem ter preferências de criptografia diferentes. Além disso, podemos também implementar gradualmente ou remover esquemas de criptografia.

Frames

Os frames são a menor unidade de dados no ALTS. Dependendo de seu tamanho, cada mensagem ALTSRP pode consistir em um ou mais frames. Cada frame contém os seguintes campos:

  • Comprimento: um valor sem assinatura de 32 bits que indica o comprimento do frame em bytes. Esse campo, com comprimento de 4 bytes, não está incluído como parte do comprimento total do frame.
  • Tipo: um valor de 32 bits que especifica o tipo do frame, por exemplo, um frame de dados.
  • Payload: os reais dados autenticados e, opcionalmente, criptografados que estão sendo enviados.

Um frame pode ter no máximo o comprimento de 1 MB mais 4 bytes. No caso dos protocolos de RPC atuais, limitamos ainda mais o comprimento do frame. Isso acontece porque os frames mais curtos requerem menos memória para armazenamento em buffer. Além disso, frames maiores podem ser explorados por possíveis ataques de negação de serviço (DoS) na tentativa de tornar um servidor indisponível. Além de limitar o comprimento do frame, também restringimos o número de frames que podem ser criptografados usando o mesmo segredo M de protocolo de registro. O limite varia dependendo do esquema de criptografia usado para criptografar e descriptografar a carga de trabalho do frame. Quando esse limite é atingido, é necessário encerrar a conexão.

Payload

No ALTS, cada frame contém um payload com integridade protegida e a criptografia opcional16 Até a data de publicação deste artigo, o ALTS é compatível com os seguintes modos:

  • AES-128-GCM, AES-128-VCM: modos AES-GCM e AES-VCM, respectivamente, com chaves de 128 bits. Esses modos protegem a confidencialidade e a integridade do payload com o uso dos esquemas GCM e VCM17, respectivamente.
  • AES-128-GMAC, AES-128-VMAC: esses modos são compatíveis com proteção somente da integridade usando GMAC e VMAC, respectivamente, para a computação de tags. O payload é transferido em um texto simples com a proteção de integridade de uma tag criptográfica.

No Google, usamos modos de proteção diferentes dependendo do modelo de ameaça e dos requisitos de desempenho. Se as entidades que estão se comunicando estiverem dentro do mesmo limite físico controlado por ou em nome do Google, usamos o modo de proteção somente da integridade. Se preferirem, essas entidades ainda poderão fazer o upgrade para a criptografia autenticada com base na confidencialidade dos dados. Por outro lado, se as entidades estiverem em diferentes locais físicos controlados por ou em nome do Google, de modo que as comunicações sejam transmitidas por meio da rede de longa distância, o upgrade da segurança da conexão será feito automaticamente para a criptografia autenticada, independentemente do modo escolhido. O Google aplica proteções diferentes aos dados em trânsito quando eles são transmitidos fora de um limite físico controlado por ou em nome do Google, já que não é possível aplicar as mesmas medidas de segurança rigorosas descritas acima.

Individualmente, cada frame tem sua integridade protegida e, opcionalmente, criptografada. Ambas as extremidades do processo mantêm os contadores de solicitação e resposta, que são sincronizados durante a operação normal. Se o servidor receber solicitações fora de ordem ou repetidas, a verificação da integridade criptográfica falhará e a solicitação será descartada. Da mesma forma, o cliente descartará respostas repetidas ou fora de ordem. Além disso, como ambas as extremidades do processo mantêm os contadores, em vez de incluir os valores deles no cabeçalho do frame, há uma economia de bytes adicionais em trânsito.

Retomada da sessão

O sistema do ALTS permite aos usuários retomar sessões anteriores sem a necessidade de realizar grandes operações criptográficas assimétricas. A retomada da sessão é um recurso incorporado no protocolo de handshake do ALTS.

Com o handshake do ALTS, os clientes e servidores conseguem, com segurança, trocar e armazenar em cache os tíquetes de retomada aplicáveis em conexões futuras18. Cada tíquete de retomada em cache é indexado por um identificador de retomada (IDR) que é único para todas as cargas de trabalho em execução com a mesma identidade e na mesma célula de data center. Os tíquetes são criptografados por meio de chaves simétricas associadas aos identificadores correspondentes delas.

O ALTS aceita dois tipos de retomada de sessão:

  1. Retomada da sessão do lado do servidor: um cliente cria e criptografa um tíquete de retomada no qual estão a identidade do servidor e a chave secreta R derivada. O tíquete de retomada é enviado ao servidor no final do handshake na mensagem ClientFinished. Nas sessões futuras, o servidor poderá optar por retomar a sessão. Para isso, ele enviará o tíquete de volta para o cliente em uma mensagem ServerInit. Ao receber o tíquete, o cliente poderá recuperar a chave secreta R e a identidade do servidor. O cliente usará essas informações para retomar a sessão.

    O IDR é sempre associado a uma identidade e não a conexões específicas. No ALTS, vários clientes podem usar a mesma identidade no mesmo data center. Dessa forma, eles podem retomar sessões com servidores que, talvez, ainda não tenham se comunicado como, por exemplo, no caso de um balanceador de carga enviar o cliente para um servidor diferente que executa o mesmo aplicativo.

  2. Retomada da sessão do lado do cliente: no final do handshake, o cliente recebe do servidor o tíquete de retomada criptografado na mensagem ServerFinished. Esse tíquete inclui a chave secreta R e a identidade do cliente. O cliente, então, pode usar o tíquete para retomar uma conexão com qualquer servidor que compartilhe o mesmo IDR.

Quando uma sessão é retomada, a chave secreta R é usada para derivar novas chaves secretas da sessão: M', R' e A'. A chave secreta M' é usada na criptografia e autenticação das mensagens de payload, a chave secreta A', na autenticação das mensagens ServerFinished e ClientFinished e a chave secreta R' é encapsulada em um novo tíquete de retomada. Observe que uma chave secreta R nunca é usada mais de uma vez.

Vantagens e desvantagens

Ataques de falsificação de identidade pelo comprometimento de chave

Por padrão, o protocolo de handshake do ALTS é suscetível a ataques de falsificação de identidade pelo comprometimento de chave (KCI, na sigla em inglês). Caso um invasor comprometa a chave privada DH ou a chave de retomada de uma carga de trabalho, ele conseguirá usá-la para falsificar a identidade de outras cargas de trabalho19. Essa vulnerabilidade está explícita em nosso modelo de ameaças na retomada, já que o nosso objetivo é que diversas instâncias de uma mesma identidade possam emitir e utilizar os mesmos tíquetes de retomada.

Há uma variante do protocolo de handshake do ALTS que oferece proteção contra ataques de KCI. No entanto, só vale a pena usá-la em ambientes em que não é permitida a retomada.

Privacidade nas mensagens de handshake

O ALTS não foi projetado para disfarçar as identidades internas que estão se comunicando. Portanto, o sistema não criptografa as mensagens de handshake para ocultar as identidades das partes.

Perfect Forward Secrecy

O ALTS é compatível com o Perfect Forward Secrecy (PFS), mas esse recurso não fica ativado por padrão. Em vez disso, alternamos os certificados frequentemente para manter o sigilo do encaminhamento na maioria dos aplicativos. No TLS 1.2 (e versões anteriores), a retomada da sessão não está protegida pelo PFS. Ao ativar o PFS no ALTS, esse recurso também será ativado para as sessões retomadas.

Retomada sem tempo de retorno

Com o TLS 1.3, a sessão é retomada sem exigir qualquer tempo de retorno (0-RTT), mas isso resultará no enfraquecimento das propriedades de segurança20. Decidimos não incluir uma opção de 0-RTT no ALTS porque as conexões de RPC no Google são normalmente de longa duração. Dessa forma, não consideramos que a redução da latência de configuração do canal seja uma vantagem que compensa a complexidade adicional e/ou segurança reduzida que os processos de handshake com 0-RTT exigem.

Outras referências

Notas de rodapé

1Um microsserviço é um estilo arquitetônico que estrutura um aplicativo como uma coleção de serviços acoplados com flexibilidade, que implementam recursos de negócios.
2Uma carga de trabalho de produção é um aplicativo que os engenheiros do Google programam para ser executado nos data centers do Google.
3Para obter mais informações sobre como o Google protege dados em trânsito, consulte nosso whitepaper, Criptografia em trânsito no Google Cloud.
4Um modelo de confiança é o mecanismo com que um protocolo de segurança identifica, distribui e alterna credenciais e identidades.
5 Alguns serviços são gerenciados diretamente pelos desenvolvedores.
6 O Borgmaster é responsável pela programação e inicialização das cargas de trabalho de produção do Google. Para obter mais informações, consulte Gerenciamento de clusters em grande escala no Google com o Borg.
7Mais informações sobre frequências de rotação de certificados são encontradas em Criptografia em trânsito no Google Cloud.
8Caso uma chave tenha sido comprometida, o invasor detectará o tráfego apenas durante o tempo de vida útil do par de chaves.
11 ALTSd: um daemon responsável por, entre outras operações ALTS, criar certificados de handshake.
12 Na prática, a CA tem acesso às chaves privadas do serviço de assinatura, transformando as duas entidades lógicas em uma só entidade física.
13 HKDF-Extract e HKDF-Expand especificamente, conforme definido no RFC-5869.
14 A implementação do protocolo de handshake do ALTS concatena as mensagens ServerInit e ServerFinished em um único payload de transmissão.
16 A criptografia do payload é negociada como parte do protocolo de registro no handshake.
17 O esquema AES-GCM de 128 bits é baseado no NIST 800-38D e o AES-VCM é abordado detalhadamente em AES-VCM, uma construção do AES-GCM que usa uma função hash universal com base e um número inteiro.
18 A retomada da sessão ocorre com operações simétricas apenas quando os parâmetros temporários não estão envolvidos.