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

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

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

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

Фон

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

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

модель угроз

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

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

Возможности

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

Ограничения

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

Решение

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

  • Android применяет криптографическую защиту к данным, хранящимся на устройстве.
  • Все данные защищены ключами, хранящимися в доверенной среде выполнения (TEE).
  • TEE выдает ключи только в том случае, если запущенная операционная система проходит криптографическую аутентификацию ( проверенную загрузку ).
  • Сервис RoR, работающий на серверах Google, обеспечивает безопасность данных CE, храня секретный ключ, который можно получить только в течение ограниченного времени . Это работает во всей экосистеме Android.
  • Для разблокировки устройства и расшифровки данных из хранилища CE используется криптографический ключ, защищенный PIN-кодом пользователя.
    • При запланированной ночной перезагрузке Android запрашивает у пользователя ввод PIN-кода, после чего вычисляет синтетический пароль (СП).
    • Затем он дважды шифрует 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-кода (воспроизведение PIN-кода SIM-карты) после автоматической перезагрузки для восстановления сотовой связи (необходимой для телефонных звонков, SMS-сообщений и передачи данных). PIN-код SIM-карты и соответствующая информация о SIM-карте (ICCID и номер слота SIM-карты) надежно хранятся вместе. Сохраненный PIN-код может быть получен и использован для проверки только после успешной автоматической перезагрузки. Если устройство защищено, PIN-код SIM-карты хранится с ключами, защищенными LSKF. Если PIN-код SIM-карты активирован, для взаимодействия с сервером 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 , переведите устройство в темный режим. Обратите внимание, что ответственность за снижение звукового и светового излучения лежит на каждом производителе оборудования.

Если вы обновляете систему до 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.

TelephonyManager

В Android 12 OTA-клиент вызывает системный API TelephonyManager при неизбежной перезагрузке. Этот 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 поддерживает сохранение данных в оперативной памяти после перезагрузки, производители оборудования могут использовать реализацию по умолчанию в AOSP ( Default RAM Escrow ).
  2. Если аппаратное обеспечение устройства или SoC поддерживает защищенный аппаратный анклав (дискретный сопроцессор безопасности со своей собственной оперативной и постоянной памятью), то дополнительно оно должно выполнять следующие функции:
    • Должна быть возможность обнаруживать перезагрузку основного процессора.
    • Необходимо иметь аппаратный таймер, который сохраняется после перезагрузки. То есть, анклав должен уметь обнаруживать перезагрузку и завершать работу таймера, установленного до перезагрузки.
    • Поддерживается хранение депонированного ключа в оперативной/постоянной памяти анклава таким образом, чтобы его нельзя было восстановить с помощью офлайн-атак. Ключ RoR должен храниться таким образом, чтобы инсайдерам или злоумышленникам было невозможно его восстановить.

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

В AOSP реализована реализация RoR HAL с использованием сохранения данных в оперативной памяти. Для этого производители оборудования должны убедиться, что их SoC поддерживают сохранение данных в оперативной памяти после перезагрузки. Некоторые SoC не способны сохранять содержимое оперативной памяти после перезагрузки, поэтому производителям оборудования рекомендуется проконсультироваться со своими партнерами по SoC, прежде чем включать этот стандартный HAL. Справочная информация по этому вопросу приведена в следующем разделе.

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

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

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

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

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

Продукт, помеченный как поддерживающий функцию RoR в Android 11, должен включать реализацию HAL RebootEscrow и 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