O provisionamento remoto de chave do Google será obrigatório no Android 13, mas é um assunto complicado. Aqui está o que isso significará para você.
O atestado principal do Android é a espinha dorsal de muitos serviços confiáveis em nossos smartphones, incluindo SafetyNet, Digital Car Key e a API de credencial de identidade. Ele é exigido como parte do Android desde o Android 8 Oreo e dependia de uma chave raiz instalada em um dispositivo de fábrica. O fornecimento dessas chaves exigia o máximo sigilo por parte do fabricante e, se uma chave vazasse, isso significaria que ela precisaria ser revogada. Isto resultaria na impossibilidade de um consumidor utilizar qualquer um destes serviços confiáveis, o que seria lamentável caso existisse uma vulnerabilidade que pudesse expô-lo. Provisionamento Remoto de Chave, que será obrigatório em Andróide 13, visa resolver esse problema.
Os componentes que compõem a atual cadeia de confiança no Android
Antes de explicar como o novo sistema funciona, é importante contextualizar como o
velho (e ainda em vigor para muitos dispositivos) o sistema funciona. Muitos telefones hoje em dia usam atestado de chave apoiado por hardware, com o qual você deve estar familiarizado como o prego no caixão para qualquer tipo de desvio do SafetyNet. Existem vários conceitos que são importantes para compreender o estado atual da certificação de chave.É uma combinação desses conceitos que garante que um desenvolvedor possa confiar que um dispositivo não foi adulterado e possa lidar com informações confidenciais no TEE.
Ambiente de execução confiável
Um Trusted Execution Environment (TEE) é uma região segura no SoC usada para lidar com dados críticos. O TEE é obrigatório em aparelhos lançados com Android 8 Oreo e superior, ou seja, qualquer smartphone recente o possui. Qualquer coisa que não esteja dentro do TEE é considerada “não confiável” e só pode ver conteúdo criptografado. Por exemplo, o conteúdo protegido por DRM é criptografado com chaves que só podem ser acessadas por software executado no TEE. O processador principal só pode ver um fluxo de conteúdo criptografado, enquanto o conteúdo pode ser descriptografado pelo TEE e depois exibido ao usuário.
Zona de confiança ARM
Trusty é um sistema operacional seguro que fornece um TEE no Android e, em sistemas ARM, faz uso do Trustzone do ARM. O Trusty é executado no mesmo processador do sistema operacional principal e tem acesso a toda a potência do dispositivo, mas está completamente isolado do resto do telefone. Confiável consiste no seguinte:
- Um pequeno kernel do sistema operacional derivado de Pequeno Núcleo
- Um driver de kernel Linux para transferir dados entre o ambiente seguro e o Android
- Uma biblioteca de espaço de usuário do Android para se comunicar com aplicativos confiáveis (ou seja, tarefas/serviços seguros) por meio do driver do kernel
A vantagem que tem sobre os sistemas TEE proprietários é que esses sistemas TEE podem ser caros e também criar instabilidade no ecossistema Android. O Trusty é fornecido gratuitamente pelo Google aos OEMs parceiros e é de código aberto. O Android oferece suporte a outros sistemas TEE, mas Trusty é o que o Google mais incentiva.
Caixa forte
Os dispositivos StrongBox são CPUs seguras completamente separadas, desenvolvidas especificamente e certificadas. Eles podem incluir Elementos Seguros incorporados (eSE) ou uma Unidade de Processamento Seguro (SPU) no SoC. O Google diz que o StrongBox é atualmente "altamente recomendado" para vir com dispositivos lançados com Andróide 12 (conforme o documento de definição de compatibilidade), pois provavelmente se tornará um requisito em uma versão futura do Android. É essencialmente uma implementação mais rigorosa de um keystore apoiado por hardware e pode ser implementado juntamente com o TrustZone. Um exemplo de implementação do StrongBox é o chip Titan M em smartphones Pixel. Poucos telefones usam o StrongBox e a maioria usa o Trustzone da ARM.
Keymaster TA
Keymaster Trusted Application (TA) é o keymaster seguro que gerencia e executa todas as operações de keystore. Ele pode ser executado, por exemplo, no TrustZone da ARM.
Como o Key Attestation está mudando com o Android 12 e o Android 13
Se uma chave for exposta em um smartphone Android, o Google será obrigado a revogá-la. Isso representa um problema para qualquer dispositivo que tenha uma chave injetada na fábrica – qualquer tipo de vazamento que exponha a chave significaria que os usuários não conseguiriam acessar determinado conteúdo protegido. Isto pode até incluir a revogação do acesso a serviços como o Google Pay, algo em que muitas pessoas confiam. Isso é lamentável para os consumidores porque, sem que seu telefone seja consertado por um fabricante, não haveria como você mesmo consertá-lo.
Insira o provisionamento de chave remota. A partir do Android 12, o Google está substituindo o provisionamento de chave privada de fábrica por uma combinação de extração de chave pública na fábrica e provisionamento de certificados over-the-air com vida curta certificados. Este esquema será necessário no Android 13 e traz alguns benefícios. Em primeiro lugar, evita que OEMs e ODMs precisem gerenciar o sigilo das chaves em uma fábrica. Em segundo lugar, permite que os dispositivos sejam recuperados caso as suas chaves sejam comprometidas, o que significa que os consumidores não perderão para sempre o acesso aos serviços protegidos. Agora, em vez de usar um certificado calculado usando uma chave que está no dispositivo e pode vazar através de um vulnerabilidade, um certificado temporário é solicitado ao Google sempre que um serviço que exige atestado é usado.
Quanto ao funcionamento, é bastante simples. Um par de chaves estático exclusivo é gerado por cada dispositivo, e a parte pública desse par de chaves é extraída pelo OEM em sua fábrica e enviada aos servidores do Google. Lá, eles servirão como base de confiança para provisionamento posterior. A chave privada nunca sai do ambiente seguro em que é gerada.
Quando um dispositivo é usado pela primeira vez para se conectar à Internet, ele gera uma solicitação de assinatura de certificado para chaves que gerou, assinando-a com a chave privada que corresponde à chave pública recolhida no fábrica. Os servidores back-end do Google verificarão a autenticidade da solicitação e assinarão as chaves públicas, retornando as cadeias de certificados. O keystore no dispositivo armazenará essas cadeias de certificados, atribuindo-as aos aplicativos sempre que um atestado for solicitado. Pode ser qualquer coisa, desde Google Pay até Pokémon Go.
Essa cadeia exata de solicitação de certificado acontecerá regularmente após a expiração dos certificados ou o esgotamento do fornecimento de chaves atual. Cada aplicativo recebe uma chave de atestado diferente e as próprias chaves são alternadas regularmente, o que garante a privacidade. Além disso, os servidores back-end do Google são segmentados de forma que o servidor que verifica a chave pública do dispositivo não veja as chaves de atestado anexadas. Isso significa que não é possível para o Google correlacionar as chaves de atestado ao dispositivo específico que as solicitou.
Os usuários finais não notarão nenhuma mudança, embora os desenvolvedores precisem estar atentos ao seguinte, de acordo com o Google.
- Estrutura da Cadeia de Certificados
- Devido à natureza da nossa nova infraestrutura de provisionamento online, o comprimento da cadeia é maior do que era anteriormente e está sujeito a alterações.
- Raiz da Confiança
- A raiz de confiança será eventualmente atualizada da chave RSA atual para uma chave ECDSA.
- Descontinuação do atestado RSA
- Todas as chaves geradas e atestadas pelo KeyMint serão assinadas com uma chave ECDSA e a cadeia de certificados correspondente. Anteriormente, as chaves assimétricas eram assinadas pelo algoritmo correspondente.
- Certificados e chaves de atestado de curta duração
- Os certificados provisionados para dispositivos geralmente serão válidos por até dois meses antes de expirarem e serem alternados.
Entramos em contato com o Google e perguntamos se isso tem alguma relevância para o Widevine DRM e como alguns usuários do Pixel relataram que seu nível de DRM foi rebaixado com um bootloader bloqueado. Também perguntamos se isso pode ser distribuído como uma atualização OTA para usuários por meio do Google Play Services agora. Teremos certeza de atualizar este artigo se recebermos uma resposta. Não está claro quais componentes da atual cadeia de confiança serão afetados ou de que forma.
Fonte: Google