Implementation of FPGA Bitstream Encryption and Authentication using CCM and EAX Modes of Operation

Milind M. Parelkar

Introduction: Current generation of FPGAs use bitstream encryption as a means of security. Although bitstream encryption prevents unauthorized cloning of the bitstream, there are a few other security scenarios which necessitate adding bitstream authentication to FPGAs in addition to encryption [3,4]. The goal of this project is to extend the already existing research work done in this field. Previous work in this field by this author includes hardware implementation of HMACs using Hash functions. Hash functions implemented were SHA-1, SHA-256 and SHA-512. One of the drawbacks of the used approach is that encryption and authentication both require a pass through different algorithms to ensure security. The solution to this problem is to implement Authenticated Encryption schemes which provide both encryption and authentication using the same block cipher core[1,2].

Authenticated Encryption Schemes: Authenticated encryption schemes can be divided into 2 types; single pass and double pass schemes[2]. In a single pass scheme, only one iteration through a block cipher core provides both encryption and authentication. These schemes include IAPM, OCB and XCBC. Two pass schemes acknowledge the fact that not all data needs to be protected. For example, packet headers etc. can be sent in the clear as long as they are authenticated. Amongst the two-pass schemes put forward, CCM has enjoyed rapid success and is a required mechanism for wireless LANs and personal area networks[1]. EAX is an improvement over CCM taking into consideration a number of factors. For example, CCM is not online; the length of the data must be known beforehand in order to compute the ciphertext and the signature. EAX improves over this property of CCM. The developers of EAX claim that CCM has unnecessary parameterization [2] which leads to inefficient implementation.

Project Goals: The goal of this project is to implement CCM and EAX mode using AES as the block cipher core. The results of hardware implementations of these modes will be compared for different implementation platforms. Targeted platforms include FPGA and ASIC. An already existing implementation of AES will be used as the starting point.

CCM mode: CCM stands for Counter with CBC-MAC. It is only defined for use with 128-bit block ciphers like AES. For a detailed description of the mode, please refer to [1]. A few parameters are explained here for clarity. There are 2 parameter choices, the size of the authentication field (M) and the size of the length field (L). Both L and M are specified in terms of number of octets. The mode also utilizes a Nonce (N) of 15-L octets. Nonce acts as an Initialization Vector (IV). The mode also supports transmission of some additional data which is not encrypted but authenticated. A block diagram for the top level entity of CCM mode is presented here. The signals included in the top level entity might change depending upon further design considerations and implementation efficiency.

A list of interface signals is listed below. Signal Name Mode Bus Width Function Key IN Equal to the width of The secret key is input through the corresponding port this port. of the AES core. Nonce IN 8 bits. Since the size of The Nonce is input through this the Nonce is 15-L port. The Nonce acts as the IV octets, it will always be for this mode. a multiple of 8 bits. M IN 3 bits M indicates the number of octets in the authentication field. L IN 3 bits L indicates the number of octets in the length field. Message IN Equal to the width of The message which has to the corresponding port encrypted and authenticated is of the AES core. input through this port. Additional IN Equal to the width of Additional data (like packet Authenticated Data the message port. headers etc.) which is to be authenticated but not encrypted is input through this port. Input FIFO IN (Not yet designed) Interface signals include signals Interface Signals which are required to perform handshaking operations with the input FIFO. Ciphertext Output OUT Equal to the width of The encrypted output data is the corresponding port available on this port. of the AES core. Authentication OUT Depends upon The message signature is Output parameter M available on this port. Output Valid OUT 1 bit. Output Flag indicating that outputs are valid. Output FIFO OUT (Not yet designed) Interface signals include signals Interface Signals which are required to perform handshaking operations with the output FIFO. Reset IN 1 bit. Master Reset

EAX Mode: A block diagram for EAX mode is shown below. The goal is to design the top-level entity such that it is similar to the top-level entity for CCM mode. The main difference is that the number of parameters specified for CCM mode is more than EAX mode [2]. Hence the top-level entity for EAX mode has fewer signals than CCM mode. All signals in the EAX mode correspond to table entries for corresponding signals in the CCM mode. Additional Authenticated Data in CCM mode is denoted by Header in EAX mode.

Language and Tools: Language: VHDL Tools: • Simulator: Aldec Active HDL v6.2, ModelSim • ASIC Synthesis Tools: Synopsys Design Compiler and related tools • FPGA Synthesis Tools: Synplify Pro v7.6, Xilinx XST v6.x • FPGA Implementation Tool: Xilinx ISE 6.x

Testing: A VHDL testbench will be used to test the operation of the design. Test vectors are provided in the specifications for the modes of operation [1,2].

Optimization Criteria: One of the optimization criteria would be minimum area. Since the authentication core would consume some real estate on the FPGA, it should not lead to a large area overhead. Maximizing the throughput would also be an important criterion. Hence the aim would be to achieve the maximum throughput to area ratio.

Possible Changes in the Specification: A possible change would be the addition of some extra control signals in the top level entity of the design. Since the circuit has not been completely designed at this stage, it is difficult to accurately include all possible control signals.

References: 1. Counter with CBC-MAC (CCM), Submission to NIST, CryptoToolkit, available at http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ccm/ccm.pdf 2. EAX mode Specifications, Available at http://www.cs.ucdavis.edu/~rogaway/papers/eax.pdf 3. Is Your FPGA Design Secure? – XCell Journal Online, available at http://www.xilinx.com/publications/xcellonline/xcell_47/xc_secure47.htm 4. Security Scenarios, available at http://www.actel.com/documents/SecurityScenarios.pdf 5. Design Security in Nonvolatile Flash and Antifuse FPGAs, available at www.actel.com/documents/DesignSecurity.pdf 6. A Whitepaper of SRAM FPGA Security, Ray Schouten, available at http://www.fpga.com.cn/advance/skill/SRAM_Security_whitepaper.pdf