Descrevemos um serviço de nuvem que usa hardware seguro para armazenar chaves criptográficas para que o acesso a elas seja protegido por um fator de conhecimento de entropia baixa (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 de fornecer o fator de conhecimento correto.
Autor: Shabsi Walfish
Data da versão: 06/03/2018
Observação: este documento ainda é um trabalho em andamento e os detalhes da implementação ainda estão sendo finalizados. À medida que o sistema for estabilizado e for possível produzir mais documentação, atualizaremos este whitepaper com informações mais detalhadas (principalmente em conjunto com versões de código aberto relevantes).
Informações gerais
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 possíveis secrets até que o correto seja encontrado. Devido à disponibilidade atual do poder computacional, um requisito mínimo razoável de entropia para chaves secretas criptográficas pode ser de 70 a 80 bits. Infelizmente, é muito difícil para os seres humanos memorizar e recuperar senhas ou outros secrets de maneira confiável com essa quantidade de entropia1, principalmente quando usados raramente. No entanto, o uso frequente de senhas de 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 segredo seja um "fator de conhecimento" que muito provavelmente será lembrado pelo usuário? Por diversos motivos, esse problema é tão difícil de resolver que os serviços do Cloud Storage normalmente criptografam apenas 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 por pessoas é 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 de baixa entropia por seres humanos. O serviço CKV liberará a chave de recuperação somente para uma parte que comprove conhecimento da chave secreta pessoal memorável correta. Ataques de força bruta contra a chave secreta memorável por humanos podem ser impedidos pelo serviço CKV, o que impõe um limite absoluto no número de tentativas malsucedidas de comprovar 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 possa 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 pessoas que não podem ter a chave de recuperação.
Neste artigo, descrevemos nossa abordagem para a criação de 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, que é PIN, senha ou 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á ativar backups do Android criptografados do lado do cliente. Anteriormente, 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 também armazenados no Cloud. Isso significa que os servidores do Google não têm a 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 neste 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 extra2 instalado neles. O chip Titan, projetado pelo Google, funciona como o componente de hardware do nosso módulo de hardware confiável, e nós o provisionamos especialmente com um carregador de inicialização personalizado e um firmware que implementa nossos protocolos e mecanismos de aplicação da segurança, conforme descrito neste documento. Usamos técnicas de atestado 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ões3 de dispositivos Android, sem perder qualquer quantidade significativa de dados do usuário devido a falhas de hardware (por exemplo, chips queimados) ou passar por interrupções estendidas 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. Uma determinada coorte será distribuída em data centers fisicamente separados em zonas de manutenção diferentes 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 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 fácil de lembrar, como um PIN curto, um padrão de deslizar em uma grade de 3 x 3 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 software com suporte equivalente.
-
Framework do Android:usamos esse termo genérico (ou apenas o Framework) para nos 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 permite que ele funcione com o sistema de contas do Google e as APIs personalizadas do servidor.
Agente de recuperação:um aplicativo do sistema executado como parte do Google Play Services no espaço do usuário de um dispositivo Android 9 Pie (ou semelhante). O agente de recuperação é responsável por executar 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 declaração de recuperação, que tenha uma cópia criptografada do LSKF que o usuário afirma saber. Normalmente, o usuário será solicitado a inserir o LSKF do dispositivo antigo em um dispositivo novo que esteja 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 os dispositivos clientes armazenem chaves criptográficas protegidas por um LSKF memorável pelas pessoas.
-
Coorte: um conjunto de servidores/THMs do Vault que podem aparecer como réplicas redundantes uns dos outros.
Chave pública de coorte: 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): um 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 (para 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 pelo LSKF de um dispositivo. Um usuário final pode ter vários Vaults em arquivo, cada um correspondendo a um dispositivo diferente ou LSKF. Somente o THM em um servidor do 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 foi adaptada 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 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 para exigir 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, além de um atestado na lista. O atestado na lista usa uma assinatura vinculada à 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á ao 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 grupo, o agente de recuperação solicita que o Framework crie um novo Vault. Sempre que a LSKF for inserida 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 é devolvido 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 precisar de acesso à chave de recuperação armazenada em um Vault específico, primeiro ele solicitará que o usuário digite o LSKF do dispositivo original que criou o Vault. O Agente de recuperação solicitará ao Framework a criação de 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 de coorte 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 solicitação de recuperação (e o Vault correspondente) para os servidores do Vault que fazem parte da coorte correta. Em seguida, 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 do LSKF reivindicado (para derivar a chave de criptografia interna). Se o hash do LSKF original e o hash do LSKF reivindicados forem correspondentes, o THM extrairá a chave de recuperação do Vault e a criptografará 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 quaisquer solicitações de recuperação subsequentes desse Vault.
Por fim, se tudo tiver dado certo, a chave de recuperação recriptografada (que agora está criptografada sob a chave do reclamante) é enviada do servidor do Vault até o Framework. O framework usa a cópia da chave do reclamante para descriptografar a chave de recuperação, e o protocolo está concluído.
Medidas de segurança
O sistema do Cloud Key Vault visa fornecer "defesa em profundidade", incluindo proteções de segurança em vários níveis da nossa pilha. Para dar uma noção de como essas proteções funcionam, vamos começar descrevendo o cliente e avançar a 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 para impor limites de taxa baseados em hardware na validação do LSKF. As novas APIs Framework que estão sendo introduzidas para permitir o uso do Cloud Key Vault foram projetadas para preservar as garantias de segurança atuais o máximo possível, mesmo quando o dispositivo usa esse módulo de segurança de hardware para proteger o armazenamento do LSKF.
Nesta seção, abordaremos especificamente os 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 Framework APIs adicionadas para oferecer suporte ao serviço CKV são marcadas como @SystemApi e exigem permissões especiais, que garantem que elas 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 direto 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 dá a certeza de que o LSKF só será usado para criar Vaults que aplicarão corretamente as proteções de força bruta baseadas em hardware. Ao contar com os THMs no serviço Cloud Key Vault para proteção contra força bruta no LSKF, podemos ter uma 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ó poderá 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. 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 proteção de segurança principal que oferecemos no Agente de recuperação é que o protocolo foi projetado para evitar que o Agente de recuperação veja o LSKF do dispositivo atual ou as Chaves de recuperação. Somente o Framework deve ver essas coisas no lado do cliente, dificultando 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 o Cloud e o Framework. A única exceção é durante uma recuperação logo antes do protocolo de abertura de cofre, quando o usuário precisa inserir o LSKF do dispositivo antigo. A interface que coleta o LSKF reivindicado do dispositivo antigo é implementada no agente de recuperação4. No entanto, a implementação do agente de recuperação "esquece" o LSKF reivindicado assim que o Framework assume a criaçã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 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 senha de alta entropia), armazenar o Vault é estritamente melhor do que armazenar um hash de senha. Nesse caso, o hash da senha pode oferecer uma medida de segurança independente da segurança dos THMs. Por esse motivo, oferecemos suporte ao hash de "memória forte" com sal do LSKF como parte do protocolo. Também vinculamos criptograficamente o Vault a um identificador para o dispositivo que o criou, além de vincular a reivindicação de recuperação a um valor de uso único usado como um desafio durante o protocolo de abertura do Vault para garantir que a declaração de recuperação seja atualizada.
Como a chave de recuperação é gerada recentemente a cada criação de cofre, implementamos a rotação de chaves substituindo uma entrada do Vault atual 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 para Vaults subsequentes não será alterado, a menos que o LSKF tenha sido alterado ou que haja uma nova lista atestada 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 um 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, na sigla em inglês), criados com 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 forma segura um par de chaves com outros membros da coorte para que a lógica do firmware proteja a chave privada contra vazamentos fora dos chips Titan na coorte. Eles também podem realizar a operação de abertura de cofre 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 dos chips Titan, é preciso garantir que a lógica não seja alterada de modo que permita 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 do chip (como a chave privada da coorte) sejam completamente excluídos antes de qualquer atualização ser aplicada. A desvantagem dessa proteção é que não podemos corrigir bugs no firmware sem sofrer alguma perda de dados. Atualizar o firmware é funcionalmente equivalente a destruir o hardware atual e substituí-lo por novos chips. Caso um patch crítico de firmware seja necessário, o Google vai precisar produzir e publicar uma lista totalmente nova de chaves públicas de grupo 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 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 rígidos de falha 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 desenvolvida para evitar que um invasor entre na conta de um usuário e esgote rapidamente o limite de tentativas de recuperação fracassadas, 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 crescente após cada solicitação de abertura de cofre malsucedida subsequente.
Também implementamos medidas de segurança padrão para serviços do Cloud que hospedam dados do usuário, 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.
Observações
- "Towards Trust Storage of 56-bit Secrets in Human Memory | USENIX." 1o de agosto de 2014, https://www.usenix.org/node/184458. ↩
- "Blog do Google Cloud Platform: Titan em profundidade: segurança em texto simples." 24 de agosto de 2017, https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html. ↩
- "O Google anuncia mais de 2 bilhões de dispositivos ativos por mês no Android..." 17 de maio de 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users. ↩
- Isso nos permite fornecer IUs flexíveis para inserir o LSKF de outro dispositivo. O framework do dispositivo atual pode não ter uma IU apropriada para a inserção do LSKF do dispositivo antigo. ↩