Security

Open systems live or die by their security model. This page documents MeshSky’s threat model, the mitigations baked into the protocol, and how to report a vulnerability.

Threat model

The mesh assumes a partially adversarial environment:

• Some peers may be malicious (forging observations, replaying messages, withholding data).
• Some peers may be negligent (mis-configured clocks, stale software).
• Some peers may be censored or partitioned from the rest of the network.
• The wire is untrusted: TLS/QUIC protects confidentiality, but compromise is assumed possible.

The mesh does not assume:

• That any single ControlTower is honest.
• That any directory or DNS provider is honest.
• That the network is connected at all times.

Mitigations

Cryptographic provenance

Every OBSERVATION carries an Ed25519 signature from its origin feeder. Every MLAT_SOLUTION carries a signature from its solving ControlTower. Every GOSSIP_FRAME carries a signature from its originating AirBridge.

Unsigned or signature-invalid messages MUST be dropped. Reference implementations enforce this at parse time.

Replay & freshness

Each signed message includes a ts_ns field. Receivers reject messages whose timestamps are more than:

• ±5 s in the future (clock skew tolerance), or
• older than the per-shard freshness window (default 30 s for observations, 5 minutes for solutions, 24 h for reputation rollups).

Sybil resistance

Reputation is slow to earn and fast to lose. New feeders enter at reputation 0. Reputation grows logarithmically with verified contributions and decays linearly with detected dishonesty. Sybil attacks therefore cost real time and real radio coverage to mount, and are detectable by the geographic-uniqueness check in the reputation rollup.

Geographic plausibility

Observations whose claimed origin location is geographically implausible for the signal received (e.g. a feeder in Tokyo claiming a 1090 MHz Mode-S reception from over Iceland) are flagged and excluded from MLAT solutions.

Defense in depth

• Capability negotiation at handshake limits what any peer can request.
• Bandwidth budgets prevent a malicious peer from drowning a relay.
• Quorum solving for high-confidence MLAT requires multiple independent ControlTowers to agree.
• Reputation gating on protocol-level rewards prevents grinding.

Disclosure policy

We follow coordinated disclosure:

• Email [email protected] (PGP key on the website).
• We acknowledge within 48 hours.
• We commit to a fix or mitigation within 30 days for high-severity issues.
• We publish a public advisory once a fix is shipped, crediting the reporter.

Please do not open a public GitHub issue for security vulnerabilities.

Audits

The reference implementations are audited annually by an independent firm. Reports are published in github.com/meshsky/audits once any flagged issues are resolved.