Skip to content

Naliat/TrabalhoCripto

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

25 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Documentação Técnica: Sistema de Chat Seguro (P2P)

Este projeto implementa um canal de comunicação criptografado de ponta a ponta, desenvolvido para a disciplina de Criptografia (UFC Quixadá). O sistema utiliza criptografia híbrida para garantir a confidencialidade e integridade das mensagens.


1. Arquitetura de Software e Rede

O sistema foi estruturado de forma modular para separar a lógica de rede da lógica criptográfica.

  • Broadcast & Discovery (UDP): O servidor envia um beacon (sinalizador) via UDP na porta 5001. Os clientes escutam essa porta para descobrir o IP do servidor automaticamente, eliminando a necessidade de configuração manual.
  • Relay Server (TCP): O servidor funciona como um "espelho". Ele aceita duas conexões TCP na porta 5000 e repassa os bytes recebidos de um cliente diretamente para o outro, sem descriptografar o conteúdo (garantindo o segredo de ponta a ponta).
  • Threads Independentes: O cliente utiliza threads para permitir que a interface de envio de mensagens e o recebimento de dados via rede ocorram simultaneamente, sem travamentos.
├── cliente_main.py         # Interface do usuário e lógica de controle do cliente
├── run_server.py           # Ponto de entrada do Servidor (Relay)
├── invasor.py              # Ferramenta de interceptação (Sniffer)
├── requirements.txt        # Dependências (cryptography, scapy)
└── src/
    ├── crypto/             # Núcleo de Criptografia Manual
    │   ├── cbc.py          # Implementação manual do modo Cipher Block Chaining
    │   ├── ctr.py          # Implementação manual do modo Counter Mode
    │   ├── rsa_handshake.py# Protocolo RSA (Geração, Cifra e Troca)
    │   └── utils.py        # Primitivas AES-ECB, XOR e Padding PKCS#7
    └── network/            # Infraestrutura de Redes
        ├── server.py       # Lógica de sockets e repasse do servidor
        └── protocolo.py    # Constantes e definições do protocolo

2. Dependências e Requisitos

As bibliotecas utilizadas foram selecionadas para garantir a manipulação de baixo nível de bytes e a execução da primitiva AES de forma eficiente.

Biblioteca Versão Função no Projeto
cffi 2.0.0 Interface para chamadas de funções em C (requisito da cryptography).
cryptography 46.0.3 Fornece a primitiva AES-ECB e suporte a chaves RSA.
pycparser 2.23 Parser C utilizado internamente para extensões C do Python.
pycryptodome 3.23.0 Suporte adicional para funções criptográficas e manipulação de bytes.
scapy 2.6.1 Utilizada no invasor.py para sniffing e análise de pacotes de rede.

3. Implementação Criptográfica (Decisões de Projeto)

Seguindo os requisitos mandatórios, não foram utilizadas funções prontas de bibliotecas para os modos de operação. Utilizamos apenas a primitiva de cifragem de bloco (AES-ECB) para processar blocos de 128 bits.

3.1 Handshake RSA e Troca de Chaves

  • Algoritmo Assimétrico: Utilização de RSA com chaves de 2048 bits.
  • Protocolo de Troca: O Cliente A gera uma chave simétrica AES-128 aleatória e a cifra utilizando a chave pública do Cliente B. O segredo de sessão é estabelecido após o Cliente B decifrar o pacote com sua chave privada.
  • Decisão de Padding Assimétrico: Foi utilizado o esquema RSA-OAEP (Optimal Asymmetric Encryption Padding). A escolha justifica-se pela sua resistência contra ataques de texto claro escolhido (Chosen Ciphertext Attacks) e por mitigar vulnerabilidades de Padding Oracle presentes em esquemas mais antigos como o PKCS#1 v1.5.

3.2 Modo CBC (Cipher Block Chaining)

  • Lógica Manual: Implementação do encadeamento onde cada bloco de texto claro ($P_i$) sofre uma operação XOR com o bloco cifrado anterior ($C_{i-1}$) antes da cifragem AES ($C_i = E_k(P_i \oplus C_{i-1})$).
  • Gerenciamento de IV: O Vetor de Inicialização (IV) de 16 bytes é gerado aleatoriamente via os.urandom(16) para cada mensagem. Ele é enviado como prefixo (primeiros 16 bytes) do pacote para que o receptor inicialize a decodificação do primeiro bloco.
  • Regra de Padding: Implementação manual do padrão PKCS#7, preenchendo o bloco até atingir o tamanho de 16 bytes.

3.3 Modo CTR (Counter Mode)

  • Lógica de Fluxo: O AES cifra um contador incremental (Nonce + Counter) para gerar um keystream. O texto cifrado é obtido através do XOR entre o texto claro e este fluxo ($C = P \oplus E_k(Counter)$).
  • Gerenciamento de Nonce: Um Nonce de 8 bytes aleatório é gerado por mensagem e enviado no início de cada pacote. Ele é concatenado a um contador de 8 bytes que inicia em zero e incrementa a cada bloco de 16 bytes processado.
  • Vantagem de Padding: Este modo opera como uma cifra de fluxo, portanto, o padding é desnecessário, uma vez que a operação XOR é aplicada apenas aos bytes existentes na mensagem original.

3.4 Transporte e Sincronização

  • Codificação Base64: Todos os dados cifrados são convertidos para Base64 antes do envio. Isso garante a integridade dos bytes na rede TCP, evitando que caracteres de controle ou bytes nulos corrompam o fluxo de dados.
  • Sincronização de Modo: No início da conexão, o Cliente A envia um pacote de controle definindo o modo de operação (CBC ou CTR), garantindo que ambos os terminais instanciem o mesmo algoritmo para a sessão.

4. Discussão Comparativa: CBC vs CTR

Critério Modo CBC Modo CTR
Padding Obrigatório (PKCS#7) Não necessário
Eficiência Pacotes múltiplos de 16 bytes Pacotes de tamanho exato + Nonce
Resiliência Propaga erros entre blocos Erro afeta apenas o bit correspondente

4.1 Análise Comparativa e Decisões de Projeto

A implementação manual de ambos os modos permitiu uma análise profunda das exigências técnicas de cada um:

  • Facilidade de Implementação: O modo CTR mostrou-se consideravelmente mais simples de codificar manualmente. Por transformar uma cifra de bloco em uma cifra de fluxo, ele permite que a lógica de cifragem e decifragem seja idêntica (XOR entre o texto e o keystream), o que reduz a complexidade do código e a probabilidade de bugs de implementação.
  • Gestão de Blocos e Padding: O modo CBC exigiu maior rigor técnico devido à necessidade de preenchimento (Padding PKCS#7). A remoção precisa do padding na recepção é um ponto crítico: qualquer erro de um único byte no gerenciamento do IV ou no encadeamento dos blocos resulta em falha catastrófica de integridade na decodificação.
  • Eficiência de Rede: O modo CTR é mais eficiente para mensagens curtas, pois não expande o dado original até o próximo múltiplo de 16 bytes, enviando apenas os bytes da mensagem mais os 8 bytes do Nonce.

5. Análise de Segurança: Por que o Invasor Falha?

Um dos objetivos centrais deste projeto é demonstrar a Confidencialidade. Abaixo, detalhamos a perspectiva do atacante durante a troca de mensagens.

5.1 O que o Invasor consegue ver?

Se um atacante executar o invasor.py (sniffer) na rede, ele conseguirá capturar todos os pacotes que passam pela porta 5000. No entanto, o que ele vê é limitado a:

  • Endereços IP: Ele sabe quem está conversando com quem (Metadados).
  • Volume de Dados: Ele sabe o tamanho das mensagens enviadas.
  • Payload Cifrado: Ele vê uma sequência de caracteres em Base64 que, ao ser decodificada, resulta em bytes aleatórios (o Ciphertext).
  • O Vetor de Inicialização (IV) ou Nonce: Estes valores viajam em texto claro no início do pacote, mas, sem a chave secreta, eles são inúteis para a decodificação.

5.2 Por que ele não entende a mensagem?

A impossibilidade de leitura pelo invasor deve-se a dois fatores matemáticos:

  1. Segredo da Chave de Sessão (AES): A chave de 128 bits nunca é enviada de forma aberta. Ela é gerada por um cliente e "embrulhada" com a chave pública RSA do outro. Para o invasor descobrir essa chave, ele precisaria resolver o problema da fatoração de números inteiros grandes, o que é computacionalmente inviável com as tecnologias atuais.
  2. Difusão e Confusão: O algoritmo AES aplica múltiplas rodadas de operações matemáticas (SubBytes, ShiftRows, MixColumns). Isso garante que cada bit do texto claro dependa de vários bits da chave. Se o invasor tentar chutar uma letra da mensagem, ele falhará, pois não existe uma relação direta ou padrão visível entre o texto original e o cifrado.

5.3 O "Efeito Avalanche" e a Variabilidade

Mesmo que você envie a mesma palavra "Bom dia" dez vezes seguidas, o invasor verá dez pacotes completamente diferentes:

  • No modo CBC: O IV (Vetor de Inicialização) muda a cada mensagem, alterando o resultado do XOR do primeiro bloco.
  • No modo CTR: O Nonce/Contador garante que o keystream seja único para cada envio.

Isso impede o Ataque de Replay ou a análise estatística, onde o invasor poderia tentar adivinhar palavras comuns baseando-se na repetição de padrões.

6. Como Executar

Siga os passos abaixo na ordem exata para garantir o funcionamento correto do ecossistema (Ambiente, Servidor, Invasor e Clientes).

6.1 Configuração do Ambiente Virtual (venv)

É altamente recomendável o uso de um ambiente virtual para isolar as dependências e evitar conflitos:

No Linux / macOS:

  1. Criar o ambiente: python3 -m venv venv
  2. Ativar o ambiente: source venv/bin/activate
  3. Instalar dependências: pip install -r requirements.txt

No Windows:

  1. Criar o ambiente: python -m venv venv
  2. Ativar o ambiente: .\venv\Scripts\activate
  3. Instalar dependências: pip install -r requirements.txt

6.2 Inicialização do Ecossistema (Ordem Correta)

Para uma demonstração completa, siga esta sequência de terminais:

1º Terminal: Servidor (Relay) Deve ser o primeiro a ser iniciado para aceitar as conexões TCP e emitir o sinalizador de rede.

  • Comando: python3 run_server.py (Linux) ou python run_server.py (Windows)

2º Terminal: Invasor (Sniffer) - Opcional Inicie o invasor antes dos clientes para capturar o tráfego desde o início. Nota: No Windows, o Scapy pode exigir a instalação do Npcap; no Linux, exige privilégios de superusuário.

  • Comando (Linux): sudo ./venv/bin/python3 invasor.py
  • Comando (Windows): python invasor.py (Executar terminal como Administrador)

3º e 4º Terminais: Clientes A e B Abra dois terminais distintos, ative a venv em ambos e execute:

  • Comando: python3 cliente_main.py (Linux) ou python cliente_main.py (Windows)

Fluxo de Operação:

  1. No Cliente A: O sistema solicitará a escolha do modo (1 para CBC ou 2 para CTR).
  2. No Cliente B: O sistema aguardará a escolha do Cliente A e realizará o Handshake RSA automaticamente.
  3. Com o canal seguro ativo, as mensagens digitadas serão cifradas, codificadas em Base64 e enviadas via servidor de relay.

7. Evidências de Testes e Funcionamento

Abaixo estão as capturas de tela que demonstram o sistema em execução, desde a descoberta do servidor até a interceptação maliciosa falha.

7.1 Descoberta e Handshake RSA

Demonstração do servidor enviando o Beacon UDP e os clientes estabelecendo a chave de sessão segura.

Servidor e Handshake Troca de Chaves

7.2 Comunicação Segura (CBC vs CTR)

Exemplo de troca de mensagens utilizando os diferentes modos de operação selecionados em tempo real. Troca de Chaves

Troca de Chaves

Troca de Chaves

7.3 Interceptação com Invasor (Sniffer)

Prova de que o atacante, ao interceptar os pacotes na porta 5000, visualiza apenas dados cifrados e o preenchimento (padding) no modo CBC.

Troca de Chaves Troca de Chaves

Troca de Chaves

Troca de Chaves

8. Desenvolvedores

  • Tailan de Souza: Cliente-Servidor, Modo CTR, Integração e documentação.
  • JV: Handshake RSA, Modo CBC e Utilitários.
  • UFC Quixadá - 2025

About

O projeto visa criar um protótipo de chat seguro, aplicando criptografia simétrica e assimétrica para garantir confidencialidade. Envolve arquitetura cliente-servidor que negocia chaves de forma segura e cifra mensagens com modos específicos de operação de blocos.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages