Crypto implementation cbc-aes-tee modifies the key given to it.

[danieljohnson]

Hello,

I am seeing some differing behavior for the kernel crypto implentation cbc-aes-tee (from NXP OP-TEE) compared to other cbc-aes implementations (cbc-aes-ce, cbc-aes-neonbs, cbc-aes-generic). I am using the iMX93 with linux-imx 6.12.20-2.0.0, yocto walnascar with optee 4.6. 

I ran into this issue when trying to install encrypted update bundles with RAUC. RAUC was able to decrypt the update bundle with openSSL but could not mount the bundle with dm_crypt. I found an issue on the RAUC Github page that described the problem. (Issue 1833, here is a link: https://github.com/rauc/rauc/issues/1833)

I confirmed that this is the issue I am facing. The problem is that cbc-aes-tee does not use the key pass to it from the kernel driver directly but treats it as a salt for deriving a new key. This goes against what the kernel expects (specifically crypto_skcipher_setkey) and is different from the other cbc-aes implementations (cbc-aes-ce, cbc-aes-neonbs, cbc-aes-generic). Other RAUC users have worked around this by lowering the priority of the OP-TEE's symmetric key cryptography implementations in the kernel's crypto API so that the kernel prefers other implementations. This can be done by settingTEE_CRYPTO_CRA_PRIORITY to a low value in tee_skcipher.h. This causes the kernel to use cbc-aes-ce instead of cbc-aes-tee on my board, which does solve the immediate problem with RAUC and dm_crypt. However, my coworkers think this is a little heavy-handed, and this does not fix the issue with cbc-aes-tee. 

I've written a small program to demonstrate the problem. The program encrypts a message using openSSL, and then decrypts it using cbc-aes-ce, cbc-aes-neonbs, cbc-aes-generic, and finally cbc-aes-tee. The cbc-aes-tee implementation is the only one that does not work, because it does not use the key directly. I've attached the program source, the compiled program binary (gzipped so it would let me upload it), and the program's output after running it on my board. 

I would love to get this fixed so that cbc-aes-tee behaves the same as the other implementations. Please let me know if there is anything I can do to help. 

[yipingwang]

According to R&D team's reply, this is an expected behaviour.

This TEE offload is not meant to be inter-operable, where encryption is done by offloading it to TEE, while corresponding decryption done by non-TEE.

I have raised one jira ticket LF-17796 to suggest R&D can decrease default priority of "cbc-aes-tee" driver.

Let's wait for feedback.

[danieljohnson]

Thank you for the feedback. 

If cbc-aes-tee is not meant to be compatible with the other cbc(aes) implementations, then I think it should not be available to the kernel crypto API to choose as an implementation of cbc(aes). 

[yipingwang]

This patch https://github.com/rauc/rauc/issues/1833#issuecomment-3632067956

is under review.

Customer can apply this patch to resolve their problem. The issue will be fixed in further BSP release.

[yipingwang]

Discussing with the AE team.

[danieljohnson]

Thank you, please let me know if there is any feedback from the team.