IEEE PAPER summary and critique.

IEEE PAPER summary and critique.

Bitstream Fault Injections (BiFI)–Automated Fault Attacks Against SRAM-Based FPGAs

Pawel Swierczynski , Georg T. Becker , Amir Moradi, and Christof Paar, Fellow, IEEE

Abstract—This contribution is concerned with the question whether an adversary can automatically manipulate an unknown FPGA

bitstream realizing a cryptographic primitive such that the underlying secret key is revealed. In general, if an attacker has full knowledge

about the bitstream structure and can make changes to the target FPGA design, she can alter the bitstream leading to key recovery.

However, this requires challenging reverse-engineering steps in practice. We argue that this is a major reason why bitstream fault

injection attacks have been largely neglected in the past. In this paper, we show that malicious bitstream modifications are i) much

easier to conduct than commonly assumed and ii) surprisingly powerful. We introduce a novel class of bitstream fault injection (BiFI)

attacks which does not require any reverse-engineering. Our attacks can be automatically mounted without any detailed knowledge

about either the bitstream format or the design of the crypto primitive which is being attacked. Bitstream encryption features do not

necessarily prevent our attack if the integrity of the encrypted bitstream is not carefully checked. We have successfully verified the

feasibility of our attacks in practice by considering several publicly available AES designs. As target platforms, we have conducted our

experiments on Spartan-6 and Virtex-5 Xilinx FPGAs.

Index Terms—FPGA security, bitstream fault injection, automated key recovery, AES, bitstream encryption vulnerability



FPGAS are used in a wide range of applications and sys-tems, e.g., in automotive, communications, computer networks, avionics, defense and many other industries. Since many of these applications require security, they need cryptographic primitives as building blocks for serv- ices such as integrity, authenticity, and confidentiality. Methods of how to attack cryptographic implementations and how to secure them have been studied for a long time in the scientific literature. As one of the earlier references, Boneh et al. [1] demonstrated in 1997 that the RSA public- key scheme as well as authentication protocols are vulner- able to fault injections. The idea is to exploit transient hardware faults that occur during the computations of the cryptographic algorithm. Due to the injected faults, faulty intermediate values may propagate sensitive information to the output revealing the private key. This concept was extended by Biham and Shamir [2] – known as Differential Fault Analysis (DFA) – to recover the secret key from sym- metric block ciphers such as DES. In 2003, Piret and Quis- quater [3] introduced a sophisticated fault model for AES which enables an attacker to recover the secret key with only two faulty ciphertexts.

In the last two decades, numerous other implementation attacks on hardware have been proposed, including power and EM side-channel attacks [4], glitch-based fault attacks [5], [6], laser fault attacks [7] and photonic emission attacks [8], each of which require different expertise and equipment. For a classification of fault injection attacks, we refer to contribution [9]. Notably, all proposed methods have in common that they cannot be executed automatically for different designs. They always require an experienced engineer to adjust the attack to each new target that may become a time-consuming task in a black-box scenario. Moreover, the majority of these attacks are generic hard- ware attacks, i.e., they do not exploit the specific nature of field programmable gate arrays.

An alternative attack strategy is to attempt to directly read-out the key from a non-volatile memory or the bit- stream. However, this is often a very difficult task. The keys may be stored externally (e.g., in a hardware security mod- ule), hard-coded in an obfuscated manner in the bitstream or can be internally derived using a Physical Unclonable Func- tion (PUF). Due to the proprietary bitstream file formats that dominate the industry and hardware architecture which are often complex, any direct read-out attempt of the key from the bitstream seems rather difficult. It should be noted that recovering the entire netlist from aXilinx FPGAdesign is nei- ther trivial nor completely possible, cf. [10]. For more infor- mation about the FPGA security, see [11] and [12].

In this paper,we introduce a new strategy to efficiently and automatically extract secrets from FPGA designs which we coin bitstream fault injection (BiFI) attack. The goal is to reduce the required expertise as well as the engineering hours. Instead of reverse-engineering an FPGA design, we manipulate an unknown bitstream without any knowledge of the design resulting in faulty ciphertexts. These faulty ciphertexts

� P. Swierczynski, A. Moradi, and C. Paar are with the Horst G€ortz Insti- tute for IT Security, Ruhr-Universit€at Bochum, Bochum 44801, Germany. E-mail: {pawel.swierczynski, amir.moradi, christof.paar}

� G.T. Becker is with the Digital Society Institute (DSI), ESMT, Berlin 10178, Germany. The work was conducted while he was with the Ruhr- Universit€at Bochum, Bochum 44801, Germany. E-mail:

Manuscript received 20 June 2016; revised 27 Oct. 2016; accepted 16 Dec. 2016. Date of publication 8 Jan. 2017; date of current version 16 Feb. 2018. Recommended for acceptance by R. Lee, P. Chaumont, R. Perez, and G. Bertoni. For information on obtaining reprints of this article, please send e-mail to:, and reference the Digital Object Identifier below. Digital Object Identifier no. 10.1109/TC.2016.2646367


0018-9340� 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See ht _tp:// for more information.

can then be used to recover the secret key. The general idea that onemight recover secret keys bymanipulating bitstreams without reverse-engineering was first mentioned in [13], but no concrete attack was proposed and it remained unclear if such an attack is feasible in practice. In this paper we not only show that such attacks are indeed feasible, but also that they are much more powerful than assumed. A surprising large number of bitstream manipulations result in exploitable faulty ciphertexts. A key finding of our analysis is that it is not necessary to make targeted manipulations based on knowl- edge of the target design. Instead, a set of design-independent manipulation rules can be applied automatically to different regions of the target bitstream until the attack succeeds. Thus, one only needs to develop an attack tool once and can apply it to any design that implements the same cryptographic algo- rithm. Crucially, no FPGA reverse-engineering expertise is needed to perform the BiFI attack on different targets.We ver- ified the feasibility of the attack with 16 different AES imple- mentations on a Spartan-6 FPGA. Out of those, 15 designs could be successfully attacked with BiFI in an automated fashion.

While it might be tempting to think that bitstream encryption can prevent BiFI attacks, this is not necessarily true. Already in [13] it was noted that bitstream manipula- tions might be possible in theory on encrypted bitstreams if no integrity check is used. However, it was also noted that the CRC feature as it is implemented in Virtex-2 through Virtex-5 FPGAs should prevent bitstream manipulation attacks such as BiFI. In this paper, we show for the first time that it is possible to apply BiFI to encrypted bitstreams. We demonstrate this by successfully attacking 12 out of 13 AES cores on a Virtex-5 FPGA with enabled bitstream encryp- tion. Hence, bitstream encryption in combination with a CRC feature is not necessarily enough to stop BiFI attacks.

1.1 Related Work

Reverse-engineering the proprietary bitstream structure of FPGAs has been the focus of several works [10], [14], [15], [16], [17]. It was shown by Ziener et al. that reverse-engi- neering LUT contents in an FPGA bitstream is relatively easy for Virtex-II FPGAs [17]. It has also been demonstrated how to recover LUT contents from a bitstream file [16]. However, reverse-engineering all elements in an FPGA including routing information is considerably harder as stated by Benz et al. [14]. The best results in the open litera- ture were achieved in 2013 by Ding et al., where between 87 percent and close to 100 percent of the routing of target designs were reverse-engineered [10]. Hence, we conclude that while reverse-engineering LUTs is rather simple, reverse-engineering the entire bitstream is considerably more challenging.

There are very few works that discuss the manipulation of non-encrypted bitstreams. It has been recently shown how to weaken a cryptographic primitive to leak a key by altering a bitstream [16]. The targets were AES designs that use a table-lookup implementation of the S-box. The authors showed how to automatically detect correspond- ing LUTs or BRAMs which realize the AES S-boxes, and fix the truth table outputs to zero. This enables a key recovery requesting one response. Similarly, Aldaya et al. proposed to modify the BRAM content of AES implementations

based on T-tables, cf. [18]. Both of these attacks have in common that they target a specific design-dependent part of the employed cryptographic algorithm, which might be missing in other implementations. It was later demon- strated how a Trojan can be realized in practice by manipu- lating the bitstream of the FPGA used in a commercial USB flash drive offering user data encryption [19]. Even though this shows that bitstream manipulations are feasible in practice, it is design-dependent and requires major efforts. In contrast to these works, the BiFI attack is much more general and targets a wide range of possible designs with many different implementation styles. Furthermore, in contrast to all previous works, BiFI (up to some extent) can still deal with encrypted bitstreams.

We should stress that while most research in the areas of fault attacks focus on transient faults in the processed data, our attack targets permanent faults in the control logic. In our experiments, most designs could be attacked with only one faulty ciphertext. In many cases, neither the plaintext nor the fault-free ciphertext are required.


This section gives a brief overview of the different building blocks of an FPGA and also provides the assumed attack and system model.

2.1 FPGA Building Blocks

One of the most important building blocks in FPGAs are look-up tables (LUTs). Small truth tables (commonly either 16 or 64 bits wide) implement together with multiplexers the combinatorial logic of a design. They can realize simple gates such as an AND or XOR, but can also implement more general Boolean expressions. LUTs are truth tables with one output bit, cf. Fig. 1.

Besides LUTs and multiplexers, FPGAs consist of D-flip- flops, BRAM blocks, DSPs and other resources that define the wiring between these building blocks. They can be con- nected with millions of wires to form a complex circuitry. The entire configuration of these elements is described in the binary bitstream file. LUTs, being the main logic ele- ments in most modern FPGAs, are used for a multitude of tasks like storing constants, processing input signals, sav- ing/loading data from flip-flops, copying signals from one location to another, controlling data buses or writing/load- ing BRAM contents. Given that LUTs play such a key role in FPGA designs, they are a particular interesting target for bitstream manipulation attacks.

Since we will later introduce various LUT modification rules in the bitstream, we first provide some low-level back- ground information on how LUTs are used in most Xilinx FPGAs. An FPGA area is virtually divided into several Configurable Logic Blocks (CLB), each of which consists of – usually four – so-called slices. One slice includes various

Fig. 1. On the left a 6-to-1 LUT with 6 input bits and 1 output bit is depicted. The LUT is a truth table T with 64 entries that is stored in the bitstream (right side).


flip-flops, multiplexers, and input/output pins which are interconnected to a switch-box. It also offers four native 64- bit LUTs. Fig. 2 illustrates a simplification of the most com- mon slice configurations. Note that we ignored some hard- ware elements such as flip-flops and switch-boxes for the sake of simplicity.

Each 6-bit LUT can implement one out of 264 possible 6 7!1 Boolean functions, cf. configuration (a) in Fig. 2. Alterna- tively, each 64-bit LUT can be split into two 32-bit subtables in order to realize two different 5 7!1 Boolean functions with shared inputs, cf. configuration (b) in Fig. 2. Two (resp. four) LUTs within one slice can also be combined to use larger truth tables with 128 bits (resp. 256 bits) to realize 7 7!1 (resp. 8 7!1) Boolean functions, cf. configuration (c) and (d) in Fig. 2.

2.2 System Assumptions and Adversary Model

In the following, we describe a generic system model for SRAM-based FPGA systems which can be often found in various practical applications. Additionally, we describe our adversary model. SRAM-based FPGAs employ volatile memory, thus they require an external (usually untrusted) storage, e.g., a flash or EEPROM chip that stores the bit- stream file. It needs to be loaded upon each power-up of the FPGA, cf. Fig. 3.

As described above, many modern applications call for cryptographic primitives to be realized on FPGAs. In this system model, we target particular designs where encryp- tion/decryption algorithms (e.g., AES) are implemented. It is assumed that the key is not directly accessible to the adversary. For example, it is encoded or obfuscated in exter- nal memory, stored in a secure on-chip memory, hard- coded in the design/bitstream, or generated internally by a PUF. We furthermore assume that the attacker can query the AES implementation (with either known or chosen plaintexts) and observe the ciphertexts. However, in many cases we need to observe only one faulty ciphertext.

Like most implementation attacks (either side-channel or fault-injection), our attack requires physical access to the target FPGA, an assumption which is often given in prac- tice. We suppose that the adversary has read- and write- access to the external memory which stores the bitstream of the target device. Consequently, he can arbitrarily modify the bitstream, and observe the behavior of the FPGA accord- ingly. More precisely, we suppose that the attacker is able to extract and modify the content of LUTs in the target

bitstream. To achieve such an ability we refer to [16], where the corresponding techniques are described.


The first step of the attack is to read out the bitstream of the device under attack from the non-volatile memory or by wiretapping the configuration data bus. The attack tool then repeatedly i) manipulates the bitstream by changing some LUT contents, ii) configures the target device, and iii) queries the manipulated design to collect faulty ciphertexts.

The faulty ciphertexts that are collected in this way are then used to recover the key by testing a set of hypotheses, e.g., the hypothesis that the collected faulty ciphertext is simply the plaintext XORed with the key. However, there are several LUTs in even small FPGAs, and testing all possi- ble modifications on all LUT bits is not practically feasible. Therefore, we try to reduce the space for manipulations by defining particular rules in such a way that the faulty cipher- texts can be still used for key recovery.

3.1 Manipulations Rules

All of the conducted manipulations target the LUTs of the FPGA, i.e., only the combinatorial logic of the design is changed. Let LUTi be the i

th occupied LUT of n available LUTs on the target FPGA. A LUT is a 64-bit truth table T

that implements a Boolean function y ¼ fðxÞ with x 2 f0; 1g6 and y 2 f0; 1g. Let us denote the jth binary ele- ment in this truth table as T ½j� with 0 � j � 63. As stated before, we suppose that the location of the truth table in the bitstream for each LUT is known to the attacker, and hence he can directly modify any single bit of this truth table.

With T as the original truth table and its corresponding manipulated truth table ~T , we define three basic operations:

(1) Clear: ~T ½j� ¼ 0, 8j 2 f0; . . . ; 63g (2) Set: ~T ½j� ¼ 1, 8j 2 f0; . . . ; 63g (3) Invert: ~T ½j� ¼ T ½j� � 1, 8j 2 f0; . . . ; 63g,

and accordingly we define three manipulation rules as

� R1½i�=R2½i�=R3½i� : Clear/Set/Invert the ith 64-bit LUT,

which cover the cases where the entire LUT forms a 6 7!1 function, cf. configuration (a) in Fig. 2.

Besides modifying the entire LUT, we also consider the cases where only the upper or lower half of the LUT is manip- ulated. As an example, we can form ~T by

� ~T ½j� ¼ 1, 8j 2 f0; . . . ; 31g � ~T ½j� ¼ T ½j�, 8j 2 f32; . . . ; 63g.

Fig. 2. Subset of the most commonly used possible slice configurations with focus on look-up tables.

Fig. 3. Overview of system model. A proprietary bitstream file imple- ments an unknown AES circuit, which configures an SRAM-based FPGA once it is powered-up. It then provides an AES interface to any possible real-world application.


In other words, we only modify the upper half (first 32 bits) of the truth table. The motivation of considering these operations is due to the cases where a LUT realizes a 5 7!2 function, cf. configuration (b) in Fig. 2. Hence we define three other rules as

� R4½i; h�=R5½i; h�=R6½i; h�: Clear/Set/Invert the hth half of the ith LUT.

To cover other two configurations-case (c) and (d) in Fig. 2, where two or four LUTs are grouped to form larger truth tables, we define the next four rules as

� R7½i�=R8½i� : Clear/Set all 4 LUTs within the ith slice.

� R9½i; h�=R10½i; h� : Set/Clear (h ¼ 1) upper or (h ¼ 2) lower 2 LUTs within the ith slice.

Let us define the Hamming weight of the content of all 4 LUTs within a slice by HW . Accordingly we define two rules as

� R11½n�; R12½n� : Clear/Set all 4 LUTs within slices withHW ¼ n,

with n 2 f1; . . . ; 256g. In other words, by these rules we clear/set all slices that have a specific Hamming weight. The motivation for these rules is to potentially alter multiple instances of the same Boolean function simultaneously. This may result in manipulating all instances of the same S-Box in the design at once.

Based on our observations, the LUTs of the control logic that examine whether a counter (e.g., AES round counter) reaches a certain value (e.g., to issue a done signal) have a considerably low or high HW. In other words, the content of such LUTs have a high imbalance between the number of ‘1’s and ‘0’s. As an example, a LUT with 4 inputs c3c2c1c0 which checks whether c3c2c1c0=1010 (10dec as the number of AES-128 rounds) has HW=1. Therefore, we consider the following rules accordingly

� R13½i; j� : Invert bit T ½j� of the ith LUT, if 1 � HW � 15,

� R14½i; j� : Invert bit T ½j� of the ith LUT, if 49 � HW � 64.

Finally, we cover the case where a LUT is replaced by a random Boolean function (in our experiments we applied this rule 10 times to each LUT):

� R15½i� : Set the ith LUT to a random 64-bit value.

3.2 Key Recovery

By applying any of the above-explained rules (R1 �R15), we have hit control logic and/or data processing part if a faulty ciphertext is observed. All collected faulty cipher- texts potentially exhibit a sensitive intermediate value allowing for key recovery. Hence, all faulty ciphertexts are further processed depending on which intermediate value hypothesis (H1 �H11) is tested to derive a set of AES key candidates. All those derived AES key candidates are then automatically tested by a C++ tool with the help of one valid plaintext-ciphertext pair ðp; cÞ.

In practice, an adversary can check whether the compu- tation AES�1keycandidateðcÞ outputs the known plaintext p.

Given this is true, the tested AES key candidate is equal to the correct AES key k. A known plaintext-ciphertext pair ðp; cÞ can for example be obtained from our encryption ora- cle itself or the attacker might know part(s) of the plaintext, i.e., due to constant header information. In cases where no plaintext-ciphertext pair is available (p unknown, encryp- tion can be invoked, ciphertext c observable), an adversary may also analyze the entropy of decrypted ciphertexts, e.g., if the decryption yields text which typically has a low entropy.

To understand our key recovery approach, we use the following notations for the AES computation:

� p; k; c; ~c : 16-byte plaintext, key, ciphertext, and faulty ciphertext with c ¼ AES128kðpÞ.

� 0128: 128-bit value consisting of all 0’s. � rkj : 16-byte jth round key with j 2 f0; . . . ; 10g with

rk0 ¼ k. � SBðstÞ; SRðstÞ;MCðstÞ : SubBytes, ShiftRows, and

MixColumns operations on the current 16-byte state st. Analogously, SB�1ðstÞ; SR�1ðstÞ, and MC�1ðstÞ represent the respective inverse functions.

� sbj; srj;mcj; kaj: 16-byte state after SubBytes, Shif- tRows, MixColumns, and KeyAdd operations respectively at round j.

Based on our observations, in several cases the key can be extracted without knowing the corresponding ciphertext. We hence define the following hypotheses:

� H1½j� : ~c ¼ rkj � H2½j� : ~c ¼ SBð0128Þ � rkj,

for j 2 f0; . . . ; 10g. The hypothesis H1 mainly deals with those cases where the state st becomes 0128. Further, H2 tar- gets those faults which hit the control logic in such a way that the S-box input register becomes always inactive. We give a more detailed information about this concept in Section 5.1.3. If only one round key rkj is extracted, the main key can be easily recovered (e.g., see [20]). As a side note, these hypotheses should be also examined on the invert of the faulty ciphertext ~c.

Further, we consider the following hypotheses:

� H3½j�: ~c ¼ c� rkj � H4: ~c ¼ ka9 � H5: ~c ¼ sb10 To recover the key using H3 is straightforward as

rkj ¼ ~c � c. Hypotheses H4 and H5 check the depen- dency between the faulty ciphertext and the state in the last AES round. With hypothesis H4 the last roundkey rk10 can be recovered: rk10 ¼ SR ðSBð~cÞÞ � c. A similar approach can be followed for hypothesis H5. The next set of hypotheses are defined as:

� H6½j�: ~c ¼ p� rkj � H7: ~c ¼ sr1 � H8: ~c ¼ sb1 � H9: ~c ¼ mc1 � H10: ~c ¼ AESk0 ðpÞ � H11: ~c ¼ SRðSBðpÞÞ � rk10,

where k0 is defined as rk00 ¼ rk0, and rk0j2f1;…;10g ¼ 0128. Using H6 is straightforward. H7, H8, and H9 can also be


checked by applying the corresponding inverse functions, e.g., rk0 ¼ SB�1 SR�1 MC�1 ~cð Þð Þð Þ � p forH9.

To examine H10, we need to apply a specific form of the decryption function as rk0 ¼ AES�1k00 ð~cÞ � p with 8j 2 f0; . . . ; 10g; rk00j ¼ 0128. Hypothesis H11 can be seen as an AES encryption where only the last round is executed. In this case, the last round key can be trivially computed with rk10 ¼ ~c� SRðSBðpÞÞ.

In each of the above hypotheses only one faulty cipher- text is used. One can also define hypotheses that used two faulty ciphertexts generated by two different bitstream manipulations for a certain plaintext. As an example, ~c1 ¼ kaj and ~c2 ¼ kajþ1, which can lead to a full key recov- ery. In this scenario, the adversary needs to try all possible combinations between different faulty ciphertexts, and the computation complexity of the attack increases quadrati- cally. Since it is – to some extent – in contradiction with our goal (i.e., limiting the number of rules as well as the hypoth- eses for key recovery), we omit the corresponding results although we have observed such successful cases in six designs in our experiments.


For practical evaluations, we collected 16 AES encryption designs D0; . . . ; D15, four of which were developed by our group. The other 12 cores have been taken from publicly- available websites, e.g., NSA homepage, OpenCores, GitHub, SASEBO project.1

Most of the designs (D0, D2 �D4, D6, D9 �D15) operate on a round-based architecture. D1 is based on a word-based architecture, where 32-bit blocks are processed at each clock cycle. D7 and D8 follow a serialized architecture, i.e., with only one instance of the S-Box, where at each clock cycle one byte is processed. Finally, D5 is an unrolled pipeline design with 10 separately instantiated round functions, which can give one ciphertext per clock cycle if the pipeline is full.

Each core is provided by an interface to set the key k and the plaintext p, and to fetch the ciphertext c. We developed an FPGA design template to play the role of an RS-232 inter- face between a PC and the target AES core, where the key is kept constant by the template. During the integration of any of the target AES cores, we did not modify the AES cir- cuitry, but adopted the template to fit to the sequences required by the underlying AES interface. As an example, some of the AES cores require first to perform a key sched- ule, while the others process the actual encryption and key schedule in parallel.

In order to perform the attacks,we developed a program to automatically apply all the rules R1-R15 given in Section 3.1 one after each other. To this end, our tool first queries the orig- inal design with a particular plaintext and captures the fault- free ciphertext ðp; cÞ. Afterwards, for each rule our toolmanip- ulates the bitstream accordingly, configures the FPGA, queries the design with the same particular plaintext p and collects the corresponding faulty ciphertext ~c. Another pro- gram (which we have also developed) examines all the hypothesesH1-H11 described in Section 3.2 by analyzing each faulty ciphertext.

4.1 Results without Bitstream Encryption

Our setup is based on a Spartan-6 (XC6SLX16) FPGA, where the JTAG port is used for configuration. The entire bitstream manipulation, configuration, query and collection of the faulty ciphertext takes around 3.3 seconds. We should emphasize that by manipulating the bitstream, the Cyclic- Redundancy-Check (CRC) checksum should be correct [16]. Alternatively, the bitstream can be modified in such a way that the CRC check is simply disabled.

As stated before, we conducted our attack on 16 different designs. The corresponding results are depicted in Table 1 indicating which manipulation rule R1-R15 on which AES design D0-D15 led to an exploitable faulty ciphtertext. Simi- larly, Table 2 shows for each AES design which hypotheses H1-H11 led to successful key recovery.

For all designs, except the unrolled pipeline one (D5), at least one hypothesis could make use of the faulty cipher- texts generated by the manipulation rules to recover the key. In Section 5.1 we give a detailed analysis on the exploitable faults. In short, many exploitable faults hit the control logic (i.e., the AES state machine is modified). We predict this to be the reason why the design D5 cannot be successfully attacked, since the unrolled pipeline design makes use of the simplest state machine.

It can be seen from Table 1 that many different manipula- tions rules lead to exploitable faulty ciphtertexts. It is also worthmentioning that eachmanipulation rule was successful for at least one design. To compare the efficiency of themanip- ulation rules, we computed a ratio between the number of performed bitstream manipulations and the number of exploitable faults, cf. Fig. 4a. Note that a lower ratio means that the underlying manipulation rule is more efficient, since the average number of manipulations required for an attack becomes smaller. As stated before, eachmanipulation rule led to at least one exploitable faulty ciphertext. However, some of them are more efficient than the others. Themost efficient one isR7 (i.e., clear an entire slice), andR13 andR14 are among the worst manipulation rules. On the other hand, we should emphasize that in R13 and R14 each bit of the target LUT is independently manipulated. Hence, the number of manipu- lated bitstreams in these two rules is considerably higher com- pared to the other rules.

Wewould like to stress that in average every 3,227 random manipulations (R15) led to an exploitable faulty ciphertext (cf. Fig. 4a) indicating that it is also a solid strategy. Nevertheless, manipulations rules R1-R12 are a bit more efficient than ran- dom manipulations with an average 1,971 manipulations required to observe an exploitable faulty ciphertext.

As stated before, the entire manipulation, configuration, and query takes around 3.3 seconds. Hence, in average 1971� 3:3 ¼ 1:8 hours of bitstream manipulations are needed per exploitable faulty ciphertext for rules R1-R12. However, this time varies significantly depending on the targeted design. Fig. 4b shows the average time of bitstream manipulations (over manipulation rules R1-R12) needed for an exploitable fault for each of the 16 AES designs.

4.2 Experimental Setup with Bitstream Encryption

To prevent reverse-engineering and IP-theft some FPGAs are equipped with so-called bitstream encryption. We also investigated to what extent the above-presented attack can

1. D0 [21], D1 [22], D2 [23], D4 [24], D5 [25], D6 [26], D10 [27], D11-D15 [28].


be efficient when the underlying bitstream is encrypted. To this end, we take a closer look at this feature integrated in several Xilinx FPGAs.

When this protection mechanism is enabled in the ven- dor’s software, the user can chose a 256-bit AES key k as well as a 128-bit initial vector IV . Excluding the header, the main body of the bitstream is encrypted using AES256kð�Þ in Cipher Block Chaining (CBC) mode. The corresponding bitstream data of size m is divided into n 16-byte plaintext blocks with P

i2f1;…;m16 g , and sequentially encrypted as

Ci ¼ AES256kðPi � Ci�1Þ; for i > 0 and C0 ¼ IV: (1) Analogously, the decryption is performed by a dedicated hardware module on the FPGA as

Pi ¼ AES256�1k ðCiÞ � Ci�1; for i > 0 and C0 ¼ IV: (2) The key needs to be programmed once into the target FPGA either in its volatile (BBRAM) or non-volatile mem- ory (eFUSE). At every power-up, if the FPGA receives an encrypted bitstream, it runs the corresponding CBC decryption and configures its internal elements accord- ingly. In relatively old Xilinx FPGAs, i.e., Virtex-4, Virtex-5, and Spartan-6 families, the integrity of the

encrypted bitstream is examined by a 22-bit CRC. In Vir- tex-4 and Virtex-5 FPGAs, the CRC checksum is not included in the encrypted part, and the corresponding command to enable the CRC is involved in the (unen- crypted) header of the bitstream. Hence, the attacker can easily disable such an integrity check by patching the encrypted bitstream. However, in case of Spartan-6 the encrypted part of the bitstream contains the CRC as well. Therefore, any bitstream manipulation most likely leads to CRC failure. Further, in more recent Xilinx products, e.g., Virtex-6 and the entire seven-series, the integrity (as well as authenticity) is additionally examined by an HMAC, which also disables any bitstream manipulation.

Therefore, in order to investigate the efficiency of our BiFI attack when the bitstream is encrypted, we conducted our experiments on a Virtex-5 FPGA. Obviously it is desir- able to control the effect of manipulation of the bitstream, e.g., to avoid the propagation of the changes. If l bits of ciphertext block Ciþ1 – in CBC mode – are toggled, its effect on the plaintext block Piþ1 is not predictable. However, it also directly changes the corresponding l bits of the next plaintext block Piþ2, and interestingly such a manipulation does not propagate through the entire bitstream. This con- cept is illustrated in Fig. 5.

TABLE 1 Overview of the Experiments with Regard to the Different Modification Rules

D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 d.att.

Changing all 64 bits of a LUT in the bitstream

R1½i� : Clear LUT 1 3 . 6 . . . 1 1 3 1 . . . . 2 8 R2½i� : Set LUT 2 4 3 1 . . . 2 2 2 . 3 . . . 1 9 R3½i� : Invert LUT 1 9 2 2 1 . . . 1 2 2 2 . . . 2 10

Changing only 32 bits of a LUT in the bitstream

R4½i; h� : Clear half LUT . 4 . 7 . . 1 4 3 3 . . 1 1 1 2 10 R5½i; h� : Set half LUT 1 3 2 3 . . . 3 3 2 . 3 1 1 1 1 12 R6½i; h� : Invert half LUT . 7 2 5 1 . . 1 1 3 1 2 2 2 3 4 13

Changing two or four 64-bit LUTs in the bitstream

R7½i� : Clear slice . 1 . 4 . . . 1 . 3 1 . . . . 1 5 R8½i� : Set slice 1 1 1 1 . . . 1 . 1 . 1 . . . 1 3 R9½i; h� : Set 2 LUTs 1 2 . 5 . . . 1 2 3 1 . . . . 1 8 R10½i; h� : Clear 2 LUTs 1 2 1 1 . . . 2 2 1 . 2 . . . 1 9

Clearing only LUTs with a specific slices’ HW in the bitstream

R11½n� : Clear slice if HW=n . . . 1 . . . 1 . . . . . . . . 2 R12½n� : Set slice if HW=n . 1 . 1 . . . 1 . . . . . . . . 2

Inverting single LUT bits (64 times) for a specific HW in the bitstream

R13½i; j� : Invert bits if HW � 15 . 2 2 3 . . 2 5 5 4 . . 1 1 1 . 7 R14½i; j� : Invert bits if HW 49 . 1 . . . . . . . . . . . . . . 1

Configuring random Boolean functions (10 times) in the bitstream

R15½i� : Set LUT randomly 7 31 16 16 1 . . 3 7 13 1 12 5 2 5 3 14 Statistics

P exploitable faulty ciphertexts 15 71 29 56 3 0 3 26 27 40 7 25 10 7 11 19

Number of vulnerable LUTs (R1-R14Þ 5 20 4 18 1 0 2 9 7 13 3 5 3 3 4 6 Measurement time R1-R12 (hours) 20 26 18 74 22 64 26 9 9 42 62 12 26 246 28 12 Measurement time R13-R14 (hours) 110 12 11 38 16 53 18 5 5 26 34 8 18 61 21 7

Each entry in the table represents the number of times for which applying the manipulation rule Ri lead to an exploitable fault for designDj. The last column “d. att.” (designs attacked) shows the number of different designsDj that could be attacked with the corresponding rule. In the experiment, several different modifica- tion rules resulted in an exploitable faulty ciphertext when applied to the same LUT. The number of LUTs that lead to at least one exploitable faulty ciphertext for at least one of the manipulation rules R1 �R14 is shown in row “Number of vulnerable LUTs” as a reference.


4.3 Results with Enabled Bitstream Encryption

On our Virtex-5 (XC5VLX50) setup – with bitstream encryp- tion enabled – we examined 13 AES designs (D0, D2-D6, D9-D15) out of the previously expressed 16 designs.

2 If we ignore the unpredictable changes on plaintext Piþ1, toggles on the bits of ciphertextCiþ1 lead to the same toggles on plaintext Piþ2 (see Fig. 5). Therefore, we can only apply the rulesR3 and R6 which toggle the entire or a half of a LUT. Further, the unpredictable manipulation of plaintext Piþ1 may also hit a utilized LUT. In short, manipulation of ciphertext Ciþ1 based on R3 and R6 indirectly applies the rule R15 to other LUTs as well. More importantly, the unpredictable changes on plain- text Piþ1 can lead to misconfiguration of switch-boxes, and hence short circuits.3 In such scenarios, the FPGA cannot be configured, and needs to be restarted.

We should emphasize that we assume that the attacker has a deep knowledge about the underlying bitstream struc- ture. As an example, he knows which parts of the bitstream (either unencrypted or encrypted) belong to LUTs’ configu- ration. However, in case of the encrypted bitstream he can- not realize which LUTs are utilized. Therefore, the rules R3 and R6 need to be applied to all available LUTs (28,800 in our Virtex-5 (XC5VLX50) FPGA). Hence, the attack takes longer compared to targeting an unencrypted bitstream. Further, since the Virtex-5 FPGA equipped in our setup is larger (hence, larger bitstream) than the Spartan-6 one, each configuration takes around 6.6 seconds, i.e., two times

slower than the previously-shown experiments, which in sum turns into 6.8 days to apply both R3 and R6 rules on all available LUTs. Table 3 shows the corresponding result of the attacks on the targeted 13 AES designs.

Similar to the unencrypted case, only the unrolled pipeline design D5 cannot be successfully attacked. Notably, an aver- age of 11.5 hours is needed for a successful attack over all designs. For further details, we refer to Table 4 which shows all successful hypotheses leading to the exposure of the key.

We also conducted another attack in whichwe considered the encrypted part of the bitstream as a complete black-box, i.e., without directly targeting the LUTs. In order tominimize the effect on plaintext block Piþ2, we only toggled the most significant bit of one ciphertext block. In other words, we tried to apply onlyR15 on plaintext block Piþ1. We conducted this bitstream manipulation to each encrypted block once and could successfully attack 11 out 13 designs. Attacking one AES core takes approximately 8 days, and led again to various exploitable faulty ciphertexts4. To conclude, know- ing the exact locations of the LUT contents in the (encrypted) bitstream is not necessarily essential.

4.4 Discussion on Altera Bitstream Encryption Scheme

The underlying mode of encryption and the employed integrity check determine whether a BiFI attack can be mounted on an encrypted bitstream. While we used Xilinx FPGAs in our practical experiments, below we discuss

TABLE 2 Overview of the Experiments with Regard to the Different Hypotheses

D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 d.att.

H1 : rk0 . . . . . . . . . . . 12 . . . . 1 H1 : rk10 . . . 33 . . . 2 4 15 . 3 . . . 5 6 H2 : Sð0128Þ � rk0 . . . . . . . . . . . . 4 2 4 . 3 yH2 : Sð0128Þ � rk1 . . . . . . . 1 . . . . . . . . 1 yH2 : Sð0128Þ � rk2 . . . . . . . . . . 1 . . . . . 1 H2 : Sð0128Þ � rk10 . 6 . . . . . 2 2 . . . . . . . 3 H3 : c� rk10 . . . . . . . 2 2 . . . . . . . 2 H4 : ka10 . . . . 3 . 2 . . . . . . . 1 1 4 H6 : p� rk0 4 . 19 10 . . . . . 14 2 10 1 3 4 7 10 yH6 : p� rk2 1 . . . . . . . . 2 . . . . . . 2 H6 : p� rk4 6 . . 1 . . . . . 1 . . . . . . 3 yH6 : p� rk5 . . . 3 . . . . . 1 . . . . . . 2 zH6 : p� rk6 . . . 1 . . . . . 2 . . . . . . 2 H6 : p� rk10 4 . . 8 . . . . . 5 . . . . . . 3 zH7 : sr1 . 2 . . . . . . . . . . . . . . 1 yH9 : mc1 . . . . . . . . . . . . 3 . . . 1 H10 : AESkðpÞ; rkj ¼ 0 . 63 10 . . . 1 17 17 . 4 . 2 2 2 4 10 H11 : SRðSðpÞÞ � rk10 . . . . . . . . . . . . . . . 2 1


Collected responses 20,333 26,455 18,044 75,296 22,442 65,051 26,522 8,914 9,080 42,620 62,991 12,261 26,226 249,813 28,188 12,077 Unique faulty responses 6,411 7,412 6,022 28,512 8,955 3,772 15,887 2,587 2,675 15,760 10,137 5,171 15,484 45,971 17,246 5,317

Each entry in the table represents the number of times a hypothesesHi for each design Dj could be used to recover the key from faulty ciphertexts being the result of applying the modification rules R1-R15. Some of the hypotheses (marked byy) succeed only for R15 while some other hypotheses withz could make use of only R1-R14. The last column “d.att.” shows the number of different designs that could be successfully attacked by the corresponding hypothesis. The last two rows summarize the number of collected responses (which are equivalent to the number of times a bitstream manipulation was conducted) and the number of observed unique faulty ciphertexts.

2. Due to their e.g., hard-coded macros not compatible with Virtex-5, the designsD1,D7, andD8 could not be synthesized on this FPGA.

3. Based on our observations, the currently-available FPGAs in the market are protected against such short circuits, preventing them being destroyed.

4. It is noteworthy that in this experiment several times the FPGA “crashed” i.e., could not be programmed until it was restarted manu- ally. This never happened for the manipulation rules that only targeted LUTs.


about the feasibility of our attack on Altera’s bitstreams with enabled encryption. In the recent families of Altera FPGAs (similar to that of Xilinx FPGAs), an HMAC authen- tication process is integrated. Hence, such devices are not susceptible to our attacks (unless the bitstream encryption and authentication is circumvented e.g., by a side-channel analysis attack [29], [30]). However, the older Stratix-II and Stratix-III families use AES in counter mode and a simple CRC for integrity check. The underlying scheme in Stratix-II and Stratix-III are similar except i) AES-128 replaced by AES-256 in the later one, and ii) arithmetic counter (of the counter mode) replaced by a sophisticated pseudo-random- number generator (for more information see [29], [30]).

Both devices generate a stream key which is XORed with the plaintext blocks to form the encrypted bitstream. The decryption process (performed on the FPGA) follows the same concept as depicted in Fig. 6. In this case, if an adver- sary manipulates the bitstream by toggling l bits of the ciphertext block Ciþ1, the corresponding l bits of the same plaintext block Piþ1 toggle, and the changes propagate nei- ther to other bits of the same block nor subsequent blocks. Therefore, compared to the encryption feature of Xilinx FPGAs, the attacker has more control over the manipula- tions, hence higher efficiency of BiFI attacks. More impor- tantly, since the CRC is linear, it can be trivially predicted

how the CRC checksum should change by any toggle made on a ciphertext block (similarly on a plaintext block). More precisely, the attacker can toggle any arbitrary bit(s) of the encrypted bitstream and correspondingly modify the CRC checksum. Therefore, the counter mode makes BiFI attacks considerably easier if a CRC integrity check is employed. Although we have not yet practically examined it, we are confident that our attack can be easily and successfully applied on Altera Stratix-II and Stratix-III FPGAs.


So far we have only expressed themanipulation rules as well as the hypotheses which we used to conduct successful attacks. Below, we give more details by focusing on a few cases, where observed faulty ciphertexts led to key recovery.

5.1 Evaluation of Observed Faults

For a couple of exploitable faulty ciphertexts, we investi- gated at the netlist level, what exactly caused this faulty behavior. To do so, we used the FPGA Editor (provided by the Xilinx ISE toolchain) to analyze the LUTs whose modifi- cation in the bitstream led to a key exposure. Due to the large number of faults, we only cover a small subset of exploitable faults that are representative for a class of similar possible faults. Hence, the provided analysis is not a comprehensive study and only aims at providing the reader with an intui- tion of what can happen during the attack. It is noteworthy that the presented figures are a simplified high-level repre- sentation of the usuallymore complex hardware structure.

5.1.1 Hitting the Control Logic

A successful key recovery on the round-based designD0 was due tomanipulating a LUTwhose two output bits are used to control a 3-to-1multiplexer controlled by two bits ðm1;m2Þ. A part of this design performs the following operations

� CLK cycle 1: state ¼ p� rk0, � CLK cycles 2-10: state ¼ mcj � rkj; j 2 f1; . . . ; 9g, � CLK cycle 11: c ¼ sr10 � rk10: Depending on the clock cycle (i.e., the round counter) the

targeted LUT (which controls the multiplexer) switches

Fig. 5. The impact of faulting one ciphertext block in case of CBC decryption.

TABLE 3 Overview of the BiFI Attack on Encrypted Bitstreams

D0 D2 D3 D4 D5 D6 D9 D10 D11 D12 D13 D14 D15 d.att.

R3½i� 12 7 11 1 . 2 6 1 8 6 4 5 6 12 R6½i; h� 25 11 14 2 . 2 8 2 11 8 7 13 13 12P

exploitable faulty ciphertexts 37 18 25 3 . 4 14 3 19 14 11 18 19 12

Two modification rules R3 and R6 were tested and each table entry represents the number of exploitable faulty ciphertexts.

Fig. 4. a) The ratio the number of performed bitstream manipulations over the number of exploitable faults. b) The average attack time (in hours) until an exploitable faulty ciphertext is obtained for each of the tar- geted design (using modification rules R1-R12).


between the plaintext p ð0; 0Þ, the state after MixColumns mcj ð0; 1Þ, and the final state after the final ShiftRows sr10 ð1; 0Þ, cf. the upper part of Fig. 7. The 128-bit multiplexer output is XORed to the corresponding 128-bit round key.

By applying the rule R1 ðClear LUT ), the LUT outputs are permanently fixed to ð0; 0Þ, and hence, the multiplexer always outputs p regardless of the clock cycle, cf. the lower part of Fig. 7. More precisely, by such a bitstream manipula- tion, the following operations are performed

(1) CLK cycle 1: state ¼ p� rk0, (2) CLK cycles 2-10: state ¼ p� rkj; j 2 f1; . . . ; 9g, (3) CLK cycle 11: ~c ¼ p� rk10. The circuit outputs ~c ¼ p� rk10 instead of c ¼ sr10 � rk10,

which is the motivation to include hypothesis H6 for key recovery.

5.1.2 Update Mechanism of Flip-Flops – Never Update

128-Bit Key Register

We noticed a manipulated LUT whose output controls the update of a couple of flip-flops. As an example, a LUT might control the CE signal (Clock Enable) of a 128-bit state or key register. The flip-flops’ content is updated on e.g., the rising edge of the clock, only if the CE signal is ‘1’. The manipula- tion rule R1 (Clear LUT) turns such a LUT into constant ‘0’, hence always disabling the update. We have observed many cases where the round key registers are never updated. Such a LUT modification can hence turn flip-flops into read-only elements, while they only output their initial value.5

An example is depicted in Fig. 8. It shows that the key schedule output is not stored by the flip-flops and they out- put always ‘0’. Therefore, such a manipulation rule can affect all round keys such that rkj2f1;…;10g ¼ 0128.

Based on our observations – depending on the design architecture – the initial KeyAdd operation is still conducted by the correct round key rk0. More precisely, the manipu- lated AES core performs the following operations:

(1) state ¼ p� rk0, (2) state ¼ MCðSBðSRðstateÞÞÞ � 0128; j 2 f1; . . . ; 9g, (3) ~c ¼ SBðSRðstateÞÞ � 0128. Therefore, the hypothesis H10 (defined in Section 3.2) can

examine whether a manipulation hit the corresponding LUT, and consequently recover the key.

Fig. 6. The decryption in counter mode as it is used for bitstream encryp- tion in Stratix-II and III FPGAs. Toggling a single ciphertext bit results in a predictable toggle of a plaintext bit.

TABLE 4 Overview of the Exploitable Faulty Ciphertexts of the Different Hypotheses

for 13 Different Designs with Enabled Bitstream Encryption

D0 D2 D3 D4 D5 D6 D9 D10 D11 D12 D13 D14 D15 d.att.

H1 : rk0 . . . . . . . . 7 . . . 5 2 H1 : rk10 . . 16 . . . 7 . . . . . . 2 H2 : Sð0128Þ � rk0 . . . . . . . . . 3 4 13 . 3 H2 : Sð0128Þ � rk1 2 . . . . . . . . . . . . 1 H3 : c� rk10 . . . . . . . 1 . . . . . 1 H4 : ka10 . . . 3 . . . . 1 . . . . 2

H6 : p� rk0 17 12 . . . . . . 11 7 6 5 13 7 H6 : p� rk2 9 . 1 . . . 1 . . . . . . 3 H6 : p� rk3 . . 2 . . . . . . . . . . 1 H6 : p� rk5 4 . 5 . . . . . . . . . . 2 H6 : p� rk6 . . 1 . . . . . . . . . . 1 H6 : p� rk8 2 . . . . . . . . . . . . 1 H6 : p� rk10 3 . . . . . 6 . . . . . . 2 H10 : AESkðpÞ; rkj ¼ 0128 . 6 . . . 4 . 1 . 2 1 . 1 6 H11 : SRðSðpÞÞ � rk1 . . . . . . . . . 2 . . . 1


Collected responses 86,400 86,400 86,400 86,400 86,400 86,400 86,400 86,400 86,400 86,400 86,400 86,400 86,400 Unique faulty responses 4,655 7,659 16,959 12,118 9,432 12,124 8,089 19,638 4,677 11,706 12,469 21,945 5,269

Fig. 7. Manipulation rule R1 (Clear LUT), round-based design D0, consequence: Plaintext p (instead of sr10) is XORed to the last AES round key rk10.

5. In Xilinx FPGAs the initial value of every flip-flop can be defined. Without any definition, the default value (usually ‘0’) is taken by the synthesizer.


5.1.3 Update Mechanism of Flip-Flops – Never Update

S-Box Input Register

We have observed a similar scenario for the other registers. As an example, we focus on the AES design D1 with 32-bit datapath, where updating the complete 128-bit AES states requires at least four clock cycles. Similar to the prior case, the CE pin of the registers are controlled by a LUT. If such a LUT is manipulated by R1 (Clear LUT), the register will have always its initial value, cf. Fig. 9.

It is noteworthy that in this design, the four aforemen- tioned AES S-boxes are used only for the SubBytes operation, i.e., the key schedule circuitry employs separate S-box instan- ces. Even though all the main AES operations (ShiftRows, AddRoundkey, MixColumns, etc.) operate correctly, the round output is not stored into the S-box input registers. Therefore, the manipulated design outputs ~c ¼ SBðSRð0128ÞÞ �rk10 ¼ SBð0128Þ � rk10, which trivially leads to recovering the last round key rk10, i.e., hypothesisH2.

These results indeed indicate that preventing registers from updating their state can lead to various exploitable ciphertexts. However, as expressed above, the feasibility of the key recovery depends on the initial value of the registers. Hence, if the registers (in HDL representation) are initialized by arbitrary values, the aforementioned attacks would need to guess the initial value instead of 0128, which obviously com- plicates the attacks.

5.1.4 Update Mechanism of Flip-Flops – Invert Updating

We also observed that the manipulation rule R3 (Invert LUT) resulted in inverting a signal that controls when the output register (128-bit flip-flops so-called out_reg) should be updated by trivially being connected to its CE pin. In the underlying AES core, the out_reg is not updated during the encryption except when the encryption is terminated thereby storing the ciphertext. To this end, the correspond- ing LUT output (so-called update_out_reg_enable) is ‘1’ at only one clock cycle, cf. upper part of Fig. 10.

By the aforementioned manipulation, the LUT output update_out_reg_enable is inverted, and the output register out_reg stores the cipher state after KeyAdd operation at all cipher rounds except the last one. Consequently, the state after the AddRoundkey at round 9 (i.e., ka9) is given as faulty output instead of the correct ciphertext c. By examin- ing hypothesis H4 it can be tested whether such a LUT is hit which directly leads to key recovery.

5.1.5 Hitting the State Machine or Round Counter

One of the most common observed exploitable faults was due to manipulation of a LUT that (partially) processes the state machine or counter signals. As a consequence, in many cases the manipulated AES core finished its opera- tions earlier than the fault-free case. Such a manipulation leads to the exposure of various intermediate values, e.g., the state after the jth AddKey (kaj). A representative exam- ple is illustrated in Fig. 11.

We have observed that the manipulated LUT realizes the following function

final round ¼ rnd0 � rnd3 � rnd1 � rnd2: (3)

Fig. 8. Manipulation rule R1 (Clear LUT), round-based designD15, group of flip-flops forming a 128-bit round key register (rkj;0 – rkj;127) used for XOR with the current AES state. Due to the manipulation, none of the round key flip-flops are updated. Instead, they always remain ‘0’.

Fig. 9. Manipulation rule R1 (Clear LUT), word-based design D1, due to the bitstream manipulation the S-box inputs remain zero, this results into the leakage of the last round key rk10.

Fig. 10. Manipulation rule R3 (Invert LUT), round-based design D4. Due to the LUT inversion of the update_out_reg_enable control signal, the relevant output register out_reg is updated at the wrong clock cycles, i.e., the modified AES core fails to copy the correct ciphertext c and writes the leaking state ka9.

Fig. 11. Manipulation rule R13 (Invert bits if HW � 15), round-based designD6, consequence: modification of AES round counter threshold.


Such a LUT controls the AES core to stop the operations when the round counter reaches ðrnd3; rnd2; rnd1; rnd0Þ ¼ ð1; 0; 1; 0Þ ¼ 10dec, obviously corresponding to 10 cipher rounds of AES-128. Inverting certain bits of this LUT’s con- tent, e.g., by R13, can lead to decrease or increase the num- ber of rounds that the AES core operates.

Similarly, if manipulation rule R2 (Set LUT) is applied, the targeted LUT (which e.g., makes the DONE signal) forces the AES core to terminate the operation right after the start, cf. Fig. 12. The state machine control flow is therefore affected, and as a consequence an intermediate state (e.g., p� rk0) is given instead of the ciphertext.


One way to counter BiFI attacks might be to include builtin self tests (BIST) and conventional fault attack countermeas- ures such as redundancy and error-detection circuitry. However, not all countermeasures aimed at e.g. differential fault attacks are suitable for BiFI attacks and attacks espe- cially aimed at overcoming a particular countermeasure might be able to defeat these. For example, let us assume a BIST as a countermeasure against BiFI. A BIST might pre- vent any manipulation attempt as conducted in this paper since it will detect that the encryption core is not function- ing correctly. However, in such a case an attacker could try to perform a two-step BiFI attack: In the first step, the attacker tries to trigger a BIST failure by identifying/manip- ulating a LUT belonging to the AES circuitry.

The attacker then tries to disable the BIST by continu- ously modifying the bitstream until a faulty ciphertext is returned instead of the BIST failure. Although we did not verify this practically, the occurrence of a decision-making LUT, indicating a failure or success of the BIST, is likely. Manipulating such a LUT to always yield a “success” is then trivial and can be automatized by means of bruteforce.

Having figured out how to disable the BIST, in a second step one can proceed to apply the BiFI attack. Similar attack strategies might be applicable for other countermeasures. Which fault attack countermeasures are the most promising defenses against BiFI is still an open and interesting research question.

6.1 State of Bitstream Authentication

The most promising countermeasure against BiFI is to use a solid bitstream authentication scheme. The most recent Xilinx and Altera FPGAs have solid bitstream authentica- tion and can therefore prevent such attacks. However, it is worth noting that actually most of the currently-deployed

FPGAs do not support bitstream authentication. According to Altera’s annual business report from 2014 [31] the peak production of an FPGA is roughly 6 years after introduction and the FPGAs are sold for more than 15 years. According to the annual reports of both Xilinx and Altera, around 50% of the revenue actually comes from older FPGA families which do not have bitstream authentication [31], [32]. Hence, our attack is applicable to a large share of FPGAs currently in use. It seems likely that it will take some time until FPGAs with bitstream authentication are widely used. It should also be noted that the bitstream encryption schemes of all Xilinx FPGAs except for the latest and rather expensive high-security devices (Kintex and Virtex Ultra- scale), have shown to be vulnerable to side-channel attacks [33], [34], [35]. Similar to Xilinx, it was shown that Altera FPGAs are susceptible to side-channel attacks as well [29], [30]. For these seemingly protected schemes, overcoming the bitstream encryption is equivalent to bypassing the bit- stream authentication. Therefore, the bitstream authentica- tion of these devices could be defeated using a side-channel attack and subsequently a BiFI attack is possible again. In summary, the majority of currently-deployed Xilinx FPGAs appear to be vulnerable to the BiFI attack. In this case the aforementioned countermeasures such as BIST, redundancy and other fault attack countermeasures need to be employed. However, which countermeasures are the most effective and how well they might be defeated by advanced BiFI attack is yet unknown. Hence, moving to FPGAs with solid bitstream authentication therefore seems to be the most advisable countermeasure for security critical applications

6.2 Impact on Other Fault Attack Types

This paper focused on generating exploitable permanent faults using bitstreammanipulation. However, wewould like to highlight that the presented approach to recover an AES key from permanent faults is not restricted to these attacks. Basically, several other fault techniques can be used to create similar exploitable faulty ciphertexts. For example, it was shown that laser fault attacks can also be used to change the configuration of the FPGA, e.g., in [36]. Typically, the goal of most laser fault attacks on FPGA designs is to cause transient faults in one round of the AES encryption to recover the key using a differential fault analysis. Permanent faults are usu- ally not intended and are seen (e.g., in [36]) mainly as an obstacle from an attacker’s perspective. However, the results in this paper show that permanent faults can actually be a very powerful attack vector. The key insight is that even ran- dom configuration errors (rule R15) have a high chance to result in exploitable faulty ciphertexts. Hence, the same attack idea can also be performed with random (or targeted) laser fault injection. Clock glitch or power glitch during the config- uration of the bitstreammight also be used to cause such con- figuration faults. Therefore, investigating how the BiFI attack can be extended to other fault techniques or cryptographic algorithms is an interesting future research direction.


This paper introduces a new attack vector against crypto- graphic implementations on SRAM-based FPGAs. In this

Fig. 12. Manipulation rule R2 (Set LUT), round-based design D9, conse- quence: The AES core permanently observes DONE=‘1’.


attack – so-called bitstream fault injection – the faults are injected repeatedly by configuring the target FPGA with malicious bitstreams. As a key insight of the BiFI attack, it can be automated so that no reverse-engineering of the tar- get design is needed. Our attack, which is based on injecting permanent faults, is feasible in many practical realistic sce- narios, where the attacker can manipulate the FPGA config- uration and observe the faulty outputs of the target design. The adversary indeed manipulates the bitstream to alter and exploit the configuration maliciously.

Our experimental results with 16 AES implementations on a Spartan-6 FPGA showed that 15 out of these 16 designs could be successfully attacked in average in a few hours. The larger the design is (i.e., the more LUTs are utilized), the longer the attack takes. We furthermore showed that such a key recovery is even possible for some FPGAs when the bitstream encryption is enabled. The time required for the attack (in case of the encrypted bitstream) depends on the size of the underlying FPGA (more precisely on the number of available LUTs). It can range from hours (for low and mid-range FPGAs) up to weeks (for high-range FPGAs, e.g., with 1 million LUTs).

In short, the BiFI attack is non-invasive and requires nei- ther a sophisticated setup nor a reverse-engineering tool. Indeed, it can be conducted by engineers without particular expertise. Hence, an interesting research question is how to develop the designs – rather than a sound integrity check – to defeat such attacks. For example, whether the concepts in [37], [38], developed mainly for software platforms, can be integrated into FPGA designs.


The work described in this paper has been partially sup- ported by the German Federal Ministry of Education and Research BMBF (grant 16KIS0015, project PhotonFX2) and under US National Science Foundation grant CNS-1318497. It has also been supported in part by the Bosch Research Foundation.

REFERENCES [1] D. Boneh, R. A. DeMillo, and R. J. Lipton, “On the importance of

checking cryptographic protocols for faults,” in Advances in Cryp- tology. Berlin, Germany: Springer, 1997, pp. 37–51.

[2] E. Biham and A. Shamir, “Differential fault analysis of secret key cryptosystems,” in Advances in Cryptology. Berlin, Germany: Springer, 1997, pp. 513–525.

[3] G. Piret and J. Quisquater, “A differential fault attack technique against SPN structures, with application to the AES and KHAZAD,” in Cryptographic Hardware and Embedded Systems. Berlin, Germany: Springer, 2003, pp. 77–88.

[4] E. D. Mulder, et al., “Electromagnetic analysis attack on an FPGA implementation of an elliptic curve cryptosystem,” in Proc. Int. Conf. Comput. Tool, Nov. 2005, vol. 2, pp. 1879–1882.

[5] Y. Li, K. Sakiyama, S. Gomisawa, T. Fukunaga, J. Takahashi, and K. Ohta, “Fault sensitivity analysis,” in Cryptographic Hardware and Embedded Systems. Berlin, Germany: Springer, 2010, pp. 320–334.

[6] H. Choukri and M. Tunstall, “Round reduction using faults,” in Proc. Workshop Fault Diagnosis Tolerance Cryptography, 2005, pp. 13–14.

[7] S. P. Skorobogatov and R. J. Anderson, “Optical fault induction attacks,” in Cryptographic Hardware and Embedded Systems. Berlin, Germany: Springer, 2002, pp. 2–12.

[8] A. Schl€osser, D. Nedospasov, J. Kr€amer, S. Orlic, and J. Seifert, “Simple photonic emission analysis of AES,” J. Cryptographic Eng., vol. 3, no. 1, pp. 3–15, 2013.

[9] I. Verbauwhede, D. Karaklajic, and J. M. Schmidt, “The fault attack jungle—a classification model to guide you,” in Proc. Work- shop Fault Diagnosis Tolerance Cryptography, 2011, pp. 3–8.

[10] Z. Ding, Q. Wu, Y. Zhang, and L. Zhu, “Deriving an NCD file from an FPGA bitstream: Methodology, architecture and eval- uation,” Microprocessors Microsystems-Embedded Hardware Des., vol. 37, no. 3, pp. 299–312, 2013.

[11] S. Drimer, “Volatile FPGA design security-a survey (v0.96),” Apr. 2008. [Online]. Available: papers/fpga_security.pdf

[12] S. M. Trimberger and J. J. Moore, “FPGA security: Motivations, features, and applications,” in Proc. IEEE, vol. 102, no. 8, pp. 1248– 1265, Aug. 2014.

[13] S. Trimberger, J. Moore, andW. Lu, “Authenticated encryption for FPGA bitstreams,” in Proc. ACM/SIGDA 19th Int. Symp. Field Pro- grammable Gate Arrays, 2011, pp. 83–86.

[14] F. Benz, A. Seffrin, and S. Huss, “BIL: A tool-chain for bitstream reverse-engineering,” in Proc. 22nd Int. Conf. Field Programmable Logic Appl., Aug. 2012, pp. 735–738.

[15] �E. Rannaud, “From the bitstream to the netlist,” in Proc. 16th Int. ACM/SIGDA Symp. Field Programmable Gate Arrays, 2008, pp. 264– 264.

[16] P. Swierczynski, M. Fyrbiak, P. Koppe, and C. Paar, “FPGA Tro- jans through detecting and weakening of cryptographic primi- tives,” IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst., vol. 34, no. 8, pp. 1236–1249, Aug. 2015.

[17] D. Ziener, S. Assmus, and J. Teich, “Identifying FPGA IP-cores based on lookup table content analysis,” in Proc. Int. Conf. Field Programmable Logic Appl., Aug. 2006, pp. 1–6.

[18] A. C. Aldaya, A. C. Sarmiento, and S. S�anchez-Solano, “AES T-Box tampering attack,” J. Cryptographic Eng., vol. 6, no. 1, pp. 31–48, 2016.

[19] P. Swierczynski, M. Fyrbiak, P. Koppe, A. Moradi, and C. Paar, “Interdiction in practice—Hardware Trojan against a high-secu- rity USB flash drive,” J. Cryptographic Eng., pp. 1–13, 2016.

[20] T. Kerins and K. Kursawe, “A cautionary note on weak implemen- tations of block ciphers,” in Proc. Workshop Inf. Syst. Secur., 2006, Art. no. 12.

[21] M. Calvin McCoy, 2010. [Online]. Available: abhinav3008/inmcm-hdl/tree/master/AES/Basic_AES_128_ Cipher

[22] J. Gbur, 2011. [Online]. Available:, aes_128_192_256

[23] F. Balazs, 2014. [Online]. Available:, aes_all_keylength

[24] Hemanth, 2014. [Online]. Available: project,aes_crypto_core

[25] T. Ahmad, 2013. [Online]. Available: project,aes-encryption

[26] M. Litochevski and L. Dongjun, 2013. [Online]. Available: http://,aes_highthroughput_lowarea

[27] NSA, 1999. [Online]. Available: aes/round2/r2anlsys.htm#NSA

[28] A. Satoh, 2007. [Online]. Available: http://www.aoki.ecei.tohoku.

[29] A. Moradi, D. Oswald, C. Paar, and P. Swierczynski, “Side-chan- nel attacks on the bitstream encryption mechanism of altera stratix II: Facilitating black-box analysis using software reverse-engineer- ing,” in Proc. ACM/SIGDA Int. Symp. Field Programmable Gate Arrays, 2013, pp. 91–100.

[30] P. Swierczynski, A. Moradi, D. Oswald, and C. Paar, “Physical security evaluation of the bitstream encryption mechanism of Altera Stratix II and Stratix III FPGAs,” ACM Trans. Reconfigurable Technol. Syst., vol. 7, no. 4, pp. 34:1–34:23, 2014.

[31] Altera, “Altera annual report for form 10-k for 2014,” 2015. [Online]. Available: data/768251/000076825115000008/altera10k12312014.htm

[32] Xilinx, “Xilinx annual report for form 10-k for 2014,” 2015. [Online]. Available: /743988/000074398815000022/xlnx0 328201510k.htm

[33] A. Moradi, A. Barenghi, T. Kasper, and C. Paar, “On the vulnera- bility of FPGA bitstream encryption against power analysis attacks: Extracting keys from Xilinx Virtex-II FPGAs,” in Proc. ACM Conf. Comput. Commun. Secur., 2011, pp. 111–124.

[34] A. Moradi, M. Kasper, and C. Paar, “Black-box side-channel attacks highlight the importance of countermeasures-an analysis of the Xilinx Virtex-4 and Virtex-5 bitstream encryption mecha- nism,” in Proc. 12th Conf. Topics Cryptology, Feb. 2012, pp. 1–18.


[35] A. Moradi and T. Schneider, “Improved side-channel analysis attacks on Xilinx bitstream encryption of 5, 6, and 7 series,” in Workshop on Constructive Side-Channel Analysis and Secure Design. Berlin, Germany: Springer, 2016.

[36] G. Canivet, P. Maistri, R. Leveugle, J. Cl�edi�ere, F. Valette, and M. Renaudin, “Glitch and laser fault attacks onto a secure AES implementation on a SRAM-based FPGA,” J. Cryptology, vol. 24, no. 2, pp. 247–268, 2011.

[37] B. Sunar, G. Gaubatz, and E. Savas, “Sequential circuit design for embedded cryptographic applications resilient to adversarial faults,” IEEE Trans. Comput., vol. 57, no. 1, pp. 126–138, Jan. 2008.

[38] M. Werner, E. Wenger, and S. Mangard, “Protecting the control flow of embedded processors against fault attacks,” in Smart Card Research and Advanced Applications. Berlin, Germany: Springer, 2015, pp. 161–176.

Pawel Swierczynski received the BSc and MSc degrees in IT-security from Ruhr University Bochum, Germany, in 2010 and 2013, respec- tively. He is currently working toward the PhD degree at the Chair for Embedded Security, under the supervision of Prof. Christof Paar. His current research is focused on the physical secu- rity of FPGAs as well as on practical attacks on real-world devices with a special emphasis on cryptographic FPGA design manipulation.

Georg T. Becker received the BSc degree in applied computer science and the MSc degree in IT-security from Ruhr University Bochum, in 2007 and 2009 respectively, and the PhD degree in electrical and computer engineering from the Uni- versity of Massachusetts Amherst, in 2014. He is currently a senior researcher in the Digital Soci- ety Institute (DSI), ESMT, Berlin. Before joining the DSI in December 2016 he was a post-doc in the Embedded Security Group, Horst G€ortz Insti- tute for IT-Security, Ruhr University Bochum. His

primary research interests is hardware security with a special focus on hardware Trojans, physical unclonable functions (PUFs), and side-chan- nel analysis.

Amir Moradi received the MSc and PhD degrees in computer engineering from Sharif University of Technology, Tehran, Iran, in 2004 and 2008 respectively. Afterwards, till 2015 he worked as a post-doctoral researcher in the Embedded Secu- rity Group, Ruhr University Bochum, Germany. Since 2016, after obtaining the Habilitation degree, he has become a senior researcher and faculty member at the faculty of electrical engi- neering and information technology with Ruhr Uni- versity Bochum. His current research interests

include physical security of embedded systems, passive side-channel analysis attacks, and the corresponding countermeasures. He has pub- lished more than 70 peer-reviewed journal articles and conference papers, in both destructive and constructive aspects of side-channel anal- ysis. He also served as Program Committee Member (and the chair) of several security-and cryptography-related conferences and workshops.

Christof Paar (Fellow, IEEE) received the MSc degree from the University of Siegen, Germany and the PhD degree from the Institute for Experimental Mathematics, University of Essen, Germany. He holds the chair for Embedded Security, Ruhr University Bochum, Germany, and is affiliated professor with the University of Mas- sachusetts Amherst. He co-founded, with C. Koc, the Conference on Cryptographic Hardware and Embedded Systems (CHES). He has more than 200 peer-reviewed publications and is co-author

of the textbook Understanding Cryptography (New York, NY: Springer- Verlag, 2010). He is a co-founder of ESCRYPT-Embedded Security, a leading consultancy firm in applied security that is now part of Bosch. His research interests include the efficient realizations of cryptography, hardware Trojans, physical security, and security evaluation of real- world systems. He is a fellow of the IEEE.

” For more information on this or any other computing topic, please visit our Digital Library at


<< /ASCII85EncodePages false /AllowTransparency false /AutoPositionEPSFiles true /AutoRotatePages /None /Binding /Left /CalGrayProfile (Gray Gamma 2.2) /CalRGBProfile (sRGB IEC61966-2.1) /CalCMYKProfile (U.S. Web Coated \050SWOP\051 v2) /sRGBProfile (sRGB IEC61966-2.1) /CannotEmbedFontPolicy /Warning /CompatibilityLevel 1.4 /CompressObjects /Off /CompressPages true /ConvertImagesToIndexed true /PassThroughJPEGImages true /CreateJobTicket false /DefaultRenderingIntent /Default /DetectBlends true /DetectCurves 0.0000 /ColorConversionStrategy /sRGB /DoThumbnails true /EmbedAllFonts true /EmbedOpenType false /ParseICCProfilesInComments true /EmbedJobOptions true /DSCReportingLevel 0 /EmitDSCWarnings false /EndPage -1 /ImageMemory 1048576 /LockDistillerParams true /MaxSubsetPct 100 /Optimize true /OPM 0 /ParseDSCComments false /ParseDSCCommentsForDocInfo true /PreserveCopyPage true /PreserveDICMYKValues true /PreserveEPSInfo false /PreserveFlatness true /PreserveHalftoneInfo true /PreserveOPIComments false /PreserveOverprintSettings true /StartPage 1 /SubsetFonts false /TransferFunctionInfo /Remove /UCRandBGInfo /Preserve /UsePrologue false /ColorSettingsFile () /AlwaysEmbed [ true /Algerian /Arial-Black /Arial-BlackItalic /Arial-BoldItalicMT /Arial-BoldMT /Arial-ItalicMT /ArialMT /ArialNarrow /ArialNarrow-Bold /ArialNarrow-BoldItalic /ArialNarrow-Italic /ArialUnicodeMS /BaskOldFace /Batang /Bauhaus93 /BellMT /BellMTBold /BellMTItalic /BerlinSansFB-Bold /BerlinSansFBDemi-Bold /BerlinSansFB-Reg /BernardMT-Condensed /BodoniMTPosterCompressed /BookAntiqua /BookAntiqua-Bold /BookAntiqua-BoldItalic /BookAntiqua-Italic /BookmanOldStyle /BookmanOldStyle-Bold /BookmanOldStyle-BoldItalic /BookmanOldStyle-Italic /BookshelfSymbolSeven /BritannicBold /Broadway /BrushScriptMT /CalifornianFB-Bold /CalifornianFB-Italic /CalifornianFB-Reg /Centaur /Century /CenturyGothic /CenturyGothic-Bold /CenturyGothic-BoldItalic /CenturyGothic-Italic /CenturySchoolbook /CenturySchoolbook-Bold /CenturySchoolbook-BoldItalic /CenturySchoolbook-Italic /Chiller-Regular /ColonnaMT /ComicSansMS /ComicSansMS-Bold /CooperBlack /CourierNewPS-BoldItalicMT /CourierNewPS-BoldMT /CourierNewPS-ItalicMT /CourierNewPSMT /EstrangeloEdessa /FootlightMTLight /FreestyleScript-Regular /Garamond /Garamond-Bold /Garamond-Italic /Georgia /Georgia-Bold /Georgia-BoldItalic /Georgia-Italic /Haettenschweiler /HarlowSolid /Harrington /HighTowerText-Italic /HighTowerText-Reg /Impact /InformalRoman-Regular /Jokerman-Regular /JuiceITC-Regular /KristenITC-Regular /KuenstlerScript-Black /KuenstlerScript-Medium /KuenstlerScript-TwoBold /KunstlerScript /LatinWide /LetterGothicMT /LetterGothicMT-Bold /LetterGothicMT-BoldOblique /LetterGothicMT-Oblique /LucidaBright /LucidaBright-Demi /LucidaBright-DemiItalic /LucidaBright-Italic /LucidaCalligraphy-Italic /LucidaConsole /LucidaFax /LucidaFax-Demi /LucidaFax-DemiItalic /LucidaFax-Italic /LucidaHandwriting-Italic /LucidaSansUnicode /Magneto-Bold /MaturaMTScriptCapitals /MediciScriptLTStd /MicrosoftSansSerif /Mistral /Modern-Regular /MonotypeCorsiva /MS-Mincho /MSReferenceSansSerif /MSReferenceSpecialty /NiagaraEngraved-Reg /NiagaraSolid-Reg /NuptialScript /OldEnglishTextMT /Onyx /PalatinoLinotype-Bold /PalatinoLinotype-BoldItalic /PalatinoLinotype-Italic /PalatinoLinotype-Roman /Parchment-Regular /Playbill /PMingLiU /PoorRichard-Regular /Ravie /ShowcardGothic-Reg /SimSun /SnapITC-Regular /Stencil /SymbolMT /Tahoma /Tahoma-Bold /TempusSansITC /TimesNewRomanMT-ExtraBold /TimesNewRomanMTStd /TimesNewRomanMTStd-Bold /TimesNewRomanMTStd-BoldCond /TimesNewRomanMTStd-BoldIt /TimesNewRomanMTStd-Cond /TimesNewRomanMTStd-CondIt /TimesNewRomanMTStd-Italic /TimesNewRomanPS-BoldItalicMT /TimesNewRomanPS-BoldMT /TimesNewRomanPS-ItalicMT /TimesNewRomanPSMT /Times-Roman /Trebuchet-BoldItalic /TrebuchetMS /TrebuchetMS-Bold /TrebuchetMS-Italic /Verdana /Verdana-Bold /Verdana-BoldItalic /Verdana-Italic /VinerHandITC /Vivaldii /VladimirScript /Webdings /Wingdings2 /Wingdings3 /Wingdings-Regular /ZapfChanceryStd-Demi /ZWAdobeF ] /NeverEmbed [ true ] /AntiAliasColorImages false /CropColorImages true /ColorImageMinResolution 150 /ColorImageMinResolutionPolicy /OK /DownsampleColorImages true /ColorImageDownsampleType /Bicubic /ColorImageResolution 150 /ColorImageDepth -1 /ColorImageMinDownsampleDepth 1 /ColorImageDownsampleThreshold 1.50000 /EncodeColorImages true /ColorImageFilter /DCTEncode /AutoFilterColorImages false /ColorImageAutoFilterStrategy /JPEG /ColorACSImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /ColorImageDict << /QFactor 0.40 /HSamples [1 1 1 1] /VSamples [1 1 1 1] >> /JPEG2000ColorACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /JPEG2000ColorImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 150 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages false /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict << /QFactor 0.76 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /GrayImageDict << /QFactor 0.40 /HSamples [1 1 1 1] /VSamples [1 1 1 1] >> /JPEG2000GrayACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /JPEG2000GrayImageDict << /TileWidth 256 /TileHeight 256 /Quality 15 >> /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict << /K -1 >> /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False /CreateJDFFile false /Description << /CHS <FEFF4f7f75288fd94e9b8bbe5b9a521b5efa7684002000410064006f006200650020005000440046002065876863900275284e8e55464e1a65876863768467e5770b548c62535370300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c676562535f00521b5efa768400200050004400460020658768633002> /CHT <FEFF4f7f752890194e9b8a2d7f6e5efa7acb7684002000410064006f006200650020005000440046002065874ef69069752865bc666e901a554652d965874ef6768467e5770b548c52175370300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c4f86958b555f5df25efa7acb76840020005000440046002065874ef63002> /DAN <FEFF004200720075006700200069006e0064007300740069006c006c0069006e006700650072006e0065002000740069006c0020006100740020006f007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400650072002c0020006400650072002000650067006e006500720020007300690067002000740069006c00200064006500740061006c006a006500720065007400200073006b00e60072006d007600690073006e0069006e00670020006f00670020007500640073006b007200690076006e0069006e006700200061006600200066006f0072007200650074006e0069006e006700730064006f006b0075006d0065006e007400650072002e0020004400650020006f007000720065007400740065006400650020005000440046002d0064006f006b0075006d0065006e0074006500720020006b0061006e002000e50062006e00650073002000690020004100630072006f00620061007400200065006c006c006500720020004100630072006f006200610074002000520065006100640065007200200035002e00300020006f00670020006e0079006500720065002e> /DEU <FEFF00560065007200770065006e00640065006e0020005300690065002000640069006500730065002000450069006e007300740065006c006c0075006e00670065006e0020007a0075006d002000450072007300740065006c006c0065006e00200076006f006e002000410064006f006200650020005000440046002d0044006f006b0075006d0065006e00740065006e002c00200075006d002000650069006e00650020007a0075007600650072006c00e40073007300690067006500200041006e007a006500690067006500200075006e00640020004100750073006700610062006500200076006f006e00200047006500730063006800e40066007400730064006f006b0075006d0065006e00740065006e0020007a0075002000650072007a00690065006c0065006e002e00200044006900650020005000440046002d0044006f006b0075006d0065006e007400650020006b00f6006e006e0065006e0020006d006900740020004100630072006f00620061007400200075006e0064002000520065006100640065007200200035002e003000200075006e00640020006800f600680065007200200067006500f600660066006e00650074002000770065007200640065006e002e> /ESP <FEFF005500740069006c0069006300650020006500730074006100200063006f006e0066006900670075007200610063006900f3006e0020007000610072006100200063007200650061007200200064006f00630075006d0065006e0074006f0073002000640065002000410064006f00620065002000500044004600200061006400650063007500610064006f007300200070006100720061002000760069007300750061006c0069007a00610063006900f3006e0020006500200069006d0070007200650073006900f3006e00200064006500200063006f006e006600690061006e007a006100200064006500200064006f00630075006d0065006e0074006f007300200063006f006d00650072006300690061006c00650073002e002000530065002000700075006500640065006e00200061006200720069007200200064006f00630075006d0065006e0074006f00730020005000440046002000630072006500610064006f007300200063006f006e0020004100630072006f006200610074002c002000410064006f00620065002000520065006100640065007200200035002e003000200079002000760065007200730069006f006e0065007300200070006f00730074006500720069006f007200650073002e> /FRA <FEFF005500740069006c006900730065007a00200063006500730020006f007000740069006f006e00730020006100660069006e00200064006500200063007200e900650072002000640065007300200064006f00630075006d0065006e00740073002000410064006f006200650020005000440046002000700072006f00660065007300730069006f006e006e0065006c007300200066006900610062006c0065007300200070006f007500720020006c0061002000760069007300750061006c00690073006100740069006f006e0020006500740020006c00270069006d007000720065007300730069006f006e002e0020004c0065007300200064006f00630075006d0065006e00740073002000500044004600200063007200e900e90073002000700065007500760065006e0074002000ea0074007200650020006f007500760065007200740073002000640061006e00730020004100630072006f006200610074002c002000610069006e00730069002000710075002700410064006f00620065002000520065006100640065007200200035002e0030002000650074002000760065007200730069006f006e007300200075006c007400e90072006900650075007200650073002e> /ITA (Utilizzare queste impostazioni per creare documenti Adobe PDF adatti per visualizzare e stampare documenti aziendali in modo affidabile. I documenti PDF creati possono essere aperti con Acrobat e Adobe Reader 5.0 e versioni successive.) /JPN <FEFF30d330b830cd30b9658766f8306e8868793a304a3088307353705237306b90693057305f002000410064006f0062006500200050004400460020658766f8306e4f5c6210306b4f7f75283057307e305930023053306e8a2d5b9a30674f5c62103055308c305f0020005000440046002030d530a130a430eb306f3001004100630072006f0062006100740020304a30883073002000410064006f00620065002000520065006100640065007200200035002e003000204ee5964d3067958b304f30533068304c3067304d307e305930023053306e8a2d5b9a3067306f30d530a930f330c8306e57cb30818fbc307f3092884c3044307e30593002> /KOR <FEFFc7740020c124c815c7440020c0acc6a9d558c5ec0020be44c988b2c8c2a40020bb38c11cb97c0020c548c815c801c73cb85c0020bcf4ace00020c778c1c4d558b2940020b3700020ac00c7a50020c801d569d55c002000410064006f0062006500200050004400460020bb38c11cb97c0020c791c131d569b2c8b2e4002e0020c774b807ac8c0020c791c131b41c00200050004400460020bb38c11cb2940020004100630072006f0062006100740020bc0f002000410064006f00620065002000520065006100640065007200200035002e00300020c774c0c1c5d0c11c0020c5f40020c2180020c788c2b5b2c8b2e4002e> /NLD (Gebruik deze instellingen om Adobe PDF-documenten te maken waarmee zakelijke documenten betrouwbaar kunnen worden weergegeven en afgedrukt. De gemaakte PDF-documenten kunnen worden geopend met Acrobat en Adobe Reader 5.0 en hoger.) /NOR <FEFF004200720075006b00200064006900730073006500200069006e006e007300740069006c006c0069006e00670065006e0065002000740069006c002000e50020006f0070007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e00740065007200200073006f006d002000650072002000650067006e0065007400200066006f00720020007000e5006c006900740065006c006900670020007600690073006e0069006e00670020006f00670020007500740073006b007200690066007400200061007600200066006f0072007200650074006e0069006e006700730064006f006b0075006d0065006e007400650072002e0020005000440046002d0064006f006b0075006d0065006e00740065006e00650020006b0061006e002000e50070006e00650073002000690020004100630072006f00620061007400200065006c006c00650072002000410064006f00620065002000520065006100640065007200200035002e003000200065006c006c00650072002e> /PTB <FEFF005500740069006c0069007a006500200065007300730061007300200063006f006e00660069006700750072006100e700f50065007300200064006500200066006f0072006d00610020006100200063007200690061007200200064006f00630075006d0065006e0074006f0073002000410064006f00620065002000500044004600200061006400650071007500610064006f00730020007000610072006100200061002000760069007300750061006c0069007a006100e700e3006f002000650020006100200069006d0070007200650073007300e3006f00200063006f006e0066006900e1007600650069007300200064006500200064006f00630075006d0065006e0074006f007300200063006f006d0065007200630069006100690073002e0020004f007300200064006f00630075006d0065006e0074006f00730020005000440046002000630072006900610064006f007300200070006f00640065006d0020007300650072002000610062006500720074006f007300200063006f006d0020006f0020004100630072006f006200610074002000650020006f002000410064006f00620065002000520065006100640065007200200035002e0030002000650020007600650072007300f50065007300200070006f00730074006500720069006f007200650073002e> /SUO <FEFF004b00e40079007400e40020006e00e40069007400e4002000610073006500740075006b007300690061002c0020006b0075006e0020006c0075006f0074002000410064006f0062006500200050004400460020002d0064006f006b0075006d0065006e007400740065006a0061002c0020006a006f0074006b006100200073006f0070006900760061007400200079007200690074007900730061007300690061006b00690072006a006f006a0065006e0020006c0075006f00740065007400740061007600610061006e0020006e00e400790074007400e4006d0069007300650065006e0020006a0061002000740075006c006f007300740061006d0069007300650065006e002e0020004c0075006f0064007500740020005000440046002d0064006f006b0075006d0065006e00740069007400200076006f0069006400610061006e0020006100760061007400610020004100630072006f0062006100740069006c006c00610020006a0061002000410064006f00620065002000520065006100640065007200200035002e0030003a006c006c00610020006a006100200075007500640065006d006d0069006c006c0061002e> /SVE <FEFF0041006e007600e4006e00640020006400650020006800e4007200200069006e0073007400e4006c006c006e0069006e006700610072006e00610020006f006d002000640075002000760069006c006c00200073006b006100700061002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400200073006f006d00200070006100730073006100720020006600f60072002000740069006c006c006600f60072006c00690074006c006900670020007600690073006e0069006e00670020006f006300680020007500740073006b007200690066007400650072002000610076002000610066006600e4007200730064006f006b0075006d0065006e0074002e002000200053006b006100700061006400650020005000440046002d0064006f006b0075006d0065006e00740020006b0061006e002000f600700070006e00610073002000690020004100630072006f0062006100740020006f00630068002000410064006f00620065002000520065006100640065007200200035002e00300020006f00630068002000730065006e006100720065002e> /ENU (Use these settings to create PDFs that match the “Suggested” settings for PDF Specification 4.0) >> >> setdistillerparams << /HWResolution [600 600] /PageSize [612.000 792.000] >> setpagedevice

Comments are closed.