Segurança

Para evitar a execução de cargas arbitrárias dentro de um pVM, o Android Virtualization Framework (AVF) usa uma abordagem de segurança em camadas, na qual cada camada adiciona imposições adicionais. A seguir está uma lista de camadas de segurança AVF:

  • O Android garante que apenas os aplicativos com permissões pVM tenham permissão para criar ou inspecionar pVMs.

  • Bootloader – O bootloader garante que apenas imagens pVM assinadas pelo Google ou por fornecedores de dispositivos tenham permissão para inicializar e respeite o procedimento de inicialização verificada do Android . Essa arquitetura implica que os aplicativos que executam pVMs não podem agrupar seus próprios kernels.

  • O pVM fornece defesa profunda, como no SELinux , para cargas executadas no pVM. A defesa profunda não permite o mapeamento de dados como executáveis ​​( neverallow execmem ) e garante que W^X seja válido para todos os tipos de arquivo.

Modelo de segurança

Confidencialidade, integridade e disponibilidade (tríade CIA), compõem um modelo desenhado para orientar as políticas de segurança da informação:

  • A confidencialidade é um conjunto de regras que limita o acesso à informação.
  • Integridade é a garantia de que as informações são confiáveis ​​e precisas.
  • A disponibilidade é uma garantia de acesso confiável à informação por entidades autorizadas.

Confidencialidade e integridade

A confidencialidade decorre das propriedades de isolamento de memória impostas pelo hipervisor pKVM. O pKVM rastreia a propriedade da memória de páginas de memória física individuais e quaisquer solicitações dos proprietários para que páginas sejam compartilhadas. O pKVM garante que apenas pVMs autorizados (host e convidados) tenham a página determinada mapeada em suas tabelas de páginas do estágio 2 que são controladas pelo hipervisor. Esta arquitetura mantém que o conteúdo da memória pertencente a um pVM permanece privado, a menos que o proprietário o compartilhe explicitamente com outro pVM.

As restrições à manutenção da confidencialidade também se estendem a quaisquer entidades do sistema que realizem acessos à memória em nome de pVMs, nomeadamente dispositivos e serviços compatíveis com DMA executados em camadas mais privilegiadas . Os fornecedores de System-on-Chip (SoC) devem satisfazer um novo conjunto de requisitos antes de poderem oferecer suporte ao pKVM. Caso contrário, a confidencialidade não pode ser fornecida.

A integridade se aplica aos dados na memória e na computação. pVMs não podem:

  • Modifiquem a memória um do outro sem consentimento.
  • Influenciem o estado da CPU um do outro.

Esses requisitos são impostos pelo hipervisor. No entanto, problemas relativos à integridade dos dados também surgem com o armazenamento virtual de dados quando outras soluções devem ser aplicadas, como dm-verity ou AuthFS.

Esses princípios não são diferentes do isolamento de processos oferecido pelo Linux, onde o acesso às páginas de memória é controlado com tabelas de páginas do estágio 1 e as trocas de contexto do kernel entre processos. No entanto, a porção EL2 do pKVM, que impõe essas propriedades, tem aproximadamente metade da superfície de ataque em comparação com todo o kernel do Linux (cerca de 10 mil versus 20 milhões de linhas de código) e, portanto, oferece uma garantia mais forte para casos de uso que são muito sensíveis para serem confiáveis. no isolamento do processo.

Dado o seu tamanho, um pKVM presta-se à 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 que cada componente de um pKVM oferece.

Hipervisor

pKVM é um hipervisor baseado em KVM que isola pVMs e Android em ambientes de execução mutuamente desconfiados. Essas propriedades são válidas no caso de comprometimento de qualquer pVM, incluindo o host. Hipervisores alternativos que estejam em conformidade com AVF precisam fornecer propriedades semelhantes.

  • Um pVM não pode acessar uma página pertencente a outra entidade, como um pVM ou hipervisor, a menos que seja explicitamente compartilhada pelo proprietário da página. Esta regra inclui o host pVM e se aplica aos acessos CPU e DMA.

  • Antes de uma página usada por um pVM ser retornada ao host, como quando o pVM é destruído, ela é apagada.

  • A memória de todos os pVMs e o firmware do pVM de uma inicialização de dispositivo são apagados antes que o carregador de inicialização do sistema operacional seja executado na inicialização subsequente do dispositivo.

  • Quando um depurador de hardware, como o SJTAG, é conectado, um pVM não pode acessar suas chaves criadas anteriormente.

  • O firmware pVM não inicializa se não conseguir verificar a imagem inicial.

  • O firmware pVM não inicializa se a integridade do instance.img estiver comprometida.

  • A Cadeia de Certificados de Inicialização (BCC) e os Identificadores de Dispositivos Compostos (CDIs) fornecidos a uma instância pVM podem ser derivados somente por essa instância específica.

SO convidado

Microdroid é um exemplo de sistema operacional executado em um pVM. O Microdroid consiste em um bootloader baseado em U-boot, GKI, e um subconjunto de espaço de usuário do Android e um iniciador de carga útil. Essas propriedades são válidas no caso de comprometimento de qualquer pVM, incluindo o host. Sistemas operacionais alternativos executados em um pVM devem fornecer propriedades semelhantes.

  • O Microdroid não inicializará se boot.img , super.img , vbmeta.img ou vbmeta\_system.img não puder ser verificado.

  • O Microdroid não inicializará se a verificação do APK falhar.

  • A mesma instância do Microdroid não inicializará mesmo que o APK tenha sido atualizado.

  • O Microdroid não inicializará se algum dos APEXes falhar na verificação.

  • O Microdroid não inicializará (ou inicializará com um estado inicial limpo) se o instance.img for modificado fora do pVM convidado.

  • Microdroid fornece atestado para a cadeia de inicialização.

  • Qualquer modificação (não assinada) nas imagens de disco compartilhadas com o pVM convidado causa um erro de E/S no lado do pVM.

  • BCC e CDIs fornecidos a uma instância pVM podem ser derivados somente por essa instância específica.

  • As gravações em um volume de armazenamento criptografado são confidenciais; no entanto, não há proteção contra reversão na granularidade de um bloco de criptografia. Além disso, outras adulterações externas arbitrárias de um bloco de dados fazem com que esse bloco 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 no caso de comprometimento do host:

  • Um pVM convidado não pode interagir diretamente (como para fazer uma conexão vsock ) com outros pVMs convidados.

  • Somente o VirtualizationService no host pVM pode criar um canal de comunicação para um pVM.

  • Somente os aplicativos assinados com a chave da plataforma podem solicitar permissão para criar, possuir ou interagir com pVMs.

  • O identificador, chamado identificador de contexto (CID), usado na configuração de conexões vsock entre o host e o pVM não é reutilizado quando o pVM do host está em execução. Por exemplo, você não pode substituir um pVM em execução por outro.

Disponibilidade

No contexto dos pVMs, a disponibilidade refere-se ao host alocar recursos suficientes aos convidados para que os convidados possam executar as tarefas para as quais foram projetados.

As responsabilidades do host incluem o agendamento das CPUs virtuais do pVM. O KVM, diferentemente dos hipervisores Tipo 1 convencionais (como o Xen), toma a decisão explícita de design de delegar o agendamento da carga de trabalho ao kernel do host. Dado o tamanho e a complexidade dos agendadores atuais, esta decisão de design reduz significativamente o tamanho da base de computação confiável (TCB) e permite que o host tome decisões de agendamento mais informadas para otimizar o desempenho. No entanto, um host mal-intencionado pode optar por nunca agendar um convidado.

Da mesma forma, o pKVM também delega o tratamento de interrupções físicas ao kernel do host para reduzir a complexidade do hipervisor e deixar o host responsável pelo agendamento. Esforços são feitos para garantir que o encaminhamento de interrupções de convidados resulte apenas em negação de serviço (interrupções de menos, demasiadas ou mal roteadas).

Finalmente, o processo de monitor de 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 forneça disponibilidade aos convidados, o design protege a disponibilidade do host contra convidados mal-intencionados porque o host sempre pode antecipar ou encerrar um convidado e recuperar seus recursos.

Modo de segurança

Os dados estão vinculados a instâncias de um 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 salt secreto para o pVM e extraindo detalhes, como chaves públicas de verificação e hashes, das imagens carregadas. Essas informações são usadas para verificar inicializações subsequentes da instância pVM e garantir que os segredos da instância sejam liberados apenas para imagens que passem na verificação. Este processo ocorre para cada estágio de carregamento dentro do pVM: firmware pVM, pVM ABL, Microdroid e assim por diante.

A DICE fornece a cada estágio de carregamento um par de chaves de atestado, cuja parte pública é certificada na entrada BCC para esse estágio. Esse par de chaves pode mudar entre as inicializações, portanto, também é derivado um segredo de vedação que é estável para a instância da VM durante as reinicializações e, como tal, é adequado para proteger o estado persistente. O segredo de vedação é altamente valioso para a VM, portanto não deve ser usado diretamente. Em vez disso, as chaves de selamento devem ser derivadas do segredo de selamento e o segredo de selamento deve ser destruído o mais cedo possível.

Cada estágio entrega um objeto CBOR codificado deterministicamente para o próximo estágio. Este objeto contém segredos e o BCC, que contém informações de status acumuladas, como se o último estágio foi carregado com segurança.

Dispositivos desbloqueados

Quando um dispositivo é desbloqueado com fastboot oem unlock , os dados do usuário são apagados. Este processo protege os dados do usuário contra acesso não autorizado. Os dados privados de um pVM também são invalidados quando ocorre um desbloqueio do dispositivo.

Uma vez desbloqueado, o proprietário do dispositivo fica livre para atualizar as partições que geralmente são protegidas por inicialização verificada, incluindo as partições que contêm a implementação do pKVM. Portanto, o pKVM em um dispositivo desbloqueado não será confiável para manter o modelo de segurança.

As partes remotas podem observar esse estado potencialmente inseguro inspecionando o estado de inicialização verificado do dispositivo em um certificado de atestado chave.