В Android 11 обновления OTA могут применяться с использованием механизмов обновления A/B или виртуального обновления A/B в сочетании с методами класса RecoverySystem . После перезагрузки устройства для применения обновления OTA Resume-on-Reboot (RoR) разблокирует хранилище Credential Encrypted (CE) устройства.
Хотя партнеры могут связать этот процесс с функцией системы OTA, которая применяет обновления, когда устройство, как ожидается, будет простаивать в Android 11, в 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 предоставила пользователям лучший опыт до того, как после загрузки потребовалось ввести Lock Screen Knowledge Factor (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).
- Затем он дважды шифрует SP: один раз с помощью ключа
K_sхранящегося в ОЗУ, и еще раз с помощью ключаK_kхранящегося в TEE. - Двойной шифрованный SP хранится на диске, а SP стирается из RAM. Оба ключа генерируются заново и используются только для одной перезагрузки .
- Когда приходит время перезагрузки, 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-карта извлечена или сброшена.
- Пользователь отключает ПИН-код.
- Произошла перезагрузка, не инициированная 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 делятся на две категории:
- Если аппаратное обеспечение SoC поддерживает сохранение ОЗУ при перезагрузках, OEM-производители могут использовать реализацию по умолчанию в AOSP ( Default RAM Escrow ).
- Если аппаратное обеспечение устройства или SoC поддерживает защищенный аппаратный анклав (отдельный сопроцессор безопасности с собственной ОЗУ и ПЗУ), дополнительно необходимо выполнить следующие действия:
- Уметь обнаруживать перезагрузку основного ЦП.
- Иметь источник аппаратного таймера, который сохраняется при перезагрузках. То есть, анклав должен иметь возможность обнаружить перезагрузку и завершить таймер, установленный перед перезагрузкой.
- Поддержка хранения депонированного ключа в RAM/ROM анклава, чтобы его нельзя было восстановить с помощью офлайн-атак. Он должен хранить ключ RoR таким образом, чтобы инсайдеры или злоумышленники не могли его восстановить.
Депонирование оперативной памяти по умолчанию
AOSP имеет реализацию RoR HAL с использованием сохранения RAM. Чтобы это работало, OEM-производители должны гарантировать, что их SoC поддерживают сохранение RAM при перезагрузках. Некоторые SoC не могут сохранять содержимое RAM при перезагрузке, поэтому OEM-производителям рекомендуется проконсультироваться со своими партнерами SoC перед включением этого HAL по умолчанию. Каноническая ссылка для этого в следующем разделе.
Поток обновления OTA с использованием RoR
Клиентское приложение OTA на телефоне должно иметь разрешения Manifest.permission.REBOOT и Manifest.permission.RECOVERY для вызова необходимых методов для реализации RoR. При наличии этого предварительного условия поток обновления следует следующим шагам:
- Клиентское приложение OTA загружает обновление.
- Клиентское приложение OTA вызывает
RecoverySystem#prepareForUnattendedUpdate, что запускает запрос на ввод пользователем PIN-кода, графического ключа или пароля на экране блокировки при следующей разблокировке. - Пользователь разблокирует устройство на экране блокировки, и устройство готово к установке обновления.
- Клиентское приложение 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