Entrixy — Ende-zu-Ende-Verschlüsselung

• 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.

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

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.

Auf dem Gerät des Besitzers (EncryptedSharedPreferences)

Auf dem Server

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 erreicht den Server nie: Der Server kennt nur seinen Fingerabdruck, und das Telefon des Gastes beweist durch die Signatur seiner Anfragen, dass es den Schlüssel besitzt.
• 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.

Ein Objekt anlegen

1. Der Besitzer drückt „Hinzufügen“ — dabei entsteht K_obj.
2. Die Felder werden in JSON gepackt und verschlüsselt mit K_obj → data_cipher.
3. POST /api/number_add mit data_cipher plus dem Typ. Der Server gibt eine id zurück.
4. 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

1. Der Besitzer hat gewählt: [obj1, obj2, obj3]. Dabei entsteht K_guest.
2. Das Bundle-JSON wird zusammengesetzt: {obj_ids: [...], obj_keys: {1: K_obj1, ...}, welcome_cipher: ...}.
3. Verschlüsselt mit K_guest → bundle_cipher.
4. POST /api/key_create mit bundle_cipher, obj_ids (im Klartext — für die Zugriffsmatrix).
5. Der Schlüssel entsteht auf dem Telefon. Der Server erhält nur seinen Fingerabdruck und die öffentliche Hälfte des Signaturpaars.
6. 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

1. 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.
2. Der Client fordert an: POST /api/key_bundle.php mit einer vom Schlüssel signierten Anfrage → erhält bundle_cipher und die Liste der obj_ids.
3. Entschlüsselt das Bundle mit K_guest→ und erhält {obj_keys, welcome}.
4. K_guest und die entschlüsselten obj_keys werden gespeichert im EncryptedSharedPreferences des Gast-Clients.
5. Fortan bei jedem Aufruf: GET des verschlüsselten data_cipher des Objekts → Entschlüsselung mit dem lokalen obj_key_{id}.

Passing access on down a chain

A key carries delegate_depth — how many steps further it may travel. The holder of such a key issues nothing itself: it creates a one-time invitation (POST /api/key_delegate.php?a=create), and the key is born on the recipient's device.

1. The recipient's device generates its own user_key and a P-256 pair, and sends the public half with ?a=redeem.
2. The server creates a child key on the owner's object with parent_key_id, delegate_depth = parent − 1 and no bundle. Expiry and the app-only flag are inherited from the parent: nobody hands on more than they hold.
3. On its next sync the owner's device sees a key marked needs_bundle, builds the bundle with a fresh K_guest and seals that key to the recipient's public half (ECDH P-256 → HKDF-SHA256 → AES-256-GCM) → key_cipher.
4. The recipient fetches bundle_cipher und key_cipher, unseals K_guest with its private half and reads the bundle as any other guest.

Neither the server nor the person who passed the access on can read the child's bundle: the sealing key never leaves the recipient's device. The whole chain hangs off the owner — nobody re-encrypts anything on the way.

Einen Gastschlüssel widerrufen

Der Besitzer drückt „Löschen“ → POST /api/key_revoke.php → the server deletes the key record. On the next bundle request the guest is refused and loses access. Revocation is cascading: everything issued further down that key's chain goes with it, along with any invitations still waiting for a recipient.

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.

Losing K_master bedeutet den Verlust des Zugangs zu allen Objekten und Schlüsseln, daher erstellt die App eine Sicherung: eine Datei, verschlüsselt mit einem Passwort, das der Besitzer festlegt. Der Server ist daran nicht beteiligt: Er erstellt, speichert und liest die Datei nicht.

• Der Besitzer legt eine Passphrase von mindestens 8 Zeichen fest.
• KDF: PBKDF2-HMAC-SHA256, 600.000 Iterationen, ein zufälliges 16-Byte-Salt → ein 32-Byte-Schlüssel.
• Der Schlüssel verschlüsselt den Speicher der App mit AES-256-GCM: K_master, die Objekte und ihre Geheimnisse, die an Gäste ausgegebenen Schlüssel und die von anderen erhaltenen Schlüssel.
• Der Dateikopf — Formatversion, KDF, Iterationszahl, Salt und Nonce — geht als zugeordnete Daten in GCM ein, sodass sich weder das Salt noch die Iterationszahl ändern lassen, ohne die Entschlüsselung zu brechen.
• Der Besitzer speichert oder versendet die Datei, wohin er möchte. Wiederherstellung auf einem neuen Telefon: Datei wählen, Passwort eingeben, und der Speicher ist wieder da.
• Eine Sicherung zieht die Schlüssel um, statt sie zu vervielfältigen: Der Server führt pro Schlüssel ein aktives Gerät, und das neue Telefon tritt an die Stelle des alten.