Introduction - Introduction - XAPP1098

AMD has been at the forefront of providing FPGA AT solutions to their customers for many generations. UltraScale and UltraScale+ FPGAs continue this trend by including asymmetric authentication, side channel attack protection, and other silicon AT features. Additionally, to provide a number of tamper protections post configuration, AMD offers an IP core known as Security Monitor (see Security Monitor Product Brief). Due to certain restrictions, Security Monitor’s availability is limited. Contact your local AMD representative for details.

Keeping one step ahead of the adversary is a continuous process that involves understanding the existing vulnerabilities and attacks and then developing new mitigation techniques (countermeasures) to combat those attacks. AMD has a multi-generational commitment to secure FPGA technology in a cost-sensitive manner for the AT-conscious communities which include both commercial and defense markets.

By taking advantage of various AMD FPGA AT features, you can choose how much AT to include with the FPGA design based on program and customer requirements. AT can be in the form of enabling individual silicon AT features or a combination of these AT features (perhaps tied together by the developer in the FPGA design and following best practice guidance).

The decision as to how much AT to include primarily depends on three factors:

Value

The perceived value of the intellectual property and the damage it might cause either financially or to national security if it were to become compromised. Certain AT features can be expensive to implement and that cost must be weighed against the value of the technology or data being protected.

Adversary

Access to the system and the sophistication level and resources available to carry out the attack. For example, can access to the system be prevented by “guns, gates, and guards” or can it be easily obtained in the open market? Is the adversary a garage-based hacker or a nation-state? The adversary’s capabilities could be at these extremes or anywhere in-between.

Design stage

The point in the system development cycle where the decision is made to enable AT for the FPGA design. AMD highly recommends that the decision to use FPGA AT features is made very early on (that is, after CT is defined in a system) to help address both schedule and cost concerns. It is always more costly, more time consuming, and often less effective to insert AT features later on in the development process.

Another factor that needs to be considered is how much of the FPGA’s logic resources are consumed by enabling certain active AT features. The overall resource penalty is usually rather small. However, it does depend on how these features are implemented and the size of the FPGA (that is, the larger FPGAs experience less of an impact).

AMD classifies the silicon AT features as either passive or active security. In general, passive security features are those that are either part of the tool flow or built into the FPGA and do not require you to do anything extra in your FPGA logic design. Passive security features are also temporal in nature—they come into effect at different times during the normal life cycle of the FPGA:

• Pre-configuration (for example, public key authentication of the configuration bitstream)
• During-configuration (for example, resistance to side-channel attacks via differential power analysis (DPA))
• Post-configuration (for example, user data protection via disabling of readback)

In contrast, active security features are required to be included in the FPGA logic design. These features only come into effect after the FPGA has been configured via the user bitstream and the design becomes active. Examples are asserting KEYCLEARB to zeroize the battery-backed advanced encryption standard (AES) key or handle a PROGRAM_B intercept.

At a bare minimum, you should always plan on including the appropriate passive security features into your design (for example, bitstream encryption and authentication). These features do not affect the function of the design. However, they might create logistical challenges (for example, key management), system challenges (for example, a battery is needed if using battery-backed RAM (BBRAM) for key storage), and increase the configuration time (for example, public key authentication might increase configuration time). Otherwise, these features are freely available in terms of impact to the design and can provide a fair amount of tamper protection. For an already fielded system or a design late in the development stage, these AT features are great candidates for enabling because they do not affect the actual FPGA logic design.

Additionally, the AT features and guidance presented in this application note fall into three main AT categories:

• Prevention (for example, JTAG port blocking)
• Detection (for example, voltage and temperature monitoring)
• Response (for example, BBRAM key erasure penalty)

The following table summarizes and classifies the built-in silicon AT features of the UltraScale and UltraScale+ FGPAs.

The following sections explore the above features in depth, providing detailed explanations on what they are, why they exist, and give specific examples on how to properly use them (either by themselves, with other built-in features and user logic, or both). Additionally, specific guidance is given on certain methods and techniques that can be employed to increase the tamper resistance of the FPGA design and overall system.

Any AT features enabled at the FPGA level should always be part of an overall system-level AT solution. The features and techniques outlined in this document provide for a very good AT “umbrella” for the FPGA itself. However, AT is most effective when it is developed with a multi-layer approach with the entire system always in mind.