Dynamic HighPerformance MultiMode Architectures for AES Encryption Eric

Dynamic High-Performance Multi-Mode Architectures for AES Encryption Eric Swankoski Naval Research Lab Vijay Narayanan Penn State University Swankoski 1 MAPLD 2005 / B 103

Background & Motivation l l Bandwidth and throughput capabilities of modern optical networks is skyrocketing Protecting transmitted data becoming more and more critical Current encryption architectures generally aren’t capable of keeping up with high-speed environments SEU effects rarely, if ever, considered Swankoski 2 MAPLD 2005 / B 103

Plan of Attack: FPGA Encryption l Algorithm: Advanced Encryption Standard (AES) – – – l Target Architecture: Xilinx FPGAs – – l Supports multiple key lengths Supports multiple encryption modes Supports multiple levels of pipelining Can be adapted to ASIC devices Virtex-II, Virtex-4 Target Performance: 60+ gigabits per second – Swankoski Requires both inner-round and outer-round pipelining 3 MAPLD 2005 / B 103

The AES Algorithm l l 10 Rounds of Encryption for 128 -bit operands Four basic operations: – Sub. Bytes: l – Shift. Rows: l – Polynomial multiplication (4 parallel operations per round) Add. Round. Key l Swankoski Byte reordering and rotation (4 parallel operations per round) Mix. Columns: l – 8 -bit substitution (16 parallel operations per round) Simple 128 -bit XOR 4 MAPLD 2005 / B 103

Optimizing for Performance l l Exploit all possible parallelism Alternative byte substitution methods – – l 1 cycle for a lookup-based substitution 5 cycles for a mathematical transformation Utilize pipelining – – Outer-Round: 1 cycle per round Inner-Round: l l Swankoski 4 cycles per round (lookup-based byte substitution) 8 cycles per round (pipelined byte substitution) 5 MAPLD 2005 / B 103

Combinatorial Byte Substitution l l Actual mathematical transformation Conventional implementation cannot be pipelined – l l Smaller than lookup table Faster than lookup table – l Swankoski Simple (atomic) 8 x 8 lookup table Utilizes five-stage pipeline All internal operands are four bits wide 6 MAPLD 2005 / B 103

Encryption Round Diagram Atomic S-Box: l – Combinatorial S-Box: l – – 76 Pipeline Stages Needs a constant stream to be effective Parallel Key Scheduling l – No performance penalty Offline Key Scheduling l – Swankoski 40 Pipeline Stages 7 Precomputed keys can be stored in registers MAPLD 2005 / B 103

Counter (CTR) Mode l l Effectively converts AES into a stream cipher High security – similar to CBC Supports inner-round and outer-round pipelining No error propagation – errors are completely isolated Swankoski 8 MAPLD 2005 / B 103

Cipher Block Chaining (CBC) Mode l l l Most secure – no patterns are observed Cannot be pipelined 100% downstream corruption resulting from data loss or singleevent upsets (SEUs) during encryption – Swankoski Errors are isolated during decryption 9 MAPLD 2005 / B 103

Electronic Codebook (ECB) Mode l l l Supports full pipelining No error propagation – errors are completely isolated Least secure – identical input gives identical output – Swankoski Patterns observable in video and image data 10 MAPLD 2005 / B 103

Staggered CBC Mode Pipelined with Output Feedback l Each encrypted block n depends on itself and the block (n – x) where x is the latency of the pipeline l Maintains security while mitigating some error propagation problems l Swankoski 11 MAPLD 2005 / B 103

More Challenges Error-Tolerant Encryption l Maintaining High Security l Maintaining High Performance l Swankoski 12 MAPLD 2005 / B 103

Error-Tolerant Encryption l Are errors acceptable? – Possibly, but better to assume not How do the multiple modes of encryption deal with upsets? l Is there a benefit to triple modular redundancy (TMR)? l – Swankoski Is it what we expect? 13 MAPLD 2005 / B 103

Error-Tolerant Encryption l CTR and ECB encryption isolate errors – l Transmission integrity largely preserved even without SEU mitigation TMR can ensure 100% transmission integrity – Swankoski TMR REQUIRED for CBC encryption 14 MAPLD 2005 / B 103

Error-Tolerant Encryption l Image 1: Error-Free Plaintext Image – – l Image 2: Decrypted Plaintext Image – – l Before Encryption / After Decryption CTR, ECB, or CBC with mitigation One corrupted block CTR or ECB without mitigation Image 3: Decrypted Plaintext Image – – Swankoski One block corrupted during encryption CBC without mitigation 15 MAPLD 2005 / B 103

Maintaining High Security l l How do the multiple modes of encryption affect security? Is physical protection of the key necessary? – l Depends on the environment How is throughput affected by increased security? – Swankoski Hopefully, not at all… 16 MAPLD 2005 / B 103

Maintaining High Security l l ECB-encrypted image has observable patterns CTR/CBC/SCBC encryption looks like random noise Swankoski 17 MAPLD 2005 / B 103

Maintaining High Security l Physical Key Protection – l Power Analysis / Soft Attacks – l Not required in aerospace applications Countermeasures not mode specific Throughput Effects – – Swankoski ECB & CTR far outperform CBC Why is CBC an official mode? 18 MAPLD 2005 / B 103

System-Level Diagram l l Supports ECB, CTR, CBC, and SCBC modes Supports two types of TMR – – Swankoski 19 System: triplicates all control, key hardware, and mode logic Encryption: triplicates only encryption and key scheduling hardware MAPLD 2005 / B 103

Performance Results – Virtex-4 Byte Substitution Key Scheduling Area Frequency Throughput (CTR, ECB, SCBC) Throughput (CBC) ROM Online 3588 339. 5 MHz 43. 5 Gbps 1. 088 Gbps ROM Offline 2827 446. 8 MHz 57. 2 Gbps 1. 430 Gbps Combinatorial Online 13651 519. 2 MHz 66. 5 Gbps 700. 0 Mbps Combinatorial Offline 10912 519. 2 MHz 66. 5 Gbps 700. 0 Mbps l Key Scheduling – – l l l Offline uses precomputed and stored keys (compile or design time) Online uses dynamically computed keys (run time) Significant performance improvement for combinatorial byte substitution in pipelined mode Virtex-II Pro performs better with ROM implementation (56. 42 & 60. 35 Gbps) Better CBC performance achieved through other architectures Swankoski 20 MAPLD 2005 / B 103

Lessons Learned l Don’t try to over-optimize FPGA code – – l Know your synthesis tool – l Returns diminish quickly Sometimes less is more Now why did it do THAT? Check your system’s memory – RAM does fail at inopportune times… l Swankoski ESPECIALLY if it has a lifetime warranty 21 MAPLD 2005 / B 103

Lessons Learned l Over-optimization – In a highly pipelined FPGA design, routing plays a MAJOR role in the clock frequency l – – – Swankoski 70%-80% of the total delay What would work in an ASIC (or in theory, or on paper…) might actually make things worse Manual floorplanning and P&R might help, but usually provides minimal (if any) improvement Moral? – Try reducing the pipeline depth as well as increasing it, it just might help! 22 MAPLD 2005 / B 103