Скачать презентацию Security for Network-Attached Storage Vishal Kher 14 March Скачать презентацию Security for Network-Attached Storage Vishal Kher 14 March

94030bfcba4a942b94aa9f7571767c87.ppt

  • Количество слайдов: 27

Security for Network-Attached Storage Vishal Kher 14 March 2003 Security for Network-Attached Storage Vishal Kher 14 March 2003

How Things Were. . • • Fileserver protects critical information resources Requests go through How Things Were. . • • Fileserver protects critical information resources Requests go through the fileserver Every request is inspected Malicious requests never read the disk Malicious Clients Authentication Server Client Network File Server Clients Disks 2

How NASD Changed Things. . . • Performance bottleneck at the file server • How NASD Changed Things. . . • Performance bottleneck at the file server • File manager is not on the datapath Malicious Clients Authentication Server NASD Array Client Network Clients NASD File Manager 3

Security Issues • Authorization – How to authenticate the users – How to control Security Issues • Authorization – How to authenticate the users – How to control access on the device • How to secure data on link and on the device – End to end encryption • Revocation 4

Outline • Motivation • Authorization Schemes – Network-Attached Secure Disks (NASD) – Secure Authentication Outline • Motivation • Authorization Schemes – Network-Attached Secure Disks (NASD) – Secure Authentication for Remotely Encrypted Devices (SCARED) • Data Encryption Scheme – Secure Network-Attached Disks (SNAD) • Conclusion 5

General Picture • Key Types – Capability keys • Client receives KC = H(cap. General Picture • Key Types – Capability keys • Client receives KC = H(cap. Args, K) – Identity Keys • Client receives Ki = H(Client ID, K) Authentication Server Clients Key, Request Client Network Response Key Req uest Dev ice File Manager 6

Security in NASD • Developed at PDL, CMU • File manager makes the policy Security in NASD • Developed at PDL, CMU • File manager makes the policy decisions • Passes access rights to the drive through cryptographic capabilities • Device doesn’t need to know the identity of the client • User proves his identity and access rights using capability key and capability arguments – These are passed by the File manager to the client • Scheme for revocation 7

Protocol Details Private Communication Request For Access FM Client Cap. Key = MACK(Cap. Args, Protocol Details Private Communication Request For Access FM Client Cap. Key = MACK(Cap. Args, AV) Cap. Args= Obj. ID, Version, Rights, Expiry, . . N) N) N, e. II e nc e. II nc nc nc No No y, , , py y, , pll N, N p y Re pll Re e. II ce nc N)) Re ( e ey on N p pk No e N ce. II ca ca q, , onc AC AC eq on M M Re N , , R , , N gs M gs y((M Ar Ar key ap cap =C C =C AC M MA M M Device Secret Key K (working key) Access Control Version (AV) Stored on the device and FM, Used for revocation Secret Key K (working key) 10

NASD Conclusion • Capability is acquired per open request – – Still overhead on NASD Conclusion • Capability is acquired per open request – – Still overhead on the file manager File manager needs to be online File manager (FM) is a central point of failure Potential for Do. S • Object migration, replication or striping – Multiple capabilities are required • Very fast revocation • URL : http: //www. pdl. cmu. edu/NASD/ 11

SCARED • Extension of NASD • Developed at IBM Almaden • Allows clients to SCARED • Extension of NASD • Developed at IBM Almaden • Allows clients to share keys – – Bob receives K 1 = H(data 1, K) Bob gives Alice K 2 = H(data 1 + data 2, K 1) K is the key shared between the storage and FM Public part (data 1) depends on the type of the key used • FM does not need to be online 12

Protocol Details • Setting – Client has two keys Ka, Kr, and corresponding Da, Protocol Details • Setting – Client has two keys Ka, Kr, and corresponding Da, Dr – Ka is the access key and Kr is the response key • Step 1: Freshness Guarantee – – – C S: M = {Frequest, Fc, Dr}, MACKr(M) S C: M = {Fresponse, Fc, Fs}, MACKr(M) Fs is the initial session counter • Counter based or Timer based 13

Protocol Details • Request C S: – M = {Oper, data, Dr, Fc, Fs}, Protocol Details • Request C S: – M = {Oper, data, Dr, Fc, Fs}, MACKa+Kr(M) • Response S C: – M = {Response, Fc, Fs}, MACKr(M) • Capability Keys – FM has ACL – Device verifies that the client has the ability to perform a transaction • Identity Keys – ACL with object on the Device – Device has to verify the identity 14

SCARED VS NASD SCARED Keys could be long lived NASD Keys per open request SCARED VS NASD SCARED Keys could be long lived NASD Keys per open request Revocation difficult Fast revocation Mutual authentication Negative FM does not need to be online FM has to be online Freshness timestamp based or counter based Time stamp based 15

SNAD Design Goals • Encrypt data on the disk – Drives lack information to SNAD Design Goals • Encrypt data on the disk – Drives lack information to decrypt data • End to end encryption – – – Restrict access to authorized users Super user should not be able to access the data Reduces load on the disk CPU • Data integrity • Avoid other attacks – Replay attack based on time stamp (time drifting? ) 16

SNAD Data Structures Key object File object Secure block Certificate object Secure block 17 SNAD Data Structures Key object File object Secure block Certificate object Secure block 17

SNAD Data Structures • Secure Blocks – Basic unit of data read or written SNAD Data Structures • Secure Blocks – Basic unit of data read or written • • • Block ID - Unique id for the block User ID - Creator of the secure block Timestamp - Used to prevent reply attack Data encrypted using the RC 5 key Key stored in Key object Block Security Information Block_ID USER_ID Timestamp Encrypted Data 18

SNAD Data Structures • File Objects – Contains normal metadata • Example: Block pointers, SNAD Data Structures • File Objects – Contains normal metadata • Example: Block pointers, file size – – – In addition contains a pointer to key object One or more secure blocks No encryption… Do we need to? • • • At least whole directory structure will be known to insider A directory and/or file name itself can mean something MS bookmark information 19

SNAD Data Structures • Key Object – Reference count to know when to delete SNAD Data Structures • Key Object – Reference count to know when to delete the key object – Signature – • User hashes the entire object and signs with his private key – Rows store information per user or group • Created by the user upon creation of a file or a file group • K is RC 5 key encrypted with users public key Key file ID User ID Signature Ref Count User ID EPKi(K) Permissions ……. Group ID EPKi(K) Permissions 20

SNAD Data Structures • Certificate Object – One per disk – Public Key Stored SNAD Data Structures • Certificate Object – One per disk – Public Key Stored for • Convenience • Scheme 1 – HMAC key • Used in Scheme 2 and Scheme 3 • Stored encrypted with decryption key held in non-volatile memory on disk! • HMAC keys decrypted during disk startup • Timestamp is updated for each write User ID Public Key HMAC Key Timestamp 21

SNAD Scheme 1 Client Write Disk CPU/ Client read EK(M) H Compare V N SNAD Scheme 1 Client Write Disk CPU/ Client read EK(M) H Compare V N H S Y Reject 22

SNAD Scheme 1 • Expensive operations on client and disk side • Vulnerable to SNAD Scheme 1 • Expensive operations on client and disk side • Vulnerable to DOS attacks Operations Read Write Client NAS En/Decrypt X X Hash X X X Sign Verify 23

SNAD Scheme 2 Client Disk CPU HMACK’ EK(M) H H Disk CPU: Compare H SNAD Scheme 2 Client Disk CPU HMACK’ EK(M) H H Disk CPU: Compare H S H HMACK’ Write 24

SNAD Scheme 2 Disk CPU Client EK(M) H Compare V N Y Reject Read SNAD Scheme 2 Disk CPU Client EK(M) H Compare V N Y Reject Read 25

SNAD Scheme 2 • Expensive operations on client specially on a write • Vulnerable SNAD Scheme 2 • Expensive operations on client specially on a write • Vulnerable to DOS attacks Operations Read Write Client NAS En/Decrypt X X Hash X X X Sign Verify 26

SNAD Scheme 3 Client Disk CPU HMACK’ EK(M) H Compare H HMACK’ Write 27 SNAD Scheme 3 Client Disk CPU HMACK’ EK(M) H Compare H HMACK’ Write 27

SNAD Scheme 3 Disk CPU Client HMACK’ EK(M) H Compare H HMACK’ Read 28 SNAD Scheme 3 Disk CPU Client HMACK’ EK(M) H Compare H HMACK’ Read 28

Conclusion • Authorization – NASD – SCARED – Improvements • • Revocation Reduce number Conclusion • Authorization – NASD – SCARED – Improvements • • Revocation Reduce number of keys Reduce frequency of access to the FM Support compound objects and object mobility • Encryption – SNAD – Improvements? • Revocation • Group key management 29