snare
Download
Skip this Video
Download Presentation
SNARE

Loading in 2 Seconds...

play fullscreen
1 / 59

SNARE - PowerPoint PPT Presentation


  • 131 Views
  • Uploaded on

SNARE. December 2004. Security in Storage Systems. References. SNARE: A Strong Security Scheme for Network-Attached Storage. Y. Zhu and Y. Hu, IEEE Symposium on Reliable Distributed Systems (SRDS), October 2003.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'SNARE' - marvel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
snare

SNARE

December 2004

Security in Storage Systems

references
References
  • SNARE: A Strong Security Scheme for Network-Attached 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.
agenda
Agenda
  • Security in brief.
  • Storage Security.
  • SNARE – Overview.
  • SNARE – Protocols.
  • Performance issues.
  • Threat analysis.
  • Conclusion.
security essentials
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.
security essentials cont
Security Essentials (cont.)
  • Security essentials:
    • Confidentiality.
    • Integrity.
    • Availability.
  • Additionally:
    • Anonymity / Privacy.
    • Survivability.
    • Robustness / Reliability.
    • Completeness.
    • Authenticity.
typical threats
Typical Threats
  • Eavesdropping.
  • Man in the middle attacks:
    • Tampering.
    • Replay.
  • DoS – Denial of Service.
  • Internal / external adversary.
storage security the players
Storage Security – The Players
  • “Sender” – writes or distributes the data.
  • “Receiver” – reads the data.
  • “Storage” – stores the data.
  • Authentication server (optional).
storage security basics
Storage Security Basics
  • Security at 2 layers:
    • Storage layer.
    • Communication layer.
  • 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.
access control
Access Control
  • The “sender” might be unavailable when the message is delivered.
  • A proxy may represent the sender:
    • Cryptographic mechanisms.
    • Access control.
link vs endpoint
Link vs. Endpoint
  • Re-encryption:
    • Data may be decrypted by the storage node, and then re-encrypted:
    • Pros
    • Cons
  • Examples: AFS, Microsoft EFS, Freenet.
  • Improves security from / to storage.
  • Prevents cryptographic decay.
  • Subject to man in the middle attacks.
link vs endpoint cont
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:
    • Cons:
  • CryptFS, Secure FileSystem, Microsoft Encrypting File System, SNAD.
  • Performance.
  • Eavesdropper can tell whether file has changed.
  • Replay (?).
nas introduction
NAS - introduction
  • NAS – Network Attached Storage.
  • The storage appliance is connected directly to a TCP/IP network.
  • Limited processing capabilities.
snare goals
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 scope
SNARE – Scope
  • Provides infrastructure for enforcing security.
  • Used by file system.
  • Does not provide access control policy.
snare assumptions
SNARE – Assumptions
  • The server is trusted.
  • NAS – less trusted.
  • Server and clients have reasonable processing capabilities.
snare the players
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.
slide19
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.
keys cont
Keys (cont.)
  • File-Lockbox key.
    • Per permission profile.
    • Known to the server and to users with permissions.
    • Used for encrypting the file-data key.
  • Capability:
    • 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.
write process
capability

Klockbox

Kfile-data

Write Process

Server

AuthReq

Client

NAS

read process
capability

Klockbox

Kfile-data

Read Process

Server

AuthReq

Request

Client

NAS

revocation
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.
file object
File Object
  • Each file is represented by a File Object.
  • Contains all relevant information about a file.
  • Created by NAS.
file object cont
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 security properties revisited
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 protocols
SNARE – Protocols
  • Authentication.
    • Pros & cons.
  • Key Distribution.
    • Pros & cons.
  • Communication with NAS.
    • Pros & cons.
  • Basic Operations.
secure authentication
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).
authentication cont
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.
authentication pros cons
Authentication – Pros & Cons
  • Pros:
  • Cons:
  • Secure authentication – protects against eavesdropping.
  • NAS is not a player in authentication.
  • Server – security single point of failure.
key distribution
Key Distribution
  • Directly follows the authentication.

AuthReq

AuthReply

Client

Server

key distribution cont
Key Distribution (cont.)
  • Client sends request – AuthReq.
  • Server verifies request, and sends Capability:
    • Permissions.
    • Expiration time.
    • Signature.
key distribution pros cons
Key Distribution – Pros & Cons
  • Pros:
  • Cons:
  • Secure channel.
  • Revocation / expiration.
  • Protocol completely trusts SFS.
communication with nas
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

Response

Client

NAS

request
Request
  • Contains data and arguments.
  • Contains KeyData.
  • Signed by hku.
response
Response
  • Contains data and arguments.
  • Contains a synchronization timer.
  • Signed by hku.
communication with nas pros cons
Communication with NAS – Pros & Cons
  • Pros:
  • Cons:
  • NAS has no access to file.
  • All data sent / received is signed.
  • Data itself is not signed on read requests: less calculations.
  • NAS spoofing: Replay of read response?
  • Out of order blocks?
performance issues
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.
overhead measurements
Overhead Measurements
  • Apples to apples?
  • So what’s new?
  • PK vs. HMAC - RSA does not justify overhead?
performance
Performance
  • Multiple clients?
  • FS / OS overhead?
  • Communication overhead?
  • Delays?
  • Sequential / random access?
vague issues
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 (?).
conclusion
Conclusion
  • SNARE: strong storage system security-wise.
  • A few minor vulnerabilities.
  • A bit vague
    • Interface with file system.
    • Performance.
    • Scalability.
secure channel using sfs
Secure Channel Using SFS
  • Both authentication and key distribution are exchanged via a secure channel.
  • “SFS” – Secure File System (reference 2).
secure channel using sfs cont
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).
authentication details
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}KU-1.
    • SignedAuthReq={“SignedAuthReq”,SessionID,SeqNo}.
  • UserID – know to server.
    • Distributed to client.
key distribution details
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}.
request details
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.
response details
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.
slide57
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.
slide58
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…).
sha 1
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.
ad