Threat modeling the LAN sync in my wildlife app (as a beginner)

Description and use

A secure LAN sync feature for Wildlife Incident Handoff was designed using AES‑256‑GCM, ECDH, and HKDF, providing protection against eavesdropping, impersonation, and replay attacks, though it lacks forward secrecy and relies on manual fingerprint comparison.

Problem

Designing a secure LAN sync feature for a wildlife incident recording app to prevent data leakage and impersonation.

Outcome

The LAN sync feature now encrypts data, authenticates devices, and protects against replay, impersonation, and eavesdropping, though it lacks forward secrecy and relies on manual fingerprint comparison.

Workflow

• Pair devices by exchanging a pairing code and approving the request on the first device.
• Generate a per‑device ECDH keypair and exchange public keys during pairing.
• Derive a shared AES‑256‑GCM key using HKDF from the ECDH secret.
• Encrypt incident records with the derived key and send over the local network.
• Include a monotonically increasing counter in each message and reject messages with old counters.
• Reject any sync requests from unpaired devices and only respond to a lightweight ping endpoint for discovery.
• When sync is disabled, reject all pairing and sync requests while keeping the listener open for discovery pings.

Evidence

Data is encrypted (AES-256-GCM) with a key both devices agree on (P-256 ECDH + HKDF)

Source

Each install has its own keypair and a fingerprint you can compare

Source

The first device has to manually approve every request

Source

Each message carries a counter, and old counters are rejected, even after a restart

Source

The sync endpoint rejects untrusted devices

Source

Pairing and sync requests are rejected when sync is disabled

Source