O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Retomar na reinicialização

No Android 11, actualizações OTA pode ser aplicado usando a actualização de A / B ou de actualização de A / B virtuais mecanismos, combinados com os RecoverySystem métodos de classe. Depois que um dispositivo é reiniciado para aplicar uma atualização OTA, Resume-on-reboot (RoR) desbloqueia o dispositivo Credencial criptografados (CE) de armazenamento .

Embora os parceiros possam emparelhar esse processo com um recurso do sistema OTA que aplica atualizações quando o dispositivo está ocioso no Android 11, no Android 12 os parceiros não precisam de um recurso adicional do sistema OTA. O processo de RoR fornece segurança e conveniência adicionais aos usuários porque as atualizações podem ser feitas durante os tempos de inatividade do dispositivo, enquanto as funcionalidades de atualização baseadas em servidor e multi-cliente do Android 12 juntas fornecem segurança do tipo de nível de hardware do dispositivo.

Embora você deve fornecer permissão de dispositivo para o android.hardware.reboot_escrow recurso para apoiar RoR no Android 11, você não precisa deste para permitir baseada em servidor RoR no Android 12 e superior, porque não usar o HAL.

fornecer permissões do dispositivo para o android.hardware.reboot_escrow característica. Você não precisa fazer nada para habilitar o RoR baseado em servidor no Android 12, porque o Android 12 e superior não usam o HAL.

Fundo

Começando com Android 7, Android suportado direto de inicialização , que permite que os aplicativos em um dispositivo para iniciar antes do armazenamento CE é desbloqueado pelo usuário. A implementação do suporte para inicialização direta proporcionou aos usuários uma experiência melhor antes que o fator de conhecimento da tela de bloqueio (LSKF) precisasse ser inserido após a inicialização.

O RoR permite que o armazenamento CE de todos os aplicativos em um dispositivo seja desbloqueado, incluindo aqueles que não suportam inicialização direta, quando uma reinicialização é iniciada após uma atualização 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 RoR deve garantir que, quando um dispositivo de cair nas mãos de um atacante, é extremamente difícil para o atacante recuperar dados CE- criptografada do usuário, mesmo se o dispositivo estiver ligado, armazenamento CE é desbloqueado, e o dispositivo é desbloqueado por o usuário após receber uma atualização OTA. A resistência a ataques internos deve ser eficaz mesmo se o invasor obtiver acesso às chaves de assinatura criptográficas de transmissão.

Especificamente, armazenamento CE não deve ser lido por um atacante que tenha fisicamente o dispositivo, e tem essas capacidades e limitações:

Capacidades

  • 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 o funcionamento de qualquer hardware (como um processador de aplicação, ou memória flash) - exceto conforme detalhado na 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 à violação (por exemplo, um Titan M).
  • Não é possível ler a RAM do dispositivo ao vivo.
  • Não é possível adivinhar as credenciais do usuário (PIN, padrão, senha) ou de outra forma fazer com que sejam inseridas.

Solução

O sistema de atualização do Android 12 RoR oferece segurança contra invasores muito sofisticados e faz isso enquanto as senhas e PINs do 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 de nível de dispositivo baseado em hardware:

  • O Android aplica proteções criptográficas aos dados armazenados em um dispositivo.
  • Todos os dados são protegido por chaves armazenadas no ambiente de execução confiável (ETE).
  • O TEE só libera as chaves se o sistema operacional em execução passa a autenticação de criptografia (boot verificado).
  • O serviço RoR rodando em servidores do Google protege os dados CE, guardando um segredo que pode ser recuperada apenas por um período 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 CE.
    • Quando uma reinicialização noturna é agendada, o Android solicita que o usuário insira seu PIN e, em seguida, calcula uma senha sintética (SP).
    • Em seguida, criptografa o SP duas vezes: uma vez com uma chave K_s armazenadas na RAM, e novamente com uma chave K_k armazenado no TEE.
    • O SP com criptografia dupla é armazenado em disco e o SP é apagado da RAM. Ambas as chaves são recém-gerado e usado para apenas uma reinicialização.
  • Quando é hora de reiniciar, Android confia K_s para o servidor. O recibo com K_k fica criptografada antes de ser armazenado em disco.
  • Após a reinicialização, o Android usa K_k para descriptografar o recebimento, em seguida, envia para o servidor para recuperar K_s .
    • K_k e K_s são usadas para descriptografar o SP armazenados no disco.
    • O Android usa o SP para desbloquear o armazenamento CE e permitir a inicialização normal do aplicativo.
    • K_k e K_s são descartados.

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

Repetição do SIM-PIN

Sob certas condições, o código PIN de um cartão SIM é verificado a partir de um cache, um processo chamado repetição do SIM-PIN.

Um cartão SIM com um PIN habilitado também deve passar por uma verificação contínua do código PIN (uma repetição do SIM-PIN) 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 SIM e as informações correspondentes do cartão SIM (o ICCID e o número do slot do SIM) 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 protegido, o PIN do SIM é armazenado com chaves protegidas pelo LSKF. Se o SIM tem o seu PIN ativado, interação com o servidor RoR requer uma conexão Wi-Fi para a atualização OTA e RoR baseada em servidor, o que garante a funcionalidade básica (com conectividade celular) após a reinicialização.

O PIN do SIM é criptografado novamente e armazenado sempre que o usuário o habilita, verifica ou modifica com sucesso. O PIN do SIM é descartado se qualquer um dos seguintes ocorrer:

  • O SIM é removido ou redefinido.
  • O usuário desativa o PIN.
  • Ocorreu uma reinicialização não iniciada por RoR.

O PIN SIM armazenado só pode ser usado uma vez após o reinício iniciado RoR, e apenas por um período de tempo muito curto (20 segundos) - se os detalhes do jogo cartão SIM. O PIN do SIM armazenado nunca sai do aplicativo TelephonyManager e não pode ser recuperado por módulos externos.

Diretrizes de implementação

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

Para garantir que as atualizações OTA durante esses períodos de tempo não interrompam os usuários, use o modo escuro para mitigar as emissões de luz. Para isso, têm a procura de dispositivos bootloader pela razão de corda unattended . Se unattended é true , colocar o dispositivo no modo escuro. Observe que é responsabilidade de cada OEM mitigar as emissões de som e luz.

Se você estiver atualizando para o Android 12 ou lançando dispositivos Android 12, não precisará fazer nada para implementar a nova funcionalidade RoR.

Há uma nova chamada no fluxo de multi-cliente, isPreparedForUnattendedUpdate , mostrado abaixo:

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

Você não precisa implementar isso, porque o HAL está obsoleto a partir do Android 12.

TelephonyManager

O cliente OTA invoca o TelephonyManager sistema API quando uma reinicialização é iminente no Android 12. Esta API move tudo em cache códigos PIN do AVAILABLE estado para o REBOOT_READY estado. O TelephonyManager API sistema é protegido pela existente REBOOT permissão 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.

Testando

Para testar a nova API, execute este comando:

    adb shell cmd phone unattended-reboot

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

Android 11 apenas

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

Em julho de 2020, as implementações de RoR HAL se enquadram em duas categorias:

  1. Se a persistência suportes de hardware SoC RAM entre as reinicializações, os OEMs podem usar a implementação padrão em AOSP ( RAM padrão de Custódia ).
  2. Se o hardware do dispositivo ou SoC suportar um enclave de hardware seguro (um co-processador de segurança discreto com sua própria RAM e ROM), adicionalmente, ele deve fazer o seguinte:
    • Ser capaz de detectar uma 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 RoR de uma maneira que impossibilite que usuários internos ou invasores a recuperem.

Custódia de RAM padrão

O AOSP tem uma implementação do RoR HAL usando persistência de RAM. Para que isso funcione, os OEMs devem garantir que seus SoCs suportem a persistência de RAM durante as 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 seguinte.

Fluxo de atualização OTA usando RoR

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

  1. O aplicativo cliente OTA baixa a atualização.
  2. Chamadas OTA aplicativos cliente para RecoverySystem#prepareForUnattendedUpdate que desencadeia o usuário será solicitado para o seu PIN, padrão ou senha 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 que a atualização seja aplicada.
  4. Chamadas de aplicativos cliente OTA para RecoverySystem#rebootAndApply , o que desencadeia imediatamente uma reinicialização.

No final desse fluxo, o dispositivo é reinicializado e o mecanismo RoR desbloqueia o armazenamento criptografado de credencial (CE). Para apps, este aparece como um desbloqueio de usuário normal, para que eles recebam todos os sinais, tais como ACTION_LOCKED_BOOT_COMPLETED e ACTION_BOOT_COMPLETED que fazem normalmente.

Modificando as configurações do produto

Um produto marcado como compatível com o recurso RoR no Android 11 deve incluir uma implementação do RebootEscrow HAL e incluir o arquivo XML do marcador de recurso. A implementação padrão funciona bem em dispositivos que usam reinicialização a quente (quando a energia da DRAM permanece ligada 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 de HAL de garantia de reinicialização padrão

Para usar a implementação padrão, você deve reservar 65536 (0x10000) bytes. Nunca grave esses bytes em armazenamento não volátil para garantir que as propriedades de segurança persistam.

Mudanças na árvore do dispositivo do kernel Linux

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

  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 bloco com um nome como /dev/block/pmem0 (como pmem1 ou pmem2 ).

Device.mk changes

Assumindo que o seu novo dispositivo da etapa anterior é nomeado pmem0 , você deve garantir as seguintes novas entradas são adicionadas ao 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

Adicionar estas novas entradas do dispositivo file_contexts :

/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