Protecting data and intellectual property in accelerator-rich architectures with high-level methods
0 likes239 views
This document discusses the challenges of hardware security in complex system-on-chip architectures, emphasizing the need for high-level methods to protect sensitive data and intellectual property. It outlines various threats, such as reverse engineering, IP theft, and hardware Trojans, and presents techniques like dynamic information flow tracking and logic obfuscation to enhance security. The author stresses the importance of addressing security at all levels of design, advocating for integrated solutions to safeguard hardware from malicious attacks.
![©Christian Pilato, 2021 17
• Key Idea: obfuscate a design at the algorithm-level so that the
obfuscation is semantically meaningful
Raising the abstraction level
C/C++ RTL Netlist
always @ posedge clk
a[i] <= b[i] + c[i];
…..
for (i=0; i<N; i++)
c[i] = a[i]+b[i];
…..
High-Level
Synthesis
Logic
Synthesis
Semantic Information](https://image.slidesharecdn.com/christianpilato-slides-210620204131/85/Protecting-data-and-intellectual-property-in-accelerator-rich-architectures-with-high-level-methods-17-320.jpg)
Protecting data and intellectual property in accelerator-rich architectures with high-level methods
- 1. Protecting data and intellectual property in accelerator-rich architectures with high- level methods Christian Pilato Dipartimento di Elettronica, Informazione e Bioingegneria christian.pilato@polimi.it
- 2. ©Christian Pilato, 2021 2 Increasing system complexity demands design & reuse approaches • IP components may be coming from many vendors • Designers need to assemble to create the SoC • Most of the design houses are becoming fab-less System Complexity and Hardware Security 2,009 2,010 2,011 2,012 2,013 2,014 2,015 2,016 2,017 2,018 2,019 2,020 2,021 2,022 2,023 2,024 0 20 40 60 80 100 percent of design % of designs with pre-existing components 0 50 100 150 Cybersecurity spending in US 0 50 100 150 billions, USD (projected) Hardware Security is the next big issue for hardware design
- 3. ©Christian Pilato, 2021 3 Supply chain is more and more distributed to reduce costs • Many security threats • Cost of addressing them is exponentially increasing from level to level Globalization of the Supply Chain Let’s focus on the early stages of the design process…
- 4. ©Christian Pilato, 2021 4 What (and How) to Protect? How Sensitive Data is Elaborated by the System-on-Chip Architectures Analysis of the data elaboration to identify the hardware modifications to improve the overall security (prevent also software-based attacks) Intellectual Property in the Design of Components and Architectures Analysis of the digital design (component or architecture) to apply security protection methods against IP theft and counterfeiting Let's Raise the Abstraction Level for Hardware Security
- 5. ©Christian Pilato, 2021 5 Hardware Threats Reverse Engineering and IP Theft Methods to extract chip functionality from circuit designs in order to create illegal copies • Steal the technology • Cut design costs • Enter into a market • ... Hardware Trojans Malicious modifications of an existing chip design to introduce an additional functionality • Steal data (e.g., through side channels) • Harm the normal operations of the chips (e.g., DoS attacks) • Altern the chip functionality (e.g., errors) • ... Data Injection Injection of spurious data to exploit software or hardware/software vulnerabilities • Buffer overflow attacks • Memory corruption • ... Side Channel Methods to create additional communication channels to steal sensitive data • Differential power analysis for key extraction • Timing channels for reverse enginnering • ...
- 6. ©Christian Pilato, 2021 6 Marking Data coming for untrusted sources with tags (taints) • Trap to OS if tainted data are used in critical operations • Pointer dereference, jump address, modified code or data, … Data Protection & Information Flow Tracking void preprocess (int v){ struct results ret; if (v > 0) ret.x = 1; else ret.x = 4; ret.y = 10; ret.z = 5; return ret; } struct results { int x; int y; int z; }; ... get_IO(&v); ... ret = preprocess(v); ... elaborate(ret); get_IO elaborate preprocess ATTACK z y x v DIFT can protect from several software-based attacks
- 7. ©Christian Pilato, 2021 7 Applications interleave tasks between hardware and software • What happens when accelerators are executed before the potential attack point? DIFT in Heterogeneous Architectures void preprocess (int v){ struct results ret; if (v > 0) ret.x = 1; else ret.x = 4; ret.y = 10; ret.z = 5; return ret; } struct results { int x; int y; int z; }; ... get_IO(&v); ... ret = preprocess(v); ... elaborate(ret); get_IO elaborate preprocess ATTACK z y x v get_IO elaborate preprocess ATTACK z y x v get_IO elaborate preprocess DoS z y x v Optimistic Pessimistic
- 8. ©Christian Pilato, 2021 8 Applications interleaves tasks in both hardware and software • What happens when accelerators are executed before the potential attack point? DIFT in Heterogeneous Architectures void preprocess (int v){ struct results ret; if (v > 0) ret.x = 1; else ret.x = 4; ret.y = 10; ret.z = 5; return ret; } struct results { int x; int y; int z; }; ... get_IO(&v); ... ret = preprocess(v); ... elaborate(ret); get_IO elaborate preprocess ATTACK z y x v get_IO elaborate preprocess Attack prevented z y x v Accelerators require fine-grained support for DIFT
- 9. ©Christian Pilato, 2021 9 Data path extended with shadow logic and memory architecture with taint memories • HLS-based methodology for automatic generation based on HLS results TaintHLS: DIFT Support within HLS Datapath reg_0 reg_1 reg_2 + - reg_3 reg_0 reg_1 reg_2 PM(+) PM(-) reg_3 mux mux Controller input_a input_b input_a input_b return return Hardware Module local memory taint memory local memory taint memory data1 data2 taint1 taint2 Controller + Datapath Hardware Module local memory taint memory Memory Interface Memory Interface DRAM Ctrl … DRAM Serializer Almost no performance overhead with optimizations to limit area overhead
- 10. ©Christian Pilato, 2021 10 Microarchitectural solutions to propagate data and tags in parallel Data Flow Consistency Datapath + - PM(+) PM(-) local memory taint memory address data tags memory interface Datapath - PM(-) mux mux Controller mux mux Datapath reg_0 Controller reg_0 resources shadow logic WE
- 11. ©Christian Pilato, 2021 11 Area overhead of each granularity wrt the baseline version • Xilinx Virtex-7 FPGA @ 100 MHz Area overhead Baseline (no DIFT) Variable-level DIFT Word-level DIFT Bit-level DIFT +31% LUT Overhead (Normalized) 0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 ICRC AES BFS Viterbi Security depends on the ”quality” of the propagation modules
- 12. ©Christian Pilato, 2021 12 Attackers can exploit on-chip communications to make DoS attacks or NoC-channel attacks • Security regions can isolate tiles and packet encryption can prevent "sniffing" Protection of On-Chip Communications Dynamic security regions can improve system performance
- 13. ©Christian Pilato, 2021 13 A tile can join/leave a security region upon request • The smart routing search for an isolated path to protect the communication Packets are encrypted with a group key to ensure only the tiles in the region can read the data Dynamic Security Regions
- 14. ©Christian Pilato, 2021 14 System Effects Communication isolation Link usage 0% 50% 100% Number of security regions 2 3 4 5 6 Performance overhead (static) Performance overhead (dynamic) 0% 5% 10% 15% 20% Number of security regions 2 3 4 5 6 Smart routing can achieve high communication isolation • Increasing the link usage leads to more power consumption Dynamic regions remove limitations on task mapping • This can mitigate the performance overhead (now around 17%) • We can create architectures with more security regions Prototype in gem5+Noxim, and estimations on RTL descriptions
- 15. ©Christian Pilato, 2021 15 Steal and claim ownership of IC and/or illegal use • Malicious SoC integration house • Malicious foundry Real-life impact • $4,000,000,000 loss per year to IC industry • ARM detected IP piracy in 2000 IC/IP piracy and overbuilding Sells license for 1 copy 3PIP vendor SoC Integration House Foundry Makes 3 copies
- 16. ©Christian Pilato, 2021 16 Logic obfuscation Obfuscated Netlist k-bit key 2k netlists 2k key values Designer applies correct key
- 17. ©Christian Pilato, 2021 17 • Key Idea: obfuscate a design at the algorithm-level so that the obfuscation is semantically meaningful Raising the abstraction level C/C++ RTL Netlist always @ posedge clk a[i] <= b[i] + c[i]; ….. for (i=0; i<N; i++) c[i] = a[i]+b[i]; ….. High-Level Synthesis Logic Synthesis Semantic Information
- 18. ©Christian Pilato, 2021 18 RTL Transformations for Security RTL Secured Netlist ASSURE RTL Synthesis Secured RTL Design key Synthesizable Verilog Compatible with any RTL synthesis flow Manual design Pre-existing IPs HLS flow Behavioral RTL* *Independent of the input flow In collaboration with
- 19. ©Christian Pilato, 2021 19 Attacker has access to layout files and can reverse engineer the functionality of the netlist • Simulation and re-synthesis of obfuscated design • No prior information on the design The attacker has no activated chip • Unknown input/output relationship (obviates SAT attacks) Security is guaranteed when all input keys are equally plausible • Make random guesses without knowing if it is correct • No insights on whether one key is correct or not Threat Model: Untrusted Foundry
- 20. ©Christian Pilato, 2021 20 Easy-to-use command-line tool for Verilog-to-Verilog RTL elaboration • Minimal requirements: runs with no modifications on DARPA Cloud • Supports three high-level obfuscation techniques ASSURE Features Constant obfuscation of sensitive data of the design (e.g., coefficients) Operation obfuscation of arithmetic operations by inserting additional ones Control/branch obfuscation masking of control branches a b * test T(F) F(T) ^ * + a b c 1 0
- 21. ©Christian Pilato, 2021 21 Obfuscated netlists are isomorphic (i.e., exactly the same) regardless of the key choice • Attacker cannot infer key from the design • Thus ASSURE achieves 2K security for K key bits ASSURE Security Analysis Power Consumption (Baseline vs Obfuscated)
- 22. ©Christian Pilato, 2021 22 Correctness of obfuscated RTL designs verified using Synopsys Formality, i.e., with correct key, obfuscated design matches baseline Power, Area, Speed: Overhead compared to baseline design using Synopsys Design Compiler: Logic synthesis for area minimization • Power: Total power consumption • Area: Total chip area • Speed: Delay of critical path(s) Security: Formal proofs of obfuscation techniques • 2number of input key bits ASSURE Evaluation – PASS Metrics
- 23. ©Christian Pilato, 2021 23 Benchmarks - Bits used for Locking Constants Operations Branches Max Security AES-192 (Datapath) 819,296 (102,403 constants) 429 1 2(820K+429+1) IIR Filter (Datapath) 608 (19 constants) 43 0 2(608+43+0) I2C-Slave (Controller) 244 (104 constants) 14 11 2(244+14+11) Ethernet MAC (Controller) 2414 (487 constants) 1217 218 2(2414+1217+218)
- 24. ©Christian Pilato, 2021 24 Synthesized with Synopsys Design Compiler J2018.SP5 targeting Nangate 15nm library (area opt) Security vs Area Trade-offs (AES) All bits used for obfuscating 8-bit constants Take-Aways 1. Constant obfuscation dominates the area overhead 2. Operator obfuscation has greater overhead per key-bit compared to const obfuscation 3. Branch obfuscation: Limited impact because there is only 1 branch 4. Full obfuscation => 3x area overhead (~820K key bits for constants; impractical?)
- 25. ©Christian Pilato, 2021 25 Synthesized with Synopsys Design Compiler J2018.SP5 targeting Nangate 15nm library (area opt) Security vs Area Trade-offs (E-Mac) 1/0/0 4/5/3 9/19/4 13/19/4 Take-Aways 1. Control-dominated design: 487 constants, 1217 operations and 218 branches 2. Branch obfuscation becomes as expensive as constant obfuscation 3. Operator obfuscation is always more expensive than constant and branch obfuscation 4. However, compared to AES, operator obfuscation is less expensive for EthernetMac
- 26. ©Christian Pilato, 2021 26 CAD Tools are Designed by Humans… • Can you always trust a programmer? Design houses (or competitors) may have interest to degradate IPs after a certain amount of time • Pushing customers to change device CAD Tools as Potential Attack Vectors High-Level Description RTL Design High-Level Synthesis Gate-Level Design Logic Synthesis So!ware Descriptions (C/C++, …) Hardware Descriptions (Verilog/VHDL) Equivalence Checking Simulation-based Verification Input Vectors Design Flow Verification Flow Very difficult to check non-functional properties (Forbes, Oct 28, 2018)
- 27. ©Christian Pilato, 2021 27 Accelerated battery discarging can motivate people to change device • HLS knows which functional units are used in each clock cycle • Unused units can be used to drain extra current Battery Exhaustion Attack + * FSM in used states activation FU FSM When unused, the FU computes fake operations with bit-flipped inputs Results of faked operations are never stored into registers This is no golden model before HLS for power analysis Selected functional units are extended with extra logic active only in specific states Extra logic to increase switching activity (more dynamic power)
- 28. ©Christian Pilato, 2021 28 We added a malicious pass after binding to add extra logic • Tech library provides information about power consumption Battery Exhaustion Attack in Bambu power overhead (%) 0 5 10 15 20 25 adpcm backprop fft gsm jpeg mips motion viterbi Select only the 5 most unused functional units to minimize area overhead area overhead (%) 0 5 10 15 adpcm backprop fft gsm jpeg mips motion viterbi Minimize area overhead with a 30% power overhead budget
- 29. ©Christian Pilato, 2021 29 Security must be address at ALL levels • Provably-secure algorithms • Robust OS and protected communications • Secure components, secure architectures, secure component integration, etc… Complete and integrated solutions are missing at all levels! • Separation of (security) concerns are required for scalable solutions What is Still Missing? Application OS IP Cores Processor Cores Memories Communication Network Creating awareness of the problems is as much important as proposing countermeasures
- 30. Thank you! Christian Pilato, christian.pilato@polimi.it
- 31. ©Christian Pilato, 2021 31 • C. Pilato, S. Garg, K. Wu, R. Karri, F. Regazzoni, “Securing Hardware Accelerators: A New Challenge for High- Level Synthesis,” Embedded Systems Letters 10(3): 77-80, 2018 • C. Pilato, K. Wu, S. Garg, R. Karri, F. Regazzoni, "TaintHLS: High-Level Synthesis for Dynamic Information Flow Tracking," IEEE Trans. on CAD of Integrated Circuits and Systems 38(5): 798-808 (2019) • M. Tibaldi, C. Pilato, "WallSoC: Protecting On-Chip Communications with Dynamic Security Regions," submitted to Computer Architecture Letters (2021) • C. Pilato, F. Regazzoni, R. Karri, S. Garg, "TAO: techniques for algorithm-level obfuscation during high-level synthesis," in Proceedings of the Design Automation Conference (DAC) 2018: 155:1-155:6 • C. Pilato, A. B. Chowdhury, D. Sciuto, S. Garg, R. Karri, "ASSURE: RTL Locking Against an Untrusted Foundry," in IEEE Transactions on Very Large Scale Integration (VLSI) Systems (2021) • K. Basu, S. M. Saeed, C. Pilato, M. Ashraf, M. Thari Nabeel, K. Chakrabarty, R. Karri, "CAD-Base: An Attack Vector into the Electronics Supply Chain," in ACM Trans. Design Autom. Electr. Syst. 24(4): 38:1-38:30 (2019) • C. Pilato, K. Basu, F. Regazzoni, R. Karri, "Black-Hat High-Level Synthesis: Myth or Reality?" in IEEE Trans. VLSI Syst. 27(4): 913-926 (2019) Home Reading