TA access to RPMB backed storage about optee_os HOT 4 CLOSED

Hi Paul,

I'm sorry to disappoint you, but what you've seen of RPMB in OP-TEE hasn't been in use for years. Even back then it wasn't available for TA usage (it was primarily intended as anti rollback protection of persistent objects). This code also relies on RPMB support in tee-supplicant which isn't available any longer. The plan was/is that OP-TEE OS communicates with eMMC via tee-supplicant (which would use some RPMB driver etc). We're currently implementing secure storage, encrypted and authenticated (but no anti rollback) protection of persistent objects, that the TAs uses through the "Trusted Storage API" described in "TEE Internal API".

Regards,
Jens

from optee_os.

Thanks for the reply. Is the long term plan to deprecate the existing RPMB functionality out of OpTEE or is it something that would be OK for us to resurrect and potentially plumb through to the storage API for TA's to use? Or, would it fit better with the long term plan to try and refactor the RPMB functionality as part of the secure storage work you're currently working on?
Thanks,
Paul.

from optee_os.

Hi Paul,

The work we are doing related to secure storage is divided in three different steps.

1. Enable encryption/decryption on file basis (this is what you find in the pull request, #231)
2. Block/section based encryption/decryption (will start soon)
3. RPMB

As Jens mentioned the RPMB implementation in OP-TEE has been collecting dust for a couple of years now. But from what I remember back in the days the implementation was starting to take shape. So I think it's a good idea to resurrect the existing implementation. I would imagine that we would start working with RPMB late 2015, however no-one will object if you'd like to start tinker with it already now.

The important thing to consider is how to differentiate between devices having support for RPMB and for devices that haven't got support for it. I.e, we cannot default everything to RPMB. There must be compile time flags etc to decide where calls should end up.

// Regards
Joakim

from optee_os.

Thanks for the reply, we're looking at this and will come back with a design proposal for integrating in RPMB, hopefully leveraging #231.
Paul.

from optee_os.