Retomar na reinicialização

No Android 11, as atualizações OTA podem ser aplicadas usando os mecanismos de atualização A/B ou atualização A/B virtual combinados com os métodos da classe RecoverySystem. Depois que um dispositivo é reinicializado para aplicar uma atualização OTA, a ação de retomar na reinicialização (RoR, na sigla em inglês) desbloqueia o armazenamento criptografado por credenciais (CE) do dispositivo.

Embora os parceiros possam parear esse processo com um recurso do sistema OTA que aplica atualizações quando o dispositivo está inativo no Android 11, no Android 12, os parceiros não precisam de outro recurso do sistema OTA. O processo de RoR oferece mais segurança e conveniência aos usuários, porque as atualizações podem ser feitas durante os tempos de inatividade do dispositivo, enquanto as funcionalidades de atualização de múltiplos clientes e servidores do Android 12 juntas oferecem segurança de tipo no hardware do dispositivo.

Embora seja necessário fornecer permissão ao dispositivo para que o recurso android.hardware.reboot_escrow ofereça suporte à RoR no Android 11, não é necessário fazer isso para ativar a RoR baseada em servidor no Android 12 e versões mais recentes, porque eles não usam o HAL.

Contexto

A partir do Android 7, o Android oferece suporte à inicialização direta, que permite que os apps em um dispositivo sejam iniciados antes que o armazenamento do CE seja desbloqueado pelo usuário. A implementação do suporte à inicialização direta proporcionou aos usuários uma experiência melhor antes que o fator de conhecimento da tela de bloqueio (LSKF, na sigla em inglês) precisasse ser inserido após a inicialização.

O RoR permite que o armazenamento CE de todos os apps em um dispositivo seja desbloqueado, incluindo aqueles que não têm suporte à inicialização direta, quando uma reinicialização é iniciada após uma atualização OTA. Esse recurso permite que os usuários recebam notificações de todos os apps instalados após a reinicialização.

Modelo de ameaça

Uma implementação do RoR precisa garantir que, quando um dispositivo cai nas mãos de um invasor, seja extremamente difícil para o invasor recuperar os dados criptografados por CE, mesmo que o dispositivo esteja ligado, o armazenamento CE seja desbloqueado e o dispositivo seja desbloqueado pelo usuário após receber uma atualização OTA. A resistência a ataques de pessoas com informações privilegiadas precisa ser eficaz mesmo se o invasor tiver acesso às chaves de assinatura criptográfica de transmissão.

Especificamente, o armazenamento de CE não pode ser lido por um invasor que tem o dispositivo fisicamente e tem estes recursos e limitações:

Recursos

• Pode usar a chave de assinatura de qualquer fornecedor ou empresa para assinar mensagens arbitrárias.
• Pode fazer com que o dispositivo receba uma atualização OTA.
• Pode modificar a operação de qualquer hardware (como um processador de aplicativos ou memória flash), exceto conforme detalhado em Limitações abaixo. No entanto, essa modificação envolve um atraso de pelo menos uma hora e um ciclo de energia que destrói o conteúdo da RAM.

Limitações

• Não é possível modificar a operação de hardware resistente a adulteração (por exemplo, um Titan M).
• Não pode ler a RAM do dispositivo ativo.
• Não consegue adivinhar as credenciais do usuário (PIN, padrão, senha) nem fazer com que elas sejam inseridas.

Solução

O sistema de atualização de RoR do Android 12 oferece segurança contra invasores muito sofisticados e faz isso enquanto senhas e PINs no dispositivo permanecem no dispositivo. Eles nunca são enviados ou armazenados nos servidores do Google. Esta é uma visão geral do processo que garante que os níveis de segurança fornecidos sejam semelhantes a um sistema RoR baseado em hardware e no dispositivo:

• O Android aplica proteções criptográficas aos dados armazenados em um dispositivo.
• Todos os dados são protegidos por chaves armazenadas no ambiente de execução confiável (TEE).
• O TEE só libera as chaves se o sistema operacional em execução passar pela autenticação criptográfica (inicialização verificada).
• O serviço RoR em execução nos servidores do Google protege os dados do CE armazenando um secret que pode ser recuperado por tempo limitado. Isso funciona em todo o ecossistema Android.
• Uma chave criptográfica, protegida por um PIN do usuário, é usada para desbloquear o dispositivo e descriptografar o armazenamento de CE.
  • Quando uma reinicialização noturna é programada, o Android solicita que o usuário insira o PIN e calcula uma senha sintética (SP, na sigla em inglês).
  • Em seguida, ele criptografa o SP duas vezes: uma com uma chave K_s armazenada na RAM e outra com uma chave K_k armazenada no TEE.
  • O SP duplamente criptografado é armazenado em disco e o SP é apagado da RAM. As duas chaves são geradas e usadas apenas para uma reinicialização.
• Quando chega a hora de reiniciar, o Android confia a K_s ao servidor. O comprovante com K_k é criptografado antes de ser armazenado no disco.
• Após a reinicialização, o Android usa K_k para descriptografar o comprovante e, em seguida, enviá-lo ao servidor para extrair o K_s.
  • K_k e K_s são usados para descriptografar o SP armazenado no disco.
  • O Android usa o SP para desbloquear o armazenamento do CE e permitir a inicialização normal do app.
  • K_k e K_s são descartados.

As atualizações que mantêm seu smartphone seguro podem acontecer em um momento conveniente para você: enquanto você dorme.

Importante :a funcionalidade de RoR baseada no servidor funciona para que o servidor nunca aprenda o PIN do usuário: a chave K_s é o único secret confiado ao servidor e é gerada aleatoriamente sempre. As senhas no dispositivo e o PIN permanecem no dispositivo. Eles nunca são enviados para servidores e nunca são armazenados neles.

Repetição do PIN do chip

Em determinadas condições, o código PIN de um chip é verificado em um cache, um processo chamado repetição do PIN do chip.

Um chip com um PIN ativado também precisa passar por uma verificação de código PIN simples (uma repetição do PIN do chip) após uma reinicialização autônoma para restaurar a conectividade celular (necessária para chamadas telefônicas, mensagens SMS e serviços de dados). O PIN do chip e as informações do chip correspondente (o ICCID e o número do slot do chip) são armazenados juntos com segurança. O PIN armazenado pode ser recuperado e usado para verificação somente após uma reinicialização autônoma bem-sucedida. Se o dispositivo estiver seguro, o PIN do chip será armazenado com chaves protegidas pela LSKF. Se o PIN do chip estiver ativado, a interação com o servidor RoR requer uma conexão Wi-Fi para a atualização OTA e o RoR baseado em servidor, o que garante a funcionalidade básica (com conexão celular) após a reinicialização.

O PIN do chip é recriptografado e armazenado sempre que o usuário o ativa, verifica ou modifica. O PIN do SIM será descartado se uma das seguintes situações ocorrer:

• O chip é removido ou redefinido.
• O usuário desativa o PIN.
• Uma reinicialização não iniciada pelo RoR ocorreu.

O PIN do chip armazenado só pode ser usado uma vez após a reinicialização iniciada pelo RoR e apenas por um período muito curto (20 segundos) se os detalhes do cartão SIM corresponderem. O PIN do chip armazenado nunca sai do app TelephonyManager e não pode ser recuperado por módulos externos.

Diretrizes de implementação

No Android 12, as funções de RoR baseadas em servidor e de vários clientes oferecem uma carga mais leve aos parceiros quando eles enviam atualizações OTA. As atualizações necessárias podem ocorrer durante os períodos de inatividade convenientes do dispositivo, como durante horas de suspensão designadas.

Para garantir que as atualizações OTA durante esses períodos não interrompam os usuários, use o modo escuro para reduzir as emissões de luz. Para fazer isso, faça com que o carregador de inicialização do dispositivo procure a string unattended. Se unattended for true, coloque o dispositivo no modo escuro. É responsabilidade de cada OEM mitigar as emissões de som e luz.

Se você está fazendo upgrade para o Android 12 ou lançando dispositivos com ele, não é necessário fazer nada para implementar a nova funcionalidade de RoR.

Há uma nova chamada no fluxo de múltiplos clientes, isPreparedForUnattendedUpdate, mostrada abaixo:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

Não é necessário implementar isso, porque a HAL foi descontinuada no Android 12.

Gerente de telefonia

O cliente OTA invoca a API do sistema TelephonyManager quando uma reinicialização é iminente no Android 12. Essa API move todos os PINs em cache do estado AVAILABLE para o estado REBOOT_READY. A API do sistema TelephonyManager é protegida pela permissão REBOOT do manifesto.

 /**
    * The unattended reboot was prepared successfully.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;

   /**
    * The unattended reboot was prepared, but the user will need to manually
    * enter the PIN code of at least one SIM card present in the device.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;

   /**
    * The unattended reboot was not prepared due to generic error.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;

   /** @hide */
   @Retention(RetentionPolicy.SOURCE)
   @IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
           value = {
                   PREPARE_UNATTENDED_REBOOT_SUCCESS,
                   PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
                   PREPARE_UNATTENDED_REBOOT_ERROR
           })
   public @interface PrepareUnattendedRebootResult {}

   /**
    * Prepare TelephonyManager for an unattended reboot. The reboot is
    * required to be done shortly after the API is invoked.
    *
    * Requires system privileges.
    *
    * <p>Requires Permission:
    *   {@link android.Manifest.permission#REBOOT}
    *
    * @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
    * {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
    * at least one SIM card for which the user needs to manually enter the PIN
    * code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
    * of error.
    * @hide
    */
   @SystemApi
   @RequiresPermission(android.Manifest.permission.REBOOT)
   @PrepareUnattendedRebootResult
   public int prepareForUnattendedReboot()

A API do sistema TelephonyManager é usada por APKs privilegiados.

Teste

Para testar a nova API, execute este comando:

    adb shell cmd phone unattended-reboot

Esse comando só funciona quando o shell está sendo executado como raiz (adb root).

Somente Android 11

O restante desta página se refere ao Android 11.

Desde julho de 2020, as implementações do RoR HAL são divididas em duas categorias:

1. Se o hardware SoC oferecer suporte à persistência de RAM entre reinicializações, os OEMs poderão usar a implementação padrão no AOSP (Escrow de RAM padrão).
2. Se o hardware do dispositivo ou o SoC oferecer suporte a um enclave de hardware seguro (um coprocessador de segurança discreto com RAM e ROM próprios), ele também precisará fazer o seguinte:
   • Ser capaz de detectar uma reinicialização da CPU principal.
   • Ter uma fonte de timer de hardware que persiste nas reinicializações. Ou seja, o enclave precisa ser capaz de detectar a reinicialização e expirar um cronômetro definido antes da reinicialização.
   • Suporte para armazenamento de uma chave depositada no enclave RAM/ROM para que ela não possa ser recuperada com ataques off-line. Ela precisa armazenar a chave de RoR de uma forma que impossibilite que pessoas de dentro ou invasores a recuperem.

Depósito em garantia de RAM padrão

O AOSP tem uma implementação do HAL de RoR usando a persistência de RAM. Para que isso funcione, os OEMs precisam garantir que os SoCs ofereçam suporte à persistência de RAM durante as reinicializações. Alguns SoCs não conseguem manter o conteúdo da RAM durante uma reinicialização. Portanto, recomendamos que os OEMs consultem os parceiros do SoC antes de ativar esse HAL padrão. A referência canônica para isso na seção a seguir.

Fluxo da atualização OTA usando RoR

O app cliente OTA no smartphone precisa ter as permissões Manifest.permission.REBOOT e Manifest.permission.RECOVERY para chamar os métodos necessários para implementar o RoR. Com esse pré-requisito, o fluxo de uma atualização segue estas etapas:

1. o app cliente OTA faz o download da atualização.
2. O app cliente OTA chama RecoverySystem#prepareForUnattendedUpdate, o que aciona a solicitação do PIN, padrão ou senha do usuário na tela de bloqueio durante o próximo desbloqueio.
3. O usuário desbloqueia o dispositivo na tela de bloqueio, e o dispositivo está pronto para receber a atualização.
4. O app cliente OTA chama para RecoverySystem#rebootAndApply, o que aciona imediatamente uma reinicialização.

No final desse fluxo, o dispositivo é reiniciado, e o mecanismo de retorno de chamada desbloqueia o armazenamento criptografado por credencial (CE, na sigla em inglês). Para apps, isso aparece como um desbloqueio normal do usuário. Portanto, eles recebem todos os indicadores, como ACTION_LOCKED_BOOT_COMPLETED e ACTION_BOOT_COMPLETED, que normalmente recebem.

Modificar as configurações do produto

Um produto marcado como compatível com o recurso RoR no Android 11 precisa incluir uma implementação da HAL RestartEscrow e incluir o arquivo XML do marcador de recursos. A implementação padrão funciona bem em dispositivos que usam a reinicialização com estado salvo (quando a energia para a DRAM permanece ativada durante a reinicialização).

Marcador de recurso de depósito de inicialização

O marcador de elemento também precisa 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 de HAL de garantia de reinicialização padrão

Para usar a implementação padrão, é necessário reservar 65536 (0x10000) bytes. Nunca grave esses bytes em armazenamentos não voláteis para garantir que as propriedades de segurança persistam.

Mudanças na árvore de dispositivos do kernel do Linux

Na árvore de dispositivos do kernel do Linux, você precisa reservar memória para uma região pmem. O exemplo a seguir mostra a reserva de 0x50000000:

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

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

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

Mudanças no Device.mk

Supondo que o novo dispositivo da etapa anterior seja chamado de pmem0, é necessário garantir que as novas entradas a seguir sejam 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 do SELinux

Adicione estas novas entradas ao file_contexts do dispositivo:

/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