Aegis selbst betreiben

1 · Architektur-Überblick

Aegis besteht aus zwei bewusst getrennten Ebenen, die sich nur das App-Gehäuse teilen – nicht die Vertrauensgrenze.

Zwei Ebenen, zwei Vertrauensgrenzen

Datenfluss

Öffentlicher Pfad – vom Handy bis in die Datenbank kommt nur Chiffretext an:

VPN-Pfad – unverändert abgeschottet:

Die WebSocket-Verbindung der App läuft über denselben Edge: wss://<host>/v1/ws. Caddy erkennt das Upgrade selbst und tunnelt es an den Relay weiter; der Relay läuft mit --proxy-headers und sieht darum weiterhin X-Forwarded-Proto: https.

Komponenten

Repo-Aufbau

Protokoll in Kurzform

REST über HTTPS für Setup und Abholung, eine dauerhafte WebSocket-Verbindung für den Live-Kanal. Bis auf Registrierung und Restore verlangt jeder Aufruf Identity-Key-Auth: Der Client signiert eine Server-Nonce mit dem privaten Geräteschlüssel und schickt das Ergebnis im Header X-Aegis-Auth. Es gibt keine Passwörter.

Was der Server tatsächlich speichert, ist ein Envelope ohne jeden lesbaren Inhalt:

{ "to": "bob", "toDeviceId": 1,
  "type": "PREKEY | CIPHERTEXT | UNIDENTIFIED",
  "ciphertext": "<base64 libsignal-CiphertextMessage, gepolstert>" }

envelopeId und serverTs vergibt der Server. Im Sealed-Sender-Modus gibt es kein Absenderfeld – der Absender steckt authentifiziert im Chiffretext.

2 · Sicherheitsmodell

Kern-Annahme: Der Server ist nicht vertrauenswürdig. Betrachtet werden ein passiver Netz-Beobachter, ein aktiver MITM, ein vollständig übernommener Relay (Root, Live-Mitschnitt, Datenbank-Dump), Geräteverlust und der Versuch fremder Clients oder Server, unsere Nutzer zu erreichen.

Was der Server sieht – und was nicht

Schlüsselverwaltung

• Account-Identity-Key – die stabile Identität des Kontos. Aus ihr und der Identität des Gegenübers wird die Sicherheitsnummer berechnet.
• Geräteschlüssel – jedes Gerät hat ein eigenes Schlüsselpaar. Das zugehörige Gerätezertifikat ist eine Signatur des Account-Schlüssels über den Geräteschlüssel; der Relay prüft sie bei Registrierung und Geräte-Verknüpfung.
• Signed-Prekey, One-Time-Prekeys, Kyber-Prekeys – ermöglichen den Sessionaufbau, während der Empfänger offline ist. Ein Kyber-Prekey ist als last resort markiert und wird nie verbraucht, damit ein Gerät nie unerreichbar wird.
• Content-Key – pro Gerät ein Curve25519-Schlüsselpaar für die Inhalts-Schicht. Der öffentliche Teil liegt im Prekey-Bundle, der private ausschließlich im Android-Keystore mit erzwungener Nutzer-Authentifizierung (StrongBox/TEE, nicht exportierbar).
• Alle privaten Schlüssel und der Session-Zustand liegen ausschließlich in der SQLCipher-Datenbank des Geräts – nie im Klartext auf der Platte, nie auf dem Server.

Signaturen sind Curve25519/XEdDSA, wie libsignal sie erzeugt. Der Relay verifiziert sie, ohne je privates Material zu sehen – die Zero-Knowledge-Eigenschaft bleibt unberührt.

Zwei Schichten – warum die Benachrichtigung funktioniert

Trade-off, ehrlich benannt: Der Content-Key lebt länger als die Ratchet-Schlüssel. Abgefedert wird das durch einen eigenen, ephemeren Schlüssel pro Nachricht und durch Rotation des Content-Keys. Die Forward Secrecy des Transports bleibt davon unberührt – Schicht 1 ratcheted weiter.

Warum kein Fremder hereinkommt

1. Standardmäßig keine Föderation – im Auslieferungszustand existiert keine Server-zu-Server-Schnittstelle; ein fremder Server hat nichts, womit er sprechen könnte. Föderation ist opt-in und wird erst durch den Betreiber im Dashboard zugeschaltet, dann gegenseitig gepinnt und fail-closed (siehe Föderation).
2. Invite-gated – ohne gültigen, einmaligen Token wird kein Konto angelegt.
3. Identity-Key-Auth – jeder authentifizierte Aufruf verlangt eine Signatur mit einem Geräteschlüssel, den der Server bereits kennt. Unbekannte Schlüssel werden abgewiesen.
4. Rate-Limits und Lockout auf Registrierung, Prekey-Abruf, Versand und Backup-Download.

Ehrliche Grenzen

• Ein einzelner, authentifizierter Relay kann Metadaten nicht vollständig eliminieren. Solange ein Gerät seine Verbindung mit dem eigenen Konto authentifiziert, ist auf Verbindungsebene ein zeitliches Muster beobachtbar. Sealed Sender entkoppelt den Envelope-Inhalt, nicht die physische Verbindung.
• Ein in der App mitgeliefertes Client-Geheimnis ist grundsätzlich extrahierbar. Die echte Schließung sind der geschlossene Default, Invite-Zwang und Schlüssel-Auth – nicht das App-Geheimnis. Auch bei zugeschalteter Föderation bleibt der Inhalt Ende-zu-Ende verschlüsselt (Zero-Knowledge), und Peer-Relays werden gegenseitig gepinnt.
• Ein kompromittiertes Endgerät mit laufender Schadsoftware ist außerhalb des Modells: Dort liegt der Klartext ohnehin offen.
• Langfristige Traffic-Analyse auf Timing-Ebene wird minimiert, aber nicht ausgeschlossen.

Backup-Hinweise

Für Nutzer

Das Identitäts-Backup ist client-seitig mit einer Passphrase verschlüsselt (Argon2id als Schlüsselableitung, AES-256-GCM); der Server hält nur den opaken Blob samt Salt und KDF-Parametern. Ohne Passphrase gibt es keine Wiederherstellung – niemand kann sie zurücksetzen. Bis der Restore-Fluss in der App verdrahtet ist, gilt: Geht das Gerät verloren, sind Identität und Verlauf weg, und Kontakte müssen die neue Sicherheitsnummer bestätigen.

Für Betreiber

• PostgreSQL – Konten, öffentliche Schlüssel, Prekeys, wartende Envelopes: docker compose exec -T postgres pg_dump -U aegis aegis_relay | gzip > relay-$(date +%F).sql.gz
• Volumes – die opaken Backup-Blobs (backups) und der ACME-Zustand von Caddy (caddy_data: Konto und Zertifikate). Letzterer spart bei einem Umzug neue Ausstellungen.
• .env-Dateien gehören nie ins Repo, aber unbedingt in den Passwort-Manager – vor allem INVITE_SIGNING_SECRET, sonst werden ausgegebene Invites ungültig.
• Release-Keystore der App offline sichern: Ohne ihn gibt es für installierte Apps keinen Update-Pfad mehr, und der Fingerabdruck in assetlinks.json stimmt nicht mehr.
• Ein Server-Backup enthält keinen Nachrichtenklartext. Es rettet Konten und Zustellbarkeit, nicht den Gesprächsverlauf – der liegt ausschließlich auf den Geräten.

3 · Selbst hosten

Der komplette Chat-Stack besteht aus zwei Docker-Compose-Stacks, die sich ein Netz teilen. Der Controller-Teil ist optional und völlig unabhängig davon.

Föderation (opt-in, standardmäßig aus)

Voraussetzungen

• Server: ein kleiner Linux-Server mit Docker und Compose-Plugin. Debian 13 (trixie) ist die Referenz. Für einen Freundeskreis genügen 1–2 vCPU und 2 GB RAM; Speicherbedarf entsteht praktisch nur durch wartende Envelopes und Blobs.
• Domain: ein A-Record auf die öffentliche IP des Servers (DNS-only, kein Proxy davor – die ACME-Validierung muss den Server direkt erreichen).
• Ports: eingehend 443/tcp zwingend, 80/tcp für den HTTP-Redirect und die HTTP-01-Challenge. Bei Anbietern mit vorgelagerter Cloud-Firewall (z. B. IONOS) müssen die Ports zweimal geöffnet werden: im Anbieter-Panel und lokal in ufw.
• Android-Seite: zum eigenen Ausliefern der App JDK 17, Android SDK 34 und Gradle 8.7 sowie ein eigener Release-Keystore.

docker network create aegis-edge

DB_PASSWORD=<openssl rand -base64 36>
ADMIN_TOKEN=<openssl rand -base64 36>
INVITE_SIGNING_SECRET=<openssl rand -base64 36>

cd /opt/aegis/messenger
docker compose up -d --build
docker compose logs -f relay

cd /opt/aegis/edge
docker compose up -d
docker compose logs -f caddy      # ACME-Fortschritt beobachten

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

curl -s -X POST https://<host>/v1/invites \
  -H "X-Admin-Token: $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"count":1}'

https://<host>/i/<token>#u=<einladender>&aik=<dessen Identitätsschlüssel>

Zertifikat und Pinning

Die App kennt hier bewusst zwei Vertrauensregime, je nachdem, welcher Relay eingestellt ist:

• Öffentlicher Relay chat.personaplay.de (Standard): festes SPKI-Pinning, fest in die App gebaut. Gepinnt wird die stabile obere Kette (Let's-Encrypt-Intermediate und Root) samt Backup-Pin, nicht der bei jeder Erneuerung wechselnde Leaf – eine Leaf-Rotation sperrt also niemanden aus, ein fremdes gültiges Zertifikat kommt trotzdem nicht durch. Diese stärkste Absicherung bleibt unangetastet.
• Selbst eingetragener Relay: normale System-CA-Prüfung (das Let's-Encrypt-Zertifikat vom eigenen Edge wird gegen den Geräte-Trust-Store validiert) plus TOFU (Trust On First Use). Der beim ersten erfolgreichen Verbinden gesehene SPKI wird pro Host gespeichert; ändert er sich später unerwartet, wird die Verbindung blockiert und gewarnt. Das ist strikt stärker als reine CA-Prüfung – es fängt auch ein später mis-issued, aber gültiges Zertifikat einer anderen CA – und weicht den Standardpfad an keiner Stelle auf. Voraussetzung ist deshalb ein CA-gültiges Zertifikat; ein rein selbst-signiertes reicht für einen zur Laufzeit gewählten Relay nicht.

Aktuellen Leaf-Pin jederzeit selbst ziehen:

echo | openssl s_client -connect <host>:443 -servername <host> 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary | openssl enc -base64

Die App-Links-Verifikation nutzt ohnehin den System-Trust-Store; das Pinning betrifft nur die Relay-Verbindung und kann parallel bestehen. Wer einen eigenen App-Build mit eigenem Pin für den eigenen Relay ausliefern will, kann den festen Pin dort setzen; die Laufzeit-Option nutzt System-CA + TOFU.

Betrieb und Prüfen

• curl -s https://<host>/health – Lebenszeichen des Relays inklusive Datenbank-Prüfung.
• docker compose logs -f relay bzw. caddy – ACME-Ausstellung, Verbindungen, Rate-Limit-Treffer.
• Zustellung wird laufend geräumt: bestätigte Envelopes verschwinden sofort, unbestätigte nach 30 Tagen. Der Speicherbedarf bleibt dadurch von selbst klein.
• Zum Testen ohne zweite Person gibt es einen dauerhaft laufenden Echo-Testkontakt: Er nimmt Nachrichten an, entschlüsselt sie durch beide Schichten und antwortet verschlüsselt zurück. Er ist ausdrücklich eine Testeinrichtung – ein unbeaufsichtigter Prozess auf dem Server liest, was man ihm schickt. Der Relay bleibt davon unberührt zero-knowledge.

4 · Stand und Grenzen