Secure Distributed Document Sharing System Dukyun Nam, Seunghyun Han, CDS&N Lab. ICU

2 Contents 1. Introduction 2. Previous Works (Ddoc System) 3. Security Risks on Ddoc System 4. Related Works 5. System Design 6. Environments 7. Implementation 8. Issues 9. Conclusion 10. Demo 11. References

3 Introduction Peer-to-peer System ‘Peer-to-peer is a communications model in which each party has the same capabilities and either party can initiate a communication session’ On the Internet, P2P is a type of transient Internet network that allows a group of computer users with the same networking program to connect with each other and directly access files from one another's hard drives Document ‘A useful file containing information’ Word doc, mp3, mpeg, txt file

4 Previous Works Distributed Documents Sharing System P2P based document sharing Centralized Server just holds resource(documents) location information Searching facilities (peer to peer, web to peer) Support group based document sharing policies Access control by privilege of users Simple way to share their document with others. Scope and features Open sharing of documents. Two searching methods: client program, web browser. Support of dynamic group creation (optional)

5 Previous Works (continue) Ddocs System Architecture Ddocss Client Ddocss Server Web Browser 2. Search query 1.Register Docs 4.Query Results 2. Search query 4.Query Results 3.Process query 6.Request File transfer 7.Actual file transfer 5. Choose a link 6.Request file transfer 7.Actual file transfer 5. Choose a link

6 Security Risks (Problem Definition) Fundamental Requirement of Document Sharing on Ddocs System Document sharing among members who can trust each other Documents not allowed to be exposed to outside of the proper group or community Documents must not be modified to protect copyright Security Risks Risks exist on entire communications between server and Ddocss users The risks are not limited to Ddocs system, but most of peer-to-peer file sharing systems also hold the risks

7 Security Risks (continue) Security Risks Between Server and Peers Login Phase User ID and password may be eavesdropped Registration (Publishing) and Search Phase Resource (Document) location may be exposed to unauthorized users Moreover, unpublished documents also may be exposed if resource location information is revealed Between Peers File Transfer Phase File may be tampered during file transfer Replay attack is possible by unauthorized users File interception Etc.

8 Security Risks (continue) Possible Security flaws of Ddocs System Ddocss Client Ddocss Server Search query Register Docs Query Results Request File transfer Actual file transfer Login Eavesdropping of user ID and password Eavesdropping of resource locations Hacking or cracking document location database Replay Attacks, Eavesdropping or tampering documents

9 Related Works Napster Data, especially MP3, sharing tool among distributed users Simple admission control is done by server password-based admission control Data is not compressed or encrypted during transferring data Hardly consider security issues, such as eavesdropping, tampering, etc. Gnutella Large-scale, fully decentralized P2P system running on the Internet It is not concerned about anonymity or copyrights protection of documents but supports sharing documents among registered users Password-based admission control, but do not support privacy, authentication, and confidentiality

10 Related Works Publius Web-based publishing system that resists censorship and tampering Mainly focuses on protecting author's rights of documents rather than sharing free documents Use secret sharing scheme to protect author’s rights Data is distributed to several servers not to client or peer machines It degrades scalability of system As many as user publish their data, the number of servers must be increased to hold the published data

11 System Design Secure Ddocs System Is Aimed to Provide Integrity, Privacy, and Confidentiality Ddocss Client DB Ddocss Server Key Agreement Encrypted File transfer between peers Encrypted Login procedures Encrypted register and search result Key exchange and verify Ddocss with Security Features Decrypt and verify Actual Shared Documents Security Functionality Encrypt message between server and peers To protect exposure of documents To protect exposure of unwanted resources (documents which is disapproved to be published by user) location Key agreement between peers, and encrypt file after signing file with user’s private key To provide confidentiality, authentication, integration of file

12 Access Control Access Control of document sharing Basic concepts Access level per document Access level per user to access leveled document Ddocss user can give 5 access levels which are inclusive Ex) if user A gives level 2 to document D1 and level 4 to document D2, user B can access D2 but can not access D1 by access level restriction Originally, user(publisher) can also give access level to group of users. (optional) Not supported yet

13 Environments Implementation & Running Environments Server Operating System Solaris 7 Database MySQL v Web Server Apache v Language Java beta-3 build-84 mixed mode version It includes Crypto package by default

14 Implementation Implementation Considerations for Secure Communications Cryptographic Algorithms Compression File Transfer (between peers) Symmetric cryptograph for performance DES Control Messages (between server and peer) Asymmetric cryptograph for privacy RSA Digital Signature Signature for File DSA with SHA-1

15 Implementation (continue) User Login Procedure Risks or possible attacks User ID and password could be revealed to public Unauthorized users could access shared documents as much as the privileges which the original user has 2. Send Encrypted Login Request 3. Verify the user Peer Ddoc Server 5. Reply Public key of Server 1. Fill up user information 4. Change User Status in DB Security Functionality Encrypt login message by public key of server using RSA algorithm provided by Bouncy Castle ( RSA Algorithm Is Feasible Login message contain just address and password information Server public key is hard-coded Login acknowledge message contains public key of server because key may be changed

16 Implementation (continue) Documents Publication Risks or Possible Attacks Publish message which contains resource location information may be exposed to public by attackers Secret document location may be guessed by the exposed document location Ddoc Server 1. Encrypt resource information (host address, file path, keywords, title, author) with public key of server 2. Publish the encrypted resource information 3. Decrypt the received resource location with private key of server Peer 4. Insert it to DB 5. Reply acknowledgement Security Functionality Encrypt publish message by public key of server using RSA algorithm RSA Algorithm Is Feasible Message size of publish message is short

17 Implementation (continue) Documents Search Risks or Possible Attacks Search result message which contains resource location information may be exposed to public by attackers 2. Send search request 3. Search DB Peer Ddoc Server 5. Reply the encrypted search result 1. Fill up Search information 4. Encrypt the search result with public key of peer 6. Decrypt the received result with its private key 7. Show document titles Security Functionality Encrypt search result by public key of peer (search query requestor) RSA Algorithm Is Also Feasible Message size of search result is short

18 Implementation (continue) File Transfer SKIP (Simple Key Management for Internet Protocols) Diffie-Hellman Key Agreement Protocol between peers (document publisher and requestor) is used A secret value of Diffie-Hellman protocol is used for a session key between peers It is still vulnerable to a man-in-the-middle attack To Provide Confidential File Transfer between Peers, File is encrypted by DES algorithm (symmetric) The secret value (session key produced by Diffie-Hellman key agreement protocol) could be used as a DES session key to encrypt the requested file Asymmetric cryptograph is inappropriate because of their performance

19 Implementation (continue) File Transfer (continue) To Provide Authentication of Requested File, DSA with SHA-1 for digital signature is adopted After generating signature file, source file and signature file are compressed with Zip to make file compact

20 Implementation (continue) File Transfer Procedure Peer (requestor)Peer (File Holder) 2. Request File Transfer with nonce (x) 3. Generate nonce (y) 1. Generate Nonce x 4. Generate session key (g y ) x 5. Transfer nonce (y) 6. Generate session key (g x ) y Diffie-Hellman Key Agreement Protocol 7. Create signature with private key 8. Append the signature to the document 9. Compress the document and signature Using Zip 10. Encrypt the compressed file with session key 11. Transfer the encrypted file 12. Decrypt the received file with session key 13. Uncompress the decrypted file 14. Check the signature with public key of the file holder Compression Using Zip and Authentication Process Using DSA with SHA1 Algorithm

21 Conclusion Legacy P2P systems hardly provide confidentiality for sharing files especially between peers Napster, Gnutella, Publius, Soribada etc. Ddocss provides confidentiality for sharing files using encryption with symmetric key (DES) after key agreement (Diffie-Hellman) Legacy P2P systems is exposed to eavesdropping of resource location Freenet encrypts URL information to protect system from attackers Ddocss provides private communications between server and peer using asymmetric cryptograph (RSA) Ddocss provides Integrity of transferred file using digital signature with appendix (DSA with SHA-1)

22 Issues Risks of Server Database Hacking or cracking server database is a critical problem of current Ddocs system Main drawback of current Ddocs system design We assume that Ddocs Server is secure from any kind of attacks Performance We try to reduce size of messages which use RSA, for instance, Login, Search Result. They are less than 100 bytes. But still it is performance bottleneck

23 Demo User Registration Documents Publication Documents Search File Transfer Ddocss Peer ADdocss Peer B DB Ddocss Server “ns-final.doc” ( yyy.bbb) ( xxx.aaa) host: angel.icu.ac.kr 1. Publish “ns-final.doc” “Security” “Network Security” Keyword Title File path“ns-final.doc” 2. Search documents “Security”Keyword 3. Return result “Security” “Network Security” Keyword Title File path“ns-final.doc” 5. Request file 4. Decrypt received result File path“ns-final.doc” “ yyy.bbb ” “ns-final.doc” “ yyy.bbb ” 6. Prepare file sending “ns-final.doc” 7. Prepare file sending “ns-final.doc” Encrypted & compressed file Encrypted

24 References [1] NapSter Web Site: [2] Gnutella Web Site: [3] M. Waldman, A.D. Rubin, and L.F. Cranor, "Publius: A robust, tamper-evident, censorship-resistant web", Proceedings of the 9th USENIX Security Symposium, August [4] Freenet Web site: [5] I. Clarke, O. Sandberg, B. Wiley, and T.W. Hong, “Freenet: A Distributed Anonymous Information Storage and Retrieval System in Designing Privacy Enhancing Technologies”, International Workshop on Design Issues in Anonymity and Unobservability, LNCS 2009, July [6] Mojo nation Web Site: [7] R. Dingledine, M.J. Freedman, and D. Molnar, "Chapter 12: Free Haven", In Peer-To-Peer: harnessing the Power of Disruptive Technologies, Ed. Andy Oram. Cambridge: O'Reilly and Associates, 2001.

25 References (continue) [8] R. Dingledine, M.J. Freedman, and D. Molnar, “The Free Haven Project: Distributed Anonymous Storage Service”, International Workshop on Design Issues in Anonymity and Unobservability, LNCS 2009, July [9] D. Nam, M. Lee, J. Lee, and S. Han, “Distributed Document Sharing System”, Term Project Report, June 2001.