Cipher Pulse

Secure Client–Server Monitoring System

A small client-server tool for monitoring system health across machines: clients collect local metrics and ship them to a central server over an encrypted, authenticated channel, where they're smoothed, checked against thresholds, stored, and plotted in real time.

I built this as a personal project to get hands-on with applying cryptography correctly in a network tool, rather than just calling library functions and hoping for the best -- the interesting part turned out to be everywhere around the encryption calls, not the calls themselves.

What it does

• Client (client.py): collects CPU, memory, disk, process, and network connection stats via psutil, encrypts each reading, and sends it to the server over TCP at a configurable interval.
• Server (server.py): verifies and decrypts incoming readings, tracks an exponentially weighted moving average (EWMA) per client for each metric, flags threshold breaches (memory/CPU >= 90%, disk >= 80%), and renders the trends live with an animated matplotlib dashboard.

Security design

• AES-CBC + HMAC-SHA256 (via pycryptodome) for every message: encrypt-then-MAC, with the IV covered by the MAC so it can't be tampered with in transit.
• Random IV per message -- no two messages, even with identical content, produce the same ciphertext.
• Records encrypted at rest, not just in transit, on both the client and server.
• client_id validated as a UUID before it's ever used to build a file path.
• Basic replay protection: messages outside a 60-second freshness window (checked against the datetime field) are rejected.
• Per-connection integrity check: each client's stored history carries its own HMAC, verified before every append, so tampering with the file on disk is detected rather than silently accepted.

Hardening history

The first working version encrypted data in transit but had several gaps a security-focused pass turned up:

Before	Fixed
Fixed IV reused for every message	Random IV per message
HMAC built from stdlib hashlib/hmac	Consistent use of pycryptodome throughout
Data only encrypted in transit	Records encrypted at rest on both sides
client_id used unsanitized in a file path (path traversal)	Validated as a UUID before touching the filesystem
A local variable holding the "stored hash" never persisted between writes, crashing the client on the second reading for any client	Integrity anchor is now a real HMAC persisted to disk and checked before every append
No protection against a captured message being replayed later	Timestamp freshness check (60s window)
Server only handled one connection at a time despite a docstring claiming otherwise	Each connection now runs in its own thread

Known limitations

This is a learning project, not a production system. A few things I'd do differently given more scope:

• Key exchange: the AES/HMAC key is a static shared secret baked into both scripts. A real deployment would negotiate session keys (e.g. via Diffie-Hellman or TLS) instead of shipping a fixed key in source.
• Transport security: raw TCP sockets, no TLS -- fine for a local demo, not for anything crossing an untrusted network.
• Replay protection is a coarse time window, not per-message nonces -- good enough to close the obvious gap, not airtight.
• Key separation: the same key is used for both encryption and authentication rather than deriving separate subkeys.

Running it

pip install -r requirements.txt

# terminal 1
python server.py
# Enter port number: 5000

# terminal 2 (repeat on any machine you want monitored)
python client.py
# Enter server IP address: <server's IP>
# Enter server port number: 5000
# Enter frequency of data collection (seconds): 5

The server writes one encrypted record file per client under server_records/, and each client keeps its own encrypted history under client_records/. Stop either side with Ctrl+C.