O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Retomar na reinicialização

Quando um OTA é baixado e preparado para ser aplicado por meio de atualização A / B , A / B virtual ou outro método disponível por meio da classe RecoverySystem , o Resume-on-Reboot tentará desbloquear o armazenamento Credential Encrypted (CE) após a reinicialização do dispositivo para aplicar o OTA. Isso pode ser emparelhado com um sistema OTA que aplica atualizações quando é mais conveniente para o usuário, como nos momentos em que o dispositivo deve estar ocioso.

fundo

Para desenvolvedores de aplicativos, o Android oferece suporte à inicialização direta, que permite que os aplicativos sejam inicializados antes que o armazenamento Credential Encrypted (CE) seja desbloqueado pelo usuário. À medida que mais desenvolvedores de aplicativos implementam o suporte para inicialização direta, o usuário tem uma experiência melhor antes de inserir o fator de conhecimento da tela de bloqueio (LSKF) após a inicialização.

Resume-on-Reboot permite desbloquear o armazenamento CE de todos os aplicativos, incluindo aqueles que ainda não suportam inicialização direta, após uma reinicialização iniciada por um OTA. Este recurso permite que os usuários recebam notificações de todos os seus aplicativos instalados após a reinicialização.

Modelo de ameaça

Uma implementação de Resume-on-Reboot deve preservar a propriedade de que quando um dispositivo cai nas mãos de um invasor, é extremamente difícil para esse invasor recuperar os dados criptografados pelo CE do usuário, mesmo que o dispositivo esteja ligado, o armazenamento do CE é desbloqueado , e o usuário desbloqueou o dispositivo após receber um OTA; para resistência a ataques internos, também assumimos que o invasor obtém acesso a chaves de assinatura criptográficas de transmissão.

Especificamente, exigimos que o armazenamento do CE não possa ser lido por um invasor que tenha fisicamente o dispositivo e, em seguida, tenha estes recursos e limitações:

  • Pode usar a chave de assinatura de qualquer fornecedor ou empresa para assinar mensagens arbitrárias.
  • Pode fazer com que um OTA seja recebido pelo dispositivo.
  • Pode modificar a operação de qualquer hardware (processador de aplicativo, flash, etc.), exceto conforme detalhado abaixo, mas tal modificação envolve um atraso de pelo menos uma hora e um ciclo de energia que destrói o conteúdo da RAM.
  • Não é possível modificar a operação de hardware resistente à violação (por exemplo, Titan M).
  • Não é possível ler a RAM do dispositivo ativo.
  • Não é possível adivinhar a credencial do usuário (PIN, padrão, senha) ou fazer com que ela seja inserida.

Diretrizes para o implementador

A partir de julho de 2020, as implementações de Resume-on-Reboot HAL se enquadram em duas categorias:

  1. Se o hardware SoC suportar persistência de RAM entre reinicializações, os OEMs podem usar a implementação padrão em AOSP (Escrow RAM padrão).
  2. Se o hardware do dispositivo ou SoC suportar um enclave de hardware seguro (um coprocessador de segurança discreto com sua própria RAM e ROM), adicionalmente, ele deve:
    • Ser capaz de detectar a reinicialização da CPU principal.
    • Ter uma fonte de temporizador de hardware que persiste durante as reinicializações; ou seja, o enclave deve ser capaz de detectar a reinicialização e expirar um cronômetro definido antes da reinicialização.
    • Suporta o armazenamento de uma chave garantida no enclave RAM / ROM de forma que não possa ser recuperada com ataques offline. Ele deve armazenar a chave Resume-on-Reboot de uma forma que torne impossível para usuários internos ou invasores recuperá-la.

Escrow RAM padrão

O AOSP tem uma implementação do HAL Resume-on-Reboot usando a persistência de RAM. Para que isso funcione, os OEMs devem garantir que seus SoCs suportem a persistência de RAM nas reinicializações. Alguns SoCs são incapazes de persistir o conteúdo de RAM em uma reinicialização, portanto, os OEMs são aconselhados a consultar seus parceiros SoC antes de habilitar este HAL padrão. A referência canônica para isso na seção abaixo.

Quando um OTA é baixado e preparado para ser aplicado por meio de atualização A / B , A / B virtual ou outro método disponível através da classe RecoverySystem , Resume-on-Reboot tentará desbloquear o armazenamento Credential Encrypted (CE) após o dispositivo reinicia para aplicar a atualização OTA. Isso pode ser emparelhado com um sistema OTA que aplica atualizações quando for mais conveniente para o usuário, como nos momentos em que o dispositivo deve ficar ocioso.

Fluxo de atualização OTA usando Resume-on-Reboot

O aplicativo cliente OTA no telefone deve ter as Manifest.permission.REBOOT e Manifest.permisson.RECOVERY permissões para chamar os métodos necessários para implementar Resume-on-Reiniciar. Com esse pré-requisito estabelecido, o fluxo de uma atualização é:

  1. Atualização de downloads do aplicativo cliente OTA
  2. O aplicativo cliente OTA chama RecoverySystem#prepareForUnattendedUpdate que RecoverySystem#prepareForUnattendedUpdate que o usuário seja solicitado a RecoverySystem#prepareForUnattendedUpdate seu PIN, padrão ou senha na tela de bloqueio durante o próximo desbloqueio
  3. Na próxima vez que o usuário desbloquear o dispositivo na tela de bloqueio, o dispositivo estará pronto para que a atualização seja aplicada
  4. Chamadas de aplicativo cliente OTA para RecoverySystem#rebootAndApply que imediatamente aciona uma reinicialização

No final desse fluxo, o dispositivo é reinicializado e o mecanismo Resume-on-Reboot desbloqueia o armazenamento criptografado de credencial (CE). Para aplicativos, isso aparece como um desbloqueio de usuário normal, então eles recebem todos os sinais, como ACTION_LOCKED_BOOT_COMPLETED e ACTION_BOOT_COMPLETED como normalmente fariam.

Modificando as configurações do produto

Para que um produto seja marcado como compatível com o recurso Resume-on-Reboot, ele deve incluir uma implementação do HAL RebootEscrow e incluir o arquivo XML do marcador de recurso. A implementação padrão funciona bem em dispositivos que usam reinicialização a quente (ou seja, a energia não é removida da DRAM durante a reinicialização).

Marcador de recurso de garantia de reinicialização

O marcador de recurso também deve estar presente:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

Implementação HAL de garantia de reinicialização padrão

Para usar a implementação padrão, 65536 (0x10000) bytes devem ser reservados para a implementação. Esses bytes não devem ser gravados em armazenamento não volátil para que as propriedades de segurança sejam mantidas.

Mudanças na árvore do dispositivo do kernel Linux

Na árvore de dispositivos do kernel do Linux, você deve reservar memória para uma região pmem . No exemplo a seguir, 0x50000000 foi reservado:

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

Verifique se você possui um novo dispositivo no diretório de bloco com um nome como /dev/block/pmem0 (como pmem1 ou pmem2 ).

Device.mk changes

Supondo que seu novo dispositivo da etapa anterior seja denominado pmem0 , as novas entradas a seguir devem ser adicionadas a vendor/<oem>/<product>/device.mk :

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default

Regras SELinux

Novas entradas para file_contexts do dispositivo devem ser adicionadas:

/dev/block/pmem0  u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default  u:object_r:hal_rebootescrow_default_exec:s0