Skip to content
This repository has been archived by the owner on Oct 12, 2021. It is now read-only.
Gianluca Serao edited this page Jun 22, 2021 · 12 revisions

Secure messaging is a chatting application developed for the Foundations of Cybersecurity course of the MSc AIDE at the University of Pisa.

Requirements

General requirements

  • Users are already registered on the server through public keys. Users authenticate themselves through the said public key.
  • When the client application starts, the server and the client must authenticate. The server must authenticate with a public key certified by a certification authority, while the client must authenticate with the public key pre-installed on the server. The corresponding private key is protected with a password on the client.
  • After authentication, the client and the server must negotiate a symmetric session key.
  • After the log-in, a user can see other available users logged to the server.
  • The server is “honest-but-curious”:
    • It will not communicate false public keys on purpose. When the server communicates the public key of the user “Alice”, the receiving client trusts that the server has given it the Alice’s public key.
    • It would try to understand the content of the communications between clients, we need to avoid this happen.

Chat requirements

  • A user can send a "request to talk" message to another user. The user who receives the "request to talk" can either accept or refuse. If the request is accepted, the users chat through the server using an end-to-end encrypted and authenticated communication.
  • After a "request to talk" is accepted, the server sends both clients the public key of the other client. Before starting the chat, the clients must negotiate a symmetric session key.
  • When a chat starts, the clients cannot start another chat (1 chat active at a time).
  • When a client wants to stop chatting, it shall log-off from the server.
  • The server acts as an intermediary for the message exchanged.

Security requirements

  • The symmetric keys negotiations must provide Perfect Forward Secrecy.
  • All session messages must be encrypted, authenticated and protected against replay attacks.

Design choices

  • The messages between client and server are exchanged through TCP to offer reliable communication. All the messages are exchanged through the server.

  • The session key exchange is performed using Ephemeral Diffie-Hellman to ensure perfect forward secrecy.

  • The sessions are encrypted and authenticated using authenticated encryption with AES-GCM. A counter is used to protect the messages against replay attacks.

  • A user in an active chat can close the communication by typing "!deh". In this case, the server will forward the message to the other side and removes the chat from the active ones.

  • Each message can be at most MAX_MESSAGE_SIZE characters. This limit is defined in symbols.h.

  • The plaintexts have a recursive structure: |OPCODE|CONTENT1_LENGTH|CONTENT1|CONTENT2_LENGTH|CONTENT2|...|.