188 lines
13 KiB
Markdown
188 lines
13 KiB
Markdown
# Relatório do Projeto de Desenvolvimento 1
|
||
|
||
## Introdução
|
||
|
||
A comunicação eficaz dentro de uma organização é essencial para a eficiência do seu funcionamento. No entanto, num ambiente cada vez mais digital, garantir a segurança e autenticidade das comunicações tem-se vindo a tornar uma preocupação fundamental. Em resposta a esta necessidade, este primeiro projeto de desenvolvimento visa criar um serviço de mensagens seguro e autenticado.
|
||
|
||
Para contextualizar o projeto, consideremos uma organização onde informações confidenciais são frequentemente trocadas entre membros de equipas distribuídas geograficamente. Neste cenário, é crucial que as mensagens enviadas e recebidas sejam protegidas contra acessos não autorizados e manipulação por partes externas. Além disso, garantir que a identidade do remetente e a integridade da mensagem sejam verificadas é essencial para manter a confiança e a segurança das comunicações internas.
|
||
|
||
Perante estas necessidades, o projeto de desenvolvimento propõe a criação de um sistema cliente/servidor que oferece um serviço de mensagens seguro e autenticado. Através deste sistema, os membros da organização poderão trocar mensagens com garantias de autenticidade, protegendo assim a confidencialidade e integridade das comunicações.
|
||
|
||
Ao longo deste relatório iremos detalhar as decisões mais importantes tomadas no desenvolvimento do projeto, bem como as medidas de segurança implementadas para garantir a confidencialidade, integridade e autenticidade das mensagens trocadas entre os utilizadores.
|
||
|
||
Algumas notas sobre o projeto:
|
||
|
||
- Optamos por escolher **Golang** como linguagem visando uma implementação mais eficiente, robusta e segura ao nível de concorrência. O modelo de concorrência baseado em goroutines e canais facilita a criação de programas concorrentes e sistemas distribuídos. Com uma sintaxe simples, semelhante a **C**, o **Go** promove a escrita de código legível e de alta qualidade. Além disso, o **Go** possui um ecossistema robusto de bibliotecas e ferramentas, tornando-o uma escolha adequada para o desenvolvimento de sistemas distribuídos e serviços de back-end.
|
||
|
||
- Implementamos algumas funcionalidades extra, como o armazenamento dos dados no servidor numa base de dados **sqlite3**
|
||
|
||
Nas secções seguintes iremos detalhar cada componente do sistema, bem como as funcionalidades implementadas.
|
||
|
||
## 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
|
||
|
||
## Arquitetura do Sistema
|
||
|
||
Neste projeto, a arquitetura do sistema é composta por 2 componentes principais:
|
||
|
||
- **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.
|
||
|
||
### Crypto
|
||
|
||
|
||
|
||
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
|
||
|
||
O canal de comunicação estabelecido entre o cliente e o servidor nesta implementação garante uma troca de dados segura e criptografada utilizando o protocolo TLS (Transport Layer Security). Ambos, cliente e servidor, empregam configurações TLS para cifrar os dados durante a transmissão, assegurando confidencialidade e integridade. Durante o handshake TLS, o servidor valida o certificado do cliente para verificar sua autenticidade, prevenindo acessos não autorizados. Este mecanismo robusto de segurança protege o canal de comunicação contra escutas, adulterações e ataques do tipo "man in the middle", garantindo uma troca de informações segura e confiável entre o cliente e o servidor.
|
||
|
||
### Protocolo de Comunicação
|
||
|
||
O package **protocol.go** define um conjunto de estruturas e funções que representam os diferentes tipos de pacotes que podem ser transmitidos entre o cliente e o servidor. Cada tipo de pacote é representado por uma constante PacketType, que indica a natureza da informação contida no pacote através de uma **flag**.
|
||
|
||
As estruturas de dados definidas, como `GetUserCert`, `GetUnreadMsgsInfo`, `GetMsg`, `SendMsg`, `AnswerGetUserCert`, `AnswerGetUnreadMsgsInfo` e `AnswerGetMsg`, descrevem os formatos específicos de cada tipo de pacote a ser enviado e recebido. Cada estrutura contém os campos necessários para armazenar e representar os dados associados a cada tipo de pacote.
|
||
|
||
Além disso, foram implementadas funções auxiliares para criar instâncias de cada tipo de pacote, como `NewGetUserCert`, `NewGetUnreadMsgsInfo`, `NewGetMsg`, `NewSendMsg`, `NewAnswerGetUserCert`, `NewAnswerGetUnreadMsgsInfo` e `NewAnswerGetMsg`. Estas funções facilitam a criação de pacotes com os dados necessários de forma estruturada.
|
||
|
||
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.
|
||
|
||
## Server
|
||
|
||
### Data Store
|
||
|
||
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
|
||
|
||
## Verificacao e Teste de Seguranca
|
||
|
||
falar da fakeCA
|
||
|
||
[Commands used to generate the key stores](./certs/README.md)
|
||
|
||
## Análise de Risco do Projeto de Desenvolvimento I (PD1)
|
||
|
||
A análise de risco do sistema visa identificar potenciais vulnerabilidades e ameaças que possam comprometer a segurança do sistema de mensagens. É essencial considerar diversos fatores que podem impactar a integridade, confidencialidade e disponibilidade das mensagens trocadas entre os utilizadores.
|
||
|
||
### Vulnerabilidades Potenciais:
|
||
|
||
1. **Comunicação Não Segura:**
|
||
|
||
- Se a comunicação entre os clientes e o servidor não foi cifrada, qualquer `man in the middle` consegue ler o conteudo trocado
|
||
|
||
1. **Armazenamento Inseguro de Chaves Privadas:**
|
||
|
||
- Se as chaves privadas dos utilizadores forem armazenadas de forma inadequada, como em arquivos desprotegidos, há o risco de acesso não autorizado.
|
||
|
||
1. **Autenticação Fraca:**
|
||
|
||
- Um sistema de autenticação vulnerável pode permitir que utilizadores mal-intencionados obtenham acesso não autorizado às contas dos utilizadores legítimos.
|
||
|
||
1. **Manipulação de Mensagens:**
|
||
|
||
- A ausência de mecanismos eficazes de controle pode facilitar a manipulação do conteúdo das mensagens durante a transmissão, comprometendo sua integridade.
|
||
|
||
1. **Vulnerabilidades de ‘Software’:**
|
||
|
||
- Falhas de segurança no ‘software’ utilizado para implementar o sistema podem ser exploradas por indivíduos mal-intencionados para obter acesso não autorizado ou comprometer a segurança dos dados.
|
||
|
||
### Possíveis Ameaças:
|
||
|
||
1. **Ataques de Intercetação de Dados:**
|
||
|
||
- Atacantes podem tentar intercetar a comunicação entre o cliente e o servidor para obter informações sensíveis, como chaves privadas ou conteúdo de mensagens.
|
||
|
||
1. **Ataques de Negação de Serviço (DOS):**
|
||
|
||
- Um ataque de negação de serviço pode tornar o servidor inacessível ao sobrecarregá-lo com um grande volume de solicitações, prejudicando a disponibilidade do serviço.
|
||
|
||
1. **Ataques de Engenharia Social:**
|
||
|
||
- Atacantes podem tentar manipular os usuários legítimos para obter acesso às suas credenciais de acesso por meio de técnicas de engenharia social.
|
||
|
||
1. **Exploração de Vulnerabilidades de Software:**
|
||
|
||
- Vulnerabilidades conhecidas ou desconhecidas no software utilizado podem ser exploradas por indivíduos mal-intencionados para comprometer a segurança do sistema.
|
||
|
||
### Propriedades desejadas
|
||
|
||
1. **Autenticidade do Remetente:**
|
||
|
||
- O cliente deseja ter a garantia de que a mensagem recebida foi realmente enviada pelo remetente indicado.
|
||
|
||
1. **Confidencialidade das Mensagens:**
|
||
|
||
- O cliente quer assegurar que apenas ele possui a capacidade de decifrar as mensagens que lhe foram enviadas, garantindo assim a privacidade das comunicações.
|
||
|
||
1. **Servidor Malicioso**
|
||
|
||
- Os clientes desejam poder operar sob a premissa de que o servidor pode agir de forma maliciosa, portanto, eles procuram mecanismos que garantam a segurança das suas interações, independentemente da confiabilidade do servidor.
|
||
|
||
1. **Comunicação Segura com o Servidor:**
|
||
|
||
- Os clientes exigem que a comunicação com o servidor seja segura, protegida contra acesso não autorizado e intercetação por partes não autorizadas, garantindo assim a integridade e confidencialidade dos dados transmitidos.
|
||
|
||
### Medidas de Mitigação:
|
||
|
||
1. **Protocolo de comunicação:**
|
||
|
||
- Utilizar um protocolo de comunicação que garanta a confidencialidade para proteger a comunicação entre o cliente e o servidor.
|
||
|
||
1. **Armazenamento Seguro de Chaves Privadas:**
|
||
|
||
- Adotar práticas seguras de armazenamento para proteger as chaves privadas dos utilizadores contra acesso não autorizado, como utilizar "passphrases" para proteger o acesso à "key store".
|
||
|
||
1. **Fortalecimento da Autenticação:**
|
||
|
||
- Implementar métodos robustos de autenticação, como certificados digitais, para garantir a identidade dos utilizadores e proteger contra acesso não autorizado.
|
||
|
||
1. **Validação de Dados:**
|
||
|
||
- Implementar controles de validação de dados para garantir a integridade das mensagens e prevenir a manipulação de dados por partes não autorizadas, como, por exemplo, assinar "hashes" das mensagens enviadas.
|
||
|
||
1. **Atualizações de ‘Software’:**
|
||
|
||
- Manter o ‘software’ utilizado atualizado para mitigar o risco de exploração de vulnerabilidades conhecidas e garantir a segurança do sistema.
|
||
|
||
Em suma, a análise de risco do projeto PD1 destaca a importância de identificar e mitigar potenciais vulnerabilidades e ameaças para garantir a segurança do sistema de mensagens desenvolvido. A implementação de medidas de segurança adequadas é essencial para proteger os dados e garantir o funcionamento seguro do sistema.
|
||
|
||
## Decisoes tomadas
|
||
|
||
1. TLS (Transport Layer Security):
|
||
|
||
- Cada conexão entre cliente e servidor é protegida pelo protocolo TLS, garantindo que a comunicação seja segura e privada.
|
||
- Cliente e servidor trocam certificados para autenticar as suas identidades.
|
||
- Ambos verificam se o certificado foi emitido pela Autoridade de Certificação (CA) central.
|
||
- O cliente verifica se comunica com o servidor legítimo.
|
||
|
||
1. End-to-End Encryption (E2EE):
|
||
|
||
- 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.
|
||
|
||
1. Visualização de Mensagens:
|
||
|
||
- Quando um cliente solicita a sua lista de mensagens não lidas, apenas o assunto é enviado, não o conteúdo cifrado.
|
||
- O cliente deve decifrar o assunto para visualizá-lo.
|
||
|
||
1. Troca de Chaves Públicas:
|
||
|
||
- Quando um cliente precisa da chave pública de outro cliente, solicita o certificado desse cliente ao servidor.
|
||
- Verifica-se se o certificado foi emitido pela CA central e se pertence ao cliente desejado.
|
||
|
||
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’.
|
||
|
||
1. Confiança na CA Central:
|
||
|
||
- A única confiança absoluta neste sistema é depositada na Autoridade de Certificação central, responsável por emitir os certificados.
|