Skip to content
C3Control / Continuity
Sync documentation
C3Sync

C3Sync / Security

Updated 2026-07-24 · C3Sync security-model.md

Security model

Trust boundaries

The hub is untrusted for confidentiality. Transcript events, file packs, and restore anchors are sealed with XChaCha20-Poly1305 under per-project content keys derived from a tenant secret held by enrolled devices.

The hub can observe routing hashes, sizes, timing, and activity patterns. End-to-end encryption does not hide traffic analysis.

Enrolled peers are fully trusted. Every enrolled device can read and write the tenant's synchronized projects; there is no per-project or read-only tier.

Transport and enrollment

  • TLS uses certificate pinning with no insecure fallback.
  • NATS uses per-device credentials minted from the account trust chain.
  • New devices use a balanced P-256 PAKE with an online enrolled responder, rate-limited against guessing.
  • Enrollment is a two-round key-confirmation exchange: the joining device must prove knowledge of the passphrase before anything is minted or recorded. A wrong passphrase leaves no orphaned credentials and no registry entry.
  • Devices enroll under their machine hostname, so c3sync devices shows recognizable names rather than raw keys.
  • The passphrase never travels to the hub, but anyone with the passphrase and hub reachability can enroll while a responder is online. Rotate it with c3sync rekey if it may have leaked.

One hub, isolated accounts

The hub created by c3sync hub init carries two isolated NATS accounts: C3_SYNC (this product's durable encrypted sync data) and C3_CONTROL (ephemeral control traffic for C3 Mobile phones and C3 Bridge hosts). Control credentials cannot subscribe to sync subjects — a phone or bridge, even a compromised one, can never read synchronized project data. Both accounts chain to the same CA pin.

Secrets at rest

Secrets use the OS keyring where available. Headless systems can use the encrypted-file backend, which refuses to operate without an explicit password.

Key rotation and device revocation

Two distinct ceremonies:

Rekey — rotate secrets without expelling anyone:

sh
c3sync rekey

Rotates the tenant secret and enrollment passphrase and bumps the key epoch. Use it after testing with a throwaway passphrase or on suspicion the passphrase leaked. Retired epoch secrets are kept so existing history stays readable.

Revoke — the full lost-device ceremony:

sh
c3sync devices
c3sync revoke <user-pub>

Revocation cuts the device's transport credentials at the hub, rotates the tenant secret and enrollment passphrase, and requires surviving devices to enroll into the new epoch.

Revocation cannot erase content already received by the lost device. Treat all previously synchronized material as disclosed.

Hub certificate lifecycle

c3sync hub tls renew-leaf rotates the serving certificate under the same CA — the pin every device verifies is unchanged, so nothing re-enrolls. c3sync hub tls rotate-ca is the compromise-response ceremony that replaces trust entirely. Back up hub administration with c3sync hub backup after either.