Execution Secure Processors Eurocrypt May 1 st , 2017 Rafael Pass, - - PowerPoint PPT Presentation

▶
execution secure processors
SMART_READER_LITE
LIVE PREVIEW

Execution Secure Processors Eurocrypt May 1 st , 2017 Rafael Pass, - - PowerPoint PPT Presentation

Apr 17, 2023 201 likes •929 views

Formal Abstractions for Attested Execution Secure Processors Eurocrypt May 1 st , 2017 Rafael Pass, Elaine Shi, Florian Tramr Trusted hardware: Different communities, different world views 2 Trusted hardware: Different communities,

slide-1
SLIDE 1

Formal Abstractions for Attested Execution Secure Processors

Eurocrypt May 1st, 2017 Rafael Pass, Elaine Shi, Florian Tramèr

slide-2
SLIDE 2

Trusted hardware:

Different communities, different world views

2

slide-3
SLIDE 3

Trusted hardware:

Different communities, different world views

Crypto

Architecture Systems & Security

2

slide-4
SLIDE 4

Trusted hardware:

Different communities, different world views

Crypto

Architecture Systems & Security

  • “Minimal” trusted

hardware to circumvent theoretical impossibilities

  • Little concern about

practical performance

2

slide-5
SLIDE 5

Trusted hardware:

Different communities, different world views

Crypto

Architecture Systems & Security

  • “Minimal” trusted

hardware to circumvent theoretical impossibilities

  • Little concern about

practical performance

  • Trusted execution of

“general-purpose” user- defined progs

  • Cost-effectiveness,

reusability, expressivity

2

slide-6
SLIDE 6

3

TPM Bastion Sanctum Ascend XOM Aegis Iso-X Phantom GhostRider

Academia Industry

Architecture community converged on “attested execution”

slide-7
SLIDE 7

4

Architecture community converged on “attested execution”

slide-8
SLIDE 8

Attested Execution

5

Client Server

Compute prog on inp

slide-9
SLIDE 9

Attested Execution

5

Client Server Enclave

Compute prog on inp

slide-10
SLIDE 10

Attested Execution

5

Client Server

Verify

Enclave Manufacturer

Sign

Compute prog on inp

slide-11
SLIDE 11

Attested Execution

5

Client Server

Verify

Enclave Manufacturer

Sign

Compute prog on inp

  • utp, σ

Attestation that outp is correctly computed from prog and inp

slide-12
SLIDE 12

Why Ideal Abstractions?

6

slide-13
SLIDE 13
  • Formal security proofs for implementations

from precise abstractions and security models

Why Ideal Abstractions?

6

slide-14
SLIDE 14
  • Formal security proofs for implementations

from precise abstractions and security models

  • Ultimate Goal: Formally verified processor

implementing this formal abstraction

Why Ideal Abstractions?

6

slide-15
SLIDE 15

Formal Model

7

𝓗att[Σ, reg]

Signature scheme Registry of all platforms with trusted hardware

slide-16
SLIDE 16

Formal Model

7

𝓗att[Σ, reg]

init():

, ⟵ Σ.KeyGen(1λ)

getpk() from P: send

to P

Signature scheme Registry of all platforms with trusted hardware

slide-17
SLIDE 17

Formal Model

7

𝓗att[Σ, reg]

init():

, ⟵ Σ.KeyGen(1λ)

getpk() from P: send

to P

install(prog, sid) from P ∊ reg: Signature scheme Registry of all platforms with trusted hardware

slide-18
SLIDE 18

Formal Model

7

𝓗att[Σ, reg]

init():

, ⟵ Σ.KeyGen(1λ)

getpk() from P: send

to P

install(prog, sid) from P ∊ reg: Signature scheme Registry of all platforms with trusted hardware (eid, P) ( sid, prog, M ) enclave id (nonce) enclave memory … …

slide-19
SLIDE 19

Formal Model

7

𝓗att[Σ, reg]

init():

, ⟵ Σ.KeyGen(1λ)

getpk() from P: send

to P

install(prog, sid) from P ∊ reg: resume(eid, inp) from P ∊ reg: Signature scheme Registry of all platforms with trusted hardware (eid, P) ( sid, prog, M ) enclave id (nonce) enclave memory … …

slide-20
SLIDE 20

Formal Model

7

𝓗att[Σ, reg]

init():

, ⟵ Σ.KeyGen(1λ)

getpk() from P: send

to P

install(prog, sid) from P ∊ reg: resume(eid, inp) from P ∊ reg: (out, M’) = prog(inp, M) Signature scheme Registry of all platforms with trusted hardware (eid, P) ( sid, prog, M ) enclave id (nonce) enclave memory … …

slide-21
SLIDE 21

Formal Model

7

𝓗att[Σ, reg]

init():

, ⟵ Σ.KeyGen(1λ)

getpk() from P: send

to P

install(prog, sid) from P ∊ reg: resume(eid, inp) from P ∊ reg: (out, M’) = prog(inp, M) Signature scheme Registry of all platforms with trusted hardware (eid, P) ( sid, prog, M ) enclave id (nonce) enclave memory … …

’

slide-22
SLIDE 22

Formal Model

7

𝓗att[Σ, reg]

init():

, ⟵ Σ.KeyGen(1λ)

getpk() from P: send

to P

install(prog, sid) from P ∊ reg: resume(eid, inp) from P ∊ reg: (out, M’) = prog(inp, M) σ = Σ.Sign( , eid, sid, prog, out) send (out, σ) to P Signature scheme Registry of all platforms with trusted hardware (eid, P) ( sid, prog, M ) enclave id (nonce) enclave memory … …

’

slide-23
SLIDE 23

Composability with Global State

8

slide-24
SLIDE 24

Composability with Global State

8

Model 𝓗att as global ideal functionality [CDPW’07]

slide-25
SLIDE 25

Composability with Global State

8

Model 𝓗att as global ideal functionality [CDPW’07]

𝓗att[Σ, reg]

Attestation key is shared across protocols

slide-26
SLIDE 26

Composability with Global State

Model 𝓗att as global ideal functionality [CDPW’07]

σ

𝓗att[Σ, reg]

9

slide-27
SLIDE 27

Composability with Global State

Model 𝓗att as global ideal functionality [CDPW’07]

σ

𝓗att[Σ, reg]

Example of concrete security issue:

Non-deniability for parties in reg

9

slide-28
SLIDE 28

10

The more interesting question

slide-29
SLIDE 29

The good

11

Powerful Abstraction!

slide-30
SLIDE 30

The good

11

Powerful Abstraction!

𝓗att ➔ ‘’Stateful Obfuscation’’ Impossible even with stateless tokens and cryptographic

  • bfuscation
slide-31
SLIDE 31

The good The surprise

11

Powerful Abstraction!

𝓗att ➔ ‘’Stateful Obfuscation’’ Impossible even with stateless tokens and cryptographic

  • bfuscation

UC-Secure MPC?

slide-32
SLIDE 32

The good The surprise

11

Powerful Abstraction!

𝓗att ➔ ‘’Stateful Obfuscation’’ Impossible even with stateless tokens and cryptographic

  • bfuscation

UC-Secure MPC?

slide-33
SLIDE 33

The surprise

12

UC-Secure MPC?

slide-34
SLIDE 34

Consider 2PC

13

slide-35
SLIDE 35

14

UC-secure 2PC possible if both parties have trusted hardware

Consider 2PC

slide-36
SLIDE 36

14

UC-secure 2PC possible if both parties have trusted hardware Impossible if only one party has trusted hardware!

Consider 2PC

slide-37
SLIDE 37

15

Impossible if only one party has trusted hardware!

Consider 2PC

This is counter-intuitive.

slide-38
SLIDE 38

Issue: non-deniability

16

under global pk

slide-39
SLIDE 39

Issue: non-deniability

16

under global pk

Convinced that some honest party in the registry participated in the protocol

slide-40
SLIDE 40

17

under global pk

Convinced that some honest party in the registry participated in the protocol

Non-issue if all nodes have trusted hardware

  • r if pk isn’t global
slide-41
SLIDE 41

What if we really really want to use a single trusted processor?

18

slide-42
SLIDE 42

What if we really really want to use a single trusted processor?

18

Extra setup assumption: Augmented CRS

slide-43
SLIDE 43

What if we really really want to use a single trusted processor?

18

Extra setup assumption: Augmented CRS

UC-Secure MPC with O(1) crypto operations

slide-44
SLIDE 44

What if we really really want to use a single trusted processor?

18

Extra setup assumption: Augmented CRS Backdoor enclave program: allow simulator to extract inputs and program the outputs for corrupt parties

UC-Secure MPC with O(1) crypto operations

slide-45
SLIDE 45

Server

What if we really really want to use a single trusted processor?

19

prog[f,𝓗acrs,𝒬1 … 𝒬n]

𝒬i

slide-46
SLIDE 46

Server

What if we really really want to use a single trusted processor?

19

prog[f,𝓗acrs,𝒬1 … 𝒬n]

  • 1. Generate pki,ski

𝒬i

slide-47
SLIDE 47

Server

What if we really really want to use a single trusted processor?

19

prog[f,𝓗acrs,𝒬1 … 𝒬n]

  • 1. Generate pki,ski

𝒬i pki, σ Full protocol replaces σ by a WI-Proof

slide-48
SLIDE 48

Server

What if we really really want to use a single trusted processor?

19

prog[f,𝓗acrs,𝒬1 … 𝒬n]

  • 1. Generate pki,ski

Key-exchange 𝒬i pki, σ Full protocol replaces σ by a WI-Proof

slide-49
SLIDE 49

Server

What if we really really want to use a single trusted processor?

19

prog[f,𝓗acrs,𝒬1 … 𝒬n]

  • 1. Generate pki,ski
  • 1. Collect all inpi

Key-exchange 𝒬i pki, σ Encrypted inpi Full protocol replaces σ by a WI-Proof

slide-50
SLIDE 50

Server

What if we really really want to use a single trusted processor?

19

prog[f,𝓗acrs,𝒬1 … 𝒬n]

  • 1. Generate pki,ski
  • 1. Collect all inpi
  • 2. Compute outp*

Key-exchange 𝒬i pki, σ Encrypted inpi Encrypted outpi Full protocol replaces σ by a WI-Proof

slide-51
SLIDE 51

Server

What if we really really want to use a single trusted processor?

20

prog[f,𝓗acrs,𝒬1 … 𝒬n]

  • 3. Trapdoors

Sim

slide-52
SLIDE 52

Server

What if we really really want to use a single trusted processor?

20

prog[f,𝓗acrs,𝒬1 … 𝒬n]

  • 3. Trapdoors

check(𝒣acrs, 𝒬i, idi)

Sim extract(idi)

slide-53
SLIDE 53

Server

What if we really really want to use a single trusted processor?

20

prog[f,𝓗acrs,𝒬1 … 𝒬n]

  • 3. Trapdoors

check(𝒣acrs, 𝒬i, idi)

Sim extract(idi) ski Sim can recover inpi

slide-54
SLIDE 54

Server

What if we really really want to use a single trusted processor?

20

prog[f,𝓗acrs,𝒬1 … 𝒬n]

  • 3. Trapdoors

check(𝒣acrs, 𝒬i, idi) set outpi = v

Sim equivocate(idi, v)

slide-55
SLIDE 55

21

Fair 2PC?

slide-56
SLIDE 56

21

Fair 2PC?

  • Fairness impossible for general

functionalities in plain model [Cleve86]

slide-57
SLIDE 57

21

Fair 2PC?

  • Fairness impossible for general

functionalities in plain model [Cleve86]

Can trusted hardware help with fairness?

slide-58
SLIDE 58

22

UC-Secure Fair 2PC

Enhanced model: Clock-aware secure processor

slide-59
SLIDE 59

22

UC-Secure Fair 2PC

Enhanced model: Clock-aware secure processor

  • Fair 2PC possible if both parties have clock-

aware secure processors

slide-60
SLIDE 60

22

UC-Secure Fair 2PC

Enhanced model: Clock-aware secure processor

  • Fair 2PC possible if both parties have clock-

aware secure processors

  • Fair coin-tossing possible if one party has clock-

aware secure processors (+ ACRS)

slide-61
SLIDE 61

22

UC-Secure Fair 2PC

Enhanced model: Clock-aware secure processor

  • Fair 2PC possible if both parties have clock-

aware secure processors

slide-62
SLIDE 62

23

Enclaves establish secure channel

slide-63
SLIDE 63

23

Enclaves establish secure channel Enclaves exchange inputs and compute outputs

slide-64
SLIDE 64

23

Enclaves establish secure channel Enclaves exchange inputs and compute outputs “Will release to Alice in 2λ time” “Will release to Bob in 2λ time”

slide-65
SLIDE 65

23

Enclaves establish secure channel Enclaves exchange inputs and compute outputs “Will release to Alice in 2λ time” “Will release to Bob in 2λ time” “Will release to Alice in 2λ-1 time” “Will release to Bob in 2λ-1 time”

…

slide-66
SLIDE 66

24

Enclaves establish secure channel “Will release to Alice in 2λ-1 time” “Will release to Bob in 2λ-1 time” …

If Alice learns result at time t < 2λ, Bob will learn it at the latest by time 2t + no ‘’wasted’’ computation!

slide-67
SLIDE 67

What next?

Formal abstractions

  • f trusted hw
slide-68
SLIDE 68

What next?

Attested execution is a powerful assumption

⟹ Stateful Obfuscation, Efficient MPC, Fair 2PC

Formal abstractions

  • f trusted hw
slide-69
SLIDE 69

What next?

Attested execution is a powerful assumption

⟹ Stateful Obfuscation, Efficient MPC, Fair 2PC

Subtle issues unless all parties have trusted hardware

⟹ Non-deniability, Extra setup assumptions

Formal abstractions

  • f trusted hw
slide-70
SLIDE 70

What next?

Attested execution is a powerful assumption

⟹ Stateful Obfuscation, Efficient MPC, Fair 2PC

Subtle issues unless all parties have trusted hardware

⟹ Non-deniability, Extra setup assumptions

Formal abstractions

  • f trusted hw

Formally verified secure processor design

slide-71
SLIDE 71

What next?

Attested execution is a powerful assumption

⟹ Stateful Obfuscation, Efficient MPC, Fair 2PC

Subtle issues unless all parties have trusted hardware

⟹ Non-deniability, Extra setup assumptions

Formal abstractions

  • f trusted hw

Formally verified secure processor design Secure implementations from formally secure abstractions

slide-72
SLIDE 72

Thank You

Formal abstractions

  • f trusted hw

Formally verified secure processor design Secure implementations from formally secure abstractions