The globalization of the electronics supply chain allows for the reduction of chip manufacturing costs but poses new security threats. Untrusted foundries can steal the intellectual property in the chips, while malicious users can tamper with the systems to steal sensitive information. The design of next-generation systems requires to change the design methods, introducing security concepts since the early stages. In this talk, I will present an overview of the security issues in the design of accelerator-rich architecture, focusing on the protection of the data and the intellectual property. I will also discuss high-level methods to address these concerns, along with metrics for their evaluations. These solutions include the design and prototyping of architectures with secure communications, the high-level synthesis of security countermeasures, and the logic locking of RTL designs.

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