pta: qcom: ice: add software-key ICE PTA

[Harikrishna (thariaruchamy-bit)]

Summary

Adds a Qualcomm Inline Crypto Engine (ICE) pseudo-TA that lets the Linux
kernel's dm-crypt/inline-crypt path program raw software keys into ICE key
slots for inline storage encryption, and enables it on the QCOM IPQ (bobcat)
platforms.

Two commands are exposed:

• PTA_CMD_ICE_INVALIDATE_KEY — wipe a key slot with random data.
• PTA_CMD_ICE_SET_CONFIG_KEY — program key/salt, cipher mode and data-unit
  size (AES-XTS-128/256, AES-CBC-128/256).

Only the REE kernel may open a session on this PTA (TEE_LOGIN_REE_KERNEL),
since it is driven by the kernel's inline-crypt engine and not by userspace.

Testing

Verified on target: booted to the kernel, confirmed an ICE software-key
configuration request is dispatched from the kernel to this PTA, then wrote
and read back a file on the encrypted filesystem and confirmed the plaintext
and decrypted-data md5sums match.

Tested-on: IPQ52xx, IPQ96xx

[Harikrishna (thariaruchamy-bit)]

Harshal Dev (@harshaldev27), Have resolved the comments, please share if there are any additional comments

[Harikrishna (thariaruchamy-bit)]

Harshal Dev (@harshaldev27) Have resolved the comments, Please share if there are any further ones, if available

[Selvam Sathappan (zelvam95)]

drivers: qcom: add ICE filesystem-encryption PTA with software-key commands
Update commit title + msg to represent the exact change.
Software-key commands seems odd. Can we update the PR Title + Description?

Note: This is a P-TA and not a driver, so it will have different format thats expected. Refer to other existing P-TA's for ref.

[Copilot]

Pull request overview

Adds a Qualcomm Inline Crypto Engine (ICE) pseudo-TA to let the normal-world kernel configure raw software keys for inline storage encryption, and enables the feature on QCOM IPQ (bobcat) platforms by mapping the ICE LUT-keys register window into secure I/O memory.

Changes:

• Introduces a new QCOM ICE PTA (dispatcher + eMMC/SDCC backend) with commands to invalidate a key slot and to program/configure software keys.
• Wires the PTA into the QCOM PTA build and adds controller-/ICE-specific config definitions.
• Enables the PTA for ipq52xx / ipq96xx and defines/maps the SDCC ICE LUT-keys register region for bobcat.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
lib/libutee/include/pta_qcom_ice.h	Adds the client-facing PTA UUID and command IDs for ICE key management.
core/pta/qcom/sub.mk	Hooks the ICE PTA into the QCOM PTA build via a CFG flag.
core/pta/qcom/ice/sub.mk	New PTA subdir makefile, building the generic ICE dispatcher and eMMC backend.
core/pta/qcom/ice/ice.c	Adds the controller-agnostic PTA dispatcher that routes to the eMMC implementation.
core/pta/qcom/ice/emmc/sub.mk	Builds the eMMC/SDCC ICE backend.
core/pta/qcom/ice/emmc/emmc_ice.h	Defines SDCC ICE register addressing/macros and eMMC ICE command prototypes.
core/pta/qcom/ice/emmc/emmc_ice.c	Implements key invalidation and key programming by writing to ICE registers and mapping the LUT-keys region.
core/pta/qcom/ice/config.h	Adds ICE constants and enums (capability indices, data-unit sizes, key layout).
core/arch/arm/plat-qcom/bobcat/ipq96xx/target.mk	Enables the ICE PTA feature flag for ipq96xx builds.
core/arch/arm/plat-qcom/bobcat/ipq52xx/target.mk	Enables the ICE PTA feature flag for ipq52xx builds.
core/arch/arm/plat-qcom/bobcat/arch_config.h	Defines the SDCC ICE LUT-keys register base/size for bobcat.

Suppressed comments (1)

core/pta/qcom/ice/emmc/emmc_ice.c:266

• The slot is disabled, but then immediately re-enabled inside ice_configure_slot() before wiping/programming key registers. This defeats the stated goal of preventing ICE from using stale/intermediate key material during reconfiguration. Configure+enable the slot only after key (and salt) registers have been written.

	/* Disable the slot so ICE can't use stale key data during reconfig */
	ice_reg_write(SDC1_SDCC_ICE_CRYPTOCFG_r_16_ADDR(index), 0, 0, 0x0);

	/* Configure CRYPTOCFG_r_16 (mode/data-unit/enable) before key data */
	ice_configure_slot(index, cap_index, data_unit_size);

	/* Security wipe: overwrite all 16 registers with random data */
	ice_wipe_key_regs(index);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Harshal Dev (harshaldev27)]

I am happy with the overall structure of this PR. I think it can be sent upstream now for further review once other stakeholders are fine as well.

[Harikrishna (thariaruchamy-bit)]

Harshal Dev (@harshaldev27) Have addressed the comment
Sumit Garg (@b49020) Harshal Dev (@harshaldev27) Jorge A. Ramirez-Ortiz (@ldts) Selvam Sathappan (@zelvam95) FYI : Have created a PR in the upstream OPTEE master branch as well
OP-TEE/optee_os#7906

[Sumit Garg (b49020)]

Harikrishna (@thariaruchamy-bit) Harshal Dev (@harshaldev27) due to ABI with the Linux kernel for ICE, please post kernel patch-set upstream as otherwise we can't merge it in OP-TEE in case the kernel ABI changes based on reviews.

[Harikrishna (thariaruchamy-bit)]

Sumit Garg (@b49020) Have fixed the comments, We have enquired the Kernel team on the patches, will update once we get them

[Jorge A. Ramirez-Ortiz (ldts)]

Please do correct me if I am wrong but this software path seems to hand OP-TEE a plaintext key the REE already holds, so it adds no key confidentiality over plain dm-crypt — it's just a transport shim to reach secure-only ICE registers.

If that is so, you should switch to a hardware-wrapped-key (HWKM) design where OP-TEE/hardware generates or unwraps the key inside the secure world and only a wrapped blob ever crosses to the REE — so plaintext key material never exists in Linux.

Please let me know - I can't give my signed-off otherwise as I dont think we should be accepting this change (seems like a serious security issue)

T0nyJH fyi

[Harshal Dev (harshaldev27)]

Please do correct me if I am wrong but this software path seems to hand OP-TEE a plaintext key the REE already holds, so it adds no key confidentiality over plain dm-crypt — it's just a transport shim to reach secure-only ICE registers.

If that is so, you should switch to a hardware-wrapped-key (HWKM) design where OP-TEE/hardware generates or unwraps the key inside the secure world and only a wrapped blob ever crosses to the REE — so plaintext key material never exists in Linux.

Please let me know

T0nyJH fyi

Hi Jorge A. Ramirez-Ortiz (@ldts) , the ICE hardware operates in two modes. Software based plain keys mode and the other which you rightly mentioned HWKM based hardware keys mode where only wrapped blobs are ever exposed to Linux.

Both of these modes are supported on Qualcomm platforms by the ICE hardware and also by the ICE Linux driver. This patch is only for supporting the former, and a subsequent patch is under development by me to support the hardware-based key one. We have customers utilizing both modes with QTEE currently, and hence want to continue maintaining that parity.

With regards to the security aspect of using software based keys, Linux only serves as a mechanism to program these keys into the controller. Once that is done, the keys cannot be read back by any hardware or software entity, quoting this from the programming guide for ICE:

3.7.2 Software encryption keys

The software keys are **write-only** and stored in a RAM inside the ICE. **Hardware is blocked from reading the keys to prevent the keys from being read back by any software entity, whether secure on nonsecure.**

The sentence above is still applicable for ICE 3.2.0 when operating in Legacy mode. In Standard mode key are completely handled and managed by HWKM Slave.

[Harikrishna (thariaruchamy-bit)]

Please do correct me if I am wrong but this software path seems to hand OP-TEE a plaintext key the REE already holds, so it adds no key confidentiality over plain dm-crypt — it's just a transport shim to reach secure-only ICE registers.

If that is so, you should switch to a hardware-wrapped-key (HWKM) design where OP-TEE/hardware generates or unwraps the key inside the secure world and only a wrapped blob ever crosses to the REE — so plaintext key material never exists in Linux.

Please let me know - I can't give my signed-off otherwise as I dont think we should be accepting this change (seems like a serious security issue)

T0nyJH fyi

In addition to Harshal's comments, FYI : We don't have HWKM in IPQ (Bobcat) targets

[Jorge A. Ramirez-Ortiz (ldts)]

With regards to the security aspect of using software based keys, Linux only serves as a mechanism to program these keys into the controller. Once that is done, the keys cannot be read back by any hardware or software entity, quoting this from the programming guide for ICE:

But this is not about software based keys not being secure: it is only this implementation that is not secure - software keys could be generated in the secure world instead: the point is that keys should never be exposed to non-secure.

[Jorge A. Ramirez-Ortiz (ldts)]

In addition to Harshal's comments, FYI : We don't have HWKM in IPQ (Bobcat) targets

and that is ok. Just do not generate plain-text keys in non-secure and then pass them to secure. Can you not generate the keys in the secure world instead?

[Selvam Sathappan (zelvam95)]

In addition to Harshal's comments, FYI : We don't have HWKM in IPQ (Bobcat) targets

and that is ok. Just do not generate plain-text keys in non-secure and then pass them to secure. Can you not generate the keys in the secure world instead?

This design is something that's already supported with QTEE & used across multiple targets that are commercialized Jorge. The Linux kernel upstream already has support for this with QTEE. We're trying to extend same thing with OP-TEE.

We can maybe explore if any additional config where keys are generated in secure world can be added (for more secure use-cases) but its not under the current scope/plan of this PR.

For targets where we have OEM Secure boot + encrypted secure boot etc. enabled, all images are OEM Signed (both OP-TEE/Linux) & they could use this current design if their threat model allows them to. Hope this is acceptable? Let us know if you have any other thoughts on this one;

[Jorge A. Ramirez-Ortiz (ldts)]

This design is something that's already supported with QTEE & used across multiple targets that are commercialized Jorge. The Linux kernel upstream already has support for this with QTEE. We're trying to extend same thing with OP-TEE.

But I do not believe the above to be relevant: it is a plain-text key moving across domains. That cant be right. why do you need the key to be generated in non-secure?

[Selvam Sathappan (zelvam95)]

This design is something that's already supported with QTEE & used across multiple targets that are commercialized Jorge. The Linux kernel upstream already has support for this with QTEE. We're trying to extend same thing with OP-TEE.

But I do not believe the above to be relevant: it is a plain-text key moving across domains. That cant be right. why do you need the key to be generated in non-secure?

What if the non-secure world already has a key and want to use that with ICE H/W?
There are even use-cases like off-device encryption and on-device decryption. For such cases -> non-secure world/user would already have the key.

These ICE IP Registers are access restricted and non-secure world has no option to program the keys directly and the only option is via a call to secure world.

The current PR is for such use-cases^. For HWKM based + HW Key (TMEL) based, we will raise separate PRs incrementally -> In those cases keys will not be exposed to non-secure world & can be used for secure use-cases.

[Harshal Dev (harshaldev27)]

This design is something that's already supported with QTEE & used across multiple targets that are commercialized Jorge. The Linux kernel upstream already has support for this with QTEE. We're trying to extend same thing with OP-TEE.

But I do not believe the above to be relevant: it is a plain-text key moving across domains. That cant be right. why do you need the key to be generated in non-secure?

What if the non-secure world already has a key and want to use that with ICE H/W? There are even use-cases like off-device encryption and on-device decryption. For such cases -> non-secure world/user would already have the key.

+1 we have these kinds of use-cases frequently in the Android world, where the OEM retains control of the key.

The Linux kernel's file system encryption framework also understands this. That's why it provides support for both hardware based wrapped keys and software programmed 'raw' keys, as in this scenario. See: https://elixir.bootlin.com/linux/v7.2-rc3/source/include/linux/blk-crypto.h#L28

It is well known that there exist SoCs which simply do not have hardware wrapped key support, and so this slightly less secure but still useful way of programming known keys into the hardware must be supported. This is reflected in the kernel's framework for hooking different storage controller drivers (UFS/eMMC) which provides call backs for directly programming these 'raw' keys: https://elixir.bootlin.com/linux/v7.2-rc3/source/include/linux/blk-crypto-profile.h#L22
Apart from the (*keyslot_program) and (*keyslot_evict) all the other callbacks are optional, and only relevant when the hardware supports wrapped keys.

The threat model here is actually similar to RPMB key programming, where a plain key is programmed into the storage controller via Linux on the factory floor. The only difference here is that the RPMB key is generated by a TEE, but here we have the key generated by the OEM and Linux again acting as a transport to program the key into the ICE hardware via the TEE.

[Jorge A. Ramirez-Ortiz (ldts)]

ex

This design is something that's already supported with QTEE & used across multiple targets that are commercialized Jorge. The Linux kernel upstream already has support for this with QTEE. We're trying to extend same thing with OP-TEE.

But I do not believe the above to be relevant: it is a plain-text key moving across domains. That cant be right. why do you need the key to be generated in non-secure?

What if the non-secure world already has a key and want to use that with ICE H/W? There are even use-cases like off-device encryption and on-device decryption. For such cases -> non-secure world/user would already have the key.

how does it change the safeness of the situation? you are still delivering a broken security feature and you are asking OP-TEE to take it. I'd say no thanks...

These ICE IP Registers are access restricted and non-secure world has no option to program the keys directly and the only option is via a call to secure world.

if the registers access is restricted to the secure world, it probably is because it expects the key to be generated in secure memory in the secure world. think about it.

[Jorge A. Ramirez-Ortiz (ldts)]

This design is something that's already supported with QTEE & used across multiple targets that are commercialized Jorge. The Linux kernel upstream already has support for this with QTEE. We're trying to extend same thing with OP-TEE.

But I do not believe the above to be relevant: it is a plain-text key moving across domains. That cant be right. why do you need the key to be generated in non-secure?

What if the non-secure world already has a key and want to use that with ICE H/W? There are even use-cases like off-device encryption and on-device decryption. For such cases -> non-secure world/user would already have the key.

+1 we have these kinds of use-cases frequently in the Android world, where the OEM retains control of the key.

I would not like Dell to be able to decrypt my filesystem. I do not see why we need to support such a use case upstream. The encryption key should just be bound to the device.

The Linux kernel's file system encryption framework also understands this. That's why it provides support for both hardware based wrapped keys and software programmed 'raw' keys, as in this scenario. See: https://elixir.bootlin.com/linux/v7.2-rc3/source/include/linux/blk-crypto.h#L28

surely this must be protected memory

It is well known that there exist SoCs which simply do not have hardware wrapped key support, and so this slightly less secure but still useful way of programming known keys into the hardware must be supported. This is reflected in the kernel's framework for hooking different storage controller drivers (UFS/eMMC) which provides call backs for directly programming these 'raw' keys: https://elixir.bootlin.com/linux/v7.2-rc3/source/include/linux/blk-crypto-profile.h#L22 Apart from the (*keyslot_program) and (*keyslot_evict) all the other callbacks are optional, and only relevant when the hardware supports wrapped keys.

why cant the key be generated in the trust zone instead, derived from the HUK like all the other keys?

The threat model here is actually similar to RPMB key programming, where a plain key is programmed into the storage controller via Linux on the factory floor. The only difference here is that the RPMB key is generated by a TEE, but here we have the key generated by the OEM and Linux again acting as a transport to program the key into the ICE hardware via the TEE.

So you are saying this operation only occurs during device provisioning in a secure environment? Well then, why do we need a PTA? the driver can provision the key on first boot via CFG_ no? ie, a CFG_ to OP_TEE carrying the key in plaintext. This configuration - as with RPMB- only gets executed once during first boot.

[Selvam Sathappan (zelvam95)]

This design is something that's already supported with QTEE & used across multiple targets that are commercialized Jorge. The Linux kernel upstream already has support for this with QTEE. We're trying to extend same thing with OP-TEE.

But I do not believe the above to be relevant: it is a plain-text key moving across domains. That cant be right. why do you need the key to be generated in non-secure?

What if the non-secure world already has a key and want to use that with ICE H/W? There are even use-cases like off-device encryption and on-device decryption. For such cases -> non-secure world/user would already have the key.

+1 we have these kinds of use-cases frequently in the Android world, where the OEM retains control of the key.

I would not like Dell to be able to decrypt my filesystem. I do not see why we need to support such a use case upstream. The encryption key should just be bound to the device.

The Linux kernel's file system encryption framework also understands this. That's why it provides support for both hardware based wrapped keys and software programmed 'raw' keys, as in this scenario. See: https://elixir.bootlin.com/linux/v7.2-rc3/source/include/linux/blk-crypto.h#L28

surely this must be protected memory

It is well known that there exist SoCs which simply do not have hardware wrapped key support, and so this slightly less secure but still useful way of programming known keys into the hardware must be supported. This is reflected in the kernel's framework for hooking different storage controller drivers (UFS/eMMC) which provides call backs for directly programming these 'raw' keys: https://elixir.bootlin.com/linux/v7.2-rc3/source/include/linux/blk-crypto-profile.h#L22 Apart from the (*keyslot_program) and (*keyslot_evict) all the other callbacks are optional, and only relevant when the hardware supports wrapped keys.

why cant the key be generated in the trust zone instead, derived from the HUK like all the other keys?

The threat model here is actually similar to RPMB key programming, where a plain key is programmed into the storage controller via Linux on the factory floor. The only difference here is that the RPMB key is generated by a TEE, but here we have the key generated by the OEM and Linux again acting as a transport to program the key into the ICE hardware via the TEE.

So you are saying this operation only occurs during device provisioning in a secure environment? Well then, why do we need a PTA? the driver can provision the key on first boot via CFG_ no? ie, a CFG_ to OP_TEE carrying the key in plaintext. This configuration - as with RPMB- only gets executed once during first boot.

Are we saying if a key is available with non-secure world -> it should never be used by ICE IP/configured via OPTEE due to security reasons? But this was an accepted design upstream in Linux Kernel & we have SCM calls to QTEE in Kernel for doing exactly the same thing.

For secure alternatives we have HWKM based ICE on some archs & TMEL IPC based on some archs like Bobcat which we plan to support incrementally as separate PRs.

Can't we see this as an equivalent of a legacy feature that was supported with QTEE?

[Selvam Sathappan (zelvam95)]

if the registers access is restricted to the secure world, it probably is because it expects the key to be generated in secure memory in the secure world. think about it.

We have both secure world generated keys (via TMEL) & direct SW Keys passed by linux which can be used by the ICE IP. These registers were protected to keep the policy+other things secure in the former case when the keys are generated in secure world. But since its protected, for this later use-case (SW Keys in PT), HLOS cannot directly program them into ICE IP.

surely this must be protected memory

No its not, its clearly captured as plain text/raw keys.

/*

• Supported types of keys. Must be bitflags due to their use in
• blk_crypto_profile::key_types_supported.
  /
  enum blk_crypto_key_type {
  /
  • Raw keys (i.e. "software keys"). These keys are simply kept in raw,
  • plaintext form in kernel memory.
    */
    BLK_CRYPTO_KEY_TYPE_RAW = 0x1,

[Selvam Sathappan (zelvam95)]

Jorge A. Ramirez-Ortiz (@ldts), We can maybe enforce/allow users to enable / use these P-TA commands only when CFG_INSECURE is y? Maybe that way we're telling them this isn't ideal for production environment/isn't recommended?

[Jorge A. Ramirez-Ortiz (ldts)]

if the registers access is restricted to the secure world, it probably is because it expects the key to be generated in secure memory in the secure world. think about it.

We have both secure world generated keys (via TMEL) & direct SW Keys passed by linux which can be used by the ICE IP. These registers were protected to keep the policy+other things secure in the former case when the keys are generated in secure world. But since its protected, for this later use-case (SW Keys in PT), HLOS cannot directly program them into ICE IP.

surely this must be protected memory

No its not, its clearly captured as plain text/raw keys.

I doubt it - at the very least the memory cant be swappable to disk (please check your data)

I do not see why OP-TEE needs this PTA for this use case.

[Jorge A. Ramirez-Ortiz (ldts)]

sharing a plaintext disk-encryption key from Linux to OP-TEE through a non-secure buffer just to program ICE is an insecure design, and I don't agree with merging PR #29 as-is.

[Jorge A. Ramirez-Ortiz (ldts)]

Are we saying if a key is available with non-secure world -> it should never be used by ICE IP/configured via OPTEE due to security reasons? But this was an accepted design upstream in Linux Kernel & we have SCM calls to QTEE in Kernel for doing exactly the same thing.

I dont know the story but if the key is shared in plain-text between worlds via non-secure buffers (ie, this PTA) then the design is bad and it should not be acceptable.

For secure alternatives we have HWKM based ICE on some archs & TMEL IPC based on some archs like Bobcat which we plan to support incrementally as separate PRs.

Can't we see this as an equivalent of a legacy feature that was supported with QTEE?

How do customers write the secure boot hashes? cant just uses the same PTA/timeline to write this key?

[Selvam Sathappan (zelvam95)]

Are we saying if a key is available with non-secure world -> it should never be used by ICE IP/configured via OPTEE due to security reasons? But this was an accepted design upstream in Linux Kernel & we have SCM calls to QTEE in Kernel for doing exactly the same thing.

I dont know the story but if the key is shared in plain-text between worlds via non-secure buffers (ie, this PTA) then the design is bad and it should not be acceptable.

For secure alternatives we have HWKM based ICE on some archs & TMEL IPC based on some archs like Bobcat which we plan to support incrementally as separate PRs.
Can't we see this as an equivalent of a legacy feature that was supported with QTEE?

How do customers write the secure boot hashes? cant just uses the same PTA/timeline to write this key?

Secure boot hashes are written to "OTPs" -> One time programmable registers which cannot be modified again in that SoC. That is a separate flow using sec.elf and that cannot be used to write into SoC MMC IP specific registers.

FYI: The way I see it is -> This is like the "ECB" in crypto which is also an AES Mode but is rarely preferred/used in an environment where security is critical? The QTEE Design is commercialized for a generation of chipsets across archs. It just exists for the completeness & given we already have something with QTEE in Linux upstream, do we want to re-design this for OP-TEE alone now?

Do you have some recommendation to handle this without changing the Linux side Impl? Or would you suggest we have separate Interfaces for OP-TEE & Q-TEE in linux side for this? Currently MMC ICE Kernel side ABIs are pretty much same for all TEEs similar to how it is for PIL (its equivalent) & its handled.

If we have different interface for OP-TEE & Q-TEE, would it be acceptable upstream in Linux?

[Jorge A. Ramirez-Ortiz (ldts)]

Are we saying if a key is available with non-secure world -> it should never be used by ICE IP/configured via OPTEE due to security reasons? But this was an accepted design upstream in Linux Kernel & we have SCM calls to QTEE in Kernel for doing exactly the same thing.

I dont know the story but if the key is shared in plain-text between worlds via non-secure buffers (ie, this PTA) then the design is bad and it should not be acceptable.

For secure alternatives we have HWKM based ICE on some archs & TMEL IPC based on some archs like Bobcat which we plan to support incrementally as separate PRs.
Can't we see this as an equivalent of a legacy feature that was supported with QTEE?

How do customers write the secure boot hashes? cant just uses the same PTA/timeline to write this key?

Secure boot hashes are written to "OTPs" -> One time programmable registers which cannot be modified again in that SoC. That is a separate flow using sec.elf and that cannot be used to write into SoC MMC IP specific registers.

yes secure boot hashes are written to OTPs of course we all know what :).
The question is, where does this happen and under what conditions? what software stack is executing? can we extend it to program this key?

FYI: The way I see it is -> This is like the "ECB" in crypto which is also an AES Mode but is rarely preferred/used in an environment where security is critical? The QTEE Design is commercialized for a generation of chipsets across archs. It just exists for the completeness & given we already have something with QTEE in Linux upstream, do we want to re-design this for OP-TEE alone now?

We are providing customers with an insecure way of configuring disk encryption where as the encryption key is delivered via an unsafe mechanism (non secure buffer) therefore exposing the key in plain text.

The question is, shall this be fixed it on the new firmware stack or not? what is your suggestion as owner of the issue? do you/your teams want to deliver it?

I can only advice against it.

T0nyJH and Jens Wiklander (@jenswikl) I'd appreciate your suggestions.

[Selvam Sathappan (zelvam95)]

The question is, where does this happen and under what conditions? what software stack is executing? can we extend it to program this key?

For fuse blowing -> Ideally, it's done in factory before going to production.
In certain cases, we have also seen certain OEMs provisioning fuses in the field (production) if something is missed/etc..

There are also certain runtime fuses like MRC Activate/Revocate & ARB which are blown in the field when certs are compromised/during version upgrade/etc..

The question is, shall this be fixed it on the new firmware stack or not? what is your suggestion as owner of the issue? do you/your teams want to deliver it?

We support 3 modes/flows in which ICE can be configured. (just to summarize)

1. Raw key passed from HLOS (This PR)
2. HWKM based (can be supported if HWKM IP is present)
3. TMEL IPC based (can be supported TMEL based target)

Usually -> (1) along with (2) or (1) along with (3) are supported in every arch/target. The OEMs prefer and in-general use (2) or (3), but just for completeness and to have the framework, we have added support for (1).

If the recommendation is to have a different impl instead of (1) where we can generate keys in secure world / etc.., it can be done, but it'd require changes in HLOS as well ideally & we'd be differentiating between QTEE & OP-TEE. The question is whether we want to do that or not given we have 2 other modes which are secure as stated above (or) do we just say with OP-TEE we don't support (1) & either (2) / (3) needs to be used?

Open to suggestions. Please share your thoughts / feedback as well. T0nyJH and Jens Wiklander (@jenswikl)

[Selvam Sathappan (zelvam95)]

Harshal Dev (@harshaldev27), If you're aware of more use-cases or background on this plain-text/raw-key passed from HLOS for ICE & why we originally supported it, then please add more context/use-cases/details. If there are any other POCs/Driver Team owners for ICE who'd be aware of this, we could potentially add them as well to get their feedback.

[Harshal Dev (harshaldev27)]

Hi,

Since a lot of discussion here is centered around the threat model of the SW keys design, I wanted to provide a few clarifications based on the Kernel fscrypt framework which actually engages the ICE hardware programming and encryption/decryption: https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#threat-model

1. It is well known that the raw/plain-text key approach to storage encryption implemented by the fscrypt framework has security issues. It is obviously less secure than hardware wrapped keys, and the above documentation lists multiple attacks which cannot be countered by its threat model.
2. There is no point in generating the keys within the TEE or from OEM programmed fuses to program them into ICE. Because when fscrypt does not use the hardware wrapped keys approach, the keys must be explicitly provided to the kernel from user-space, and remain in unprotected kernel memory as part of the Linux keyring.

struct fscrypt_provisioning_key_payload {
        __u32 type;
        __u32 flags;
        __u8 raw[];
};

mkdir /overlay
$ head -c 64 /dev/urandom > /overlay/stdkey
$ identifier=`./fscryptctl add_key /overlay < /overlay/stdkey`

So the threat model explicitly outlines these drawbacks, and advises against using it when hardware wrapped key support is present. However, it is also a fact that if the SoC does not have support for hardware wrapped keys, it is the only way to provide some limited form of protection to the user data storage.

So I believe at this point, it is a debate about whether we want OPTEE to support the raw key approach on hardware where wrapped key support cannot be provided, and allow some limited form of data protection to the users.
I am trying to dig into whether we have customers actively using this approach, my hunch is that users switching over from closed Qualcomm proprietary firmware over to open boot firmware on devices which have already been encrypted using their own raw keys would want to access their storage contents.

But I hope this sets the context right for this discussion.

[Selvam Sathappan (zelvam95)]

T0nyJH and Jens Wiklander (@jenswikl), Can you please share your thoughts on this one?^