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…

M2351 Block Diagram

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.

Functional View of MKROM

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:

Access to maskROM Crypto Lib from 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.

NuMaker-PFM-M2351 development board

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:

UART display

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():

AES Code example on M2351

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

Timing identification of AES related functions.

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:

Schematics describing the M2351 Power Supply.

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

Three SMD components are removed

A thin wire is soldered to LDO_CAP:

One wire…

then finally connected to a SMA connector:

…connected to SMA

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:

Final 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:

XAES_SetKey() function bypass
----- Cipher 19 -----Pulse delay = 0.000003810
cipher: c8a331ff8edd3db175e1545dbefb760b
...
----- Cipher 30 -----Pulse delay = 0.000003821
cipher: c8a331ff8edd3db175e1545dbefb760b

A python script to confirm:

AES encryption with a zeroizedkey

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:

Fault Timing to target AES penultimate round
... 
----- 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):

DFA using PhoenixAES

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

Subkey K10 recovered by DFA. Master Key recovered by reversing the aes_keyschedule

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.

5 Replies to “Nuvoton M2351 MKROM”

  1. Thank you for sharing, this article clearly explains how fault injection can change the results of program execution.

    The mentioned method uses the high / low output of GPIO PA10 to identify the operating range of AES, and then injects voltage glitch on specific function calls, such as XAES_SetKey(), to change the program execution result. I have some questions about this approach:

    1. How is the voltage drop and width determined? If it is the result of an experiment, how much test time will it take?

    2. Generally, MCUs have system level protection. For example, Flash’s read-write protection. In other words, we may not know the content of the code and cannot modify part of its code (for example, output GPIO state). In such case, how to find the specific function call which is the target of fault injection?

    Hope you can share your valuable experience, thanks!

    Nathan

    1. Hi,

      thanks for your comment.

      1. XP and knowledge of the target I would say… also, a little bit of characterisation can help.
      2/Agree, GPIO are just added to speed up the tests. On closed products, use reverse and side channel 😉

      Regards
      LR

  2. Hi,

    nice post.
    I am looking for a reaction from Nuvoton but I cannot find :-(.
    Do they fix? Do they communicate?

    Please keep sharing your expertise!
    tony

  3. Can I ask what is your Propagation Delay using the new HW (since the MAX4619 has 15ns)? Or did you gain other advantages instead of a decreased propagation delay?

    Best,
    Trashina

Leave a Reply

Your email address will not be published. Required fields are marked *