Securing Cloud

File Storage Using

20BIT0150
Problem
Statement
Security Risks in Cloud Environments
1. Privacy Concerns: Cloud service providers' access to stored data raises privacy concerns,
particularly for highly sensitive files.
2. Trust Issues: Inherent trust in CSPs can be a source of apprehension, especially with
confidential data.
3. Access Control Limitations: Traditional methods may prove insufficient. While
implementing access controls, one still has to trust CSPs to handle these critical aspects.
4. Data Integrity Concerns: Centralized access control mechanisms on the cloud introduce
opportunities for unauthorized alterations to files.
Literature Survey
Architecture
Components
Cloud (Google Firebase)
• Client-side encryption: encrypted files are uploaded to the cloud.

Blockchain (Ethereum/Kaleido)
• Acts as distributed database in our project.

• Smart Contracts are used to interact with our blockchain.

• Files, Users and Data Owners records are stored in the blockchain.
Types of Users
• There are two types of users in our project: Data Owners and Users.

• Data Owners act like an admin. Each department will have only one Data Owner.

• Users are further classified based on roles. Roles will vary from department to department.

• Data Owner Privileges: Approve and delete a user, upload and delete a file, generate keys and
clear keys.
• User Privileges: Get keys, view and verify the files.
File Handling (Upload)
• While uploading the file, the Data Owner should select the user role and provide the encryption
key for the selected user role.
• File metadata such as title, size, mime type, department, role, Merkle root (fingerprint of
the file) and file path (in the cloud) are calculated and stored in the blockchain.
• Files are then encrypted using AES-GCM algorithm and uploaded to the cloud storage.

• For security reasons, there is no smart contract function to update the file metadata. This will
ensure that the initial fingerprint of the file can never be modified.
File Handling (View)
• Data Owners have access to all the files in their department. They can provide relevant keys and
view the files.
• Users have access to only select files. Example: An HR Manager can view files that are meant
for HR Managers. This is done by comparing the User details and the access details provided in
the file metadata (department and role) in the blockchain.
• User should have correct access and correct keys to view and verify the file. (Two Factor
Authentication)
JSON Web Tokens (JWT)
• We are using Client-Server Architecture (frontend is developed with React.js and backend with
Node.js)
• Authentication and Authorization is handled using Json Web Tokens.

• Upon login, Data Owners and Users will receive a token. They should this token to interact with
our REST API after login.
• User Privileges mentioned in the previous slides can be implemented with the help of these
tokens.
Implementation
Smart Contract (Users)
Function Name Type Description
constructor Write Initializes the contract, setting up initial values
createUser Write Creates a new user and emits an event.
approveUser Write Approves a user by updating their status.
deleteUser Write Deletes a user and emits an event.
getUser Read Retrieves user information by ID.
getUserByEmail Read Retrieves user information by email.
getUsersByDepartment Read Retrieves an array of users in a specific department.

06/23/2024 17
API Endpoints (Users)
Endpoint Request Type Description
/secretkeys GET Returns the key file associated with the user. Requires Authentication.
/dept/:dept GET Returns an array of users associated with the specified department. Requires
Authentication.
/:id GET Return the user with the specified ID. Requires Authentication.
/login POST Validate user login. Return a token on successful login.
/signup POST Create a new user in the blockchain.
/approve/:id PATCH Approve a user, so that they can access the portal. This is performed by the Data
Owner belonging to the same department as the user.
/:id DELETE Delete a user. This is performed by the Data Owner belonging to the same department
as the user.

06/23/2024 18
Smart Contract (Data Owners)
Function Name Type Description
constructor Write Initializes the contract, setting up initial values
createDataOwner Write Creates a new data owner entry and emits an event.

getById Read Retrieves data owner information by ID.

06/23/2024 19
API Endpoints (Data Owners)
Endpoint Request Type Description
/secretkeys GET Generate secret keys used for encryption and decryption. The keys are temporarily
stored in the server for the users to access them. Requires Authentication.
/clearkeys POST Clears the keys stored in the server. Requires Authentication.
/:id GET Return the Data Owner with the specified ID. Requires Authentication.
/login POST Validate Data Owner login. Return a token on successful login.
/signup POST Create a new Data Owner in the blockchain.

06/23/2024 20
Smart Contract (Files)
Function Name Type Description
constructor Write Initializes the contract, setting up initial values
createFile Write Creates a new file entry and emits an event.
deleteFile Write Deletes a file entry and emits an event.
getFileById Read Retrieves file information by ID.
getFilesByDepartment Read Retrieves an array of files in a specific department.

06/23/2024 21
API Endpoints (Files)
Endpoint Request Type Description
/dept/:dept GET Returns an array of files associated with the specified department. Requires
Authentication.
/:id POST Return the file with the specified ID. Requires Authentication and key file
/integrity/:id POST Verifies the integrity of the file by fetching the file from cloud, decrypting
using the key and calculating the Merkle Root and comparing it with the
Merle Root stored in the blockchain.
/ POST Creates a new file record in blockchain and upload file to the cloud.
/:id DELETE Delete the file with the specified id. This is performed by the Data Owner
belonging to the same department as the file.

06/23/2024 22
Data Owner Portal
User Portal
Backend
Testing