Nuvoton M2351 MKROM

TrustZone is the last hardware security mechanism integrated to ARMv8-M. This article presents some Fault Injection results achieved on Nuvoton M2351 (Cortex-M23), targeting MKROM crypto-functions and secure Code.

ARMv8-M TrustZone

TrustZone technology (TZ) is NOT really a NEW security concept. It has been available on ARM Cortex-A since more than 10 years now. The TrustZone security extension is now available for low-power Microcontroller, enabling the system and the software to be partitioned into Secure World and Non-Secure World. Secure software can access both Secure and Non-secure memories and resources, while Normal software can only access Non-secure memories and resources. Full reference documentation is present on ARM website.

Nuvoton M2351 series

Nuvoton is fabless company based in Taiwan. The NuMicro M2351, based on Arm Cortex-M23, is the first series in the Family to realise robust IoT security applications, empowered by the Arm TrustZone for Armv8-M architecture.

M2351 operates at up to 64 MHz frequency, with up to 512 Kbytes embedded Flash memory and up to 96 Kbytes embedded SRAM. It provides high-performance connectivity peripheral interfaces such as UART, SPI, I²C, GPIOs, USB…

Datasheet, TRM and other documents are available here. Quality of documentation is pretty good.

Previous Researchs

During 36C3 conference in December 2019, @StackSmashing presented some Hardware Attacks on Nuvoton M2351, breaking Secure Attribution Units (SAU) configuration. Nice job, link is here.

The Target: M2351 MKROM Lib

According to the application note AN2023, the MKROM Lib is a software library which is resident in M2351 Mask ROM. It provides a set of built-in functions that can be used to enable Flash, Crypto and firmware download functions by application programs.

The content of MKROM Lib is tamper-proof due to the Read-Only feature of Mask ROM. Besides, the memory attribute of Mask ROM is configured as Execute-Only to prevent a thief from reading the library or tracing the instruction execution.

Cryptographic Library

The M2351 MKROM Crypto library supports cryptographic functions which are implemented with the M2351 hardware cryptographic accelerator. The supported functions include AES, TDES, SHA, ECC and TRNG and can only be called by the secure code:

Crypto-Library is part of BSP_CMSIS_V3.00.004. Example codes are located in SampleCode/MKROM/CryptoLibDemo.

Code source for MKROM and Hardware crypto-function are NOT provided by NUVOTON.

Setup

Development Board

NuMaker-PFM-M2351 is used for the tests. User Manual is here.

Chip reference is M2351KIAAE.

Tool Development

Keil uVision V5.29.0.0 is used to develop, compile and flash the code running on Nuvoton M2351 development kit.

AES Code

AES Test Code is based on BSP AES_Demo example. The code performs an AES-128 bit Encryption and displays the output over UART.

Data used during the tests:

AES Key = ’00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f’
AES in  = ’00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff’
AES out = ’69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a’

From the UART, the following information are displayed:

AES Identification

AES Test Code is modified to insert GPIO functions. GPIO PA10 is set to High before the function XAES_Open() and then set to Low after XAES_Start():

The LDO_CAP voltage signal is probed to be visualised on the scope screen (CH4). Hardware AES encryption is identified (red frame below):

Voltage Glitching

I deicide to use voltage glitching to disturb MKROM code executing secure operations (aka AES related functions running in Secure World). 

The glitching method is based on a MOSFET board I designed recently. These tests are also the opportunity to validate the efficiency of this low cost glitcher (total cost around 2$).

This technique is different than the previous one presented last year and can be used as secondary glitching technique, depending on the target.

PCB Preparation

Here is the interesting part from the schematics:

I decide to slightly modified the PCB by removing L14, CM1 and CM2:

A thin wire is soldered to LDO_CAP:

then finally connected to a SMA connector:

The output of my home-made Glitcher is then connected to the SMA connector and everything is now ready to produce very short perturbations.

Final Setup

The image below shows the complete setup:

USB cable is used to power the entire board. USB to Serial Cable is used to connect the board to the PC (minicom is used as serial client 115200 8N1). LDO_CAP (pin54) is connected to the scope Channel 3 and PA10 (pin14) to the scope Channel 2.

A python script is used to communicate with the board and to set all the glitching parameters, resetting it after each AES encrypt operation.

Results

Vulnerability n*1 = AES Key Zeroized

The AES Key can be zeroized using fault injection. As a result, the AES output corresponds to AES(input, key=0x00*16), which is a predictable value and can be exploited in various attack scenarios.

Here is a scope screen showing the XAES_SetKey() is just skipped. The timing is 2.5us shorter than usual:

----- Cipher 19 -----Pulse delay = 0.000003810
cipher: c8a331ff8edd3db175e1545dbefb760b
...
----- Cipher 30 -----Pulse delay = 0.000003821
cipher: c8a331ff8edd3db175e1545dbefb760b

A python script to confirm:

Vulnerability n*2 = AES Output Zeroized

The AES output can be zeroized using fault injection. As a result, the AES output corresponds to a zeroized output, demonstrating function such as XAES_SetDMATransfer() can be easily corrupted, even if it is running as Secure Code in TrustZone.

----- Cipher 641 -----Pulse delay = 0.000009210
cipher: 00000000000000000000000000000000
...
----- Cipher 983 -----Pulse delay = 0.000010920
cipher: 00000000000000000000000000000000

Vulnerability n*3 = AES Key recovery by Differential Fault Analysis 

Targeting the Round 8 of AES-128, an attacker can introduce fault during the computation done by Crypto-Accelerator to produce a wrong AES ciphertext output:

... 
----- Cipher 407 -----Pulse delay = 0.000014208 
cipher: 0b8d117c09e8e17a8cb82e7843d22d21

----- Cipher 412 -----Pulse delay = 0.000014213 
cipher: 49d246633a603b4983c121fdf9bd91eb
...

The PhoenixAES from @doegox is then used to perform Differential Fault analysis (DFA):

The AES key is then fully recovered (only two faulted AES ciphertexts are sufficient to retrieve the entire key K00):

Conclusion

Some Fault Injections tests were performed on Nuvoton M2351 (Cortex-M23). Several vulnerabilities were presented to demonstrate software executed in Secure World can be modified. MaskROM pre-written functions were also targeted, allowing AES Key recovery by faulting the crypto-engine.

From a hardware hacker point of view, the ARMv8-M does not bring any security hardness against Fault Injections.

Timeline Disclosure

20/12/2019: First email to Nuvoton.

25/12/2019: Second email to Nuvoton.

29/12/2019: Third and last email to Nuvoton.

12/01/2020: Posted.