Security

Security model

Threat model in one paragraph

Your phone holds your User Master Key (UMK), wrapped by a key in its secure hardware (Secure Enclave on iPhone, hardware-backed Keystore on Android); while the app is unlocked it is held in the phone's memory. It never leaves the phone unwrapped. Derived keys do specific jobs: BAK gates server boot, IRK signs account-level operations like image-rebuild and revocation, and SWK is provisioned to the server so backup runs autonomously without keeping your phone awake. Peer hosts who store your backup shards only ever see opaque ciphertext. The flagshipserver.com control plane is a delivery channel and matchmaker; it never sees secrets in the clear.

What we promise

• All security-critical code (key derivation, signing, encryption, daemon, boot path, mobile clients) is public under BUSL-1.1, which becomes Apache 2.0 on 2030-05-03.
• The boot image is built reproducibly: you can verify the bytes match stock Debian.
• Standard primitives only: Ed25519, X25519, AES-256-GCM, HKDF-SHA-256, and since 0.3 ML-DSA-65 and ML-KEM-768 in hybrid with the classical ones. No homemade crypto.
• By default a server's encrypted disk opens only after your phone approves, over the network, at every boot, so a stolen server stays locked. Auto-unlock is an option you turn on per server: with it, the server starts by itself after a power cut, and so would a stolen one. If that happens, revoke the server in the app: it gets no unlock key at its next start and the relay stops serving its apps. You can also set a time limit, so a server stops its apps, or locks itself, when no admin has opened Flagship for 7 or 30 days.
• The auth domain (flagshipserver.com) is separate from the user-content domain (*.flagship.services) so user apps cannot reach session cookies via subdomain confusion.
• flagshipserver.com is physically unable to read user-content TLS: bytes are routed by SNI and decrypted only on your own server.
• No KYC, ever. We do not collect, store, or expose any real-world identity attribute about any user: no legal name, no email, no phone, no government ID. Read the full policy →

What 0.3 changed

For 0.3 we assumed parts of a server could be attacked, and made each part hold as little power as it needs. In plain terms:

• The server program no longer runs as root. It runs as an ordinary user. The few jobs that need root (power, containers, the firewall, installing a release) go through a small broker that accepts only a fixed list of typed requests and refuses and records everything else.
• Keys live apart from the server program. The server's identity key, its TLS key and its Let's Encrypt account key sit in a separate key service. The server program asks it to sign and never holds the keys. This is a software boundary on the same machine, not a hardware one.
• Your phone pins each server's own key at first contact. A new server proves it was built from your recipe with a one-time secret, and shows a six-digit code that your phone computes for itself from the server's key. After that, a server presenting a different key is refused.
• Sensitive actions need your admin key. On a server that knows its admin, updates, rank changes, journal reads, graphics-card approvals and similar orders are refused unless the admin device signed them. Every route of the server's control interface goes through one default-deny check.
• Signed install packages. Servers install and update from one release package signed by Flagship's maintainers, with a sequence number that only goes up and a minimum runtime version. No package manager, compiler or git checkout runs on your server to install or update it. A rollback only switches back to a release already on the disk.
• Boot. Each VM appliance makes its own disk key on first start and removes the shared factory key. The sealed copy of the disk key is addressed to a boot-only key, and where a server has a TPM the key that opens it is kept in the TPM. We make no measured-boot or attestation claims.
• Apps stay in their lane. Each app runs under gVisor and reaches only the internet hosts you approve. App database migrations run in a locked-down one-shot container. A restored backup's apps start with nobody on their access list until you approve it, and run only the exact image the backup recorded. An app that needs a graphics card waits for your signed approval.
• AI stays fenced. Every tool call an AI model makes goes through a broker that allows only what you granted, and everything your server shows a model is stripped of names, mail addresses, times, languages and network addresses. Local AI runs on the server with no internet.
• Recovery checks your passkey. flagshipserver.com releases a cloud-recovery record only after a valid signature from your passkey, and a new record is signed over all of its contents. A recovery set up before 0.3 gets this when you accept the apps' one-time "Update your account recovery" prompt.
• Quantum-safe groundwork. Servers and phones hold ML-DSA-65 keys bound to their Ed25519 keys, and a hybrid channel (X-Wing: ML-KEM-768 with X25519) is built, with an opt-in setting on iPhone and Android. Release signatures, install packages and new CA leases now carry a quantum-safe signature (ML-DSA-65) beside the classical one, and servers and apps refuse them without it. All of this is pending external review; it is not a claim that Flagship is quantum-safe today.
• Findings fixed. 0.3 was reviewed for security across the whole product, and its newest parts (voi.ci and Messages, certificates, the relay, updates and rescue over home Wi-Fi) were reviewed again before release. What the reviews found was fixed before release, and so was every finding of our own adversarial test suite, which now runs on every release. A few hardening items are partly done and continue in the next update. An external assessment has not been done yet.

What has not changed: TLS ends on your own server, so we can't read what your apps send. Our relay sees connection metadata: which server, when, and how much. An AI model never learns who or where you are.

Source code

The protocol, daemon, image-builder, and mobile clients live at github.com/ibisllc/flagship (link will be live when the repo is published). Audit it, build it, run it.

Coordinated disclosure & bounty

We pay for serious vulnerabilities in a defined scope and respond to reports under a published SLA. Coordinated disclosure is required: exploit details stay private until a fix ships.

Scope

Response targets

• Initial acknowledgement within 2 business days.
• Triage decision (in/out of scope, severity) within 7 days.
• Fix ship target by severity: critical within 7 days; high within 30; medium within 90; low best-effort, usually rolled into the next release.
• Public disclosure (reporter credit): coordinated with you, after the fix has shipped to all auto-update channels.

Bounty payouts

Status: pre-release, not yet fully funded. Flagship has not launched commercially and the bounty programme is not funded yet, so payouts are delayed until it is. The bands below are what we expect to pay once funding is in place; they are not a current offer. Until then we triage, fix, and credit reports under this policy, and we record every qualifying report as an outstanding obligation to be assessed against these bands at commercial launch. We would rather tell you this before you spend your time than after.

What that means in practice, until the programme is funded:

• We still triage and fix on the published SLA. Funding has no bearing on how fast a report gets dealt with. Every report listed in the hall of fame below was fixed and deployed within the SLA.
• Every qualifying report is recorded as an outstanding obligation, with the severity we assess it at, to be settled against the bands below at commercial launch.
• We assess severity ourselves and will rate upwards. If your own write-up is more conservative than the facts support, as the first report we received was, we record the higher severity, not the one you claimed.
• Credit is available immediately, in whatever form you ask for, and is not contingent on anything. It is the one thing we can give you now, so we would rather give it properly.
• No embargo once the fix has shipped. Write your findings up publicly whenever you like. Ask us first if you want a technical-accuracy review; we will not ask you to soften anything.
• If the delay causes you real hardship, tell us. We would rather hear it than have you discover our funding position afterwards and feel misled.

Final amount depends on impact, exploitability, the quality of the report, and whether you provided a working PoC. We reserve the right to award above the listed range for exceptional reports. Payouts are in USD via bank transfer or sent to a Bitcoin / Ethereum address you provide.

Safe harbor

Good-faith research conducted under this policy will not be subject to legal action by Flagship. You may probe production endpoints provided you don't:

• Access, modify, or delete other users' data beyond the minimum needed to demonstrate the issue. Use your own account.
• Use the issue to extract more than test-account data.
• Run automated scanners that generate sustained load.
• Publish details before the fix has shipped, or before our mutually agreed disclosure date (we aim for 90 days at most, negotiable for critical issues).

Hall of fame

Researchers who reported a vulnerability to us, and the commits that closed each report, are on the hall of fame.

Report a vulnerability

Use the form below (preferred: it asks for the right structured fields), or email security@flagshipserver.com. Encrypted reports are encouraged. Use our PGP key:

• Download the public key, or let your mail client find it for security@flagshipserver.com (published via Web Key Directory).
• Fingerprint: D96D 675D B03E 3F3B BC88  7030 2308 936D 2154 96D0

Please include:

• A clear description of the issue.
• The exact endpoint / file / commit hash affected.
• A working PoC (script, curl invocation, or screenshots).
• Your assessed impact and severity.
• Whether you'd like to be credited publicly (and under what name).