System Security Overview with an Emphasis on Security Issues for - - PowerPoint PPT Presentation

▶
system security overview
SMART_READER_LITE
LIVE PREVIEW

System Security Overview with an Emphasis on Security Issues for - - PowerPoint PPT Presentation

Mar 26, 2023 111 likes •1.27k views

System Security Overview with an Emphasis on Security Issues for Storage and Emerging NVM (Part 2) Byoungyoung Lee ( ) byoungyoung@snu.ac.kr Seoul National University 1 Outline Part1. Bugs in File Systems Semantic inconsistency

slide-1
SLIDE 1

System Security Overview with an Emphasis on Security Issues for Storage and Emerging NVM (Part 2)

Byoungyoung Lee (이병영) byoungyoung@snu.ac.kr Seoul National University

1

slide-2
SLIDE 2
  • Part1. Bugs in File Systems

Semantic inconsistency inference Fuzzing

  • Part2. Attacks and Defenses

Ransomware Cold boot attacks Side-channels

2

Outline

slide-3
SLIDE 3

The CIA Principle in Security

  • Confidentiality
  • Ability to hide information from unauthorized access
  • Integrity
  • Maintaining consistency, accuracy, and trustworthiness of data
  • Availability
  • Information requested is readily available to authorized entity

3

slide-4
SLIDE 4

Defenses

  • Many defense schemes
  • Access control
  • Encryption
  • Authentication
  • Authorization
  • Firewall
  • Intrusion detection system
  • etc.
  • Which defense schemes should you need?
  • It depends on an attack model.

4

slide-5
SLIDE 5

Attack Vectors

  • Privilege escalation attacks
  • Exploiting software bugs
  • Exploiting hardware bugs
  • Ransomware
  • Cold boot attacks
  • Side-channels

5

slide-6
SLIDE 6
  • Part1. Bugs in File Systems

Semantic inconsistency inference Fuzzing

  • Part2. Attacks and Defenses

Ransomware Cold boot attacks Side-channels

6

Outline

slide-7
SLIDE 7

Ransomware

7

A random notification: users files have been encrypted Pay ransom to recover user files

“FlashGuard: Data recovery [CCS 17]”

slide-8
SLIDE 8

Candidate Defenses against Ransomware

  • Malware detection
  • Damage has already happened when ransomware is detected
  • Journaling & log-structured filesystem
  • Ransomware with kernel privilege can destroy data backups
  • Networked & cloud storage
  • Increased storage cost
  • Can be stopped by ransomware

8

slide-9
SLIDE 9

Threat Model of Ransomware

9

slide-10
SLIDE 10

Threat Model of Ransomware

9

slide-11
SLIDE 11

Threat Model of Ransomware

9

slide-12
SLIDE 12

Threat Model of Ransomware

9

Traditional security solutions does not work

slide-13
SLIDE 13

Threat Model of Ransomware

9

Traditional security solutions does not work Need low-level solutions at the disk layer

slide-14
SLIDE 14

Defense Solutions in SSD

  • Defenses implemented in flash-based SSD
  • Without relying on software-based solutions
  • FlashGuard: Data recovery [CCS 17]
  • Leveraging existing features in SSD: out-of-place update and garbage collection
  • Retain pages caused by ransomware encryptions
  • SSD-Insider: Attack detection [ICDCS 18]
  • Detection based on behavior characteristics
  • Recovery of infected files using intrinsic delayed deletion features of NAND flash

10

slide-15
SLIDE 15
  • Part1. Bugs in File Systems

Semantic inconsistency inference Fuzzing

  • Part2. Attacks and Defenses

Ransomware Cold boot attacks Side-channels

11

Outline

slide-16
SLIDE 16

Disk Encryption (Encrypted File Systems)

12

slide-17
SLIDE 17

Trust Models in Encrypted FS

  • Memory hierarchy with trust models (when OS is trusted)

13

CPU Registers CPU Cache Random access memory Flash / Hard drives

slide-18
SLIDE 18

Trust Models in Encrypted FS

  • Memory hierarchy with trust models (when OS is trusted)

13

CPU Registers CPU Cache Random access memory Flash / Hard drives

Trusted

slide-19
SLIDE 19

Trust Models in Encrypted FS

  • Memory hierarchy with trust models (when OS is trusted)

13

CPU Registers CPU Cache Random access memory Flash / Hard drives

Trusted Untrusted

slide-20
SLIDE 20

Trust Models in Encrypted FS

  • Memory hierarchy with trust models (when OS is trusted)

13

CPU Registers CPU Cache Random access memory Flash / Hard drives

Trusted Untrusted Encrypted data

slide-21
SLIDE 21

Trust Models in Encrypted FS

  • Memory hierarchy with trust models (when OS is trusted)

13

CPU Registers CPU Cache Random access memory Flash / Hard drives

Trusted Untrusted Encryption key Encrypted data

slide-22
SLIDE 22

Trust Models in Encrypted FS

  • Memory hierarchy with trust models (when OS is trusted)

13

CPU Registers CPU Cache Random access memory Flash / Hard drives

Trusted Untrusted Encryption key Encrypted data

slide-23
SLIDE 23

Trust Models in Encrypted FS

  • Memory hierarchy with trust models (when OS is trusted)

13

CPU Registers CPU Cache Random access memory Flash / Hard drives

Trusted Untrusted Encryption key Encrypted data

slide-24
SLIDE 24

Attacking DRAM

  • Physical attacks against DRAM
  • What happen if DRAMs are detached from DIMM slots?
  • Should data be retained? Probably not.
  • DRAM cell has to be refreshed
  • If detached, a data value in a capacitor decays over time
  • Can we slowdown decay?

14

slide-25
SLIDE 25

Cold Boot Attack: Slowing Decay by Cooling

15

  • 50°C: less than 0.2% decay after 1 minute

“Lest We Remember: Cold Boot Attacks on Encryption Keys [USENIX Security 08]”

slide-26
SLIDE 26

Security Implications of Cold Boot Attack

16

CPU Registers CPU Cache Random access memory Flash / Hard drives

Trusted Untrusted Encryption key Encrypted data

slide-27
SLIDE 27

Security Implications of Cold Boot Attack

16

CPU Registers CPU Cache Random access memory Flash / Hard drives

Trusted Untrusted Encryption key Encrypted data

slide-28
SLIDE 28

Security Implications of Cold Boot Attack

  • Encryption keys stored in DRAM can be leaked
  • Demonstrated attacks in [USENIX Security 08]
  • Windows BitLocker
  • MacOS FileVault
  • Linux dm-crypt
  • Linux LoopAES
  • TrueCrypt

17

slide-29
SLIDE 29

Security Implications of Cold Boot Attack

  • Encryption keys stored in DRAM can be leaked
  • Demonstrated attacks in [USENIX Security 08]
  • Windows BitLocker
  • MacOS FileVault
  • Linux dm-crypt
  • Linux LoopAES
  • TrueCrypt

17

“the emergence of non-volatile DIMMs that fit into DDR4 buses is going to exacerbate the risk of cold boot attacks.” [USENIX Security 08]

slide-30
SLIDE 30

Countermeasures against Cold Boot Attack

  • Encryption key and states only present in registers/cache
  • TRESOR [USENIX Security 11]
  • Linux kernel patch
  • The AES encryption algorithm and its key management solely on CPU

18

CPU Registers CPU Cache Random access memory Flash / Hard drives Trusted Untrusted

slide-31
SLIDE 31

Countermeasures against Cold Boot Attack

  • Sensitive data always leaves CPU as encrypted
  • Software-only solution
  • Leverage iRAM or locked L2 cache [ASPLOS 15]
  • Hardware solution  Fully encrypted memory
  • Hardware-assisted Trusted Execution Environments
  • Intel SGX, AMD Secure Execution Environment, RISC-V Keystone [USENIX Security 16]
  • Encrypted channel
  • InvisiMem [ISCA 17]
  • ORAM-based memory controllers
  • ObfusMem [ISCA 17], SDIMM [HCPA 18]

19

slide-32
SLIDE 32
  • Part1. Bugs in File Systems

Semantic inconsistency inference Fuzzing

  • Part2. Attacks and Defenses

Ransomware Cold boot attacks Side-channels

20

Outline

slide-33
SLIDE 33

Side-Channels

  • Definition from Wikipedia

21

“Any attack based on information gained from the implementation of a computer system, rather than weaknesses in the implemented algorithm itself (e.g. cryptanalysis and software bugs)” “Timing information, power consumption, electromagnetic leaks or even sound can provide an extra source of information, which can be exploited.”

slide-34
SLIDE 34

Timing attacks

  • This may happen for website login
  • Your (plain) password is compared at the server side

22

slide-35
SLIDE 35

Timing attacks

  • This may happen for website login
  • Your (plain) password is compared at the server side

22

slide-36
SLIDE 36

Timing attacks

  • This may happen for website login
  • Your (plain) password is compared at the server side

22

slide-37
SLIDE 37

Cache Side-Channel

  • Timing channels in CPU Cache

23

slide-38
SLIDE 38

Cache Side-Channel

  • Timing channels in CPU Cache

23

Cache miss

slide-39
SLIDE 39

Cache Side-Channel

  • Timing channels in CPU Cache

23

Cache miss Request

slide-40
SLIDE 40

Cache Side-Channel

  • Timing channels in CPU Cache

23

Cache miss Request Response

slide-41
SLIDE 41

Cache Side-Channel

  • Timing channels in CPU Cache

23

Cache miss Request Response i

slide-42
SLIDE 42

Cache Side-Channel

  • Timing channels in CPU Cache

23

Cache miss Request Response i Cache hit

slide-43
SLIDE 43

Cache Side-Channel

  • Timing channels in CPU Cache

23

Cache miss Request Response i Cache hit

DRAM access, slow

slide-44
SLIDE 44

Cache Side-Channel

  • Timing channels in CPU Cache

23

Cache miss Request Response i Cache hit

DRAM access, slow No DRAM access, much faster

slide-45
SLIDE 45

Cache Side-Channel

  • Flush+Reload attack

24

Shared memory Attacker Victim cached

Shared memory

Fast if victim accessed data, slow otherwise cached

slide-46
SLIDE 46

Cache Side-Channel

  • Flush+Reload attack

24

Shared memory Attacker Victim

Shared memory

Fast if victim accessed data, slow otherwise

slide-47
SLIDE 47

Cache Side-Channel

  • Flush+Reload attack

24

Shared memory Attacker Victim

Shared memory

Fast if victim accessed data, slow otherwise flush

slide-48
SLIDE 48

Cache Side-Channel

  • Flush+Reload attack

24

Shared memory Attacker Victim Fast if victim accessed data, slow otherwise flush

slide-49
SLIDE 49

Cache Side-Channel

  • Flush+Reload attack

24

Shared memory Attacker Victim access Fast if victim accessed data, slow otherwise

slide-50
SLIDE 50

Cache Side-Channel

  • Flush+Reload attack

24

Shared memory Attacker Victim

Shared memory

access Fast if victim accessed data, slow otherwise

slide-51
SLIDE 51

Cache Side-Channel

  • Flush+Reload attack

24

Shared memory Attacker Victim

Shared memory

access Fast if victim accessed data, slow otherwise

slide-52
SLIDE 52

Meltdown: Out-of-order execution

  • Out-of-order execution
  • Out-of-order instructions leave micro-architectural traces
  • Storing values in cache
  • Give such instructions a name: transient instructions

25

slide-53
SLIDE 53

Meltdown

26

  • Permission check for transient instructions is only done
  • when committing them
  • Suppose we are running a user-level program below
slide-54
SLIDE 54

Meltdown

26

  • Permission check for transient instructions is only done
  • when committing them
  • Suppose we are running a user-level program below
slide-55
SLIDE 55

Meltdown

26

  • Permission check for transient instructions is only done
  • when committing them
  • Suppose we are running a user-level program below

Fetching a kernel address. Should not be allowed.

slide-56
SLIDE 56

Meltdown

26

  • Permission check for transient instructions is only done
  • when committing them
  • Suppose we are running a user-level program below

Fetching a kernel address. Should not be allowed. Permission checks will be done later

slide-57
SLIDE 57

Meltdown

26

  • Permission check for transient instructions is only done
  • when committing them
  • Suppose we are running a user-level program below

Fetching a kernel address. Should not be allowed. Permission checks will be done later

slide-58
SLIDE 58

Meltdown

26

  • Permission check for transient instructions is only done
  • when committing them
  • Suppose we are running a user-level program below

Fetching a kernel address. Should not be allowed. Permission checks will be done later kernel's data value will be stored in array, which can be retrieved using flush+reload

slide-59
SLIDE 59

Mitigating Meltdown

  • Kernel Page Table Isolation
  • KAISER [ESSoS 17]

27

slide-60
SLIDE 60

Side Channels in SGX

  • Page fault
  • Controlled Channel Attack [S&P 15]
  • Cache
  • Software Grand Exposure [WOOT 17]
  • Branch prediction
  • Branch shadowing [Security 17]
  • Transient out-of-order execution
  • Foreshadow [Security 18]
  • Bus snooping

 All of these are about memory access

28

slide-61
SLIDE 61

SGX's Threat Model

29

SGX CPU Cache MEE

slide-62
SLIDE 62

SGX's Threat Model

29

SGX CPU Cache MEE

Only CPU is trusted All the rest are untrusted

slide-63
SLIDE 63

SGX's Threat Model

29

SGX CPU Cache MEE Any data leaving CPU is encrypted by Memory Encryption Engine (MEE)

Only CPU is trusted All the rest are untrusted

slide-64
SLIDE 64

Attacking SGX

30

SGX CPU Cache MEE

slide-65
SLIDE 65

Attacking SGX

30

SGX CPU Cache MEE Bus snooping: Access patterns are still visible

slide-66
SLIDE 66

Attacking SGX

30

SGX CPU Cache MEE Bus snooping: Access patterns are still visible Monitor syscalls: Access patterns are still visible

slide-67
SLIDE 67

Attacking SGX

30

SGX CPU Cache MEE Bus snooping: Access patterns are still visible Monitor syscalls: Access patterns are still visible Cache side channels

slide-68
SLIDE 68

Why Does Access Patterns Matter?

31

Client Server Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry)

slide-69
SLIDE 69

Why Does Access Patterns Matter?

31

Client Server Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Request: C

slide-70
SLIDE 70

Why Does Access Patterns Matter?

31

Client Server Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Request: C Response: Ek(Apple)

slide-71
SLIDE 71

Why Does Access Patterns Matter?

31

Client Server Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Request: C Response: Ek(Apple) Server learns client asked for “C” How to make client’s query private?

slide-72
SLIDE 72

Easy Solution: Ask Everything

32

Client Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-73
SLIDE 73

Easy Solution: Ask Everything

32

Client Request: A,B,C,D,…,G Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-74
SLIDE 74

Easy Solution: Ask Everything

32

Client Request: A,B,C,D,…,G Response: Ek(Bluberry), Ek(Tomato), …, Ek(Cherry) Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-75
SLIDE 75

Easy Solution: Ask Everything

32

Client Request: A,B,C,D,…,G Response: Ek(Bluberry), Ek(Tomato), …, Ek(Cherry) Secure but too much overhead Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-76
SLIDE 76

Better Solution: Ask k tuples [S&P 98]

33

Client Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-77
SLIDE 77

Better Solution: Ask k tuples [S&P 98]

33

Client Request: A,C Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-78
SLIDE 78

Better Solution: Ask k tuples [S&P 98]

33

Client Request: A,C Response: Ek(Blueberry), Ek(Apple) Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-79
SLIDE 79

Better Solution: Ask k tuples [S&P 98]

33

Client Request: A,C Response: Ek(Blueberry), Ek(Apple) Provides k-1 ambiguity

  • So called k-anonymity [S&P 98]

Limited security guarantees

  • See l-diversity [ICDE 06], t-closeness [ICDE 07]

Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-80
SLIDE 80

Oblivious RAM (ORAM): Idea Sketch

34

Client Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-81
SLIDE 81

Oblivious RAM (ORAM): Idea Sketch

34

Client Request: A,C,D Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-82
SLIDE 82

Oblivious RAM (ORAM): Idea Sketch

34

Client Request: A,C,D Response: Ek(Blueberry), Ek(Apple) Ek(Banana) Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server

slide-83
SLIDE 83

Oblivious RAM (ORAM): Idea Sketch

34

Client Request: A,C,D Response: Ek(Blueberry), Ek(Apple) Ek(Banana) Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server Shuffle

slide-84
SLIDE 84

Oblivious RAM (ORAM): Idea Sketch

34

Client Request: A,C,D Response: Ek(Blueberry), Ek(Apple) Ek(Banana) Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server Shuffle Write-back: A: Ek(Apple), C: Ek(Banana) D: Ek(Blueberry)

slide-85
SLIDE 85

Oblivious RAM (ORAM): Idea Sketch

34

Client Request: A,C,D Response: Ek(Blueberry), Ek(Apple) Ek(Banana) Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server Shuffle Write-back: A: Ek(Apple), C: Ek(Banana) D: Ek(Blueberry) Ek(Apple)

slide-86
SLIDE 86

Oblivious RAM (ORAM): Idea Sketch

34

Client Request: A,C,D Response: Ek(Blueberry), Ek(Apple) Ek(Banana) Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server Shuffle Write-back: A: Ek(Apple), C: Ek(Banana) D: Ek(Blueberry) Ek(Apple) Ek(Banana)

slide-87
SLIDE 87

Oblivious RAM (ORAM): Idea Sketch

34

Client Request: A,C,D Response: Ek(Blueberry), Ek(Apple) Ek(Banana) Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server Shuffle Write-back: A: Ek(Apple), C: Ek(Banana) D: Ek(Blueberry) Ek(Blueberry) Ek(Apple) Ek(Banana)

slide-88
SLIDE 88

Oblivious RAM (ORAM): Idea Sketch

34

Client Request: A,C,D Response: Ek(Blueberry), Ek(Apple) Ek(Banana) Key Value A Ek(Blueberry) B Ek(Tomato) C Ek(Apple) D Ek(Banana) E Ek(Orange) F Ek(Mango) G Ek(Cherry) Server Shuffle Write-back: A: Ek(Apple), C: Ek(Banana) D: Ek(Blueberry) Ek(Blueberry) Ek(Apple) Ek(Banana) Key-Value mapping always changes

slide-89
SLIDE 89

Path ORAM [CCS 13]

35

ORAM Client ORAM Server

Position Map Stash

slide-90
SLIDE 90

Path ORAM [CCS 13]

35

ORAM Client ORAM Server

Position Map Stash

Tree-like data structures

  • Client: Position map, stash
  • Server: ORAM Tree with real/dummy nodes
slide-91
SLIDE 91

ORAM-based solutions for Memory Access

36

SGX CPU Cache MEE

slide-92
SLIDE 92

ORAM-based solutions for Memory Access

36

SGX CPU Cache MEE Bus snooping: Access patterns are still visible

slide-93
SLIDE 93

ORAM-based solutions for Memory Access

36

SGX CPU Cache MEE Bus snooping: Access patterns are still visible Monitor syscalls: Access patterns are still visible

slide-94
SLIDE 94

ORAM-based solutions for Memory Access

36

SGX CPU Cache MEE Bus snooping: Access patterns are still visible Monitor syscalls: Access patterns are still visible Cache side channels

slide-95
SLIDE 95

Mitigation: ORAM-based Memory Controller

37

SGX CPU Cache

ORAM Server ORAM Client

ObfusMem [ISCA 17], SDIMM [HPCA 18]

  • ORAM-based Memory Controller
slide-96
SLIDE 96

Mitigation: ORAM-based Memory Controller

37

SGX CPU Cache Patterns are secured using ORAM protocols

ORAM Server ORAM Client

ObfusMem [ISCA 17], SDIMM [HPCA 18]

  • ORAM-based Memory Controller
slide-97
SLIDE 97

Mitigation: ORAM-based Memory Controller

37

SGX CPU Cache Patterns are secured using ORAM protocols

ORAM Server ORAM Client

ObfusMem [ISCA 17], SDIMM [HPCA 18]

  • ORAM-based Memory Controller
slide-98
SLIDE 98

Mitigation: Place Trust in DRAM

38

SGX CPU Cache MEE Bus snooping InvisiMem [ISCA 17]

  • Place trust in DRAM
  • All address and data bus traffics are encrypted

 Note: SGX only encrypts values in data bus

  • Communication patterns are normalized
slide-99
SLIDE 99

Mitigation: Place Trust in DRAM

38

SGX CPU Cache MEE Bus snooping InvisiMem [ISCA 17]

  • Place trust in DRAM
  • All address and data bus traffics are encrypted

 Note: SGX only encrypts values in data bus

  • Communication patterns are normalized
slide-100
SLIDE 100

Mitigation: Place Trust in DRAM

38

SGX CPU Cache MEE Bus snooping InvisiMem [ISCA 17]

  • Place trust in DRAM
  • All address and data bus traffics are encrypted

 Note: SGX only encrypts values in data bus

  • Communication patterns are normalized
slide-101
SLIDE 101

Mitigation: Place Trust in DRAM

38

SGX CPU Cache MEE Bus snooping InvisiMem [ISCA 17]

  • Place trust in DRAM
  • All address and data bus traffics are encrypted

 Note: SGX only encrypts values in data bus

  • Communication patterns are normalized
slide-102
SLIDE 102

Mitigation: Place Trust in DRAM

38

SGX CPU Cache MEE Bus snooping InvisiMem [ISCA 17]

  • Place trust in DRAM
  • All address and data bus traffics are encrypted

 Note: SGX only encrypts values in data bus

  • Communication patterns are normalized
slide-103
SLIDE 103

Mitigation: ORAM-based File System

39

SGX CPU Cache Patterns are secured using ORAM protocols

ORAM Client ORAM Server

Obliviate [NDSS 18]

  • ORAM-based File System
slide-104
SLIDE 104

Mitigation: ORAM-based File System

39

SGX CPU Cache Patterns are secured using ORAM protocols

ORAM Client ORAM Server

Obliviate [NDSS 18]

  • ORAM-based File System
slide-105
SLIDE 105

Mitigation: ORAM-based File System

39

SGX CPU Cache Patterns are secured using ORAM protocols

ORAM Client ORAM Server

Obliviate [NDSS 18]

  • ORAM-based File System
slide-106
SLIDE 106

Obliviate [NDSS 18]: Memory charm against the OS

Program

Obliviate

Enclave Application

Disk

40

slide-107
SLIDE 107

Obliviate [NDSS 18]: Memory charm against the OS

Trusted Proxy

Program

1. FS Syscall interceptor Obliviate

Enclave Application

Disk

40

slide-108
SLIDE 108

Obliviate [NDSS 18]: Memory charm against the OS

Untrusted Proxy

Trusted Proxy

Program

1. FS Syscall interceptor

  • 2. Message

Queues Obliviate

Enclave Application

Disk

40

slide-109
SLIDE 109

Obliviate [NDSS 18]: Memory charm against the OS

Untrusted Proxy

Trusted Proxy

Program

1. FS Syscall interceptor

  • 2. Message

Queues

  • 3. Encrypted IPC

Untrusted Service

Obliviate

Enclave Application

Disk

40

slide-110
SLIDE 110

Obliviate [NDSS 18]: Memory charm against the OS

Untrusted Proxy

Trusted Proxy

Program

1. FS Syscall interceptor

  • 2. Message

Queues

Trusted Service

  • 3. Encrypted IPC

Untrusted Service

Obliviate

Enclave Application

Disk

  • 4. Trusted Service bridges

the gap between FS and ORAM

40

slide-111
SLIDE 111

Obliviate [NDSS 18]: Memory charm against the OS

Untrusted Proxy

Trusted Proxy

Program

1. FS Syscall interceptor

  • 2. Message

Queues

Trusted Service

  • 3. Encrypted IPC

Untrusted Service

ORAM client FS Metadata

  • 5. Data Oblivious

Metadata Handling Obliviate

Enclave Application

Disk

  • 4. Trusted Service bridges

the gap between FS and ORAM

40

slide-112
SLIDE 112

Obliviate [NDSS 18]: Memory charm against the OS

Untrusted Proxy

Trusted Proxy

Program

1. FS Syscall interceptor

  • 2. Message

Queues

Trusted Service

  • 3. Encrypted IPC

Untrusted Service

ORAM client FS Metadata

f4

T1 T2

f3 f2

ORAM Server

  • 5. Data Oblivious

Metadata Handling Obliviate

Enclave Application

Disk

  • 6. Encrypted ORAM Tree

(s) outside Enclave

  • 4. Trusted Service bridges

the gap between FS and ORAM

40

slide-113
SLIDE 113

Obliviate [NDSS 18]: Memory charm against the OS

Untrusted Proxy

Trusted Proxy

Program

1. FS Syscall interceptor

  • 2. Message

Queues

Trusted Service

  • 3. Encrypted IPC

Untrusted Service

ORAM client FS Metadata

f4

T1 T2

f3 f2

ORAM Server

  • 5. Data Oblivious

Metadata Handling Obliviate

Enclave Application

Disk

  • 6. Encrypted ORAM Tree

(s) outside Enclave

  • 4. Trusted Service bridges

the gap between FS and ORAM

40

(Init) load all files into ORAM Tree(s)

slide-114
SLIDE 114

Conclusion

  • Bug finding in file systems
  • Semantic, memory, concurrency, error code bugs
  • Semantic inconsistency inference
  • Fuzzing
  • Attacks and Defenses
  • Ransomware
  • Cold boot attacks
  • Side channels

41

slide-115
SLIDE 115

감사합니다.

이병영 서울대학교 전기정보공학부 byoungyoung@snu.ac.kr

42