Entrixy — E2EE-Architektur

Eine Zero-Knowledge-Architektur: Der Server besitzt Entschlüsselungsschlüssel für nichts als technische Kennungen. Jedes bedeutungstragende Feld — Rufnummern, Adressen, Koordinaten, Webhook-Geheimnisse, WLAN-BSSIDs, Begrüßungen — wird auf dem Gerät des Besitzers verschlüsselt und liegt auf dem Server als undurchsichtiger Blob. Der Entschlüsselungsschlüssel erreicht den Gast im Einladungslink, im Adressfragment, das der Browser nie an den Server sendet.

1. Ziele und Grenzen

Vertraulichkeit der Inhalte. Der Server kennt weder die Adresse der Schranke noch die Rufnummer, noch die Webhook-Adresse, die Koordinaten, die WLAN-BSSID oder den Begrüßungstext.
Überprüfbare Integrität. Jede Manipulation eines Blobs auf dem Server bricht die Entschlüsselung (AES-GCM), und der Client meldet beschädigte Daten.
Vorwärtskompatibilität der Schlüssel. Ein Gast erhält Zugang nur zu den Objekten, die ihm erteilt wurden. Die Kompromittierung eines Gastschlüssels verrät nichts über die anderen.
Die Grenze des Nullwissens. Der Server sieht sehr wohl, dass ein Schlüssel existiert, Aktivitätszeitstempel und Objektkennungen — er braucht sie zum Routing. Das Verbergen von Metadaten (Onion-Schemata) gehört nicht zum Umfang.

2. Kryptografisches Primitiv

Algorithm: AES-256-GCM. Auf der JVM ab Werk verfügbar (über javax.crypto), und vom Android Keystore unterstützt. Es liefert Vertraulichkeit und Authentifizierung zugleich.

Format des Chiffretexts

v1:<base64url(nonce || ciphertext || tag)>

v1: — ein Versionspräfix, um das Format später zu wechseln.
nonce — 12 zufällige Bytes, für jede Verschlüsselung neu.
ciphertext+tag — alles, was Cipher.doFinalzurückgibt; das 128-Bit-Tag ist enthalten.
base64url ohne Padding — sowohl in einer Adresse als auch in JSON sicher.

Entropiequelle

SecureRandom() (die des Systems). Auf Android ist das /dev/urandom + Linux-PRNG.

3. Schlüsselhierarchie

K_master — der Hauptschlüssel des Besitzers

32 zufällige Bytes, beim ersten Start erzeugt.
Gespeichert in EncryptedSharedPreferences unter dem Namen master_key und verlässt das Gerät nie im Klartext.
Wird ausschließlich zum Umschließen von K_obj zur lokalen Speicherung verwendet.

K_obj — der Objektschlüssel

32 zufällige Bytes, bei der Erstellung jedes Objekts erzeugt.
Lokal gespeichert als encrypt_k_master(K_obj) unter dem Schlüssel obj_key_{id}.
Er verschlüsselt das JSON aller sensiblen Felder des Objekts (data_cipher auf dem Server).
Rotation bedeutet ein neues K_obj_new → data_cipher und jedes Bundle, das ihn trug, neu verschlüsseln.

K_guest — der Schlüssel des Gast-Bundles

32 zufällige Bytes, bei der Ausstellung eines Gastschlüssels erzeugt.
Er verschlüsselt das bundle — ein kleines JSON {obj_id: K_obj} für die Objekte, die dem Gast erlaubt sind.
Auf den Server gelangt only bundle_cipher. Der K_guest selbst bekommt der Server nie zu sehen.
K_guest erreicht den Gast im Adressfragment: entrixy.com/key#<user_key><base64url(K_guest)> — ein einziger Block aus 75 Zeichen. Das Fragment geht mit der HTTP-Anfrage nicht an den Server — eine grundlegende Garantie des Browsers.

Changing K_guest ist nur durch Ausstellung eines neuen Links möglich. Genau darauf beruht der Widerruf: Der Server löscht den Schlüsseleintrag, und der Gast erhält keinen aktuellen bundle_cipher mehr.

4. Was wo gespeichert wird

Auf dem Gerät des Besitzers (EncryptedSharedPreferences)

Key	Wert
`master_key`	32 Bytes im Klartext (SharedPreferences verschlüsselt sie ohnehin).
`obj_key_{id}`	Der K_obj des Objekts, umschlossen mit K_master.
`obj_plain_{id}`	(optional) ein Cache des entschlüsselten JSON, damit die Oberfläche schnell zeichnet.

Auf dem Server

Tabelle / Feld	Inhalt
`numbers.data_cipher`	Mit K_obj verschlüsseltes JSON: `{phone, url, secret, geo_lat, geo_lon, share_lat, share_lon, snapshot, welcome, label}`.
`numbers.id / type`	Im Klartext — nötig für Routing und die Anzeige des Symboltyps.
`keys.bundle_cipher`	Mit K_guest verschlüsseltes JSON: `{obj_ids: [1,2,3], obj_keys: {1: K_obj1, 2: K_obj2, ...}, welcome_cipher: ..., ...}`.
`keys.user_key / mode / force_when_busy`	Im Klartext — für Routing und eine schnelle Zugriffsprüfung.

Die Begrüßung für den Gast wird separat im Bundle verschlüsselt, der Server sieht also auch sie nicht.

5. Format des Einladungslinks

https://entrixy.com/key#<user_key(32)><K_guest_base64url(43)>

Das Fragment ist ein Block aus 75 Zeichen: 32 Zeichen user_key und 43 Zeichen des Gastschlüssels.
user_key — die Kennung auf Serverseite. Ohne sie gibt der Server das Bundle nicht heraus.
Das Fragment (#...) landet nie im Serverprotokoll — das ist eine Garantie des Browsers.
Die Seite /key — schlichtes JS: sie liest location.hash, zerlegt den Block und übergibt den Schlüssel entweder der App oder der Webversion /app/. Der Server sieht den Schlüssel nie.
Ist die App nicht installiert, kopiert die Seite den Link in die Zwischenablage und schickt Sie zu /download/android, von wo die App den Schlüssel selbst aufnimmt.

6. Wichtigste Abläufe

Ein Objekt anlegen

Der Besitzer drückt „Hinzufügen“ — dabei entsteht K_obj.
Die Felder werden in JSON gepackt und verschlüsselt mit K_obj → data_cipher.
POST /api/number_add mit data_cipher plus dem Typ. Der Server gibt eine id zurück.
Lokal gespeichert wird: obj_key_{id} = encrypt_k_master(K_obj).

Ein Objekt aktualisieren

Das neue JSON lokal bauen, mit dem vorhandenen K_obj → POST /api/number_update. K_obj verschlüsseln, der sich nicht ändert.

Einen Gastschlüssel erstellen

Der Besitzer hat gewählt: [obj1, obj2, obj3]. Dabei entsteht K_guest.
Das Bundle-JSON wird zusammengesetzt: {obj_ids: [...], obj_keys: {1: K_obj1, ...}, welcome_cipher: ...}.
Verschlüsselt mit K_guest → bundle_cipher.
POST /api/key_create mit bundle_cipher, obj_ids (im Klartext — für die Zugriffsmatrix).
Der Server gibt zurück: user_key.
Dem Besitzer wird ein QR-Code mit dem Link angezeigt entrixy.com/key#{user_key}{base64url(K_guest)}.

Der Gast nimmt den Schlüssel an

Der Gast öffnet den QR-Code oder den Link. Die Seite /key reads location.hash und übergibt den Schlüssel der App oder der Webversion.
Der Client fordert an: POST /api/key_bundle.php mit user_key → erhält bundle_cipher und die Liste der obj_ids.
Entschlüsselt das Bundle mit K_guest→ und erhält {obj_keys, welcome}.
K_guest und die entschlüsselten obj_keys werden gespeichert im EncryptedSharedPreferences des Gast-Clients.
Fortan bei jedem Aufruf: GET des verschlüsselten data_cipher des Objekts → Entschlüsselung mit dem lokalen obj_key_{id}.

Einen Gastschlüssel widerrufen

Der Besitzer drückt „Löschen“ → POST /api/key_revoke.php → der Server löscht den Schlüsseleintrag. Beim nächsten Bundle-Abruf wird der Gast abgewiesen und verliert den Zugang.

Einen Objektschlüssel rotieren

Der Besitzer drückt in den Objekteinstellungen „Schlüssel neu erzeugen“. Dabei entsteht K_obj_new, und jeder bundle_cipher, der dieses Objekt enthält, wird neu verschlüsselt. Der Client kennt sie nicht auswendig, deshalb baut der Client des Besitzers die Bundles neu: Er holt den bundle_cipher jedes eigenen Schlüssels, entschlüsselt ihn, setzt K_obj_newein und verschlüsselt neu. Die neuen Blobs gehen in einem Schwung an den Server.

7. Sicherung und Wiederherstellung

Dieser Abschnitt beschreibt einen Plan, der noch nicht umgesetzt ist: Ein Export des Hauptschlüssels existiert in der App heute nicht.

Losing K_master bedeutet den Verlust des Zugangs zu allen Objekten und Schlüsseln, deshalb ist ein Export unerlässlich.

Der Besitzer legt eine passphrase fest (mindestens 8 Zeichen).
KDF: Argon2id (64 MB Speicher, 3 Iterationen, 1 Thread) → abgeleiteter 32-Byte-Schlüssel.
Der abgeleitete Schlüssel verschlüsselt K_master → es entsteht master_backup_blob.
Der Blob wird angezeigt als QR-Code und in „Downloads“ gespeichert. Er lässt sich ausdrucken und im Safe verwahren.
Wiederherstellung auf einem neuen Gerät: QR-Code scannen, Passphrase eingeben, K_master wird wiederhergestellt, und der Client lädt vorab alle obj_keys vom Server — sie liegen im Bundle der eigenen Schlüssel des Besitzers — und verschlüsselt sie lokal neu.

Ohne Passphrase ist der Sicherungs-QR-Code schlicht K_master, deshalb ist die Passphrase Pflicht.

8. Einführungsphasen

Phase 2 — Migration des Serverschemas (erledigt)

Alle sensiblen Felder sind umgezogen nach numbers.data_cipher und user_keys.bundle_cipher. Die alten Klartextspalten (phone, label, radius, time_*, geo_*, wifi_*, share_*, has_avatar, security_level, user_keys.label, hosts.label, pending_actions.phone, hosts.last_ip) wurden aus der Datenbank entfernt (Phase 7). webhook_url und webhook_secret bleiben NUR dann im Klartext, wenn webhook_mode='server' — ohne sie kann der Server die HTTP-Anfrage nicht senden. Bei webhook_mode='phone' werden sie verschlüsselt in data_cipher.

9. Risiken und Maßnahmen

Risk	Measure
Verlust von K_master	Ein verpflichtender Sicherungsablauf (Phase 5). Solange keine Kopie existiert, wird ein Warnhinweis gezeigt.
Kompromittierung des Besitzergeräts	Nicht vollständig vermeidbar: Der Zugang zur App ist durch PIN oder Biometrie geschützt, dazu EncryptedSharedPreferences und Android Keystore.
Die Rotation eines Objektschlüssels erfordert den Neuaufbau aller Bundles	Der Client des Besitzers nimmt alle bundle_cipher — lokal oder vom Server —, baut sie neu und sendet sie in einem Schwung. Eine seltene Operation.
Der Server manipuliert ein Bundle	Das AES-GCM-Tag passt nicht, und der Client meldet einen beschädigten Schlüssel.
Abfluss von K_guest über einen Screenshot des QR-Codes	Technisch nicht zu verhindern: Der Schlüssel steckt im Code selbst. Zeigen Sie den QR-Code nur einem Gast, dem Sie vertrauen.
Das Adressfragment bleibt im Browserverlauf	Die Seite `/key` ruft direkt nach dem Lesen des Hashs `history.replaceState(..., '#')`auf, was das Fragment löscht.

Entrixy — Ende-zu-Ende-Verschlüsselung