Snare
Download
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.



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?


Threat analysis authentication
Threat Analysis - Authentication


Threat analysis communication with nas
Threat Analysis – Communication with NAS


Threat analysis communication with nas cont
Threat Analysis – Communication with NAS (cont.)


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.


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.


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