reverse engineering for security · reverse engineering for security pramod subramanyan...

76
Reverse Engineering for Security Pramod Subramanyan [email protected] Indian Institute of Technology, Kanpur 6 th Workshop on Design Automation for Understanding Hardware Designs March 29 2019 This work was supported in part by the Semiconductor Research Corporation (SRC). 1

Upload: others

Post on 26-May-2020

12 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Reverse Engineering for Security

Pramod Subramanyan

spramodcseiitkacin

Indian Institute of Technology Kanpur

6th Workshop on Design Automation for Understanding Hardware Designs

March 29 2019

This work was supported in part by the Semiconductor Research Corporation (SRC) 1

acknowledgements

bull Srinivas Devadas

bull Bruno Dutertre

bull Jason M Fung

bull Dejan Jovanovic

bull Hareesh Khattri

bull Ilia Lebedev

bull Abhranil Maiti

bull Aarti Gupta

bull Adria Gascon

bull Wenchao Li

bull Sharad Malik

bull Kanika Pasricha

bull Dillon Reisman

bull Sanjit Seshia

bull Rohit Sinha

bull Adriana Susnea

bull Ashish Tiwari

bull Nestan Tsiskaradze

bull Weikun Yang

bull Yakir Vizel

2

outline

why do we care about HW security

view from the bottom (reconstructing trust)

view from the top security property verification (constructing trust)

is there a middle-ground where the lsquotwain shall meet

3

in the news security breaches galore

$400B in losses worldwide due to cybercrime [McAfee 2014]

4

1B records 100TB of data80m records40m cards 500M records

not even the police are safe

5

Georgia county paid ransom of $400000 to cyber-criminals

ldquoeverything we have is down hellip were operating by paper in terms of reports and arrest bookingsrdquo

httpswwwzdnetcomarticlegeorgia-county-pays-a-whopping-400000-to-get-rid-of-a-ransomware-infection

industry response move all the thingz to HW

6

examples of HW security primitives

bull HW-supported SW isolation SGX Keystone TrustZone

bull SW authenticationmeasurement SecureBoot TXT

bull HW support for code protection eg MPX CFI mechanisms

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

all driven by the perception that hardware is ldquoharderrdquo to ldquohackrdquo than software

but if we learned one thing in 2018 hellip

hardware can have security vulnerabilities too

7

data supports growing HW vulns claim

8

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

whatrsquos the connection between these two

9

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 2: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

acknowledgements

bull Srinivas Devadas

bull Bruno Dutertre

bull Jason M Fung

bull Dejan Jovanovic

bull Hareesh Khattri

bull Ilia Lebedev

bull Abhranil Maiti

bull Aarti Gupta

bull Adria Gascon

bull Wenchao Li

bull Sharad Malik

bull Kanika Pasricha

bull Dillon Reisman

bull Sanjit Seshia

bull Rohit Sinha

bull Adriana Susnea

bull Ashish Tiwari

bull Nestan Tsiskaradze

bull Weikun Yang

bull Yakir Vizel

2

outline

why do we care about HW security

view from the bottom (reconstructing trust)

view from the top security property verification (constructing trust)

is there a middle-ground where the lsquotwain shall meet

3

in the news security breaches galore

$400B in losses worldwide due to cybercrime [McAfee 2014]

4

1B records 100TB of data80m records40m cards 500M records

not even the police are safe

5

Georgia county paid ransom of $400000 to cyber-criminals

ldquoeverything we have is down hellip were operating by paper in terms of reports and arrest bookingsrdquo

httpswwwzdnetcomarticlegeorgia-county-pays-a-whopping-400000-to-get-rid-of-a-ransomware-infection

industry response move all the thingz to HW

6

examples of HW security primitives

bull HW-supported SW isolation SGX Keystone TrustZone

bull SW authenticationmeasurement SecureBoot TXT

bull HW support for code protection eg MPX CFI mechanisms

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

all driven by the perception that hardware is ldquoharderrdquo to ldquohackrdquo than software

but if we learned one thing in 2018 hellip

hardware can have security vulnerabilities too

7

data supports growing HW vulns claim

8

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

whatrsquos the connection between these two

9

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 3: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

outline

why do we care about HW security

view from the bottom (reconstructing trust)

view from the top security property verification (constructing trust)

is there a middle-ground where the lsquotwain shall meet

3

in the news security breaches galore

$400B in losses worldwide due to cybercrime [McAfee 2014]

4

1B records 100TB of data80m records40m cards 500M records

not even the police are safe

5

Georgia county paid ransom of $400000 to cyber-criminals

ldquoeverything we have is down hellip were operating by paper in terms of reports and arrest bookingsrdquo

httpswwwzdnetcomarticlegeorgia-county-pays-a-whopping-400000-to-get-rid-of-a-ransomware-infection

industry response move all the thingz to HW

6

examples of HW security primitives

bull HW-supported SW isolation SGX Keystone TrustZone

bull SW authenticationmeasurement SecureBoot TXT

bull HW support for code protection eg MPX CFI mechanisms

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

all driven by the perception that hardware is ldquoharderrdquo to ldquohackrdquo than software

but if we learned one thing in 2018 hellip

hardware can have security vulnerabilities too

7

data supports growing HW vulns claim

8

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

whatrsquos the connection between these two

9

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 4: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

in the news security breaches galore

$400B in losses worldwide due to cybercrime [McAfee 2014]

4

1B records 100TB of data80m records40m cards 500M records

not even the police are safe

5

Georgia county paid ransom of $400000 to cyber-criminals

ldquoeverything we have is down hellip were operating by paper in terms of reports and arrest bookingsrdquo

httpswwwzdnetcomarticlegeorgia-county-pays-a-whopping-400000-to-get-rid-of-a-ransomware-infection

industry response move all the thingz to HW

6

examples of HW security primitives

bull HW-supported SW isolation SGX Keystone TrustZone

bull SW authenticationmeasurement SecureBoot TXT

bull HW support for code protection eg MPX CFI mechanisms

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

all driven by the perception that hardware is ldquoharderrdquo to ldquohackrdquo than software

but if we learned one thing in 2018 hellip

hardware can have security vulnerabilities too

7

data supports growing HW vulns claim

8

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

whatrsquos the connection between these two

9

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 5: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

not even the police are safe

5

Georgia county paid ransom of $400000 to cyber-criminals

ldquoeverything we have is down hellip were operating by paper in terms of reports and arrest bookingsrdquo

httpswwwzdnetcomarticlegeorgia-county-pays-a-whopping-400000-to-get-rid-of-a-ransomware-infection

industry response move all the thingz to HW

6

examples of HW security primitives

bull HW-supported SW isolation SGX Keystone TrustZone

bull SW authenticationmeasurement SecureBoot TXT

bull HW support for code protection eg MPX CFI mechanisms

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

all driven by the perception that hardware is ldquoharderrdquo to ldquohackrdquo than software

but if we learned one thing in 2018 hellip

hardware can have security vulnerabilities too

7

data supports growing HW vulns claim

8

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

whatrsquos the connection between these two

9

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 6: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

industry response move all the thingz to HW

6

examples of HW security primitives

bull HW-supported SW isolation SGX Keystone TrustZone

bull SW authenticationmeasurement SecureBoot TXT

bull HW support for code protection eg MPX CFI mechanisms

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

all driven by the perception that hardware is ldquoharderrdquo to ldquohackrdquo than software

but if we learned one thing in 2018 hellip

hardware can have security vulnerabilities too

7

data supports growing HW vulns claim

8

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

whatrsquos the connection between these two

9

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 7: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

but if we learned one thing in 2018 hellip

hardware can have security vulnerabilities too

7

data supports growing HW vulns claim

8

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

whatrsquos the connection between these two

9

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 8: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

data supports growing HW vulns claim

8

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

whatrsquos the connection between these two

9

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 9: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

whatrsquos the connection between these two

9

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 10: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

10

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 11: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

what could be untrusted in my IC

[Brian Sharkey TRUST in Integrated Circuits Program Briefing to Industry DARPA MTO 26 March 2007]

Specification Design Mask Fab

Wafer Probe Package Test

IP Tools Std Cells Models

Deploy

Trusted Untrusted11

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 12: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

one way of reconstructing trust

12

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

reverse engineering to extract high-level components from an unstructured and flat netlist

ALU

Register File

MU

XM

UX

Instr DecoderManual analysis

Algorithmic analysis

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 13: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Netlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

reverse engineering algorithm portfolio

Analyze Netlist to Detect Malicious Behaviour

13[HOSTrsquo13 DATErsquo13 TETCrsquo14 FMCADrsquo 14]

Combinational component analyses

Sequential component analyses

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 14: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

general strategy

14

Identify Potential Module Boundaries

BDDSAT-Based Analyses to Verify Functionality

Output Inferred Modules

muxmuxNetlist is a sea of gates No information about boundaries of modules inside it

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 15: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

bitslice identification and aggregation

15

Multiplexers decoders demultiplexers ripple carry adders and subtractors parity trees hellip

Netlist

K-cut matching

Aggregation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 16: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

119891 119886 119887 = 119886 + 119887

119891 119886 119887 = 119886119887 + 119888

bitslice Identification using cut matching

16

119891 119886 119887 = 119886119887 + not119886119888

Cong and Ding FlowMap [TCADrsquo94]Chatterjee et al Reducing Structural Bias in Technology Mapping [ICCADrsquo05]

bull cuts are computed recursively bull made tractable by enumerating cuts with k le 6 inputs bull group cuts into equivalence classes using permutation independent comparison bull BDDs used to represent Boolean functions during matching

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 17: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

bitslice aggregation

17

Group Bitslices With Shared Signals

Group Bitslices With Cascading Signals

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 18: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

word propagation and module matching

18

Netlist

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 19: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

word propagation and module generation

19

given an ldquooutputrdquo word we can traverse backwardsforwards to closely-related words to find candidate modules

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 20: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

library matching

20

candidate module

library module

Want to match candidate modules against a library of common modules such as adders ALUs hellip

Challengesbull Permutation and polarity of inputsbull Setting of control inputs

ABc

BA

bull formulate as QBF problembull use signatures to restrict space of permutations searched [FMCADrsquo14]

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 21: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

library matching as QBF

21

exist119888 119901 forall119883 119872 Π 119901 X c = L(X)

M

control signals ck

ndata inputs X Π

nPermutation

Network

permutation p

Ln signature of an input i is

the number of outputs osuch that 119900119894 ne 119900not119894

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 22: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

there are many more algorithms here hellipNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

Combinational component analyses

Sequential component analyses

22

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 23: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

but the takeaway isNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

Overlap Resolution

Abstracted Netlist

we have a reasonably effective portfolio of inference algorithms to identify word-level modules from a unstructured netlists

23

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 24: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

summarizing inference results (12)

24

bull 50-90 of the gates in these are coveredbull Runtime is a maximum of a several minutes

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 25: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

summarizing inference results (22)

25

bull Covered ~70 of the large test article (375k gates)bull Split the up big design into 7 subcomponents using reset tree Covered 60-87

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 26: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

retrospective on reverse engineering

bull possible to reconstruct many high-level structures from flat netlists

bull easier if we have information about what we expect to findrecall we were working blind ndash had no RTL info at all

bull challenges are mostly due to aggressive synthesis and optimizationminus tools merge equivalent functionality across sub-modules

minus tools aggressively optimize out constants

bull these challenges may be solvable with CEGIS

26

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 27: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

so we can do this hellip

Source httpmiscpartsmanuals2tpubcomTM-9-1240-369-34TM-9-1240-369-340115htm

ALU

Register File

MU

XM

UX

Instr Decoder

27

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 28: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

but the elephant in the room is hellip

How does one analyze a design to find security vulnerabilities

Manual analysis

Algorithmic analysis

28

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 29: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

two views of hardware vulnerabilities

1 someone untrusted controls part of my design(can I somehow analyze and then trust this design)

2 the design is trusted but is it trustworthy(what can I do to convince myself that the designrsquos security behavior is what I intended)

29

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 30: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

30

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 31: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

need more than safety for security (14)

int secret[N]int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)if (priv_level == sup_user)

r = secret[index]else

r = public[index]return r

mov ebx secretmov edi indexmov eax [ebx+4edi]mov r eax

Idea instrument each load to ensure that secret array is not accessed

Specification only super user must access secret array

31

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 32: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

need more than safety for security (24)

define valid (addr) = (addr gt= secret ampamp addr lt secret + N) priv_level == sup_user)

32

mov ebx secretmov edi indexassert valid(ebx+4edi)mov eax [ebx+4edi]mov r eax

Specification only super user must access secret array

Idea instrument each load to ensure that secret array is not accessed

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 33: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

need more than safety for security (34)

What is the bug

33

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

Specification only super user must access secret array

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 34: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

need more than safety for security (44)

34

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)if (priv_level == sup_user)

r=t=secret[index]else

r = public[index]return r

1 superuser calls foo(0)

2 t contains secret[0] (bug 1)

3 attacker calls foo(4)

4 this should have returned 0

5 due to bug 2 we return t(which contained secret[0])

Note our property is still satisfied

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 35: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

moral of the story

bull we wanted to verify the flow of information

bull but what we were actually checking was access to the information

bull trace (or safety) properties can capture the latter not the former

35

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 36: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

cryptographers solution distinguishability games

36

secret=X0public=A

secret=X1public=A

foo(x)

bull Pose game between an attacker and defenderbull Attacker wins game system is not securebull Defender wins the game system is secure

System 0

System 1

result

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 37: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

distinguishability game for function foo

37

DefenderAttacker

Choose 119887 isin01

secret0 secret1

public

foo(0) SU

perp

publicb[1]

b = 1

hellip

hellip

Finalization Attacker wins if she can determine b

foo(1) U

Game Initialization

bull Defender chooses 119887 isin 01

bull Attacker chooses 1199041198901198881199031198901199050 1199041198901198881199031198901199051 119901119906119887119897119894119888

bull System initial state is defined by 119904119890119888119903119890119905119887 119901119906119887119897119894119888

Game Execution

bull Attacker makes calls to foo(x) and observes result r

bull Result defined to be perp when called in SU mode

bull Result is the return value of foo in usr mode

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 38: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

can attacker win the game

38

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp

7

b =

hellip

hellip

foo(1) U

int secret[N] int public[N]int foo(int index)

int r = 0if (index gt= 0 ampamp index lt N)

if (priv_level == sup_user)r = secret[index]

elser = public[index]

return r

foo(2) U

8The game can go on forever nothing will reveal secret to adversary

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 39: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

can attacker win game with buggy foo

39

DefenderAttacker

Choose 119887 = 1

secret0=1234 secret1=5678

public=9786

foo(0) SU

perp (t = 5)

7

b = 1

hellip

hellip

foo(1) U

foo(4) U

5 (val in t) bull Now attacker always wins

bull Secrets are not indistinguishable

int secret[N] ampsecret[0]=100int public[N] amppublic[0]=104int t = 0 ampt=108 N=4int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 40: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

game viewed as a sequence of states

40

int secret[N]int public[N]int t = 0int foo(int index)

int r = 0if (index gt= 0 ampamp index lt= N)

if (priv_level == sup_user)r=t=secret[index]

elser=public[index]

return r

Initial statesbull secret0 = 1234bull secret1 = 5678bull public = 10111213

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

b=0 b=1

Initial States

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 41: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

we can view this as a 2-trace property (12)

41

1 init states have different secrets same public values2 attacker takes arbitrary actions at each step3 must prove results of invocation are same at each step

=res =res

priv_level=SU foo(1)

priv_level=U foo(4)

res=perp

res=2 res=6

b=0 b=1

Initial States

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 42: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

we can view this as a 2-trace property (22)

42

1 Init states have different secrets same public values

2 Attacker takes arbitrary actions at each step

3 Must prove results of invocation are same at each step

=res =res

forall12058711205872 isin 1198791199031198861198881198901199041205871 0 119901119906119887119897119894119888 = 1205872 0 119901119906119887119897119894119888 rArrforall119894 119903119890119904(1205871 119894 ) = 119903119890119904(1205872 119894 )

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 43: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

there is a well-developed theory here

43

bull This was an example of a hyperproperty [Clarkson and Schneider 2009]

bull Was a relation over traces not a set of traces

bull Studied since at least the early eightiesminus Non-interference [Goguen and Meseguer 1982]

minus Observational Determinism [Zdancewic and Myers 2003]

minus Many more classes with many subtle (but important) differences

Hyperproperties enable succinct system-level security specification

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 44: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

44

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 45: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

enclave platforms 101 (13)

45

Program Code+Input

Output

What guarantees do we want for secure remote execution

[CCSrsquo17]

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 46: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

enclave platforms 101 (23)

46

MyApp App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

How to ensure security in this scenario

Typical public cloud implies untrusted OS hypervisor and co-located apps

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 47: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

enclave platforms 101 (33)

47

MyEnc App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

Enclave Platforms like Intel SGX and MIT Sanctum provide ISA-level primitives for ldquosecurerdquo remote execution

Enclave consists of

bull Protected mem region for codedatabull Even OSVM canrsquot access enclave membull HW ldquomeasurementrdquo operator

Research Question How do enclave primitives translate to secure remote execution

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 48: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

using enclaves

1 User sends program

2 Untrusted OS creates enclave

3 User authenticates w measurement

4 If measurement matches encrypted input is set to enclave

5 Enclave computes returne encrypted output

48

Program

App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

MyEnc

untrusted network

MyEnc

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 49: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

how could platforms betray us

bull Access control untrusted code is able to readwrite enclave memory

bull Side channels caches page tables speculation etc

bull Measurements different enclaves with the same measurement

bull Bad operations like cloning of enclaves

49

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 50: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Secure Remote Execution of Enclaves

Remote serverrsquos execution of enclave program e must be identical to trusted local execution modulo inputs provided to the enclave

50

(Definition) Secure Remote Execution (SRE)

(Theorem) SRE Decomposition

Measurement is the right program being executed

Integrity is adversary effect on enclave restricted to providing inputs

Confidentiality is adversary state a deterministic function of only public observations and adversary operations

SRE

equ

ival

ent

to

MIC

pro

per

ties

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 51: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Enclave Measurement Property

51

hellip hellip

hellip hellip

Sam

e m

eas

Sam

e In

pu

t

Sam

e In

pu

t

If we start two enclaves with the same measurement and and if at each step the enclave executes the inputs to the enclave are identical then these two enclaves must have the same state and outputs at every step

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 52: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Enclave Integrity Property

52

hellip hellip

hellip hellip

Sam

e En

clav

e

Sam

e In

pu

t

Sam

e In

pu

t

If we start two identical enclaves and if at each step the enclave executes the inputs to the enclave are identical then regardless of adversary actions the enclave computation must also be identical

A1

A2

A1

A2

e

e

e

e

Sam

e en

cst

Sam

e en

cst

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 53: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Enclave Confidentiality Property

53

hellip hellip

hellip hellip

Sam

e A

dv

Sam

e O

bs

Sam

e O

bs

If we start two different enclaves and if at each step the enclave executes the outputs of the enclave are identical and the adversary actions are the same then regardless of adversary actions the adversary state must also be identical

A

A

A

A

e1

e2

e1

e2

Sam

e ad

vst

Sam

e ad

vst

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 54: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

The Trusted Abstract Platform

54

bull Registers program counterbull Virtual to physical mappingsbull Enclave metadatabull Memory and associated cache

bull Create Destroybull Enter Exitbull Pause Resumebull LoadStoreALUbull Update page tables

TAP State Variables TAP Operations

A model of an enclave platform that is not specific to a particular implementation like SGX or Sanctum

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 55: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Verification of Enclave Platforms

55

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

The TAP provides a common framework for reasoning about security of enclave platform primitives and adversary models

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 56: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Verification of Enclave Platforms

56

Intel SGX ModelMIT Sanctum

Model

Trusted Abstract Platform

Parameterized Adversary Model

Machine-checked simulation proof

Machine-checked proof of SREbull create(container_t )bull destroy(enclave_t)bull enter(enclave_t)bull exit()bull pause(enclave_t)bull resume(enclave_t)bull rand()bull attest(msg_t)

bull Proofs were done by induction just like this tutorialbull Two safety properties proven using self-composition

4700 lines of proof code + 4200 lines of model

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 57: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

what is the point of all this

bull enclave platforms are quite complex SGX developer guide is 381 pages

and guide already assumes reader understands enclave security guarantees

bull you might think their security specification would be complex too

bull but no only 3 hyperproperties capture enclave security guarantees

moral of the story security specification can be a lot more succinct (and easier to verify) than a specification of full functional correctness

57

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 58: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

outline revisited

we should care about HW security

can we reconstruct trust in an untrusted component (bottom-up)

can we prove a trusted component is trustworthy (top-down)

bull techniques for security property specification

bull case study of enclave platform verification

whatrsquos connection between the two

58

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 59: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

where are we now

59

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

verified SRE at this level of abstraction

reverse engineeringIntel SGX Impl

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 60: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

where we would like to be

60

Trusted Abstract Platform Model

SGX Model Sanctum Model

Monitor (FW code in C)

Processor (Chisel)

Binary CodeSynthesized

Netlist

Intel SGX Impl

secure remote execution guarantees for the entire stack

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 61: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

what makes this difficult

microarchitectural impl and RTL synthesis pose new verif challenges

bull new attacks become possible at the lower layers (eg spectre)

bull system invariants may be messed up due to retiming etc

therefore proofs cannot be straightforwardly translated to lower levels

this is where reverse engineering could help bridge the gap

61

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 62: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

lot of important research problems here

bull can we do hyperproperty mining for finding security properties

bull software compilation is known to introduce security bugsdoes synthesis also do the same

if so what are they and how do we fix them

if not why not and can we use those tricks in software

bull the μarchHWFWSW interfaces seem to be a rich source of bugs

eg spectre sysret rowhammer etc

what can we do to eliminate these bugs

62

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 63: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

more broadly hyperproperties are under-explored

bull they capture properties like determinism commutativity associativitycould be important in specification of system-level behavior

bull in security a key challenge is formulating the right propertyhyperproperties can help here

bull verification techniques are also relatively under-studiedrelational invariants seem to be harder for IC3 etc

63

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 64: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

references

bull Goguen and Meseguer Security Policies and Security Models SP lsquo82

bull Cong and Ding FlowMap TCAD rsquo94

bull Zdancewic and Myers Observational Determinism for Concurrent Program Security CSFW rsquo04

bull Terauchi and Aiken Secure Information Flow as a Safety Problem SAS lsquo05

bull Chatterjee Mischenko Brayton Reducing Structural Bias in Technology Mapping TCAD rsquo06

bull Li et al WordRev Finding word-level structures in a sea of bit-level gates HOST lsquo13

bull Subramanyan et al Reverse Engineering Digitial Circuits using Functional Analyses DATE lsquo13

bull Subramanyan et al Reverse Engineering Digital Circuits using Structural and Functional Analyses TETC rsquo14

bull Gascon et al Template-based circuit understanding FMCAD rsquo14

bull Subramanyan et al A Formal Foundation for Secure Remote Execution of Enclaves CCS rsquo17

bull Yang et al Lazy Self-Composition for Security Verification CAV rsquo18

64

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 65: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Thank You

65

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 66: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Identifying Register FilesNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

RF analysisCombinational component analyses

Sequential component analyses

66

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 67: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

The Structure of a Register File

67

Register FileWrite data

Write addr + write enable

Read address

Read data

Register file consists of

bull Flip-flops that store informationbull Read logic takes a read address and outputs stored databull Write logic stores data in the register file

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 68: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Identifying Read Logic

68

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Insight look for trees of logic where the leaves of the tree are flip-flops

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 69: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Verifying Identified Read Logic

69

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

bull Verify there exists some address which propagates each flip-flop output to the data output

bull This is done using a BDD-based analysis

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 70: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Identifying Write Logic

70

bull Muxes select between current value and write databull Decoders select the location that is being written tobull Easy to find muxes and decoders after we find the flip-flops

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 71: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Overlap ResolutionNetlist

Common-support analysis

K-cut matching

Aggregation

Word propagation

Module generation

Library Matching

Multibit Register Analysis

RF analysis

Counter analysis

Shift register analysis

71

Combinational component analyses

Sequential component analyses

Overlap Resolution

Abstracted Netlist

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 72: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Problem Inferred Modules Overlap

72

FF FF FF FF FF FF FF FF

dataout

addr[2]

addr[1]

addr[0]

Inferred register file

4-bit MUX

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 73: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Resolving Overlaps

Formulate an Integer-Linear Program

1 Constraints specify that modules must not overlap2 Objective is one of the following

bull Maximize the number of covered gates ORbull Minimize the number of modules given a coverage target

73

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 74: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

Experimental Setup

bull Implemented in C++

bull MiniSAT 22

bull CUDD 24

bull CPLEX 125

Toolchain

bull Many from OpenCoresorg

bull Size ranges from few hundred to several thousand gates

bull Also got a test case with 375k gates from DARPA

Designs

74

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 75: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

why the deluge of security breachesmy theory of the case

75

1 attacks possible from above below and peers(so everything ends up in the TCB)

2 layer boundaries are ill-specifiedfor ex AMD vs Intel sysret

3 security requirements not formally specifiedfor ex meltdown foreshadow

OS

App App App

OS OS

Hypervisor

FW FW FW

CPU SoC HW

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76

Page 76: Reverse Engineering for Security · Reverse Engineering for Security Pramod Subramanyan spramod@cse.iitk.ac.in Indian Institute of Technology, Kanpur 6th Workshop on Design Automation

what is the impact of hardware bugs

Beforeafter pictures of a suspected nuclear reactor site

Suspicion that a hardware backdoor was exploited to disable the radar system

[Sally Adee The Hunt for the Kill Switch IEEE Spectrum May 2008][John Markoff Old Trick Threatens the Newest Weapons NY Times 26 October 2009] 76