Transcript SNARE

SNARE
December 2004
Security in Storage
Systems
References
1)
2)
3)
SNARE: A Strong Security Scheme for NetworkAttached Storage.
Y. Zhu and Y. Hu, IEEE Symposium on Reliable
Distributed Systems (SRDS), October 2003.
Separating key management from file system security.
D. Mazi`eres, M. Kaminsky, M. F. Kaashoek, and E.
Witchel. ACM Symposium on Operating Systems
Principles (SOSP), December 1999.
Network Security and Storage Security: Symmetries
and Symmetry-Breaking.
D. Beaver, IEEE Security in Storage Workshop, 2002.
SNARE
Slide 2
Agenda

Security in brief.

Storage Security.

SNARE – Overview.

SNARE – Protocols.

Performance issues.

Threat analysis.

Conclusion.
SNARE
Slide 3
Security Essentials





The weakest link in the chain defines the
strength of the security .
Always assume a “smart” adversary.
Strong cryptography is not necessarily
strong security.
Security scheme is based on a threat
analysis.
Cost effectiveness.
SNARE
Slide 4
Security Essentials (cont.)


Security essentials:
•
•
•
Confidentiality.
Integrity.
Availability.
Additionally:
•
•
•
•
•
Anonymity / Privacy.
Survivability.
Robustness / Reliability.
Completeness.
Authenticity.
SNARE
Slide 5
Typical Threats




Eavesdropping.
Man in the middle attacks:
• Tampering.
• Replay.
DoS – Denial of Service.
Internal / external adversary.
SNARE
Slide 6
Storage Security – The Players




“Sender” – writes or distributes the data.
“Receiver” – reads the data.
“Storage” – stores the data.
Authentication server (optional).
SNARE
Slide 7
Network security vs. Storage
Security
Network
Storage
Communication Nodes are separated by
space.
Nodes are separated by
time (+ space).
Key
management
Interaction is usually not
possible.
Certain cryptographic
algorithms require
interaction.
Encryption
algorithms
~ Similar.
Error correcting
codes
~ Similar.
SNARE
Slide 8
Storage Security Basics

Security at 2 layers:

Access Control - The desires of the
owner should be reflected even when
the owner is no longer present.
Storage may be considered as a Link or
as an endpoint.

• Storage layer.
• Communication layer.
SNARE
Slide 9
Access Control


The “sender” might be unavailable when
the message is delivered.
A proxy may represent the sender:
• Cryptographic mechanisms.
• Access control.
SNARE
Slide 10
Link vs. Endpoint

Re-encryption:
• Data may be decrypted by the storage node,
•
and then re-encrypted:
Pros
• Improves security from / to storage.
• Prevents cryptographic decay.
• Cons
• Subject to man in the middle attacks.

Examples: AFS, Microsoft EFS, Freenet.
SNARE
Slide 11
Link vs. Endpoint (cont.)

Disk Encryption:
•
•
•
•
•

An alternative approach to re-encryption is to send the
encrypted file directly across the network (end-to-end).
Data stored on disk is encrypted.
Sometimes encryption is up to the endpoint (PAST, Freenet).
Pros:
•
Performance.
Cons:
•
•
Eavesdropper can tell whether file has changed.
Replay (?).
CryptFS, Secure FileSystem, Microsoft Encrypting
File System, SNAD.
SNARE
Slide 12
NAS - introduction



NAS – Network Attached Storage.
The storage appliance is connected
directly to a TCP/IP network.
Limited processing capabilities.
SNARE
Slide 13
SNARE – Goals



Strong security for NAS.
Limited processing resources at the storage.
Security properties:
•
•
•
•
•
•
•
Confidentiality.
Integrity.
Authentication.
Access control.
Copy resistance.
File sharing.
End-to-end encryption – NAS cannot read data, does
not manage keys.
SNARE
Slide 14
SNARE – Scope



Provides infrastructure for enforcing
security.
Used by file system.
Does not provide access control policy.
SNARE
Slide 15
SNARE – Assumptions



The server is trusted.
NAS – less trusted.
Server and clients have reasonable
processing capabilities.
SNARE
Slide 16
SNARE – The Players




Client.
•
•
•
= Computer.
Runs a client daemon.
May run several users.
User (+user agent).
•
•
Has to be authenticated by server.
Produces file the encryption key.
Authorization server.
•
•
Authorizes users.
Manages and distributes keys.
NAS.
•
Stores the data.
SNARE
Slide 17
SNARE – Infrastructure
SNARE
Slide 18
Keys



Private + public key.
•
•
•
Per user.
Private – known only to user. Public – known to all.
Used for authentication.
Kd – disk key.
•
•
•
Per NAS.
Known to authorization server and NAS.
Used for authenticating user ID and permissions.
File-data key.
•
•
•
Per file.
Known only to user.
Used for end-to-end encryption of the files.
SNARE
Slide 19
Keys (cont.)


File-Lockbox key.
•
•
•
Capability:
•
•

Per permission profile.
Known to the server and to users with permissions.
Used for encrypting the file-data key.
KeyData.
•
•
•
Per user.
Generated by server - sent to user on first access.
A record representing the access control policy.
hku = MACKd(KeyData)
•
•
•
Per user.
Generated by server - sent with KeyData.
Used for authenticating KeyData.
Note: the capability and the file-lockbox key are sent at the
authentication protocol.
SNARE
Slide 20
Write Process
Klockbox
capability
Server
AuthReq
Kfile-data
Client
SNARE
NAS
Slide 21
Read Process
Klockbox
capability
Server
AuthReq
Kfile-data
Request
Client
SNARE
NAS
Slide 22
Revocation


Keys have a lifetime (specifically KeyData).
AV – Access control Version number:
•
•
Per file.
Signed by the server.

Blacklist at the NAS.

Changing Kd:
•
Keys of clients who have already been authenticated are
revoked.
SNARE
Slide 23
File Object



Each file is represented by a File Object.
Contains all relevant information about a file.
Created by NAS.
SNARE
Slide 24
File Object
SNARE
Slide 25
File Object (cont.)

HMAC – fhash(file object information, Kd).
objectID – unique identifier.
AV – Access control Version.
lockbox – file-data key encrypted by file-lockbox key.
Other fields: length, create time, modify time.

For each block:




•
•
checksum (SHA-1).
pointer – encrypted with key=fhash(object ID, Kd).
SNARE
Slide 26
SNARE - Security Properties
Revisited




Authentication:
•
•
•
Secure channel.
User sends request.
Server sends capability + lockbox key.
Confidentiality:
•
File is encrypted at the client by a file-data key and is stored
encrypted.
Integrity:
•
Checksums + HMAC hash.
Copy resistance (?).
•
Block pointers are encrypted.
SNARE
Slide 27
SNARE – Protocols

Authentication.
• Pros & cons.

Key Distribution.
• Pros & cons.

Communication with NAS.
• Pros & cons.

Basic Operations.
SNARE
Slide 28
Secure Authentication



Both authentication and key distribution are exchanged
via a secure channel.
Guarantees future communication in the session.
“SFS” – Secure File System (reference 2).
SNARE
Slide 29
Authentication
SNARE
Slide 30
Authentication (cont.)







User requests authentication.
Client replies user with SessionID+SeqNo.
User signs SessionID+SeqNo with private key, and sends to client.
Clients relays to server, adding a SeqNo.
Server relays to AuthAgent.
AuthAgent verifies signature, finds UserID and sends back to
server.
Server relays to client.
SNARE
Slide 31
Authentication – Pros & Cons

Pros:
• Secure authentication – protects against
•

eavesdropping.
NAS is not a player in authentication.
Cons:
• Server – security single point of failure.
SNARE
Slide 32
Key Distribution

Directly follows the authentication.
AuthReq
Client
SNARE
AuthReply
Server
Slide 33
Key Distribution (cont.)


Client sends request – AuthReq.
Server verifies request, and sends Capability:
•
•
•
Permissions.
Expiration time.
Signature.
SNARE
Slide 34
Key Distribution – Pros & Cons

Pros:

Cons:
• Secure channel.
• Revocation / expiration.
• Protocol completely trusts SFS.
SNARE
Slide 35
Communication with NAS

Any operation on the NAS is a two way handshake.
Two basic operations:
•
•

Block read.
Block write.
Cannot be performed before authentication and key
distribution are complete.
Request
Client
SNARE
Response
NAS
Slide 36
Request



Contains data and arguments.
Contains KeyData.
Signed by hku.
SNARE
Slide 37
Response



Contains data and arguments.
Contains a synchronization timer.
Signed by hku.
SNARE
Slide 38
Basic Operations – Block Write
SNARE
Slide 39
Basic Operations – Block Read
SNARE
Slide 40
Communication with NAS – Pros &
Cons

Pros:
• NAS has no access to file.
• All data sent / received is signed.
• Data itself is not signed on read requests: less calculations.

Cons:
• NAS spoofing: Replay of read response?
• Out of order blocks?
SNARE
Slide 41
Performance Issues

Implementation of the cryptographic protocols.
Performance has not been analyzed for multiple
clients.

The client performs more calculations than the NAS:


•
•
SHA-1 checksums over data blocks.
Data decryption.
Thus the bottleneck is shifted to the client.
SNARE
Slide 42
Overhead Measurements



Apples to apples?
So what’s new?
PK vs. HMAC - RSA does not justify overhead?
SNARE
Slide 43
Performance





Multiple clients?
FS / OS overhead?
Communication overhead?
Delays?
Sequential / random access?
SNARE
Slide 44
Threat Analysis - Authentication
Threat
Security
Property
Mechanisms
Client impersonation
Integrity
Secure
channel using SFS - Mutual authentication.
Key interception
Confidentiality
Authentication
and key distribution are encrypted
(SFS).
User impersonation
Integrity,
Confidentiality
Authentication
KeyData tampering
Integrity
KeyData
is signed (hku).
“Cryptographic
decay”
Confidentiality
ExpTime
– expiration time on key.
SNARE
request is PK signed.
The public key is matched to UserID.
Slide 45
Threat Analysis – Communication
with NAS
Threat
Security
Property
Mechanisms
Tamper with Requests / Responses
Integrity
All
Replay of requests
Integrity
Using
Replay of responses
Integrity
Not
Tamper with data blocks by man in the middle
Integrity
All
Tamper with data blocks by NAS
Integrity
Checksum
Out of order block reading
Integrity
Not
Man in the middle eavesdropping
Confidentiality
All
User impersonation at the client
Confidentiality /
integrity
SessionID
Copy file from one NAS to another
Integrity /
availability
Block
SNARE
requests / responses are signed using hku.
time stamps on all requests.
prevented.
Since the client uses Fs from the NAS to update its timer.
data blocks have a checksum + there is an HMAC over the
checksum.
is on plaintext – performed by client.
prevented.
A method of packet counter (+IV) is suggested.
data blocks are end-to-end encrypted at the client (key
known only to client).
is a unique hash – difficult to guess.
? – User / client share the same machine / memory.
pointers are encrypted by Kd.
Cracking the pointers without data key – difficult to guess.
? – Kd might also be available to adversary.
Slide 46
Threat Analysis – Communication
with NAS (cont.)
Threat
Security
Property
Mechanisms
User falsifies
permissions
Integrity
KeyData
NAS impersonation
Integrity
NAS
SNARE
is signed by hku.
uses Kd to sign responses (using hk u).
Replaying NAS Responses is possible.
Slide 47
Vague issues








User / Client relationship.
Client-user authentication: client can deceive users.
Copy resistance – if adversary has access to NAS, he might have Kd…
SeqNo in authentication protocol:
•
•
+ Not for security purposes – just for matching UserID with the right user.
- The server checks that the sequence number has not been used before.
Permissions: it is not clear how the server knows a user’s permissions.
Thus it is not clear if the lockbox keys are per user, per group…
The paper does not confront networks with multiple NAS’s:
•
In the authentication protocol the server uses a specific Kd – how is it chosen?
Response / request and Read / Write messages – not consistent.
Secure channel assures all authentications are fresh (?).
SNARE
Slide 48
Conclusion



SNARE: strong storage system security-wise.
A few minor vulnerabilities.
A bit vague
• Interface with file system.
• Performance.
• Scalability.
SNARE
Slide 49
Appendix
Secure Channel Using SFS


Both authentication and key distribution are exchanged
via a secure channel.
“SFS” – Secure File System (reference 2).
SNARE
Slide 51
Secure Channel Using SFS (cont.)





The client and server create a per-session pair of keys.
One for each direction.
These session keys are used to encrypt and guarantee the
integrity of the communication in the channel.
Kcs=SHA-1(“KCS”, KS, kS1, KC, kC1).
Ksc=SHA-1(“KCS”, KS, kS2, KC, kC2).
SNARE
Slide 52
Authentication - Details




SessionID – created by client.
•
•
•
A unique identifier for the session.
SessionID = SHA-1{“SessionInfo”,Kcs,Ksc}
Kcs,Ksc are per-session keys.
SeqNo – created by client.
•
•
A sequence number for the authentication requests.
Since a session might contain a few requests.
AuthMsg – created by user.
•
•
•
Signed authentication message.
AuthMsg=KU, {SignedAuthReq}K .
SignedAuthReq={“SignedAuthReq”,SessionID,SeqNo}.
-1
U
UserID – know to server.
•
Distributed to client.
SNARE
Slide 53
Key Distribution – Details


AuthReq= {“UserAuthReq”, UserID, ObjectID,
SessionID, SeqNo}.
Capability:
•
•

KeyData = {“KeyData”, UserID, ObjectID, Perms, nonce,
ExpTime, AV}
hku = MACKd(KeyData).
AuthReply = {“UserAuthReply”,KeyData, hku , SeqNo,
klockbox}.
SNARE
Slide 54
Request – Details


A client request to the NAS has the form:
M = {RequestArgs, RequestData, SeqNo, Fs,
KeyData, MAChku(M)}.
•
•
•
•
RequestArgs – operation type, etc.
RequestData – payload for writing (in write operations).
SeqNo – uniquely identifies the request.
Fs – timestamp.
SNARE
Slide 55
Response – Details


A NAS response to a client request is of the form:
M = {RequestArgs, RequestData, SeqNo, Fs,
MAChku(M)}.
•
•
•
•
RequestArgs – operation status, etc.
RequestData – requested block (in read operations).
SeqNo – uniquely identifies the request.
Fs – the NAS timer, used for time synchronization.
SNARE
Slide 56
RC5







SNARE uses the RC5 algorithm for data encryption.
Designed by Ronald Rivest, 1994.
Block cipher (data dependent).
Simple to implement.
Block size: 32 / 64 / 128 bits.
Key size: 0-2040 bits.
Encryption mechanism:
•
•
•
Integer addition.
Bitwise XOR.
Variable rotation.
SNARE
Slide 57
HMAC






Hashed Message Authentication Codes.
A message authentication function.
Designed for IPSEC.
RFC 2104.
Defines the protocol for calculating a hash from a
message.
Does not define the hash function (SHA-1, MD5…).
SNARE
Slide 58
SHA-1





Secured Hash Algorithm.
First created as a FIPS (Federal Information
Processing Standard).
Became RFC 3174.
A hash of the data is called a “message digest”.
Message digest size: 160 bits.
SNARE
Slide 59