Secure Configuration Schemes for FPGA-based Systems with Simple Key Management Abdelghani Errandani, Abderrahim Doumar and Eric Châtelet Institue Charles Delaunay (ICD), STMR, UMR CNRS 6279 Laboratoire de Modélisation et Sûreté des Systèmes (LM2S) Université de Technologie de Troyes (UTT) 12, rue Marie Curie, 10010 Troyes Cedex, France
[email protected],
[email protected],
[email protected] Abstract—The growing evolution in field programmable gate array (FPGA) performances appeals to embedded systems designers to expansively incorporate FPGA devices in their systems. This expanding use makes FPGA-based systems more attractive to several attackers and hence vulnerable to a number of threats. In this paper, we propose two protection schemes against design theft, for SRAM-based FPGA devices, considering the key management issue at the customer facility. The first scheme proposes some improvements to a pre-reported scheme for reducing its implementation cost. The second proposition is distinct from others by combining both symmetric and asymmetric encryption. An evident comparison shows that our proposed schemes are more advantageous over other works and present the best tradeoff between hardware, security and key management, making good use of different cryptography features. Index Terms—FPGA security, bitstream encryption, key management, IP protection, design cloning, reverse engineering.
I. I NTRODUCTION Nowadays there are several electronic equipments that incorporate FPGA circuits and they cover almost all sectors, from consumer products to avionic equipments. Electronic industry takes benefit from FPGA performances to reduce research and development expenses and to increase first-tomarket revenue gains. Equally, FPGA circuits take advantage from the growing evolution in the copper process technology to be used in more complex manufacturing equipments such as in military assets. Built on a 28nm technology, today more advanced FPGAs offer the best solution for meeting the needs of high-performance embedded systems designers. Moreover, the user programmability feature makes FPGA devices more advantageous over mask-programmed application specific integrated circuits (ASICs) for designing embedded systems, especially those need to be frequently upgraded. Because of the great importance and the expanding use of the FPGAs in the electronic industry, FPGA devices become so appealing to enemy attackers and hence increasingly vulnerable to several threats [1]. The protection of the designs stored in their configuration memory, from being stolen, is among critical security concerns of FPGA devices. According to the 2009 International Anti-Counterfeiting Directory [2], the international trade loses about US$200 billion a year due to theft. Depending on technologies and vendors, FPGAs offer different levels of security to defend itself against the
978-1-4673-0186-2/12/$31.00 ©2012 IEEE
theft of designs. Antifuse FPGAs are considered as the most secure while SRAM ones are the least [3]. In fact, the whole intelligence for configuring the antifuse FPGAs is contained in programmer, so no configuration file (or bitstream) is readable from the devices. However, SRAM FPGAs are volatile and require an off-chip non-volatile memory to store the configuration bitstream. Therefore, the availability of the bitstream file outside the device makes SRAM FPGA designs more vulnerable to theft threats. This security issue is one of the few remaining advantages of non-volatile FPGAs over volatile ones. Nevertheless, the end-user reconfigurability capability of SRAM FPGAs appeals to many designers, and hence SRAM FPGAs vendors become more interested in providing their customers with efficient solutions to meet their design security needs. In the following only SRAM FPGAs design security will be discussed. The security problem of FPGAs has been well-known in the industry for at least 20 years, and hence several solutions, based on different approaches, such as bitstream encapsulation and bitstream encryption techniques [4], have been proposed. Currently, the most important FPGA manufacturers (Xilinx and Altera) have proposed similar security systems [5] [6] to protect FPGA design against theft, relied on symmetric (secret key) cryptography; but they have not considered the key management problem in the customer facility. In fact, disclosing encryption keys makes FPGA designs vulnerable to theft and therefore keys need be securely managed in the FGPA device as well as in the customer facility. Kean from Algotronix has proposed in [4] an efficient security system in which encryption keys never leave the FPGA device. However, Kean’s scheme requires more FPGA resources to be implemented and does not support secure remote update. Hence, this scheme is not well-suited for resource-constrained systems nor for frequently updated designs. This paper emphasizes the importance of addressing the key management problem in the customer facility. Considering this problem, we propose two different schemes to protect FPGA designs against theft. Firstly, Kean’s scheme is enhanced by reducing the cost of implementing its security circuit, and hence it can be an efficient solution when no frequent updates of design are needed. Secondly, another security scheme, based on a hybrid cryptographic mechanism, is proposed. This
mechanism combines both symmetric and asymmetric (public key) encryption to offer an efficient security solution with no hard constraints on the key management at the customer facility. The remainder of this paper is organised as follows. Section II describes the attack environment of an FPGA-based system. In section III, we review two design protection schemes proposed in the FPGA security literature. Section IV presents our proposed schemes and shows their advantages compared to others. Comparison and security analysis of all schemes are given in section V. Finally, the paper is concluded by outlining future works. II. FPGA E NVIRONMENT To clarify the scope of this paper, it is necessary to consider the various stages in the life of an FPGA circuit and to define the attack environment of an FPGA-embedded system. First, a simple FPGA use model, inspired from [7], will be considered. This model presents three important principals that participate in FPGA security system. * FPGA manufacturer introduces his FPGA devices in the marketplace for sale, taking into account the security features invoked by his customers when new FPGA devices will be produced. * Customer facility is concerned with either meeting product specifications at the lowest cost or protecting designs from theft according to his primary concern. Customer facility is linked to both system designer and system manufacturer. * End-user is the owner of the FPGA-embedded system and may be considered as an enemy attacker trying to circumvent security. Assuming that an attacker has physical access to the FPGAbased system. The FPGA design can be intercepted in two different places: in the field between an off-chip non-volatile memory and the FPGA during startup, or over an insecure channel (like internet) when the customer facility transmits an updated design to the end-user. In both cases, the FPGA design may be exposed to two well-known forms of theft [1] [3] [8]. In fact, when the design file is probed, the attacker (pirate) can build copies of the cloned design and sell them with a lower price than the original manufacturer for great profit. This form of theft is named cloning attack. Further, the attacker can analyse the probed file to recreate the design at the register transfer level (RTL) or in hardware description language (HDL), before modifying it to produce competitive products. This form of theft is called reverse engineering attack. Although both attacks present a real menace to product revenue, reverse engineering is more serious. In fact, reverse engineering is legal and what companies and governments often do to either develop effective countermeasures or to produce similar equipment. In this paper, semi-invasive and side channel attacks on FPGA will not be considered, so the would-be attacker can neither probe nor affect sensitive data stored in the FPGA. As a result, encryption keys will be considered secure in the
FPGA device and hence their security will be addressed only in the customer facility. III. R ELATED W ORK The design security issue can be generally addressed using two different approaches. The first one emphasizes the importance of creating new regulation and norms to protect intellectual propriety (IP) rights. This approach may be a good deterrent to IP thieves; but only if government authorities enforce IP rights laws. The second approach leverages cryptography algorithms and standards to develop effective security systems that are able to deter thefts. In the following, all security schemes deal with the second approach. A. Commercial SRAM FPGA Security Schemes Based on the user-selected key idea, today the most important FPGA manufacturers (Xilinx and Altera) offer similar bitstream encryption systems, using the last encryption cipher recommended by the National Institute of Standards and Technology (NIST). Fig. 1 presents the encryption/decryption system provided by Xilinx 7-series (Virtex-7/Spartan-7) and Altera Stratix-V FPGA families [5] [6]. CAD tool configuration generator
CAD: computer−aided design NVM: non volatile memory
FPGA
NVM
configuration memory
encrypted bitstream
AES decryption circuit
AES encryption software 256−bit key
bbRAM
fuses
external battery
Fig. 1.
AES encryption system in 7 series and Stratix-V FPGA families.
The designer uses the CAD software for generating an encrypted bitstream file with a user-selected key and then for storing the generated file in an off-chip non-volatile memory. The encryption key is also stored in a dedicated memory inside the FPGA via the JTAG interface. When the system is powered up, the FPGA loads the encrypted bitstream from the off-chip memory and decrypts the incoming bitstream, using the onchip key and the built-in decryption engine, before configuring itself. Except Xilinx Virtex-II families, all Xilinx and Altera FPGA families providing such encryption/decryption solution use the advanced encryption standard (AES) as an encryption algorithm. AES is a FIPS-approved cryptographic algorithm specified by the NIST publication [9]. AES specifies a symmetric block cipher using 128-, 192-, and 256-bit keys to encrypt and decrypt data in 128-bit blocks. The most recent FPGA families build in an AES decryption engine with a key of 256 bits. The above-mentioned FPGA families offer a flexible encryption key storage. They allow to program the key in either dedicated volatile memory, backed up by a small offchip battery, or in one-time-programmable (OTP) fuses. While holding an encryption key, the FPGA cannot be configured
with a bitstream encrypted using another key; because a mismatch between the key in the encrypted bitstream and the key stored in the FPGA causes configuration to fail. Moreover, the configuration of the FPGA with an unencrypted bitstream would be rejected if proper key settings have been enabled. The encryption system, described above, provides FPGA designers with an efficient solution to protect their designs against theft. To prevent reverse-engineering and cloning attacks, the designer (or the customer facility) must keep encryption keys secret. In fact, the secrecy of the encryption key provides the bitstream confidentiality and prevents cloning the key which, in turn, prevents cloning the bitstream. Moreover, this encryption system supports secure remote update of the FPGA design if the encryption key is cautiously stored. In fact, the loss of the encryption key results in two undesirable problems. ∙ It affects the key storage flexibility when the missed key have been programmed into the fuses. Because the fuses can never be re-programmed with a new encryption key and hence one key storage possibility will be missed. ∙ It prevents the secure transmission of an upgraded or new design from the customer facility to its customers (end-users). Indeed, the designer must re-program a new volatile key into the FPGA in the end-user field when a bitstream encryption is required. As a result, the designer has to securely manage the database of encryption keys for protecting his designs from theft. However, the key management process is not an easy task in largescale production, and hence an adequate infrastructure and strategy should be established. Further, the key management issue has not been well-addressed in the FPGA security literature and has not been taken into account when new security systems were proposed. Therefore, the key management is still a big challenge for FPGA security designers. B. Kean’s Scheme The best way to overcome the key management problem in the customer facility is to incorporate both encryption and decryption circuit into the FPGA. In such proposition, encryption keys do not leave the FPGA and hence there is no need to any database of keys. Kean have proposed similar solution in [4], even though the key management was not a high-priority concern for him. Fig. 2 presents the scheme proposed by Kean to protect FPGA design against theft. This scheme involves two configuration steps which are completed in different stages. In the customer facility, an initial configuration is done by the designer that generates an unencrypted bitstream and downloads it on the FPGA via the JTAG interface. Then, the FPGA encrypts the received bitstream using the on-chip key and the built-in encryption circuit, prior to programming the encrypted bitstream into an off-chip FLASH memory. When the system is powered up in the end-user field, a normal configuration is accomplished. The FPGA loads the secure bitstream from the FLASH memory and decrypts it using the on-chip key and the built-in decryption circuit before configuring itself.
Kean proposed employing laser to program the key into the FPGA during manufacture, and using any standard cipher operating in cipher block chaining (CBC) mode to implement the encryption and decryption functions. encryption key
FPGA encryption circuit
JTAG
FLASH
configuration circuit
FLASH encrypted bitstream
encrypted bitstream
configuration memory
A: Initial configuration of FPGA
Fig. 2.
FPGA decryption circuit configuration circuit configuration memory
B: Normal configuration of FPGA
Kean’s scheme for secure FPGA.
Kean’s scheme offers an effective solution to protect FPGA designs from theft with no key management constraint in the customer facility; because the FPGA encrypts and decrypts the bitstream by itself without support from the CAD software and hence designers do not need to keep encryption keys. However, the scheme does not support secure remote update because an upgraded or new design requires to be initially configured within the customer facility. Further, the security circuit embedded into the FPGA includes two different circuits, which decreases the size of the FPGA and hence reduces the number of logic resources reserved for user applications. Consequently, when there is no need for frequently changing the design, Kean’s scheme may be an efficient security solution if its implementation cost could be reduced. For this purpose an enhanced scheme is proposed in the next section for resourceconstrained systems. Notice that we have classified the encryption schemes proposed in the FPGA security literature [10] [11] into two categories depending on whether or not the CAD software supports the encryption process. For that reason, we have limited our related work to only two schemes, one from each category. IV. P ROPOSED FPGA S ECURITY S CHEMES This section proposes two new schemes for resolving the shortcomings of the security systems described in the previous section, by introducing new cryptographic features. The first scheme applies some useful enhancements to Kean’s scheme for reducing the implementation cost of its security circuit. The second scheme takes benefit from asymmetric cryptography to overcome the key management complexity resulted in the commercial FPGA schemes. A. Improved Kean’s Scheme Kean proposed the use of any standard cipher operating in CBC mode to implement the security circuit (encryption and decryption circuits) inside the FPGA. In fact, CBC mode uses two different cipher functions for encryption and decryption processes: a forward cipher function for encryption and an inverse cipher function for decryption. Therefore, the security
circuit involves two cipher functions, which increases the cost of its implementation and hence decreases the FPGA size, compared to the commercial schemes in which only the decryption circuit is built in the FPGA. For reducing the implementation cost of the Kean’s security circuit, another mode of cipher operation, employing the same cipher function for encryption and decryption, should be used instead of CBC mode. According to the NIST special publication [12], cipher feedback (CFB), output feedback (OFB) and counter (CTR) are all modes that use the forward function for both encryption and decryption. Furthermore, for security reasons we propose using the AES stantard to implement the security circuit of the improved scheme shown in Fig. 3 (B). security circuit
security circuit
encryption circuit
decryption circuit
encryption / decryption circuit
forward cipher
inverse cipher
forward cipher
A:
an
c m
Fig. 3.
B: Im ro
c m
Security circuit for FPGA.
To assess the performances of the improved scheme, one should compare the FPGA implementations of distinct AES functions which is not an easy task. In fact, performances of different AES cores should be compared using the same FPGA, same design strategies and same design specifications. However, most published AES implementations implement only AES encryption; some others implement both AES encryption and decryption in a same core; while the implementation of a separate AES decryption is rarely completed. To the best of our knowledge, Rodriquez et al. [13] are the only ones who have presented FPGA implementations of different AES functions, using the same design technique (pipeline) and the same FPGA family (Virtex-E). Table I shows the performances of the FPGA implementation of AES – encryption (Enc), decryption (Dec) and encryption/decryption (Enc/Dec) – functions, as summarized in [13]. It is clear that the AES encryption core is the most compact and fastest core, that is, it occupies a reduced number of FPGA resources and achieves a high throughput. Thus, the security circuit of the improved scheme presents the most efficient implementation compared to the commercial FPGAs and Kean’s schemes . TABLE I C OMPARISON OF AES CORES Core Enc/Dec Enc Dec
Device (XCV) 2600E 812E 812E
Block RAMs 100 100 100
CLB(S ) Slices 5677 2136 3216
Throughput Mbits/s (T) 4121 5193 4949
T/S 0.73 2.43 1.54
As a result, the improved scheme protects FPGA design against theft with no constraint on the key management, as
in Kean’s scheme. In addition, its security circuit presents a more efficient implementation. However, the improved scheme does not support secure remote update. In fact, any change or update of the design requires the intervention of the designer in the field or bringing the system to the customer facility. Therefore, this improved scheme is still limited to cases where the design loaded in the FPGA does not need frequent updates, and hence a scheme supporting secure remote update should be proposed. B. Hybrid Encryption-based Scheme One simple but useful observation is that unlike in symmetric cryptography, data confidentiality in asymmetric cryptography will not be affected when the encryption key (public key) is discovered. Therefore, keeping public key secret is not a big concern for public key schemes and hence no hard constraints on key management will be invoked. Taking advantage of that, this section proposes a second scheme for protecting FPGA designs and supporting secure remote update. The proposed scheme is based on a hybrid encryption mechanism and allows to soften, if not to wholly resolve, the key management problem previously emphasized in the commercial FPGAs. This mechanism combining both symmetric and asymmetric encryption is commonly used in network security applications [14]. In fact, asymmetric algorithms are relatively computationally expensive compared with most symmetric algorithms; which makes them less appealing to embedded systems designers. public key
CAD tool configuration generator encryption software
SY
SY: symmetric
NVM
configuration memory
encrypted bitstream
decryption circuit
e. session key
AS
NVM: non volatile memory CAD: computer−aided design AS: asymmetric
Fig. 4.
FPGA
e: encrypted
SY
AS
Private key
external battery
Proposed hybrid encryption-based scheme
However, their combining in a same cryptosystem is beneficial if asymmetric algorithms are only used to securely share secret keys (session keys) which are then employed to fast encrypt and decrypt data using symmetric algorithms. Fig. 4 gives an illustration of the hybrid encryption-based scheme. The CAD tool incorporates the encryption software for both symmetric (SY) and asymmetric (AS) algorithm while the decryption engines are integrated inside the FPGA in a dedicated hardware. The designer uses the CAD software to generate a public-private key pair before programming the private key in a battery back-up memory into the FPGA via the JTAG interface. Then, the designer selects a session key, with which he encrypts the bitstream file, and encrypts it using the public key. Next, he stores both the encrypted bitstream and the encrypted session key into an off-chip non-volatile
memory. The encrypted session key should be stored such that the FPGA can distinguish it from the configuration bitstream. One possible solution is to store them in different memory locations as shown in Fig. 4. When the system is powered up, the FPGA loads the encrypted session key from the off-chip memory and decrypts it using the private key. Then, the FPGA uses the decrypted session key to decrypt the incoming encrypted bitstream prior to configuring itself. The session key should be used only one time and not be stored in any database in the customer facility. Any symmetric-asymmetric ciphers pair can be used to implement the encryption and decryption functions. The choice of cipher pair is not critical but the AES-RSA or AES-ECC pairs are a reasonable option. In fact, RSA and ECC are two asymmetric encryption standards specified, in the American National Standards [15] and [16], respectively, for digital signature generation and verification. The security of RSA and ECC is much relied on the key length. The longer the key, the more secure the algorithm will be. For resource-constrained embedded systems, it is suitable to use the ECC as asymmetric encryption given that it uses shorter keys than those used by RSA to offer the same level of security. Table. II shows the keys sizes required by RSA and ECC to give a level of security equivalent to that given by AES cipher [17]. TABLE II C IPHERS C OMPARISON Bits of security 128 192 256
AES 128 192 256
RSA 3072 7680 15350
ECC 256-383 384-511 512+
The scheme proposed here protects FPGA designs from theft, relying on the secrecy of the private key. In fact, cloning attacks are prevented because the attacker cannot get the private key and therefore cannot program it into additional FPGA devices, while reverse-engineering attacks are defeated because without the knowledge of the private key the attacker cannot decrypt the session key with which he can decrypt the encrypted design. As the private key is not stored in any database in the customer facility and the FPGA is considered under the assumptions mentioned in Section II, this scheme allows the protection of FPGA designs against theft without any key management constraint in the customer facility. Moreover, for allowing secure remote update, the designer must properly safeguard the public key. However, in asymmetric encryption the public key is only used to encrypt and its secrecy is not a big concern. Thus, making some backup copies of public keys, periodically, is the most easy-to-use solution to prevent keys from loss. In fact, backup technique has already been popularly used in computer systems or in database severs to recover data after its loss. As a result, the hybrid encryption-based scheme provides FPGA designers with a more security-efficient solution compared to the commercial systems: It protects FPGA design
against theft and supports secure remote update with no complex key management process. This scheme could be an effective deterrent to attackers from stealing FPGA designs, if its FPGA implementation will be optimized. V. D ISCUSSION AND C OMPARISON To analyse and compare their performances, the schemes presented above are summarized in Table III. This table specifies the requirements imposed, by each scheme, on key management for protecting FPGA designs from theft and providing secure remote update when supported, as well as it estimates the hardware needed to implement the security block of each scheme. Considering the assumptions, mentioned above in section II, only the customer facility are concerned with meeting the key management constraints outlined in the Table III. This remark is very important to understand the scope of this paper that deals with bitstream security considering the key management problem in the customer facility. In the following, two cases will be discussed according to whether or not remote update is needed. A. No Need for Remote Update The improved Kean’s scheme is the best suited solution to protect the FPGA design when remote update of the design is not needed. In fact, both Kean’s and improved Kean’s scheme prevent reserve-engineering and cloning attacks with no constraint on key management; because the FPGA encrypts and decrypts the bitstream by itself using the in-chip key, and hence encryption key does not need to be stored outside the FPGA in the customer facility. Therefore, FPGA design theft is definitively defeated when using these schemes. However, the improved Kean’s scheme requires only one cipher function to implement its security circuit, which reduces its implementation cost compared to Kean’s scheme. Consequently, the improved Kean’s scheme is the best suited security scheme, especially for resource-constrained systems such as wireless sensor networks. B. Need for Remote Update In cases where remote update of the design is required, it is clear that the hybrid encryption-based scheme is welladapted to security-conscious designers. Indeed, this scheme protects FPGA design against theft with no key constraint, compared to other schemes given by the FPGA manufacturers. Furthermore, to ensure secure remote update (i.e. secure design distribution), the customer facility must safeguard the public key; which is not a big concern for this scheme, since discovering the public key does not affect the security of the scheme, and hence the designer can make some backup copies of the key to recover it after its loss. On the contrary, the disclosure of the key completely affects the security of the FPGA design in the commercial schemes. But these schemes may be suited for cost-conscious designers, particularly for resource-constrained systems.
TABLE III S CHEMES COMPARISON Cloning attack secret key must be not disclosed
Reverse engineering secret key must be not disclosed
Secure remote update secret key must be safeguard from loss
Kean’s scheme
not possible
not possible
not supported
- forward cipher function - inverse cipher functions
Improved Kean’s scheme
not possible
not possible
not supported
- forward cipher function
Hybrid encryption based scheme
not possible
not possible
public key must be safeguard from loss
FPGA vendors (Xilinx and Altera) schemes
C. More Security Improvements The schemes proposed here offer efficient solutions to prevent FPGA design theft, but none of them prevents the tampering attack. In fact, encryption protects the design against theft but does not prevent an attacker from loading a no intended bitstream into the FPGA. The attacker can execute malicious codes on the FPGA with the intent to compromise or shut down the system. Therefore, a strong authentication is required to prevent tampering with the bitstream and to ensure more secure remote update of designs. Xilinx offers a strong bitstream authentication system, in its Virtex-6 FPGAs, based on the FIPS-approved HMAC standard [1] [18]. However, for a reason of resource sharing, another FIPS-approved authentication standard, CMAC [19], should be used to ensure the bitstream authentication in our proposed schemes. In both the improved Kean’s and hybrid encryptionbased schemes, the forward AES function can be shared between encryption and authentication. VI. C ONCLUSION This paper presents two schemes for protecting SRAM FPGA designs against theft. The first suggests some useful improvements to Kean’s scheme with the goal of reducing its implementation cost. These improvements could make the scheme well-suited for resource-constrained systems designers, if no frequent updates of the designs are needed. The second proposes a hybrid cryptographic mechanism to protect FPGA designs from theft while supporting secure remote update of the design. Thanks to asymmetric encryption, the scheme does not require a complex key management process to secure FPGA designs. Despite of the time-consuming inconvenient of asymmetric algorithms, a reasonable choice and proper implementation could make this scheme very efficient. Moreover, with the use of CMAC standard, the proposed schemes can prevent the tampering attack. In the future work, more optimized schemes and detailed implementations of encryption standards will be addressed in order to estimate the performances of the proposed schemes. ACKNOWLEDGMENT Thanks to Steve Trimberger, distinguished engineer at Xilinx Research Labs, for his valuable comments and suggestions.
Hardware cost - inverse cipher function
- SY inverse cipher function - AS inverse cipher function
**
**
**
This work has been performed within the framework of the MBSIE-CPER project with the European Union co-financing. R EFERENCES [1] C. Hu, “Solving Today’s Design Security Concerns,” WP365 (v1.0), June 2010. [Online]. Available: www.xilinx.com [2] ICCCIB, “The International Anti-Counterfeiting Dicrectory 2009,” UK, 2009. [Online]. Available: www.icc-ccs.org [3] T. Barraza, “How to protect intellectual property in FPGAs Devices Part 1,” EE Times, August 2005. [Online]. Available: www.eetimes.com [4] T. Kean, “Secure configuration of field programmable gate arrays,” in Field-Programmable Logic and Applications. Springer, 2001, pp. 142– 151. [5] Altera, “Stratix V device Handbook,” Volume 2, May 2011. [Online]. Available: www.altera.com [6] Xilinx, “7 Series FPGA Configuration User Guide,” UG470 (v1.1), March 2011. [Online]. Available: www.xilinx.com [7] S. Drimer, “Security for volatile FPGAs,” Ph.D. dissertation, University of Cambridge, November 2009. [Online]. Available: http://www.cl.cam. ac.uk/techreports/UCAM-CL-TR-763.pdf [8] M. Moran, “How to implement high-security in low-cost FPGAs,” EE Times, December 2005. [Online]. Available: www.eetimes.com [9] NIST, “Advanced Encryption Standard (AES),” Federal Information Processing Standard, FIPS-197, November 2001. [Online]. Available: www.csrc.nist.gov [10] J. Castillo, P. Huerta, and J. Martinez, “Secure ip downloading for sram fpgas,” Microprocessors and Microsystems, vol. 31, no. 2, pp. 77–86, 2007. [11] L. Bossuet, G. Gogniat, and W. Burleson, “Dynamically configurable security for sram fpga bitstreams,” International Journal of Embedded Systems, vol. 2, no. 1, pp. 73–85, 2006. [12] NIST, “Recommendation for Block Cipher Modes of Operation Methods and Techniques,” NIST Special Publication, SP 800-38A, December 2001. [Online]. Available: www.csrc.nist.gov [13] F. Rodriquez-Henriquez, N. Saqib, A. Díaz-Pérez, and C. Koc, Cryptographic algorithms on reconfigurable hardware. Springer-Verlag New York Inc, 2006. [14] B. Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd ed., P. Sutherland, Ed. New York, NY, USA: John Wiley & Sons, Inc., 1996. [15] ANSI, “ANS X9.31: Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA),” pub-ANSI, 1998. [Online]. Available: www.x9.org [16] ——, “ANS X9.62: Public Key Cryptography for the Financial Services Industry – The elliptic curve digital signature algorithm (ECDSA),” pub-ANSI, 2005. [Online]. Available: www.x9.org [17] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid, “Recommendation for Key Management - Part 1: General,” NIST Special Publication, SP 800-57, March 2007. [Online]. Available: www.csrc.nist.gov [18] S. Trimberger, J. Moore, and W. Lu, “Authenticated encryption for fpga bitstreams,” in Proc. of the 19th ACM/SIGDA international symposium on Field programmable gate arrays. ACM, 2011, pp. 83–86. [19] M. Dworkin, “Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication,” NIST Special Publication, SP 800-38B, May 2005. [Online]. Available: www.csrc.nist.gov
