Ende-zu-Ende-Verschlüsselung
in Revier3D.

1. Zusammenfassung

Revier3D verschlüsselt alle Jagddaten clientseitig, bevor sie den Server erreichen. Der Server ist ein dummer, verschlüsselter Speicher: er sieht nur Chiffretext und kann ihn nicht entschlüsseln. Er weiß nicht, wo deine Grenze liegt, und nicht, was du erlegt hast.

Jedes Revier, das über den Einrichtungsassistenten entsteht, ist ab der Anlage-Sekunde versiegelt: Schlüsselmaterial und Revierzeile entstehen in einem einzigen Schreibvorgang, es gibt also kein Fenster „Revier existiert schon, Schlüssel noch nicht". Das Revier-Passwort ist dort Pflicht, und es ist zugleich das Verschlüsselungspasswort; der Server verweigert es, daneben ein abweichendes zweites zu etablieren.

Architektur: Row-Level-Verschlüsselung statt einer _enc-Spalte je Feld. Jede Zeile wird als ein verschlüsselter JSON-Blob (data_enc) gespeichert. Im Klartext bleiben nur die Spalten, die der Server für Sync, Mandantentrennung und Fremdschlüssel braucht: id, revier_id, die *_id-Bezüge, created_at, updated_at, deleted_at, created_by. Alle Inhalte (Koordinaten, Wildart, Datum, Name, Notiz und so weiter) liegen im Blob.

Der Revier-Schlüssel (RK) wird einmalig beim Anlegen als 256-Bit-Zufall erzeugt und nicht aus dem Passwort abgeleitet, sondern mit einem aus dem Passwort erzeugten Schlüssel (KEK) verpackt. Das ist die Voraussetzung dafür, dass ein Passwortwechsel die Daten nicht unlesbar macht. Der Wechsel selbst ist noch nicht gebaut und wird derzeit mit 409 abgewiesen, siehe Abschnitt 7.

Was der Server am Ende noch weiß: Account-E-Mail (Login), Paddle-Zahlungsdaten (Billing), Revier-Slug (URL), Revier-Status (Zugangskontrolle), Mitgliedschaften (wer mit welcher Rolle), Speichermenge (Quota). Keine Jagddaten, nicht einmal die Position. 3D-Gelände, Luftbild-Vorrat und Grenzdatei folgen einem zweiten Weg (Abschnitt 5.3), weil sie auf dem Server entstehen und nicht auf dem Gerät.

Es gibt keinen Betreiber-Notschlüssel und keine Hintertür, auch nicht während der Beta. In der Datenbank existiert keine Spalte für eine zweite, betreibereigene Verpackung des RK; sie war geplant und wurde am 09.08.2026 ausdrücklich verworfen (Abschnitt 6).

2. Bedrohungsmodell

2.1 Was wir abwehren

• Server-Kompromittierung. Vollständiger Dateisystem- und Datenbankzugriff, inklusive Live-Daten und Backups. Folge für verschlüsselte Daten: Angreifer sieht nur Chiffretext.
• Backup-Diebstahl. Wochen-Tars, GPG-verschlüsselte DB-Dumps, Offsite-Tower-Spiegel, R2. Foto-Spiegel liegen unverschlüsselt am Offsite-Standort; E2EE macht sie wertlos.
• Behördliche Auskunftspflicht. Revier3D kann herausgeben, was es hat. Was es hat, ist Chiffretext.
• Insider-Bedrohung. Betreiber-Mitarbeiter und Hosting-Provider (netcup) haben vollen Systemzugriff. Sie sehen nur Chiffretext.
• Netzwerk-Mitm. TLS plus clientseitige Verschlüsselung, Defense in Depth.

2.2 Was wir nicht abwehren

• Client-Kompromittierung. Malware auf dem Endgerät sieht den Klartext und den Schlüssel im Speicher. E2EE schützt nicht vor Malware.
• Fremder Code auf unserer eigenen Herkunft. Der Revier-Schlüssel liegt als rohe Bytes in der IndexedDB des Browsers, damit er einen Neustart überlebt und man am Hochstand nicht tippen muss. Jedes Skript, das auf revier3d.at läuft, könnte ihn damit lesen. Das ist der Preis dieser Entscheidung und wird hier nicht weggeredet: Ein per WebCrypto nicht auslesbarer Schlüssel wäre an dieser Stelle besser, verlangt aber Verfahren, die WebCrypto anbietet, und XChaCha20 gehört nicht dazu (Abschnitt 3.2). Dagegen steht die Content-Security-Policy, nicht die Krypto.
• Endgerät-Diebstahl ohne Gerätesperre. Wer das entsperrte Handy hat, hat die Daten. Gerätverschlüsselung und Bildschirmsperre sind die Verantwortung der Nutzung.
• Gewaltsame Erpressung. „Gib mir dein Passwort" ist kein Krypto-Problem.
• Metadaten-Analyse. Zeitpunkt, Größe und Häufigkeit von Schreibvorgängen sind sichtbar. Das ist eine bewusste Grenze.

3. Kryptographische Wahlbegründungen

3.1 Argon2id (Schlüssel-Hüllfunktion, KEK, und der Anmelde-Beweis)

Das Passwort verlässt den Client nicht mehr. Bis zur Verschlüsselung ging es bei /api/login/shared im Klartext an den Server, der damit selbst den KEK hätte ableiten und rk_wrapped auspacken können. Deshalb liefert ein einziger Argon2id-Lauf 64 Byte, die HKDF-SHA256 mit verschiedenen Etiketten in zwei Schlüssel spaltet: KEK bleibt im Gerät und packt den RK aus, AUTH geht zum Server, der davon nur einen Passwort-Hash hält. Aus AUTH lässt sich KEK nicht zurückrechnen. Ein zweiter Argon2id-Lauf wäre eine zweite Sekunde Wartezeit am Handy ohne Sicherheitsgewinn.

Warum nicht PBKDF2 oder scrypt? PBKDF2 ist GPU- und ASIC-freundlich und damit für passwortbasierte Schlüssel heute unterlegen. scrypt ist eine starke Alternative, Argon2id ist jedoch der Gewinner der Password Hashing Competition 2015 und hat eine breitere Bibliotheksunterstützung. Der hybride Modus (id) schützt sowohl gegen Seitenkanäle (vorne memory-hard) als auch gegen GPU-Cracking (hinten time-hard).

Bewusst speicherhungrig. 64 MiB je Versuch machen Massen-Cracking auf GPUs unrentabel. Auf dem Endgerät eines Nutzers sind 64 MiB eine vernachlässigbare Last, für einen Angreifer mit Millionen Versuchen eine mengenbegrenzende Barriere. Serverseitig kommt eine schlichte Bremse dazu: zehn Versuche je Verbindung in zehn Minuten, danach 429.

3.2 XChaCha20-Poly1305 (Datenverschlüsselung)

Warum XChaCha20 und nicht AES-256-GCM (NIST SP 800-38D)? Der 192-Bit-Nonce erlaubt zufällige Nonces ohne Buchhaltung. Bei AES-GCM sind es 96 Bit, und ein Zähler müsste über alle Geräte hinweg eindeutig bleiben: Vier Freunde, die dasselbe Revier offline bearbeiten und später nachsenden, bekommen das nicht sicher hin, und eine Nonce-Wiederholung kostet bei GCM nicht nur die Vertraulichkeit der beiden Nachrichten, sondern den Authentisierungsschlüssel. Dazu kommt: ChaCha20 ist reine Ganzzahl-Arithmetik, braucht kein AES-NI, ist auf dem fünf Jahre alten Android im Revier schneller als AES und hat keine Tabellen-Seitenkanäle.

Der Preis dieser Wahl steht in Abschnitt 2.2: WebCrypto kennt XChaCha20 nicht, also entfällt der nicht auslesbare Schlüssel-Handle, den crypto.subtle für AES-GCM anbieten würde. Wir halten die Nonce-Sicherheit über Gerätegrenzen hinweg für das schwerere Argument, benennen den Verlust aber, statt ihn zu verschweigen.

Wozu der Pflicht-Kontext gut ist. Das Datenmodell ist Row-Level: eine ganze Zeile liegt als ein Blob in data_enc. Ohne mitauthentisierten Kontext könnte, wer die Datenbank hat, Blobs vertauschen, den Blob von Marker 7 nach Marker 9 schreiben oder eine Zeile aus strecke nach ansitz, und der Client entschlüsselte sie klaglos: Die Verschlüsselung wäre intakt und die Daten trotzdem falsch. Was der Kontext nicht abwehrt, ist das Weglassen oder Doppeln ganzer Zeilen und das Zurückspielen eines älteren Blobs derselben Zeile. Dagegen hilft erst ein Versionsvektor, und der ist nicht gebaut.

3.3 X25519 (asymmetrisch: versiegeln können, ohne öffnen zu können)

Was das nicht leistet: Es ist keine Absender-Authentisierung. Wer den öffentlichen Schlüssel des Reviers hat, und der liegt offen, kann etwas hineinlegen. Für den Kamera-Eingang ist genau das die Anforderung, denn der Server soll es können. Wer Herkunft beweisen muss, braucht eine Signatur.

Warum X25519 und nicht ECDH P-256? P-256 (FIPS 186-4) wäre der Weg gewesen, um über crypto.subtle einen nicht auslesbaren privaten Schlüssel zu bekommen. Nachdem die symmetrische Seite (Abschnitt 3.2) diesen Vorteil ohnehin nicht nutzen kann, wiegt er hier nicht mehr auf: Curve25519 hat die einfacheren Implementierungen, keine Parameterwahl, die man falsch treffen kann, und die kürzeren Schlüssel. Beide Seiten, Browser und Python-Server, benutzen dieselbe Bauform.

3.4 HKDF (Schlüsseltrennung)

4. Schlüsselhierarchie

# Einmalig beim Anlegen des Reviers erzeugt, im selben Schreibvorgang wie die
# Revierzeile (kein Fenster "Revier da, Schlüssel noch nicht"):
RK  = random(256 bit)            # Revier-Schlüssel, EINMAL erzeugt, danach konstant

# Ein Argon2id-Lauf, zwei Schlüssel. Das Passwort selbst geht nirgends hin.
roh  = Argon2id(revier_passwort, revier.kek_salt, m=64 MiB, t=3, p=4)   # 64 Byte
KEK  = HKDF(roh, info="kek")     # bleibt im Gerät
AUTH = HKDF(roh, info="auth")    # geht zum Server, der nur hash(AUTH) hält

# Verpackung 1: Revier-Passwort (vier Freunde teilen Link + Passwort)
revier.rk_wrapped = XChaCha20-Poly1305(Enc, RK, KEK)

# Verpackung 2 (optional): je Konto, mit dessen öffentlichem Schlüssel
membership.wrapped_rk = X25519-Seal(RK, konto_pubkey)

# Verpackung 3 (optional): 12 Wiederherstellungs-Wörter, BIP39-Konstruktion
woerter          = 12 aus 2048   # 128 Bit Zufall + 4 Bit Prüfsumme
recovery_enc     = Enc(RK,     schluessel_aus_woertern)   # Weg zurück zum RK
recovery_woerter_enc = Enc(woerter, RK)                   # Weg zu den Wörtern

# KEIN Betreiber-Notschlüssel. Keine Hintertür. Die Zusage gilt ab Tag 1,
# und die Spalte dafür existiert im Schema nicht.

# Daten-Verschlüsselung (je Zeile, Row-Level):
aad    = "revier3d.e2ee.v1|" + revier + "|" + tabelle + "|" + zeile + "|" + gen
huelle = 0x01 || nonce(192 bit, zufällig) || XChaCha20-Poly1305(Enc, zeile_json, RK, aad)

# Server-Eingang ohne offenen Client (Kamera, Bau-Artefakte):
huelle = X25519-Seal(datei, revier.pubkey)   # hineinlegen ja, öffnen nein

Die Trennung zwischen RK (konstant) und KEK (aus dem Passwort) löst das Hauptproblem einer ableitungsbasierten Architektur: Ein Passwortwechsel muss keine Daten kosten. Er bedeutet nur, dass die eine Verpackung rk_wrapped neu erzeugt wird, eine kleine Blob-Operation, und die verschlüsselten Daten bleiben unberührt. Gebaut ist dieser Wechsel noch nicht: Weil Revier-Passwort und Verschlüsselungspasswort dasselbe sind, muss er beides atomar umstellen, und bis dahin weist der Server einen Wechsel am verschlüsselten Revier mit 409 und einem Hinweistext ab, statt still den Zugang vom Schlüssel zu trennen.

rk_version trägt die Schlüsselgeneration und fährt im Kontext jeder Zeile mit. Sie steht heute überall auf 1: Einen Wechsel des RK mit anschließender Umschlüsselung des Bestands gibt es noch nicht. Erst er würde einen alten, eventuell abgeflossenen RK wertlos machen.

5. Protokoll-Details

5.1 Schema

Verschlüsselt werden 26 Fachtabellen, darunter marker, foto, strecke, ansitz, wartung, schaden, belegung, buchung, sketch und sketch_stroke, kontrolle, nachsuche, fuetterung_log, zone, line, cam_bild. Jede davon bekommt eine Spalte:

• data_enc: die ganze Zeile als ein verschlüsseltes JSON-Paket. Die bisherigen Fachspalten bleiben bestehen und tragen im versiegelten Revier neutrale Platzhalter (Koordinaten 0/0, Daten 1970-01-01, Beträge 0), damit Fremdschlüssel, Indizes und Prüfregeln der Datenbank weiter greifen.

Im Klartext bleiben pro Zeile: id, revier_id, alle *_id-Bezüge, die Zeitstempel created_at / updated_at / deleted_at, created_by und einige Ordnungswerte, die der Server prüfen muss (Belegnummer und Belegjahr der Buchhaltung wegen des lückenlosen Nummernkreises nach § 131 BAO, Dateigröße und Dateityp der Fotos wegen des Speicherkontingents, Zeitstempel und Kamera-Kennung der Kamerabilder).

Am Revier selbst: kek_salt (128 Bit), kek_params, rk_wrapped, rk_version, pubkey (X25519, öffentlich), revier_priv_enc (privater Teil, mit RK verschlüsselt), recovery_enc und recovery_woerter_enc, e2ee_aktiv. Je Mitgliedschaft: wrapped_rk.

⚠️ Die Tabelle revier ist selbst keine zeilenverschlüsselte Tabelle. Sie hat kein data_enc, steht in keinem Räumfragment und wird von finalize nur mit SET e2ee_aktiv=TRUE berührt. Ihre fachlichen Spalten bleiben deshalb dauerhaft Klartext, darunter name, bundesland und land. Die vollständige Aufzählung samt Folgen steht in 5.3.

5.2 Foto- und Kachel-Auslieferung

Die Route /foto/<id> liefert im versiegelten Revier Chiffretext aus, mit einem Kopfzeilen-Vermerk, welche der beiden Siegelarten anliegt. Ein Service Worker (sw.js) fängt die Anfrage ab, entschlüsselt clientseitig und liefert eine gewöhnliche Antwort zurück. Damit bleibt <img src="/foto/…"> im HTML unverändert, und Lazy-Loading, Caching und Speicherverwaltung des Browsers funktionieren weiter. Derselbe Worker rechnet im versiegelten Revier auch die Höhenkacheln der 2D-Schummerung aus der entschlüsselten Höhenkarte, weil der Server dafür weder eine fremde Quelle fragen noch die eigene Datei lesen darf.

5.3 Karten-Dateien und der Kachel-Riegel

Grenze, Geländemodell und Luftbild-Vorrat entstehen beim 3D-Bau auf dem Server, aus den amtlichen Quellen. Sie können deshalb nicht am Gerät verschlüsselt werden; der Server versiegelt sie selbst mit dem öffentlichen Revier-Schlüssel (3.3). Der Zeitpunkt ist ein Riegel und kein Zufall:

• Solange die Dateien des Reviers noch nicht weggeschlossen sind, bedient der Server Kachel-Anfragen weiter aus den amtlichen Quellen und spiegelt jede geholte Kachel in den Vorrat des Reviers. Der Abruf verrät die Gegend. Es sind dieselben Abrufe, die derselbe Server für jeden Gast der öffentlichen Demo-Karte macht, und der Preis ist ausgesprochen statt versteckt: Ohne Luftbild kann niemand eine Grenze ziehen, und ein frisch angelegtes Revier hat noch keinen Vorrat.
• Sind sie weggeschlossen, liefert der Server nur noch aus dem eigenen Vorrat und fragt für dieses Revier keine fremde Quelle mehr. Eine fehlende Kachel bleibt dann leer, statt extern nachgeholt zu werden.
• Deshalb verlangt der Schließ-Schritt einen vollständigen Vorrat bis Zoomstufe 19 und verweigert sonst mit einem Bericht, was noch fehlt. Der Weg dahin ist ein Nachlade-Lauf in der höchsten Textur-Stufe.

Der Ortsteil der Weltdatei wird beim Schließen abgetrennt und mitversiegelt. Es sind genau neun Felder: lat_c, lon_c, bbox3857, env_bbox3857, merc_edge, minH, maxH, env_minH, env_maxH. Der Rest bleibt lesbar, damit Vorrats-Zähler und Auslieferungs-Versionen weiterlaufen; edge_ground (Boden-Kantenlänge in Metern) gehört dazu und ist allein ortsfrei, weil die Rückrechnung auf den Breitengrad merc_edge braucht und das versiegelt ist.

Nicht gelöst und hier benannt, in der Reihenfolge ihrer Reichweite:

• Die Pfade des Kachel-Vorrats. Der Versiegelungslauf hängt .enc an und benennt nichts um. Auf der Platte steht danach reviere/<rid>/tiles/<z>/<x>/<y>.jpg.enc: der Inhalt ist zu, der Pfad ist eine Web-Mercator-Kachelkoordinate. Aus Minimum und Maximum der Ordner- und Dateinamen fällt der Diorama-Ausschnitt heraus, bei z19 auf etwa 50 m genau, und er ist über den Ordner <rid> genau einem Revier zugeordnet. Zwei Umstände verschärfen das: der Vorrat enthält nach dem Schließen nur noch das Diorama-Fenster, weil _vorrat_im_fenster ohne bbox3857 konstant falsch liefert und nichts mehr dazugespiegelt wird, es gibt also kein Rauschen; und _e2ee_klartext_offen klassifiziert ausschließlich Datei-inhalte und sieht einen Verzeichnisnamen nie an. Ein Gegenmittel wäre ein Namens-HMAC über (z,x,y) mit dem Revierschlüssel; er müsste zeichengleich in _e2ee_datei_zeile, _vorrat_kachel und sw.js nachgezogen werden, und die AAD hängt heute an genau dieser Klartext-Kennung tiles/z/x/y. Solange das nicht gebaut ist, steht der Ort des 3D-Modells auf /sicherheit als benannte Ausnahme.
• Die Quellennamen. dem, env_dem, ortho_quelle, quellen{} und veg_stichtag bleiben Klartext (etwa bev1m, at-basemap) und verraten damit das Land, in Deutschland über das Vermessungsamt auch das Bundesland.
• Klartextspalten an revier selbst. Die Tabelle revier ist keine der zeilenverschlüsselten Tabellen und wird vom Versiegelungslauf nicht angefasst: slug, name, bundesland, land, betriebsart sowie die Behördenstammdaten jab_anschrift, jab_bezirk, jab_bevollm_ort, jab_behoerde und jagdgebiets_nr bleiben lesbar. _bl_key liest bundesland ohne jede E2EE-Weiche.
• Der Kamera-Slug. cam hat den Primärschlüssel (revier_id, slug); name wird auf '' geräumt, der slug bleibt als Zeilenkennung und als Ordnername auf der Platte stehen. Er ist der slugifizierte Kameraname, also Reviergeografie in Prosa.
• Der Empfänger einer Meldung. meldungs_empfaenger.bezeichnung steht nicht in E2EE_TABELLEN; ein Eintrag wie „Polizeiposten Pernitz" verrät die Region.

6. Debugging ohne Backdoor

Es gibt keinen Betreiber-Notschlüssel und keine Hintertür. Die Zusage „wir können nicht hineinsehen" gilt ab Tag 1, nicht erst nach einer Beta-Phase. Eine zweite, betreibereigene Verpackung des RK war im ersten Entwurf dieses Vorhabens vorgesehen und wurde am 09.08.2026 ausdrücklich verworfen; die Spalte dafür existiert im Schema nicht, und der Abschnitt des alten Plans steht dort nur noch als Chronik der verworfenen Variante.

Ehrlich zur Betreiber-Rolle: Ein Sitzungs-Zugang der Betreiberseite in ein fremdes Revier existiert weiterhin (Support-Zugang). Er verschafft eine Sitzung, keinen Schlüssel: Ohne Mitgliedschafts-Verpackung, ohne KEK und ohne Revier-Passwort liefert er in einem versiegelten Revier Chiffretext und Platzhalter. Das ist der Unterschied zwischen „darf zugreifen" und „kann lesen", und nur der zweite Teil ist hier durch Kryptographie und nicht durch eine Regel abgesichert.

Geplant, noch nicht gebaut: ein Knopf „Fehler melden mit Daten". Der Client packt dabei den kaputten Datensatz samt Umfeld, verschlüsselt ihn mit dem öffentlichen Betreiber-Schlüssel und lädt ihn hoch; lesen kann ihn dann nur der private Schlüssel auf dem Rechner des Betreibers, und zwar genau diesen einen Datensatz. Bis dahin läuft Fehlersuche über Beschreibung und Bildschirmfotos. Im ausgelieferten Code gibt es diesen Knopf heute nicht.

7. Ehrliche Grenzen

Eine Verschlüsselung, die alles verspricht, lügt. Folgende Daten bleiben Klartext, das Minimum, ohne das der Server nicht funktionieren kann:

Konkrete Folge: der Server weiß nicht, wo deine Grenze liegt, nicht wo ein Marker steht, nicht was du erlegt hast. Er weiß nur: „Konto #31 zahlt für Revier #71, das 2,3 GB belegt hat."

Weitere Grenzen, benannt statt weggelassen:

• Zeitmuster und Mengen. Zeitstempel und Zeilenzahl bleiben lesbar, weil daran Sync, Papierkorb und Kontingent hängen. Wer lange genug zusieht, liest daraus Aktivitätsmuster, nicht Inhalte.
• Das Bearbeitungs- und Bau-Fenster. Beim Bearbeiten der Grenze und beim 3D-Bau schickt der Client die entschlüsselte Grenze im Rumpf der Anfrage mit, weil der Server die Rechnung macht (Vereinigung von Parzellen, Rasterung, Kachelbeschaffung). Er legt sie dabei nicht ab, auch keine Sicherungskopie; beim Bau geht sie als flüchtige Datei in den Arbeitsspeicher und wird danach gelöscht. Das ist keine Offenlegung im Ruhezustand, sondern ein benanntes Fenster während der Anfrage. Die dabei entstehenden Karten-Dateien sind wieder offen, bis der Riegel aus 5.3 fällt.
• Das Ausgabe-Fenster. GPX, Erfüllungsnachweis, Streckenliste, Jahresbericht, Statistik und die Buchhaltungs-Ausgaben rechnet weiterhin der Server; der Client schickt dafür genau die benötigten Zeilen im Rumpf mit. Verschickt der Server ein Dokument per Mail an eine Behörde, sieht er dessen Inhalt in diesem Moment. Dazu ein eigenes, kleines Leck: Die Bezeichnung des Meldungs-Empfängers muss der Server lesen können, und ein Eintrag wie „Polizeiposten Pernitz" verrät damit die Region.
• Karten-Rendering. Das serverseitige Rendern der Druckkarte und die Rasterung der Grenzmaske sind die letzten Wege, die noch nicht über das Fenster laufen. Ein versiegeltes Revier verliert diese beiden Ausgaben, bis sie umgestellt sind: Die Grenze liegt als .enc, der Server kann sie nicht lesen und holt sich für das Rendern keinen Klartext zurück.
• Zugangsdaten für Kameraportale. Das zeitgesteuerte Abholen läuft ohne offenen Client, der Server muss sich also selbst anmelden können. Die Zugangsdaten liegen verschlüsselt, der Schlüssel dafür aber auf dem Server (Datei im Datenverzeichnis, nur für den Dienst lesbar). Wer den Server hat, hat diese Portal-Zugangsdaten. Es ist die einzige Stelle im Produkt mit dieser Eigenschaft, und sie betrifft keine Jagddaten.
• Wetter. Dein Gerät rundet Wetterpunkte vor der Anfrage auf 0,01 Grad, etwa einen Kilometer. GeoSphere Austria für österreichische Reviere und Bright Sky mit DWD-Daten für deutsche Reviere werden direkt gefragt; sie sehen den gerundeten Ort und die IP-Adresse deines Geräts. Ergänzungen, Windfeld und Ausfallersatz kommen von Open-Meteo auf unserer eigenen Infrastruktur, ebenso die Schweizer Vorhersage. Unser Server sieht diese gerundeten Punkte während der Anfrage, prüft Sitzung und Abo und reicht keine Sitzungsdaten an den Wetterdienst weiter. Die Punkte stehen im Anfrageinhalt, nicht in der URL. Ortsbezogene Antworten bleiben nur kurz im Arbeitsspeicher, es gibt keine dauerhaften Wetterort-Protokolle. Der Modellabgleich ist unabhängig von Revierorten. „Kein Wetter abrufen“ unter „Wetter & Himmel“ schaltet alle diese Abfragen je Gerät ab; frühere Abfragen macht der Schalter nicht ungeschehen.
• Der Ort im Anfrage-Rumpf im versiegelten Revier. Nach der Orts-Abtrennung kennt der Server den Reviermittelpunkt nicht mehr; die Dämmerungs-Statistik der Wildkamera (/api/cam/stats) braucht ihn trotzdem, seit dem 04.09.2026 als einzige Route. Der Client schickt ihn deshalb im Rumpf der Anfrage mit ({"e2ee_ort":{"lat":…,"lon":…}}, auf 0,01° gerundet, also rund einen Kilometer). Bewusst im Rumpf und nie als Query-Parameter: die Query stünde im Zugriffsprotokoll, und daraus ließen sich Mandant und Ort rekonstruieren. Unversiegelt nimmt der Server einen Rumpf-Ort gar nicht erst an. Abgelegt wird er nicht, weder in der Datenbank noch in einem Protokoll; im Arbeitsspeicher steht er als Schlüssel des Sonnenzeiten-Caches (je Tag und Ort, bis zum Neustart des Dienstes). Fehlt der Ort, benennt er den Zustand (ort_fehlt) und die ortsabhängigen Blöcke bleiben leer, statt für einen Ersatz-Standort gerechnet zu werden. Es ist dasselbe Fenster wie beim Bearbeiten der Grenze, kein zweites Zugeständnis. Was die Rundung leistet und was nicht: 0,01° ist bei 47,5° N ein Raster von 1.112 m Höhe und 753 m Breite, Zellfläche 0,84 km², maximaler Versatz zum echten Mittelpunkt 672 m. Es ist ein Raster-Snap, keine Verwischung: dasselbe Revier landet immer in derselben Zelle, Wiederholungen bringen keinen Zusatzgewinn und mitteln sich auch nicht heraus. Und sie ist keine Ortsverschleierung im Ruhezustand: die Pfade des Kachel-Vorrats (5.3) nennen denselben Ort dauerhaft und rund zwanzigmal genauer. Die Rundung begrenzt allein, was dieser Weg zusätzlich über die Leitung schickt. Ein Restpfad: zwischen finalize und dem Dateien-Schritt liegt world.json noch im Klartext mit lat_c; dann greift Zweig 1 von _revier_coords(), der Server rechnet die Sonnenzeiten mit dem echten Mittelpunkt, und der gerundete Rumpfwert wird durch das or gar nicht gelesen. An einen Fremddienst geht dieser Wert nicht mehr, seit der Browser das Wetter selbst holt.
• Vergessenes Passwort ohne Wiederherstellungs-Wörter ist Datenverlust. Es gibt kein Zurücksetzen, das die Daten rettet. Das ist die Kehrseite echter Verschlüsselung und steht ausdrücklich in den AGB.
• Passwortwechsel und Aussperren. Beides ist noch nicht gebaut. Wer das Revier-Passwort einmal hatte, hat den RK einmal gesehen; endgültiges Aussperren verlangt einen neuen RK und die Umschlüsselung des Bestands, alte Daten blieben für ihn lesbar. Bis dahin weist der Server einen Passwortwechsel am verschlüsselten Revier ab, statt Zugang und Schlüssel auseinanderlaufen zu lassen.
• Serverseitige Suche, Sortierung und Aggregation entfallen. Der Client lädt die Zeilen, entschlüsselt sie und sortiert, filtert und sucht lokal. Bei großen Revieren kann das am Handy spürbar sein; die Server-Seite arbeitet dafür heute mit Obergrenzen je Abruf.
• Belegerkennung (OCR) in der Buchhaltung stirbt oder braucht einen WASM-Download im Browser (rund 10 MB).
• Buchhaltungs-Export (§ 132 BAO). Belege sind verschlüsselt. Im versiegelten Revier lehnt der Steuerberater-Link den Export ab, statt still Platzhalter auszuliefern — die Revierleitung zieht den entschlüsselten Export in der App und gibt ihn an die Kanzlei weiter. Ein Zugang über einen Fragment-Schlüssel im Link wurde erwogen und verworfen: kein zweiter Schlüsselweg, kein zweites Angriffsziel. Die eine dokumentierte Ausnahme ist der befristete Nur-Lese-Gastlink (Leselink): dort reist der Revierschlüssel bewusst im URL-Fragment mit, das den Server nie erreicht. Der Server prüft nur den widerruflichen Zugangs-Token, der Gast kann lesen und nichts ändern, und wer den Link hat, hat den Schlüssel: derselbe Sorgfaltsmaßstab wie beim Revier-Passwort. Für den Steuerberater-Weg bleibt es beim Nein. Bei Schlüsselverlust sind auch Buchhaltungsdaten nicht wiederherstellbar.
• Rollback einzelner Zeilen. Der Pflicht-Kontext verhindert das Vertauschen von Blobs, nicht das Weglassen, Doppeln oder Zurückspielen eines älteren Blobs derselben Zeile durch jemanden mit Datenbankzugriff. Dagegen hilft erst ein Versionsvektor, und der ist nicht gebaut.

8. Prüfbarkeit (vier Stufen)

„Vertrau uns" reicht bei Verschlüsselung nicht. Vier Stufen, aufsteigend nach Überzeugungskraft:

1. Eine Bremse, die es beweist statt behauptet (läuft). Prüfreihen fahren die echte App gegen einen echten Server und messen die Schreibwege daraufhin, dass kein Fachfeld im Klartext hinausgeht, dazu die Lesewege, das Ausgabe-Fenster und den Versiegelungs-Lauf. Mit Gegenprobe: schaltet man die Verschlüsselung ab, müssen die Reihen rot werden. Das ist die Hausform dieses Projekts.
2. Der eigene Blick ins Netzwerk (jederzeit, ohne uns). Entwicklerwerkzeuge des Browsers öffnen, Reiter „Netzwerk", einen Marker anlegen: Im abgeschickten Rumpf steht ein einziges Feld mit Chiffretext, kein Name, keine Koordinate, keine Wildart.
3. Offener Client-Code (heute noch privat). Notwendig, aber für sich schwach: Woher weiß der Nutzer, dass das ausgelieferte JavaScript dem im Verzeichnis entspricht?
4. Veröffentlichter Bundle-Hash plus nachbaubare Auslieferung. Dann nennt jede Freigabe den Hash des ausgelieferten Programms; wer will, baut aus dem Stand nach und vergleicht. Das ist die Stufe, die den vorigen Punkt erst tragfähig macht.

Bewusst nicht: ein externes Audit (Cure53 und andere). Zu teuer für den jetzigen Stand, ohne zahlende Kunden auch nicht nötig. Kann später folgen und wird in diesem Whitepaper als „nicht erfolgt" ausgewiesen, nicht verschwiegen.

9. Vergleich mit Alternativen

Marktrecherche August 2026, nachgemessen statt behauptet. Belege in PLAN-APP-SYNC-E2EE.md Teil A.

Belastbare Fassung der Aussage: Es war keine cloudbasierte Revier-App auffindbar, die Ende-zu-Ende-Verschlüsselung für Revierdaten zusagt.

Revier3D positioniert sich damit zwischen Waidly (lokal, isoliert) und Revierwelt (Cloud, mitlesbar): privat wie eine Offline-App, aber trotzdem gemeinsam nutzbar, gesichert und von überall erreichbar.

10. Rechtliche Kompatibilität

Dieser Abschnitt prüft, ob die Vollverschlüsselung mit österreichischem Recht und der DSGVO vereinbar ist. Die Einschätzung beruht auf der Rechtslage Stand August 2026 und ersetzt keine anwaltliche Prüfung im Einzelfall.

10.1 Vorratsdatenspeicherung (IP-Adressen)

Der Verfassungsgerichtshof (VfGH) hat die Vorratsdatenspeicherung 2014 als verfassungswidrig aufgehoben. Es gibt keine gesetzliche Pflicht für Web-Anwendungen, IP-Adressen zu speichern. Revier3D ist kein Telekommunikationsanbieter im Sinne des TKG. Die Nichtspeicherung von IP-Adressen ist nicht nur legal, sondern datenschutzrechtlich geboten (DSGVO Art. 5 Abs. 1 lit. c, Datenminimierung).

Bei einer konkreten Strafverfolgung (§ 76 StPO) kann die Behörde verlangen, was vorhanden ist. Ist nichts gespeichert, gibt es nichts herauszugeben. Man kann nicht verpflichtet werden, Daten zu speichern, die man nicht speichern will.

10.2 Auskunftsrecht (DSGVO Art. 15)

Der Nutzer hat Anspruch auf Auskunft über die Verarbeitung seiner Daten. Mit E2EE kann Revier3D Auskunft geben über Metadaten (Konto, E-Mail, Tarif, Speichermenge, Revier-ID). Die verschlüsselten Inhalte kann Revier3D nicht ausweisen, weil es sie nicht entschlüsseln kann. Der Nutzer kann die Inhalte selbst einsehen (er entschlüsselt lokal). Art. 15 ist erfüllt.

10.3 Recht auf Datenübertragbarkeit (DSGVO Art. 20)

Der Nutzer kann seine Daten in einem strukturierten, gängigen Format exportieren. Der Browser entschlüsselt sie dafür lokal und schickt die entschlüsselten Zeilen für diese eine Anfrage an den Server, der die Datei setzt und nichts davon behält (Ausgabe-Fenster, Abschnitt 7). Die fertige Datei ist unverschlüsselt, weil sie beim Nutzer landet und dort weiterverarbeitet werden soll. Art. 20 ist erfüllt.

10.4 Datenschutz durch Verschlüsselung (DSGVO Art. 25, 32)

Die DSGVO fordert ausdrücklich Verschlüsselung als technische und organisatorische Maßnahme (Art. 32 Abs. 1 lit. a) und Privacy by Design (Art. 25). Vollständige E2EE übertrifft die Anforderungen. E2EE ist nicht nur legal, sondern datenschutzrechtlich das Optimum.

10.5 § 132 BAO (Aufbewahrungspflicht Buchhaltungsunterlagen)

Der Nutzer hat eine gesetzliche 7-Jahres-Aufbewahrungspflicht für Buchhaltungsunterlagen. Mit E2EE sind Belege und Buchungen verschlüsselt. Bei Schlüsselverlust ohne Wiederherstellungscode sind diese Daten unwiderruflich verloren.

Dies ist die Pflicht des Nutzers, nicht die von Revier3D. Die AGB (§ 2.4) stellen ausdrücklich klar: „Die Verantwortung für die steuerliche Richtigkeit der Eintragungen und für die Einhaltung der Aufbewahrungspflichten (insbesondere § 132 BAO) liegt beim Kunden." E2EE ändert daran nichts, verschärft aber das Risiko bei Schlüsselverlust.

Revier3D mindert dieses Risiko durch: (1) die 12 Wiederherstellungs-Wörter bei der Einrichtung, jederzeit im Planer wieder ansehbar, (2) den Export als zusätzliche Sicherung außerhalb des Produkts, (3) den Buchhaltungs-Export, den die Revierleitung entschlüsselt zieht und an die Kanzlei weitergibt (Abschnitt 7).

10.6 Behördliche Auskunftspflicht (StPO)

Öffentliche Behörden können Daten beschlagnahmen (§ 76 StPO) oder Auskunft verlangen. Revier3D gibt heraus, was es hat: Kontometadaten und chiffrierte Datenblöcke. Die verschlüsselten Inhalte kann Revier3D nicht entschlüsseln und daher nicht ausweisen. Das ist mit ProtonMail (Schweiz) und Tutanota (Deutschland) vergleichbar, die beide legal in deutschsprachigen Rechtsräumen operieren.

Revier3D kann nicht ausschließen, dass künftig eine gesetzliche Verpflichtung zur Protokollierung von Verbindungsdaten (IP-Adressen) eingeführt wird. Eine solche Pflicht gälte aber für Metadaten, nicht für Jagddaten. Selbst dann blieben die verschlüsselten Inhalte unlesbar.

10.7 Kein Backdoor-Zwang

Es gibt keine österreichische Rechtsgrundlage, die einen Software-Anbieter zwingt, seine Verschlüsselung zu schwächen oder eine Hintertür einzubauen. Auf EU-Ebene wird die CSAR-Verordnung („Chat Control") diskutiert, die Scanning verschlüsselter Kommunikation vorsehen würde. Stand August 2026 ist sie nicht verabschiedet, richtet sich gegen Messenger und nicht gegen Nischen-SaaS. Mit offenem Code und reproduzierbarem Bau wäre ein heimlicher Backdoor nachweisbar.

11. Referenzen

• RFC 9106: Argon2 Memory-Hard Function (Schlüssel aus Passwörtern).
• RFC 8439: ChaCha20 und Poly1305 für IETF-Protokolle.
• draft-irtf-cfrg-xchacha: XChaCha20-Poly1305, der 192-Bit-Nonce-Aufsatz auf RFC 8439. Der Testvektor aus Abschnitt 2.2.1 ist in der Prüfreihe des Servers fest verdrahtet.
• RFC 7748: Elliptic Curves for Security (Curve25519, X25519).
• RFC 5869: HKDF (HMAC-based Extract-and-Expand Key Derivation Function).
• RFC 8032: Edwards-Curve Digital Signature Algorithm (Ed25519), vorgesehen für Welle 5.
• BIP39: Wortlisten-Konstruktion der 12 Wiederherstellungs-Wörter (2048 Wörter, 128 Bit Zufall plus 4 Bit Prüfsumme, eindeutige Vier-Zeichen-Vorsilbe).
• NIST SP 800-38D und FIPS 197: AES-256-GCM. Geprüft und aus den in Abschnitt 3.2 genannten Gründen nicht gewählt.
• FIPS 186-4: NIST Curve P-256. Geprüft und aus den in Abschnitt 3.3 genannten Gründen nicht gewählt.
• OWASP Password Storage Cheat Sheet: Argon2id-Empfehlungen.
• Bibliotheken: im Browser @noble/ciphers (XChaCha20-Poly1305), @noble/curves (X25519), @noble/hashes (HKDF-SHA256), hash-wasm (Argon2id, WASM-basiert). Auf dem Server cryptography (ChaCha20-Poly1305, X25519, HKDF) plus rund 30 selbst geschriebene Zeilen HChaCha20, weil die Bibliothek die XChaCha20-Variante nicht mitbringt.
• Quellcode: revier3d/src/crypto/, ausgeliefert als webmap/static/revier-crypto.js; Server-Seite webmap/e2ee.py.
• Vollständiger Plan: webmap/PLAN-APP-SYNC-E2EE.md im Repository.