1. Structure of Xilinx ISE and Vivado Tool

In general, an FPGA consists of a configurable logic block (CLB) as a logic block, switch matrix (SM) as a connection block, and input/output block (IOB) as an input/output block as shown in Fig. 1 CLB (Fig. 1(b)) constitutes the basic block of FPGA and serves to store logic, and its structure comprises two blocks called SLICE. There are two types of SLICE, called SLICEM or SLICEL, and each CLB contains a SLICEM and a SLICEL or two SLICELs. These SLICEs include four look-up tables (LUTs), eight flip flops (FFs), a carry logic network, and three types of multiplexers (MUXs). The SM shown in Fig. 1(c) connects the BLOCKs, and the points at both ends of the rectangular or square grid are implemented in the form of a single wire. The IOB in Fig. 1(d) provides a bi-directional interface between logics inside the FPGA for IO. Xilinx includes programmable logic point (PLP), programmable interconnect point (PIP), and programmable contents point (PCP) in each block so that designers can change the internal circuit of these three types of blocks. The PLP is responsible for the logical functions of the circuit, the PIP selects the internal connections, and the PCP maintains the stored values.

Fig. 2 illustrates the bitstream generation process of Xilinx ISE tool. RTL design uses -ngd build to generate Xilinx internal netlist (NGD file). Subsequently, -map is used to convert the NGD file to NCD file for mapping. Additionally, -par places circuit primitives on the actual FPGA chip and connects each circuit primitive to create a place and routing (P&R) NCD file. Fully P&R’d primitives (P&R’d NCD file) are converted to bitstream files using -bitgen. The bit file is converted into an MCS file and stored in the external memory, PROM. The P&R NCD file can generate an XDLRC file and XDL file via -ncd2xdl to convert into a xdl file format. The description of each file is as follows.

• NGD (Native Generic Database): A file that synthesizes RTL input in binary format with a generic gate.

• NCD (Native Circuit Description): Netlist file that maps the generic gates of the NGD file to the target FPGA in binary format.

• XDL (Xilinx Design Language): A file converted binary NCD file into text format the user can read.

• XDLRC (Xilinx Design Language Routing and Configurable logic block): A file that illustrates the chip architecture of the target FPGA and all available hardware resources in text format.

• BIT (bitstream file): A file that converts an NCD file to bitstream in binary format.

• MCS (Configuration Memory file): Converted from a bit file into a form that that can be stored in an external memory.

While existing Xilinx ISE supports 6-series FPGAs, Xilinx Vivado supports the latest series such as Virtex-7, Kintex-7, and Artix-7. Although Xilinx discontinued support for the ISE design tool in 2014, ISE continues to be widely used for FPGA programming because Vivado primarily supports high-performance and advanced devices.

Fig. 3 illustrates the Vivado Design Suite bitstream generation process, including the design of RTL, synthesis, floorplan, and implementation followed by design check and bitstream generation. In the RTL design stage, designers create RTL using hardware description language (HDL) tool or high-level synthesis (HLS) tool. In the case of HDL, there is no need for additional work because it is a hardware language; however, HLS requires converting to HDL after coding in C language. When the coding design is completed, verification is performed through simulation. It does not matter if it is verified with FPGA after synthesis; however, if an error occurs, it takes longer because it needs re-checking. Following the simulation, a netlist file is generated, and design optimization and P&R are performed in the implement design stage. The tool automatically performs this process, while it can also be modified by the designer. At the final design check point, the tool can be used to check how much H/W resources the designer has used, which resources are used in which location, and how they are connected. Once all the steps are complete, the configuration bitstream generation stage creates the bitstream file containing all information on the design. The created bitstream file is stored in the external memory.

Fig. 1. Internal Structure of FPGA.

Fig. 2. Conceptual diagram of the Xilinx ISE Design Suite flow.

Fig. 3. Conceptual diagram of the Xilinx Vivado Design Suite flow.

2. Bitstream File Format

FPGAs are composed of binary files called bitstreams. The bitstream contains information on which logical elements to configure, how to implement the target design, and how to operate the FPGA. The file format of bitstream is architecture dependent; however, most FPGAs from the same vendor use the same file format. The bitstream file encrypts sensitive parts, such as actual logic data or configurate data in a specific way, for security. Xilinx's bitstream file uses bit swapping when saving configurate data.

The bitstream file format of Xilinx 7-series FPGA is the same as shown in Fig. 4. The header part contains various information about the source and contents of the entire bitstream, such as the bitstream generation date, FPGA chip name, and tool version. It is saved in Tag-Length-Value (TLV) format when a bitstream file is generated using the Vivado tool.

The bus width auto detect plays a role in determining the bus width providing configuration data, and for this purpose, a specific byte pattern is included at the beginning of the bitstream file. The configuration logic checks the lower 8 bits of the parallel bus and sets the appropriate external bus width according to the received sequence. The synchronization word (Sync word) must find configuration logic before a configuration packet can be processed by the FPGA, where the configuration logic is used to align within the 32-bit word boundary. Synchronization word of most Xilinx FPGAs is set to 0xAA995566.

Bitstream commands all Xilinx 7-series FPGAs to operate as the way of reading or writing configuration registers and are divided into two packet types. The first type of packet is used to read and write registers. In the case of the 7-series, it uses only 5 out of 14 registers addresses. The second type of packet extends the number of words field in packets of type 1. Since the address is used in the type 1 packet, the address is omitted here, but it must be used the same as the type 1 packet that delivers address information.

The addresses specified in the configuration packet are mapped to registers that provide low-level control over the chip. Not all these registers participate in the programming sequence; some participate in the programming sequence and others control the physical aspects. Key registers used during programming are as follows:

• IDCODE: A register that stores the device ID code before writing to configuration memory.

• CRC: When the device receives a packet, it automatically updates the internal CRC calculation to include the contents of the packet. The write CRC register checks that the calculated CRC matches the expected value written in the register, and if there is no error, the flag is initialized to zero. It is possible to set whether the designer will use it or not.

• command: A register that store works that can be triggered immediately by the work being requested or delayed until other conditions are satisfied.

• FAR (Frame Address Register): Set address for next frame read or write.

• FDRI (Frame): When a frame is written to the FDRI, the frame data are written to the configuration memory address specified in FAR.

Fig. 4. Bitstream file format of Xilinx 7-series FPGA.

3. Flash Memory Structure

FGPA requires nonvolatile memory that can maintain data even when power is turned off to store bitstream files. PROM, which was widely used in the past, is a nonvolatile memory that enables users to read/write contents in byte units. However, a delay of approximately a millisecond per byte occurs in the writing time. Therefore, it is infeasible to be used as a memory or stack memory to store data and variables used in real time; however, it can be used to store nonvolatile for a long time once written, so it is primarily used for reading only or for data backup. Conversely, flash memory can read freely in bytes, and the memory cell structure is simpler than PROM. So, it can be made into a mass storage, and it displays a much faster speed when writing the entire block.

Recently, most Xilinx FPGA had flash memory outside the FPGA chip, and the extracted bitstream file is stored in this external flash memory. However, bitstream files contain unnecessary data, such as headers, including file creation date and tool version, and noop (no operation), which is an unused part. Therefore, when writing a bitstream file to memory, only the actual data are saved, and unnecessary data are excluded.

Fig. 5 and 6 illustrate the structure between the FPGA chip and flash memory. Most Xilinx FPGAs are designed with similar structures. The pins of the FPGA chip are different for each FPGA; however, in the case of flash memory, most of the same flash memory is used and the pin information is the same. When the generated bitstream file is stored in flash memory, data are entered via SDI/DQ0 pin. Subsequently, when power is applied to the FPGA, data are exported via SDO/DQ1 to retrieve the bitstream file data stored in flash memory.

Fig. 5. Conceptual diagram of the Xilinx Vivado design flow (Artix-7)[17].

Fig. 6. A simplified of Xilinx Vivado design flow.

1. Trojan Attack using FPGA Security Issue

FPGA is encrypted in special patterns and methods, such as bitstream files, external memory, and IP to enhance security. Most FPGA encryption is a black box; however, many vulnerabilities are still found. There are many Trojan attacks that exploit these vulnerabilities to maliciously modify circuits or penetrate malicious code.

Cahill et al. ^[1] revealed vulnerabilities n the compile process and presents solutions. The compile tools used in the FPGA CAD process are black box systems. Moreover, the generated bitstream file is exclusive and encrypted, so the designer does not know if the bitstream file is correctly implemented. Therefore, it is difficult for the designer to know even if the manager of the tool maliciously fixes it or a bug in the tool causes sensitive data to leak and significantly affects the system.

Yoon et al. ^[2] proposed a reverse engineering tool that detects Trojan horses to compensate for vulnerabilities in Virtex-5, a Xilinx FPGA5 series. Since FPGA is reconfigurable, malicious modification is possible in both the development and deployment stages (Fig. 7). Therefore, to effectively detect Trojan horses, detection should be possible in the development stage and in the netlist and deployment stages. The proposed tool learns various Trojans using machine learning as samples to detect Trojans in both stages. Machine learning consists of a learning stage that proceeds only in the forward direction and a hardware Trojan horse detection stage that proceeds in the forward and backward directions. In the forward-only direction, only netlists containing third-party IP cores are provided, and source files specified in HDL are not provided. In the reverse direction, only bitstream files are provided, and sources and netlists produced in the development stage are not available. When learning the Trojan horse, we focus on Trojan triggers rather than the Trojan payload. Hardware Trojan payloads may vary based on functionality and target, while hardware Trojan trigger logic has unique features that prevent hardware Trojan from being easily activated and detected. Therefore, we apply the learned data to logic to find the trigger of the Trojan horse.

Speith et al. ^[3] describes the structural problems of existing IEEE 1735. Specifically, IEEE 1735 uses a digital envelope to protect the IP itself and the rights granted by the IP author. Therefore, a unified format is specified for the protected IP to ensure security and compatibility between standard specifications and tools. The structure of a digital envelope contains parts that specify access rights and additional attributes, and parts that include encrypted real IP data, which are encrypted using the Session Key. The part that specifies access rights and additional attributes consists of a common block that grants permission to all supported tools and a tool block that grants permission to a specific tool. This encryption structure designs an attacker that can fully control the EDA tool execution environment based on the existing Man-at-the-End (MATE) attack model ^[6]. In the design of the attacker, the symmetric session key is decrypted using the RSA private key within the digital envelope of the IP. Subsequently, the session key is used to decrypt the protected IP data. An attacker designed this way can completely analyze the EDA tool software and manipulate and extract values during execution. Protected IPs of FPGAs can be attacked, decrypted, and maliciously modified and reconfigured in a short time using the IEEE 1735 encryption structure. The method targets the EDA tools of representative companies in the FPGA market, such as Inter Quartus Prime, Cadence Xcelium, Lattice Radiant, Microsemi Libero SoC, Siemens Medelsim, and Xilinx Vivado Design Suite. The vulnerabilities for each EDA tool are as follows.

Intel Quartus Prime searches program memory for documented RSA key names to identify the interest Dynamic Link Library (DLL) at runtime. The identified DLL provides only IEEE 1735 encryption and includes a portion containing public keys from other vendors and symbols supporting the reverse engineering process by providing human-readable names to library functions. It automatically searches using key\_keyname to identify the encrypted subroutine. According to IEEE 1735, the key\_keyname is located before the actual key identifier within the digital envelope. It prepares the assembly key by analyzing a string reference, and an RSA private key for decryption. Publishing the RSA private key is straightforward because the private key is only protected by the XOR of two hard-coded byte arrays.

Cadence Xcelium is a logic simulation-based verification tool. To identify the target keys of Cadence, refer to the user guide document to identify the two target keys. One of them is the now obsolete 512-bit RSA key. Owing to the availability of symbols and the absence of code obfuscation, automatic scanning of executables for documented RSA key names reveals target functions. When a function is called, it calls one of two other functions depending on the selected encryption key. The function returns a static memory address pointing to the private key, all stored in plaintext. Therefore, it is relatively simple to reverse engineer and recover RSA private keys.

Latice Radiant automatically searches the documented key name again and identifies the target library ^[20] to find a function that loads the security key. A reference to the caller of the corresponding function is followed to extract the RSA private key from the decryption context. The searched decryption function then calls the RSA decryption function provided by OpenSSL. Subsequently, it inserts a custom code that triggers decryption of the target private key and extracts the RSA private key from the OpenSSL decryption at runtime.

In the Microsemi Libero SOC, automatic scanning of RSA key names represents 2048 bits of RSA private key in program memory. However, there is no access right to the encrypted IP or its RSA public key. Therefore, we execute Microsemi Libero SoC, import the manufactured IP, execute the RSA decryption routine, and verify the behavior at runtime. Consequently, we confirmed that Libero SoC first supplies encrypted soft IP to the synthesizer to generate synthetic and re-encrypted IP at the netlist level. Additionally, the Libero SoC itself interacts with encrypted files via a dedicated executable file and is dynamically linked to DLLs with a code obfuscation function in this executable file. This complexity invalidates all anti-debugging measures that protect DLLs using ScyllaHide ^[21]. Moreover, it uses integrity checks across the library to prevent software breakpoint insertion and uses hardware breakpoint to invalidate this protection. The RSA encryption session key is found in the memory when it is passed as an input to a function called very close to the searched RSA key name.

Siemens ModelSim is generally bundled with other EDA tools and encrypted IPs for these tools include additional tool blocks for ModelSim. Therefore, extracting private RSA keys from Siemens ModelSim is fatal to other FPGA vendors. Since the encryption function cannot be identified within the main ModelSim executable file, so we connect the debugger and trace all subprocess calls. Therefore, it identifies the subprocess processing the decryption of the protected IP, as shown in the console output. Moreover, static analysis is used to check if encryption libraries within this subprocess are used; however, it cannot check all cryptographic functions. Therefore, we match the file name and line number with the implementation of the open-source encryption library to identify the missing encryption function. To recover session keys, we reconstruct the white box algorithm with high-level language so that the oracle executes the white box decryption. As a result, we found three separate RSA key pairs, two 1024 bits, and one 2048 bits pair. These RSA keys use the same decryption routine. Given the white box data associated with each key, the protected IP can be decrypted without knowledge of the key.

Fig. 7. System overview[2].

2. Reverse Engineering

While comprehensive review of general reverse engineering techniques was studied in ^[8], this paper focuses on exploring more recent reverse engineering approaches which were applied to the latest FPGAs based on the Vivado design suite. Choi et al. ^[7] analyzed the mapping relationship between FPGA primitives and FPGA hardware resources targeting Xilinx Spartan-3 FPGA and proposes reverse engineering using them. Generally, FPGAs provide a primitive library written in HDL for easy RTL implementation. In the case of the target, ROM of Xilinx XC3S50, there are five types of primitive libraries, as shown in Fig. 8. To analyze FPGA hardware resources, it analyzes all bitstreams generated by synthesizing and implementing each ROM primitive library. Analysis of the generated bitstream is as follows.

• Bitstream generation for each primitive

• ROM location search

• Extract ROM data for target bitstream

• ROM data rearrangement

Through the above steps, it is revealed that all ROMs are internally assigned to SLICE's LUTs, and the ROM data of the S-BOX are completely recovered using the most widely used algorithm, advanced encryption standard (AES). Additionally, the proposed reverse engineering can be applied to all types of primitive libraries.

Zhang et al. ^[13] proposed a new FPGA reverse engineering toolchain. It compiled an integrated database containing FPGA architecture information and bitstream mapping information. Two tools were developed: Bitstream Reversal Tool (BRT) and Netlist Reversal Tool (NRT). It can search for RTL code in FPGA bitstream using two tools.

The proposed toolchain includes all reverse engineering from bitstream to netlist and from netlist to code without the support of other tools. The overall reverse engineering is shown in Fig. 9. Connect the configuration lines of the PCB (Print Circuit Board) and apply power to the target FPGA. Hijack when FPGA reads bitstream from external non-volatile memory. The obtained bitstream is then supplied to the toolchain. Our BRT, supported by the database containing FPGA architecture information and bitstream mapping information, decompiles the bitstream into a netlist, and then NRT converts the netlist into RTL code. Using this reverse engineering method, the netlist is restored to 100%. However, there is a limitation in that the encrypted bitstream file cannot be applied.

Yu et al. ^[16] revealed that the bitstream file swaps in a certain pattern and proposes a method of extracting a complete circuit by combining signal connection data of programmable interconnect point (PIP) after identifying the pattern. In the Vivado tool, the logic is generated with a MUX and converts the input to the LUT into an output signal. The LUT is set as default; however, the user can use the LUT at the desired location. Therefore, the configuration position of each LUT can be determined by analyzing the bitstream generated by the LUT. LUT is written in a specific order at intervals of 404 bytes and is written in units of 2 bytes at a time. When power is supplied to the FPGA and the use of the LUT is activated, a total of 8 bytes are extracted in units of 2 bytes at intervals of 404 bytes based on the active start bit. A specific pattern was found in the extracted data. Accordingly, a 100% restoration rate was achieved using an in-house tool.

Fig. 8. Implementation S-box of AES on FPGA.

Fig. 9. An overview of reverse engineering flow[13].