information flow control for distributed trusted execution

Information Flow Control for Distributed Trusted

Execution Environments

Anitha Gollamudi Owen ArdenStephen Chong

�1

Trusted Execution Environment (TEE)

•Protected memory region for code and data

•Offers isolated execution and remote attestation

•Only host can communicate with TEE

•Hardware feature

•e.g. Intel SGX, ARM TrustZone

•Good fit for offering security in distributed settings

2

TEEs ⇏ Security Guarantees

!3


!3

if secretsend cipher on public

else ()


!3


else ()

Ah, secret is 1


!3


else ()

Ah, secret is 1

Information Flow Control (IFC) techniques!

IFC for Distributed TEEs: Challenges

!4


1. Choose right abstractions for crypto and TEEs

• Focus on application-level security

• Reflect the capabilities and limitations of TEEs

• e.g. TEE can communicate only with the host

• Implementable!

!4


1. Choose right abstractions for crypto and TEEs


• Reflect the capabilities and limitations of TEEs

• e.g. TEE can communicate only with the host

• Implementable!

2. Enforce security

!4

Contributions

!5

Contributions1. Distributed Flow-limited Authorization calculus for TEEs

(DFLATE)

• Supports distributed TEEs

• Design mapping to real system

!5

Contributions1. Distributed Flow-limited Authorization calculus for TEEs

(DFLATE)

• Supports distributed TEEs

• Design mapping to real system

2. A permissive security type system

• Enforces security (noninterference) for confidentiality and integrity

!5

DFLATE

• Simply typed lambda calculus extended with

• Communication primitives (send/receive/spawn)

• Abstractions for crypto and TEE

• Security types

!6

Address Challenge #11. Choose right abstractions for crypto and TEEs

• Abstractions should reflect the capabilities and limitations of TEEs

• e.g. TEE can only communicate with host


• Implementable!

2. Enforce security

!7

Communication

!8

recv chab as x in…

Alice (a) Bob (b)

send blue on chab

chab

Securing Communication

!9

if secretsend blue on public

else ()

Public channel


!10


else ()

Public channel


!10

Security labels on channels prevent leaks due to communication


else ()

Public channel

!11

Communication through trusted/untrusted nodes

1

2

?

!11


1

2

•Bob can not learn/modify the content of the message•Bob may learn the existence of the message

?

!11


1

2

•Bob can not learn/modify the content of the message•Bob may learn the existence of the message

Bob can learn the message received from Alice

?

!12

2b

Carol must not learn the contents of the blue message

2a

Carol may learn the contents of the blue message

!13

3

Bob cannot learn/modify the orange message

Support for communication with enclaves

DFLATE abstracts crypto mechanisms using protected expressions

!14

chab

!15

Protected Expression

(ηa 42)chab

!15


Protected expression

(ηa 42)chab

!15


Protected expression

Protected expressions abstract encryption and signing

!16


chab

has type a says int(ηa 42)

(ηa 42)

send (ηa 42) on chab

recv chab as enc inbind x = enc in ( f x)

Bind abstracts decryption and signature verification

Operating on Protected Expressions

!17

chab

(ηa 42)

send (ηa 42) on chab


To successfully decrypt,Alice must authorize Bob

Secure Bind

!18

chab

(ηa 42)

Bob ≽ Alice

Principals delegate authority using acts-for (≽)!19

assume b ≽ a insend (ηa 42) on chab


Delegation of Authority

!20

(ηa 42)chab



Delegation of Authority

!20

(ηa 42)

Assume abstracts key sharing among principals

chab

!21

1

2

a says τ

a says τ


•Bob must not learn/modify the content of the message•Bob may learn the existence of the message

?

!21

1

2

a says τa says τ

a says τ



?

!21

Types enable reasoning about Bob’s power

1

2

a says τa says τ

a says τ



?



Secure Bind (2)

!22

(ηa 42)chab



Bob must not leak the decrypted value

Secure Bind (2)

!22

(ηa 42)chab



Secure Bind (2)

!23

(ηa 42)chab

a ⊑ τ

The output type of bind must protect Alice



Secure Bind (2)

!23

(ηa 42)chab

a ⊑ τThe output type of bind must protect Alice

!24

Type system ensures that Bob uses the decrypted value securely

2b

Carol must not learn the contents of the blue message

2a

Carol may learn the contents of the blue message

a says τ

a says τ b says τ′�

b says τ′�

assume t ≽ a in send (ηa blue) on chab

assume t ≽ c in recv chbc as x in ⋯

recv chab as xsend x on chbt

recv chbt as x′� in ⋯

TEEt {⋯send v on chbt

}

Abstracting TEE

!25

chab chbc



recv chab as xsend x on chbt

recv chbt as x′� in ⋯


}

Computation principal

Abstracting TEE

!25

chab chbc



recv chab as xsend chbt x then recv chbt as x′� in ⋯


}

Abstracting TEE

!26

chab chbc

!27

3

a says τ


!27

3

a says τ a says τ′�


Implementing DFLATE

!28

Design• DFLATE abstractions are implementable!

!29


• TEEs can be implemented by Intel SGX enclaves

• SGX provides remote attestation

• SGX enclave communicates through the host

!29


• TEEs can be implemented by Intel SGX enclaves

• SGX provides remote attestation

• SGX enclave communicates through the host

• Protected expressions can be implemented using public key encryption and digital signatures

• However, this requires access to the corresponding signing/decryption keys

• Key distribution, especially for enclaves, is non-trivial

!29

Key Distribution

• A global key master has key pairs for all principals

• Key master provisions the nodes and enclaves with necessary private keys

!30

Key Distribution

!31

Key Master

To obtain keys, a node proves its identity to the key master

Key Distribution

!32

Key Master

To obtain keys, an enclave attests itself to the key master

Address Challenge #21. Choose right abstractions for crypto and TEEs

• Abstractions should reflect the capabilities and limitations of TEEs

• e.g. TEE can only communicate with host


• Implementable!

2. Enforce security

!33

Security

• Formal definition of security is noninterference (NI)

• Confidentiality NI: private inputs can’t influence public outputs

• Integrity NI: Low integrity inputs can’t influence high integrity outputs

• Type system enforces security

!34

Example Revisited

Alice

!35

Bob


Ah, secret is 1

Example Revisited

Alice

!35

Bob


Ah, secret is 1

Program is ill-typed

Confidentiality Theorem

!36

Secret inputs from Alice Public outputs

Integrity Theorem

!37

Untrusted inputs from Bob

Trusted outputsto Carol

Compromised-node Noninterference

!38


!38

Trace for blue execution


!38


Trace for green execution

Traces observed (by Bob) for executions with different secret inputs are equal


!39


!39


Trace for green execution

Traces observed can be different

Confidentiality vs Integrity Guarantees

• Asymmetry due to the ability to suppress messages

• Faithfully models the expressive power of the integrity attacker

• Without undermining the guarantees of cryptography and TEEs

!40

Conclusion

• DFLATE: A programming model for distributed TEEs

• Design for implementing the abstractions in DFLATE

• DFLATE enforces confidentiality and integrity

!41

Backup Slides

!42

(ηa 42)

!43

Nested Protection

chab

(ηa 42)

!43

Nested Protection

chab

has type b says a says int(ηb (ηa 42))

(ηb (ηa 42))

send chab (ηa mblue) recv chab as x in send chbc x

!44

send chab (ηa mblue) assume b ≽ a inrecv chab as x in send chbc x

!45

send chab (ηa mblue)assume b ≽ a inrecv chab as x in send chbc x

!45

Malicious declassification


Type system prevents malicious declassifications and endorsements

!45

Malicious declassification


Insufficient authority to add delegation!46

information flow control for distributed trusted execution

Documents