Likely a bug in HashCrypt() in TZ

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

Likely a bug in HashCrypt() in TZ

Jump to solution
546 Views
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!

Labels (1)
0 Kudos
1 Solution
517 Views
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

View solution in original post

0 Kudos
2 Replies
518 Views
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 Kudos
507 Views
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 Kudos