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

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

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

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

предоставить разрешения устройства для функции android.hardware.reboot_escrow . Вам не нужно ничего делать, чтобы включить RoR на основе сервера в Android 12, потому что 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 требуется соединение WiFi для обновления 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 ).

только андроид 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