S iRiUS: Securing Remote Untrusted S torage NDS S 2003 Eu-Jin - - PowerPoint PPT Presentation

▶
s irius securing remote untrusted s torage
SMART_READER_LITE
LIVE PREVIEW

S iRiUS: Securing Remote Untrusted S torage NDS S 2003 Eu-Jin - - PowerPoint PPT Presentation

Aug 29, 2023 163 likes •743 views

S iRiUS: Securing Remote Untrusted S torage NDS S 2003 Eu-Jin Goh, Hovav S hacham, Nagendra Modadugu, and Dan Boneh S tanford University Introduction S ecure network file syst ems not widespread. Why? 1. Hard to deploy No

slide-1
SLIDE 1

S iRiUS: Securing Remote Untrusted S torage

NDS S 2003 Eu-Jin Goh, Hovav S hacham, Nagendra Modadugu, and Dan Boneh S tanford University

slide-2
SLIDE 2

Introduction

S ecure network file syst ems not

  • widespread. Why?
  • 1. Hard to deploy
  • No backwards compatibility
  • 2. File sharing not well supported
  • No file sharing ability, or
  • Fully trusted server handles file sharing
slide-3
SLIDE 3

Insecure Network File S ystems

Legacy network file systems

  • widely used: NFS

, CIFS , Yahoo!

  • insecure: NFS

v2

  • Weak authentication: UID/ GID
  • Fully trusted server
slide-4
SLIDE 4

S iRiUS Goals

1. No changes to remote file server

  • Implies crypto techniques

2. Easy for end users to deploy

  • Minimal client software, no kernel changes

3. File S haring with fine grained access control

  • Read-write separation

4. Minimize trust in file server

slide-5
SLIDE 5

Existing S ecure File S ystems

  • 1. CFS – Blaze
  • Single user: no file sharing
  • 2. SFS – Mazières et al.
  • File sharing but uses trusted server
  • 3. SUNDR – Mazières et al.
  • File sharing by untrusted server
  • Not easy to deploy: requires block servers
slide-6
SLIDE 6

“ Although NFS version 2 has been superseded in recent years by NFS version 3, system administrators are slow to upgrade … so NFS version 2 is not only widespread, it is still by far the most popular version of NFS .”

NFS v3 Designers 4½ years after NFS v3 introduced

slide-7
SLIDE 7

Design Limitations

Cannot defend against DOS attacks:

  • attacker breaking into file server can

delete all files

  • Solution:
  • 1. Keep good backups: S

iRiUS easy t o backup

  • 2. Replicate files using quorum systems
  • e.g. Reiter-Mahlki (1997)
slide-8
SLIDE 8

S iRiUS Usage Model

  • S

iRiUS is a file system layered over existing network file systems

  • Stop-gap measure until full upgrade of

legacy systems

slide-9
SLIDE 9

S ecurity Design

  • 1. Confidentiality and integrity
  • 2. Cryptographic file level read-write

access controls

  • 3. Simple key management
  • 4. S

imple access control revocation

  • 5. Freshness guarantees for access

control meta data

slide-10
SLIDE 10

Architecture

SiRiUS layered over NFS

Application NFS Client NFS Server NFS Client NFS Server User Kernel SiRiUS Client Client Machine File Server Network

slide-11
SLIDE 11

Architecture

SiRiUS layered over CIFS

Application CIFS Client NFS Server NFS Client CIFS Server User Kernel SiRiUS Client Client Machine File Server Network

slide-12
SLIDE 12

Architecture

SiRiUS layered over Yahoo!

Application Yahoo! Client NFS Server NFS Client Yahoo! Server User Kernel SiRiUS Client Client Machine File Server Network

slide-13
SLIDE 13

File Data S ecurity

  • Each file has unique:

1.File Encryption Key (FEK) 2.File Signing Key (FSK)

  • FEK, FSK control file read-write access
  • Users keep only 2 keys for all files:

1.Master Signing Key (MSK) 2.Master Encryption Key (MEK)

  • MSK, MEK control all file FEK and FSK access
slide-14
SLIDE 14

File S tructures

Files on remote server split in 2 parts

  • 1. md-file contains the file meta data. e.g.

access control information

  • 2. d-file contains the file data
slide-15
SLIDE 15

File S tructures

ENCFEK[File Data] SIGFSK [File Data Hash]

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) Time S tamp File name SIGMS

K

[Meta Data Hash]

  • Enc. Key

Block (User 1)

d-file md-file

slide-16
SLIDE 16

Encrypted Key Blocks

Username (KeyID) File Enc. Key (FEK) File Sig. Private Key (FSK) Encrypted with username’ s MEK public key Username (KeyID) File Enc. Key (FEK) Read-writ e Read only

slide-17
SLIDE 17

Meta Data File Creation

slide-18
SLIDE 18

Meta Data File Creation

File Enc. Key (FEK) File Sig. Private Key (FSK) 1) Generate file keys (FSK and FEK)

slide-19
SLIDE 19

Meta Data File Creation

Username (KeyID) File Enc. Key (FEK) File Sig. Private Key (FSK) Encrypted with

  • wner’ s

MEK public key 1) Generate file keys (FSK and FEK) 2) Create encrypted key block.

slide-20
SLIDE 20

Meta Data File Creation

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) Time S tamp File name 3) Append Pub FSK, time stamp, and file name to enc. key block

slide-21
SLIDE 21

Meta Data File Creation

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) Time S tamp File name SIGMS

K

[Meta Data Hash] 3) Append Pub FSK, time stamp, and file name to enc. key block 4) Hash and sign using owner’ s master signing key

slide-22
SLIDE 22

Meta Data File Creation

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) Time S tamp File name SIGMS

K

[Meta Data Hash] 3) Append Pub FSK, time stamp, and file name to enc. key block 4) Hash and sign using owner’ s master signing key 5) Update md-file freshness tree

slide-23
SLIDE 23

Why are freshness guarantees needed?

  • Can verify latest version of info is read
  • md-file freshness prevents rollback of

revoked privileges

slide-24
SLIDE 24

Rollback Revoked Privileges

  • 1. Bob revokes write access from Alice
  • 2. Alice replaces new md-file with saved

(older) copy

  • 3. Replacement restores write privileges
  • 4. Alice can undetectably write to d-file
slide-25
SLIDE 25

Freshness Overview

  • S

iRiUS client generates hash tree of all md-files owned by user

  • Hash tree root: hash of all the md-files
  • Every directory has mdf-file made of

the hash of:

  • 1. md-files in that directory
  • 2. mdf-files of sub directories
slide-26
SLIDE 26

Hash Tree Generation

/ a / a/ b foo bar con bin / dir file Key:

slide-27
SLIDE 27

Hash Tree Generation

/ a / a/ b foo bar con bin / dir file Key: root mdf Want to generat e root mdf

slide-28
SLIDE 28

Hash Tree Generation

/ a / a/ b foo bar con bin / dir file Key: root mdf mdf Before root mdf can be generated, we need / a/ mdf Want to generat e root mdf

slide-29
SLIDE 29

Hash Tree Generation

/ a / a/ b foo bar con bin / dir file Key: root mdf mdf Before root mdf can be generated, we need / a/ mdf which in turn needs / a/ b/ mdf mdf Want to generat e root mdf

slide-30
SLIDE 30

Hash Tree Generation

/ a / a/ b foo bar con bin / dir file Key: Hash bin and con to generate / a/ b/ mdf mdf

slide-31
SLIDE 31

Hash Tree Generation

/ a / a/ b foo bar con bin / dir file Key: mdf Hash / a/ b/ mdf and bar to generate / a/ mdf mdf / a/ b/ mdf

slide-32
SLIDE 32

Hash Tree Generation

/ a / a/ b foo bar con bin / dir file Key: root mdf mdf / a/ mdf mdf / a/ b/ mdf Hash / a/ mdf and foo to generate root mdf

slide-33
SLIDE 33

Root mdf-file

  • Contains a time stamp
  • Time stamp updated by client at

specified time intervals

  • S

igned by owner of the md-files

slide-34
SLIDE 34

Hash Tree Generation

  • 1. Generated only once
  • 2. Generated by owner of md-files
  • 3. Hash tree cacheable
  • 4. Updated only on md-file changes
slide-35
SLIDE 35

Verify md-file Freshness

/ a / a/ b foo bar con bin / dir file Key: root mdf mdf / a/ mdf mdf / a/ b/ mdf

slide-36
SLIDE 36

Verify md-file Freshness

/ a / a/ b foo bar con bin / dir file Key: root mdf mdf / a/ mdf mdf / a/ b/ mdf Verify bar md-file freshness

slide-37
SLIDE 37

Verify md-file Freshness

/ a / a/ b foo bar con bin / dir file Key: root mdf mdf 1) Hash / a/ b/ mdf and bar to regenerate / a/ mdf mdf / a/ b/ mdf Verify bar md-file freshness

slide-38
SLIDE 38

Verify md-file Freshness

/ a / a/ b foo bar con bin / dir file Key: root mdf 2) Compare regenerated / a/ mdf t o current version mdf / a/ b/ mdf Verify bar md-file freshness 1) Hash / a/ b/ mdf and bar to regenerate / a/ mdf mdf

slide-39
SLIDE 39

Verify md-file Freshness

/ a / a/ b foo bar con bin / dir file Key: root mdf mdf / a/ mdf mdf / a/ b/ mdf Verify bar md-file freshness 1) Hash / a/ mdf and foo to regenerate root mdf

slide-40
SLIDE 40

Verify md-file Freshness

/ a / a/ b foo bar con bin / dir file Key: root mdf mdf / a/ mdf mdf / a/ b/ mdf Verify bar md-file freshness 1) Hash / a/ mdf and foo to regenerate root mdf 2) Compare regenerated root mdf t o current version

slide-41
SLIDE 41

Verify md-file Freshness

/ a / a/ b foo bar con bin / dir file Key: root mdf mdf / a/ mdf mdf / a/ b/ mdf Verify bar md-file freshness 1) Hash / a/ mdf and foo to regenerate root mdf 2) Compare regenerated root mdf t o current version 3) Check timestamp verify owner’ s sig

slide-42
SLIDE 42

File S ystem Operations

  • 1. Create, read, write, rename, unlink,

share files

  • 2. S

ymbolic links but no hard links

  • 3. User access revocation
slide-43
SLIDE 43

User 1 Access Revocation

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) Time S tamp File name SIGMS

K

[Meta Data Hash]

  • Enc. Key

Block (User 1)

slide-44
SLIDE 44

Time S tamp

  • Enc. Key

Block (User 1)

User 1 Access Revocation

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) File name SIGMS

K

[Meta Data Hash] 1) Regenerate new file keys

slide-45
SLIDE 45

User 1 Access Revocation

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) Time S tamp File name SIGMS

K

[Meta Data Hash]

  • Enc. Key

Block (User 1) 1) Regenerate new file keys 2) Remove user 1 key block

slide-46
SLIDE 46

Time S tamp

User 1 Access Revocation

1) Regenerate new file keys 3) Update file sig. key and enc. key blocks 2) Remove user 1 key block

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) File name SIGMS

K

[Meta Data Hash]

slide-47
SLIDE 47

User 1 Access Revocation

1) Regenerate new file keys 3) Update file sig. key and enc. key blocks 4) Update time stamp 2) Remove user 1 key block

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) File name SIGMS

K

[Meta Data Hash] Time S tamp

slide-48
SLIDE 48

User 1 Access Revocation

1) Regenerate new file keys 3) Update file sig. key and enc. key blocks 4) Update time stamp 5) Update hash and sig 2) Remove user 1 key block

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) Time S tamp File name SIGMS

K

[Meta Data Hash]

slide-49
SLIDE 49

User 1 Access Revocation

1) Regenerate new file keys 3) Update file sig. key and enc. key blocks 4) Update time stamp 5) Update hash and sig 6) Update freshness hash tree 2) Remove user 1 key block

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) Time S tamp File name SIGMS

K

[Meta Data Hash]

slide-50
SLIDE 50

User 1 Access Revocation

1) Regenerate new file keys 3) Update file sig. key and enc. key blocks 4) Update time stamp 5) Update hash and sig 6) Update freshness hash tree 7) reencrypt file data 2) Remove user 1 key block

  • Enc. Key

Block (Owner) File Sig.

  • Pub. Key

(FSK) Time S tamp File name SIGMS

K

[Meta Data Hash]

slide-51
SLIDE 51

Architecture

SiRiUS layered over NFS using SFS toolkit

Application NFS Client NFS Server NFS Client NFS Server User Kernel SiRiUS Client Client Machine File Server Network

slide-52
SLIDE 52

Implementation Details

  • Multiplex incoming NFS

requests into multiple outgoing NFS requests

  • NFS

file handle cache

  • Changing file access controls
  • Random access
  • Essential for good performance in partial

file reads/ writes

slide-53
SLIDE 53

Random Access

Existing crypto file systems that support random access either

1. use block storage servers (S UNDR) 2. don’ t encrypt data on server (SFS )

Method:

1. View file as a series of blocks 2. Hash tree for file integrity

S imilar construction used for authenticating digital streams – Wong and Lam (1998).

slide-54
SLIDE 54

Performance

  • 1. Public key encryption - RS

A-1024

  • 2. S

ignatures - DS A-512

  • 3. Data file encryption - AES
  • 128
  • 4. Linux 2.4

NFS server - 1.13 GHz P3 NFS client - 866 MHz P3-M 100 Mbps link

slide-55
SLIDE 55

Performance

632.9 102.7 100.0 1 MB

  • Seq. Write

223.8 97.8 96.7 1 MB

  • Seq. Read

21.9 2.0 1.1 8 KB

  • Seq. Write

18.0 1.4 0.9 8 KB

  • Seq. Read

1.1 0.4 0.3 Delete File 14.5 3.4 0.4 Create File SiRiUS DumbFS Kernel NFS File Size Test

Times are in milliseconds.

slide-56
SLIDE 56

Other Extensions

  • Encrypted path names
  • Large scale group sharing using NNL

broadcast encryption

  • Maintaining traditional file system

semantics using union mounts

  • Union mounts also solve d-file rollback