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

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

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

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

Фон

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

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

Модель угроз

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

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

Возможности

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

Ограничения

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

Решение

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

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

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

Повтор PIN-кода SIM-карты

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

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

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

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

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

Руководство по реализации

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

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

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

В многоклиентском потоке появился новый вызов isPreparedForUnattendedUpdate, который показан ниже.

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

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

TelephonyManager

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

 /**
    * 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 г. реализации HAL RoR делятся на две категории:

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

Хранение ключей шифрования ОЗУ по умолчанию

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

Процесс беспроводного обновления с помощью RoR

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

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

В конце этого процесса устройство перезагружается, а механизм перезагрузки при обновлении разблокирует хранилище, зашифрованное с помощью учетных данных. Для приложений это выглядит как обычная разблокировка устройства пользователем, поэтому они получают все сигналы, например 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 для перезагрузки по умолчанию

Чтобы использовать реализацию по умолчанию, необходимо зарезервировать 65 536 (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