Built on TSMCs 16FinFET Plus (16FF+) process, the Zynq UltraScale+ MPSoC integrates AMD programmable logic (PL) and an Arm® -based processing system (PS) that includes an application processing unit containing two or four Cortex®-A53 cores (APU subsystem) and a real-time processing unit containing two Cortex-R5F cores (RPU) in a single device.
The Zynq UltraScale+ MPSoC provides a number of features to help secure not only the hardware but the software applications running on it. These features include a hardened physical unclonable function (PUF), user-accessible hardened cryptographic blocks, asymmetric authentication, side-channel attack protection, and other silicon-based anti-tamper protections. See Accelerating Cryptographic Performance on the Zynq UltraScale+ MPSoC (WP512) and Developing Tamper-Resistant Designs with Zynq UltraScale+ Devices (XAPP1323) for details. AMD also offers an intellectual property (IP) known as Security Monitor (SecMon) to provide runtime protection against a variety of tamper attacks. [REF 7].
AMD classifies the security features as either passive or active. In general, passive features are either part of the tool flow or built into the device and do not require you to do anything extra in your SoC design. Passive features are also temporal in nature and come into effect at the following phases of the operating life of the Zynq UltraScale+ MPSoC:
- Pre-boot
- During boot
- Post-boot
In contrast, active security features are required to be included in the SoC design. These features only come into effect after the Zynq UltraScale+ MPSoC has been securely booted and the design becomes active. The security features fall into three main categories:
- Prevention (e.g., JTAG port disabling)
- Detection (e.g., on-chip temperature and voltage monitoring)
- Response (e.g., key zeroization)
The following table summarizes the security features of the Zynq UltraScale+ MPSoC (see Developing Tamper-Resistant Designs with Zynq UltraScale+ Devices (XAPP1323)).
| Zynq UltraScale+ MPSoC Security Features | Type | Category |
|---|---|---|
| Image/bitstream confidentiality (symmetric) | Passive | Prevention |
| Volatile on-chip 256-bit BBRAM AES key storage | Passive | Prevention |
| Non-volatile on-chip 256-bit eFUSE AES key storage | Passive | Prevention |
| PUF-enabled black key storage (internal eFUSEs) | Passive | Prevention |
| Write-only key load with integrity check (BBRAM and eFUSE) | Passive | Prevention |
| Image/bitstream authentication (symmetric) | Passive | Prevention |
| Image/bitstream authentication (asymmetric) | Passive | Prevention |
| Non-volatile 384-bit eFUSE public key hash storage to enable RSA authentication | Passive | Prevention |
| DPA side-channel attack protections | Passive | Prevention |
| Obfuscation of the user AES key loading and storage | Passive | Prevention |
| Hardened readback disabling circuitry | Passive | Prevention |
| Design for test (DFT) boot mode permanent disable | Passive | Prevention |
| Uninterruptible internal clock source for CSU | Passive | Prevention |
| Error correction code (ECC) on PS memories | Passive | Prevention |
| Triple-mode redundancy (TMR) in PS critical operations | Passive | Prevention |
| JTAG port permanent disable (eFUSE) |
Passive or active |
Prevention or response |
| JTAG port temporary disable |
Passive or active |
Prevention |
| JTAG port monitor | Active | Detection |
| PL configuration memory integrity checking | Active | Detection |
| Unique identifiers (device DNA and user eFUSE) | Active | Detection |
| On-chip temperature and voltage monitors/alarms | Active | Detection and response |
| PL configuration memory clearing | Active | Response |
| Uninterruptible internal clock source on PL STARTUP block | Active | Detection |
| Key agility (BBRAM only) | Active | Prevention and response |
| BBRAM key zeroize (erase + verify) | Active | Response |
| CSU tamper monitor and response | Active | Detection and response |
| Public key revocation | Active | Response |
| Non-volatile (eFUSE) tamper event logging | Active | Response |
| User accessible crypto blocks | Active | Prevention |
| Arm TrustZone | Active | Prevention and detection |
| Arm v8 cryptography extensions | Active | Prevention and detection |
| AMD memory protection unit (XMPU) | Active | Prevention and detection |
| AMD peripheral protection unit (XPPU) | Active | Prevention and detection |
| AXI/APB isolation block (AIB) | Active | Prevention and response |
| AXI timeout block (ATB) in interconnects | Active | Detection and response |
| System memory management unit (SMMU) | Active | Prevention and detection |
| Global 3-state (GTS) enable (PL I/O only) | Active | Response |
| Global set-reset (GSR) enable (PL I/O only) | Active | Response |
At the center of the device security is the hardened configuration security unit (CSU), shown in the following figure. The CSU consists of two main blocks, the secure processor block (SPB) and the crypto interface block (CIB), shown on the left and right of the figure, respectively. The SPB contains a triple-redundant MicroBlaze™ processor for controlling boot operation, an associated ROM, a small private RAM, a PUF, and the necessary control/status registers required to support all secure operations. The CIB contains engines for supporting and accelerating the following cryptographic operations:
- AES-GCM, SHA-3, and RSA
- Direct memory access (DMA) controller
- Processor configuration access port (PCAP) interface
The CSU ensures the secure boot of the device by supporting the authentication and confidentiality of the partitions in the boot image. This also includes the secure storage and management of the cryptographic keys. After boot, the CSU is used for tamper monitoring and response of the device. At runtime, the crypto engines of the CSU can also be used by PS/PL applications to accelerate cryptographic operations. Access to the CSU can be restricted to specific applications with the XPPU.
The following figure illustrates a typical Zynq UltraScale+ MPSoC boot process that builds a chain of trust to ensure a secure boot process so that security at runtime (application execution) can be achieved. The chain of trust is maintained assuming each loaded component is either immutable (for example, boot ROM code) or is properly authenticated.
Secure boot is defined as authenticating PS/PL images (use of encryption is optional unless confidentiality is required for boot products). Image authentication (using RSA) ensures that an image came from a trusted source and has not been modified. The Zynq UltraScale+ MPSoC builds the chain of trust by supporting the authentication of the very first piece of user code that is loaded on the SoC, which is the first stage boot loader (FSBL). To this end, the device also checks the integrity of the immutable boot ROM code (using SHA-3), which brings up the FSBL. Along with integrity and authentication, the Zynq UltraScale+ MPSoC also provides confidentiality of the images (using AES-GCM) to protect against attacks such as cloning, over-building, and reverse engineering. There are a number of other security features such as black key storage and side-channel attack countermeasures that add to the robustness of the Zynq UltraScale+ device secure boot process.
Unlike previous generations, the Zynq UltraScale+ MPSoC provides a PUF. The PUF, among other functions, serves as a generator of a die-unique AES key-encryption key (KEK) that can be used to encrypt/decrypt the symmetric 256-bit AES key that decrypts the partitions of the boot image. That is, the Zynq UltraScale+ MPSoC encrypts the symmetric AES key using the KEK to further protect it, before storing it in non-volatile eFUSEs. Furthermore, the device stores the 384-bit SHA-3 hash of the user-defined 4096-bit RSA public key in the eFUSE bits. This unmodifiable SHA-3 hash links the RSA public key to the device to enable authentication of the FSBL to establish a root-of-trust. User-defined cryptographic keys (AES keys and the hashes of RSA keys) can be stored in the on-chip eFUSEs or battery-backed RAM (BBRAM). The programming of BBRAM and eFUSEs is achieved using software that runs on the PS, which uses the AMD Secure Key (XilSKey) library (see Zynq UltraScale+ MPSoC: Software Developers Guide (UG1137)).
Arm TrustZone combined with XPPU and XMPU provides a system approach to security by isolating secure applications from non-secure applications, preventing access to or corruption of the secure applications. TrustZone is integrated into the Zynq UltraScale+ MPSoC Arm Cortex-A53 processors, extending to the PS and PL using the AXI bus. TrustZone defines secure world and normal world for a trusted execution environment and a rich operating system. For more details, see Isolate Security-Critical Applications on Zynq UltraScale+ Devices (WP516). TrustZone can be used for isolation and access control. Access control is a focus of the cryptographic module security policy, which is a security requirement described in CMVP Overview.
As an additional layer of runtime tamper protection, the AMD SecMon IP [REF 7] can be implemented in Zynq UltraScale+ MPSoCs to provide runtime protection against a variety of tamper attacks. SecMon provides clock, JTAG port, voltage, temperature, and configuration monitoring, and generates alarms if out-of-bounds activity is detected (SecMon IP also blocks the JTAG port). SecMon can respond to tamper detection by performing functions such as BBRAM key zeroization and zeroization of the device. SecMon can also take tamper input from external elements to provide a centralized system-level tamper detection and system response.
The isolation design flow (IDF) (see Isolation Design Flow for UltraScale+ FPGAs and Zynq UltraScale+ MPSoCs (XAPP1335)) is supported for static and reconfigurable PL applications with Zynq UltraScale+ MPSoCs. The IDF methodology allows the designer to logically isolate the secure from the non-secure functions implemented in the PL.