🔐 SecureLink 🪪

Secure Messaging, Applied Cryptography, Attack Simulation & Security Monitoring Platform

🚀 Executive Summary

SecureLink is a secure messaging and attack-detection platform that demonstrates applied cryptography, authentication, message integrity, replay protection, digital signatures, TLS termination, rate limiting, security telemetry, and IDS-style monitoring.

The system models a safer communication workflow where messages are encrypted, authenticated, signed, validated, monitored, and protected against common attack classes such as replay, tampering, invalid signatures, and simulated man-in-the-middle behavior.

This project was built as a CS50 Cybersecurity final project and extended into a production-style secure systems engineering portfolio project.

It demonstrates how cybersecurity concepts move from theory into a working application architecture.

🧩 Problem Statement

Modern applications exchange sensitive messages across networks, APIs, browsers, services, databases, and third-party infrastructure.

Without layered defences, those messages can be:

intercepted
modified
replayed
forged
exposed through weak authentication
abused through missing rate limits
left invisible due to poor monitoring

SecureLink addresses this by combining secure communication primitives with an observable attack-detection workflow.

The goal is not just to encrypt data.

The goal is to show how a real secure system requires:

authentication
authorization
confidentiality
integrity
non-repudiation
replay protection
transport security
auditability
monitoring
incident visibility

🌍 Real-World Incident Inspiration

SecureLink is partly inspired by the 2024 Snowflake customer data theft campaign attributed by Mandiant to UNC5537.

That campaign showed how stolen credentials, weak access controls, missing MFA, and limited anomaly detection can lead to large-scale cloud data theft and extortion.

The lesson is powerful:

Encryption matters, but identity, access control, monitoring, and incident response matter just as much.

SecureLink focuses on the defensive side of that lesson by implementing a layered security model for secure application messaging.

🧠 CS50 Cybersecurity Concepts Applied

This project directly connects to the major themes from CS50 Cybersecurity.

https://youtu.be/xoNXw7LtP6w

0. Securing Accounts

SecureLink implements authentication controls designed to reduce account compromise risk.

Applied Concepts

User registration
Login workflows
Password hashing with bcrypt
JWT access tokens
Authenticated API routes
Current-user lookup through /auth/me

Project Implementation

POST /auth/register
POST /auth/login
GET  /auth/me

Passwords are never stored in plaintext. Instead, they are hashed before persistence, helping protect users even if database contents are exposed.

1. Securing Data

SecureLink protects message confidentiality and integrity using modern cryptographic primitives.

Applied Concepts

Symmetric encryption
Message authentication
Hashing
Digital signatures
Secure key exchange
Integrity validation

Project Implementation

Security Goal	Implementation
Confidentiality	AES-256-GCM encrypted messages
Integrity	HMAC-SHA256 validation
Authenticity	RSA-PSS digital signatures
Key exchange demo	Diffie-Hellman shared-key workflow
Replay prevention	Message IDs, nonces, and timestamps

The project demonstrates that secure data protection requires multiple layers.

Encryption protects content.

HMAC protects integrity.

Signatures help prove origin.

Replay protection prevents old messages from being reused maliciously.

2. Securing Systems

SecureLink includes infrastructure-level security controls beyond application logic.

Applied Concepts

TLS
Reverse proxying
Service readiness
Containerized infrastructure
Monitoring
Observability
Rate limiting

Project Implementation

Docker Compose service orchestration
Caddy TLS reverse proxy
PostgreSQL persistence
Redis-backed IP rate limiting
In-memory fallback rate limiting
/health and /ready checks
Prometheus /metrics
Grafana monitoring stack

This makes SecureLink more than a script.

It behaves like a real deployed security service.

3. Securing Software

SecureLink demonstrates secure software design through attack simulation, validation, and defensive coding patterns.

Applied Concepts

Secure API design
Input validation
Attack simulation
Tamper detection
Replay detection
Invalid-signature detection
Security event logging

Project Implementation

POST /security/simulate/replay
POST /security/simulate/tamper
POST /security/simulate/invalid-signature
POST /security/simulate/mitm

The attack simulator allows the system to demonstrate not only normal behavior, but also how malicious behavior is detected and logged.

This is important because secure software should be testable against adversarial scenarios.

4. Preserving Privacy

SecureLink is designed around reducing unnecessary exposure of sensitive communication data.

Applied Concepts

Encrypted message storage
Authenticated access
Limited visibility
Security event audit trail
Privacy-aware design

Project Implementation

Messages are stored encrypted, accessed only through authenticated workflows, and inspected through controlled API paths.

The dashboard visualizes security events without exposing unnecessary plaintext message contents.

The broader privacy lesson:

Data privacy is not only about hiding information. It is about controlling who can access it, when they can access it, and how that access is monitored.

🎓 CSEN2071 Concepts Applied

SecureLink also maps directly to core cybersecurity and cryptography concepts from CSEN2071.

Unit	Concept	SecureLink Application
Unit 1	Security concepts, attacks, services, mechanisms	Attack simulation, CIA triad, security monitoring
Unit 2	AES symmetric encryption	AES-256-GCM encrypted messages
Unit 3	RSA and Diffie-Hellman	RSA-PSS signatures and DH shared-key demo
Unit 4	SHA, HMAC, digital signatures	HMAC-SHA256 and signature validation
Unit 5	TLS, firewalls, IDS/IPS concepts	Caddy TLS proxy, rate limiting, security dashboard

🏗️ Architecture

SecureLink uses a modular architecture built around secure APIs, persistent storage, attack simulation, and observability.

System Flow

Client / Swagger / Simulator
        ↓
Caddy TLS Reverse Proxy
        ↓
FastAPI Security API
        ↓
Authentication + Crypto + Validation Layer
        ↓
PostgreSQL + SQLAlchemy
        ↓
Security Events + Metrics
        ↓
Streamlit Dashboard + Prometheus + Grafana

Core Components

Component	Responsibility
FastAPI API	Authentication, messaging, keys, security simulation
SQLAlchemy	ORM for users, messages, events
PostgreSQL	Persistent storage
Redis	IP rate limiting
Caddy	TLS reverse proxy
Streamlit	Security event dashboard
Prometheus	Metrics collection
Grafana	Observability dashboards
Attack Simulator	Replay, tamper, invalid-signature, MITM demos

🧨 Attack Flow

SecureLink includes attack simulation workflows to demonstrate how the system detects suspicious behavior.

Simulated Attacks

Attack	What It Tests
Replay Attack	Reusing a previously valid message
Tampering	Modifying encrypted or signed message data
Invalid Signature	Forged or corrupted digital signatures
MITM Simulation	Unsafe communication assumptions and key exchange risks

Each simulation produces a security event that can be reviewed through the API, dashboard, and monitoring stack.

🔐 Security Features

Authentication

User registration
Login
JWT-based session access
Protected API routes
Current-user identity endpoint

Cryptography

AES-256-GCM encrypted messages
HMAC-SHA256 integrity protection
RSA-PSS digital signatures
Diffie-Hellman shared-key demonstration
Secure random nonces
Timestamp validation

Attack Detection

Replay detection
Tamper detection
Invalid-signature detection
MITM simulation
IDS-style security events

Infrastructure Security

TLS reverse proxy through Caddy
Redis-backed rate limiting
Security headers
PostgreSQL persistence
Alembic migrations
Docker Compose service orchestration

Observability

Streamlit dashboard
Prometheus metrics
Grafana monitoring
/health
/ready
/metrics

🌐 API Endpoints

Authentication

POST /auth/register
POST /auth/login
GET  /auth/me

Key Management

POST /keys/generate-rsa
POST /keys/exchange-dh
GET  /keys/public/{user_id}

Secure Messaging

POST /messages/send
GET  /messages/inbox
GET  /messages/{message_id}

Security Monitoring

GET  /security/events
GET  /security/summary
POST /security/simulate/replay
POST /security/simulate/tamper
POST /security/simulate/invalid-signature
POST /security/simulate/mitm

Platform Health

GET /health
GET /ready
GET /metrics

⚙️ Local Setup

Use Python 3.12.

Create Virtual Environment

python -m venv .venv

Activate Environment

Windows

.venv\Scripts\activate

macOS / Linux

source .venv/bin/activate

Install Dependencies

pip install -r requirements.txt

Run API Locally

uvicorn app.main:app --reload

🐳 Docker Setup

docker compose up --build

Services

Service	URL
API	`http://localhost:8010`
API Docs	`http://localhost:8010/docs`
Dashboard	`http://localhost:8501`
Prometheus	`http://localhost:9090`
Grafana	`http://localhost:3010`
TLS Reverse Proxy	`https://localhost:8443`

Grafana login:

admin / securelink

TLS uses Caddy's internal local certificate authority in Docker.

🧭 Interface Connectivity

SecureLink exposes four browser-accessible interfaces, each serving a different role in the security workflow.

All of them connect back to the same secure messaging system, but they are designed for different audiences and demo moments.

Browser
  |
  |-- Swagger UI: http://localhost:8010/docs
  |       API testing console
  |       Used to register users, log in, send messages, and trigger attacks
  |
  |-- Streamlit Dashboard: http://localhost:8501
  |       Security monitoring dashboard
  |       Used to visualize failed logins, replay attempts, HMAC failures,
  |       invalid signatures, severity counts, and recent security events
  |
  |-- Prometheus: http://localhost:9090
  |       Metrics collection and query layer
  |       Used to inspect API metrics, health signals, and exported telemetry
  |
  |-- Grafana: http://localhost:3010
          Production observability dashboard
          Used to visualize metrics from Prometheus in a monitoring UI

FastAPI / Swagger UI

Swagger UI is automatically served by the FastAPI backend.

Open:

http://localhost:8010/docs

Use Swagger UI for active API testing.

Common Swagger Demo Actions

POST /auth/register
POST /auth/login
GET  /auth/me

POST /messages/send
GET  /messages/inbox
GET  /messages/{message_id}

POST /security/simulate/replay
POST /security/simulate/tamper
POST /security/simulate/invalid-signature
POST /security/simulate/mitm

GET  /security/events
GET  /security/summary

Swagger acts as the project’s API console.

It is the best place to manually:

Register Alice and Bob.
Log in as Alice.
Authorize requests with Alice’s JWT token.
Send Bob a secure encrypted message.
Log in as Bob.
Read Bob’s inbox.
Trigger replay, tamper, invalid-signature, and MITM simulations.

Streamlit Security Dashboard

Streamlit is a separate dashboard service.

Open:

http://localhost:8501

The dashboard is used for security monitoring, not as the primary messaging frontend.

Inside Docker, Streamlit calls the FastAPI backend using Docker’s internal service name:

http://api:8000

Do not enter that internal Docker URL in your browser. From your browser, use:

http://localhost:8501

Dashboard Login Flow

You enter a username and password in Streamlit.
Streamlit sends a login request to FastAPI:

POST /auth/login

FastAPI returns a JWT token.
Streamlit stores the token in session state.
Streamlit calls:

GET /security/summary
GET /security/events

The dashboard displays security telemetry.

Dashboard Shows

total security events
severity counts
replay attempts
tamper attempts
invalid signature events
failed login events
recent security event table
IDS-style monitoring output

Prometheus Metrics

Prometheus is the metrics collection and query layer.

Open:

http://localhost:9090

SecureLink exposes metrics through the FastAPI endpoint:

GET /metrics

Prometheus scrapes these exported metrics and makes them queryable.

Prometheus Is Used To Inspect

API request metrics
service health signals
exported telemetry
runtime monitoring data
security-related counters where available

Example Monitoring Questions

Is the API responding?
Are requests increasing?
Are security simulation events increasing?
Are error rates changing?
Is the service ready and healthy?

Prometheus is the raw metrics layer.

Grafana turns those metrics into visual dashboards.

Grafana Observability Dashboard

Grafana is the production-style observability interface.

Open:

http://localhost:3010

Default credentials:

admin / securelink

Grafana reads metrics from Prometheus and provides a dashboard-style view of system behavior.

Grafana Is Used To Show

service health
API activity
metrics trends
observability readiness
production monitoring workflow

This gives SecureLink a more realistic deployment profile because security systems need both application-level event logs and infrastructure-level monitoring.

Monitoring Test Process

After starting the Docker stack:

docker compose up --build

the monitoring services can be tested locally through Prometheus, Grafana, Swagger UI, and the Streamlit dashboard.

Expected local status:

Prometheus: ready
Grafana: ok
FastAPI /metrics: SecureLink metrics are present

Test Prometheus

Open:

http://localhost:9090

Then go to:

Status -> Targets

The securelink-api target should show:

UP

Return to the Prometheus query page and test:

securelink_http_requests_total

sum by (path) (securelink_http_requests_total)

sum by (path) (rate(securelink_http_requests_total[5m]))

histogram_quantile(0.95, sum by (le, path) (rate(securelink_http_request_duration_seconds_bucket[5m])))

Generate more traffic by refreshing Swagger UI, logging in through Streamlit, triggering attack simulations, or running:

curl.exe http://localhost:8010/health
curl.exe http://localhost:8010/ready
curl.exe http://localhost:8010/metrics

Test Grafana

Open:

http://localhost:3010

Login:

Username: admin
Password: securelink

A Grafana Cloud account is not required. This project runs a local Grafana container through Docker Compose.

Check the Prometheus data source:

Connections -> Data sources -> Prometheus

It should already point to:

http://prometheus:9090

Click Save & test. Grafana should report that the data source is working.

To create a visualization, go to:

Dashboards -> New -> New visualization

Choose Prometheus and try:

sum by (path) (rate(securelink_http_requests_total[5m]))

sum(securelink_http_requests_total)

sum by (status_code) (rate(securelink_http_requests_total[5m]))

Local Hosting Note

Swagger UI and Streamlit run locally after Docker starts the stack:

Swagger UI: http://localhost:8010/docs
Streamlit:  http://localhost:8501

Inside Docker, Streamlit reaches FastAPI through:

http://api:8000

From a browser on the host machine, use the localhost URLs. A public Streamlit Community Cloud dashboard cannot access a laptop's localhost; a public dashboard would require a publicly hosted FastAPI backend.

How They Work Together In The Demo

Use all four interfaces together for the most polished SecureLink demonstration.

1. Swagger UI: Perform Security Actions

Use Swagger to:

register Alice and Bob
log in users
send encrypted messages
read inbox messages
trigger attack simulations

2. Streamlit: Visualize Security Events

Use Streamlit to show:

attacks logged
failed login events
replay attempts
high-severity counts
security event summaries
recent alerts

3. Prometheus: Inspect Raw Metrics

Use Prometheus to show:

metrics exposure
/metrics integration
service telemetry
queryable runtime signals

4. Grafana: Present Observability

Use Grafana to show:

production-style dashboarding
visual monitoring
service health and metrics trends

Current UI Scope

In the current version, Streamlit is a security monitoring dashboard.

Message sending is handled through:

Swagger UI
attack simulator scripts
API endpoints

Streamlit is not yet a full chat interface.

A future enhancement would be adding a dedicated Streamlit Messaging Demo tab that supports:

log in as Alice
choose Bob
send secure message
log in as Bob
view inbox
trigger attack scenarios
watch the dashboard update in real time

This separation is intentional and realistic for a backend/security engineering project.

Interface	Purpose
Swagger UI	API testing and manual security workflow execution
Streamlit Dashboard	Security monitoring and event visualization
Prometheus	Metrics collection and query layer
Grafana	Production observability dashboards

🧪 Demo Walkthrough

This demo uses Swagger UI for API actions and Streamlit for monitoring.

Step 1: Start The Stack

docker compose up --build

Verify:

API ready: http://localhost:8010/ready
Dashboard: http://localhost:8501

Step 2: Use Swagger For API Actions

Open:

http://localhost:8010/docs

Then:

Register Alice with POST /auth/register.
Register Bob with POST /auth/register.
Login Alice with POST /auth/login.
Click Authorize and paste:

Bearer <alice_token>

Send Bob a message with POST /messages/send.
Login Bob and authorize Swagger with Bob’s token.
Read Bob’s inbox with GET /messages/inbox.
Trigger replay, tamper, invalid-signature, and MITM simulations.

Step 3: Use Streamlit For Security Monitoring

Open:

http://localhost:8501

Log in with any user registered through Swagger, such as Alice or Bob.

Use the dashboard to inspect:

security event counts
severity breakdowns
replay attempts
HMAC/tamper failures
invalid signatures
recent event logs

Step 4: Use Prometheus And Grafana For Observability

Open:

http://localhost:9090
http://localhost:3010

Grafana credentials:

admin / securelink

This demonstrates the full SecureLink workflow:

Swagger UI executes actions
        ↓
FastAPI validates, encrypts, signs, detects, and logs events
        ↓
Streamlit visualizes security events
        ↓
Prometheus and Grafana expose production-style monitoring

Full Demo Shortcut

python attack_simulator/full_demo.py --api http://localhost:8010

🧾 Example Message Body

{
  "receiver_id": 2,
  "plaintext": "Hello Bob, this is a secure encrypted message."
}

🧬 Production Workflow

Copy .env.example to .env.
Replace development secrets.
Run Docker Compose.
Confirm /health and /ready.
Register demo users.
Send secure messages.
Run attack simulations.
Review dashboard alerts.
Review Prometheus metrics.
Review Grafana dashboards.
Run tests before pushing changes.

The API container runs:

alembic upgrade head

on startup before launching Uvicorn.

✅ Testing

Run Unit Tests

pytest

Run Compile Checks

python -m compileall app attack_simulator tests

Optional Dockerized PostgreSQL Integration Check

docker compose up -d db redis

PowerShell

$env:SECURELINK_POSTGRES_TEST_URL="postgresql+psycopg2://securelink:securelink@localhost:15432/securelink"
pytest tests/test_postgres_integration.py

macOS / Linux

export SECURELINK_POSTGRES_TEST_URL="postgresql+psycopg2://securelink:securelink@localhost:15432/securelink"
pytest tests/test_postgres_integration.py

CI is configured in:

.github/workflows/ci.yml

📈 Observability

SecureLink exposes operational and security signals through:

/metrics
Prometheus
Grafana
Streamlit dashboard
security event APIs

Example Monitoring Questions

How many attacks were simulated?
Which attack type occurred most often?
Did replay detection trigger?
Did tamper detection trigger?
Are APIs healthy?
Is the system ready?
Are suspicious requests increasing?

⚠️ Security Limitations

SecureLink is an educational and portfolio-grade security system.

It intentionally demonstrates security concepts in a controlled environment, but it is not a drop-in replacement for a production encrypted messaging platform.

Current limitations:

Private keys are stored encrypted with an application secret for demonstration.
Key rotation is minimal.
TLS uses Caddy's internal local certificate authority in Docker.
Diffie-Hellman-derived conversation keys are generated server-side for classroom clarity.
A full client-held end-to-end encryption ceremony is not implemented.
Hardware-backed key storage is not included.
Production deployment would require stronger secrets management and key lifecycle controls.

This section is important because strong security engineering includes knowing what the system does not yet guarantee.

👤 Author

Mitra Boga

Name		Name	Last commit message	Last commit date
Latest commit History 17 Commits
.github/workflows		.github/workflows
app		app
assets		assets
attack_simulator		attack_simulator
dashboard		dashboard
docker		docker
docs		docs
migrations		migrations
monitoring		monitoring
reverse_proxy		reverse_proxy
scripts		scripts
tests		tests
.dockerignore		.dockerignore
.env.example		.env.example
.gitattributes		.gitattributes
.gitignore		.gitignore
CODE_OF_CONDUCT.md		CODE_OF_CONDUCT.md
Dockerfile		Dockerfile
LICENSE		LICENSE
README.md		README.md
Slideshow_Presentation.pdf		Slideshow_Presentation.pdf
alembic.ini		alembic.ini
docker-compose.yml		docker-compose.yml
pytest.ini		pytest.ini
requirements.txt		requirements.txt

Folders and files

Latest commit

History

Repository files navigation

🔐 SecureLink 🪪

Secure Messaging, Applied Cryptography, Attack Simulation & Security Monitoring Platform

🚀 Executive Summary

🧩 Problem Statement

🌍 Real-World Incident Inspiration

🧠 CS50 Cybersecurity Concepts Applied

0. Securing Accounts

Applied Concepts

Project Implementation

1. Securing Data

Applied Concepts

Project Implementation

2. Securing Systems

Applied Concepts

Project Implementation

3. Securing Software

Applied Concepts

Project Implementation

4. Preserving Privacy

Applied Concepts

Project Implementation

🎓 CSEN2071 Concepts Applied

🏗️ Architecture

System Flow

Core Components

🧨 Attack Flow

Simulated Attacks

🔐 Security Features

Authentication

Cryptography

Attack Detection

Infrastructure Security

Observability

🌐 API Endpoints

Authentication

Key Management

Secure Messaging

Security Monitoring

Platform Health

⚙️ Local Setup

Create Virtual Environment

Activate Environment

Windows

macOS / Linux

Install Dependencies

Run API Locally

🐳 Docker Setup

Services

🧭 Interface Connectivity

FastAPI / Swagger UI

Common Swagger Demo Actions

Streamlit Security Dashboard

Dashboard Login Flow

Dashboard Shows

Prometheus Metrics

Prometheus Is Used To Inspect

Example Monitoring Questions

Grafana Observability Dashboard

Grafana Is Used To Show

Monitoring Test Process

Test Prometheus

Test Grafana

Local Hosting Note

How They Work Together In The Demo

1. Swagger UI: Perform Security Actions

2. Streamlit: Visualize Security Events

3. Prometheus: Inspect Raw Metrics

4. Grafana: Present Observability

Current UI Scope

🧪 Demo Walkthrough

Step 1: Start The Stack

Step 2: Use Swagger For API Actions

Step 3: Use Streamlit For Security Monitoring

Step 4: Use Prometheus And Grafana For Observability

Full Demo Shortcut

🧾 Example Message Body

Packages