-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reading secure object from OPTEE-OS core #6441
Comments
If you need a PTA or not depends on how this is triggered. |
I agree with @jenswi-linaro.
|
@jenswi-linaro @etienne-lms Okay, but how do one verify encryption/decryption of an file that resides in secure storage (at /data/tee, and file has data like "abc" that needed to be verified with encryption/decryption) using vendor specific crypto Engine. Can APIs like "TEE_OpenPersistentObject" be called while OPTEE-OS is still booting (from tee_fs_init_key_manager()) ? [1]: |
IIUC, what you're look for is more or less the tee_pobj layer: tee_pobj.c.
|
@etienne-lms Thanks for the pointers.
Do we have any such example TA's using APIs from tee_svc_storage.c ? Also, is there a way to avoid calling into vendor specific drvcrypt_register_xxx (authenc.c) whenever there is user space CA application (like I mentioned above for optee_example_hello_world or for optee_example_secure_storage) ? |
TAs cannot call functions from TAs never access raw secure storage data, they can only access their own persistent objects, following the TEE Object formalism defined by the GP TEE API specifications. |
Crypto drivers registered in core drvcrypto framework are used for all related crypto operations requested by the core, how ever is the caller. If you want your HW crypto module to be used only for specific crypto operation from specific callers, you should not integrate it in OP-TEE drvcrypt framework. You will need a dedicated PTA with a dedicated interface that clients (non-secure applications and/or secure TAs) will explicitly invoke for those specific operation. |
Okay, got this point but OPTEE core should allow to create secure storage object on own its using APIIs like tee_pobj_create_final, and access these objects to perform encryption/decryption operations on it, right ? If so, it would be really helpful to know which exact API one should use to create secure storage object? |
OP-TEE core could do that, for sure. Up to now, there was not need for such an API. Note that OP-TEE core must ensure it will not create object that could conflict with object created by TAs. Note also that OP-TEE may not be able to reach the secure storage at boot time. For example, when the secure storage is located in a Linux file system ( Maybe can you describe more precisely what is your need so we can discuss the best way to handle it? |
At the moment, I have HW accelerated crypto block registered as drvcrypt using drvcrypt_register_xxx() functions. It does support AES operations, and registers to AE (Authenticated Encryption), and verified it by encrypting/decrypting some data that is defined locally , for instance I have (vendor_aes_engine_huk.c)
Now I would like to verify it using a file that is stored in secure storage or REE file system instead of having this data locally. Can there be TA that would pass file data to crypto_authenc_enc_final() , and that would eventually call into vendor specific HW crypto block or from vendor_aes_engine_huk.c one read REE file system file. Also, looked at core/tee/tee_ta_enc_manager.c where like tee_ta_decrypt_init, can have tee_ta_encrypt_init/decrypt to verify it, but how to trigger these functions ? |
Do you mean you want to get the HUK from the secure storage? If so there is a chicken and egg problem. The keys used to cipher and authenticate data in the secure storage are derived from the HUK. |
No, I wanted to have payload (for encryption/decryption) from secure storage (or file stored in Linux file system) in term of a file. The key to authenticate data is taken by HW Crypto AES engine itself. |
Another query I have, when a secure storage object is created (using a TA say optee_example_secure_storage) , the objecte is in encrypted form, May I know what is code flow that encrypts this object, is it happen here ? https://github.com/ForgeRock/optee-os/blob/master/core/tee/fs_htree.c#L639 |
Yes core/tee/fs_htree.c is where secure storage data are ciphered/signed/verified using AES GCM. Helpful details in Secure storage "hash-tree" section documentation about keys involved in secure storage (SSK, TSK and FEK) and related crypto operations. |
@etienne-lms, I think for cipher process (encryption for FEK) it uses AES ECB mode but for decryption (the entire Image) it uses AES GCM. The image here is the object file that gets created in encrypted form, right ? Also, while running a simple TA (optee_example_secure_storage), control does not enter into following if condition even for once, and wondering how encryption is performed.
https://github.com/ForgeRock/optee-os/blob/master/core/tee/fs_htree.c#L632C2-L634C1 Looking to offload this encryption/decryption to HW based crypto engine block. |
(edited in bold): I meant, yes you are right You can check the key ladder from Secure storage "hash-tree" section documentation. FEK is encrypted/decrypted with AES ECB while the data payload (read from storage/written to storage) is processed (encrypted/signed and decrypted/authenticated) with AES GCM. Note that encrypted FEK is also stored in the secure storage, with some other payload side information (metadata). The metadata are also processed with AES GCM.
Likely because the hash tree was already created before you run optee_example_secure_storage. Try with an fully reset secure storage and run optee_example_secure_storage before any other OP-TEE TA invocation. |
@etienne-lms , Thanks for the answers. Also, in case of Versal, and STM32 platform, the encryption/decryption is completely offloaded to Hardware block instead of doing it through software algorithms ? |
@jenswi-linaro @etienne-lms , can you please look into the latest queries ? |
Hi @Amit-Radur, sorry for the delayed answer. Few new below your pointer is shows the IDs used to distinguish hash tree head blobs (
For Versal, I cannot tell. I guess the answer is yes when For STM32 based on STM32MP13 ( For STM32 based on STM32MP15 (e.g. |
@etienne-lms, Thanks. It helped. What I see, in order to create an encrypted object (using OPTEE secure storage, and encryption/decryption is completely offloaded to Hardware block). Platform must support/implement drvcrypt_register_cipher and drvcrypt_register_authenc, its because HASH tree that manages secure storage using AES ECB (comes from cipher driver), and AES GCM (come from authenc driver). Is this right understanding ? Is there other way to use OPTEE's encrypted file system without going through HASH tree, for instance a platform that has Hardware crypto block that does support AES GCM (for encryption/decryption, there is no AES ECB), and an Image file that is stored in encrypted file system (or may be reading from non secure Linux filesystem) ? Also, from STM32MP13, stm32_cipher_final() is empty() But then how encryption take place for fek ? |
Yes.
The hash tree is there to protect the data stored in OP-TEE secure storage. It is highly recommended to use it. You could implement another mechanism but do that with care and with advise from experts.
That is because everything is done from the update operation, unless I missed something. I think we should even remove the function since it's useless, crypto API don't mandate
|
Thanks @etienne-lms , almost got all my answers to get going on this. The final thing, would like to know what are the other mechanism can be used to secure storage without going hash tree layer |
I know no available solution for OP-TEE REE_FS secure storage not using the hash tree. |
Okay, thanks for clarifying this. Marking it close. |
Would like to read an object file that is stored into secure storage, i.e. at /data/tee from OPTEE-OS core, and then pass it to an crypto engine block registered as drvcrypt_register_xxx, Does it need to have PTA that would call API like TEE_MemMove ?
The text was updated successfully, but these errors were encountered: