Возобновление после перезагрузки

В Android 11 обновления OTA можно применять с помощью механизмов обновления A/B или виртуального обновления A/B в сочетании с методами класса RecoverySystem . После перезагрузки устройства для применения OTA-обновления функция возобновления при перезагрузке (RoR) разблокирует хранилище с зашифрованными учетными данными (CE) .

Хотя партнеры могут связать этот процесс с функцией системы OTA, которая применяет обновления, когда устройство находится в режиме ожидания в Android 11, в Android 12 партнерам не требуется дополнительная функция системы OTA. Процесс RoR обеспечивает дополнительную безопасность и удобство для пользователей, поскольку обновления можно выполнять во время простоя устройства, а функции многоклиентского и серверного обновления Android 12 вместе обеспечивают безопасность на аппаратном уровне устройства.

Хотя вы должны предоставить разрешение устройства для функции android.hardware.reboot_escrow для поддержки RoR в Android 11, вам не нужно делать это, чтобы включить серверный RoR в Android 12 и более поздних версиях, поскольку они не используют HAL.

Фон

Начиная с Android 7, Android поддерживает прямую загрузку , которая позволяет запускать приложения на устройстве до того, как пользователь разблокирует хранилище CE. Реализация поддержки прямой загрузки обеспечила пользователям удобство работы до того, как после загрузки потребуется ввести фактор знания экрана блокировки (LSKF).

RoR позволяет разблокировать хранилище CE всех приложений на устройстве, включая те, которые не поддерживают прямую загрузку, когда перезагрузка инициируется после обновления OTA. Эта функция позволяет пользователям получать уведомления от всех установленных приложений после перезагрузки.

Модель угроз

Реализация RoR должна гарантировать, что при попадании устройства в руки злоумышленника злоумышленнику будет чрезвычайно сложно восстановить данные пользователя, зашифрованные CE, даже если устройство включено, хранилище CE разблокировано, а устройство разблокировано пользователь после получения OTA-обновления. Сопротивление инсайдерским атакам должно быть эффективным, даже если злоумышленник получит доступ к широковещательным ключам криптографической подписи.

В частности, хранилище CE не должно быть прочитано злоумышленником, который физически владеет устройством и имеет следующие возможности и ограничения:

Возможности

  • Можно использовать ключ подписи любого поставщика или компании для подписи произвольных сообщений.
  • Может привести к тому, что устройство получит OTA-обновление.
  • Может изменять работу любого оборудования (например, процессора приложений или флэш-памяти), за исключением случаев, описанных в разделе «Ограничения» ниже. (Однако такая модификация включает в себя как задержку минимум на один час, так и цикл включения и выключения, приводящий к уничтожению содержимого ОЗУ.)

Ограничения

  • Невозможно изменить работу защищенного от несанкционированного доступа оборудования (например, Titan M).
  • Невозможно прочитать оперативную память работающего устройства.
  • Невозможно угадать учетные данные пользователя (PIN-код, шаблон, пароль) или иным образом вызвать их ввод.

Решение

Система обновлений Android 12 RoR обеспечивает защиту от очень изощренных злоумышленников, при этом пароли и PIN-коды устройства остаются на устройстве — они никогда не отправляются на серверы Google и не сохраняются на них. Это обзор процесса, который гарантирует, что предоставляемые уровни безопасности аналогичны аппаратной системе RoR на уровне устройства:

  • Android применяет криптографическую защиту к данным, хранящимся на устройстве.
  • Все данные защищены ключами, хранящимися в доверенной среде выполнения (TEE).
  • TEE выдает ключи только в том случае, если работающая операционная система проходит криптографическую аутентификацию ( проверенная загрузка ).
  • Служба RoR, работающая на серверах Google, защищает данные CE, сохраняя секрет, который можно получить только в течение ограниченного времени . Это работает во всей экосистеме Android.
  • Криптографический ключ, защищенный PIN-кодом пользователя, используется для разблокировки устройства и расшифровки хранилища CE.
    • Когда запланирована ночная перезагрузка, Android предлагает пользователю ввести PIN-код, а затем вычисляет синтетический пароль (SP).
    • Затем он дважды шифрует SP: один раз с помощью ключа K_s хранящегося в ОЗУ, и снова с помощью ключа K_k хранящегося в TEE.
    • SP с двойным шифрованием хранится на диске, а SP стирается из ОЗУ. Оба ключа создаются заново и используются только для одной перезагрузки .
  • Когда приходит время перезагрузки, Android доверяет K_s серверу. Квитанция с K_k шифруется перед сохранением на диске.
  • После перезагрузки Android использует K_k для расшифровки квитанции, а затем отправляет ее на сервер для получения K_s .
    • K_k и K_s используются для расшифровки SP, хранящегося на диске.
    • Android использует SP для разблокировки хранилища CE и обеспечения нормального запуска приложений.
    • K_k и K_s отбрасываются.

Обновления, обеспечивающие безопасность вашего телефона, могут устанавливаться в удобное для вас время: пока вы спите.

Повтор SIM-PIN

При определенных условиях PIN-код SIM-карты проверяется из кэша. Этот процесс называется повтором SIM-PIN.

SIM-карта с включенным PIN-кодом также должна пройти плавную проверку PIN-кода (воспроизведение SIM-PIN) после автоматической перезагрузки для восстановления сотовой связи (требуется для телефонных звонков, SMS-сообщений и услуг передачи данных). PIN-код SIM-карты и соответствующая информация о SIM-карте (ICCID и номер слота для SIM-карты) надежно хранятся вместе. Сохраненный PIN-код можно получить и использовать для проверки только после успешной автоматической перезагрузки. Если устройство защищено, PIN-код SIM-карты хранится вместе с ключами, защищенными LSKF. Если на SIM-карте включен PIN-код, для взаимодействия с сервером RoR требуется подключение Wi-Fi для обновления OTA и RoR на базе сервера, что обеспечивает базовую функциональность (с сотовой связью) после перезагрузки.

PIN-код SIM-карты повторно шифруется и сохраняется каждый раз, когда пользователь успешно включает, проверяет или изменяет его. PIN-код SIM-карты аннулируется, если происходит одно из следующих событий:

  • SIM-карта удалена или сброшена.
  • Пользователь отключает PIN-код.
  • Произошла перезагрузка, не инициированная RoR.

Сохраненный PIN-код SIM-карты можно использовать только один раз после перезагрузки, инициированной RoR, и только в течение очень короткого времени (20 секунд) – если данные SIM-карты совпадают. Сохраненный PIN-код SIM-карты никогда не покидает приложение TelephonyManager и не может быть получен внешними модулями.

Рекомендации по внедрению

В Android 12 функции RoR на основе нескольких клиентов и серверов снижают нагрузку на партнеров при отправке обновлений OTA. Необходимые обновления могут устанавливаться во время удобного простоя устройства, например в определенные часы сна.

Чтобы обновления OTA в такие периоды времени не отвлекали пользователей, используйте темный режим для уменьшения светового излучения. Для этого загрузчик устройства должен выполнить поиск строки Reason unattended . Если unattended равно true , переведите устройство в темный режим. Обратите внимание, что ответственность за снижение уровня звукового и светового излучения лежит на каждом OEM-производителе.

Если вы обновляетесь до Android 12 или запускаете устройства Android 12, вам не нужно ничего делать для реализации новой функциональности RoR.

В многоклиентском потоке есть один новый вызов, isPreparedForUnattendedUpdate , показанный ниже:

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

Вам не нужно это реализовывать, поскольку HAL устарел с Android 12.

Менеджер по телефонии

Клиент OTA вызывает системный API TelephonyManager когда перезагрузка неизбежна в Android 12. Этот API перемещает все кэшированные PIN-коды из состояния AVAILABLE в состояние REBOOT_READY . Системный API TelephonyManager защищен существующим разрешением REBOOT Manifest.

 /**
    * 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()

Системный API TelephonyManager используется привилегированными APK.

Тестирование

Чтобы протестировать новый API, выполните следующую команду:

    adb shell cmd phone unattended-reboot

Эта команда работает только тогда, когда оболочка запущена от имени пользователя root ( adb root ).

только Android 11

Оставшаяся часть этой страницы относится к Android 11.

По состоянию на июль 2020 года реализации RoR HAL делятся на две категории:

  1. Если оборудование SoC поддерживает сохранение ОЗУ при перезагрузках, OEM-производители могут использовать реализацию по умолчанию в AOSP ( депонирование ОЗУ по умолчанию ).
  2. Если аппаратное обеспечение устройства или SoC поддерживает безопасный аппаратный анклав (дискретный сопроцессор безопасности с собственными ОЗУ и ПЗУ), дополнительно необходимо выполнить следующее:
    • Уметь обнаруживать перезагрузку основного процессора.
    • Имейте источник аппаратного таймера, который сохраняется после перезагрузки. То есть анклав должен иметь возможность обнаружить перезагрузку и истечь таймером, установленным перед перезагрузкой.
    • Поддержка хранения депонированного ключа в ОЗУ/ПЗУ анклава, чтобы его нельзя было восстановить с помощью автономных атак. Он должен хранить ключ RoR таким образом, чтобы инсайдеры или злоумышленники не могли его восстановить.

Депонирование оперативной памяти по умолчанию

AOSP имеет реализацию RoR HAL, использующую постоянство ОЗУ. Чтобы это работало, OEM-производители должны убедиться, что их SoC поддерживают сохранение оперативной памяти при перезагрузках. Некоторые SoC не могут сохранять содержимое оперативной памяти после перезагрузки, поэтому OEM-производителям рекомендуется проконсультироваться со своими партнерами SoC, прежде чем включать этот HAL по умолчанию. Каноническая ссылка на это в следующем разделе.

Последовательность обновления OTA с использованием RoR

Клиентское приложение OTA на телефоне должно иметь разрешения Manifest.permission.REBOOT и Manifest.permission.RECOVERY для вызова необходимых методов для реализации RoR. При наличии этого предварительного условия процесс обновления следует следующим шагам:

  1. Клиентское приложение OTA загружает обновление.
  2. Клиентское приложение OTA вызывает RecoverySystem#prepareForUnattendedUpdate , в результате чего пользователю будет предложено ввести PIN-код, шаблон или пароль на экране блокировки во время следующей разблокировки.
  3. Пользователь разблокирует устройство на экране блокировки, и устройство готово к установке обновления.
  4. Клиентское приложение OTA вызывает RecoverySystem#rebootAndApply , что немедленно запускает перезагрузку.

В конце этого потока устройство перезагружается, и механизм RoR разблокирует хранилище зашифрованных учетных данных (CE). Для приложений это выглядит как обычная пользовательская разблокировка, поэтому они получают все сигналы, такие как ACTION_LOCKED_BOOT_COMPLETED и ACTION_BOOT_COMPLETED , которые они обычно поступают.

Изменение конфигурации продукта

Продукт, помеченный как поддерживающий функцию RoR в Android 11, должен включать реализацию RebootEscrow HAL и XML-файл маркера функции. Реализация по умолчанию хорошо работает на устройствах, использующих теплую перезагрузку (когда питание DRAM остается включенным во время перезагрузки).

Перезагрузить маркер функции условного депонирования

Маркер объекта также должен присутствовать:

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

Реализация HAL условного депонирования перезагрузки по умолчанию

Чтобы использовать реализацию по умолчанию, необходимо зарезервировать 65536 (0x10000) байт. Никогда не записывайте эти байты в энергонезависимое хранилище, чтобы гарантировать сохранение свойств безопасности.

Изменения в дереве устройств ядра Linux

В дереве устройств ядра Linux вы должны зарезервировать память для региона pmem . В следующем примере показано, что 0x50000000 зарезервировано:

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

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

Убедитесь, что в каталоге блоков есть новое устройство с именем типа /dev/block/pmem0 (например, pmem1 или pmem2 ).

Изменения в Device.mk

Предполагая, что ваше новое устройство из предыдущего шага называется pmem0 , вы должны убедиться, что следующие новые записи добавлены в 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
правила SELinux

Добавьте эти новые записи в 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
,

В Android 11 обновления OTA можно применять с помощью механизмов обновления A/B или виртуального обновления A/B в сочетании с методами класса RecoverySystem . После перезагрузки устройства для применения OTA-обновления функция возобновления при перезагрузке (RoR) разблокирует хранилище с зашифрованными учетными данными (CE) .

Хотя в Android 11 партнеры могут связать этот процесс с функцией системы OTA, которая применяет обновления, когда ожидается, что устройство будет бездействовать, в Android 12 партнерам не нужна дополнительная функция системы OTA. Процесс RoR обеспечивает дополнительную безопасность и удобство для пользователей, поскольку обновления можно выполнять во время простоя устройства, а функции многоклиентского и серверного обновления Android 12 вместе обеспечивают безопасность на аппаратном уровне устройства.

Хотя вы должны предоставить разрешение устройства для функции android.hardware.reboot_escrow для поддержки RoR в Android 11, вам не нужно делать это, чтобы включить серверный RoR в Android 12 и более поздних версиях, поскольку они не используют HAL.

Фон

Начиная с Android 7, Android поддерживает прямую загрузку , которая позволяет запускать приложения на устройстве до того, как пользователь разблокирует хранилище CE. Реализация поддержки прямой загрузки обеспечила пользователям удобство работы до того, как после загрузки потребуется ввести фактор знания экрана блокировки (LSKF).

RoR позволяет разблокировать хранилище CE всех приложений на устройстве, включая те, которые не поддерживают прямую загрузку, когда перезагрузка инициируется после обновления OTA. Эта функция позволяет пользователям получать уведомления от всех установленных приложений после перезагрузки.

Модель угроз

Реализация RoR должна гарантировать, что при попадании устройства в руки злоумышленника злоумышленнику будет чрезвычайно сложно восстановить данные пользователя, зашифрованные CE, даже если устройство включено, хранилище CE разблокировано, а устройство разблокировано пользователь после получения OTA-обновления. Сопротивление инсайдерским атакам должно быть эффективным, даже если злоумышленник получит доступ к широковещательным ключам криптографической подписи.

В частности, хранилище CE не должно быть прочитано злоумышленником, который физически владеет устройством и имеет следующие возможности и ограничения:

Возможности

  • Можно использовать ключ подписи любого поставщика или компании для подписи произвольных сообщений.
  • Может привести к тому, что устройство получит OTA-обновление.
  • Может изменять работу любого оборудования (например, процессора приложений или флэш-памяти), за исключением случаев, описанных в разделе «Ограничения» ниже. (Однако такая модификация включает в себя как задержку минимум на один час, так и цикл включения и выключения питания, приводящий к уничтожению содержимого ОЗУ.)

Ограничения

  • Невозможно изменить работу защищенного от несанкционированного доступа оборудования (например, Titan M).
  • Невозможно прочитать оперативную память работающего устройства.
  • Невозможно угадать учетные данные пользователя (PIN-код, шаблон, пароль) или иным образом вызвать их ввод.

Решение

Система обновлений Android 12 RoR обеспечивает защиту от очень изощренных злоумышленников, при этом пароли и PIN-коды устройства остаются на устройстве — они никогда не отправляются и не сохраняются на серверах Google. Это обзор процесса, который гарантирует, что предоставляемые уровни безопасности аналогичны аппаратной системе RoR на уровне устройства:

  • Android применяет криптографическую защиту к данным, хранящимся на устройстве.
  • Все данные защищены ключами, хранящимися в доверенной среде выполнения (TEE).
  • TEE выдает ключи только в том случае, если работающая операционная система проходит криптографическую аутентификацию ( проверенная загрузка ).
  • Служба RoR, работающая на серверах Google, защищает данные CE, сохраняя секрет, который можно получить только в течение ограниченного времени . Это работает во всей экосистеме Android.
  • Криптографический ключ, защищенный PIN-кодом пользователя, используется для разблокировки устройства и расшифровки хранилища CE.
    • Когда запланирована ночная перезагрузка, Android предлагает пользователю ввести PIN-код, а затем вычисляет синтетический пароль (SP).
    • Затем он дважды шифрует SP: один раз с помощью ключа K_s хранящегося в ОЗУ, и снова с помощью ключа K_k хранящегося в TEE.
    • SP с двойным шифрованием хранится на диске, а SP стирается из ОЗУ. Оба ключа создаются заново и используются только для одной перезагрузки .
  • Когда приходит время перезагрузки, Android доверяет K_s серверу. Квитанция с K_k шифруется перед сохранением на диске.
  • После перезагрузки Android использует K_k для расшифровки квитанции, а затем отправляет ее на сервер для получения K_s .
    • K_k и K_s используются для расшифровки SP, хранящегося на диске.
    • Android использует SP для разблокировки хранилища CE и обеспечения нормального запуска приложений.
    • K_k и K_s отбрасываются.

Обновления, обеспечивающие безопасность вашего телефона, могут устанавливаться в удобное для вас время: пока вы спите.

Повтор SIM-PIN

При определенных условиях PIN-код SIM-карты проверяется из кэша. Этот процесс называется повтором SIM-PIN.

SIM-карта с включенным PIN-кодом также должна пройти плавную проверку PIN-кода (воспроизведение SIM-PIN) после автоматической перезагрузки для восстановления сотовой связи (требуется для телефонных звонков, SMS-сообщений и услуг передачи данных). PIN-код SIM-карты и соответствующая информация о SIM-карте (ICCID и номер слота SIM) надежно хранятся вместе. Сохраненный PIN-код можно получить и использовать для проверки только после успешной автоматической перезагрузки. Если устройство защищено, PIN-код SIM-карты хранится вместе с ключами, защищенными LSKF. Если на SIM-карте включен PIN-код, для взаимодействия с сервером RoR требуется подключение Wi-Fi для обновления OTA и RoR на базе сервера, что обеспечивает базовую функциональность (с сотовой связью) после перезагрузки.

PIN-код SIM-карты повторно шифруется и сохраняется каждый раз, когда пользователь успешно включает, проверяет или изменяет его. PIN-код SIM-карты аннулируется, если происходит одно из следующих событий:

  • SIM-карта удалена или сброшена.
  • Пользователь отключает PIN-код.
  • Произошла перезагрузка, не инициированная RoR.

Сохраненный PIN-код SIM-карты можно использовать только один раз после перезагрузки, инициированной RoR, и только в течение очень короткого времени (20 секунд) – если данные SIM-карты совпадают. Сохраненный PIN-код SIM-карты никогда не покидает приложение TelephonyManager и не может быть получен внешними модулями.

Рекомендации по внедрению

В Android 12 функции RoR на основе нескольких клиентов и серверов снижают нагрузку на партнеров при отправке обновлений OTA. Необходимые обновления могут устанавливаться во время удобного простоя устройства, например в определенные часы сна.

Чтобы обновления OTA в такие периоды времени не отвлекали пользователей, используйте темный режим для уменьшения светового излучения. Для этого загрузчик устройства должен выполнить поиск строки Reason unattended . Если unattended равно true , переведите устройство в темный режим. Обратите внимание, что ответственность за снижение уровня звукового и светового излучения лежит на каждом OEM-производителе.

Если вы обновляетесь до Android 12 или запускаете устройства Android 12, вам не нужно ничего делать для реализации новой функциональности RoR.

В многоклиентском потоке есть один новый вызов, isPreparedForUnattendedUpdate , показанный ниже:

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

Вам не нужно это реализовывать, поскольку HAL устарел с Android 12.

Менеджер по телефонии

Клиент OTA вызывает системный API TelephonyManager когда перезагрузка неизбежна в Android 12. Этот API перемещает все кэшированные PIN-коды из состояния AVAILABLE в состояние REBOOT_READY . Системный API TelephonyManager защищен существующим разрешением REBOOT Manifest.

 /**
    * 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()

Системный API TelephonyManager используется привилегированными APK.

Тестирование

Чтобы протестировать новый API, выполните следующую команду:

    adb shell cmd phone unattended-reboot

Эта команда работает только тогда, когда оболочка запущена от имени пользователя root ( adb root ).

только Android 11

Оставшаяся часть этой страницы относится к Android 11.

По состоянию на июль 2020 года реализации RoR HAL делятся на две категории:

  1. Если оборудование SoC поддерживает сохранение ОЗУ при перезагрузках, OEM-производители могут использовать реализацию по умолчанию в AOSP ( депонирование ОЗУ по умолчанию ).
  2. Если аппаратное обеспечение устройства или SoC поддерживает безопасный аппаратный анклав (дискретный сопроцессор безопасности с собственными ОЗУ и ПЗУ), дополнительно необходимо выполнить следующее:
    • Уметь обнаруживать перезагрузку основного процессора.
    • Имейте источник аппаратного таймера, который сохраняется после перезагрузки. То есть анклав должен иметь возможность обнаружить перезагрузку и истечь таймером, установленным перед перезагрузкой.
    • Поддержка хранения депонированного ключа в ОЗУ/ПЗУ анклава, чтобы его нельзя было восстановить с помощью автономных атак. Он должен хранить ключ RoR таким образом, чтобы инсайдеры или злоумышленники не могли его восстановить.

Депонирование оперативной памяти по умолчанию

AOSP имеет реализацию RoR HAL, использующую постоянство ОЗУ. Чтобы это работало, OEM-производители должны убедиться, что их SoC поддерживают сохранение оперативной памяти при перезагрузках. Некоторые SoC не могут сохранять содержимое оперативной памяти после перезагрузки, поэтому OEM-производителям рекомендуется проконсультироваться со своими партнерами SoC, прежде чем включать этот HAL по умолчанию. Каноническая ссылка на это в следующем разделе.

Последовательность обновления OTA с использованием RoR

Клиентское приложение OTA на телефоне должно иметь разрешения Manifest.permission.REBOOT и Manifest.permission.RECOVERY для вызова необходимых методов для реализации RoR. При наличии этого предварительного условия процесс обновления следует следующим шагам:

  1. Клиентское приложение OTA загружает обновление.
  2. Клиентское приложение OTA вызывает RecoverySystem#prepareForUnattendedUpdate , в результате чего пользователю будет предложено ввести PIN-код, шаблон или пароль на экране блокировки во время следующей разблокировки.
  3. Пользователь разблокирует устройство на экране блокировки, и устройство готово к установке обновления.
  4. Клиентское приложение OTA вызывает RecoverySystem#rebootAndApply , что немедленно запускает перезагрузку.

В конце этого процесса устройство перезагружается, и механизм RoR разблокирует хранилище зашифрованных учетных данных (CE). Для приложений это выглядит как обычная пользовательская разблокировка, поэтому они получают все сигналы, такие как ACTION_LOCKED_BOOT_COMPLETED и ACTION_BOOT_COMPLETED , которые они обычно поступают.

Изменить конфигурации продукта

Продукт, помеченный как поддерживающий функцию RoR в Android 11, должен включать реализацию RebootEscrow HAL и XML-файл маркера функции. Реализация по умолчанию хорошо работает на устройствах, использующих теплую перезагрузку (когда питание DRAM остается включенным во время перезагрузки).

Перезагрузить маркер функции условного депонирования

Маркер объекта также должен присутствовать:

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

Реализация HAL условного депонирования перезагрузки по умолчанию

Чтобы использовать реализацию по умолчанию, необходимо зарезервировать 65536 (0x10000) байт. Никогда не записывайте эти байты в энергонезависимое хранилище, чтобы гарантировать сохранение свойств безопасности.

Изменения в дереве устройств ядра Linux

В дереве устройств ядра Linux вы должны зарезервировать память для региона pmem . В следующем примере показано, что 0x50000000 зарезервировано:

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

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

Убедитесь, что в каталоге блоков есть новое устройство с именем типа /dev/block/pmem0 (например, pmem1 или pmem2 ).

Изменения в Device.mk

Предполагая, что ваше новое устройство из предыдущего шага называется pmem0 , вы должны убедиться, что следующие новые записи добавлены в 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
правила SELinux

Добавьте эти новые записи в 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