[PD1] - Missing FakeCA and examples

Projs/PD1/README.md

@@ -84,7 +84,7 @@ Tendo em consideração as vulnerabilidades e ameaças identificadas na análise
 
 1. **End-to-End Encryption (E2EE)**
 
-   - Ao enviar uma mensagem, o cliente assina a 'hash' do texto simples com a sua chave privada.
+   - Ao enviar uma mensagem, o cliente assina a *hash* do texto simples com a sua chave privada.
    - A assinatura é anexada ao texto limpo e esse conjunto é cifrado com uma chave de sessão gerada aleatoriamente.
    - A chave de sessão é cifrada com a chave pública do destinatário, Isso garante que apenas o destinatário possa decifrar a mensagem.
 
@@ -100,8 +100,8 @@ Tendo em consideração as vulnerabilidades e ameaças identificadas na análise
 
 1. **Verificação de Inputs**
 
-   - Tanto cliente quanto servidor realizam verificações básicas nos ‘inputs’ para garantir a sua integridade.
-   - Ambos desconfiam um do outro e verificam cuidadosamente todos os ‘inputs’.
+   - Tanto cliente quanto servidor realizam verificações básicas nos *inputs* para garantir a sua integridade.
+   - Ambos desconfiam um do outro e verificam cuidadosamente todos os *inputs*.
 
 1. **Confiança na CA Central**
 
@@ -110,22 +110,75 @@ Tendo em consideração as vulnerabilidades e ameaças identificadas na análise
 
 ## Certificates and Keys
 
-Falar da criacao de certificados e chaves para o servidor e clientes e se calhar das fake ou entao no fim para falar da validacao e seguranca contra ataques
+Para gerar os certificados e chaves necessárias para a comunicação segura entre o cliente e o servidor, foram seguidos os seguintes passos utilizando a ferramenta **OpenSSL**. Estes passos incluem a geração de chaves privadas, certificados e *keystores* para o servidor e clientes, bem como a assinatura dos certificados pela CA central.
 
-## Arquitetura do Sistema
 
-Neste projeto, a arquitetura do sistema é composta por 2 componentes principais:
+1. **Gerar *CA key* e o *certificate***
 
-- **Cliente**: é a aplicação que cada utilizador executa para interagir com o servidor. O cliente é responsável por enviar mensagens para o servidor e receber mensagens de outros utilizadores (pelo servidor).
-- **Servidor**: é a aplicação que recebe os pedidos dos clientes, processa-os e responde de acordo. O servidor é responsável por armazenar as mensagens dos utilizadores e garantir a autenticidade das mensagens.
+```bash
+openssl genrsa -aes256 -out CA/CA.key 4096
+openssl req -x509 -new -nodes -key CA/CA.key -sha256 -days 18250 -out CA/CA.pem -subj "/2.5.4.3=CA"
+```
+A *passhphrase* da CA é 1234
 
-### Crypto
+2. **Gerar a *server key* e *CSR***
+
+```bash
+openssl genrsa -out server/server.key 4096
+openssl req -new -key server/server.key -out server/server.csr -subj "/2.5.4.11=MSG SERVICE/2.5.4.65=SERVER"
+```
+
+3. **Assinar o *CSR* do *server* com a *CA***
+
+```bash
+openssl x509 -req -in server/server.csr -CA CA/CA.pem -CAkey CA/CA.key -CAcreateserial -out server/server.crt -days 1825 -sha256
+```
+
+4. **Gerar o *keystore* do *server***
+
+```bash
+openssl pkcs12 -export -out server/server.p12 -inkey server/server.key -in server/server.crt -certfile CA/CA.pem -name "ServerKeyStore"
+```
+A passphrase usada para o *keystore* é server
+
+5. **Gerar as chaves e *CSR* de cada *client***
+
+```bash
+openssl genrsa -out client{NUM}/client{NUM}.key 4096
+openssl req -new -key client{NUM}/client{NUM}.key -out client{NUM}/client{NUM}.csr -subj "/2.5.4.11=MSG SERVICE/2.5.4.65=CL{NUM}/2.5.4.3=Client {NUM}"
+```
+
+6. **Assinar os *CSR* dos clientes com a *CA***
+
+```bash
+openssl x509 -req -in client/client.csr -CA CA/CA.pem -CAkey CA/CA.key -CAcreateserial -out client/client.crt -days 1825 -sha256
+```
+7. **Gerar o *keystore* do *client***
+
+```bash
+openssl pkcs12 -export -out client{NUM}/client{NUM}.p12 -inkey client{NUM}/client{NUM}.key -in client{NUM}/client{NUM}.crt -certfile CA/CA.pem -name "Client{NUM}KeyStore"
+```
+A passphrase usada para o *keystore* é client{NUM}
+
+Neste processo, foram geradas as chaves privadas, certificados e *keystores* necessários para estabelecer uma comunicação segura entre os clientes e o servidor. Os certificados foram assinados pela Autoridade de Certificação (CA) central, garantindo a autenticidade e integridade dos certificados emitidos. Os *keystores* contêm tanto o certificado quanto a chave privada do cliente ou servidor, protegidos por *passhprase* para garantir a confidencialidade e segurança das chaves privadas. Este processo de geração de certificados e *keystores* é essencial para estabelecer uma comunicação segura e autenticada entre os componentes do sistema.
+
+### Certificados
+- **Autenticidade**: Os certificados são assinados digitalmente pela Autoridade de Certificação (CA) central, garantindo sua autenticidade. Isso significa que os clientes podem verificar se o certificado foi emitido por uma entidade confiável.
+- **Criptografia**: Os certificados contêm a chave pública do cliente ou do servidor, que é usada para estabelecer uma comunicação segura por meio de criptografia assimétrica. Isso permite que as mensagens sejam cifradas pelo remetente e decifradas apenas pelo destinatário.
+- **Verificação**: Antes de confiar num certificado, os clientes verificam sua validade, incluindo a data de expiração e a correspondência com a entidade emissora. Isso ajuda a evitar a utilização de certificados inválidos ou falsificados.
+
+### *Keystores*
+- **Armazenamento Seguro**: Os *keystores* são arquivos protegidos por *passphrase* que contêm tanto o certificado quanto a chave privada do cliente ou servidor. Essas informações sensíveis são protegidas por meio de criptografia, garantindo que apenas o proprietário autorizado possa acessá-las.
+- **Proteção da Chave Privada**: A *passphrase* do *keystore* protege a chave privada contra acesso não autorizado. Isso é crucial, pois a chave privada é usada para decifrar as mensagens recebidas e assinar as mensagens enviadas, garantindo a autenticidade e integridade da comunicação.
+- **Confidencialidade**: Como os *keystores* são protegidos por *passphrase*, mesmo que alguém obtenha acesso ao arquivo, não poderá extrair a chave privada sem a *passphrase* correta. Isso ajuda a manter a confidencialidade das chaves privadas dos usuários.
+
+
+## Criptografia
+
+É importante destacar que, para garantir a segurança e integridade das mensagens, implementamos um protocolo de comunicação seguro. Este protocolo utiliza tanto criptografia simétrica quanto assimétrica. As mensagens são cifradas com a chave pública do destinatário para garantir a confidencialidade, enquanto são assinadas com a chave privada do emissor para autenticidade. Dessa forma, asseguramos que as mensagens sejam protegidas contra acessos não autorizados e que sua origem possa ser verificada.
 
 ![Digital Envelope](report_content/digital-envelope-diagram.drawio.png)
 
-Justificar a necessidade de cifrar e autenticaçao e explicar melhor o processo de encryption com o diagrama
-
-É importante destacar que, para garantir a segurança e integridade das mensagens, implementamos um protocolo de comunicação seguro. Este protocolo utiliza tanto criptografia simétrica quanto assimétrica. As mensagens são cifradas com a chave pública do destinatário para garantir a confidencialidade, enquanto são assinadas com a chave privada do emissor para autenticidade. Dessa forma, asseguramos que as mensagens sejam protegidas contra acessos não autorizados e que sua origem possa ser verificada.
 
 ### Networking
 
@@ -141,13 +194,17 @@ Além disso, foram implementadas funções auxiliares para criar instâncias de
 
 Para facilitar a serialização e desserialização dos pacotes em formato JSON, foram implementadas funções `Unmarshal` específicas para cada tipo de pacote. Estas funções convertem os dados do pacote entre o formato JSON e as estruturas de dados correspondentes, permitindo a comunicação eficiente entre o cliente e o servidor.
 
-Este package serve como uma camada de abstração que facilita a comunicação entre os componentes cliente e servidor, garantindo que os dados sejam transmitidos de forma estruturada e padronizada, facilitando o desenvolvimento, manutenção e expansão do sistema de comunicação.
+Este package serve como uma camada de abstração que facilita a comunicação entre os componentes cliente e servidor, garantindo que os dados sejam transmitidos de forma estruturada e *standardized*, facilitando o desenvolvimento, manutenção e expansão do sistema de comunicação.
 
 ## Server
 
-### Data Store
+### Sqlite3 Database
+
+Como mencionado anteriormente neste relatório, uma das funcionalidades adicionais implementadas foi o armazenamento dos dados do servidor numa base de dados persistente. Neste projeto, optamos por utilizar o **SQLite3**. Este é utilizado para armazenar as mensagens enviadas e recebidas pelos utilizadores, além dos certificados digitais dos clientes. A escolha de uma base de dados permite a persistência segura e eficiente dos dados, assegurando que as mensagens e certificados sejam armazenados de maneira duradoura e acessível.
+
+Em relação à segurança contra ataques como *SQL Injection*, é crucial adotar medidas para mitigar esse tipo de ameaça. A utilização de *prepared statements* é uma prática essencial para prevenir ataques deste tipo. Com *prepared statements*, os valores dos parâmetros são tratados como dados e não como parte do comando SQL, o que reduz significativamente o risco de injeção de código malicioso. Essa abordagem fortalece a segurança do sistema, garantindo a integridade e confiabilidade das operações da base de dados.
+
 
-Verificaçao de dados ? Proteçao contra ataques a base de dados (falar apenas em nota que nao foi implementado, possivelmente fora do scope deste projeto)
 
 ## Client
 
@@ -155,5 +212,3 @@ Verificaçao de dados ? Proteçao contra ataques a base de dados (falar apenas e
 
 falar da fakeCA
 
-[Commands used to generate the key stores](./certs/README.md)
-