OP-TEE key

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OP-TEE key

Jump to solution
1,958 Views
antonio_santagi
Contributor IV

Hello,

I am using Yocto BSP for iMX8M mini. Not sure if this is the right place where to ask this question, in case not please let me know.

At https://source.codeaurora.org/external/imx/imx-optee-os/tree/documentation/porting_guidelines.md?h=i... 

I can read that 

 

## 9. Trusted Application private/public keypair
By default all Trusted Applications (TA's) are signed with the pre-generated
2048-bit RSA development key (private key). This key is located in the `keys`
folder (in the root of optee_os.git) and is named `default_ta.pem`. This key
**must** be replaced with your own key and you should **never ever** check-in
this private key in the source code tree when in use in a real product.  

and also at : 

https://optee.readthedocs.io/en/latest/building/trusted_applications.html#signing-of-tas 

Warning

"optee_os comes with a default private key in its source to facilitate easy development, testing, debugging and QA. Never deploy an optee_os binary with this key in production. Instead replace this key as soon as possible with a public key and keep the private part of the key offline, preferably on an HSM."

 

Right, then I generated a new keypair and extracted the public key. 

I have then put the extracted public key in the keys folder renaming it to default_ta.pem, overwriting the original default_ta.pem.

This means that there is only a public key now in default_ta.pem.

Now, optee-os-imx builds correctly but optee-test-imx raises error, this is understandable because it's a trusted app and therefore it needs the private key to be signed with.

So, my question is, if I replace the default_ta.pem with another KEYPAIR .pem file that I generated, is this secure ? optee-os-imx and optee-test-imx will build correctly but does the private key part of the key pair gets stripped from the optee-os binary file ? or does the default_ta.pem keypair gets embedded completely in the image ?

In this last case this would clash a bit with the instructions that suggest to not put any private key in the sources being built.

Can you point to the script that handles this part ?

thank you!

 

 

0 Kudos
1 Solution
1,940 Views
antonio_santagi
Contributor IV

Yes, that's correct @IvanRuiz .

Only problem is that we build also imx-optee-test recipe and this requires optee-os and it tries to get the private key from the optee-os build folder. 

Anyway now I found that the private key is stripped out from the keypair before embedding into the tee image, it's done by this script : 

pem_to_pub_c.py

it generates a c file with information only about the public key extracted from the keypair.

that is what goes then in the tee.bin file.

We anyway will not commit the private key to the repository with the sources, as per your documentation. 

View solution in original post

0 Kudos
2 Replies
1,941 Views
antonio_santagi
Contributor IV

Yes, that's correct @IvanRuiz .

Only problem is that we build also imx-optee-test recipe and this requires optee-os and it tries to get the private key from the optee-os build folder. 

Anyway now I found that the private key is stripped out from the keypair before embedding into the tee image, it's done by this script : 

pem_to_pub_c.py

it generates a c file with information only about the public key extracted from the keypair.

that is what goes then in the tee.bin file.

We anyway will not commit the private key to the repository with the sources, as per your documentation. 

0 Kudos
1,950 Views
IvanRuiz
NXP Employee
NXP Employee

Hello,

 

For security reasons it is not recommended to keep any private keys in keys/default_ta.pem and the recommendation according to documentation is to use the generated public key only since that will only be used for the encryption and the private key shall be stored preferably in an HSM. The TAs are signed using the sign_encrypt.py from OP-TEE as mentioned in the documentation.

 

Hope it helps!

 

BR,

Ivan.