Programming RPMB key, or how to avoid CFG_RPMB_WRITE_KEY=y

[jenswi-linaro]

Hi all!

Problems with programing the RPMB key has been discussed recently in
#5323 and OP-TEE/optee_docs#157.

The config variable CFG_RPMB_WRITE_KEY must be set to y for OP-TEE to do this. But there are a few problems with this. From security point of view it may lead to a class break if ever such a signed OP-TEE binary is leaked. Then there's the accidents with writing unusable keys which in worst case may brick the device. Vendors will do well to never use CFG_RPMB_WRITE_KEY=y, but since the option is there it's a risk that it's just too convenient to use.

The best would be if this wasn't done by OP-TEE at all. If secure fuses etc used to derive the RPMB key are known the RPMB key can be calculated offline, possibly with help from a script for the last step. Typically the steps done by huk_subkey_derive() after the HUK has been retrieved with tee_otp_get_hw_unique_key().

With the key calculated independent of OP-TEE we could let U-Boot and/or some user space application in Linux program the key during production. As a safety step to avoid accidents we can add a PTA function to verify that the calculated RPMB key matches OP-TEE's view. Providing such a function should not be a security problem since an eventual attacker just as well could do a brute force on the RPMB itself.

From testing point of view in CI we could add the capability to xtest to write the RPMB key if needed on QEMU. For real hardware I assume that the key will be programmed before it's added to a CI loop.

Thoughts, comments?

Thanks,
Jens

[jforissier]

If secure fuses etc used to derive the RPMB key are known the RPMB key can be calculated offline

This may not always be true. If the device uses a derivation mechanism where the root key cannot leave the chip, then the key can only be generated by software running on the device (and probably only in secure world?). In this case some special firmware would be needed to program the RPMB key no matter what, be it a special build of OP-TEE or something else.

[jenswi-linaro]

OK. I had the impression that even if the root key doesn't leave the chip it would still be known because it was known how the chip was fused during production. But if some firmware randomizes and program this early in the life cycle of the platform then it will truly unknown to the outside.

In that case I guess we'd need a PTA function to extract the RPMB key too. This function should of course be protected with some other config flag and normally not enabled. Perhaps we can have some authentication scheme to make it obvious that it can't be used totally unprotected. I was hoping that we could avoid this.

[etienne-lms]

If secure fuses etc used to derive the RPMB key are known the RPMB key can be calculated offline

This may not always be true.

Agree with @jforissier, leading to "...we'd need...":

In that case I guess we'd need a PTA function to extract the RPMB key too.

That is almost what CFG_RPMB_WRITE_KEY=y does.
Do you think CFG_RPMB_WRITE_KEY is too sensitive to rely upon a config switch?

For real hardware I assume that the key will be programmed before it's added to a CI loop.

I agree.
But Qemu is a bit specific in that, no?

[jenswi-linaro]

If secure fuses etc used to derive the RPMB key are known the RPMB key can be calculated offline

This may not always be true.

Agree with @jforissier, leading to "...we'd need...":

In that case I guess we'd need a PTA function to extract the RPMB key too.

That is almost what CFG_RPMB_WRITE_KEY=y does. Do you think CFG_RPMB_WRITE_KEY is too sensitive to rely upon a config switch?

CFG_RPMB_WRITE_KEY=y is very dangerous to use a on a production platform. With that you can extract the RPMB key without any authentication whatsoever. You'd need to be root or have control over tee-supplicant, but that's as far as security goes.

With a special function to extract the RPMB key it pretty clear that the function is very sensitive and can't be left without some level of authentication. CFG_RPMB_WRITE_KEY=y just works and there's a risk that it's overlooked when securing the system. As I said above, it can lead to a class breach of security.

For real hardware I assume that the key will be programmed before it's added to a CI loop.

I agree. But Qemu is a bit specific in that, no?

Yes, but we could implement the secure world part in a secure way so serve as an example or at least to highlight a problem.

[ldts]

What I like about this proposal is that OP-TEE could return the key qualified: ie this is a development RPMB key vs this is a production RPMB key, and then let the user implement the policy.

For instance, if the system is booting non-secure (ie, firmware signatures not being hw verified) the system might choose to still write the RPMB key. Under those circumstances it doesnt really matter if the key leaks, after all, the system hasnt been secured.

If the system is booting secure - firmware running signatures validated - asking for the key cant not lead to a leak unless the signed firmware willingly leaks it.

(I do realize that there are corner cases - ie if the board doesnt implement a HW root-of-trust)...but those boards are not really secure in any case.

So if it counts for anything, I am in favour of this functionality being added to OP-TEE.

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

[ldts]

@jenswi-linaro I was thinking about this a bit more.

Since the HUK is the only variable that is affecting the RPMB key calculation - all other inputs to the HUK are pretty much fixed for the platform - perhaps we should just declare the HUK as an unique_id + property with the property being secure (ie, persistent) or non-secure.

And then force the user to be explicit about letting the non-secure HUK be used for the RPMB key generation - never allow it by default.

[jenswi-linaro]

@jenswi-linaro I was thinking about this a bit more.

Since the HUK is the only variable that is affecting the RPMB key calculation - all other inputs to the HUK are pretty much fixed for the platform - perhaps we should just declare the HUK as an unique_id + property
with the property being secure (ie, persistent) or non-secure.

And then force the user to be explicit about letting the non-secure HUK be used for the RPMB key generation - never allow it by default.

I'm sorry, I don't get it. We have the implementation of huk_subkey_derive() which basically MACs a usage enum plus some data using the HUK as key to the MAC. We depend on the HUK being secure. Where does non-secure come into this?