Strong Security for Distributed File Systems

Group A3Ka Hou Wong

Jahanzeb FaizanJonathan Sippel

Introduction

Presenter: Ka Hou Wong

Introduction Security is important because a

violation could cost billions of dollars As network-attached disks are getting

popular, we need to improve existing file systems to support security

This paper presents Secure Network-Attached Disks (SNAD)

Features Store and transfer all data

encrypted Decrypt data only in a client

workstation If the disk is physically stolen, the thief

cannot access the information Ability to detect forged data Little overhead because the disk

performs secure hashes only

Shortcomings of Existing File Systems Store information in clear text Rely upon trusted file servers not

to alter the original information Do not deal with issues such as

sharing files between users

Design Goals End-to-end encryption of all file system

data and metadata Only authorized people can access the data

Data integrity Ability to detect modified data

Flexibility Easy to share files

Performance and scalability No one wants to use a file system as slow as

a turtle

Basic Mechanisms Encrypt all data at client

Server has sufficient info to authenticate the writer

Reader has sufficient information to verify the end-to-end integrity of the data

Uses standard cryptographic tools Public-key cryptography

Extensive use of cryptographic hashes and keyed hashes such as Hashed Message Authentication Codes (HMAC)

SNAD Data Structures

Presenter: Jahanzeb Faizan

SNAD Data Structures Four basic structures

Data Objects File Objects Key Objects Certificate Objects

Storage Contiguous blocks of data, or Data (actual) in file system and remainder

in some special structures (I-nodes in UNIX)

Secure Data Object (SDO) Minimum unit of data that can be read

or written Corresponds to a file block

Block Security Info

Block ID

User IDs

Timestamp

Initialization Vector

Data

32 Bytes

Uniquely identifies each block (File ID and Block offset)

Creator of SDO and security

RC5 encrypted data

Prevent replay attacks

Prevent data blocks encrypted with the same key from encrypting to the same cipher text

File Object Composed of one or more data

objects along with per file metadata

Metadata consists of Block pointers File size Time stamping Pointer to a key object

Key Object Uses encryption key to encrypt

files Used for more than one file Corresponds to a UNIX group

Key Object (cont.)

Key File ID User ID Signature

User ID Encrypted Key

Permission

User ID Encrypted Key

Permission

User ID Encrypted Key

Permission

Unique Identifier for block on system

Private key of user or group

Last user to modify key object

RC5 key encrypted with user’s public key (cannot be decrypted without private key which is never sent to disk)

•On write, user hashes object and signs it with his private key

•On read, used to verify data integrity

To determine if user is allowed to write the key object

Certificate Object Each server contains a single

Certificate Object Contains administrative and

cryptographic information about each SNAD user

Used to authenticate users and do basic storage management

Certificate Object (cont.)

User ID Public Key

HMAC Key

Timestamp

User ID Public Key

HMAC Key

Timestamp

User ID Public Key

HMAC Key

Timestamp

User or group the tuple belongs to

Stored on disk for two reasons:

1. No need to consult key server

2. Writer authentication

To prevent replay attacksTo verify identity of user writing data (encrypted)

Overall OrganizationCertificate object

File object

Data object

Data object

Data object

Key object

File object

Data object

Key object

File object

Data object

Data object

File objects sharing a single key object (the two files have

the same access controls)

Overhead

Data

36-100 bytes,depending on scheme used

Header

Data Object

Dataobjects

andMetadata

Header Pointer to Key object

File Object

Data

72 bytes Header

Key Object

72 bytes * no. of users

Certificate object <100 bytes per user

SNAD Security Schemes

Presenter: Jonathan Sippel

SNAD Security Schemes Goal

To provide authenticated, encrypted storage Problem

Encryption/decryption times are not easily reduced

Solution Symmetric algorithms are relatively fast Different methods of authentication are

available which vary in security and speed

SNAD Security Schemes (cont.) Reading and writing of authenticated data

User is required to give a private key to the client

User opens the file and reads the key object Appropriate field of key object is decrypted to

obtain symmetric encryption key for the file Symmetric encryption key is used to encrypt

data before sending it to the server and after receiving it from the server

Scheme 1 Most secure Requires the user to sign the checksum

of every block written using public-key encryption

Requires the server to authenticate every block before writing it

Allows the system to track the writer for each block

Signature generation and checking are slow

Scheme 1 (cont.) Read

Server operations are not required Client verification of hash and signature

Write Client encrypts each data block Client computes a hash over entire data

object Client signs hash using the user’s private key Server compares recomputed hash against

signed hash

Scheme 1 (cont.)

Operation

Read Write

Client

NAS Client

NAS

En/Decrypt

X X

Hash X X X

Signature X

Verification

X X

Scheme 2 Signature check on server is replaced

with a Message Authentication Code (MAC) check

Client still generates a signature and checks it upon reading a block

Server is freed from time consuming verification

Overall performance is improved

Scheme 2 (cont.) Read

Server operations are not required Client verification of hash and signature

Write Client performs a cryptographic hash on the

block and signs it Client calculates a HMAC on the SDO using

the shared secret HMAC key Server computes HMAC using shared secret

key from the certificate object and compares it to the one received from the client

Scheme 2 (cont.)

Operation

Read Write

Client

NAS Client

NAS

En/Decrypt

X X

Hash X X X

Signature X

Verification

X

Scheme 3 Signatures are eliminated Cryptographic hashes are used to insure

data integrity Considerably faster because no

signature generation/checking is involved

Not possible to verify who wrote the block last

Scheme 3 (cont.) Read

Server calculates the HMAC using the key provided by the user requesting the data

Client verifies the hash and performs a checksum on the decrypted data

Write Client encrypts the SDO and calculates a

HMAC over the encrypted data Server authenticates the write by

computing the HMAC using the shared secret key from the certificate object

Scheme 3 (cont.)

Operation

Read Write

Client

NAS Client

NAS

En/Decrypt

X X

Hash X X X X

Signature

Verification

Performance Results

0

2

4

6

8

2 4 8 16 32

Block size (KB)

Read

ban

dw

idth

(M

B/s

)

Base Scheme 1 Scheme 2 Scheme 3

0

2

4

6

8

10

2 4 8 16 32

Block size (KB)W

rite

ban

dw

idth

(M

B/s

)

Base Scheme 1 Scheme 2 Scheme 3

Conclusions SNAD

Solves many performance and security problems found today

Provides user confidentiality and integrity

Performs better and is more reliable than centralized file servers

Improves performance and scalability with decentralized security functionality

Eliminates a single point of failure