CS6238 Secure Computer Systems – Spring Project 4:
Secure Shared Store (3S)
IMPORTANT NOTE: We will not accept PyCrypto, Crypto, or Cryptodome libraries
in project four. Use the cryptography library (https://cryptography.io/en/latest/) for
this project. We will not give credit for any effort using the prohibited libraries.
Goals & Assumptions
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 the 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.
Project Setup
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:
1. CA - Represents the Certificate Authority and contains the CA certificates.
2. server - Represents the server. It contains server certificates and the 3S application code. The 3S server
is implemented using Python Flask and server.py contains the outline of the server code which is to be
fully completed.
3. client1 - Represents one of the client nodes. client.py has the skeletal implementation of the client. You
will be required to generate client certificates and place them in the client1/certs folder.
4. client2 - Represents another client node and the environment should be similar to client1.
Fig: Folder structure of Project4
Certificates
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
3S Implementation Details
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:
1. login(User UID, UserPrivateKey): This call allows a client node to generate necessary statements to
convince the 3S server that requests made by the client are for the user having UID as its user-id. The
client node will take UID and UserPrivate key as two separate inputs from the user. The filename of the
key is to be provided as input as opposed to the key value itself. A user’s private key should only be
used to sign the necessary statement, but never sent to the server. The statement should be of the form
“ClientX as UserY logs into the Server” where X represents the client-id and Y represents the userid.
On successful login, the server should return a unique session-token for the user. The session token will
have to be included in all the subsequent requests and would play the role of the statement in those
requests. Also, you must ensure that each user has a unique UID. You can assume that a given client
node only handles requests of a single user in one session (if a user logs in successfully from another
client, the previous session will be invalidated). Example of a public / private key creation with
OpenSSL: https://www.digicert.com/kb/ssl-support/openssl-quick-reference-guide.htm.
2. checkin(Document DID, SecurityFlag): A document with its id (DID = filename) is sent to the server
over the secure channel that was established when the session was initiated. If the document already
exists on the server, it may be overwritten along with its meta-data. If a new document is checked in,
the user at the client node becomes the owner of the document. The owner does not change if the
document is updated (using checkin) by an authorized user who is not the owner. The SecurityFlag
specifies how document data should be stored on the server. The documents that are to be checked
into the server must be present in the documents/checkin folder within the client directory [It is already
created within client1]. On the server, the documents that are checked in must be stored in the
documents folder within the server directory.
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.
3. checkout(Document DID): After a session is established, a user can use this function to request a
specific document based on the document identifier (DID) over the secure channel to the server.
• The request is granted only if the checkout request is made either by the owner of the document
or if performed by a user who is authorized to perform this action.
• If successful, a copy of the document is sent to the client node.
• The server would have maintained information about documents (e.g., meta-data) during
checkin that allows it to locate the requested document, decrypt it and send the document back
to the requestor.
• Once the document is checked out, it must be stored in the documents/checkout folder within
the Client directory.
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
4. grant(Document DID, TargetUser TUID, AccessRight R, time 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.
5. delete(Document DID): If the user currently logged in at the requesting client is the document owner,
the file is safely deleted. No one in the future should be able to access data contained in it even if the
server gets compromised. The deletion of a confidential document should result in permanent removal
of the key used to encrypt it.
6. logout(): Terminates the current session. If any documents received from the server were modified, their
new copies must be sent to the server before session termination completes. While checking back in
the modified documents, you must set Integrity as the SecurityFlag.
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
Project Deliverables
1. Report. It should cover the following aspects (Each answer need not be more than a few sentences):
● Architectural design details:
− 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.
● Implementation details:
− 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.
● Results of the static code analysis and the tools used.
● Threat Modelling and the threats currently handled by your implementation.
● Your report should be named as Report.pdf
2. Server code
● This will be the completed version of server.py that was provided.
● This must be named as server.py
3. Client node
● This will be the completed version of client.py that was provided.
● This must be named as client.py
4. Requirements
• This should include all additional python modules used in your implementation.
• Please add any additional python libraries in a file with the name: “requirements.txt” to
generate the file. This will be used by the auto grader to replicate your environment.
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.
Additional Instructions
● Please go through the comments in server.py and client.py and follow the provided instructions. Ensure
to complete the sections where TODOs are specified. You can add utility functions as required.
● All requests sent from the client must make use of the post_request() utility function and do not modify
this function. A sample response format is given in the login() function within the server code. Feel free
to make use of the same for the other server function.
● Expected response status codes for different scenarios are provided in the server.py for each function.
Ensure that the completed code behaves accordingly since the auto grader would use the status for
verification. (Status codes provided are custom status codes and not the standard ones. Using custom
status codes in HTTP is not best practice, however, this is being used for the purpose of the auto grader)
● Failure to follow the provided instructions would result in unnecessary point loss.
● Run the script start_server.sh present in the server directory to start the server. It essentially invokes
server.py to start the server.
● Make sure that the status of nginx is active by using the command – systemctl status nginx. If the
status is not active, you can restart it using the command – sudo systemctl restart nginx
● Ensure that your implementation can be run and tested by just invoking the start_server.sh and
client.py. Your code must also automatically initialize the required databases, if any and this is necessary
so that the autograder can successfully be run. Additionally, ensure that your code would create any
folders as necessary by your implementation since we would be using just the two python scripts for
evaluation.
● No specific test cases will be provided for this project, and you are free to develop a test harness that
consists of a sequence of calls made to the 3S server. However, we will soon be releasing a basic testing
script to give you an idea of how inputs are provided to the client.
● Make sure to test your 3S implementation using at least 2 clients and 3 users. The autograder would
be tested with users named ‘user1’, ‘user2’, ‘user3’ [these are the UIDs] and clients named
‘client1’, ‘client2’. Please make sure your implementation would be able to support these. The
auto grader would also expect userX.key and userX.pub as the private and public keys for those
users. So, ensure to test with these three users and create any metadata (in your application and
database) as required to support this mapping with the necessary files, keys or paths.
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.
● 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 (this is an important setup step.). These must be used
in client.py when the post_request() is invoked.
● While sending requests some of you might encounter SSL errors and to avoid this issue, please have a
look at the python package certifi for this. (You can use this link as a reference -
https://incognitjoe.github.io/adding-certs-to-requests.html)
● We encourage you all to discuss the project at a high-level on Ed Discussion. Please ensure that you
are not over-sharing and maintain academic honesty.
Halfway through the project, if there are many common doubts, we will consolidate the clarification
posts and share it as a note.
Grading Outline
Report - 30 points
● Architectural design details - 5 points
● Implementation details - 15 points
● Security Analysis of the implemented secure shared store - 5 points ● Threat Modelling - 5 points
Implementation of 3S - 70 points
Each function in the implementation will be scored as below:
1. Login - 10 points
● Handling the private key of the user and verifying the signature of the created statements
● Generation of a session token used for further requests.
2. Checkin - 15 points
● Secure file transfer of documents
● Handling the security flag - Integrity and Confidentiality
● Ownership/ Authorization check
3. Checkout - 15 points
● Secure file transfer of documents
● Handling the security flag - Integrity and Confidentiality
● Ownership/ Authorization check
4. Grant - 15 points
● Granting authorization to other users
● Handling expiry of granted access (in seconds)
5. Delete - 10 points.
● Ensuring deletion of files
● Ownership/ Authorization check
6. Logout - 5 points
● Checking in all the modified checked out files and session termination.
Video Requirements
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:
● Download your latest submission from Canvas.
● Walk through the 6 functions that are mentioned as a part of the Implementation requirements
● Follow these steps when recording the video:
1. Login as user1 with user1.key (Success)
2. Login as user2 with user2.key (Success)
3. Login as user3 with user1.key (Fail)
4. user1 checkin file1 with Security Flag (Success)
5. user2 checkin file2 with Integrity Flag (Success)
6. user1 checkout file1 (Success)
7. user2 checkout file2 (Success)
8. user1 checkout file2 (Fail)
9. user2 checkout file1 (Fail)
10. user1 grant checkout file1 to user2 (Success)
11. user2 checkout file 1 (within the granted time for step 10) (Success)
12. user3 checkout file 1 (within the granted time for step 10) (Fail)
13. Wait for the granted period in step 10 to expire and try 11 again. (Fail)
14. user1 delete file 1 (Success)
15. user1 delete file 2 (Fail)
16. user2 delete file 2 (Success)
17. Logout (Success)
The video should show the file locations and content. Try to show as many details about the
functionality of the program as possible.
● The entire duration of this video should not exceed 10 minutes, but we are flexible.
APPENDIX A
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.
● https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/
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.
请加QQ：99515681 邮箱：99515681@qq.com WX：codinghelp
