Postado por Max Bires, engenheiro de software
Como recurso, o atestado é obrigatório desde o Android 8.0. Ao longo das várias versões, ele foi se tornando cada vez mais fundamental para a confiabilidade de diversos recursos e serviços, como SafetyNet, Identity Credential, Digital Car Key, e de muitas bibliotecas de terceiros. Em vista disso, chegou a hora de revisar nossa infraestrutura de atestados para reforçar a segurança da cadeia de confiança e aumentar a capacidade de recuperação da confiabilidade dos dispositivos em caso de vulnerabilidades conhecidas.
A partir do Android 12.0, forneceremos uma opção de substituição do provisionamento de chaves privadas de fábrica por uma combinação de extração de chaves privadas de fábrica e provisionamento OTA de certificados de curta duração. Esse esquema será obrigatório no Android 13.0. Ele é conhecido como provisionamento remoto de chaves.
Quem será impactado?
OEMs/ODMs
Os fabricantes de dispositivos deixarão de provisionar chaves privadas de atestado diretamente para os dispositivos na fábrica, o que elimina a sobrecarga de gerenciamento de chaves secretas na fábrica para fins de atestado.
Potencialmente, as partes confiáveis
O formato, os algoritmos e o comprimento da cadeia de certificados de um atestado, descritos mais adiante, passarão por mudanças. Se uma parte confiável tiver configurado o código de validação de certificados com correspondência muito rígida à estrutura da cadeia de certificados legada, esse código precisará ser atualizado.
Por que foi feita essa mudança?
Os dois fatores principais que motivaram a mudança da forma como provisionamos certificados de atestado para os dispositivos são permitir a recuperação de dispositivos após um comprometimento e reforçar a cadeia de suprimentos de atestados. No atual esquema de atestado, se um modelo de dispositivo for comprometido de uma forma que afete o sinal de confiabilidade de um atestado ou se ocorrer o vazamento de uma chave por meio de qualquer mecanismo, a chave deverá ser revogada. Devido ao número cada vez maior de serviços que dependem do sinal de chave de atestado, isso pode ter um grande impacto sobre os consumidores cujos dispositivos forem afetados.
Essa mudança nos permite interromper o provisionamento para dispositivos com software comprovadamente comprometido e eliminar o potencial de vazamento não intencional de chaves. Isso ajudará a reduzir muito a possibilidade de interrupção de serviços para os usuários.
Como isso funciona?
Cada dispositivo gera um par de chaves estáticas exclusivas, e a parte pública desse par de chaves é extraída pelo OEM na fábrica. Em seguida, é feito o upload dessas chaves públicas para os servidores do Google, onde elas servem como base de confiança para o provisionamento posterior. A chave privada nunca deixa o ambiente seguro na qual é gerada.
Quando um novo dispositivo é conectado pela primeira vez à Internet, ele gera uma solicitação de assinatura de certificado para as chaves geradas por ele, assinando-a com a chave privada correspondente à chave pública coletada na fábrica. Os servidores de back-end verificam a autenticidade da solicitação e assinam as chaves públicas, retornando as cadeias de certificados. O armazenamento de chaves, então, armazena essas cadeias de certificados, atribuindo-as aos apps sempre que um atestado é solicitado.
Esse fluxo ocorre regularmente com a expiração dos certificados ou a exaustão do suprimento de chaves atual. O esquema preserva a privacidade, porque cada aplicativo recebe uma chave de atestado diferente, e as próprias chaves passam periodicamente por um rodízio. Além disso, os servidores de back-end do Google são segmentados de tal forma que o servidor que verifica a chave pública do dispositivo não vê as chaves de atestado anexadas. Isso significa que não é possível para o Google correlacionar as chaves de atestado com o dispositivo em particular que as solicitou.
O que muda, do ponto de vista técnico?
Os usuários finais não notarão nenhuma mudança. Os desenvolvedores que usam atestados deverão ficar atentos às seguintes mudanças:
Estrutura da cadeia de certificados
Devido à natureza de nossa nova infraestrutura de provisionamento on-line, o comprimento da cadeia está maior do que antes e está sujeito a mudanças.
Raiz de confiança
A raiz de confiança será eventualmente atualizada da atual chave RSA para uma chave ECDSA.
Suspensão de uso do atestado RSA
Todas as chaves geradas e atestadas pelo KeyMint serão assinadas com uma chave ECDSA e a cadeia de certificados correspondente. Antes, as chaves assimétricas eram assinadas por seus algoritmos correspondentes.
Certificados e chaves de atestado de curta duração
Os certificados provisionados a dispositivos geralmente serão válidos por até dois meses antes de expirarem e passarem pelo rodízio.
2 comentários :
O que torna o 1Win Aviador tão especial são as experiências únicas que oferece aos jogadores. Desde a variedade de jogos disponíveis até as promoções exclusivas, cada aspecto da plataforma https://primeirahora.com.br/explorando-1win-aviator-experiencias-unicas-de-jogadores/ foi projetado para cativar e envolver os usuários. Aqui estão algumas das experiências mais notáveis que os jogadores podem esperar ao explorar o 1Win Aviador
I find the community around Colorbox Mustard to be incredibly supportive. Players share their creations online, and it's inspiring to see the diverse range of music being made. It's a great reminder of how music can connect us all, regardless of background!
Postar um comentário