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

В Android 11, обновление OTA может быть применено с помощью A / B обновления или виртуальных обновлений A / B механизмов, в сочетании с RecoverySystem методов класса. После того, как устройство перезагрузится , чтобы применить обновления OTA, Resume-на-Reboot (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 хранится в тройник.
    • 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-карта удалена или сброшена.
  • Пользователь отключает ПИН-код.
  • Произошла перезагрузка, не инициированная RoR.

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

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

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

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

TelephonyManager

Клиент OTA вызывает TelephonyManager системы API , когда перезагрузка неизбежна в Android 12. Этого API перемещает все кэшированные коды PIN из AVAILABLE состояния в REBOOT_READY состояния. TelephonyManager системы API защищено существующей 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

Эта команда работает только тогда , когда оболочка работает как корень ( adb root ).

Только Android 11

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

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

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

Депонирование RAM по умолчанию

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

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

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

  1. Клиентское приложение OTA загружает обновление.
  2. OTA клиент приложение звонки в RecoverySystem#prepareForUnattendedUpdate который вызывает пользователю будет предложено ввести ПИН - код, шаблон или пароль на экране блокировки во время следующей разблокировки.
  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