CS6238程序代写、代做Python程序设计

日期：2024-04-16 09:26

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.