Serviço Google Cloud Key Vault

Descrevemos um serviço em nuvem que usa hardware seguro para armazenar chaves criptográficas de modo que o acesso a elas seja protegido por um fator de conhecimento de baixa entropia (por exemplo, um PIN da tela de bloqueio). O hardware seguro foi projetado para impedir ataques de força bruta, tornando as chaves criptográficas armazenadas permanentemente irrecuperáveis após muitas tentativas de fornecer o fator de conhecimento correto.

Autor:Shabsi Walfish
Data da versão:2018-03-06

Observação: este documento ainda está em andamento, e os detalhes da implementação ainda estão sendo finalizados. À medida que o sistema se estabiliza e mais documentação pode ser produzida, vamos atualizar este documento com informações mais detalhadas, principalmente em conjunto com lançamentos de código aberto relevantes.

Visão geral

Tradicionalmente, a criptografia, que é usada para garantir a privacidade dos dados, exige o uso de segredos que têm alta entropia do ponto de vista do invasor. A alta entropia é necessária porque o esquema de criptografia precisa resistir a ataques de força bruta que exploram o espaço de todos os segredos prováveis até que o correto seja encontrado. Dada a disponibilidade atual de capacidade computacional, um requisito de entropia mínimo razoável para segredos criptográficos pode estar na faixa de 70 a 80 bits. Infelizmente, os seres humanos têm dificuldade para memorizar e lembrar senhas ou outros segredos com essa quantidade de entropia¹, especialmente se elas forem usadas raramente. No entanto, o uso frequente de uma senha de alta entropia é difícil e tedioso. Isso nos deixa com um problema desafiador: como podemos proteger dados particulares com a tecnologia de criptografia se quisermos que o segredo seja um "fator de conhecimento" que provavelmente será lembrado pelo usuário? Por vários motivos, esse problema é tão difícil de resolver que os serviços de armazenamento em nuvem normalmente criptografam dados apenas com segredos gerenciados pelo próprio provedor de armazenamento em nuvem, em vez de depender do usuário para lembrar o próprio segredo.

Uma abordagem para preencher a lacuna entre os requisitos de segredos criptográficos e segredos memoráveis por humanos é usar um serviço do Cloud Key Vault (CKV) para armazenar uma "chave de recuperação" de alta entropia, protegida por um segredo memorável por humanos de baixa entropia. O serviço de CKV só vai liberar a chave de recuperação para uma parte que comprove o conhecimento do segredo memorável humano correto. Os ataques de força bruta contra o segredo memorável humano podem ser frustrados pelo serviço CKV, que impõe um limite absoluto ao número de tentativas para provar o conhecimento do segredo. A chave de recuperação é uma chave simétrica criptográfica padrão, adequada para uso com um esquema de criptografia (autenticado) que pode criptografar facilmente um grande volume de dados (como um backup de disco) que pode ser armazenado com segurança em qualquer lugar. Esses dados criptografados são inúteis para qualquer pessoa que não possa acessar a chave de recuperação.

Este documento técnico descreve nossa abordagem para criar um serviço do Cloud Key Vault usando módulos de hardware confiáveis (THMs, na sigla em inglês). Nossa primeira implementação do serviço de CKV foi projetada para proteger chaves de recuperação com o fator de conhecimento da tela de bloqueio (LSKF, na sigla em inglês) do usuário, que é o PIN secreto, a senha ou o padrão de deslizar usado para desbloquear smartphones. Seres humanos podem lembrar com segurança do LSKF. Ao mesmo tempo, esses segredos do LSKF geralmente têm entropia suficiente para resistir a um invasor que tem um número muito limitado de tentativas, o que os torna adequados para o serviço CKV.

A primeira aplicação do nosso serviço do Cloud Key Vault será ativar os backups criptografados do lado do cliente do Android. Anteriormente, os arquivos criptografados localmente no dispositivo Android usavam uma chave protegida com a LSKF do usuário, mas os backups desses arquivos armazenados (e criptografados) na nuvem não eram protegidos pela LSKF. Pela primeira vez, o Cloud Key Vault também permite a proteção da tela de bloqueio para backups do Android armazenados na nuvem. Isso significa que os servidores do Google não podem acessar ou restaurar o conteúdo dos backups criptografados. Somente um dispositivo com o LSKF do usuário pode descriptografar os backups.

Conceitos centrais

Inicialmente, a única plataforma de cliente com suporte para o serviço do Cloud Key Vault é o sistema operacional Android 9 Pie. Quando nos referimos ao cliente neste documento técnico, estamos nos referindo a um dispositivo com o sistema operacional Android 9 Pie e os Serviços do Google Play. Nossa implementação do lado do servidor é executada em servidores do Google especialmente designados que têm um chip extra do Titan² instalado. O chip Titan desenvolvido pelo Google serve como o componente de hardware no nosso Módulo de Hardware Confiável. Ele é provisionado especialmente com um carregador de inicialização e um firmware personalizados que implementam nossos protocolos e mecanismos de aplicação de segurança (conforme descrito aqui). Usamos técnicas de atestado de hardware para garantir que nosso protocolo esteja realmente sendo executado no hardware Titan.

O serviço de CKV precisa ser dimensionado para processar o tráfego de bilhões³ de dispositivos Android, sem perder uma quantidade significativa de dados do usuário devido a falhas de hardware (por exemplo, chips queimados) ou interrupções prolongadas devido à manutenção do data center. Por esse motivo, os servidores com os chips Titan são organizados em coortes, em que cada coorte consiste em vários THMs independentes, cada um contendo uma cópia do mesmo material de chave. Um determinado grupo será distribuído por data centers fisicamente diferentes em diferentes zonas de manutenção para garantir que o sistema atenda às metas de disponibilidade e confiabilidade. Para escalonamento, os clientes serão divididos em vários grupos diferentes, para que possamos ajustar a capacidade do serviço apenas adicionando mais servidores para aumentar o número de grupos disponíveis.

Agora estamos prontos para enumerar os principais componentes da arquitetura do Cloud Key Vault.

Componentes da arquitetura/glossário

Fator de conhecimento da tela de bloqueio (LSKF, na sigla em inglês): um segredo que as pessoas podem lembrar, como um PIN curto, um padrão de deslizar sobre uma grade de pontos 3 x 3 ou uma senha. Esse segredo é usado para proteger a capacidade de desbloquear o dispositivo localmente e é considerado um fator de autenticação principal (ou "forte") para o bloqueio de tela local do dispositivo do usuário.

Cliente:um dispositivo do usuário final com o sistema operacional Android 9 Pie e o Google Play Services ou um software com suporte equivalente.

Android Framework:usamos esse termo genérico (ou simplesmente o framework) para nos referirmos às APIs no Android 9 Pie ou versões mais recentes. Ele não se destina a versões anteriores.

Google Play Services:uma coleção de serviços e apps executados no dispositivo do usuário final, que permite que ele funcione com o sistema de conta do Google e as APIs do servidor personalizado.

Agente de recuperação:um aplicativo do sistema executado como parte dos serviços do Google Play no espaço do usuário em um dispositivo Android 9 Pie (ou semelhante). O agente de recuperação é responsável por executar o lado do cliente dos vários protocolos e interagir com o sistema operacional Android conforme necessário para criar mensagens de protocolo que envolvam o LSKF.

Reclamação de recuperação:quando o usuário quer recuperar a chave de recuperação, ele precisa criar uma reivindicação de recuperação, que tem uma cópia criptografada da chave de chaves de recuperação de LS que o usuário afirma conhecer. Normalmente, o usuário precisa inserir a LSKF do dispositivo antigo em um novo dispositivo que está tentando acessar a chave de recuperação do antigo.

Chave de recuperação:uma chave secreta criptográfica protegida pelo serviço do cofre de chaves do Cloud e usada para criptografar (e autenticar) dados no dispositivo cliente. Depois que a chave de recuperação for colocada em um cofre (consulte abaixo), a cópia local poderá ser excluída assim que o cliente terminar de usá-la para criptografar dados.

Serviço de cofre de chaves em nuvem (CKV, na sigla em inglês):um serviço de Internet que permite que os dispositivos clientes armazenem chaves criptográficas protegidas por uma LSKF que pode ser memorizada por humanos.

Cohorte:uma coleção de servidores do Vault/THMs que podem servir como réplicas redundantes uns dos outros.

Chave pública de coorte: a chave pública de um par de chaves gerado por uma coorte específica de THMs. A chave privada correspondente só está disponível nos THMs que estavam na coorte no momento da geração da chave.

Módulo de hardware confiável (THM): um módulo de segurança dedicado (microcontrolador) projetado para fornecer um ambiente de computação mínimo e confiável. No mínimo, o elemento seguro precisa ser capaz de gerar e/ou armazenar chaves secretas e manter algum estado de evolução não volátil para evitar ataques que envolvam redefinições para um estado anterior.

Vault:uma entrada específica no banco de dados do serviço CKV, que contém uma chave de recuperação protegida por LSKF de um único dispositivo. Um usuário final pode ter vários cofres em arquivo, cada um correspondendo a um dispositivo ou LSKF diferente. Somente o THM em um servidor do Vault pode examinar ou extrair o conteúdo de um Vault.

Servidor do vault:uma máquina de uso geral que opera em um data center do Google e foi adaptada especialmente para adicionar um módulo de hardware confiável (THM, na sigla em inglês).

Criação de protocolos

O protocolo CKV é composto de diversas fases. São elas:

Inicialização

Para inicializar o sistema, o Google vai fornecer uma chave pública para uma "raiz de confiança" que o framework vai usar para verificar os atestados de hardware do Google. A chave de assinatura desse certificado raiz de confiança é armazenada off-line e protegida cuidadosamente, de modo que exige a participação de vários funcionários para assinar com ela. A chave pública desse raiz de confiança está integrada ao SO Android e só pode ser alterada por uma atualização do SO.

O Google também publica periodicamente uma lista de chaves públicas para cada grupo de THMs, junto com uma declaração na lista. A atestação na lista usa uma assinatura que se conecta de volta à raiz de confiança. Cada atualização da lista publicada também contém um número de sequência para evitar reversão. O agente de recuperação vai buscar a lista mais recente de chaves públicas de coorte publicada e fornecê-la ao framework. O framework verifica o atestado e seleciona aleatoriamente uma chave pública do grupo da lista para ser usada na fase de criação do cofre.

Criação de cofre (Vault)

Depois de ajudar o framework a concluir a inicialização, recuperando a lista de chaves públicas de coorte, o agente de recuperação solicitará que o framework crie uma nova Vault. Sempre que o LSKF for inserido pelo usuário, o Framework vai gerar uma nova chave de recuperação e criptografá-la primeiro com uma chave derivada de um hash do LSKF e, em seguida, com a chave pública do grupo de coorte selecionada pelo Framework durante a inicialização. O blob criptografado resultante é o Vault que é transmitido pelo framework ao agente de recuperação, que o envia para o serviço CKV do Google.

Abertura de cofre (vault)

Quando o agente de recuperação no novo dispositivo precisa acessar a chave de recuperação armazenada em um Vault específico, ele primeiro solicita que o usuário insira a LSKF do dispositivo original que criou o Vault. O agente de recuperação vai pedir ao framework para criar uma reclamação de recuperação usando o LSKF. O Framework vai gerar uma chave de reclamante nova e criptografar essa chave, bem como o hash da LSKF reivindicada, com a mesma chave pública do grupo com que o Vault foi criptografado originalmente. O blob criptografado resultante é chamado de Reivindicação de recuperação, e o Framework o transmite ao agente de recuperação, que o apresenta ao serviço CKV.

O CKV encaminha a Reclamação de recuperação (e o Vault correspondente) para os Servidores do Vault que fazem parte do grupo correto. O THM nos servidores do Vault descriptografa a Reclamação de recuperação e tenta extrair a Chave de recuperação do Vault original usando o hash LSKF reivindicado (para derivar a chave de criptografia interna). Se o hash original do LSKF e o hash do LSKF reivindicado forem iguais, o THM vai extrair a chave de recuperação do cofre e criptografá-la novamente com a chave do autor da reivindicação que estava na reivindicação de recuperação. Se não, o THM aumentará um contador de tentativas malsucedidas. Quando o contador de tentativas com falha atingir o limite, o THM vai recusar o processamento de reclamações de recuperação subsequentes para esse cofre.

Por fim, se tudo tiver corrido bem, a chave de recuperação recriptografada (que agora está criptografada com a chave de reclamante) será enviada de volta do servidor do cofre até o framework. O framework usa a cópia da chave do requerente para descriptografar a chave de recuperação, e o protocolo está concluído.

Medidas de segurança

O sistema do Cloud Key Vault tem como objetivo fornecer "defesa em profundidade", incluindo proteções de segurança em vários níveis da pilha. Para dar uma ideia de como essas proteções funcionam, vamos começar descrevendo o cliente e avançando até o serviço do Cloud Key Vault.

Segurança no cliente

Dependendo do OEM e do dispositivo, o fator de conhecimento da tela de bloqueio (LSKF, na sigla em inglês) normalmente é armazenado e protegido no dispositivo usando vários métodos que variam de acordo com o OEM. Por exemplo, os dispositivos Pixel 2 do Google usam um módulo de segurança de hardware resistente a adulterações para armazenar o LSKF em repouso e aplicar limites de taxa baseados em hardware na validação do LSKF. As novas APIs do framework que estão sendo introduzidas para permitir o uso do cofre de chaves do Cloud são projetadas para preservar as garantias de segurança atuais ao máximo possível, mesmo quando o dispositivo usa um módulo de segurança de hardware para proteger o armazenamento do LSKF.

Esta seção se concentra especificamente nas questões e proteções de segurança relevantes que afetam o novo recurso do cofre de chaves do Cloud, em vez de tentar fornecer uma imagem completa de todos os mecanismos de segurança associados ao LSKF.

Protegendo as Framework APIs

As novas APIs do framework que foram adicionadas para oferecer suporte ao serviço CKV são marcadas como @SystemApi e exigem permissões especiais, que garantem que elas só estejam disponíveis para apps de sistema aprovados pelo OEM, como o Google Play Services. Isso remove em grande parte qualquer superfície de ataque direta que possa ser exposta a apps que o usuário instala no dispositivo.

As APIs do framework também garantem que os cofres sejam criados apenas para chaves públicas de coorte que foram atestadas por uma raiz de confiança. A raiz de confiança é integrada ao Framework pelo OEM quando ele é enviado e não pode ser alterada sem uma atualização do SO. Isso garante que o LSKF só seja usado para criar vaults que apliquem corretamente proteções de força bruta baseadas em hardware. Ao usar os THMs no serviço do cofre de chaves do Cloud para proteção contra força bruta para o LSKF, podemos alcançar uma segurança comparável ao uso de hardware seguro no dispositivo para a mesma coisa (como os dispositivos Google Pixel 2).

Como não presumimos que o LSKF será armazenado em qualquer lugar do dispositivo, exceto no hardware seguro, um novo Vault só pode ser criado imediatamente após o desbloqueio do dispositivo. No momento em que o usuário insere o LSKF para desbloquear o dispositivo, o LSKF é disponibilizado brevemente para o Framework na RAM. É nesse momento que a nova API que cria o cofre o usa. Não é possível criar um novo Vault protegido por LSKF enquanto o dispositivo está bloqueado, porque o LSKF não está disponível.

Protegendo o agente de recuperação

A principal proteção de segurança que oferecemos no agente de recuperação é que o protocolo foi projetado para impedir que o agente de recuperação tenha acesso ao LSKF do dispositivo atual ou a qualquer chave de recuperação. Somente o framework pode ver essas informações no lado do cliente, o que dificulta muito a exploração de possíveis bugs ou vulnerabilidades de segurança no agente de recuperação. O agente de recuperação é usado principalmente para gerenciar eventos de ciclo de vida e a transmissão de dados entre a nuvem e o framework. A única exceção a isso acontece durante uma recuperação, pouco antes do protocolo de abertura do Vault, quando o usuário precisa inserir o LSKF do dispositivo antigo. A interface que coleta o LSKF reivindicado para o dispositivo antigo é implementado no agente de recuperação⁴. No entanto, a implementação do agente de recuperação "esquece" o LSKF reivindicado assim que a estrutura assume a construção da reivindicação de recuperação.

Recursos de segurança do protocolo

Embora uma análise completa do protocolo esteja fora do escopo deste documento, queremos destacar algumas das proteções integradas ao protocolo. Especificamente, o protocolo só usa o hash do LSKF. Isso significa que, se o LSKF tiver alta entropia (por exemplo, se for uma boa senha de alta entropia), armazenar o Vault é estritamente melhor do que armazenar um hash de senha. Nesse caso, o hash de senha pode fornecer uma medida de segurança independente da segurança dos THMs. Por esse motivo, oferecemos suporte a hash "memory hard" com sal do LSKF como parte do protocolo. Também vinculamos criptograficamente o Vault a um identificador do dispositivo que o criou e vinculamos a reivindicação de recuperação a um valor de uso único que é usado como um desafio durante o protocolo de abertura do Vault para garantir que a reivindicação de recuperação seja atualizada.

Como a chave de recuperação é gerada novamente em cada criação do Vault, implementamos a rotação de chaves substituindo uma entrada do Vault existente por uma recém-criada. O endereço do contador de tentativas com falha usado pelo cofre é selecionado durante a criação do cofre, e o framework garante que o endereço do contador usado para qualquer cofre subsequente não vai mudar, a menos que a LSKF tenha sido alterada ou haja uma nova lista certificada de chaves públicas de coorte. Assim, a rotação da chave de recuperação pode ser feita sem prejudicar a proteção contra força bruta do LSKF.

Segurança do servidor para o Cloud Key Vault Service

O servidor é implementado usando uma combinação de software em execução em hardware de servidor comum e firmware em execução em hardware especializado (o chip Titan). Vamos descrever as proteções oferecidas em cada camada.

Proteções de hardware

A proteção de segurança principal implementada no lado do servidor do serviço CKV são os módulos de hardware confiáveis (THMs, na sigla em inglês) criados usando os próprios chips Titan personalizados do Google. Os chips estão executando um firmware que expõe as APIs necessárias para implementar os protocolos CKV. Em particular, eles podem gerar e compartilhar com segurança um par de chaves com outros membros do grupo para que a lógica do firmware proteja a chave privada contra vazamento fora dos chips Titan no grupo. Eles também podem executar a operação de abertura do Vault e manter um contador de tentativas com falhas por Vault (onde o contador é baseado no estado armazenado no chip Titan). Uma descrição mais detalhada do protocolo executado pelo firmware do chip CKV Titan será fornecida em uma versão futura deste documento.

Como a segurança do servidor deriva da lógica do firmware nos chips Titan, é necessário garantir que a lógica não mude de forma que permita que os chips vazem segredos ou ignorem os limites do contador. Para alcançar esse objetivo, também alteramos o carregador de inicialização do Titan para garantir que os dados armazenados do chip (como a chave privada do grupo) sejam completamente apagados antes que qualquer atualização seja aplicada. A desvantagem dessa proteção é que não podemos corrigir bugs no firmware sem perder alguns dados. Atualizar o firmware é funcionalmente equivalente a destruir o hardware existente e substituí-lo por novos chips. Caso um patch de firmware crítico seja necessário, o Google vai precisar produzir e publicar uma lista totalmente nova de chaves públicas de coorte atestadas e migrar gradualmente todos os usuários para a nova lista. Para reduzir esse risco, tentamos manter a base de código do firmware bastante reduzida e auditamos cuidadosamente em busca de possíveis problemas de segurança.

Proteções de software

Além dos limites rígidos de falha por Vault impostos pelos THMs, o serviço CKV também implementa a limitação de taxa baseada em software. O limite de taxa foi projetado para impedir que um invasor entre na conta de um usuário e esgote rapidamente o limite de tentativas de recuperação com falha, bloqueando efetivamente o acesso do usuário real às chaves de recuperação. Assim como os atrasos impostos pelo dispositivo do usuário após muitas tentativas de desbloqueio da tela, o serviço de CKV vai aplicar um atraso cada vez maior após cada solicitação de abertura do Vault com falha.

Também implementamos medidas de segurança padrão para serviços do Cloud que hospedam dados do usuário, incluindo controles de acesso, monitoramento e auditoria rigorosos.

Especificação detalhada do protocolo

A especificação detalhada do protocolo ainda está em andamento, e este documento será atualizado para incluir esses detalhes e a publicação do código do cliente no Projeto Android Open Source ainda este ano.

Observações