Likely a bug in HashCrypt() in TZ

キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

Likely a bug in HashCrypt() in TZ

ソリューションへジャンプ
151件の閲覧回数
mat1024
Contributor II

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 解決策
122件の閲覧回数
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 返答(返信)
123件の閲覧回数
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 件の賞賛
112件の閲覧回数
mat1024
Contributor II

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 件の賞賛