+
+- Typically implemented as TrustZone on ARM processors
+- Hardware-enforced isolated environment
+- Provides trusted execution environment for confidential operations
+- REE (Android OS) is considered unstrusted
+- Small TEE OS separated from the main OS
+- Trusted Apps provide critical security services
+
+
+
+
+
+---
+
+# Trusty
+
+- Trusty - open-source implementation of secure Operating System providing TEE
+for Android (Pixel devices)
+- Other vendors typically have their own secure OSes provided as binary blobs
+- Goal: provide reliable and free TEE alternative for hardware vendors
+ - Improve transparency, reduce fragmentation of the ecosystem, simplify
+ trusted apps development
+- Uses Google TEE API - **not compliant** to the Global Platform TEE API
+
+
+
+
+
+---
+layout: two-cols-header
+---
+
+# TEE usage in Android
+
+::right::
+
+
+
+::left::
+
+- Lock screen passcode verification
+ - unless a more secure environment is present (like Titan M on Pixel)
+- Biometrics
+ - fingerprint template matching and Face Unlock
+- KeyStore
+ - key protection and management
+- Protected Confirmation
+ - hardware-protected Trusted UI for high-assurance transactions
+- DRM
+ - apps can manage DRM-protected content
+
+
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+theme: ../slidev-template/theme
+---
+
+# Android Verified Boot (AVB)
+
+---
+
+# Boot process
+
+
+
+- BL1 - Primary Boot Loader (PBL), BootROM, provides RoT
+- BL2 - Secondary Boot Loader (SBL) (e.g. TF-A)
+ - sets up Secure and Non-Secure Worlds, defines memory isolation boundaries
+- BL31 - Secure Monitor (e.g. implementation from TF-A)
+- BL32 - Secure Payload / TEE OS (e.g. OP-TEE, Trusty, QSEE Qualcomm, TEEGRIS Samsung)
+- BL33 - Non-Secure Firmware / OS Bootloader (e.g. U-Boot, Little Kernel, EDK2)
+
+
+
+---
+
+# RoT Requirements
+
+Verified Boot is a feature that guarantees the integrity of the device
+software. If device implementations support the feature, they:
+
+- [C-1-1] MUST declare the platform feature flag android.software.verified_boot.
+- [C-1-2] MUST perform verification on every boot sequence.
+- [C-1-3] MUST start verification from an immutable hardware key that is the
+root of trust and go all the way up to the system partition.
+- Full list of requirements for Device Integrity
+ - https://source.android.com/docs/compatibility/16/android-16-cdd#910_device_integrity
+- Android Compatibility program
+ - https://source.android.com/docs/compatibility/overview
+- Compatibility Test Suite - some requirements covered as tests
+ - https://source.android.com/docs/compatibility/cts
+
+
+
+---
+
+# RoT example
+
+Xiaomi
+
+
+
+- BootROM uses public key stored in FUSE space inside of the main SoC
+- The `Level I Bootloader` will run after successful verification
+
+
+
+---
+
+# RoT example
+
+Qualcomm
+
+
+
+
+
+- `PBL` is in BootROM and verifies images that it loads
+- The `XBL_SEC` image acts as a RoT for all TrustZone images (Qualcomm TEE in particular)
+- The `XBL` image acts as a RoT for all non-TrustZone images (OS loader, OS kernel), etc.
+- The Root CA certificate \[...\] is either stored in QTI’s QFPROM eFuses or in the hardware ROM code
+
+
+
+---
+
+# RoT example
+
+Google Pixel - Titan M
+
+
+
+- RoT provided by an external security chip (Google Titan M / M2)
+
+
+
+---
+
+# Verified Boot
+
+- Main goal
+ - to ensure all executed code comes from a trusted source
+ - establishes a full chain of trust, starting from a hardware-protected RoT
+ - each stage verifies the integrity of the next stage before handing over
+ execution
+- In addition: checks for the correct version of Android with rollback
+ - it helps to prevent a possible exploit from becoming persistent
+ - by ensuring devices only update to newer Android versions
+- In addition: communicate verification state the user
+
+
+
+---
+
+# dm-verity
+
+- Device Mapper (DM) is a Linux kernel component for managing logical volumes
+ - allows mapping physical block devices, to create virtual block devices
+- In short: it is used to verify the integrity of system/data partitions
+
+
+
+
+
+
+
+---
+
+# User-settable root of trust
+
+- Optional feature designed in the Verified Boot flow
+- Implemented on Google Pixel devices
+- Key stored in virtual partition: `avb_custom_key`
+- Allows for custom OS deployments
+ - Signed by key trusted by end-user
+- Used by the [Graphene OS during installation](https://grapheneos.org/install/web#replacing-grapheneos-with-the-stock-os)
+
+
+
+---
+
+# Verified Boot states
+
+Possible boot states:
+- no issues - boot normally with no information to the user
+- YELLOW: Warning screen for LOCKED devices with custom root of trust set
+- ORANGE: Warning screen for UNLOCKED devices
+- RED (eio): Warning screen for dm-verity corruption
+- RED (no os found): No valid OS found
+
+Communicated to the OS via
+[bootconfig](https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig)
+
+
+
+---
+layout: two-cols-header
+---
+
+# LOCKED devices with custom root of trust
+
+::left::
+
+
+
+::right::
+
+- YELLOW screen on every boot
+- Continues booting automatically after 10s
+- User can pause it to compare OS fingerprint
+
+
+
+---
+layout: two-cols-header
+---
+
+# UNLOCKED devices
+
+::left::
+
+
+
+::right::
+
+- ORANGE screen
+- Continues booting automatically after 10s
+- Bootloader is unlocked - software integrity is not guaranteed
+
+
+
+---
+layout: two-cols-header
+---
+
+# dm-verity corruption
+
+::left::
+
+
+
+::right::
+
+- RED screen
+- dm-verity verification failed
+- Powers off automatically after 30s
+- User can bypass this and continue
+
+
+
+---
+
+# Generic Bootloader (GBL)
+
+- UEFI app (dynamic allocations use UEFI)
+- Supports x86 / arm64 / riscv64 architectures
+- Available as a part of AOSP (fully opensourced)
+- Standardized, updatable bootloader to streamline the Android boot process
+- Aims to replace fragmented landscape of vendor-specific bootloaders
+- GBL contains:
+ - core Android boot logic
+ - Fastboot
+ - Vendor extensions
+ - UEFI protocol handlers
+ - Android Specific UEFI Protocol definitions
+- **Strongly recommended** for arm64 since Android 16, may become mandatory in the
+future
+
+
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+theme: ../slidev-template/theme
+---
+
+# Encryption
+
+---
+layout: two-cols-header
+---
+
+# Encryption
+
+All user data on Android device is encrypted using symmetric encryption keys
+
+::left::
+
+
+
+
+```mermaid
+sequenceDiagram
+ participant App as Application
+ participant Encryption as Encryption Layer
+ participant Disk as Disk Storage
+
+ App->>+Encryption: write(userData)
+ Note over Encryption: Automatically encrypts with symmetric key
+ Encryption->>+Disk: write(encryptedData)
+ Disk-->>-Encryption: success
+ Encryption-->>-App: success
+
+ Note over App,Disk: 🔒 Data encrypted before committing to disk
+```
+
+
+
+
+::right::
+
+
+
+
+```mermaid
+sequenceDiagram
+ participant App as Application
+ participant Encryption as Encryption Layer
+ participant Disk as Disk Storage
+
+ App->>+Encryption: read()
+ Encryption->>+Disk: read()
+ Disk-->>-Encryption: encryptedData
+ Note over Encryption: Automatically decrypts with symmetric key
+ Encryption-->>-App: userData (decrypted)
+
+ Note over App,Disk: 🔒 Data decrypted before returning to app
+```
+
+
+
+
+
+
+---
+
+# Encryption
+
+
+
+
+
+---
+
+# Storage locations
+
+Apps can use two kinds of storage locations with FBE
+
+