Microchip ATSAMA5 SoC Multiple Vulnerabilities [Full Release]

CVE-2020-12787, CVE-2020-12788, CVE-2020-12789

    Type

  • Multiple
  • Severity

  • High
  • Affected products

  • Microchip SAMA5 Series SoCs
  • Credits

  • The issues were discovered by Dmitry Janushkevich of the F-Secure Hardware Security team.
  • CVE Reference

  • CVE-2020-12787 CVE-2020-12788 CVE-2020-12789
Timeline
2020-01-23Initial contact. Details and suggested mitigations provided to Microchip, as well as proposing a 90 days disclosure timeline.
2020-01-24Microchip confirms the reception.
2020-01-28Microchip informs they are in the process of confirming the issues.
2020-02-04F-Secure requests a status update.
2020-02-05Microchip provides the status update and confirms the issues against SAMA5D27. Microchip intends to respond "in few days" regarding the disclosure timeline.
2020-02-25F-Secure requests a status update.
2020-02-27Microchip informs they are still working on identifying mitigations.
2020-03-17F-Secure requests a status update.
2020-03-19Microchip confirms SAMA5D3 and SAMA5D4 are also vulnerable, as well as informing F-Secure that suggested mitigations may not be applicable for all devices. Microchip starts planning a disclosure toward the customers.
2020-04-20F-Secure informs Microchip about the embargo period expiring.
2020-04-2390 day disclosure deadline missed.
2020-04-28Microchip informs regarding the mitigation plan for SAMA5D3. Microchip requests postponing the disclosure until December 2020 or early 2021.
2020-04-28F-Secure suggests timing the disclosure to the planned customer communication activities as information will become effectively public despite the limited amount of people being informed.
2020-05-04Conference call between Microchip and F-Secure. An agreement is reached for limited (what is vulnerable, impact) disclosure within weeks and full disclosure upon fixed part availability.
2020-05-09Microchip provides a draft of planned customer communication document. Also included is the list of affected part numbers for the D2 series.
2020-05-11F-Secure requests CVE identifiers from MITRE.
2020-05-12F-Secure provides a draft of planned limited disclosure document together with feedback on the Microchip document.
2020-05-19Microchip responds regarding the level of detail provided.
2020-05-21F-Secure provides a second draft of planned limited disclosure document with bare minimum of information included.
2020-05-25Tentative deadline for limited disclosure missed.
2020-05-30Microchip responds regarding the level of detail provided. Microchip also informs about starting the dissemination of limited information among select customers.
2020-05-30Microchip provides the list of affected part numbers for the D3 and D4 series.
2020-06-04F-Secure informs the vendor on the decision to adhere to the previously discussed limited disclosure, setting the new deadline to 2020-06-10.
2020-06-10Limited disclosure document published.
2021-01-12F-Secure and Microchip discuss the full disclosure procedure and timeline.
2021-03-19F-Secure publishes the full advisory.

Introduction

The SAMA5 System-on-Chip (SoC) device series is based on the high-performance ARM Cortex-A5 core and includes three device families: ATSAMA5D2, ATSAMA5D3, and ATSAMA5D4. This section provides a short introduction (derived from publicly available sources) into the security architecture of the SAMA5D2 series; other devices implement similar features.

All devices in the SAMA5 series provide a Secure Boot option backed by hardware cryptographic acceleration. As expected, Secure Boot is implemented by code located in read-only memory (ROM), however, access to this ROM area both via JTAG and through code/data fetches is disabled once control flow switches to non-secure code. This presents a challenge from the security analysis perspective where step one is gaining access to the actual code.

The ROM code, at a very high level, implements the following boot flow:

  • Initialize the required SoC blocks.
  • Scan external memory devices and attempt to boot from each.
  • If the SoC started in secure mode, pass control to the secure monitor.
  • Otherwise, pass control to the standard monitor.

The SAM Boot Assistant tool (SAM-BA) is provided by the manufacturer to help developers in provisioning the SoC. It interacts with the monitor code via e.g. a serial link or USB.

The secure monitor implements a variety of features:

  • Check the monitor version
  • Program fuse bits related to various features
  • Program security keys which are used to verify customer bootstrap code
  • Data transfer commands in both directions
  • Load and execute encrypted applets extending ROM functionality

The Secure Boot feature provides support for ensuring confidentiality and authenticity of loaded code. The confidentiality function is based on the AES algorithm, while authentication may use either AES-CMAC or RSA.

The following sections describe issues identified in the ROM code.

Improper applet verification

One of the more interesting functions is uploading of "applets" that augment the mask ROM code by providing advanced functionality such as programming external memories connected to the SoC via various peripheral interfaces. Applets are uploaded to the SoC via the appletUpload() function implemented in the sam-ba tool, which makes use of the SAPT Secure Monitor command.

Applet data for this command is both encrypted and authenticated as could be inferred from applets shipped with the tool: "secure" applet versions have the .cip extension, contain apparently random data, and are consistently 16 bytes longer (after block alignment) than non-secure versions. Tampering with secured applets results in data being rejected by the monitor citing CMAC verification failure. Further study of the sam-ba tool also shows the applets are loaded at the address 0x220000, the same address is used as the entry point, and "mailbox" address is at 0x220004. This also suggests the mailbox area is within the applet image.

However, despite the verification failure when CMAC is incorrect, offending data is not wiped from the buffer. This can be verified easily by reading the mailbox via the RMBX command and observing the returned data. Moreover, this also means applet image is decrypted in place. Here, an unencrypted ARM code was sent as an applet; note the SAPT command returning an error due to CMAC verification failure. The same ARM code is returned in the response to the RMBX command.

<<< SAPT,0,24,0,1#
>>> CACK,00000000,00000024#
>>> CACK,fffffff5,00000000#
<<< RMBX,0,80,0,0#
>>> CACK,00000000,00000080#
14309fe5141093e5020011e30110d2141c108315faffffea00000000000002f800000...

The following snippet presents the pseudocode of the SAPT command implementation, as extracted from the ROM code dump, validating the observations made before.

...
if ( !strncmp(&samba_cmd_params, "SAPT", 4u) ) {
  memzero(applet_code, 0x20000u);
  if ( samba_cmd_params.length > 0x20000u )
    goto LABEL_66;
  samba_send_response("CACK", 0, samba_cmd_params.length, 0);
  xmodem_receive(applet_code, samba_cmd_params.length);
  v6 = cmac_and_decrypt(
      applet_code,
      samba_cmd_params.length - 16,
      applet_code,
      &byte_21FFF0[samba_cmd_params.length],
      &applet_key);
  if ( v6 >= 0 ) {
    samba_send_response("CACK", 0, 0, 0);
    v7 = 1;
  } else {
    samba_send_response("CACK", v6, 0, 0);
    v7 = 0;
  }
  samba_applet_loaded = v7;
}
...

Note the flag signifying successful applet validation is properly set or reset at the end of command execution.
However, it was found the EAPP command designed to invoke the applet does not verify whether the applet was properly loaded before passing control to the applet's entry point address. The following presents the pseudocode of the EAPP command implementation, as extracted from the ROM code dump:

...
if ( !strncmp(&samba_cmd_params, "EAPP", 4u) ) {
  samba_jump((int (*)(void))applet_code);
  samba_send_response("ASTA", applet_mailbox->status, 0, 0);
  if ( applet_mailbox->command == -1 && !applet_mailbox->status ) {
    applet_buffer = applet_mailbox->data[0];
    applet_buffer_size = applet_mailbox->data[1];
  }
}
...

This means that an attacker can upload arbitrary applet code using the SAPT command, completely ignoring encryption and authentication requirements, and use the EAPP command to execute it. The uploaded code executes with the privileges equal to the Secure Monitor itself.

The same issue affects the SFIL and RFIL commands.

Impact

An attacker with access to Secure SAM-BA Monitor is able to execute arbitrary code on the target SoC while in secure boot mode, thus bypassing all code integrity restrictions. This further allows the attacker to exfiltrate the customer key, subverting the whole chain of trust.

CMAC verification susceptible to SPA

The AES-128 based CMAC authentication is used to prove authenticity and integrity of software components such as monitor applets and bootstrap code.

It was experimentally found that the implementation of the comparison operation, when comparing computed and provided CMAC values, leaks information regarding CMAC validity via both timing and power channels.

A setup based on a ChipWhisperer-Lite (CW1173) tool was used to capture power traces of the ATSAMA5D27 SoC, part of the SAMA5D2-XULT evaluation kit. The kit board was modified by removing C27 and C28, as well as inserting a small resistor in place of JP7. To control the target and provide a trigger signal, a separate device was programmed to issue SAM-BA commands in a deterministic manner to the Secure SAM-BA Monitor running on the SoC.

To validate whether the comparison operation is susceptible to timing attacks, bytes in a known-valid CMAC value were corrupted one by one, with the result submitted for processing by the SoC every time. The following graph represents power traces captured (averages of 100 runs each).

NOTE: Here and below the horizontal axis represents time in samples taken at 100MSPS, while the vertical axis represents power measurements.

While traces to the left of the second large peak (around sample 7300) are synchronized, traces to the right are shifted according to the corrupted byte position. Same graphs are obtained for each byte corrupted within a word, therefore only 4 traces are depicted in the graph above.

While the attack does not allow for byte-level timing attacks, it is possible to discern whether a 32-bit word is correct or not. This already constitutes a theoretical break of the algorithm used to perform the comparison, however in practice any brute force attacks against each word would take too long.

The next graph represents power measurements taken when the highest nibble of the first byte (big endian byte order) takes values 0x0 through 0xF to investigate how this might affect power consumption. The valid CMAC word in this case was 0x8D7D5742. Traces are averages of 5 runs each.

The traces are clustered into two distinct groups, diverging around sample 1220. Further, the traces in the "upper" group are all from the cases where a borrow occurs during subtraction of the provided word from the computed word, i.e. when the provided word is above the computed word.

This fact can be used to conduct an effective bit-level divide-and-conquer attack against each word, starting from all zeros and verifying whether setting each bit, starting from the highest, results in a borrow. Based on this, a proof-of-concept practical attack was developed that guesses the correct CMAC value for an arbitrary text taking less than 1300 power measurements in total, executed in about 20 minutes.

All use cases of the affected CMAC function are believed to be affected: when booting a bootstrap image, when loading a SAM-BA applet, and when installing a key.

Impact

An attacker with physical access is able to infer correctness of guesses against a valid CMAC code by observing power consumption of the SoC. Ultimately, this allows the attacker to forge CMACs and authenticate arbitrary data.

Hardcoded keys are used for protecting applets

As described above, applet code is both encrypted and authenticated. However, it was found that the key set used to encrypt and authenticate applets is hardcoded within the Secure Monitor and is available for abuse once the code has been extracted. The key is shared among at least all ATSAMA5D2 devices.

The following snippet presents the pseudocode of the SAPT command implementation, as extracted from the ROM code dump, illustrating the hardcoded key usage.

...
if ( !strncmp(&samba_cmd_params, "SAPT", 4u) ) {
  memzero(applet_code, 0x20000u);
  if ( samba_cmd_params.length > 0x20000u )
    goto LABEL_66;
  samba_send_response("CACK", 0, samba_cmd_params.length, 0);
  xmodem_receive(applet_code, samba_cmd_params.length);
  v6 = cmac_and_decrypt(
      applet_code,
      samba_cmd_params.length - 16,
      applet_code,
      &byte_21FFF0[samba_cmd_params.length],
      &applet_key);
  if ( v6 >= 0 ) {
    samba_send_response("CACK", 0, 0, 0);
    v7 = 1;
  } else {
    samba_send_response("CACK", v6, 0, 0);
    v7 = 0;
  }
  samba_applet_loaded = v7;
}
...

The applet key set referenced above is located at offset 0xA600. The validity of this credential was confirmed by using the extracted key set to decrypt applets shipped with the sam-ba tool.

Impact

An attacker able to extract ROM code can obtain the hardcoded key set and proceed to encrypt and authenticate malicious applets. Encrypted applets can then be used to gain access to any device in the given series (D2, D3, or D4) provided the Secure Monitor can be accessed.

Affected products and versions

The issues were identified in ATSAMA5D27 SoC mask revision C, Secure Monitor version 1.3, build date October 28, 2016, 16:04:43.

Affected CPNs for the SAMA5D2 product line:

  • ATSAMA5D21C-CU, ATSAMA5D21C-CUR
  • ATSAMA5D22C-CN, ATSAMA5D22C-CNR, ATSAMA5D22C-CU, ATSAMA5D22C-CUR
  • ATSAMA5D23C-CN, ATSAMA5D23C-CNR, ATSAMA5D23C-CU, ATSAMA5D23C-CUR
  • ATSAMA5D24C-CU, ATSAMA5D24C-CUF, ATSAMA5D24C-CUR
  • ATSAMA5D26C-CN, ATSAMA5D26C-CNR, ATSAMA5D26C-CU, ATSAMA5D26C-CUR
  • ATSAMA5D27C-CN, ATSAMA5D27C-CNR, ATSAMA5D27C-CU, ATSAMA5D27C-CUR
  • ATSAMA5D28C-CN, ATSAMA5D28C-CNR, ATSAMA5D28C-CU, ATSAMA5D28C-CUR
  • ATSAMA5D27C-CNVAO, ATSAMA5D27C-CNRVAO

SiP variants:

  • ATSAMA5D225C-D1M-CUR
  • ATSAMA5D27C-D5M-CU, ATSAMA5D27C-D5M-CUR,
  • ATSAMA5D27C-D1G-CU, ATSAMA5D27C-D1G-CUR
  • ATSAMA5D28C-D1G-CU, ATSAMA5D28C-D1G-CUR
  • ATSAMA5D27C-LD1G-CU, ATSAMA5D27C-LD1G-CUR
  • ATSAMA5D27C-LD2G-CU, ATSAMA5D27C-LD2G-CUR
  • ATSAMA5D28C-LD1G-CU, ATSAMA5D28C-LD1G-CUR
  • ATSAMA5D28C-LD2G-CU, ATSAMA5D28C-LD2G-CUR

SoM variants:

  • ATSAMA5D27-WLSOM1
  • ATSAMA5D27-SOM1

Affected CPNs for the SAMA5D3 product line:

  • ATSAMA5D31A-CU, ATSAMA5D31A-CUR, ATSAMA5D31A-CFU, ATSAMA5D31A-CFUR
  • ATSAMA5D33A-CU, ATSAMA5D33A-CUR
  • ATSAMA5D34A-CU, ATSAMA5D34A-CUR
  • ATSAMA5D35A-CU, ATSAMA5D35A-CUR, ATSAMA5D35A-CN, ATSAMA5D35A-CNR
  • ATSAMA5D36A-CU, ATSAMA5D36A-CUR, ATSAMA5D36A-CN, ATSAMA5D36A-CNR

Affected CPNs for the SAMA5D4 product line:

  • ATSAMA5D41A-CU, ATSAMA5D41A-CUR, ATSAMA5D41B-CU, ATSAMA5D41B-CUR
  • ATSAMA5D42A-CU, ATSAMA5D42A-CUR, ATSAMA5D42B-CU, ATSAMA5D42B-CUR
  • ATSAMA5D43A-CU, ATSAMA5D43A-CUR, ATSAMA5D43B-CU, ATSAMA5D43B-CUR
  • ATSAMA5D44A-CU, ATSAMA5D44A-CUR, ATSAMA5D44B-CU, ATSAMA5D44B-CUR

Solution

For products based on the SAMA5D2 and SAMA5D4 devices, disabling the SAM-BA monitor after provisioning the chips mitigates all the reported issues. This can be done by setting the "Disable Monitor" bit in the fuse area.

CMAC verification issue may be mitigated by choosing the RSA authentication option to replace CMAC calculation.

For products based on the SAMA5D3 devices, no mitigations were identified. The only identified solution is to update the products to the next silicon revision when made available by Microchip.

CVE assignment

CVEDescription
CVE-2020-12787Improper applet verification
CVE-2020-12788CMAC verification susceptible to SPA
CVE-2020-12789Hardcoded keys are used for protecting applets