Serviço Google Cloud Key Vault

Descrevemos um serviço de 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 entropia baixo (por exemplo, um PIN da tela de bloqueio). O hardware seguro foi projetado para evitar ataques de força bruta, tornando as chaves criptográficas armazenadas permanentemente irrecuperáveis após muitas tentativas com falha para fornecer o fator de conhecimento correto.

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

Observação: este documento ainda está em desenvolvimento, e os detalhes da implementação ainda estão sendo finalizados. À medida que o sistema se estabilizar e mais documentação puder ser produzida, atualizaremos este whitepaper com informações mais detalhadas, especialmente em conjunto com versões de código aberto relevantes.

Visão geral

Tradicionalmente, a criptografia (usada para garantir a privacidade dos dados) exige o uso de secrets com 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 secrets prováveis até que o correto seja encontrado. Devido à disponibilidade atual de capacidade computacional, um requisito mínimo razoável de entropia para chaves secretas criptográficas pode ser de 70 a 80 bits. Infelizmente, para as pessoas, é muito difícil memorizar e lembrar de maneira confiável senhas ou outros secrets com essa quantidade de entropia¹, especialmente quando são usados raramente. No entanto, o uso frequente de senhas com alta entropia é difícil e tedioso. Isso nos deixa com um problema desafiador: como proteger dados particulares com tecnologia de criptografia se queremos que o secret seja um "fator de conhecimento" com probabilidade de ser lembrado pelo usuário? Por uma variedade de motivos, esse problema é tão difícil de resolver que os serviços do Cloud Storage normalmente só criptografam dados com secrets gerenciados pelo próprio provedor de armazenamento em nuvem, em vez de depender do usuário para lembrar o próprio secret.

Uma abordagem para preencher a lacuna entre os requisitos de secrets criptográficos e segredos memoráveis humanos é usar um serviço Cloud Key Vault (CKV) para armazenar uma "chave de recuperação" de alta entropia, protegida por uma chave secreta memorável por humanos de baixa entropia. O serviço CKV liberará a chave de recuperação somente para as partes que comprovarem que você conhece a chave secreta memorável por humanos. O serviço CKV pode impedir ataques de força bruta contra a chave secreta memorável por humanos, o que impõe um limite absoluto no número de tentativas de comprovação de conhecimento do secret. A chave de recuperação em si é uma chave criptográfica simétrica padrão, adequada para uso com um esquema de criptografia (autenticado) que pode facilmente criptografar 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 tenha a chave de recuperação.

Neste artigo, descrevemos nossa abordagem para criar um serviço do Cloud Key Vault usando módulos de hardware confiáveis (THMs). Nossa primeira implementação do serviço CKV foi projetada para proteger as chaves de recuperação com o fator de conhecimento da tela de bloqueio (LSKF, na sigla em inglês) do usuário: o PIN, a senha ou o padrão de deslizar secreto usado para desbloquear smartphones. Os seres humanos conseguem lembrar o LSKF com segurança. Ao mesmo tempo, esses secrets LSKF normalmente 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 Cloud Key Vault será permitir backups do Android criptografados do lado do cliente. Antes, os arquivos criptografados localmente no dispositivo Android usavam uma chave protegida com o LSKF do usuário, mas os backups desses arquivos armazenados (e criptografados) na nuvem não eram protegidos pelo LSKF. Pela primeira vez, o Cloud Key Vault ativa a proteção da tela de bloqueio para backups do Android armazenados no Cloud também. Isso significa que os servidores do Google não têm capacidade de acessar ou restaurar o conteúdo dos backups criptografados. Apenas um dispositivo com o LSKF do usuário pode descriptografar os backups.

Conceitos centrais

Inicialmente, a única plataforma de cliente compatível com o serviço Cloud Key Vault é o sistema operacional Android 9 Pie. Quando nos referimos ao cliente ao longo deste artigo, estamos nos referindo a um dispositivo que executa o sistema operacional Android 9 Pie com o Google Play Services. Nossa implementação do lado do servidor é executada em servidores do Google especialmente designados que têm um chip Titan extra² instalado neles. O chip Titan, projetado pelo Google, funciona como o componente de hardware no nosso módulo de hardware confiável, e ele é fornecido especialmente com um carregador de inicialização personalizado e um firmware que implementa nossos protocolos e mecanismos de aplicação de segurança, conforme descrito neste documento. Usamos técnicas de confirmação de hardware para ter garantias de que nosso protocolo está realmente sendo executado no hardware Titan.

O serviço CKV precisa ser escalonado para lidar com 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 enfrentar interrupções estendidas devido à manutenção do data center. Por esse motivo, os servidores com os ícones Titan são organizados em coortes. Cada coorte consiste em vários THMs independentes, cada um com uma cópia do mesmo material de chave. Uma determinada coorte será distribuída em data centers fisicamente diferentes em diferentes zonas de manutenção para garantir que o sistema possa atender às metas de disponibilidade e confiabilidade. Para fins de escalonabilidade, os clientes serão fragmentados em várias coortes diferentes, para que possamos ajustar a capacidade do serviço adicionando mais servidores para aumentar o número de coortes 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 memorável por humanos, como um PIN curto, um padrão de deslizar em uma grade de 3 x 3 pontos ou uma senha. Esse secret é 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 de usuário final que executa o sistema operacional Android 9 Pie e o Google Play Services ou um software compatível equivalente.

Framework do Android:usamos esse termo genérico (ou apenas o framework) para se referir às APIs no Android 9 Pie ou versões mais recentes, e ele não se destina a versões anteriores.

Google Play Services:um conjunto de serviços e apps executados no dispositivo do usuário final que permitem o funcionamento com o sistema de contas do Google e as APIs de servidor personalizadas.

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

Reivindicaçã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 do LSKF que o usuário afirma conhecer. Normalmente, o usuário precisa inserir o LSKF do dispositivo antigo em um novo dispositivo que está tentando acessar a chave de recuperação do antigo.

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

Serviço Cloud Key Vault (CKV): um serviço de Internet que permite que dispositivos clientes armazenem chaves criptográficas protegidas por um LSKF memorável por humanos.

Coorte: um conjunto de servidores/THMs do Vault que podem atuar como réplicas redundantes uns dos outros.

Chave pública do grupo: a chave pública de um par de chaves gerado por um grupo específico de THMs. A chave privada correspondente só está disponível dentro dos THMs que estavam no grupo no momento da geração da chave.

Módulo de hardware confiável (THM): módulo de segurança dedicado (microcontrolador) projetado para oferecer um ambiente de computação mínimo e confiável. No mínimo, o elemento de segurança precisa ser capaz de gerar e/ou armazenar chaves secretas e manter algum estado evolutivo não volátil, de modo que possa 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 a chave de recuperação protegida por LSKF de um dispositivo. Um usuário final pode ter vários Vaults registrados, cada um correspondendo a um dispositivo ou LSKF diferente. Somente o THM em um servidor de Vault pode examinar ou extrair o conteúdo de um cofre.

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

Criação de protocolos

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

Inicialização

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

O Google também publica periodicamente uma lista de chaves públicas para cada coorte de THM com um atestado na lista. O atestado na lista usa uma assinatura que está encadeada à raiz de confiança. Cada atualização da lista publicada também contém um número de sequência para que seja possível evitar reversões. O agente de recuperação buscará a lista publicada mais recente de chaves públicas de coorte e a fornecerá para o Framework. Em seguida, o Framework verifica o atestado e seleciona aleatoriamente uma chave pública de grupo da lista para ser usada na fase de criação do Vault.

Criação de cofre (Vault)

Depois de ajudar o Framework a concluir a inicialização buscando a lista de chaves públicas de coorte, o agente de recuperação solicitará que o Framework crie um novo Vault. Sempre que o LSKF for inserido pela próxima vez pelo usuário, o Framework vai gerar uma nova chave de recuperação e a criptografar primeiro com uma chave derivada de um hash do LSKF e, em seguida, com a chave pública de coorte selecionada pelo framework durante a inicialização. O blob criptografado resultante é o Vault que é retornado pelo Framework para o 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 precisar de acesso à Chave de recuperação armazenada em um Vault, primeiro ele solicitará que o usuário digite o LSKF do dispositivo original que criou o Vault. O Agente de recuperação vai solicitar que o Framework crie uma solicitação de recuperação usando esse LSKF. O Framework vai gerar uma nova chave do reclamante e criptografar essa chave, bem como o hash do LSKF reivindicado, com a mesma chave pública do grupo com que o Vault foi originalmente criptografado. O blob criptografado resultante é chamado de solicitação de recuperação, e o Framework a transmite para o agente de recuperação, que a apresenta ao serviço CKV.

O CKV encaminha a declaração de recuperação (e o Vault correspondente) aos servidores do Vault que fazem parte da coorte correta. O THM nos servidores do Vault descriptografa a solicitaçã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 LSKF original e o hash LSKF reivindicado forem correspondentes, o THM vai extrair a chave de recuperação do Vault e criptografá-la novamente com a chave do reclamante 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 se recusará a processar qualquer solicitação de recuperação subsequente para esse Vault.

Por fim, se tudo tiver dado certo, a chave de recuperação recriptografada (que agora está criptografada sob a chave do reclamante) será enviada do servidor do Vault até o Framework. O Framework usa a cópia da chave de reclamante para descriptografar a chave de recuperação, e o protocolo agora está completo.

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 nossa pilha. Para entender como essas proteções funcionam, vamos começar descrevendo o cliente e avançar na pilha até o serviço do Cloud Key Vault.

Segurança no cliente

Dependendo do OEM e do dispositivo específicos, o fator de conhecimento da tela de bloqueio (LSKF, na sigla em inglês) normalmente é armazenado e protegido no dispositivo por meio de 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 LSKF. As novas APIs Framework que estão sendo lançadas para permitir o uso do Cloud Key Vault foram projetadas para preservar as garantias de segurança atuais ao máximo, mesmo quando o dispositivo usa esse módulo de segurança de hardware para proteger o armazenamento do LSKF.

Vamos focar esta seção especificamente nos problemas e proteções de segurança relevantes que afetam o novo recurso do Cloud Key Vault, em vez de tentar fornecer uma visão completa de todos os mecanismos de segurança associados ao LSKF.

Protegendo as Framework APIs

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

As APIs Framework também garantem que os Vaults sejam criados apenas para chaves públicas de coorte que foram atestadas por uma raiz de confiança. A raiz de confiança é incorporada ao Framework pelo OEM quando é enviada e não pode ser alterada sem uma atualização do SO. Isso transmite a confiança de que o LSKF está sendo usado apenas para criar cofres que aplicarão corretamente proteções contra força bruta baseadas em hardware. Ao contar com os THMs no serviço do Cloud Key Vault para proteção contra força bruta para o LSKF, podemos ter segurança comparável ao uso de hardware seguro no dispositivo (como os dispositivos Google Pixel 2).

Como não presumimos que o LSKF será armazenado em qualquer lugar do dispositivo fora do hardware protegido, 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 é brevemente disponibilizado para o Framework na RAM. É nesse momento que a nova API que cria o cofre o usa. Enquanto o dispositivo está bloqueado, não é possível criar um novo cofre protegido por LSKF 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 é projetado para evitar que o agente de recuperação veja o LSKF do dispositivo atual ou as chaves de recuperação. Somente o Framework precisa ver esses itens no lado do cliente, dificultando 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 o Cloud e o Framework. A única exceção é durante uma recuperação logo antes do protocolo de abertura do cofre, quando o usuário precisa inserir o LSKF do dispositivo antigo. A IU que coleta o LSKF reivindicado do dispositivo antigo é implementada no agente de recuperação⁴. No entanto, a implementação do agente de recuperação "esquece" o LSKF reivindicado assim que o Framework assume a construção da solicitação de recuperação.

Recursos de segurança do protocolo

Embora uma análise completa do protocolo esteja além do escopo deste documento, queremos destacar algumas das proteções integradas. Mais especificamente, o protocolo usa apenas 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 da senha pode fornecer uma medida de segurança independente da segurança dos THMs. Por esse motivo, oferecemos compatibilidade com o hash de "memória difícil" com sal do LSKF como parte do protocolo. Também vinculamos criptograficamente o Vault a um identificador para o dispositivo que o criou, e a reivindicação de recuperação a um valor de uso único usado como um desafio durante o protocolo de abertura do cofre para garantir que a solicitação de recuperação seja atualizada.

Como a chave de recuperação é gerada recentemente em cada criação de cofre, implementamos a rotação de chaves substituindo uma entrada existente do Vault por um recém-criado. O endereço do contador de tentativas com falha usado pelo Vault é selecionado durante a criação dele, e o Framework garante que o endereço do contador usado nos Vaults subsequentes não seja alterado, a menos que o LSKF tenha sido alterado ou que haja uma nova lista atestado 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 executado em hardware de servidor comum e firmware executado em hardware especializado (o chip Titan). Vamos descrever as proteções oferecidas em cada camada.

Proteções de hardware

A principal proteção de segurança implementada no lado do servidor do serviço CKV são os módulos de hardware confiável (THMs) criados usando os chips Titan personalizados do Google. Os chips estão executando firmware que expõe as APIs necessárias para implementar os protocolos CKV. Em particular, eles podem gerar e compartilhar de maneira segura um par de chaves com outros membros da coorte. Assim, a lógica do firmware protege a chave privada contra vazamentos para fora dos chips Titan da coorte. Eles também podem realizar a operação de abertura do Vault e manter um contador por cofre estritamente incrementado de tentativas com falha, em que o contador é apoiado pelo estado armazenado dentro do chip Titan. Uma descrição mais detalhada do protocolo executado pelo firmware do chip CKV Titan vai ser fornecida em uma versão futura deste documento.

Como a segurança do servidor deriva da lógica do firmware nos chips Titan, é preciso garantir que a lógica não seja alterada de modo que os chips vazem secrets ou ignorem os limites do contador. Para alcançar esse objetivo, também alteramos o carregador de inicialização Titan para garantir que os dados armazenados no chip (como a chave privada da coorte) sejam completamente excluídos antes de qualquer atualização. A desvantagem dessa proteção é que não podemos corrigir bugs no firmware sem passar por perda de dados. Atualizar o firmware é funcionalmente equivalente a destruir o hardware atual e substituí-lo por novos chips. Caso um patch crítico do firmware seja necessário, o Google precisará produzir e publicar uma lista totalmente nova de chaves públicas de coorte atestadas e migrar gradualmente todos os usuários para ela. Para mitigar esse risco, tentamos manter a base de código do firmware relativamente mínima e auditá-la com cuidado em busca de possíveis problemas de segurança.

Proteções de software

Além dos limites de falha rígido por Vault impostos pelos THMs, o serviço CKV também implementa limitação de taxa com base em software. A limitação de taxa foi projetada para impedir que um invasor entre na conta de um usuário e esgote rapidamente o limite de tentativas de recuperação malsucedidas, bloqueando efetivamente o acesso do usuário real às chaves de recuperação. Semelhante aos atrasos impostos pelo dispositivo do usuário após muitas tentativas malsucedidas de desbloquear a tela, o serviço CKV aplicará um atraso cada vez maior após cada solicitação de abertura de cofre com falha subsequente.

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

Especificação detalhada do protocolo

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

Notes