imx93 dm-crypt options

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

imx93 dm-crypt options

1,120 Views
electro1
Contributor II

Hi,

We are setting up dm-crypt on imx93 and have been having stability issues with the cbc-aes-tee driver, which we still hope NXP are looking at.

When looking at the keytypes and encryption algorithms, I tried understanding the different options. As I understand it:

1. Using user key and cbc-aes-ce. Key is completely unprotected and available in plain text in user space. Encryption is handled in kernel. Not a viable option.

2. Using TEE-backed trusted key and cbc-aes-ce. Key is protected and only available encrypted in user space. Key is unsealed in kernel by calling OP-TEE. Encryption is handled in kernel. Key is open to DRAM bus sniffing and kernel attacks.

3. Using user key and cbc-aes-tee. Key in keyring is completely unprotected and available in plain text in user space. However, this key is only used as a salt for the actual key derived in OP-TEE so it does not matter(?). Derived key is only ever stored in OCRAM. Encryption is handled in OP-TEE.

4. Using TEE-backed trusted key and cbc-aes-tee. Key is protected and only available encrypted in user space. Key is unsealed in kernel by calling OP-TEE. However, this key is still only used as a salt for the actual key derived in OP-TEE so now it is unnecessarily protected in keyring as well(?). Derived key is only ever stored in OCRAM. Encryption is handled in OP-TEE.

In Rev. LF6.12.3_1.0.0 of Linux User Guide a user key is used, and in Rev. LF6.12.20_2.0.0 a trusted key is used (chapter 10.5.5), that's why I started thing about the difference. Is my understanding of the options listed above correct?

Thinking about the security implications of option 2 versus 3 or 4 is seems the main difference is that the key might be open to DRAM sniffing attacks or kernel attacks? The on-disk storage of the key is still encrypted and secure?

 

Labels (1)
0 Kudos
Reply
1 Reply

1,049 Views
Harvey021
NXP TechSupport
NXP TechSupport

Hi, 

Please referencing our latest BSP release: 6.12.34_2.1.0 to see if there are any issues. First, the salt is encapsulated in a trusted blob. Second, the key is exported from the ELE to OCRAM with the salt, and is only used within the TEE.

 

Regards

Harvey

0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2175753%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3Eimx93%20dm-crypt%20options%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2175753%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3EWe%20are%20setting%20up%20dm-crypt%20on%20imx93%20and%20have%20been%20having%20stability%20issues%20with%20the%20cbc-aes-tee%20driver%2C%20which%20we%20still%20hope%20NXP%20are%20looking%20at.%3C%2FP%3E%3CP%3EWhen%20looking%20at%20the%20keytypes%20and%20encryption%20algorithms%2C%20I%20tried%20understanding%20the%20different%20options.%20As%20I%20understand%20it%3A%3C%2FP%3E%3CP%3E1.%20Using%20user%20key%20and%20cbc-aes-ce.%20Key%20is%20completely%20unprotected%20and%20available%20in%20plain%20text%20in%20user%20space.%20Encryption%20is%20handled%20in%20kernel.%20Not%20a%20viable%20option.%3C%2FP%3E%3CP%3E2.%20Using%20TEE-backed%20trusted%20key%20and%20cbc-aes-ce.%20Key%20is%20protected%20and%20only%20available%20encrypted%20in%20user%20space.%20Key%20is%20unsealed%20in%20kernel%20by%20calling%20OP-TEE.%20Encryption%20is%20handled%20in%20kernel.%20Key%20is%20open%20to%20DRAM%20bus%20sniffing%20and%20kernel%20attacks.%3C%2FP%3E%3CP%3E3.%20Using%20user%20key%20and%20cbc-aes-tee.%20Key%20in%20keyring%20is%20completely%20unprotected%20and%20available%20in%20plain%20text%20in%20user%20space.%20However%2C%20this%20key%20is%20only%20used%20as%20a%20salt%20for%20the%20actual%20key%20derived%20in%20OP-TEE%20so%20it%20does%20not%20matter(%3F).%20Derived%20key%20is%20only%20ever%20stored%20in%20OCRAM.%20Encryption%20is%20handled%20in%20OP-TEE.%3C%2FP%3E%3CP%3E4.%20Using%20TEE-backed%20trusted%20key%20and%20cbc-aes-tee.%20Key%20is%20protected%20and%20only%20available%20encrypted%20in%20user%20space.%20Key%20is%20unsealed%20in%20kernel%20by%20calling%20OP-TEE.%20However%2C%20this%20key%20is%20still%20only%20used%20as%20a%20salt%20for%20the%20actual%20key%20derived%20in%20OP-TEE%20so%20now%20it%20is%20unnecessarily%20protected%20in%20keyring%20as%20well(%3F).%20Derived%20key%20is%20only%20ever%20stored%20in%20OCRAM.%20Encryption%20is%20handled%20in%20OP-TEE.%3C%2FP%3E%3CP%3EIn%20Rev.%20LF6.12.3_1.0.0%20of%20Linux%20User%20Guide%20a%20user%20key%20is%20used%2C%20and%20in%20Rev.%20LF6.12.20_2.0.0%20a%20trusted%20key%20is%20used%20(chapter%2010.5.5)%2C%20that's%20why%20I%20started%20thing%20about%20the%20difference.%20Is%20my%20understanding%20of%20the%20options%20listed%20above%20correct%3F%3C%2FP%3E%3CP%3EThinking%20about%20the%20security%20implications%20of%20option%202%20versus%203%20or%204%20is%20seems%20the%20main%20difference%20is%20that%20the%20key%20might%20be%20open%20to%20DRAM%20sniffing%20attacks%20or%20kernel%20attacks%3F%20The%20on-disk%20storage%20of%20the%20key%20is%20still%20encrypted%20and%20secure%3F%3C%2FP%3E%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2175753%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CLINGO-LABEL%3ESecurity%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2178075%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20imx93%20dm-crypt%20options%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2178075%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%2C%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%20data-teams%3D%22true%22%3EPlease%20referencing%20our%20latest%20BSP%20release%3A%206.12.34_2.1.0%20to%20see%20if%20there%20are%20any%20issues.%20First%2C%20the%20salt%20is%20encapsulated%20in%20a%20trusted%20blob.%20Second%2C%20the%20key%20is%20exported%20from%20the%20ELE%20to%20OCRAM%20with%20the%20salt%2C%20and%20is%20only%20used%20within%20the%20TEE.%3C%2FSPAN%3E%3C%2FP%3E%0A%3CBR%20%2F%3E%0A%3CP%3E%3CSPAN%20data-teams%3D%22true%22%3ERegards%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%3CSPAN%20data-teams%3D%22true%22%3EHarvey%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E