BurnBox Self-Revocable Encryption in a World of Compelled Access - - PowerPoint PPT Presentation

▶
burnbox
SMART_READER_LITE
LIVE PREVIEW

BurnBox Self-Revocable Encryption in a World of Compelled Access - - PowerPoint PPT Presentation

Jun 09, 2023 247 likes •788 views

BurnBox Self-Revocable Encryption in a World of Compelled Access Nirvan Tyagi Muhammad Haris Thomas Ristenpart Ian Miers Mughees Usenix Security 2018 1 Compelled Access Setting file 1 file 2 file 3 2 Compelled Access Setting file 1

slide-1
SLIDE 1

BurnBox

Nirvan Tyagi

Self-Revocable Encryption in a World of Compelled Access

Usenix Security 2018 Muhammad Haris Mughees Thomas Ristenpart Ian Miers

1

slide-2
SLIDE 2

Compelled Access Setting

file 1 file 2 file 3

2

slide-3
SLIDE 3

Compelled Access Setting

file 1 file 2 file 3

3

slide-4
SLIDE 4

Compelled Access Setting

file 1 file 2 file 3

e.g., border crossing, airport security, police checkpoints

4

slide-5
SLIDE 5

Compelled Access Setting

file 1 file 2 file 3

e.g., border crossing, airport security, police checkpoints e.g., journalists, dissidents, activists

5

slide-6
SLIDE 6

Compelled Access Setting

file 1 file 2 file 3

e.g., border crossing, airport security, police checkpoints e.g., journalists, dissidents, activists

6

> 50% increase

slide-7
SLIDE 7

Contributions

  • BurnBox: Cloud storage secure in compelled access setting

○ Allow users to honestly comply with authorities while preserving confidentiality ○ Secure deletion: permanently delete files ○ Temporary revocation: self-revoke access to files temporarily

  • Formal compelled access security notions and analysis
  • Proof-of-concept prototype

7

slide-8
SLIDE 8

Deniable/Steganographic file systems hide files by deceiving authority

file 1 file 2 file 3

8

Real Duress [CDNO96, ANS98, ADW97, Truecrypt]

slide-9
SLIDE 9

file 1 file 2 file 3

9

Deniable/Steganographic file systems hide files by deceiving authority

[CDNO96, ANS98, ADW97, Truecrypt]

slide-10
SLIDE 10

fake 1 fake 2 fake 3 file 1 file 2 file 3

10

Deniable/Steganographic file systems hide files by deceiving authority

[CDNO96, ANS98, ADW97, Truecrypt]

slide-11
SLIDE 11

file 1 file 2 file 3

Limitation: High usability burden where deception is inherent to security

  • Maintenance of “realistic-looking” fake content
  • Ability to convincingly lie about duress key

11

Deniable/Steganographic file systems hide files by deceiving authority

fake 1 fake 2 fake 3

[CDNO96, ANS98, ADW97, Truecrypt]

slide-12
SLIDE 12

file 1 file 2 file 3

12

Deniable/Steganographic file systems hide files by deceiving authority

fake 1 fake 2 fake 3

Limitation: High usability burden where deception is inherent to security

  • Maintenance of “realistic-looking” fake content
  • Ability to convincingly lie about duress key

Is this really your key?

[CDNO96, ANS98, ADW97, Truecrypt]

slide-13
SLIDE 13

file 1 file 2 file 3

13

Deniable/Steganographic file systems hide files by deceiving authority

fake 1 fake 2 fake 3

Limitation: High usability burden where deception is inherent to security

  • Maintenance of “realistic-looking” fake content
  • Ability to convincingly lie about duress key

Is this really your key?

[CDNO96, ANS98, ADW97, Truecrypt]

slide-14
SLIDE 14

A Different Approach

  • 1. Allow users to honestly comply at compelled access

checkpoints

14

slide-15
SLIDE 15

A Different Approach

  • 1. Allow users to honestly comply at compelled access

checkpoints

15

Strawman: burner device or full wipe of device

slide-16
SLIDE 16

A Different Approach

  • 1. Allow users to honestly comply at compelled access

checkpoints

16

Strawman: burner device or full wipe of device BurnBox: selective temporary self-revocation of sensitive files

slide-17
SLIDE 17

A Different Approach

  • 1. Allow users to honestly comply at compelled access

checkpoints

17

Strawman: burner device or full wipe of device BurnBox: selective temporary self-revocation of sensitive files

  • 2. Designed specifically for use with the cloud

BurnBox: secure against passive cloud adversaries

slide-18
SLIDE 18

Threat Model

Untrusted Cloud Storage

  • Write-only store
  • Passive attacker

18

file 1 file 2 file 3

slide-19
SLIDE 19

Threat Model

Untrusted Cloud Storage

  • Write-only store
  • Passive attacker

19

file 1 file 2 file 3

slide-20
SLIDE 20

Threat Model

Untrusted Cloud Storage

  • Write-only store
  • Passive attacker

20

file 1 file 2 file 3

slide-21
SLIDE 21

Threat Model

Untrusted Cloud Storage

  • Write-only store
  • Passive attacker

Compelling Agent

  • Access to local device
  • User passwords
  • Cloud history

21

file 1 file 2 file 3

slide-22
SLIDE 22

Threat Model

Untrusted Cloud Storage

  • Write-only store
  • Passive attacker

Compelling Agent

  • Access to local device
  • User passwords
  • Cloud history

Offline Restoration Cache

  • Inaccessible to

compelling agent

  • Inaccessible to user

during checkpoint

22

file 1 file 2 file 3

slide-23
SLIDE 23

BurnBox Overview

23

file 1 file 2 file 3

slide-24
SLIDE 24

Offline Restoration Cache Local Device

24

file 1 file 2 file 3

BurnBox Overview

slide-25
SLIDE 25

file 1 file 2 file 3

Untrusted Cloud Storage

f0c531 39731a 0dea2d

25

BurnBox Overview

slide-26
SLIDE 26

file 1 file 2 file 3

Before Compelled Access User selectively deletes and revokes sensitive files

f0c531 39731a 0dea2d

26

BurnBox Overview

slide-27
SLIDE 27

file 1 revoke delete

Before Compelled Access User selectively deletes and revokes sensitive files

f0c531 39731a 0dea2d

27

BurnBox Overview

slide-28
SLIDE 28

file 1

During Compelled Access Deleted files and revoked files are inaccessible and are cryptographically indistinguishable Before Compelled Access User selectively deletes and revokes sensitive files

file 1 revoke delete f0c531 39731a 0dea2d

28

BurnBox Overview

slide-29
SLIDE 29

file 1 revoke delete

After Compelled Access User restores access to revoked files with access to restoration key During Compelled Access Deleted files and revoked files are inaccessible and are cryptographically indistinguishable Before Compelled Access User selectively deletes and revokes sensitive files

f0c531 39731a 0dea2d

29

BurnBox Overview

slide-30
SLIDE 30

file 1 file 2

During Compelled Access Deleted files and revoked files are inaccessible and are cryptographically indistinguishable Before Compelled Access User selectively deletes and revokes sensitive files After Compelled Access User restores access to revoked files with access to restoration key

f0c531 39731a 0dea2d

30

BurnBox Overview

slide-31
SLIDE 31

cc64c3 5707dd 1be052

Conventional client-side encryption

f0c531 39731a 0dea2d

f1.txt f2.txt f3.txt

31

f0c531 39731a 0dea2d file 1 file 2 file 3

filename encryption key encrypted file

Device State

slide-32
SLIDE 32

cc64c3 5707dd 1be052

Compelled access reveals local keys

f0c531 39731a 0dea2d

f1.txt f2.txt f3.txt

32

f0c531 39731a 0dea2d file 1 file 2 file 3

filename encryption key encrypted file

Device State

slide-33
SLIDE 33

cc64c3 1be052

Delete rows of sensitive files

f0c531 39731a 0dea2d

f1.txt f3.txt

33

f0c531 0dea2d file 1 file 2 file 3

filename encryption key encrypted file

Device State

5707dd

f2.txt

39731a

slide-34
SLIDE 34

cc64c3 1be052

Delete rows of sensitive files

f0c531 39731a 0dea2d

f1.txt f3.txt

34

f0c531 0dea2d file 1 file 2 file 3

filename encryption key encrypted file

Device State

5707dd

f2.txt

39731a

Problem 1: How to support revocation? Problem 2: Secure deletion of persistent state is hard.

Forensic analysis

slide-35
SLIDE 35

cc64c3 1be052 f0c531 39731a 0dea2d

f1.txt f3.txt

35

f0c531 0dea2d file 1 file 2 file 3

filename encryption key encrypted file

Device State

5707dd

f2.txt

39731a

Revocation: use public-key encryption

restoration ciphertext

E(pk,cc64c3) E(pk,39731a) E(pk,1be052)

slide-36
SLIDE 36

cc64c3 1be052 f0c531 39731a 0dea2d

f1.txt f3.txt

36

f0c531 0dea2d file 1 file 2 file 3

filename encryption key encrypted file

Device State

5707dd

f2.txt

39731a

Revocation: use public-key encryption

restoration ciphertext

E(pk,39731a)

Revoke

E(pk,cc64c3) E(pk,1be052)

slide-37
SLIDE 37

cc64c3 1be052 f0c531 39731a 0dea2d

f1.txt f3.txt

37

f0c531 0dea2d file 1 file 2 file 3

filename encryption key encrypted file

Device State

5707dd

f2.txt

39731a

Revocation: use public-key encryption

restoration ciphertext Revoke Delete

E(pk,39731a) E(pk,cc64c3) E(pk,000000)

slide-38
SLIDE 38

cc64c3 1be052 f0c531 39731a 0dea2d

f1.txt f3.txt

38

f0c531 0dea2d file 1 file 2 file 3

filename encryption key encrypted file

Device State

5707dd

f2.txt

39731a

Revocation: use public-key encryption

restoration ciphertext Revoke Delete

Problem 1: How to support revocation? Problem 2: Secure deletion of persistent state is hard.

E(pk,39731a) E(pk,cc64c3) E(pk,000000)

slide-39
SLIDE 39

Erasable Index

cc64c3... f1.txt f2.txt 5707dd... f3.txt 1be052... f4.txt ca46b6...

  • File keys stored in append-only table

39

slide-40
SLIDE 40

Erasable Index

cc64c3... f1.txt f2.txt 5707dd... f3.txt 1be052... f4.txt ca46b6...

  • File keys stored in append-only table
  • Secure deletion of row keys with trusted hardware [RRBC13]

○ Trusted hardware assumed to manage small “effaceable” storage ○ E.g., TPM, iOS/Android keystore APIs

effaceable storage key tree

40

slide-41
SLIDE 41

Erasable Index

cc64c3... f1.txt f2.txt 5707dd... f3.txt 1be052... f4.txt ca46b6...

  • File keys stored in append-only table
  • Secure deletion of row keys with trusted hardware [RRBC13]

○ Trusted hardware assumed to manage small “effaceable” storage ○ E.g., TPM, iOS/Android keystore APIs

effaceable storage key tree

41

slide-42
SLIDE 42

Erasable Index

cc64c3... f1.txt f2.txt 5707dd... f3.txt 1be052... f4.txt ca46b6...

  • File keys stored in append-only table
  • Secure deletion of row keys with trusted hardware [RRBC13]

○ Trusted hardware assumed to manage small “effaceable” storage ○ E.g., TPM, iOS/Android keystore APIs

effaceable storage key tree

42

slide-43
SLIDE 43

Erasable Index

cc64c3... f1.txt f2.txt 5707dd... f3.txt 1be052... f4.txt ca46b6...

  • File keys stored in append-only table
  • Secure deletion of row keys with trusted hardware [RRBC13]

○ Trusted hardware assumed to manage small “effaceable” storage ○ E.g., TPM, iOS/Android keystore APIs

effaceable storage key tree

43

slide-44
SLIDE 44

Erasable Index

cc64c3... f1.txt f2.txt 5707dd... f3.txt 1be052... f4.txt ca46b6...

  • File keys stored in append-only table
  • Secure deletion of row keys with trusted hardware [RRBC13]

○ Trusted hardware assumed to manage small “effaceable” storage ○ E.g., TPM, iOS/Android keystore APIs

effaceable storage key tree

44

slide-45
SLIDE 45

Erasable Index

cc64c3... f1.txt f2.txt 5707dd... f3.txt 1be052... f4.txt ca46b6...

  • File keys stored in append-only table
  • Secure deletion of row keys with trusted hardware [RRBC13]

○ Trusted hardware assumed to manage small “effaceable” storage ○ E.g., TPM, iOS/Android keystore APIs

effaceable storage key tree

45

slide-46
SLIDE 46

Efficiency and other approaches?

Related asymptotically better approaches not secure against threat model

  • Puncturable pseudorandom functions [GMM86]
  • History-independent data structures [NT01]

46

Erasable index uses:

  • Storage on the order of number of files
  • Linear time search by filename

In practice, this is actually fine

slide-47
SLIDE 47

Security Analysis

47

  • Provide formal security models
  • Limit leakage to well-specified access pattern history

○ Pseudonymous operation history Adversary observing: Cloud communication history Encrypted cloud contents Erasable index on local device Pseudonymous operation history

E.g., Add file A at 1:00 Access file A at 4:30

Open question: Inference attacks on file accesses?

[CGPR15,NKW15]

slide-48
SLIDE 48

Prototype

  • Implemented as file system in userspace (FUSE)

○ Available at github.com/mhmughees/burnbox ○ About as efficient as standard client-side encryption

Untrusted App Container

OS Kernel Persistent Storage File System BurnBox (FUSE)

Trusted App

Userspace

(e.g. HDD, SSD) 48

slide-49
SLIDE 49

Prototype

  • Implemented as file system in userspace (FUSE)

○ Available at github.com/mhmughees/burnbox ○ About as efficient as standard client-side encryption

Untrusted App Container

OS Kernel Persistent Storage File System

Trusted App

Userspace

(e.g. HDD, SSD) 49

BurnBox (FUSE)

slide-50
SLIDE 50

Prototype

  • Implemented as file system in userspace (FUSE)

○ Available at github.com/mhmughees/burnbox ○ About as efficient as standard client-side encryption

Untrusted App Container

OS Kernel Persistent Storage File System BurnBox (FUSE)

Trusted App

Userspace

(e.g. HDD, SSD) 50

slide-51
SLIDE 51

Prototype

  • Implemented as file system in userspace (FUSE)

○ Available at github.com/mhmughees/burnbox ○ About as efficient as standard client-side encryption

51

Untrusted App Container

OS Kernel Persistent Storage File System BurnBox (FUSE)

Trusted App

Userspace

(e.g. HDD, SSD)

  • Best effort to address application and OS leakage

[CHKGKS08,DLJKSXSW12]

○

Memory-locked pages

○

Containers for untrusted applications ○ Guidelines for off-the-shelf OS configurations

slide-52
SLIDE 52

Contributions

  • BurnBox: Cloud storage secure in compelled access setting

○ Allow users to honestly comply with authorities while preserving confidentiality ○ Secure deletion: permanently delete files ○ Temporary revocation: self-revoke access to files temporarily

  • Formal compelled access security notions and analysis
  • Proof-of-concept prototype

○ github.com/mhmughees/burnbox

52