[SOLVED] Cs6238 project 4- secure shared store (3s)

IMPORTANT NOTES:

This project is based on the topic of distributed systems security that is covered in Modules 11 and 12. The goal of the project is to gain hands-on experience in implementing secure distributed services. You will develop a simple Secure Shared Store (3S) service that allows for the storage and retrieval of documents created by multiple users who access the documents at their local machines. In the implementation, the system should consist of one or more 3S client nodes and a single server that stores the documents.

Users should be able to login to the 3S server through any client by providing their private key as discussed in Module 12. Session tokens would be generated upon successful authentication of the users. They can then check-in, checkout and delete documents as allowed by access control policies defined by the owner of the document.

To implement such a distributed system, we will need to make use of certificates to secure communication between clients and the server, and to authenticate sources of requests. You will need to make use of a Certificate Authority (CA) that generates certificates for users, client nodes and the server. All nodes trust the CA.

We have provided a Virtual Machine for the project. Links to download the image (.ova file) will be posted on Ed Discussion.

The default account on the VM is cs6238 and the password is cs6238. The root password is also cs6238. In an ideal setting, the 3S server and the client would be on separate nodes. For simplicity, we have set up only one VM. The server and client nodes are abstracted as separate folders within the VM. For example, the server folder represents the server and the client1 folder represents the client node.

The desktop contains a Project4 folder which has the skeletal implementation of the 3S service. You will be required to complete the implementation to satisfy all the functionalities which will be detailed below. The Project4 folder contains:

Fig: Folder structure of Project4

As discussed above, we will need to make use of a Certificate Authority that is trusted by all nodes. This CA would be used to generate certificates for the users, client nodes and the server. One can make use of a library such as OpenSSL for setting up the CA and to generate certificates.

For this project, we have created a CA. This CA has been used to generate certificates for the server. You would be required to generate certificates for the client nodes using this CA. The CA (certificate and key) was generated using the password (passphrase) cs6238.

Detailed instructions on generating certificates are present in Appendix A.

When the client keys and certificates are created, they should be placed in the clientX/certs folder and should be named as clientX.key and clientX.crt

After a 3S server starts, a client node can make requests to the server. Let’s assume that client nodes have a discovery service that allows them to find the hostname where 3S runs. The hostname, in this case, is secureshared-store. The certificate for the server contains secure-shared-store as the common name of the server. Whenever the client node makes a request, mutual authentication is performed, and a secure communication channel is established between the client node and the server. Here we make use of nginx to perform mutual authentication (MTLS). Every request from the client node should include the certificate of the client node for authentication.

As mentioned before, the 3S service should enable functions such as login, checkin, checkout, grant, delete, and logout. You will have to complete the skeleton code provided for the server and client to achieve these functionalities. Details are as follows:

When the Security Flag is set as Confidentiality (to be represented by “1”), the server generates a random AES key for the document, uses it for encryption and stores data in the encrypted form. To decrypt the data at a later time, this key is also encrypted using the server’s public key and stored with document meta-data. When the

Security Flag is set as Integrity (to be represented by “2”), the server stores the document along with a signed copy.

When a request is made for a document stored with Confidentiality as the SecurityFlag, the server locates the encrypted document and its key, decrypts the data and sends it back over the secure channel. Similarly, when a request is made for a document stored with Integrity as the SecurityFlag, the signature of the document must be verified before sending a copy to the client.

Additionally, when a request is made to checkin a document that is checked out in the current active session, the client must move (not copy) the document from the “/documents/checkout” folder into the

“/documents/checkin” folder. The client implementation must handle the transfer of these files between the folders automatically.  t

a Grant can only be issued by the owner of the document.    b This will change the defined access control policy to allow the target user (TUID) to have authorization for the specified action (R) for the specified document (DID).

c  AccessRight R can either be:

i  checkin (which must be represented by input 1)  ii checkout (which must be represented by input 2)   iii both (which must be represented by input 3)

for time duration T (in seconds). If the TargetUser is ALL (TUID=0), the authorization is granted to all the users in the system for this specific document. If there are multiple grants that have been authorized for a particular document and user, the latest grant would be the effective rule. Basically, the latest grant for the tuple (DID, TUID) should persist.

Here are a few clarification scenarios for Grant:

− If an initial grant for (file1, user1, 2, 100) is successful and then a successful grant request (file1, 0, 1, 50) is made, then file1 should be accessible for checkin only to all users for 50 seconds. User1 loses the checkout access given earlier.

− Grant (file1, 0, 3, 100) exists and then a successful grant request (file1, user2, 2, 50), then file1 is accessible to user2 for checkout for 50 seconds and invalidates the previous grant.

Since this is a security class, you should use secure coding practices. You are also expected to use static code analysis tools such as Pylint, Pyflakes, etc. and minimize the use of unsafe function calls (justify any such calls you need to make by providing inline comments). The report should list tools used to ensure that your code does not have any vulnerabilities. The report should also discuss the threat model and what threats are handled by your implementation.

Fig. Project Flow

−  How mutual authentication is achieved in the current implementation of 3S.

−  Details on the cryptographic libraries and functions used to handle secure file storage.

−  How the user information and metadata related to documents were stored.

−  Details of how the required functionalities were implemented

−  List any features that were not implemented or tested (partial points may be awarded).

−  List the assumptions made, if any.

as client.py     4. Requirements

Please ensure that you do not zip the files in your submission. Also, please stick to the specified naming conventions since an auto grader would be evaluating your submissions. 

IMPORTANT: Please ensure that you submit only these 4 files along with the video (See Video Requirements below) that are mentioned and follow the specified naming conventions. Any error in adhering to these guidelines would result in an error with the autograder and would result in a significant loss of points.

IMPORTANT: Do not hardcode the public or private key names (eg: user1.key or user1.pub) in your code. Make sure the usernames and keys are all in lowercase only.

Halfway through the project, if there are many common doubts, we will consolidate the clarification posts and share it as a note.

As mentioned earlier, this project will be graded by an auto grader so please follow the guidelines mentioned in this file. However, there is an alternative solution if the auto grader fails for your submission due to any reason. This video (a screen recording) will be required to be submitted as part of your submission and will be then graded for partial credit (only if the auto grader fails). This must be added as a media comment on your submission and can be of any common video format.  If you fail to submit the video, you’ll get a penalty of 10 points.

The following steps will be required to be shown as a part of your video:

The video should show the file locations and content. Try to show as many details about the functionality of the program as possible.

Certificate Generation:

The resource below describes how to set up a Certificate Authority (CA) and then how it’s certificate would be used to generate certificates for the nodes.

We have already set up a CA. You can find the CA certificates in the CA folder of Project4. We have also generated the server keys and certificate (certname is secure-shared-store) using the CA certificate. Also, the following command was used to extract the public key from the certificate.  openssl x509 -pubkey -noout -in secure-shared-store.crt > secure-shared-store.pub You can use the above resources to generate certificates and keys for the client nodes and users.