strong security for distributed file systems group a3 ka hou wong jahanzeb faizan jonathan sippel
TRANSCRIPT
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