DEK blob fail due OP-TEE capabilities mismatch

[Dominique1]

Hello,

I have follow the documents AN4581/AN12056 try to build an encrypted and signed u-boot image for imx8mq chipset.

I rebuild uboot with correct config :

CONFIG_SECURE_BOOT=y

CONFIGURE_FAT_WRITE=y

CONFIGURE_CMD_DEKBLOB=y

CONFIG_IMX_OPTEE_DEKBLOB_ENCAP=Y

CONFIG_CMD_PRIBLOB=Y

I have also recompile ATF (with SPD=opteed) and OP-TEE (with CFG_NXPCRYPT=Y and CFG_GEN_DEK_BLOB=y)

I follow all the steps and when i try to generate the DEK blob on the target with this cmd :

dek_blob 0x40400000 0x40401000 128

I have error message "Cannot get OP-TEE device" .

With more log, I can see the reason is OP-TEE capabilities mismatch, and OP-TEE Dynamics seems to not support "Dynamic share memory". But the OP-TEE config.mk file is configured with  CFY_DYN_SHM_CAP=y (dynamic share memory is enable).

So i don't understand why DEK blob generation is falling and I have no idea how to fix it.

One remark, there is no fuse done on the chipset. I don't know if it is required to generate the dek_blob.

Thanks for your help

Dominique

[Dominique1]

Hi,

Now we are trying to secure a box. The chipset is still the same,iMX8MQ. 

We want to do it in the linux application, not in uboot.

So we have added the config CONFIG_FSL_OTP=y in the kernel config.

As describe in the document iMX_Howto_Program_Fuses.pdf (revision B 2020-03-18), we can list and read the registers as follow :

ls /sys/fsl_otp/

cat /sys/fsl_otp/HW_OCOTP_SRK0

...

But the "fuse" operation does not work even if there is no error message return. But after reboot i can see the value has not been written.

As describe in the document, the cmd we use to fuse register SRK0 (value 0x11111111 is an example) is:

echo 0x11111111 > /sys/fsl_otp/HW_OCOTP_SRK0

Do you have an idea of the issue ?

Best regards,

Dominique

[Dominique1]

Hello Igor,

Sorry, i didn't see your answer before i posted others questions on my story.

So ok, it is clear now that device must be closed before to use dek_blob generation. So not simple to use as we need after to insert the dek_blob in final image that we have to flash.

Regarding my others questions on my story, they are valid :

-OP-TEE does not compile due to SECMEM_BASE not defined for iMX8mq device. ! We are using OP-TEE branch imx_4.19.35_1.1.0 commit 6a22e6e8 (to be align with kernel version). The version with commit id 25fee73 you mention is for branch imx_5.4.24_2.1.0 (not for OP-TEE master branch).  I have set the define to 0x100000 but not sure it is correct.

-Even with device closed, i have still issue with dec_blob command (OP-TEE device not found du to capabilities mismatch) ! So is it supported in branch imx_4.19.35_1.1.0 ?

-How to encrypt an additional image like a linux application (there is detail about how to sign an additional  application, but not to encrypt).

-How to encrypt a bloc of data called blob (I can see some information in chapter 8.10.6.5 but no uboot cmd or API to do that).

Best regards,

Dominique

[igorpadykov]

Hi Dominique

I checked internally and got answers on your others questions :

--------------

For the #1 and #2 questions, the OPTEE 4.19.35_1.1.0 links to the 3.2.0 version, and merged into the 3.2.0 version. You can port to imx_3.2.y branch and do the encrypted boot based on the link:https://community.nxp.com/t5/Security-Blog-NXP-Internal/HABv4-encrypted-boot-in-i-MX8M-family-device...

For the #3 question, we don't have method to encrypt an additional image like a linux application. We have method to encrypt disk by dm-crypt. Link is:https://www.nxp.com.cn/docs/en/application-note/AN12714.pdf

For the #4 question, you can refer to AN12554:https://www.nxp.com/docs/en/application-note/AN12554.pdf

--------------

Best regards
igor

[igorpadykov]

Hi Dominique

regarding that there is no fuse done on the chipset,

for dek_blob generation, the chip must have been closed, so necessary to close the device as described on

link:https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4?h=imx_v2019.04_5.4.3_2.0.0.

AN12056 is suitable for i.MX6 and i.MX7. For i.MX8 I sent additional info by mail.

Best regards
igor

[Dominique1]

Hello Igor,

Thanks for your answer.

For OP-TEE version, you mention OPTEE 4.19.35_1.1.0 is link to the version 3.2.0 version and merged into the 3.2.0 version.
I don't find this version (which branch and commit id) on the git :
https://source.codeaurora.org/external/imx/imx-optee-os/refs/heads?h=OP-TEE/coverity_scan
Also the link you gave "imx_3.2.y" is failing.
And i have not enough privilege for access to :https://community.nxp.com/t5/Security-Blog-NXP-Internal/HABv4-encrypted-boot-in-i-MX8M-family-device...
But i guess it is a document explaining how to encrypt. I have the AN12056 which explain how to encrypt boot on HABv4, so should be enough.

Does version 3.2.0 means the branch imx_v2019.04_5.4.3_2.0.0. (and last commit is

b32a9b6b9fa474359464ca70e62b796a45e16e36)

?

Best regards

Dominique

[Dominique1]

Hi Igor,

And additional question, my understanding is we should also align other packages to same version :

-ATF, op-tee client and op-tee test, mkimage

-uboot

-kernel

Do you confirm ?

Thanks

Dominique

[igorpadykov]

Hi Dominique

you are right, all versions should be aligned.

Best regards
igor

[igorpadykov]

Hi Dominique

you are right, all versions should be aligned.

Best regards
igor

[Dominique1]

Hi Igor,

OK thanks. 

And regarding the version 3.2.0 you mention (imx_3.2.y), is it the branch imx_5.4.3_2.0.0 ?

(latest commit)

BR,

Dominique

[igorpadykov]

Hi Dominique

one can use the 4.19.35_1.1.0 version BSP. For this version BSP, the optee branch is checkout from imx_3.2.y, so one needs to do encrypt boot at link :

https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/guides/mx8m_mx8mm_encrypted_...

Regardng matching versions  one can look at

 

https://source.codeaurora.org/external/imx/imx-optee-os/tree/?h=imx_4.19.35_1.1.0

Best regards
igor