В 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 разблокировано, и устройство разблокировано пользователем после получения беспроводного обновления. Защита от внутренних атак должна быть эффективной, даже если злоумышленник получит доступ к транслируемым криптографическим ключам подписи.
В частности, данные хранилища CE не должны читаться злоумышленником, физически владеющим устройством и имеющим следующие возможности и ограничения:
Возможности
- Можно использовать ключ подписи любого поставщика или компании для подписи произвольных сообщений.
- Может привести к получению устройством обновления OTA.
- Может изменять работу любого оборудования (например, процессора приложений или флэш-памяти) — за исключением случаев, подробно описанных в разделе «Ограничения» ниже. (Однако такое изменение подразумевает как задержку продолжительностью не менее одного часа, так и выключение питания, которое уничтожает содержимое оперативной памяти.)
Ограничения
- Невозможно изменить работу оборудования, защищенного от взлома (например, Titan M).
- Невозможно прочитать ОЗУ работающего устройства.
- Невозможно угадать учетные данные пользователя (PIN-код, графический ключ, пароль) или иным образом заставить его ввести их.
Решение
Система обновления RoR в Android 12 обеспечивает защиту от самых изощрённых злоумышленников, при этом пароли и PIN-коды остаются на устройстве — они никогда не отправляются на серверы Google и не хранятся там. Ниже представлен обзор процесса, обеспечивающего уровни безопасности, аналогичные аппаратной системе RoR на уровне устройства:
- Android применяет криптографическую защиту к данным, хранящимся на устройстве.
- Все данные защищены ключами, хранящимися в доверенной среде выполнения (TEE).
- TEE выдает ключи только в том случае, если работающая операционная система проходит криптографическую аутентификацию ( проверенную загрузку ).
- Служба RoR, работающая на серверах Google, защищает данные CE, сохраняя секретный код, доступ к которому ограничен . Это работает во всей экосистеме Android.
- Для разблокировки устройства и расшифровки хранилища CE используется криптографический ключ, защищенный PIN-кодом пользователя.
- Когда запланирована ночная перезагрузка, Android предлагает пользователю ввести PIN-код, а затем вычисляет синтетический пароль (SP).
- Затем он дважды шифрует 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отбрасываются.
-
Обновления, обеспечивающие безопасность вашего телефона, могут происходить в удобное для вас время: пока вы спите.
Повтор 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-обновлений. Необходимые обновления можно устанавливать во время удобного простоя устройства, например, в определённые часы сна.
Чтобы беспроводные обновления в такие периоды не мешали пользователям, используйте тёмный режим для снижения уровня светового излучения. Для этого загрузчик устройства должен выполнить поиск строки с параметром 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 поддерживает защищенный аппаратный анклав (отдельный сопроцессор безопасности с собственной ОЗУ и ПЗУ), дополнительно оно должно выполнять следующие действия:
- Уметь обнаруживать перезагрузку основного ЦП.
- Наличие аппаратного таймера, сохраняющегося при перезагрузках. То есть анклав должен иметь возможность обнаружить перезагрузку и завершить отсчёт таймера, установленного перед перезагрузкой.
- Поддержка хранения депонированного ключа в ОЗУ/ПЗУ анклава таким образом, чтобы его невозможно было восстановить с помощью офлайн-атак. Ключ RoR должен храниться таким образом, чтобы инсайдеры или злоумышленники не могли его восстановить.
Депонирование оперативной памяти по умолчанию
В AOSP реализована реализация RoR HAL с использованием персистентности ОЗУ. Для этого OEM-производители должны обеспечить поддержку персистентности ОЗУ в своих SoC. Некоторые SoC не способны сохранять содержимое ОЗУ после перезагрузки, поэтому 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, должен включать реализацию 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