# SDIS Project

SDIS Project for group T4G24.

## Clean-up

Clears the `src/build` folder and all the storage.
example: `./cleanup.sh`

## Compiling
To compile the project:
example: `./compile.sh`

## Running

#### Server
To start the server:
`./server.sh <port> <address>`
example: `./server.sh 5002 localhost`

#### Peer
`./peer.sh <peer_id> <peer_ap> <port> <central_server_address> <peer_pass>`
example: `./peer.sh 1 1 5002 localhost 12345`

#### Client
`./test.sh <peer_id> <sub_protocol> [<file_path>]`
example: `./test.sh 1 BACKUP test.txt`
example: `./test.sh 1 STATE`

### Testing

1) Open the folder scripts
2) Clean up the class files and storage: `./cleanup.sh`
3) Compile the project: `./compile.sh`
4) Start the server: `./server.sh 5002 localhost`
5) Open another terminal to start the peer: `./peer.sh 1 1 5002 localhost 12345`
6) Open another terminal to start another peer: `./peer.sh 2 1 5002 localhost 123``
7) Open yet another terminal to start the client using all subprotocols, starting with backup, following with state, then with restore and finally with delete to check them all: `./test.sh 1 BACKUP test.txt` -> `./test.sh 1 STATE` -> `./test.sh 1 RESTORE test.txt` -> `./test.sh 1 DELETE test.txt`

Group members:

1. Bruno Vale Fernandes - ([e-mail])
2. Diogo Gomes - ([e-mail])
3. Inês Marques - ([e-mail])
4. João Rocha - ([e-mail])

----------------

# Report - Proj 2 -T4G24

## Overview

We decided to go with a centralized server approach. The implemention uses JSSE, more specifically the SSLEngine with *AsynchronousSocketChannel* to secure the communication between the Clients and the Server as well as allowing for non-blocking operations.

Most of the code used to handle the protocols to handle the files (chunks) was taken from the first project.

It also features a simple authentication system to avoid clients accessing unauthorized files.

The files storage and the authentication systems both are serializable, allowing the server to "save" it's back-ups in the case of a crash.

## Protocols

As said above, the protocol is heavily based on the first project.

To Backup a file the Client must sends the chunks from a file to the Server and it will store on a folder (similar to the `putchunk` protocol in the first project).

To restore/retrieve a chunk a Client must ask for it to the Server (sending a message with the `getchunk` protocol). If the authentication goes correctly it should respond with a `chunk` message informing it was successful.

The code for each protocol can be found under the `Protocols/` folder.

We used TCP with JSSE (SSLEngine, TLS context) for communication between the server and the clients.

To avoid users accessing files from other users the server uses a basic authentication (userID + password). It stores the password using the same `sha256` hashing algorithm from the project 1. This authentication system is also *Serializable*.

The file chunks are *Serialized*, Allowing for the server to recover from crashes without losing data.

## Concurrency design
We used multithreading to maximize the likelihood of competition between processes and, as a result, to shorten the time required for peers to get the desired files. This strategy entails running multiple processes in parallel to reduce overall execution time.

## JSSE

The *JSSE* services are utilized in this project when sending messages between the Client and the Server. In order to provide a greater level of security in data transmissions the TCP connections are established througth the employment of the *SSLEngine*.

Almost all configurations regarding *SSLEngine* can be found inside the `SSLEngine/` folder. All the setup, wrapping/unwrapping, handshaking and read/write functions can be found there. The handshake phase begins after the SSLEngine has been formed and the connection has been properly established. There's also a *boolean/flag* called `debugmode` that, when `true`, allow to visualize the steps it takes to handshake, wrap, unwrap, send, etc. It needs to be manually changed in the code.

This is an example of the server's output when running with `debugmode` as true during a `BACKUP` protocol call:

Received -- PUTCHUNK 1
0ffcb4fb332f4831dab823dbd94936b27f00ac673f4103fbecd7ea1d6a521b51 12345 4
OK
WRITTEN 111 bytes
Sent -- STORED 1 0ffcb4fb332f4831dab823dbd94936b27f00ac673f4103fbecd7ea1d6a521b51 12345 4
System started handshake
NEED_UNWRAP
res: BUFFER_UNDERFLOW
res: OK
Handshaking / re-handshaking in process
NEED_TASK
Handshaking / re-handshaking in process
NEED_TASK
Handshaking / re-handshaking in process  
NEED_TASK
Handshaking / re-handshaking in process
NEED_TASK
Handshaking / re-handshaking in process
NEED_TASK
Handshaking / re-handshaking in process
NEED_TASK
Handshaking / re-handshaking in process
NEED_WRAP
OK
Handshaking / re-handshaking in process
NEED_UNWRAP
res: BUFFER_UNDERFLOW
res: OK
Handshaking / re-handshaking in process
NEED_TASK
Handshaking / re-handshaking in process
NEED_TASK
Handshaking / re-handshaking in process
NEED_TASK
res: OK
Handshaking / re-handshaking in process`

The passwords for the *keys* and the *truststore* are already present in the *scripts* used to test the project. They were generated beforehand using the guide in the Lab5. We did it that way because entering a wrong password would only cause the Server or Client to crash, showing the error that the password to the *keystore/truststore* is wrong.

The only password required is needed to access the files "inside" the server. It should be specified when initiating a Peer. They are near "hard-coded" in the `Authentication/Authentication.java` file.

We are using these 3 cypher-suites for the *SSLEngine* configuration: `TLS_ECDHE_RSA_WITH_NULL_SHA`,`TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256`,`TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384`. From our limited search these were 3 of the recommended cipher-suites from all the available.

## Fault-tolerance

Both the storage and the user authentication systems are serializable. This allows the server to recover from any crash without losing data. The servers also are stateless: they act only given the data received in the messages. We simply need to `load()` before and `save()` after each operation.

## Notes

In the last pratical class we told the professor we were trying to use *Chord* with *SSLSockets*. However assembling the *Chord* protocol proved too difficult and we changed to a centralized approach.

## Bibliography

https://stackoverflow.com/questions/18787419/ssl-socket-connection (SSLSockets / certicates example)

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/net/ssl/SSLEngine.html#:~:text=public%20abstract%20class%20SSLEngine%20extends,Integrity%20Protection. (SSLEngine documentation)

https://docs.oracle.com/en/java/javase/16/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-3D26386B-BC7A-41BB-AC70-80E6CD147D6F (generation keystores and truststore)

https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngineResult.HandshakeStatus.html (SSLEngine status)

https://docs.oracle.com/javase/10/security/sample-code-illustrating-use-sslengine.htm#JSSEC-GUID-EDE915F0-427B-48C7-918F-23C44384B862 (SSLEngine config and usage example by Oracle)

https://ciphersuite.info/cs/TLS_RSA_WITH_AES_256_CBC_SHA/ (documentation about Cipher_suits)

https://www.thesslstore.com/blog/cipher-suites-algorithms-security-settings/ (blog post explaining most TLS cyphers available)

Group members:

1. Bruno Vale Fernandes - ([e-mail])
2. Diogo Gomes - ([e-mail])
3. Inês Marques - ([e-mail])
4. João Rocha - ([e-mail])