blue_ghost

Purpose

The blue_ghost threat model defines what the system protects against, what it does not protect against, and the assumptions required for secure operation. The goal: minimize systemic exposure by eliminating entire classes of attack.

Assumptions

• Both devices are running authentic, untampered builds of blue_ghost
• Android's TEE (Trusted Execution Environment) is uncompromised
• Users verify each other's Safety Numbers out-of-band to confirm session authenticity
• Attackers cannot physically access the device during an active session

Adversary Classes

blue_ghost is designed to defend against:

• Passive RF interceptors — BLE sniffers, SDR rigs capturing packets in the air
• Active network adversaries — MITM attempts during handshake, replay and injection attacks
• Metadata collectors — centralized servers, cloud relays, ISP-level surveillance
• Malicious access points — Wi‑Fi exploitation vectors (eliminated entirely)
• Compromised infrastructure — routers, telecoms, cloud providers
• Bulk surveillance systems — dragnet RF collection

The system assumes adversaries may have:

• Full RF capture capability with long-term storage
• BLE packet injection and replay tooling
• Access to OS-level device metadata
• Correlation capabilities across time and location

Threats Mitigated

• ✓ mitigatedMessage interception — AES-256-GCM + Double Ratchet; captured packets are opaque ciphertext
• ✓ mitigatedReplay attacks — authenticated sequence numbers + 1024-message sliding window bitmap
• ✓ mitigatedMessage injection or reordering — GCM authentication tag failure on tampered payloads
• ✓ mitigatedMITM during handshake — Safety Number verification (out-of-band comparison)
• ✓ mitigatedMetadata leakage — no servers, no internet, no logs, no persistent message storage
• ✓ mitigatedIdentity spoofing — hardware-backed P-256 keys in Android Keystore TEE
• ✓ mitigatedCompromised server infrastructure — no servers exist in the architecture
• ✓ mitigatedPast message exposure after key compromise — Double Ratchet forward secrecy; message keys deleted after use
• ✓ mitigatedFuture message exposure after key compromise — DH ratchet provides break-in recovery
• ✓ mitigatedInput capture via keyboard — password-mode input suppresses autocorrect, autofill, and IME clipboard access
• ✓ mitigatedScreen capture — FLAG_SECURE blocks OS-level screenshots and screen recording

Threats Reduced

These cannot be fully eliminated, but blue_ghost significantly reduces their impact:

• ~ reducedRF triangulation — BLE low-power mode minimises detection radius
• ~ reducedDevice fingerprinting via BLE advertisement — minimal advertisement payload (service UUID + 5 bytes of data)
• ~ reducedTraffic analysis — uniform encrypted payloads with no length correlation to content
• ~ reducedSide-channel leakage — screenshot blocking, notification redaction, no keyboard data retention

Threats Not Mitigated

No secure system can defend against everything. blue_ghost does not protect against:

• ✗ openCompromised devices — rootkits, spyware, or keyloggers running on either device
• ✗ openPhysical access attacks — device seizure during an active unlocked session
• ✗ openShoulder surfing — visual eavesdropping of the screen
• ✗ openCoercion attacks — forced disclosure or device hand-over under duress
• ✗ openBroken Android TEE — malicious firmware or hardware-level key extraction
• ✗ openUnverified sessions — without Safety Number confirmation, MITM during handshake is theoretically possible