establishing a security verification framework for …
TRANSCRIPT
Dr. Jason Oberg
CEO
Tortuga Logic
ESTABLISHING A SECURITY
VERIFICATION FRAMEWORK
FOR THE RISC-V ARCHITECTURE
@risc_v https://tmt.knect365.com/risc-v-summit 1 Copyright Tortuga Logic, Inc. 2018
The Growing Popularity of RISC-V
• RISC-V is gaining popularity for a variety of applications • AI Accelerators
• IoT Edge
• Storage devices
• Compute in datacenter
• Graphics applications
• By design, RISC-V does not standardize implementations so users can freely build what they want for their end application
• This flexibility is great, but has potential for insecure side effects.
2
Architecture Vs. Microarchitecture
• Processors are built in accordance to an ISA (Instruction Set Architecture)
• An ISA is the timing independent functionality of the processor
• Defines the “contract” between software and the hardware
• Realizations of an ISA are referred to as implementations
• Implementations of an ISA differ based on Microarchitecture • Microarchitecture is the specific way an implementation is created
• The ISA defines inputs and output, but nothing else
Same ISA – different implementations!
https://github.com/riscv/riscv-wiki/wiki/RISC-V-Cores-and-SoCs
3
Architecture Vs. Microarchitecture
• The microarchitecture is how the ISA is actually built: • Caches • Branch predictors • Speculative execution / prefetching • Out-of-order execution • Instruction Pipelining • Cryptographic accelerators • Memory Protection Units (MPUs)
• All of these structures and design principles are hidden from SW developer’s point of view but greatly help performance, efficiency, and security
• Even if the ISA is sound, the implementation can be vulnerable • This is true even if microarchitecture perfectly implements ISA
4
Security is a System Property
Securing systems has focused on later layers of the computing stack
However, each layer in the computing stack relies on security of layers below it
There is a misconception that hardware is inherently “secure” • Hardware previously not considered to be a source of vulnerabilities
• However, microarchitecture design choices can enable security exploits
• This is highlighted by many recent attacks
Hardware BootROM Firmware Kernel/VMs Applications 5
System Exploits Caused by Hardware
February 2017
January 2018 August 2018
June 2018
Vulnerable hardware enables system-level exploits 6
Memory Hierarchy in Modern Processors
• Performance limited by time to access main memory
• Cache: smaller memory with faster access time which stores a subset of main memory based on access patterns
• Cache Hit: data present in cache, can return to CPU immediately
• Cache Miss: data not in cache, must be fetched from memory
CPU Core
L1 Instr.
Cache
L1 Data
Cache
L2 Cache
Main Memory
Memory access resulting in cache hit
completes orders of magnitude faster
than if cache miss occurs
7
Meltdown/Spectre Vulnerabilities
Attacks showed that unauthorized
information can be observed via caches
and speculative execution
January, 2018
if( x < array1.size() )
y = array2[array1[x] * 256];
Cache
Speculative execution fills the cache, even though instructions are never committed.
Content can then be inferred being fast and slow memory accesses
Attacker sets “x” out of bounds to load data into cache
If array1[x] is Kernel memory, attacker can learn this
from timing side channel without having direct access to data 8
Cache Side Channel Example: Encryption Algorithm Look-up Table
stack
heap
text
data T[0]
T[1]
T[n]
… Look-
up
Table
Program Memory Footprint Machine Mode
encrypt(input, key)
{
v = input ^ T[key]
…
return output
}
”key” is secret and should not
be observed by User Mode
Note: T is not secret
9
Cache Side Channel Example: Encryption Algorithm Look-up Table
stack
heap
text
data T[0]
T[1]
T[n]
… Look-
up
Table
Program Memory Footprint User Mode
Data Cache
for i = 0 to n:
time(T[i])
10
Cache Side Channel Example: Encryption Algorithm Look-up Table
stack
heap
text
data T[0]
T[1]
T[n]
… Look-
up
Table
Program Memory Footprint Machine Mode User Mode
encrypt(input, key)
{
v = input ^ T[key]
…
return output
}
Data Cache
Example: key = 1
T[1]
for i = 0 to n:
time(T[i])
Access to T[1] slower
than other entries
(attacker learns key=1)
Cache Timing Side-
channel Attack
”key” is secret and
should not be observed
by User Mode
Note: T is not secret
11
Additional Implementation Use Cases
• Hardware Roots of Trust
• SoC Access control verification
• Secure boot analysis
• Timing side channels
• Encryption key leakage
• Configuration register read/write protection
• Memory Protection Unit (MPU) configuration
• JTAG disablement/analysis
• 3rd party/vendor IPs and interfaces
These all require the analysis of both hardware AND software together
12
Tortuga Logic’s Security Verification Solutions
• Step 1 - Define the Threat Model • Specify assets to protect and intended use of those assets
• Specified in Tortuga Logic’s rule set
• Step 2 - Hardware design (RTL) and Threat Model are analyzed to produce our Security Model Design (SMD), a synthesizable hardware IP.
• Step 3 – Run SMD in parallel with RTL inside existing functional verification environments (Formal Verification, Simulation, or Emulation)
• Tortuga Logic’s Unison product is used in standard RTL simulation environments
• Step 4 – Analyze results and identify security violations
13
Tortuga Logic’s Security Verification Solutions
RTL
Security Rules
Expressed in its
Sentinel™ rule set
Security Model
Generation
Security Model Design
(Verilog IP) Existing
Verification
Environment
Tortuga Logic Analysis
Platform
Step 1: Express Threat Model
Step 2: Generate Security Model
Step 3: Insert Security Model into existing regressions/emulation
Step 4: Analyze results; Identify violations
Already Exist at User
Provided by Tortuga
Logic
14
Example Use Case on Rocket Core
• Determine if Machine Mode information leaks to User Mode
Sentinel Security Property:
( dcache.tag_array.wdata
when (dcache.tag_array.wmode &&
dcache.dprv == MACHINE_MODE)
=/=> dcache.rdata
|| dcache.dprv == MACHINE_MODE );
Data Cache
wdata
rdata
wmode
15
Unison Waveform View for Data Cache Timing Channel
Machine Mode User Mode
Machine Mode information leaks
indirectly due to timing even
though value does not change
Machine Mode data written to
cache when machine mode
16
Key Takeaways
• Open source RISC-V ISA offers wide implementation flexibility • High flexibility introduces security complications for implementations
• Security is a system property so verifying from the ISA up is not enough • Many exploits show you need to consider the hardware implementation as well
• We have a framework for verifying security of RISC-V implementations that crosses both hardware and software
• We are creating a set of open security threat models for RISC-V implementations and frameworks for helping verify them
17
THANK YOU
https://tmt.knect365.com/risc-v-summit @risc_v 18
Dr. Jason Oberg
CEO
Tortuga Logic
Copyright Tortuga Logic, Inc. 2018