Para evitar a execução de payloads arbitrários em uma pVM, o Android Virtualization Framework (AVF) usa uma abordagem de segurança em camadas em que cada camada adiciona outras restrições. Confira a seguir uma lista das camadas de segurança do AVF:
O Android garante que apenas os apps com permissões de pVM possam criar ou inspecionar pVMs.
Bootloader: garante que apenas imagens de pVM assinadas pelo Google ou fornecedores de dispositivos possam ser inicializadas e respeita o procedimento de inicialização verificada do Android. Essa arquitetura implica que os apps que executam pVMs não podem agrupar os próprios kernels.
A pVM oferece defesa em profundidade, como o SELinux, para payloads executados na pVM. A defesa em profundidade não permite mapear dados como executáveis (
neverallow execmem) e garante que W^X seja válido para todos os tipos de arquivo.
Modo de segurança
Confidencialidade, integridade e disponibilidade (tríade CIA) formam um modelo criado para orientar as políticas de segurança da informação:
- Confidencialidade é um conjunto de regras que limita o acesso às informações.
- Integridade é a garantia de que as informações são confiáveis e precisas.
- Disponibilidade é a garantia de acesso confiável às informações por entidades autorizadas.
Confidencialidade e integridade
A confidencialidade decorre das propriedades de isolamento de memória aplicadas pelo hipervisor pKVM. O pKVM rastreia a propriedade da memória de páginas individuais da memória física e quaisquer solicitações de compartilhamento de páginas feitas pelos proprietários. O pKVM garante que apenas as pVMs autorizadas (host e convidados) tenham a página mapeada nas tabelas de páginas de estágio 2 controladas pelo hipervisor. Essa arquitetura mantém o conteúdo da memória de uma pVM em particular, a menos que o proprietário a compartilhe explicitamente com outra pVM.
As restrições para manter a confidencialidade também se estendem a todas as entidades no sistema que realizam acessos à memória em nome das pVMs, ou seja, dispositivos compatíveis com DMA e serviços executados em camadas mais privilegiadas. Os fornecedores de sistema em um chip (SoC) precisam atender a um novo conjunto de requisitos antes de oferecer suporte ao pKVM. Caso contrário, não será possível oferecer confidencialidade.
A integridade se aplica aos dados na memória e à computação. As pVMs não podem:
- Modificar a memória um do outro sem consentimento.
- Influenciam o estado da CPU um do outro.
Esses requisitos são aplicados pelo hipervisor. No entanto, problemas relacionados à integridade dos dados também surgem com o armazenamento virtual quando outras soluções precisam ser aplicadas, como dm-verity ou AuthFS.
Esses princípios não são diferentes do isolamento de processos oferecido pelo Linux, em que o acesso a páginas de memória é controlado com tabelas de páginas de estágio 1 e o kernel alterna o contexto entre processos. No entanto, a parte EL2 do pKVM, que impõe essas propriedades, tem três ordens de magnitude a menos de superfície de ataque em comparação com todo o kernel do Linux (aproximadamente 10 mil versus 20 milhões de linhas de código) e, portanto, oferece maior garantia para casos de uso que são muito sensíveis para depender do isolamento de processos.
Devido ao tamanho, o pKVM se presta à verificação formal. Estamos apoiando ativamente pesquisas acadêmicas, que visam provar formalmente essas propriedades no binário pKVM real.
O restante desta página aborda as garantias de confidencialidade e integridade fornecidas por cada componente em torno de uma pKVM.
Hipervisor
A pKVM é um hipervisor baseado em KVM que isola pVMs e o Android em ambientes de execução mutuamente desconfiados. Essas propriedades são válidas em caso de comprometimento em qualquer pVM, incluindo o host. Hipervisores alternativos que estejam em conformidade com o AVF precisam fornecer propriedades semelhantes.
Uma PVM não pode acessar uma página pertencente a outra entidade, como uma PVM ou um hipervisor, a menos que seja compartilhada explicitamente pelo proprietário da página. Essa regra inclui a pVM do host e se aplica aos acessos de CPU e DMA.
Antes de uma página usada por uma pVM ser retornada ao host, como quando a pVM é destruída, ela é apagada.
A memória de todas as pVMs e o firmware de pVM de uma inicialização de dispositivo são apagados antes que o carregador de inicialização do SO seja executado na inicialização subsequente do dispositivo.
Quando um depurador de hardware, como o SJTAG, é anexado, uma pVM não pode acessar as chaves geradas anteriormente.
O firmware da pVM não é inicializado se não for possível verificar a imagem inicial.
O firmware da pVM não será inicializado se a integridade do
instance.imgestiver comprometida.A cadeia de certificados DICE e os identificadores de dispositivo compostos (CDIs) fornecidos a uma instância de pVM só podem ser derivados por essa instância específica.
SO convidado
O Microdroid é um exemplo de SO executado em uma pVM. O Microdroid consiste em um carregador de inicialização baseado em U-boot, GKI, um subconjunto do espaço do usuário do Android e um iniciador de payload. Essas propriedades são válidas em caso de comprometimento em qualquer pVM, incluindo o host. Sistemas operacionais alternativos executados em uma pVM precisam oferecer propriedades semelhantes.
O Microdroid não será inicializado se não for possível verificar
boot.img,super.img,vbmeta.imgouvbmeta\_system.img.O Microdroid não será inicializado se a verificação do APK falhar.
A mesma instância do Microdroid não será inicializada mesmo que o APK tenha sido atualizado.
O microdroid não será inicializado se algum dos APEXs falhar na verificação.
O Microdroid não será inicializado (ou será inicializado com um estado inicial limpo) se o
instance.imgfor modificado fora da pVM convidada.O Microdroid fornece atestado para a cadeia de inicialização.
Qualquer modificação (não assinada) nas imagens de disco compartilhadas com a pVM convidada causa um erro de E/S no lado da pVM.
A cadeia de certificados DICE e os CDIs fornecidos a uma instância de pVM só podem ser derivados por essa instância específica.
As gravações em um volume de armazenamento criptografado são confidenciais, mas não há proteção contra rollback na granularidade de um bloco de criptografia. Além disso, outras adulterações externas arbitrárias de um bloco de dados fazem com que ele apareça como lixo para o Microdroid, em vez de ser detectado explicitamente como um erro de E/S.
Android
Estas são propriedades mantidas pelo Android como host, mas não são válidas em caso de comprometimento do host:
Uma pVM convidada não pode interagir diretamente com outras pVMs convidadas, como fazer uma conexão
vsock.Somente o
VirtualizationServicena pVM do host pode criar um canal de comunicação com uma pVM.Somente os apps assinados com a chave da plataforma podem solicitar permissão para criar, possuir ou interagir com pVMs.
O identificador, chamado de identificador de contexto (CID), usado na configuração de conexões
vsockentre o host e a pVM não é reutilizado quando a pVM do host está em execução. Por exemplo, não é possível substituir uma pVM em execução por outra.
Disponibilidade
No contexto das pVMs, disponibilidade se refere à alocação pelo host de recursos suficientes para os convidados, para que eles possam realizar as tarefas a que se destinam.
As responsabilidades do host incluem o agendamento das CPUs virtuais da pVM. O KVM, ao contrário dos hipervisores convencionais do tipo 1 (como o Xen), toma a decisão explícita de delegar o agendamento de cargas de trabalho ao kernel do host. Devido ao tamanho e à complexidade dos programadores atuais, essa decisão de design reduz significativamente o tamanho da base de computação confiável (TCB, na sigla em inglês) e permite que o host tome decisões de programação mais informadas para otimizar o desempenho. No entanto, um host malicioso pode optar por nunca agendar um convidado.
Da mesma forma, o pKVM também delega o processamento de interrupções físicas ao kernel do host para reduzir a complexidade do hipervisor e deixar o host responsável pelo agendamento. Fazemos o possível para garantir que o encaminhamento de interrupções de convidados resultem apenas em uma negação de serviço (interrupções insuficientes, em excesso ou mal encaminhadas).
Por fim, o processo do monitor da máquina virtual (VMM) do host é responsável por alocar memória e fornecer dispositivos virtuais, como uma placa de rede. Um VMM malicioso pode reter recursos do convidado.
Embora o pKVM não ofereça disponibilidade para convidados, o design protege a disponibilidade do host contra convidados maliciosos, porque o host sempre pode substituir ou encerrar um convidado e recuperar os recursos dele.
Inicialização segura
Os dados são vinculados a instâncias de uma pVM, e a inicialização segura garante que o acesso aos dados de uma instância possa ser controlado. A primeira inicialização de uma instância a provisiona gerando aleatoriamente um sal secreto para a pVM e extraindo detalhes, como chaves públicas e hashes de verificação, das imagens carregadas. Essas informações são usadas para verificar inicializações subsequentes da instância de pVM e garantir que os secrets da instância sejam liberados apenas para imagens que passem na verificação. Esse processo ocorre em todas as etapas de carregamento na pVM: firmware da pVM, ABL da pVM, Microdroid e assim por diante.
O DICE fornece a cada estágio de carregamento um par de chaves de atestado, cuja parte pública é certificada no certificado DICE para esse estágio. Esse par de chaves pode mudar entre as inicializações. Por isso, um segredo de lacre também é derivado e é estável para a instância de VM em reinicializações. Assim, ele é adequado para proteger o estado persistente. O segredo de lacre é muito valioso para a VM e não deve ser usado diretamente. Em vez disso, as chaves de lacre precisam ser derivadas do secret de lacre, que deve ser destruído o mais rápido possível.
Cada estágio entrega um objeto CBOR codificado de forma determinística para o próximo estágio. Esse objeto contém secrets e a cadeia de certificados DICE, que contém informações de status acumuladas, como se a última etapa foi carregada com segurança.
Dispositivos desbloqueados
Quando um dispositivo é desbloqueado com fastboot oem unlock, os dados do usuário são excluídos permanentemente.
Esse processo protege os dados do usuário contra acesso não autorizado. Os dados particulares de uma pVM também são invalidados quando um dispositivo é desbloqueado.
Depois de desbloqueado, o proprietário do dispositivo pode atualizar partições que geralmente são protegidas pela inicialização verificada, incluindo as que contêm pvmfw e a implementação do pKVM. Portanto, um dispositivo desbloqueado não é confiável para manter o modelo de segurança de uma pVM.
Partes remotas podem observar esse estado potencialmente inseguro inspecionando o estado de inicialização verificada do dispositivo em um certificado de atestado de chave.