Implementation and Analysis of the PRIMATEs Family of Authenticated Ciphers

Transcription

1 Implementation and Analysis of the PRIMATEs Family of Authenticated Ciphers Ahmed Ferozpuri Abstract Lightweight devices used for encrypted communication require a scheme that can operate in a low resource environment where it may be required to produce decrypted text without verification, to provide resistance to a non-unique nonce and DPA side channel attacks. Such a scheme is provided by the PRIMATEs family of authenticated ciphers. This paper will compare; the hardware implementation of the PRIMATEs, the hardware and software performance, and benchmarking / optimization results. In order to verify the hardware implementation is valid, the results were matched with the output of the C-code implementation. Additionally, execution of the software on an ultra-low power TI MSP microcontroller was analyzed and compared to the hardware timing. The comparison will also provide an FPGA resource utilization summary with timing analysis, and benchmarking results in different FPGA implementations. The results will show how PRIMATEs perform in different environments, comparatively to each other and other algorithms. Index Terms Authenticated Encryption, ATHENa, CAESAR, duplex, FPGA, hardware, lightweight, misuse resistance, PRIMATEs, sponge, duplex I. INTRODUCTION Authenticated Encryption (AE) is an encryption scheme that allows data communication with both privacy and authenticity. For lightweight communication devices AE is a valuable tool, but resource costs are a primary concern, and any AE scheme in this environment must offer a low resource cost with sufficient throughput. Offering both 80-bit and 120- bit mode, the PRIMATEs family of authenticated ciphers offers AE at low resource costs. According to the definition of AE, no message block should be released until the tag is verified. Unfortunately, this is only possible after the entire ciphertext is processed and would require buffering the entire message, which may not be possible with limited memory. The PRIMATEs construction allows for the Release of Unverified Plaintext (RUP), which accommodates such low memory environments. Additionally, the internal state can be either 200 or 280 bits, which leave a small memory footprint during execution and also minimizes processor usage. This paper was submitted on December 7, 2014 for peer review at George Mason University (GMU). The next few paragraphs should contain the authors current affiliations, including current address and . A. Q. Ferozpuri is currently a graduate student at GMU, Fairfax, VA. A. The PRIMATEs Family of Authenticated Ciphers The PRIMATEs family of authenticated ciphers is designed for lightweight cryptographic targets, where resources are limited and efficiency is of paramount concern. There are three modes of operation in the PRIMATEs family: APE, HANUMAN, and GIBBON, with two security levels: 80 and 120 bits. The three modes of operation have trade-offs in security and performance. The most secure mode is APE, but both APE and HANUMAN are provably secure. On the other hand, GIBBON is intended for lightweight applications, where speed, area, cost, power and energy are paramount, and a security proof is not required. The duplex sponge construction of the algorithms, enables either producing an output after a permutation on the input or simultaneously. In both cases, it is possible to perform RUP. B. Duplex Sponge Structure A sponge transformation used a fixed-length permutation with a padding rule to map a variable length input to a variable length output. In the case of AE, this is a very useful property because there can be many input blocks that produce corresponding output blocks based on the sponge transformation. During the input process, data is absorbed like a sponge into different permutation blocks and after all stages of input are complete, the squeezing begins where output can be taken. This process is shown below in Figure 1. Figure 1 - The Sponge Construction. Source [1]. The duplex sponge transformation has the same properties of the sponge transformation, except data is ready immediately after the permuted input - see Figure 2.

2 Figure 2 - The Duplex Sponge Construction. Source [1]. The inspiration for APE came from SpongeWrap[4], but it differs in that the output is taken directly from the state as opposed to key stream generation for encryption. PRIMATEs use this duplex sponge structure, which allows for the RUP and receiving an output block right after the input. The sponge construction of PRIMATEs follows Figure 2 for APE, however, HANUMAN and GIBBON use a modified construction, shown in Figure 3. Figure 3 - Modified Duplex Sponge. Source [2]. The sponge structure of the PRIMATEs family facilitates RUP and efficient stream processing. The permutations shown above are p 1 and p 4, and each take 12 rounds. Therefore, APE will ideally take 12 cycles to produce the output block, where HANUMAN and GIBBON can give the result in the same clock cycle. However, before the next input can be processed for the latter two the corresponding permutation must be completed first. C. The PRIMATE Permutation The internal state of APE, V, is either a 5 8 or 7 8 matrix consisting of 5-bit blocks or elements totaling either 200 or 280 bit. The first row of this matrix in either case in known as V r, or the rate portion of the state, and the remaining elements are the capacity, V c. All permutations are performed on V, and the output is taken from V r when required. Figure 4 below illustrates the state matrix in 200-bit mode. Figure bit 5 5 State Matrix There are four transformations performed in one round: SubElements (SE), ShiftRows (SR), MixColumns (MC), and ConstantAddition (CA). The order of PRIMATE transformation is SE SR MC CA, and the inverse permutation is CA -1 MC -1 SR -1 SE -1. Only APE uses the inverse permutation during decryption. SubElements is a 5-bit S-box transformation on each element, SR shifts rows with a different constant, MC follows a wide trail strategy, and CA generates a round constant using a Fibonacci Linear Feedback Shift Register (LFSR). In the hardware implementation, the PRIMATE permutation block is called PN, which represents all possible permutations for each PRIMATE algorithm - including inverse mode. These permutations differ in the number of rounds, either 6 or 12, and the initial value of the LFSR - see [2] for a complete description of the PRIMATE permutation. D. The APE PRIMATE APE has the most security features and also offers input key and IV sizes of either 160 or 240 bits. The APE PRIMATE permutation requires 12 rounds to produce an output and permutes over each block in the initialization vector (IV), associated data (AD), and message or cipher text. Permutation over the IV is unique to APE in the PRIMATEs family, and this property allows for nonce misuse resistance. In fact, APE is claimed to be the first permutation-based and nonce misuse resistant authenticated encryption scheme[3]. Also, because the nonce is treated the same as associated data, it is not strictly required. The security features of APE comparatively cost more in hardware due to more multiplexed logic required as input to PN, and additional control logic for decryption. Additionally, in order to execute decryption, PN must be capable of operating in both normal and reverse order requiring the instantiation of both regular and inverse permutations. This makes the dual mode PN comparatively larger by 4 permutation blocks. Although the area in hardware would be larger because of this, the throughput should not suffer since either permutation path can be chosen. E. The HANUMAN and GIBBON PRIMATEs Both the HANUMAN and GIBBON PRIMATEs share the same duplex sponge construction, offer less security features, and require no inverse permutations. In fact, the algorithm for both encryption and decryption are nearly identical. The nonce must be unique in both algorithms to achieve confidentiality or the XOR of the first message blocks can be determined from the XOR of the ciphertext blocks. The associated data is processed in an independent permutation, which helps to prevent against forgery attacks. However, attacks can be found if a collision occurs in the capacity part of the state, but only after approximately 2 c/2 steps of the permutation, where c is the capacity [2]. II. HARDWARE DESIGN OVERVIEW In order to simulate the PRIMATE cipher, a top level interface was implemented to receive blocks of 40 bits from a public and secret FIFO and the results were sent to an output

3 FIFO. Figure 5 shows a diagram of the top level unit with associated FIFOs used in the design and simulation for verification. This scheme allows the removal of any ambiguity between comparisons of the different algorithms and allowed for a practical testing scenario. PN in the hardware design, and consists of the sequence SE SR MC CA, with inverse mode capability. However, the inverse mode is only instantiated for APE decryption. Figure 7 - General Datapath Approach Figure 5 - Top Level Interface[5] A closer look in to the Cipher Core block, illustrated below in Figure 6, shows the separation between the actual PRIMATE Cipher (PC) and the Data Processor (DP), which is used to interface with the I/O FIFOs. The PC has access to all required data and is controlled by 5 sync signals and produces a done signal when the current permutation is complete. This design allows for isolation of the cipher and facilitates analysis. B. Algorithm Flow Control Design Ideally during data processing, a block of data is read and processed as soon as it is available, unless the PC requires some intermediate processing on the state. In the latter case, data from the FIFO must not be read. In order to separate the data processing flow control from the algorithm flow control the approach shown below in Figure 8 was used. Figure 8 - General Control Approach The Data Flow Ctrl block has control parameters that indicate to the FIFO Driver what type of processing will be required for IV, AD, M/C, and Tag segments. The format of data communication is shown below in Figure 9. A. Cipher Datapath Design Figure 6 - Inside the Cipher Core The datapath of all PRIMATEs was designed using the same general method shown below in Figure 7. There are n functions denoted f n of (K, IV, X, T_i, and p o ), where K is the key, IV is the nonce, X is either a message or ciphertext block, and T_i is the input tag. These functions are multiplexed in to a registered transformation, which produce outputs that can be used as feedback. The output, Y, is either a message or ciphertext block and along with the T_o, the output tag, they can be used as required. This interface can also be verified in Figure 6, and was used to design each PRIMATE. The registered transformation is the permutation block, known as Figure 9 - Cipher Core Communication Format During data processing, it was assumed that these segments will always be in the order shown in Figure 9. As shown in Figure 8, the Algorithm Flow Ctrl block is located inside the CIPHER, which corresponds to PC. Separation of the Algorithm Flow Ctrl facilitated analysis of each PRIMATE algorithm s control independently.

4 III. HARDWARE VERIFICATION In order to verify the functional correctness each PRIMATE hardware implementation, waveforms were generated and compared to the corresponding output from the reference C implementation with the same stimuli. Additionally, all combinations of empty AD and message/ciphertext block data segments were verified for each PRIMATE. The order of verification was to start with the smallest components, and then PN, and finally the datapath for each PRIMATE. After the datapath was verified, the next step was to implement and verify the control logic illustrated in Figure 8. A. Work Flow Overview As shown below in Figure 10, Eclipse was used to generate test vectors from the reference C implementation. For each permutation, the output was displayed for each round. IV. HARDWARE COMPARISON During development in Xilinx ISE Webpack, the Xilinx Virtex-6 XC6VLX75T FF784 device was targeted for implementation. All results generated, other than from ATHENa, are for the Virtex-6 device. For benchmark results from ATHENa, the Xilinx Spartan-3 and Virtex-5 device results are shown. A. Datapath FPGA Utilization Using the general approach shown in Figure 7, each PRIMATE was designed the same way. The results shown below in Table 1 are from synthesis in Xilinx ISE Webpack of each datapath. It is clear that APE takes the largest area, followed by HANUMAN and GIBBON. Additionally, if APE encryption is analyzed without the inverse PN, the size of APE with decryption, denoted APE(D) in Table 1 below, is consistent with the results. Specifically, APE (D) APE(E) + HANUMAN, which is consistent with the design since APE (D) requires double the permutation blocks for inverse mode. Table 1 - Datapath FPGA Utilization B. Control FPGA Utilization Figure 10 - Workflow Overview Xilinx ISE Webpack was used to write the VHDL code, and ISim was used to generate and verify the waveform matched the expected test vector. However, prior to verification of the test vectors, the algorithm state was properly verified by examining the state machines of Algorithm Flow Ctrl and FIFO Drivers shown in Figure 8. Once the flow control was correct then the expected output was confirmed, and this process facilitated quickly fixing errors. B. Test Vector Selection and Procedure The first case that was verified for each algorithm was the case where there is no AD or message / ciphertext (M/C) data to process. The only output to verify in this case is the tag, but the internal state was also confirmed. Let cases be written as (AD,M/C), indicating the number of blocks for each data type. As shown in Figure 10, the order of test cases was (0,0) (1,0) (2,0) (0,1) (0,2) (1,1) (2,2). The only way to move to the next case was if the previous cases all worked. For example, if one failed, then changes would be made to fix the problem, and the previous cases were verified again. This allowed to check for any possible side effects of the current fix and also helped to design the system better overall. Using the general approach shown in Figure 8, each PRIMATE controller was designed the same way. The results shown below in Table 2 are from synthesis in Xilinx ISE Webpack of each controller, named Algorithm Flow Ctrl in Figure 8. Since each controller corresponds to a state machine, only state information is analyzed. Table 2 - Control FPGA Utilization It is clear that GIBBON has the largest number of states, nearly double that of HANUMAN. This can be explained by looking at the clock cycle summary provided in Table 5, which indicates that GIBBON has many dependencies and preprocessing when input is not being received. For example, GIBBON runs p 2 initially if at least one block of AD is present, or it does not execute any permutations for the AD segment. This type of control logic makes the finite state machine comparatively more complex.

5 C. Overall FPGA Utilization Using Xilinx ISE Webpack for implementation, the results shown below in Table 3 were generated for the target Virtex 6 FPGA. The maximum frequency generated was based on a constraint of a 10ns input clock. represent the number of IV blocks, m, the number of AD blocks, and n the number of M/C blocks. Table 5 - Clock Cycles Overview Note: The + symbol indicates that even empty M/C blocks will have at least 1 permutation executed. [12] indicates that if in the case of empty AD, this value will be 0. Table 3 - Overall FPGA Utilization As expected, APE has the largest area in terms of slices, and GIBBON can achieve highest max frequency. Both HANUMAN and GIBBON have slower maximum frequencies, which may be due to the fact that both of they use 12 rounds as opposed to 6 for GIBBON. D. ATHENa Benchmarking Results After each algorithm was verified to be functionally correct, the waveform was analyzed to create values for throughput and latency of AD and M/C blocks. Both HANUMAN and GIBBON have the same performance for AD and M/C blocks, while APE performs slightly worse for processing M/C blocks. APE and HANUMAN perform the worst according to this analysis for throughput and latency of AD blocks and throughput of M/C blocks. APE has the worst latency for processing M/C blocks. ATHENa is a tool developed at George Mason University, and is used for the evaluation of cryptographic cores, and it was used to generate benchmarking results for the Xilinx Virtex-6 FPGA. The results for throughput, throughput/area, latency, latency*area, and area are shown below in Table 4. Table 6 - Waveform-based Throughput and Latency results. Note: The bus width is 40-bits and latency calculations are based on a 4MHz clock to a low-power application on a TI MSP430F5229. The number of bonded IOBs was 135. B. Software Testing Overview Table 4 - ATHENa Benchmarking Results According to the results in Table 4, all algorithms have very similar throughput, with GIBBON being marginally better. This is expected since GIBBON executes 6 rounds on a block. However, compared to the results in Table 6, GIBBON was expected to give better comparative results. The throughput / area are worst for APE, but the total area is smaller than shown in Table 3. HANUMAN has the worst latency results, which is similar to the results in Table 6. However, the comparative latency increase is higher in Table 4. V. SOFTWARE AND HARDWARE EXECUTION COMPARISON In order to compare the execution timing in hardware and software, execution on a low power microcontroller was compared to the hardware timing results. A. Hardware Timing The hardware timing was analyzed based upon the algorithm specification, and is shown below in Table 5. Let k In order to get an idea of PRIMATEs performance on a lightweight device, the ultra-low power MSP430F5229 Launchpad from Texas Instruments was used. As shown below in Figure 11, the character E is displayed first, and indicates encryption of 10 bytes ABCDEFGHIJ has begun. After some time, D appears to show decryption has started. The result of ABCDEFGHIJ is displayed afterwards only if decryption is successful, as shown in Figure 11. The same test was repeated using only 5 message blocks, displaying ABCDE. These results were used to determine the latency and throughput of execution on the Launchpad. For simplicity, only the results M/C latency were analyzed. The software submitted by PRIMATEs to the Competition for Authenticated Encryption: Security, Applicability, and Robustness (CAESAR) was executed on the Launchpad. However, a few small modifications were made to allow TI s Code Composer Studio (CCS) to compile and run the code. The code consists only calling the standard CAESAR required encrypt and decrypt functions, after which the decrypted message is iterated though and displayed on the LCD. During execution, the only other functions invoked were to display output before and after the encrypt/decrypt function calls.

6 This test represents the best case scenario for executing PRIMATEs, where no other concurrent processing occurs. Additionally, the average execution time of 12 runs for each algorithm processing either 5 or 10 bytes was used in the timing analysis. VI. CONCLUSION The PRIMATEs family of Authenticated Ciphers requires a low number of FPGA slices, with the largest belonging to APE. The GIBBON PRIMATE has more complex state logic, but all PRIMATEs have similar throughput, throughput/area, and latency, as shown in Table 4. The throughput values are based on a standard block size of 40-bits, but it is possible to increase this value at the cost of latency. The comparison between hardware and software shows a vast improvement executing PRIMATEs in hardware, which was expected. However, it is important to note that an optimized version of the software code may produce better throughput and latency results. Each PRIMATE offers its own unique benefits and all of them can operate in a low resource environments; requiring a comparably small amount of memory and processor resources. Figure 11 - Software Execution Environment C. Software Timing Results The software timing was recorded by a stopwatch because it took longer than one second for encryption, and the results are shown below in Table 7. Please note, the clock frequency of 4MHz on the Launchpad was used to simulate a low power environment, but it could be clocked faster. Table 7 - Software Timing Results The speedup in throughput for hardware compared to software is on average on the order of ~10 7 and for latency about ~10 4. The reason for this large speedup maybe due to the fact the reference C implementation was created for a nonembedded environment and not optimized for embedded execution. It may possible to have much faster execution with modification to the code. ACKNOWLEDGMENT I would like to thank for Dr. Kris Gaj, associate professor at George Mason University, for offering valuable feedback during the implementation of the PRIMATEs family of Authenticated Ciphers. His feedback greatly assisted me in determining an efficient and effective solution. REFERENCES [1] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G.: Cryptographic Sponge Functions, available at [2] Andreeva, E., Bilgin, B., Bogdanov, A., Luykx, A., Mennink, B., Mouha, N., Yasuda, K.: PRIMATEs v Submission to the CAESAR Competition. [3] Andreeva, E., Bilgin, B., Bogdanov, A., Luykx, A., Mennink, B., Mouha, N., Yasuda, K.: APE: Authenticated Permutation-Based Encryption for Lightweight Cryptography. In: FSE Lecture Notes in Computer Science, Springer (2014) [4] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G.: Duplexing the Sponge: Single-Pass Authenticated Encryption and Other Applications. In: Miri, A., Vaudenay, S. (eds.) Selected Areas in Cryptography Lecture Notes in Computer Science, vol. 7118, pp Springer (2012) [5] Gaj, K. : Interface of Ciphers and Authenticated Ciphers,available at nterface.pdf