The 2010 Military Communications Conference - Unclassified Program - Cyber Security and Network Management

FPGA-Based, Multi-Processor HW-SW System for Single-Chip Crypto Applications

Andrew Fitzgerald , Marcin ukowiak , Michael Kurdziel , Christopher Mackey , Kenneth Smith Jr , Brian Boorman , Duncan Harris , and William Skiba
of Computer Engineering Rochester Institute of Technology, Rochester, NY 146235698 Harris Corporation, RF Communications Division Rochester, NY 14610-1887 Email: {andrew.tzgerald@harris.com, mxleec@rit.edu}
AbstractThis paper discusses design and analysis of an FPGA-based system containing two isolated, Altera Nios II softcore processors that share data through two custom cryptoengines. FPGA-based Single-Chip Cryptographic (SCC) techniques were employed to ensure full red/black separation. Each crypto-engine is a hardware implementation of the Advanced Encryption Standard (AES), operating in Galois/Counter mode (GCM). The features of the AES crypto-engines were varied with the goal of determining which best achieve high performance or minimal hardware usage. To quantify the costs of red/black separation, a thorough analysis of resource requirements was performed. The hardware/software approach was utilized in order to provide appropriate levels of exibilty and performance, allowing for a range of target applications.
Department

I. I NTRODUCTION To facilitate the implementation of Single-Chip Cryptographic (SCC) systems, the Field Programmable Gate Array (FPGA) industry recently developed new families of devices. New features added include anti-tamper monitoring, bit stream encryption, and optimized routing architectures for physical and functional logic partition isolation [1]. The implementation of Type-1 cryptographic equipment is one exemplary application that can benet from utilizing these devices, as more functionality can be embedded into a single FPGA chip and still meet classied Fail-Safe Design and Analysis (FSDA) requirements [1], [2]. The amount of logic and memory available in these secured FPGAs is comparable to that offered by modern unsecured FPGAs, which enables a secured FPGA to utilize Intellectual Property (IP) originally employed by unsecured platforms. This includes microprocessor IP cores, allowing for an unprecedented level of hardware and software interaction within a single FPGA chip. In this paper we present a study on red/black hardware/software systems for secured FPGAs. The reference implementation created in this work is a red/black separated, FPGA-based system containing two isolated, softcore Nios II processors that share data through two crypto-engines. The hardware/software approach was utilized in order to provide appropriate levels of exibilty and performance, allowing for a range of target applications. FPGA-based SCC techniques were employed to ensure proper component isolation when

placed on a device supporting the appropriate security primitives. Each crypto-engine is a parameterized custom hardware implementation of the Advanced Encryption Standard (AES) [3], operating in Galois/Counter mode (GCM) [4]. The AES components support the 128, 192 and 256-bit key lengths. The GCM hashing component features a generic GF(2128 ) multiplier that can increase the parallelization in the product calculation from bit serial up to a full parallel implementation by powers of two. The base functionality of the system was veried on an Altera Cyclone III (EP3C120) FPGA. The nal design was synthesized for a Cyclone III LS (EP3CLS70) FPGA, fully incorporating the security features of the device. The synthesis results were compared to quantify the increased resource utilization found in the secured implementation. This includes resources used as a border between secured regions and resources allocated to a secured region, but not necessarily utilized. II. D ESIGN OVERVIEW The top level architecture of the designed system is presented in Figure 1. The red subsystem, black subsystem, and the GCM engines are designed as separate, secured partitions. As such, data may only pass through security routing interfaces (SRIs), located on the borders between regions. The number of signals passing between regions was minimized to reduce the number of interconnections that needed to be routed through these interfaces. Signals passing between secured regions were registered both on their inputs and the outputs in an effort to mitigate timing problems within the FPGA. The numbered callouts in Figure 1 indicate: 1) two SRIs bounding unencrypted data signals that connect the red subsystem and the GCM engines, 2) a fence of unused logic bordering a secured partition, and 3) two SRIs bounding encrypted data signals that connect the black subsystem and the GCM engines. The ow of data in an encryption operation is as follows: 1) data is received by the red subsystems off-chip communication inputs, 2) processed by the red subsystems Nios II processor, 3) transferred to the GCM encryption engine through memory-mapped GCM interface registers, 4) read by

978-1-4244-8180-4/10/$26.00 2010 IEEE

1317

Altera Cyclone III FPGA

Red Subsystem Partition System Interconnect Fabric Off-chip Communication I/O GCM Decrypt Interface Registers GCM Encrypt Interface Registers Black Subsystem Partition System Interconnect Fabric Off-chip Communication I/O GCM Decrypt Interface Registers GCM Encrypt Interface Registers

Nios II Processor Core

Nios II Processor Core

GCM Encryption Engine Partition Black Interface Registers Red Interface Registers GCM Controller

AES Encrypt

GF(2128) Multiplier

GCM Decryption Engine Partition Black Interface Registers Red Interface Registers GCM Controller

GF(2128) Multiplier

AES Decrypt

Fig. 1.

Dataow diagram of FPGA-based, multi-processor HW-SW system with AES GCM encryption and decryption engines.

the black subsystems Nios II processor through memorymapped GCM interface registers, and 5) sent out through the black subsystems off-chip outputs. In a decryption operation, data ows through the GCM decryption engine in the opposite direction, starting from the black subsystem. The black subsystem is also responsible for reading and writing the authentication tag. The red subsystem is solely responsible for the initialization and key management of the GCM engines. III. R ELATED W ORK This section summarizes the relevent related work in hardware implementations of the Advanced Encryption Standard (AES) and architectures for AES operating in Galois/Counter mode (GCM). A. Advanced Encryption Standard Since Rijndael was submitted as a candidate algorithm for AES [5], there has been a great body of work exploring its security, performance, implementability, and exibility. Once standardized, it became the rst public algorithm approved for use in systems intended to protect classied data [6]. Hardware implementations of AES vary greatly in their architectures in order to better target particular performance or hardware usage metrics. Early high performance architectures targeted the T-box approach, where one entire round of AES is replaced with 8 Kilobits of lookup tables (LUTs) or memory [5], [7][9]. Later approaches focused on unrolling and pipelining a number of rounds [10]. In contrast, the iterative

round structure of AES allows small area implementations to operate with reduced datapath widths. This was explored in [11][14]. Apart from high level organization, AES designs vary particularly in the SubBytes implementation: 1) as a table in memory [7][11], 2) as combinational logic implementing calculations in GF(28 ) [12], [15], or 3) as combinational logic utilizing the composite eld technique [11], [13], [16][22]. B. Galois/Counter Mode GCM is an algorithm that provides both encryption, using a NIST approved block cipher, and authentication, using a specied GHASH function [4], [23]. The implementations of GCM explored in this section exclusively target AES as the block cipher algorithm. The main operation of GHASH is to accumulate (hash) blocks of already encrypted data through GF(2128 ) multiplication. The constant operand to this multiplication is H, which is a 128-bit block of zeroes that has been encrypted using the private key. A variety of techniques have been applied in the design of the GF(2128 ) multiplier required by the GHASH component. [24] utilizes a Mastrovito parallel multiplier implemented in combinational logic for this calculation. Although a product is created in one clock cycle in this implementation, the large depth of this circuit forms the critical path of the entire GCM implementation. Two GHASH designs are implemented in [25]: a parallel calculation performed in one clock cycle and an iterative calcu-

1318

GCM GCTR AES KEY EXPANSION

H Register

CIRCUIT OUTPUTS
128

IV Registers Temp Registers Expansion Logic Data Output Registers (CT/PT) Expanded Key Memory Y0 Encrypted Register Hash Register (Tag)
128 128

Output

Data Input Registers (AAD) AAD Len | CT Len registers

+1

IV Cntr Register

AES ENCRYPT
32

Input

32

IV Registers

128 96

Encryption Logic

Data Output Registers

128

0 Data Input Registers 0 PT/CT

128

AAD Len Registers Ciphertext Register

64

GF(2128) Multiplier Hash Register

CT Len Registers

64

GHASH

Fig. 2.

A high-level diagram illustrating the individual GCM components and their interconnections.

lation through four sequential 128-bit x 32-bit multiplications stored in a partial product register. This iterative calculation reduces the GHASH multiplier hardware requirements by a factor of four. [26] improves upon the throughput in [25] by using the interleaved data parallelization of the GHASH function suggested in [23]. [26] further generalizes [23]s suggestion from a two-parallel block architecture to a four-parallel block architecture. Building on [26], [27] performs four 128-bit by 32-bit pipelined digit-serial multiplications in GHASH. This shortens the original GHASH critical path from [26], increasing the maximum operating frequency of the circuit. In [28], the GF(2128 ) multiplier was implemented as bitparallel; digit-serial and as a hybrid, where a composite eld GF((216 )8 ) allows a 16-bit multiplier to complete the multiplication. [28] found that the hybrid multiplier was larger and slower than a digit serial approach on an FPGA, likely due to the selected irreducible polynomial for the composite eld. In [29], two high performance GCM designs were created where the GF(2128 ) multiplier was implemented in bit parallel fashion for performance and using Karatsubas algorithm for a more area efcient design. [30] improves on this by using a 4 stage pipelined Karatsuba-Ofman based multiplier in the GHASH component. As stated in [30], this approach for the multiplier has reduced complexity when compared to the approach in [27] by reducing hardware area requirements. [30] achieved a higher max operating frequency than their previous work in [29] and a three times better throughput to area ratio than [28]s three key length supporting implementation. IV. P ROJECT D ESIGN All implementations of GCM in this work utilize a 96bit Initialization Vector (IV), as recommended by the NIST standard [4] for efciency purposes [24]. The engine supports data in lengths that are multiples of the AES block size and

the length of the data must be provided externally to the engine. This approach was selected to better complement the microprocessors in the system, which can trivially pad the data as necessary. For decryption, the GHASH and plaintext can be computed in parallel since the ciphertext is already known, illustrated in [24]. All decryption implementations in this work take advantage of this parallelism. Figure 2 illustrates the high-level architecture of the GCM engines. The dark blue blocks indicate memory and the light blue blocks indicate logic or subcomponents. The outputs of the engine are grouped at the far right of the diagram for simplicity. The thick black interconnection indicates a signal that is only used during encryption. The thick red interconnection indicates a signal that is only used during decryption. The AES encryption and key schedule logic is used both in the main datapath for encryption and for the calculation of H, as was also done in [26]. The GCM engines were interfaced to the processors using an Avalon memory-mapped interface. Control, status, and conguration registers were incorporated into the top level GCM interface. The control register strobes the appropriate component control signals and the conguration register stores the key length and encrypt/decrypt mode of the engine. A. Small Area Implementation The small area implementation in this work focused on using a 32-bit datapath for the AES key schedule and encryption components. The key schedule was based upon the ofine 32-bit iterative version featured in [31]. Modications were made to the design to support all three AES key lengths. The AES 32-bit encryption implementation is a simple word iterative design. The round keys are stored in on-chip memory, addressable by 32-bit words. The GF(2128 ) multiplier in the GHASH component was implemented in bit serial fashion: multiplying and accumulating

1319

one bit of the input data by the 128-bit H value sequentially for 128 clock cycles. The high-level architecture differs from Figure 2 in the additional logic required by the GHASH component to accumulate the partial products. B. Performance Implementation This performance implementation targets a 128-bit datapath. The implementation of AES is based on a round iterative design, where the round keys are read out of on-chip memory. These round keys are placed into on-chip memory by an ofine key schedule. This key schedule was adapted from [25] to make better use of FPGA resources. The on-chip memory is organized such that it is addressable by 128-bit blocks. This allows one entire round key to be read or written in one cycle. The key schedule and encryption components were designed to support all three AES key lengths. The GHASH multiplier is implemented using the sequential multiply and add approach from [27]. In this approach, a result is calculated in 16 clock cycles by sequential multiply and accumulate operations using one 128-bit operand and one byte operand. The GHASH component in Figure 2 would requires an additional register and several multiplexors to compute the partial product needed by the sequential multiply and accumulate approach. V. E XPERIMENTAL R ESULTS The performance results of system conguration with 256bit AES key are shown in Table I. The packet size is the amount of encrypted data that is processed by the GCM engine before an authentication tag is generated. Functionality was veried for proper handling of the Additional Authenticated Data (AAD), but AAD processing was not included in the performance tests. The architectures and peripherals of the two Nios II/e processors were consistent through every test. The GCM implementations in this work were able to make efcient use of the available FPGA resources because of the use of true dual-port memory for the S-Boxes and the expanded key memory. The small area implementation had a maximum frequency that was over 20 MHz faster than that of the high performance implementation; however, the high performance implementation had a signicantly higher throughput. The reason for this is that the high performance implementation produces 128-bit results, while the small area approach produces 32-bit results. The difference in the maximum clock frequencies was not enough to allow the small area approach to achieve a higher throughput. Implementation oorplans for the Cyclone III LS (EP3CLS70) can be seen in Figure 3. In these gures, labels one and two identify the red and black subsystem partitions respectively. Labels three and four identify the GCM encryption and decryption engine partitions respectively. The darker shaded blocks are utilized resources, except on the borders of secured regions. These are fences of unused logic where no routing connections are permitted. The small lightly shaded regions containing no logic between secured regions are SRIs that allow routing to pass between regions. The strips passing vertically throughout the FPGA are M9K memory elements

TABLE I 256- BIT AES, S INGLE GCM E NGINE P ERFORMANCE S TATISTICS Target App. Small Perf. AES Width (bits) 32 128 AES S-Box Arch M9K M9K GHASH Arch Bit serial 16-Sequen. GCM Max Freq. (MHz) 119 97.0 128-bit Pckt. Th/put (Mbps) 58.1 327 2K-bit Pckt. Th/put (Mbps) 110 645

and embedded multipliers. It is important to note that the unallocated space is where the global signals are input to the global routing structures for distribution throughout the entire FPGA. A. Secure Partitioning Costs In this work, the designs were rst functionally veried on a Cyclone III device and the nal designs were synthesized for a Cyclone III LS device. While the implemented hardware is functionally equivalent, additional resources were necessary to satisfy the security requirements on the LS device. Table II illustrates the total utilized logic elements (LEs) and M9Ks out of the total allocated for a particular secured region. Together the size and position of the secured regions 1) dictate the amount of resources available to a region, 2) set the timing of on-chip and off-chip data transfers to and from regions, and 3) limit the available routing paths between secured partitions. Each secured region is also a logical partition in itself, which prevents optimizations that would have taken place at the partition boundaries [32]. As such, these secured regions are highly design and platform dependent. To allow conclusions to be drawn more easily, the sizes of the secured regions were xed for a given target application. For the high performance implementation in Figure 3b, overhead costs include 3664 LEs, 15 M9Ks, and 16 embedded multipliers that must remain unused to form the borders between secured regions. SRIs may only contain routing, thus the 2512 LEs, 12 M9Ks, and 16 embedded multipliers contained within SRIs are allocated, but not utilized. Taking these gures into account, this leaves 61376 LEs, 252 M9Ks and 188 embedded multipliers free for use as global logic. An additional concern when choosing the size of a secured region is routability. [33] species that the minimum size of a secured region is 8x8 logic array blocks (LABs), else the possiblity exists that routing would need to protrude beyond the regions borders to connect to each LAB. The width of an SRI is also recommended to be 12 LABs when signals are passing up or down and 17 LABs when signals are passing left or right within the FPGA. The encryption and decryption partitions pass 78 connections vertically, necessitating an 8 LAB width. The red and black partitions have 186 connections each to the Altera JTAG Hub, requiring 16 LABs for vertical connections. The nal size was selected to be 10 LABs for vertical and 5 LABs for horizontal, yielding a value of 205 possible connections. This minimum recommended region size

1320

TABLE II S ECURED REGION RESOURCE UTILIZATION STATISTICS GCM Engine Partion Allocated Utilization M9K LEs M9K LEs (#) (#) (%) (%) 26 30 4160 6240 27 47 76 75 Red/Blk Subsystem Partition Utilized Allocated Utilization M9K LEs M9K LEs M9K LEs (#) (#) (#) (#) (%) (%) 22 22 1596 1636 51 60 7856 9488 43 37 20 18

Target App. Small Perf.

AES Width (bits) 32 128

AES S-Box Arch M9K M9K

GHASH Arch Bit serial 16-Sequen.

Utilized M9K LEs (#) (#) 7 14

3170 4682

(a) Fig. 3.

(b)

Small area (3a) and high performance (3b) implementation oorplans for the EP3CLS70 FPGA.

contributes signicantly to the excessive height of the red and black partitions. The I/O banks available for global logic are limited in a secured design because I/O banks may not be shared by secured regions [33]. In this work, one free bank was utilized at the global level to provide the system clock and reset inputs. Excluding the Altera JTAG interface signals, no other I/O banks were utilized. Designing for the previously mentioned constraints resulted in an ineffecient use of FPGA resources within the secured regions. The reference design for this project utilized the Altera JTAG connection for input and output to the systems. This restricted the oorplan such that the red and black subsystem partitions both needed to connect to the JTAG signals, obscured by the black box in Figure 3. In a practial application, a designer would assign pins such that data could ow across the FPGA, removing the need for excessive logic to be allocated for circuitous routing.

VI. C ONCLUSION

In this work, a red/black separated system was designed with independent encryption and decryption implementations of GCM using AES to pass authenticated and encrypted information between two Nios II processors. The implementations of this system were evaluated on a Cyclone III LS (EP3CLS70) FPGA based on the metrics of high performance and low resource usage. An analysis of resource utilization was performed, yielding the additional cost of red/black separation on this platform. FPGA hardware designers with a need for high security should be able to use this work to assist in selecting component architectures that best meet their performance or resource requirements. Future high performance designs based on this work could explore pipelined approaches or passing data directly to the hardware engines from the input and output. Small area approaches could benet from an 8-bit datapath or a T-box approach for further reduction in required resources.

1321

R EFERENCES
[1] P. Quintana, Fail-Safe FPGA Design Features for High-Reliability Systems, in Military Communications Conference, 2009. MILCOM 2009. IEEE, (101 Innovation Drive, San Jose, CA), pp. 17, Altera Corporation, Oct. 2009. [2] D. Harris, J. Fitton, and C. Mackey, High Assurance Multiplexer Techniques for use with Secure Digital Communications, in Military Communications Conference, 2008. MILCOM 2008. IEEE, (1680 University Avenue, Rochester, NY), p. 1, Harris Corporation, RF Communications Division, November 2008. [3] National Institute of Standards and Technology (NIST), Specication for the Advanced Encryption Standard (AES). Federal Information Processing Standards Publication 197, 2001. [4] M. Dworkin, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, NIST Special Publication 800-38D, National Institute of Standards and Technology (NIST), Gaithersburg, MD 20899-8930, USA, November 2007. [5] J. Daemen and V. Rijmen, AES Proposal: Rijndael, March 1999. [6] L. Hathaway, National Policy on the Use of the Advanced Encryption Standard (AES) to Protect National Security Systems and National Security Information. Online, June 2003. CNSS Policy No. 15, Fact Sheet No. 1. [7] M. McLoone and J. McCanny, Rijndael FPGA Implementation Utilizing Look-up Tables, in Signal Processing Systems, 2001 IEEE Workshop on, pp. 349360, September 2001. [8] V. Fischer and M. Drutarovsk, Two Methods of Rijndael Implementation in Recongurable Hardware, in Cryptographic Hardware and Embedded Systems CHES 2001, vol. 2162 of Lecture Notes in Computer Science, pp. 7792, Springer Berlin / Heidelberg, 2001. [9] M. Alam, W. Badawy, and G. Jullien, A Novel Pipelined Threads Architecture for AES Encryption Algorithm, pp. 296302, 2002. [10] N. Weaver and J. Wawrzynek, High Performance, Compact AES Implementations in Xilinx FPGAs, tech. rep., U.C. Berkely BRASS group, September 2002. [11] T. Good and M. Benaissa, AES on FPGA from the Fastest to the Smallest, in Cryptographic Hardware and Embedded Systems CHES 2005, vol. 3659 of Lecture Notes in Computer Science, pp. 427440, Springer Berlin / Heidelberg, 2005. [12] M. Feldhofer, J. Wolkerstorfer, and V. Rijmen, AES implementation on a grain of sand, Information Security, IEE Proceedings, vol. 152, pp. 1320, Oct. 2005. [13] P. Hamalainen, T. Alho, M. Hannikainen, and T. Hamalainen, Design and Implementation of Low-Area and Low-Power AES Encryption Hardware Core, in Digital System Design: Architectures, Methods and Tools, 2006. DSD 2006. 9th EUROMICRO Conference on, pp. 577583, 2006. [14] T. Good and M. Benaissa, Very Small FPGA Application-Specic Instruction Processor for AES, Circuits and Systems I: Regular Papers, IEEE Transactions on, vol. 53, pp. 14771486, July 2006. [15] J. Wolkerstorfer, E. Oswald, and M. Lamberger, An ASIC Implementation of the AES SBoxes, in Topics in Cryptology CT-RSA 2002, vol. 2271 of Lecture Notes in Computer Science, pp. 6778, Springer Berlin / Heidelberg, 2002. [16] V. Rijmen, Efcient Implementation of the Rijndael S-box, 2000. [17] A. Rudra, P. Dubey, C. Jutla, V. Kumar, J. Rao, and P. Rohatgi, Efcient Rijndael Encryption Implementation with Composite Field Arithmetic, in Cryptographic Hardware and Embedded Systems CHES 2001, vol. 2162 of Lecture Notes in Computer Science, pp. 171184, Springer Berlin / Heidelberg, 2001. [18] A. Satoh, S. Morioka, K. Takano, and S. Munetoh, A Compact Rijndael Hardware Architecture with S-Box Optimization, in Advances in Cryptology ASIACRYPT 2001, vol. 2248 of Lecture Notes in Computer Science, pp. 239254, Springer Berlin / Heidelberg, 2001. [19] K. J rvinen, M. Tommiska, and J. Skytt , A Fully Pipelined Mema a oryless 17.8 Gbps AES-128 Encryptor, in FPGA 03: Proceedings of the 2003 ACM/SIGDA eleventh international symposium on Field programmable gate arrays, (New York, NY, USA), pp. 207215, ACM, 2003. [20] X. Zhang and K. Parhi, High-Speed VLSI Architectures for the AES Algorithm, IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 12, no. 9, pp. 957967, 2004.

[21] X. Zhang and K. Parhi, On the Optimum Constructions of Composite Field for the AES Algorithm, Circuits and Systems II: Express Briefs, IEEE Transactions on, vol. 53, pp. 11531157, Oct. 2006. [22] R. Liu and K. Parhi, Fast Composite Field S-Box Architectures for Advanced Encryption Standard, in GLSVLSI 08: Proceedings of the 18th ACM Great Lakes symposium on VLSI, (New York, NY, USA), pp. 6570, ACM, 2008. [23] D. McGrew and J. Viega, The Galois/Counter Mode of Operation (GCM), May 2005. [24] B. Yang, S. Mishra, and R. Karri, A High Speed Architecture for Galois/Counter Mode of Operation (GCM). Cryptology ePrint Archive, Report 2005/146, 2005. [25] A. Satoh, High-Speed Hardware Architectures for Authenticated Encryption Mode GCM, in Circuits and Systems, 2006. ISCAS 2006. Proceedings. 2006 IEEE International Symposium on, pp. 48314834, May 2006. [26] A. Satoh, High-Speed Parallel Hardware Architecture for Galois Counter Mode, in Circuits and Systems, 2007. ISCAS 2007. IEEE International Symposium on, pp. 18631866, May 2007. [27] A. Satoh, T. Sugawara, and T. Aoki, High-Speed Pipelined Hardware Architecture for Galois Counter Mode, in Information Security, vol. 4779 of Lecture Notes in Computer Science, pp. 118129, Springer Berlin / Heidelberg, 2007. [28] S. Lemsitzer, J. Wolkerstorfer, N. Felber, and M. Braendli, Multigigabit GCM-AES Architecture Optimized for FPGAs, in Cryptographic Hardware and Embedded Systems - CHES 2007, vol. 4727 of Lecture Notes in Computer Science, pp. 227238, Springer Berlin / Heidelberg, 2007. [29] G. Zhou, H. Michalik, and L. Hinsenkamp, Efcient and HighThroughput Implementations of AES-GCM on FPGAs, in FieldProgrammable Technology, 2007. ICFPT 2007. International Conference on, pp. 185192, Dec. 2007. [30] G. Zhou, H. Michalik, and L. Hinsenkamp, Improving throughput of AES-GCM with pipelined karatsuba multipliers on FPGAs, in Recongurable Computing: Architectures, Tools and Applications, vol. 5453 of Lecture Notes in Computer Science, pp. 193203, Springer Berlin / Heidelberg, 2009. [31] P. Chodowiec and K. Gaj, Very Compact FPGA Implementation of the AES Algorithm, in Cryptographic Hardware and Embedded Systems CHES 2003, vol. 2779 of Lecture Notes in Computer Science, pp. 319 333, Springer Berlin / Heidelberg, 2003. [32] Altera Corporation, 101 Innovation Drive, San Jose, CA, Quartus II Handbook, December 2009. QII5V1-9.1.1. [33] Altera Corporation, 101 Innovation Drive, San Jose, CA, Quartus II Design Separation Flow, June 2009. AN 569.

1322