Technische Dokumentation für Sicherheitsforschende, IT-Verantwortliche und Kundinnen, die genau wissen wollen, was wie und warum verschlüsselt wird.
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, nicht wo deine Grenze liegt, nicht was du erlegt hast.
Architektur: Row-Level-Verschlüsselung statt pro-Feld-`_enc`-Spalten. Jede Zeile wird als ein verschlüsselter JSON-Blob (`data_enc`) gespeichert. Der Server sieht nur Metadaten (`id`, `revier_id`, `created_at`, `updated_at`, `deleted_at`, `vvec`) für Sync und Mandantentrennung. Alle Felder (Koordinaten, Wildart, Datum, Name, Notiz, etc.) sind 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. Dadurch ist ein Passwortwechsel möglich, ohne dass Daten unlesbar werden.
Was der Server am Ende noch weiß: Account-E-Mail (Login), Paddle-Zahlungsdaten (Billing), Revier-Slug (URL), Revier-Status (Zugangskontrolle), Speichermenge (Quota). Keine Jagddaten, nicht einmal die Position. Auch 3D-Terrain und Luftbild sind verschlüsselt.
Es gibt keinen Betreiber-Notschlüssel und keine Hintertür, auch nicht während der Beta. Für die Fehlersuche existiert ausschließlich der Knopf „Fehler melden mit Daten" (Abschnitt 6).
revier.kek_salt)Warum nicht PBKDF2 oder scrypt? PBK2 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 Side-Channel (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.
crypto.subtlecrypto.subtle.importKey(extractable:false) im sicheren Schlüsselspeicher des Browsers gehalten. JavaScript kann ihn nutzen, aber nie lesen.Warum AES-GCM über WebCrypto statt XChaCha20? Drei Gründe. Erstens: crypto.subtle erlaubt extractable: false, der Schlüssel verlässt nie den sicheren Schlüsselspeicher des Browsers. Ein XSS-Angriff kann Daten ver- und entschlüsseln, solange der Tab offen ist, aber den Schlüssel nicht stehlen. Das ist der wichtigste Einzel-Schritt für maximale Sicherheit. Zweitens: AES-NI-Hardware-Beschleunigung macht AES-GCM auf den meisten Geräten schneller als XChaCha20 in Software. Drittens: Nonce als Zähler (96 Bit) schließt Nonce-Wiederverwendung vollständig aus, dem einzigen katastrophalen Fehler bei GCM.
crypto.subtleWarum P-256 statt X25519? X25519 wird von WebCrypto noch nicht in allen Browsern unterstützt (Safari nicht). P-256 ist universell unterstützt und kann als non-extractable importiert werden. Der non-extractable-Gewinn wiegt schwerer als der theoretische X25519-Vorteil. P-256 ist der Standard für TLS bei Apple, Google, Microsoft.
crypto.subtle.deriveBitsRK_data (Zeilen), RK_cam (Kamera-File-Keys), RK_meta (Index/Cache). Leckt ein Zweckschlüssel, sind die anderen sicher.# Einmalig beim Anlegen des Reviers erzeugt: RK = random(256 bit) # Revier-Schlüssel, EINMAL erzeugt, danach konstant # Schlüsseltrennung via HKDF (Zweckschlüssel): RK_data = HKDF(RK, "data") # Zeilen-Verschlüsselung (AES-256-GCM) RK_cam = HKDF(RK, "camera") # Kamera-File-Key-Entschlüsselung (ECDH P-256) RK_meta = HKDF(RK, "metadata") # Index/Cache # Verpackung 1: Revier-Passwort (Single-Modus, vier Freunde teilen Link+PW) KEK = Argon2id(revier_passwort, revier.kek_salt, m=64 MiB, t=3, p=1) revier.rk_wrapped = AES-256-GCM(Enc, RK, KEK) # über crypto.subtle # Verpackung 2 (optional): Konten (Multi-Modus, je Mitglied) revier.rk_wrapped_konto[i] = ECDH-Seal(RK, konto_pubkey[i]) # P-256 über crypto.subtle # KEIN Betreiber-Notschlüssel. Keine Hintertür. Die Zusage gilt ab Tag 1. # Daten-Verschlüsselung (je Eintrag): file_key = random(256 bit) cipher = AES-256-GCM(Enc, klartext, file_key, nonce=counter) # über crypto.subtle wrapped_file_key = ECDH-Seal(file_key, revier.pubkey) # Kamera-Inbound # Alle Schlüssel-Handles sind non-extractable (extractable:false).
Die Trennung zwischen RK (konstant) und KEK (aus Passwort) löst das Hauptproblem einer ableitungsbasierten Architektur: Passwortwechsel kostet keine Daten. Ein Passwortwechsel bedeutet nur, dass die eine Verpackung rk_wrapped neu erzeugt wird, eine kleine Blob-Operation. Die verschlüsselten Daten selbst werden nicht angefasst.
rk_version trägt die Schlüsselgeneration. Beim Beta-Ende wird der RK gewechselt und der gesamte Bestand mit neuem RK umverschlüsselt: erst dann ist ein alter, eventuell kompromittierter RK wertlos geworden.
Pro Tabelle mit verschlüsselten Feldern (marker, foto, strecke, ansitz, wartung, schaden, belegung, buchung, sketch, kontrolle, nachsuche, fuetterung_log) kommen neue Spalten:
<feld>_enc: Chiffretext (Base64), ersetzt das bisherige Klartext-Feldkek_salt: je Revier (in revier), 128 Bitrk_wrapped: in revier, Verpackung 1 (Revier-Passwort)rk_wrapped_konto: in revier_membership, je Konto (ECDH P-256)rk_version: int, Schlüsselgenerationpubkey: in revier, öffentlicher P-256-Schlüssele2ee_aktiv: bool, Migration kann etappenweise erfolgenBestehende Reviere werden lazy migriert: beim ersten Lesen nach dem Update entschlüsselt der Client den Klartext aus der Alt-Spalte, verschlüsselt ihn mit RK neu und schreibt ihn in <feld>_enc zurück. Cloudflare-Cache (4 Stunden) und alt- Clients können in dieser Phase existieren; die Alt-Spalte bleibt bis Welle 3 erhalten.
Die Route /foto/<id> liefert ab Welle 2 Chiffretext aus. 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 native Verzögerung, Caching und Speicherverwaltung des Browsers funktionieren weiter.
Es gibt keinen Betreiber-Notschlüssel, keinen administrativen Zugriff, keine Hintertür. Die Zusage „wir können nicht hineinsehen" gilt ab Tag 1, nicht erst nach einer Beta-Phase.
Für Debugging bei verschlüsselten Fehlern gibt es den Knopf „Fehler melden mit Daten": der Client packt den kaputten Datensatz samt Umfeld, verschlüsselt ihn mit dem öffentlichen Betreiber-Schlüssel und lädt ihn hoch. Der Betreiber kann genau diesen einen Datensatz mit seinem privaten Schlüssel auf seinem Rechner lesen. Er hat keinen stehenden Zugriff auf irgendwelche Revierdaten.
Dieses Verfahren bleibt auch nach der Beta und ist der einzige Debugging-Weg.
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, 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 konzeptionelle Grenzen:
admin_enter entfällt. Support läuft über Anleitung und den „Fehler melden mit Daten"-Knopf, der kaputte Datensätze asymmetrisch verschlüsselt hochlädt./stb/<token>#<schlüssel> rein (Fragment-Schlüssel, Browser entschlüsselt lokal). Bei Schlüsselverlust sind auch Buchhaltungsdaten nicht wiederherstellbar, das muss in die AGB.„Vertrau uns" reicht bei Verschlüsselung nicht. Vier Stufen, aufsteigend nach Überzeugungskraft:
/sicherheit zeigt dem eingeloggten Nutzer an seinen eigenen Daten nebeneinander: links was der Browser anzeigt, rechts die Rohzeile, wie sie wirklich in der Datenbank steht. Der Nutzer sieht mit eigenen Augen Buchstabensalat. Dazu ehrlich: eine zweite Tabelle mit dem, was nicht verschlüsselt ist.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.
Marktrecherche August 2026, nachgemessen statt behauptet. Belege in PLAN-APP-SYNC-E2EE.md Teil A.
| Anbieter | Verschlüsselungszusage | Quelle |
|---|---|---|
| Revierwelt (Marktführer) | Keine E2EE-Zusage messbar. Apples Datenschutzangaben deklarieren Standort, Fotos, Identität, alle mit Nutzeridentität verknüpft. | App Store |
| Waidly | Gar keine Cloud, alles lokal am Gerät, keine Registrierung. 12,99 € einmalig. Dafür: kein Teilen, kein Backup, kein Web, kein 3D. | iphone-ticker |
| RevierBuch, JagdCom, Mein Revier | Allgemeine „Datensicherheit", keine E2EE-Zusage über TLS hinaus. | Anbieterseiten |
| Jagdgefährte | „Verschlüsselter Chat". Betrifft Kommunikation, nicht Revierdaten. | Store-Beschreibung |
| CoHunt (international) | E2EE für Peer-to-peer-Kommunikation (Mesh-Chat); Revierdaten werden nicht zentral gespeichert (kein Konto, kein Cloud-Bestand). Zusage betrifft Kommunikation, nicht cloudgespeicherte Revierdaten. | Anbieter-Datenschutzerklärung 03/2026 |
| HuntStand, onX Hunt (international) | Keine E2EE- oder Zero-Knowledge-Zusage auffindbar. | Marktübersichten 2026 |
| Signal, Matrix | E2EE für Kommunikation. Nicht auf Revierdaten und 3D-Karten ausgelegt. | Projektseiten |
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.
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.
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.
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.
Der Nutzer kann seine Daten in einem strukturierten, gängigen Format exportieren. Der Export erfolgt clientseitig: der Browser entschlüsselt die Daten lokal und erzeugt das Export-Format. Der Export ist standardmäßig passwortgeschützt. Art. 20 ist erfüllt.
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.
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) Wiederherstellungscode bei der Einrichtung, (2) verschlüsselten Export als zusätzliche Sicherung, (3) Steuerberater-Zugang über einen Fragment-Schlüssel-Link.
Ö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.
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.
crypto.subtle (WebCrypto API, AES-GCM + ECDH P-256 + HKDF, non-extractable), hash-wasm (Argon2id, WASM-basiert), @noble/ed25519 (nur Lizenz-Signatur Welle 5).revier3d/src/crypto/ (Welle 1, ab August 2026), webmap/static/revier-crypto.js.webmap/PLAN-APP-SYNC-E2EE.md im Repository.