Application Layer Transport Security

O conteúdo aqui apresentado está correto a partir de dezembro de 2017. Este relatório técnico representa o status quo no momento em que foi escrito. As políticas e os sistemas de segurança do Google Cloud podem mudar no futuro, à medida que melhoramos continuamente a proteção dos nossos clientes.

Resumo ao nível de CIO

  • A Application Layer Transport Security (ALTS) da Google é um sistema de autenticação mútua e encriptação de transporte desenvolvido pela Google e usado normalmente para proteger as comunicações de chamadas de procedimentos remotos (RPC) na infraestrutura da Google. O ALTS é semelhante em conceito ao TLS autenticado mutuamente, mas foi concebido e otimizado para satisfazer as necessidades dos ambientes de centro de dados da Google.
  • O modelo de confiança ALTS foi adaptado para aplicações contentorizadas semelhantes à nuvem. As identidades estão associadas a entidades em vez de a um nome ou um anfitrião de servidor específico. Este modelo de confiança facilita a replicação perfeita de microsserviços, o equilíbrio de carga e o reagendamento entre anfitriões.
  • O ALTS baseia-se em dois protocolos: o protocolo de handshake (com retoma da sessão) e o protocolo de registo. Estes protocolos regem a forma como as sessões são estabelecidas, autenticadas, encriptadas e retomadas.
  • O ALTS é uma solução de segurança da camada de transporte personalizada que usamos na Google. Adaptámos o ALTS ao nosso ambiente de produção, pelo que existem algumas concessões entre o ALTS e a norma da indústria, o TLS. Pode encontrar mais detalhes na secção Compromissos.

Introdução

Os sistemas de produção na Google consistem numa constelação de microsserviços1 que, em conjunto, emitem O(1010) chamadas de procedimentos remotos (RPCs) por segundo. Quando um engenheiro da Google agenda uma carga de trabalho de produção2, todos os RPCs emitidos ou recebidos por essa carga de trabalho são protegidos com o ALTS por predefinição. Esta proteção automática, sem configuração, é fornecida pela segurança de transporte da camada de aplicação (ALTS) da Google. Além das proteções automáticas conferidas nas RPCs, o ALTS também facilita a replicação de serviços, o equilíbrio de carga e o reagendamento nas máquinas de produção. Este artigo descreve o ALTS e explora a respetiva implementação na infraestrutura de produção da Google.

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

Pré-requisitos: além desta introdução, assumimos uma compreensão básica da gestão de clusters na Google.

Segurança ao nível da aplicação e ALTS

Muitas aplicações, desde navegadores de Internet a VPNs, dependem de protocolos de comunicação seguros, como TLS (Transport Layer Security) e IPSec, para proteger os dados em trânsito3. Na Google, usamos o ALTS, um sistema de autenticação mútua e encriptação de transporte que é executado na camada de aplicação, para proteger as comunicações RPC. A utilização da segurança ao nível da aplicação permite que as aplicações tenham uma identidade remota autenticada, que pode ser utilizada para implementar políticas de autorização detalhadas.

Por que não usar o TLS?

Pode parecer invulgar a Google usar uma solução de segurança personalizada, como o ALTS, quando a maioria do tráfego da Internet atual é encriptada através do TLS. O ALTS começou a ser desenvolvido na Google em 2007. Na altura, o TLS estava incluído no suporte de muitos protocolos antigos que não cumpriam os nossos padrões de segurança mínimos. Podíamos ter concebido a nossa solução de segurança adotando os componentes TLS de que precisávamos e implementando os que queríamos. No entanto, as vantagens de criar um sistema mais adequado à Google desde o início superaram as vantagens de aplicar patches a um sistema existente. Além disso, o ALTS é mais adequado às nossas necessidades e, historicamente, mais seguro do que o TLS mais antigo. Seguem-se as principais diferenças entre o TLS e o ALTS.

  • Existe uma diferença significativa entre os modelos de confiança4 do TLS com semântica HTTPS e ALTS. No primeiro caso, as identidades do servidor estão associadas a um nome específico e a um esquema de nomenclatura correspondente. No ALTS, a mesma identidade pode ser usada com vários esquemas de nomenclatura. Este nível de indireção oferece mais flexibilidade e simplifica bastante o processo de replicação de microsserviços, equilíbrio de carga e reagendamento entre anfitriões.
  • Em comparação com o TLS, o ALTS é mais simples no seu design e implementação. Como resultado, é mais fácil monitorizar erros e vulnerabilidades de segurança através da inspeção manual do código-fonte ou de testes de fuzzing extensivos.
  • O ALTS usa o Protocol Buffer para serializar os respetivos certificados e mensagens de protocolo, enquanto o TLS usa certificados X.509 codificados com ASN.1. A maioria dos nossos serviços de produção usa buffers de protocolo para comunicação (e, por vezes, armazenamento), o que torna o ALTS mais adequado para o ambiente da Google.

ALTS Design

O ALTS foi concebido para ser um sistema fidedigno e altamente fiável que permite a autenticação e a segurança de serviço para serviço com um envolvimento mínimo do utilizador. Para tal, as propriedades indicadas abaixo fazem parte do design do ALTS:

  • Transparência: a configuração do ALTS é transparente para a camada de aplicação. Por predefinição, os RPCs de serviço são protegidos através do ALTS. Isto permite que os programadores de aplicações se concentrem na lógica funcional dos respetivos serviços sem terem de se preocupar com a gestão de credenciais ou as configurações de segurança. Durante o estabelecimento de ligação entre serviços, o ALTS fornece às aplicações uma identidade remota autenticada que pode ser usada para verificações de autorização detalhadas e auditoria.
  • Criptografia de vanguarda: as primitivas e os protocolos criptográficos usados pelo ALTS estão atualizados com os ataques conhecidos atuais. O ALTS é executado em máquinas controladas pela Google, o que significa que os protocolos criptográficos suportados podem ser facilmente atualizados e implementados rapidamente.
  • Modelo de identidade: o ALTS realiza a autenticação principalmente por identidade e não por nome do anfitrião. Na Google, cada entidade de rede (por exemplo, um utilizador empresarial, uma máquina física ou um serviço ou uma carga de trabalho de produção) tem uma identidade associada. As comunicações entre serviços são autenticadas mutuamente.
  • Distribuição de chaves: o ALTS baseia-se no facto de cada carga de trabalho ter uma identidade, que é expressa como um conjunto de credenciais. Estas credenciais são implementadas em cada carga de trabalho durante a inicialização, sem envolvimento do utilizador. Em paralelo, é estabelecida uma raiz de confiança e uma cadeia de confiança para estas credenciais para máquinas e cargas de trabalho. O sistema permite a rotação e a revogação automáticas de certificados sem a intervenção dos programadores de aplicações.
  • Escalabilidade: o ALTS foi concebido para ser muito escalável de modo a suportar a escala massiva da infraestrutura da Google. Este requisito resultou no desenvolvimento da Retoma da sessão eficiente.
  • Ligações de longa duração: as operações criptográficas de troca de chaves autenticadas são computacionalmente dispendiosas. Para acomodar a escala da infraestrutura da Google, após uma sincronização inicial do ALTS, as ligações podem ser mantidas durante mais tempo para melhorar o desempenho geral do sistema.
  • Simplicidade: o TLS inclui, por predefinição, suporte para versões de protocolos antigas e retrocompatibilidade. O ALTS é consideravelmente mais simples, uma vez que a Google controla os clientes e os servidores, que foram concebidos para suportar nativamente o ALTS.

Modelo de fidedignidade do ALTS

O ALTS realiza a autenticação principalmente por identidade e não por anfitrião. Na Google, cada entidade de rede (por exemplo, um utilizador empresarial, uma máquina física ou um serviço de produção) tem uma identidade associada. Estas identidades estão incorporadas em certificados ALTS e são usadas para a autenticação de pares durante o estabelecimento de ligações seguras. O modelo que seguimos é que os nossos serviços de produção são executados como entidades de produção que podem ser geridas pelos nossos engenheiros de fiabilidade de sites (EFS)5. As versões de desenvolvimento destes serviços de produção são executadas como entidades de teste que podem ser geridas por engenheiros de fiabilidade do site e programadores.

Por exemplo, vamos supor que temos um produto com dois serviços: service-frontend e service-backend. Os SREs podem iniciar a versão de produção destes serviços: service-frontend-prod e service-backend-prod. Os programadores podem criar e iniciar versões de desenvolvimento destes serviços, service-frontend-dev e service-backend-dev, para fins de teste. A configuração de autorização nos serviços de produção vai ser configurada para não confiar nas versões de desenvolvimento dos serviços.

Credenciais ALTS

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

  • Certificado principal: assinado por um serviço de assinatura remoto e usado para validar certificados de handshake. O certificado principal contém uma chave pública associada a uma chave privada principal, por exemplo: Par de chaves RSA. Esta chave privada é usada para assinar certificados de handshake. Estes certificados, quando exercidos em combinação com a política ALTS abordada abaixo, são essencialmente certificados de autoridade de certificação (AC) intermédios restritos. Normalmente, os certificados principais são emitidos para máquinas de produção e programadores de cargas de trabalho em contentores, como o Borgmaster6.
  • Certificado de handshake: criado e assinado localmente pela chave privada principal. Este certificado contém os parâmetros usados durante o handshake ALTS (estabelecimento de ligação segura), por exemplo, parâmetros Diffie-Hellman (DH) estáticos e as cifras de handshake. Além disso, o certificado de handshake contém o certificado principal do qual é derivado, ou seja, o certificado associado à chave privada principal que assina o certificado de handshake.
  • Chave de retoma: é um segredo usado para encriptar os pedidos de retoma. Esta chave é identificada por um ID do identificador de retoma R que é exclusivo e partilhado entre cargas de trabalho de produção executadas com a mesma identidade e na mesma célula do centro de dados. Para ver mais detalhes sobre o recomeço da sessão no ALTS, consulte o artigo Recomeço da sessão.

A Figura 1 mostra a cadeia de certificados ALTS, que consiste numa chave de verificação do serviço de assinatura, num certificado principal e num certificado de handshake. As chaves de validação do serviço de assinatura são a raiz de confiança no ALTS e estão instaladas em todas as máquinas da Google nas nossas redes de produção e empresariais.

Figura 1: cadeia de certificados ALTS

No ALTS, um serviço de assinatura certifica os certificados principais que, por sua vez, certificam os certificados de Handshake. Como os certificados de Handshake são criados com mais frequência do que os certificados principais, esta arquitetura reduz a carga no serviço de assinatura. A rotação de certificados ocorre com frequência na Google, especialmente para certificados de handshake 7. Esta rotação frequente compensa os pares de troca de chaves estáticos transportados pelos certificados de handshake8.

Emissão de certificados

Para participar num handshake seguro ALTS, as entidades na rede têm de ser aprovisionadas com certificados de handshake. Primeiro, o emissor obtém um certificado principal assinado pelo serviço de assinatura e, opcionalmente, transfere-o para a entidade. Em seguida, é criado um certificado de handshake e assinado pela chave privada principal associada.

Normalmente, o emissor é a nossa autoridade de certificação (AC) interna quando emite certificados para máquinas e humanos, ou o Borgmaster quando emite certificados para cargas de trabalho. No entanto, pode ser qualquer outra entidade, por exemplo, um Borgmaster restrito para uma célula de centro de dados de teste.

A Figura 2 mostra como o serviço de assinatura é usado para criar um certificado principal. O processo consiste nos seguintes passos.

Figura 2: emissão de certificados

  1. O emissor do certificado envia um pedido de assinatura de certificado (CSR) para o serviço de assinatura. Este pedido pede ao serviço de assinatura que crie um certificado para a identidade A. Esta identidade, por exemplo, pode ser um utilizador empresarial ou a identidade de um serviço de produção da Google.
  2. O serviço de assinatura define o emissor do certificado (incluído no CSR) como o requerente (o emissor do certificado neste caso) e assina-o. Lembre-se de que a chave pública (de validação) do serviço de assinatura correspondente está instalada em todas as máquinas da Google.
  3. O serviço de assinatura envia o certificado assinado de volta.
  4. É criado um certificado de handshake para a identidade A e é assinado pela chave privada associada ao certificado principal

Conforme mostrado no processo acima, com o ALTS, o emissor e o signatário de um certificado são duas entidades lógicas diferentes. Neste caso, o emissor é a entidade Certificate Issuer, enquanto o signatário é o serviço de assinatura.

Existem três categorias comuns de certificados no ALTS, nomeadamente: humano, máquina e carga de trabalho. As secções seguintes descrevem como cada um destes certificados é criado e usado no ALTS.

Certificados humanos

Na Google, usamos ALTS para proteger RPCs emitidos por utilizadores humanos para serviços de produção. Para emitir um RPC, um utilizador tem de fornecer um certificado de handshake válido. Por exemplo, se a Alice quiser usar uma aplicação para emitir um RPC seguro com ALTS, pode autenticar-se na nossa AC interna. A Alice autentica-se na AC através do respetivo nome de utilizador, palavra-passe e autenticação de dois fatores. Esta operação resulta na obtenção de um certificado de handshake por parte de Alice válido durante 20 horas.

Certificados de máquinas

Todas as máquinas de produção nos centros de dados da Google têm um certificado principal da máquina. Este certificado é usado para criar certificados de handshake para aplicações principais nesse computador, por exemplo, daemons de gestão de computadores. A identidade principal incorporada num certificado de máquina refere-se à finalidade típica da máquina. Por exemplo, as máquinas usadas para executar diferentes tipos de cargas de trabalho de produção e desenvolvimento podem ter identidades diferentes. Os certificados principais só são utilizáveis por máquinas que executam stacks de software validadas. Em alguns casos, esta confiança baseia-se em hardware de segurança personalizado9. Os certificados principais da máquina de produção são emitidos pela AC e são alterados a cada poucos meses. Além disso, todos os certificados de handshake são rodados a cada poucas horas.

Certificados de cargas de trabalho

Uma vantagem fundamental do ALTS é que funciona com base na ideia de uma identidade de carga de trabalho, o que facilita a replicação de serviços, o equilíbrio de carga e o reagendamento em várias máquinas. Na nossa rede de produção, usamos um sistema denominado Borg10 para a gestão de clusters e a atribuição de recursos de máquinas à escala. A forma como o Borg emite certificados faz parte da implementação da identidade da carga de trabalho independente da máquina do ALTS.

Cada carga de trabalho na nossa rede de produção é executada numa célula Borg. Cada célula contém um controlador logicamente centralizado denominado Borgmaster e vários processos de agente denominados Borglets que são executados em cada máquina nessa célula. As cargas de trabalho são inicializadas com certificados de handshake de carga de trabalho associados emitidos pelo Borgmaster. A Figura 3 mostra o processo de certificação da carga de trabalho no ALTS com o Borg.

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

O Borgmaster já está pronto para agendar cargas de trabalho que precisam de usar ALTS. Os passos abaixo ocorrem quando um cliente agenda uma carga de trabalho para ser executada no Borg como uma determinada identidade.

  1. Cada Borgmaster é pré-instalado com um certificado principal da máquina e uma chave privada associada (não apresentada no diagrama).
  2. O ALTSd11 gera um certificado de handshake do Borgmaster e assina-o com a chave privada principal da máquina. Este certificado de handshake permite que o Borgmaster emita RPCs seguras com ALTS.
  3. O Borgmaster cria um certificado principal de carga de trabalho base e a chave privada correspondente. O Borgmaster inicia um pedido (um RPC protegido por ALTS) para obter este certificado principal da carga de trabalho base assinado pelo serviço de assinatura. Como resultado, o serviço de assinatura indica o Borgmaster como o emissor neste certificado.
  4. O Borgmaster verifica se o cliente tem autorização para executar cargas de trabalho como a identidade especificada na configuração da carga de trabalho. Nesse caso, o Borgmaster agenda a carga de trabalho do Borg no Borglet e emite um certificado de sincronização de carga de trabalho e a respetiva chave privada. Este certificado é encadeado a partir do certificado principal da carga de trabalho base. O certificado de Workload Handshake e a respetiva chave privada são, em seguida, entregues em segurança ao Borglet (através de um canal protegido por ALTS autenticado mutuamente entre o Borgmaster e o Borglet). O Borgmaster roda o respetivo certificado principal da carga de trabalho base e reemite certificados de handshake para todas as cargas de trabalho em execução aproximadamente a cada dois dias. Além disso, cada carga de trabalho executada como o mesmo utilizador na mesma célula recebe a mesma chave de retoma e identificador (IDR) aprovisionado pelo Borgmaster.
  5. Quando a carga de trabalho precisa de fazer um RPC seguro com ALTS, usa o certificado de handshake da carga de trabalho no protocolo de handshake. O IDR também é usado como parte do handshake para iniciar a retoma da sessão. Para mais informações sobre a retoma de sessões no ALTS, consulte o artigo Retoma de sessões.

Aplicação da política ALTS

A política ALTS é um documento que indica que emissores estão autorizados a emitir determinadas categorias de certificados para determinadas identidades. É distribuído a todas as máquinas na nossa rede de produção. Por exemplo, a política ALTS permite que a AC emita certificados para máquinas e humanos. Também permite que o Borgmaster emita certificados para cargas de trabalho.

Constatámos que a aplicação de políticas durante a validação de certificados, em oposição à emissão de certificados, é uma abordagem mais flexível, uma vez que permite a aplicação de diferentes políticas em diferentes tipos de implementações. Por exemplo, podemos querer que uma política num cluster de teste seja mais permissiva do que uma num cluster de produção.

Durante a negociação ALTS, a validação de certificados inclui uma verificação da política ALTS. A política garante que o emissor indicado no certificado que está a ser validado está autorizado a emitir esse certificado. Se não for esse o caso, o certificado é rejeitado e o processo de handshake falha. A Figura 4 ilustra como funciona a aplicação de políticas no ALTS. Seguindo o cenário na Figura 2, suponha que a Mariana (uma utilizadora corporativa que quer aumentar os seus privilégios) quer emitir um certificado principal ao administrador de rede, que é uma identidade poderosa que pode reconfigurar a rede. É evidente que a Mallory não tem autorização na política ALTS para realizar esta operação.

Figura 4: emissão e utilização de certificados

  1. A Mallory emite um certificado principal para a identidade de administrador de rede e recebe a respetiva assinatura do serviço de assinatura. Isto é semelhante aos três primeiros passos na Figura 2.
  2. A Mallory cria e assina um certificado de handshake localmente para o administrador de rede, usando a chave privada principal associada ao certificado principal criado.
  3. Se a Mallory tentar roubar a identidade do administrador de rede através do certificado de handshake criado, o agente de aplicação da política ALTS, no ponto de rede com o qual a Mallory tenta comunicar, bloqueia a operação.

Revogação de certificados

Na Google, um certificado é invalidado quando expira ou é incluído na nossa Lista de revogação de certificados (LRC). Esta secção descreve a conceção dos mecanismos de revogação de certificados internos da Google.

Todos os certificados emitidos para utilizadores corporativos humanos têm uma data/hora de expiração diária que força os utilizadores a autenticarem-se novamente todos os dias. Muitos dos certificados emitidos para máquinas de produção não usam indicações de tempo de validade. Evitamos basear-nos em datas/horas para fazer expirar os certificados de produção, uma vez que isso pode originar interrupções causadas por problemas de sincronização do relógio. Em alternativa, usamos a CRL como a nossa fonte de verdade para a rotação e o tratamento de resposta a incidentes de certificados. A Figura 5 mostra como funciona a LCR.

Figura 5: criação do certificado principal com um RevocationID

  1. Quando uma instância da nossa CA é inicializada12, contacta o serviço de LCR e pede um intervalo de IDs de revogação. Um ID de revogação é um ID longo de 64 bits com dois componentes: uma categoria de certificado de 8 bits (por exemplo, certificado humano ou de máquina) e um identificador de certificado de 56 bits. O serviço CRL escolhe um intervalo destes IDs e devolve-o à AC.
  2. Quando a CA recebe um pedido de um certificado principal, cria o certificado e incorpora um ID de revogação que escolhe no intervalo.
  3. Em paralelo, a AC mapeia o novo certificado para o ID de revogação e envia estas informações para o serviço de LCR.
  4. A AC emite o certificado principal.

Os IDs de revogação atribuídos aos certificados de handshake dependem da forma como o certificado é usado. Por exemplo, os certificados de handshake emitidos para utilizadores corporativos humanos herdam o ID de revogação do certificado principal do utilizador. Para certificados de handshake emitidos para cargas de trabalho do Borg, o ID de revogação é atribuído pelo intervalo de IDs de revogação do Borgmaster. Este intervalo de IDs é atribuído ao Borgmaster pelo serviço CRL num processo semelhante ao apresentado na Figura 5. Sempre que um par está envolvido num handshake ALTS, verifica uma cópia local do ficheiro CRL para garantir que o certificado do par remoto não foi revogado

O serviço CRL compila todos os IDs de revogação num único ficheiro que pode ser enviado para as máquinas Google que usam o ALTS. Embora a base de dados da LCR tenha várias centenas de megabytes, o ficheiro LCR gerado tem apenas alguns megabytes devido a várias técnicas de compressão.

Protocolos ALTS

O ALTS baseia-se em dois protocolos: o protocolo de handshake (com retoma da sessão) e o protocolo de registo. Esta secção oferece uma vista geral de cada protocolo. Estas descrições gerais não devem ser interpretadas como especificações detalhadas dos protocolos.

Protocolo de handshake

O protocolo de handshake ALTS é um protocolo de troca de chaves autenticado baseado em Diffie-Hellman que suporta a confidencialidade perfeita (PFS) e a retoma da sessão. A infraestrutura ALTS garante que cada cliente e servidor tem um certificado com as respetivas identidades e uma chave de curva elíptica Diffie-Hellman (ECDH) que se encadeia a uma chave de validação do serviço de assinatura fidedigna. No ALTS, o PFS não está ativado por predefinição porque estas chaves ECDH estáticas são atualizadas com frequência para renovar a confidencialidade futura, mesmo que o PFS não seja usado numa negociação. Durante um handshake, o cliente e o servidor negociam de forma segura uma chave de encriptação em trânsito partilhada, e o protocolo de registo que a chave de encriptação vai usar para proteger. Por exemplo, o cliente e o servidor podem concordar com uma chave de 128 bits que vai ser usada para proteger uma sessão RPC através de AES-GCM. O handshake consiste em quatro mensagens de Protocol Buffer serializadas, cuja vista geral pode ser vista na Figura 6.

Figura 6: mensagens do protocolo de confirmação ALTS

  1. O cliente inicia a troca de informações enviando uma mensagem ClientInit. Esta mensagem contém o certificado de handshake do cliente e uma lista das cifras relacionadas com o handshake e os protocolos de registo suportados pelo cliente. Se o cliente estiver a tentar retomar uma sessão terminada, inclui um identificador de retoma e um pedido de retoma do servidor encriptado.

  2. Após a receção da mensagem ClientInit, o servidor valida o certificado do cliente. Se for válido, o servidor escolhe uma cifra de handshake e um protocolo de registo na lista fornecida pelo cliente. O servidor usa uma combinação das informações contidas na mensagem ClientInit e das suas próprias informações locais para calcular o resultado da troca DH. Este resultado é usado como entrada para as funções de derivação de chaves13 juntamente com a transcrição do protocolo para gerar os seguintes segredos da sessão:

    • Uma chave secreta record protocol M usada para encriptar e autenticar mensagens de payload.
    • Um segredo de retoma R a ser usado num pedido de retoma em sessões futuras.
    • Um segredo do autenticador A.

    O servidor envia uma mensagem ServerInit que contém o respetivo certificado, a cifra de handshake escolhida, o protocolo de registo e um pedido de retoma encriptado opcional.

  3. O servidor envia uma mensagem ServerFinished que contém um autenticador de negociação14. O valor deste autenticador é calculado através de um código de autenticação de mensagens baseado em hash (HMAC) calculado sobre uma string de bits predefinida e o segredo do autenticador A.

  4. Assim que o cliente recebe ServerInit, valida o certificado do servidor, calcula o resultado da troca DH de forma semelhante ao servidor e deriva os mesmos segredos M, R e A. O cliente usa o A derivado para validar o valor do autenticador na mensagem ServerFinished recebida. Neste ponto do processo de negociação, o cliente pode começar a usar M para encriptar mensagens. Como o cliente já consegue enviar mensagens encriptadas, podemos dizer que o ALTS tem um protocolo de handshake de um RTT.

  5. No final da negociação, o cliente envia uma mensagem ClientFinished com um valor do autenticador semelhante (consulte o passo 3) calculado sobre uma string de bits predefinida diferente. Se necessário, o cliente pode incluir um pedido de retoma encriptado para sessões futuras. Assim que esta mensagem for recebida e validada pelo servidor, o protocolo de sincronização ALTS é concluído e o servidor pode começar a usar M para encriptar e autenticar mais mensagens de conteúdo.

Protocolo de registo

A secção Protocolo de handshake descreveu como usamos o protocolo de handshake para negociar um segredo do protocolo de registo. Este segredo do protocolo é usado para encriptar e autenticar o tráfego de rede. A camada da pilha que executa estas operações é denominada Protocolo de registo ALTS (ALTSRP).

O ALTSRP contém um conjunto de esquemas de encriptação com tamanhos de chaves variáveis e funcionalidades de segurança. Durante o handshake, o cliente envia a respetiva lista de esquemas preferenciais, ordenada por preferência. O servidor escolhe o primeiro protocolo na lista do cliente que corresponde à configuração local do servidor. Este método de seleção de esquemas permite que os clientes e os servidores tenham preferências de encriptação diferentes e permite-nos introduzir (ou remover) esquemas de encriptação.

Enquadramento

Os frames são a unidade de dados mais pequena no ALTS. Consoante o respetivo tamanho, cada mensagem ALTSRP pode consistir num ou mais frames. Cada frame contém os seguintes campos:

  • Length: um valor não assinado de 32 bits que indica o comprimento da frame, em bytes. Este campo de comprimento de 4 bytes não está incluído no comprimento total da moldura.
  • Type: um valor de 32 bits que especifica o tipo de frame, por exemplo, frame de dados.
  • Payload: os dados reais autenticados e, opcionalmente, encriptados que estão a ser enviados.

O comprimento máximo de um frame é de 1 MB mais 4 bytes de comprimento. Para os protocolos RPC atuais, limitamos ainda mais o comprimento dos frames, uma vez que os frames mais curtos requerem menos memória para o armazenamento em buffer. Os frames maiores também podem ser explorados por um potencial atacante durante um ataque de negação de serviço (DoS) numa tentativa de sobrecarregar um servidor. Além de limitar o comprimento dos frames, também restringimos o número de frames que podem ser encriptados com o mesmo segredo M do protocolo de registo. O limite varia consoante o esquema de encriptação usado para encriptar e desencriptar a carga útil da frame. Quando este limite é atingido, a ligação tem de ser fechada.

Payload

Nos ALTS, cada frame contém uma carga útil com proteção de integridade e, opcionalmente, encriptada15. À data da publicação deste artigo, o ALTS suporta os seguintes modos:

  • AES-128-GCM, AES-128-VCM: modos AES-GCM e AES-VCM, respetivamente, com chaves de 128 bits. Estes modos protegem a confidencialidade e a integridade da carga útil através dos esquemas GCM e VCM16, respetivamente.
  • AES-128-GMAC, AES-128-VMAC: estes modos suportam a proteção apenas de integridade usando GMAC e VMAC, respetivamente, para o cálculo de etiquetas. A carga útil é transferida em texto simples com uma etiqueta criptográfica que protege a respetiva integridade.

Na Google, usamos diferentes modos de proteção consoante o modelo de ameaça e os requisitos de desempenho. Se as entidades de comunicação estiverem dentro do mesmo limite físico controlado pela Google ou em nome desta, é usada a proteção apenas de integridade. Estas entidades podem continuar a optar pela atualização para a encriptação autenticada com base na sensibilidade dos respetivos dados. Se as entidades que comunicam estiverem em limites físicos diferentes controlados pela Google ou em nome desta e, por isso, as comunicações passarem pela rede de área alargada, atualizamos automaticamente a segurança da ligação para encriptação autenticada, independentemente do modo escolhido. A Google aplica diferentes proteções aos dados em trânsito quando são transmitidos fora de um limite físico controlado pela Google ou em nome desta, uma vez que não é possível aplicar as mesmas medidas de segurança rigorosas.

Cada frame está protegido contra adulteração em separado e, opcionalmente, encriptado. Ambos os pares mantêm os contadores de pedidos e respostas, que são sincronizados durante o funcionamento normal. Se o servidor receber pedidos desordenados ou repetidos, a validação da integridade criptográfica falha, o que faz com que o pedido seja ignorado. Da mesma forma, o cliente rejeita uma resposta repetida ou desordenada. Além disso, a manutenção dos contadores por parte de ambos os pares (em vez de incluir os respetivos valores no cabeçalho da frame) poupa bytes adicionais na transmissão.

Retoma da sessão

O ALTS permite que os respetivos utilizadores retomem sessões anteriores sem terem de realizar operações criptográficas assimétricas complexas. A retoma da sessão é uma funcionalidade integrada no protocolo de handshake ALTS.

A troca de informações ALTS permite que os clientes e os servidores troquem (e armazenem em cache) de forma segura vales de retoma que podem ser usados para retomar ligações futuras17. Cada pedido de retoma em cache é indexado por um identificador de retoma (IDR) que é exclusivo para cargas de trabalho executadas com a mesma identidade e na mesma célula do centro de dados. Estes pedidos são encriptados através de chaves simétricas associadas aos respetivos identificadores.

O ALTS suporta dois tipos de retoma de sessão:

  1. Retoma da sessão do lado do servidor: um cliente cria e encripta um bilhete de retoma que contém a identidade do servidor e o segredo de retoma derivado R. O pedido de retoma é enviado para o servidor no final do handshake, na mensagem ClientFinished. Em sessões futuras, o servidor pode optar por retomar a sessão enviando o pedido de volta ao cliente na respetiva mensagem ServerInit. Após a receção do pedido, o cliente pode recuperar o segredo de retoma R e a identidade do servidor. O cliente pode usar estas informações para retomar a sessão.

    O IDR está associado a uma identidade e não a ligações específicas. No ALTS, vários clientes podem usar a mesma identidade no mesmo centro de dados. Isto permite que os clientes retomem sessões com servidores com os quais podem não ter comunicado anteriormente, por exemplo, se um equilibrador de carga enviar o cliente para um servidor diferente que execute a mesma aplicação.

  2. Retoma da sessão do lado do cliente: no final de um handshake, o servidor envia um pedido de retoma encriptado ao cliente na mensagem ServerFinished. Este pedido inclui o segredo de retoma R e a identidade do cliente. O cliente pode usar este pedido para retomar uma ligação com qualquer servidor que partilhe o mesmo IDR.

Quando uma sessão é retomada, o segredo de retoma R é usado para derivar novos segredos de sessão M′, R′ e A′. M′ é usado para encriptar e autenticar mensagens de payload, A′ é usado para autenticar mensagens ServerFinished e ClientFinished, e R′ é encapsulado num novo pedido de retoma. Tenha em atenção que o mesmo segredo de retoma não é usado mais do que uma vez.

Compromissos

Ataques de roubo de identidade por violação de chaves

Por definição, o protocolo de handshake ALTS é suscetível a ataques de roubo de chaves de roubo de identidade (KCI). Se um adversário comprometer a chave privada DH ou a chave de retoma de uma carga de trabalho, pode usar a chave para roubar a identidade de outras cargas de trabalho para esta carga de trabalho18. Isto está explicitamente no nosso modelo de ameaças de retoma, uma vez que queremos que os pedidos de retoma emitidos por uma instância de uma identidade sejam utilizáveis por outras instâncias dessa identidade.

Existe uma variante do protocolo de handshake ALTS que protege contra ataques KCI, mas só valeria a pena usar em ambientes onde a retoma não é desejada.

Privacidade para mensagens de handshake

O ALTS não foi concebido para ocultar as identidades internas que estão a comunicar, pelo que não encripta nenhuma mensagem de handshake para ocultar as identidades dos pares.

Perfect Forward Secrecy

A Perfect Forward Secrecy (PFS) é suportada, mas não está ativada por predefinição no ALTS. Em alternativa, usamos a rotação frequente de certificados para estabelecer a confidencialidade futura para a maioria das aplicações. Com o TLS 1.2 (e as respetivas versões anteriores), a retoma da sessão não está protegida com PFS. Quando o PFS está ativado com o ALTS, o PFS também está ativado para sessões retomadas.

Retoma sem viagens de ida e volta

O TLS 1.3 oferece retoma de sessão que requer zero viagens de ida e volta (0-RTT), no entanto, tem propriedades de segurança mais fracas19. Decidimos não incluir uma opção 0-RTT em ALTS porque as ligações RPC na Google são geralmente de longa duração. Consequentemente, a redução da latência de configuração do canal não foi uma boa compensação para a complexidade adicional e/ou a segurança reduzida que as negociações 0-RTT requerem.

Outras referências

Notas de rodapé

1 Um microsserviço é um estilo arquitetónico que estrutura uma aplicação como uma coleção de serviços fracamente acoplados que implementam capacidades empresariais.
2 Uma carga de trabalho de produção é uma aplicação que os engenheiros da Google agendam para ser executada nos centros de dados da Google.
3 Para mais informações sobre como a Google protege os dados em trânsito, consulte o nosso documento técnico, Encriptação em trânsito no Google Cloud.
4 Um modelo de confiança é o mecanismo através do qual um protocolo de segurança identifica, distribui e roda credenciais e identidades.
5 Alguns serviços são geridos diretamente pelos programadores.
6 O Borgmaster é responsável pelo agendamento e pela inicialização das cargas de trabalho de produção da Google. Para mais informações, consulte o artigo Gestão de clusters em grande escala na Google com o Borg.
7 Pode encontrar mais informações sobre as frequências de rotação de certificados em Encriptação em trânsito no Google Cloud.
8 Se uma chave for comprometida, apenas o tráfego durante a vida útil deste par de chaves será detetável pelo atacante.
11 ALTSd: um daemon responsável, entre outras operações ALTS, pela criação de certificados de handshake.
12 Na prática, a AC tem acesso às chaves privadas do serviço de assinatura, o que torna as duas entidades lógicas numa única entidade física.
13 Especificamente, HKDF-Extract e HKDF-Expand, conforme definido na RFC-5869.
14 A implementação do protocolo de handshake ALTS concatena as mensagens ServerInit e ServerFinished num único payload de transmissão.
15 A encriptação da carga útil é negociada como parte do protocolo de registo no handshake.
16 O esquema AES-GCM de 128 bits baseia-se na NIST 800-38D, e o AES-VCM é abordado detalhadamente em AES-VCM, An AES-GCM Construction Using an Integer-Based Universal Hash Function.
17 O recomeço da sessão envolve operações simétricas simples apenas se não estiverem envolvidos parâmetros efémeros.