GENERIC TRUSTED COMPONENT BRUNO VAVALA CMU / UL Nuno Neves Peter - - PowerPoint PPT Presentation

SECURE IDENTIFICATION of ACTIVELY EXECUTED CODE on a GENERIC TRUSTED COMPONENT

Nuno Neves

UL IEEE/IFIP Conference on Dependable Systems & Networks (DSN’16)

BRUNO VAVALA

CMU / UL

Peter Steenkiste

CMU

• utline

Problem definition Identifying Actively Executed Code Practical Analysis Conclusions

Trusted Executions: trends & tradeoffs

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Anatomy of a Trusted Execution

3

Execute

client untrusted third party

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

secure environment

Anatomy of a Trusted Execution

Load & Identify Outsource Execute Attest Verify

untrusted third party client

4

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

secure environment

Anatomy of a Trusted Execution

Load & Identify Outsource Execute Attest V erify

untrusted third party client

5

• Code must have an ID (i.e. hash)
• Trusted hardware computes ID
• Hardware attests the ID
• Client trusts hardware & ID

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Generic TCC Interface

• execute
• code loading + identification + isolated execution
• attest
• TCC-signed code identity and I/O data
• auth_put
• secure storage for a specific recipient 


(TCC authenticates the sender)

• auth_get
• secure storage from a specific sender 


(TCC authenticates the recipient)

• verify


6

UTP-side client-side

Implementable with:

• Intel TXT + TPM
• Hypervisor-based TCC
• Intel SGX
• …

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Trends

7

Reduced TCB On-demand execution Improved efficiency Richer services in TCB +security +efficiency Now

timeline

Static Root of Trust: a system is able to boot in a verifiable trusted state. [2004] TOCTOU Problem: static measurements do not reflect later changes. [2005-] Dynamic Root

• f Trust: build

a new robust and verifiable chain of trust

• n demand.

[2008] Fast Trusted Computing: combine slow trusted chips with software

• n main CPU.

[2010-] Large Trusted Executions: implement large services in the trusted environment. [2011-]

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Security/Efficiency Tradeoff 
 for Large-Scale Services

8

identify-once- execute-once

?

identify-once- execute-forever

security efficiency

high high low

Trusted Executions: trends & tradeoffs

• utline

Identifying Actively Executed Code Practical Analysis Conclusions Problem definition

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Code Identity

10

/* SQLite code */ int main () { switch(op) { case SELECT: do_select(); case DELETE: do_delete(); case INSERT: do_insert(); . . case FOOBAR: do_foobar(); }

COMPILE IDENTIFY

source code binary code identity

SQLite

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Verification

11

VERIFIES VOUCHES FOR

executed code attested identity client

SQLite

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Identified ≠ Executed

12

identified binary code

actually executed binary code

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Desirable Properties

• Identifying what is “actually” executed
• TCC agnostic execution
• Keeping efficient client-side verification

13

Trusted Executions: trends & tradeoffs

• utline

Problem definition Practical Analysis Conclusions Identifying Actively Executed Code

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Trusted Environment

Model

15

hardware OS TCC untrusted services

• OS and services are untrusted
• Client knows service identity and TCC certificate

trusted service TPM/SGX

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Enriching the Interface

• execute
• code loading + identification + isolated execution
• attest
• TCC-signed code identity and I/O data
• auth-put
• secure storage for a specific recipient 


(TCC authenticates the sender)

• auth-get
• secure storage from a specific sender 


(TCC authenticates the recipient)

• verify


16

UTP-side client-side

Implementable with:

• Intel TXT + TPM
• Hypervisor-based TCC
• Intel SGX
• …

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

One ID Per Code Module

17

/* SQLite code */ int main () { switch(op) { case SELECT: do_select(); case DELETE: do_delete(); case INSERT: do_insert(); . . case FOOBAR: do_foobar(); }

select delete insert foobar

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

18

A B C

hardware OS TCC A B C A B C

code base

• Execution flows: A-to-B, A-to-C
• If C must be executed, then B is not loaded

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

19

A B C

hardware OS TCC A B C A B C

code base

input, ID’s Tab

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

20

A B C

hardware OS TCC A B C A B C

code base

input, ID’s Tab

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

21

A B C

hardware OS TCC A B C A B C

code base

• int. results,

ID’s Tab

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

22

A B C

hardware OS TCC A B C A B C

code base

1.id(A) 2.id(B) 3.id(C)

identity table

secure channel

• int. results,

ID’s Tab

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

23

A B C

hardware OS TCC A B C A B C

code base

• int. results,

ID’s Tab

A —>C

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

24

A B C

hardware OS TCC A B C A B C

code base

• int. results,

ID’s Tab

A —>C

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

25

A B C

hardware OS TCC A B C A B C

code base

• int. results,

ID’s Tab

A —>C

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

26

A B C

hardware OS TCC A B C A B C

code base

• int. results,

ID’s Tab

A —>C

1.id(A) 2.id(B) 3.id(C)

identity table

secure channel

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

27

A B C

hardware OS TCC A B C A B C

code base

• int. results,

ID’s Tab

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

28

A B C

hardware OS TCC A B C A B C

code base

• utput

ID’s Tab

attested

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

29

A B C

hardware OS TCC A B C A B C

code base

• utput

ID’s Tab

attested

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

30

hardware OS TCC A B C

• utput

ID’s Tab

attested

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Execution Protocol

31

hardware OS TCC A B C

• utput

ID’s Tab

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Solved Challenges for General Executions

• 1. Client/Verifier does not verify intermediate results
• Results are secured locally
• 2. Client does not verify execution flow
• Verification of last module & ID’s Table implies correct execution flow
• 3. Build mutually authenticated secure channels
• Using TCC-based secure storage
• 4. Fast (zero round) identity-based key sharing
• Construction: 1 hash using sender-receiver identity pairs


(see paper for details)

• 5. Avoid hash loops in general executions
• Detach identity from code module using the ID’s Table

32

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

• General execution may have loops

33

A B C

A B C

code base

• 5. Avoiding Hash Loops

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

• General execution may have loops

34

A B C

A B C

code base

A

ID(C)

C

ID(A)

problem

(hash loop)

• 5. Avoiding Hash Loops

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

• 5. Avoiding Hash Loops
• General execution may have loops

35

A B C

A B C

code base

A

ID(C)

C

ID(A)

1.id(A) 2.id(B) 3.id(C)

identity table

problem

(hash loop)

solution

(ID’s in input table)

A

next: 3

C

next: 1

Trusted Executions: trends & tradeoffs

• utline

Problem definition Identifying Actively Executed Code Conclusions Practical Analysis

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Practical Analysis

• Hypervisor-based TCC Implementation
• Protocol applied to a real-world service (SQLite)
• End-To-End experiments on server cluster

37

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Code Size

• SQLite (full implementation) is ~1MB
• 5-10x reduction of used code 


for single operation
 (PAL = Piece of Application Logic)

38

300 600 900 1200

PAL0 PALSEL PALINS PALDEL PALSQLITE Code Size (kilobytes)

monolithic SQLite (baseline) multi-PAL SQLite

12 135 90 155 1085 300 600 900 1200

PAL0 PALSEL PALINS PALDEL PALSQLITE Code Size (kilobytes)

monolithic SQLite (baseline) multi-PAL SQLite

12 135 90 155 1085

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

End-to-End Evaluation

39

• Same critical path, different code identification
• Monolithic SQLite is up 46% slower


(w/ attestation)

30 60 90 120 150

Insert Delete Select Time (milliseconds)

monolithic SQLite (baseline) multi-PAL SQLite

90 106 96 132 134 127

W/ Attestation

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

End-to-End Evaluation

40 20 40 60 80

Insert Delete Select Time (milliseconds)

monolithic SQLite (baseline) multi-PAL SQLite

35 47 41 75 77 71

W/O Attestation

• Multi-PAL SQLite up to 2x faster


(w/o attestation)

Trusted Executions: trends & tradeoffs

• utline

Problem definition Identifying Actively Executed Code Practical Analysis Conclusions

/ 42 Bruno Vavala - IEEE/IFIP DSN'16

Real-World Service

Conclusions

• Code identification has security/efficiency tradeoffs
• Identification of just actively executed code can:
• provide fresher integrity guarantees
• improved resource usage & performance
• be done retrofitting existing trusted components

42

Generic Trusted Component

Our Solution

Nuno Neves

UL IEEE/IFIP Conference on Dependable Systems & Networks (DSN’16)

BRUNO VAVALA

CMU/UL

Peter Steenkiste

CMU

t h a n k s

blank

blank

backup slides

/ 42 Bruno Vavala - IEEE/IFIP DSN'16 47

• Identity Dependent keys
• Sender specifies recipient’s identity to TCC
• Recipient specifies sender’s identity to TCC
• Very efficient construction (one hash per-key)

Efficient Mutually- Authenticated Channels

A C

Untrusted environment (OS+other applications) TCC

• 4. get KAC

auth data

• 2. release data
• 3. retrieve data
• 1. get KAC

MAC data