Likely a bug in HashCrypt() in TZ

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Likely a bug in HashCrypt() in TZ

跳至解决方案
890 次查看
mat1024
Contributor III

Hi,

 

Environment

Board: LPC55s69
SDK version: 2.12.0
SW: MCUXPresso IDE

 

I was trying to exploit ECDSA sign/verify functions in secure memory, so I ported "lpcxpresso55s69_mbedtls_benchmark" project in SDK 2.12.0 to my TZ project.

 

 

I found that when I use those functions in applications in secure world, it was always stuck in 'hashcrypt_sha_finalize' or 'hashcrypt_sha_process_message_data'  functions, specifically in this while loop,

while (0U == (base->STATUS & HASHCRYPT_STATUS_DIGEST_MASK))
     {
     }

The status here was set to 5 when I tried in secure world, but it was 3 when I tried in normal work, where the code worked fine.

To clarify why this happens, I changed the MEMADDR where the message was given to any non-secure RAM and it worked well, which probably means that this is not the configuration issue, but the hardware/software bug using secure RAM.

//  base->MEMADDR = HASHCRYPT_MEMADDR_BASE(message);
    base->MEMADDR = 0x2001bd4c;

 

Would anybody help me to figure this out in more detail?

Here is the original question I posted a few days before.

https://community.nxp.com/t5/LPC-Microcontrollers/Question-about-Hashcrypt-in-LPC55S69/m-p/1586892#M...

 

Thanks!

标签 (1)
0 项奖励
回复
1 解答
861 次查看
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello @mat1024 

 

How about add code 

HASHCRYPT->LOCK = HASHCRYPT->LOCK | ((0x0A75<<4) | 0x1);

Because the HASH-AES engine is unlocked by default. That means it will issue non-secure requests as AHB master, as shown below.

Alice_Yang_0-1675134717870.png

 

So we cannot use it at secure state when it is unlocked. We must lock it at secure state if we want to use it at secure state.

 

BR

Alice

在原帖中查看解决方案

0 项奖励
回复
2 回复数
862 次查看
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello @mat1024 

 

How about add code 

HASHCRYPT->LOCK = HASHCRYPT->LOCK | ((0x0A75<<4) | 0x1);

Because the HASH-AES engine is unlocked by default. That means it will issue non-secure requests as AHB master, as shown below.

Alice_Yang_0-1675134717870.png

 

So we cannot use it at secure state when it is unlocked. We must lock it at secure state if we want to use it at secure state.

 

BR

Alice

0 项奖励
回复
851 次查看
mat1024
Contributor III

Hi @Alice_Yang ,

 

Thanks for your comment!

After adding code right next to resetting the peripheral in HASHCRYPT_Init() function, it works perfectly!

void HASHCRYPT_Init(HASHCRYPT_Type *base)
{
#if !(defined(FSL_SDK_DISABLE_DRIVER_CLOCK_CONTROL) && FSL_SDK_DISABLE_DRIVER_CLOCK_CONTROL)
    CLOCK_EnableClock(kCLOCK_HashCrypt);
#endif /* FSL_SDK_DISABLE_DRIVER_CLOCK_CONTROL */
    RESET_PeripheralReset(kHASHCRYPT_RST_SHIFT_RSTn);

	// From NXP forum
	HASHCRYPT->LOCK = HASHCRYPT->LOCK | ((0x0A75<<4) | 0x1);
}

 

Hope this snippet of code would be helpful to those who want to use cryptographic functions in a secure world.

 

Thanks!

0 项奖励
回复