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

Description and use

The developer implemented a LAN sync feature using ECDH, HKDF, and AES‑256‑GCM, adding manual pairing and counter‑based replay protection, yet noted gaps in forward secrecy and human verification.

Problem

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

Outcome

The LAN sync feature now encrypts data, uses per‑install keypairs, and requires manual pairing approval, reducing the risk of data leakage and impersonation. However, gaps remain in forward secrecy, human verification, and comprehensive testing.

Workflow

• 1. Generate a unique keypair per install. 2. Exchange a pairing code and manually approve pairing requests. 3. Perform P‑256 ECDH to derive a shared secret. 4. Derive an AES‑256‑GCM encryption key using HKDF. 5. Encrypt incident records with the derived key before transmission. 6. Include a counter in each message to prevent replay. 7. Reject requests from unpaired devices and from devices when sync is disabled. 8. Provide a fingerprint for manual verification to mitigate impersonation.

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