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-...
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.
1. 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.
1.1 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.
1.2 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.
2. 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
2.1 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.
3. Setup
3.1 Development Board
NuMaker-PFM-M2351 is used for the tests. User Manual is here.
NuMaker-PFM-M2351 development board
Chip reference is M2351KIAAE.
3.2 Tool Development
Keil uVision V5.29.0.0 is used to develop, compile and flash the code running on Nuvoton M2351 development kit.
3.3 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
3.4 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.
4. 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.
4.1 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.
5. 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.
6. Results
6.1 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
6.2 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
6.3 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
7. 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.
8. 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.