Security

Security Whitepaper

The Managed Sovereign Model — how Phone Stack proves trust instead of asking for it.

The Managed Sovereign Model

Core Philosophy

Most platforms hold the keys to your kingdom. We actively throw them away.

Most hosting platforms store your credentials, manage your access, and ask you to trust that no employee, breach, or rogue process will ever abuse that power.

Phone Stack takes a fundamentally different approach. We handle the billing and the hardware. But the authority — the cryptographic proof of who you are and what you're allowed to do — lives exclusively on your VPS and your device. We are the caretaker, not the landlord. If we disappear tomorrow, your server keeps running. If we get breached tonight, your data stays untouched.


The Core Promise: Don't Trust Us. Trust the Math.

Traditional platforms require you to trust a chain of people: the ops team, the support staff, the database admin, the vendor's vendor. Phone Stack replaces human trust with cryptographic guarantees wherever possible.

Chain of Trust

| What | Trust the Vendor | Trust the Math | |------|:---:|:---:| | Billing & Payments | ✓ | | | Initial Server Setup | ✓ | | | DNS Routing | ✓ | | | Your Identity | | ✓ WebAuthn + PoP | | Command Integrity | | ✓ HMAC SHA-256 | | Code Updates | | ✓ GPG Signatures | | Data Access | | ✓ Zero-Knowledge | | Command Execution | | ✓ Proof of Possession |

The left column is what every platform requires. The right column is what we moved out of our hands and into yours.


The Four Locks

Phone Stack's security architecture is built on four independent cryptographic guarantees. Each one eliminates an entire class of attack — not by making it harder, but by making it mathematically impossible.

1

Identity — WebAuthn + Proof of Possession

Tech

Non-extractable ECDSA keys in device secure enclave. PoP signatures over timestamp, method, path, body hash, and nonce.

Benefit

Phishing is impossible. Session hijacking is impossible. Even if our database is breached, your server cannot be accessed.

The Problem: Traditional platforms authenticate you with passwords or session tokens stored in their database. If that database is breached, an attacker can impersonate you.

Our Solution: Phone Stack's breach-safe modes use WebAuthn passkeys — the same technology behind Face ID and Touch ID. Your private key is generated inside your device's secure enclave and never leaves it.

Every sensitive operation (delete, rebuild, update, change security tier) requires a Proof of Possession signature: your device signs the request parameters using ECDSA. The VPS independently verifies this signature against the public key it stored during registration.

  • Phishing is impossible. WebAuthn is domain-bound — your passkey only works on the real Phone Stack domain.
  • Session hijacking is impossible. Stolen cookies are worthless without the hardware key.
  • A full platform breach cannot compromise your server. There is nothing in our database to steal.
2

Integrity — Deterministic Body Hashing

Tech

SHA-256 canonical body hash with recursive key sorting, embedded in PoP signature.

Benefit

The 'Bait and Switch' defense. It is mathematically impossible for anyone to modify your command between your browser and the server.

The Problem: Even with strong authentication, a man-in-the-middle (or a compromised platform) could alter the content of your request after you authenticate it. You confirm "restart my server" but the platform sends "delete my server."

Our Solution: Every sensitive request is bound to its payload using deterministic SHA-256 body hashing. The hash is computed over canonicalized JSON (recursively sorted keys) and embedded in the PoP signature. The VPS recomputes the hash independently — if a single parameter was changed by anyone, including us, the operation is rejected.

  • TOCTOU protection. Parameters cannot change between confirmation and execution.
  • Three-way integrity chain. During provisioning, the API hashes the cloud-init YAML, your browser independently computes the same hash, and the server verifies it on first boot. All three must agree.
3

Supply Chain — GPG-Verified Updates

Tech

Offline air-gapped GPG key. Fingerprint pinned as a build-time constant. Anti-rollback enforcement.

Benefit

We cannot push a backdoor to your server. Your VPS independently verifies every update against a public key that even we cannot change.

The Problem: If an attacker compromises a platform's CI/CD pipeline, they can push a backdoored update to every server — a single point of failure affecting all users simultaneously.

Our Solution: Your VPS independently verifies every update against a GPG signature created with an offline, air-gapped key. The verification happens on your server, not on our infrastructure.

| Check | What It Prevents | |-------|-----------------| | GPG Signature Verification | Unsigned or tampered releases | | Fingerprint Pinning | Swapped GPG keyring (even by root attacker) | | Anti-Rollback | Downgrade to vulnerable older versions | | Tag Format Validation | Path traversal or injection via tag names |

Circular Dependency Defense

The GPG fingerprint is a build-time constant embedded in the daemon binary. An attacker would need to both compromise the GPG key and push a fraudulent GPG-signed update to change it — a circular dependency that makes the attack infeasible.

4

Isolation — SSH-Only Dark Mode

Tech

Port cloaking via dual-layer firewall. Process-level kill of web services. Capabilities stripping.

Benefit

Turn the lights off. When you enable SSH-Only, the web dashboard becomes cryptographically dead. Your server disappears from scanners.

The Problem: Every open port is an attack surface. Web dashboards, APIs, and management interfaces all present opportunities for exploitation — especially when the platform itself could be compromised.

Our Solution: SSH-Only mode doesn't just hide the web interface — it cryptographically kills it:

1

Process termination

The web terminal process (ttyd) is stopped at the OS level.

2

Capabilities stripped

The capabilities endpoint returns an empty object. There is nothing to discover.

3

Hard rejection

A global middleware gate returns 403 for all web-initiated operations.

4

Dual-layer firewall

External cloud firewall (Hetzner/DO API) + internal UFW. Both must agree to open a port. Compromising one layer is still blocked by the other.


The "Bus Factor" — What If Phone Stack Disappears?

This is the question every developer should ask their hosting provider. Most can't give you a good answer. Here's ours.

Break Glass Protocol

Your server is a standard Linux VPS on Hetzner or DigitalOcean. Phone Stack is a management layer on top — not a proprietary container, not a locked-down image, not a walled garden.

If Phone Stack goes offline — whether from an outage, a shutdown, or the heat death of the universe:

1

Your server keeps running

All your applications, data, and configurations continue to operate. Nothing depends on our API for runtime functionality.

2

The daemon enters fail-safe mode

After 5 consecutive missed heartbeats (25 seconds), the State Enforcer enters Emergency Lockdown — closing external access as a precaution while the daemon stays alive and polls for recovery.

3

You SSH in and take over

Disable the agent, open SSH permanently, and your server is a standard Linux VPS. All your data, apps, and configs are intact.

4

Keep your server forever

Transfer billing to your own cloud provider account. Phone Stack is fully out of the picture.

# The full takeover — five minutes of work
sudo systemctl stop phonestack-enforcer
sudo systemctl disable phonestack-enforcer
sudo ufw allow 22/tcp
# Done. Standard Linux VPS.

We lock ourselves out, not you.

There is no kill switch, no remote wipe, no dead man's trigger. The worst case scenario for Phone Stack going away is five minutes of terminal commands.


Identity Pinning — The Anti-Takeover Defense

During initial provisioning, your user ID is written to an immutable lockfile on the VPS:

/etc/phonestack/owner.lock    (chmod 400, chattr +i)

The chattr +i flag makes this file immutable at the filesystem level — not even root can modify or delete it without first removing the flag.

Every heartbeat (every 30 seconds), the State Enforcer checks whether the user ID reported by the API matches this lockfile.

Attack scenario: database takeover

An attacker compromises the database and runs UPDATE servers SET userId='hacker'. The next heartbeat detects the mismatch against owner.lock. Soft Lockdown activates instantly: JWT secret deleted, terminal killed, SSH closed. The attacker cannot issue commands despite "owning" the database record. When the database is corrected, the enforcer auto-recovers — no manual intervention, no support ticket.


Compliance & Privacy

Data Residency

Phone Stack supports strict region selection with EU-compliant datacenters:

| Region | Provider | Location | EU Residency | |--------|----------|----------|:-:| | eu-central | Hetzner | Nuremberg, DE | Yes | | eu-north | Hetzner | Helsinki, FI | Yes | | eu-central (overflow) | DigitalOcean | Frankfurt, DE | Yes | | eu-north (overflow) | DigitalOcean | Amsterdam, NL | Yes | | us-east | Hetzner / DO | Ashburn / NYC | — | | us-west | Hetzner / DO | Hillsboro / SFO | — | | asia-pacific | Hetzner / DO | Singapore | — |

EU-region servers are provisioned exclusively in EU datacenters. Your data stays in the jurisdiction you choose.

Abuse Prevention — The Liability Straitjacket

Blocked by default on every VPS

SMTP (25, 465, 587) — prevents spam relay. Mining pools (3333, 5555, 7777, 8888, 9999, 14433, 14444, 45560) — prevents cryptojacking. Outbound SYN flood — rate-limited to 100/s, preventing DDoS participation.

A clean IP means your legitimate services work reliably. Platforms that don't enforce these rules end up on blocklists — and so do you.

Encryption at Rest

All secrets stored in the Phone Stack database are encrypted with AES-256-GCM before storage. Initialization vectors are unique per record. Auth tags prevent tampering. Token hashes use SHA-256 with timing-safe comparison to prevent length oracle attacks.


The Audit Trail

Every security-relevant action is recorded with structured audit events. The system tracks 52 distinct event types across five categories:

| Category | Example Events | |----------|---------------| | Authentication | Login, logout, failed auth attempts | | Server Operations | Create, delete, rebuild, rollback | | Security Changes | Tier changes, passkey registration, SSH key management | | Anomaly Detection | Replay attempts, conflicting transitions, oversized requests | | System Events | Lockdown triggers, recovery events, heartbeat failures |

Sensitive data (keys, tokens, credentials) is automatically redacted before logging. All sensitive requests include a one-time nonce with a 5-minute TTL, scoped per-server to prevent cross-server replay.

Hostile Red Team Audit

The system has been subjected to adversarial testing covering four domains:

| Audit Domain | What Was Tested | |-------------|----------------| | Data Sovereignty | Can the platform access user data? Can a database breach expose server contents? | | Credential Isolation | Do breach-safe tiers remain safe under full platform compromise? | | Localhost Bypass Prevention | Can internal services be reached by circumventing authentication layers? | | Ghost Port Detection | Do disabled services leave residual open ports or listening sockets? |


Phone Stack vs. Traditional Platforms

Traditional PaaSStandard VPSPhone Stack
Who holds the keys?The platformYou (manage everything)You (we manage the rest)
Platform breach = your breach?YesN/ANo (breach-safe modes)
Can the vendor read your data?Usually yesN/ANo
Can the vendor push code?YesN/ANo (GPG verification)
Survive vendor shutdown?No (proprietary runtime)YesYes (standard Linux VPS)
Command integrity?NoN/AYes (HMAC body hashing)
Phishing-resistant auth?RarelyN/AYes (WebAuthn)
Setup complexityLowHighLow

FAQ for Skeptics

You say you can't access my server. How do I know that's true?+

Because there's no mechanism to. In SSH-Only mode, the only way in is with an SSH private key that was never transmitted to us. In Web Locked mode, the only way is with a WebAuthn passkey whose private component lives in your device's secure enclave. We don't have a backdoor, an admin override, or an emergency access protocol. We architecturally cannot build one without breaking the GPG-signed update chain.

What if I lose my SSH key or my passkey device?+

In SSH-Only mode, you need your SSH key. In Web Locked mode, you need your registered device. If you lose both, you can access the underlying Hetzner or DigitalOcean VPS through the provider's emergency console. We intentionally do not offer a recovery path — because any recovery path we offer is a recovery path an attacker can exploit.

What stops a rogue Phone Stack employee from pushing a malicious update?+

GPG verification. Every update must be signed with an offline, air-gapped GPG key. The VPS verifies the signature and checks the fingerprint against a build-time constant. A rogue employee with full access to our infrastructure still cannot sign a release, because the signing key has never touched a networked machine.

How is this different from just renting a VPS myself?+

Three things: automated provisioning (your server is ready in minutes, not hours), managed security defaults (firewall rules, abuse prevention, hardened configs), and the tiered security model (WebAuthn, PoP signatures, body hashing) that would take significant engineering effort to implement yourself. You get self-managed sovereignty without the self-managed overhead.

What data do you actually store about me?+

Your account info (email, OAuth tokens for login), server metadata (IP, region, plan, security tier), and encrypted secrets (SSH public keys, API tokens). We do not store: your server's contents, your terminal history, your application data, your SSH private keys, or your WebAuthn private keys.

Can you read my terminal sessions?+

In Standard mode, terminal traffic is proxied through our API — so theoretically, yes. This is one reason we offer SSH-Only and Web Locked modes: terminal access either bypasses us entirely (SSH) or is end-to-end authenticated with passkeys stored on the VPS. If terminal privacy matters, upgrade to a breach-safe tier.

What happens to my data if I delete my account?+

Server deletion is handled at the cloud provider level. The VPS and all its data are destroyed. Your account data is deleted from our database. If you want to keep your server, disable the Phone Stack agent via SSH and transfer billing to your own provider account before deleting.

Has this been independently audited?+

The system has undergone internal adversarial testing (hostile red team audit) covering data sovereignty, credential isolation, localhost bypass prevention, and ghost port detection. We publish our security architecture transparently so you can audit the design yourself.