18
Enabling AOSP FBE with OP-TEE Keymaster Victor Chong - Linaro Security Working Group

Enabling AOSP FBE with OP-TEE Keymaster · 2019. 9. 26. · Boot flow without File-Based Encryption (FBE) - Bootloader firmware boots - Linux boots - OP-TEE keymaster (KM) service

  • Upload
    others

  • View
    11

  • Download
    0

Embed Size (px)

Citation preview

  • Enabling AOSP FBE with OP-TEE KeymasterVictor Chong - Linaro Security Working Group

  • Agenda● Problem description

    ○ Boot flow without File-Based Encryption (FBE)○ Boot flow with FBE○ Boot flow with FBE - OP-TEE KM + SW KM○ 2nd (!) boot with FBE - OP-TEE KM + SW KM

    ● Remedies○ Non-standard partition○ RPMB○ Start tee-supplicant and OP-TEE KM services earlier○ Boot flow with FBE

  • Boot flow without File-Based Encryption (FBE)- Bootloader firmware boots- Linux boots- OP-TEE keymaster (KM) service starts- Volume daemon (vold) starts -- vold prepares /data/vendor (nonencrypted)

    - tee-supplicant service starts- OP-TEE KM CA ‘connects’ to TA (via optee_os) -- optee_os loads KM TA -- OP-TEE KM TA creates secret key -- Secret key stored in /data/vendor/tee (secure store)

    - Boot completes

    NOTE: Boot flow simplified for easier understanding

  • Boot flow with FBE- Bootloader firmware boots- Linux boots- OP-TEE KM service starts- vold starts -- vold calls KM services (APIs) to generate crypto keys

    - tee-supplicant service starts- OP-TEE KM CA ‘connects’ to TA (via optee_os) -- optee_os loads KM TA -- OP-TEE KM TA creates secret key -- Secret key stored in /data/vendor/tee → /data/vendor NOT prepared

    -- vold prepares /data/vendor (encrypted)- Boot hangs

  • Boot flow with FBE - OP-TEE KM + SW KMOP-TEE KM coexist with default software keymaster (SW KM)- Bootloader firmware boots- Linux boots- SW KM and OP-TEE KM services starts- vold starts -- vold calls KM services (APIs) to generate crypto keys

    - SW KM service generates keys for vold -- vold prepares /data/vendor (encrypted)

    - tee-supplicant service starts- OP-TEE KM CA ‘connects’ to TA (via optee_os) -- optee_os loads KM TA -- OP-TEE KM TA creates secret key -- Secret key stored in /data/vendor/tee (secure store)

    - Boot completes

  • But..

  • 2nd (!) boot with FBE - OP-TEE KM + SW KM- Bootloader firmware boots- Linux boots- SW KM service starts- OP-TEE KM service starts (priority over SW KM)- vold starts -- vold knows crypto keys (path) exist so no need to generate -- vold prepares /data/vendor (encrypted)

    - tee-supplicant service starts- OP-TEE KM CA ‘connects’ to TA (via optee_os) -- optee_os loads KM TA -- OP-TEE KM TA creates secret key -- Secret key stored in /data/vendor/tee (secure store)

    -- vold calls KM services (APIs) using existing keys -- OP-TEE KM processes keys created on 1st boot using SW KM -- Key size mismatch!

    - Boot hangs

  • Agenda● Problem description

    ○ Boot flow without File-Based Encryption (FBE)○ Boot flow with FBE○ Boot flow with FBE - OP-TEE KM + SW KM○ 2nd (!) boot with FBE - OP-TEE KM + SW KM

    ● Remedies○ Non-standard partition○ RPMB○ Start tee-supplicant and OP-TEE KM services earlier○ Boot flow with FBE

  • Remedies- Avoid having both OP-TEE and SW KMs coexisting on the same device

    - Keystore supports one KM 3.0 instance- Move secure storage out of /data

    - Use non-standard or RPMB partition- Add appropriate SELinux rules

    - Start tee-supplicant and OP-TEE KM services earlier- post-fs-data and late-fs --> post-fs

  • Non-standard partitionHikey partitions

    https://github.com/96boards-hikey/l-loader/blob/testing/hikey960_v1.2/generate_ptable.sh- fastboot- nvme- boot- vendor- cache- system- userdata

    https://github.com/96boards-hikey/l-loader/blob/testing/hikey960_v1.2/generate_ptable.shhttps://github.com/96boards-hikey/l-loader/blob/testing/hikey960_v1.2/generate_ptable.sh

  • Non-standard partitiondevice/linaro/hikey

    --- a/hikey/fstab.hikey+++ b/hikey/fstab.hikey+/dev/block/platform/soc/f723d000.dwmmc0/by-name/nvme /persist ext4 discard,noatime,noauto_da_alloc,nosuid,nodev,data=ordered,user_xattr,barrier=1 wait,formattable

    optee_client--- a/Android.mk+++ b/Android.mk-TEEC_TEST_LOAD_PATH ?= /data/vendor/tee-CFG_TEE_FS_PARENT_PATH ?= /data/vendor/tee+TEEC_TEST_LOAD_PATH ?= /persist/tee+CFG_TEE_FS_PARENT_PATH ?= /persist/tee

  • RPMBoptee_os- Set CFG_RPMB_FS=y and CFG_REE_FS=n (optional, recommended)- CFG_RPMB_FS_DEV_ID in mk/config.mk must match /dev/mmcblkrpmb- RPMB key used must match that programmed into the device, if not programmed by optee_os

    optee_client- Set RPMB_EMU=0

  • RPMBLinux- Make sure driver works -- Test with mmc-utils- Program key into RPMB device -- Use mmc-utils -- Proceed with caution! Lost key = unusable RPMB partition

    NOTE- Get RPMB to work first before enabling FBE

  • Anatomy of the Android Init LanguageStages of the init process. Order of execution by row. List is NOT exhaustive.

    system init.rc vendor init.rc

    early-init early-init

    init init

    late-init late-init

    early-fs early-fs

    fs fs

    post-fs post-fs

    late-fs late-fs

    post-fs-data post-fs-data

    early-boot early-boot

    boot boot

  • Start tee-supplicant and OP-TEE KM services earliersystem init.rc (before) vendor init.rc (before)

    post-fs post-fs

    late-fs start KM

    late-fs

    post-fs-data start vold

    post-fs-data start tee-supplicant

    system init.rc (after) vendor init.rc (after)

    post-fs post-fs start tee-supplicant start OP-TEE KM

    late-fs late-fs wait_for_keymaster (blocking)

    post-fs-data start vold

    post-fs-data

  • init.rcdevice/linaro/hikey/init.common.rc

    on post-fs chown system system /persist chmod 0771 /persist restorecon /persist mkdir /persist/tee 0770 shell shell restorecon_recursive /persist/tee

    start tee-supplicant start vendor.keymaster-3-0-optee

    on late-fsexec_start wait_for_keymaster_optee

  • Boot flow with FBE- Bootloader firmware boots- Linux boots- OP-TEE KM and tee-supplicant services start- vold starts -- vold calls KM services (APIs) to generate crypto keys

    - OP-TEE KM CA ‘connects’ to TA (via optee_os) -- optee_os loads KM TA -- OP-TEE KM TA creates secret key -- Secret key stored in /persist/tee or RPMB partition -- OP-TEE KM generates keys for vold- wait_for_keymaster completes

    -- vold prepares /data/vendor (encrypted) → don’t care- Boot completes

  • Thank youJoin Linaro to accelerate deployment of your Arm-based solutions through collaboration

    [email protected]

    mailto:[email protected]