NomadVault
Kostenlos testen
Sicherheitsarchitektur

Wie NomadVault Schlüssel vom Server fernhält

Diese Seite beschreibt die eingesetzte Kryptographie, was jede Komponente sehen kann und was nicht, und die Bedrohungen, die dieses Design nicht adressiert. Stand September 2026.

Vertrauensmodell

Wir gehen davon aus, dass unsere eigene Infrastruktur kompromittiert werden kann. Das Design legt daher jeden Schlüssel und jede Klartextoperation in den Client und behandelt Tenant-API, Datenbank und Objektspeicher als nicht vertrauenswürdige Chiffrat-Speicher. Ein Betreiber mit vollem Datenbankzugriff erhält Dateigrößen, Zeitstempel und verpackte Schlüssel, keine Inhalte.

01
Lokale Verschlüsselung
Browser · Ihre Schlüssel
AMK → RSA-4096 + ML-KEM-768 → Dateischlüssel
Hält den eigenen Account Master Key des Nutzers, leitet Dateischlüssel ab und öffnet sie, führt alle AES-GCM-Operationen aus.
Vertrauenswürdig
02
Mandantengrenze
Isolierte Mandanten-API + Datenbank
Verschlüsselte Nutzdaten · signierte Zugriffsrechte
Autorisiert Anfragen, speichert verpackte Schlüssel, Freigaben und die Audit-Kette.
Nicht vertrauenswürdig
03
EU-Speicher
Verschlüsselter Objektspeicher
Dedizierter Bucket · Deutschland / Finnland
Speichert opake Chiffrat-Blobs, adressiert über zufällige Kennungen.
Nicht vertrauenswürdig

02 / 03 Der Server erhält Chiffrat, nicht Ihre Dokumentinhalte. Metadaten und Zugriffsereignisse bleiben sichtbar.

Was der Server sehen kann und was nicht

  • Dateigrößen, MIME-Typen, Zeitstempel und Versionsanzahl
  • Ordnerstruktur und Freigabegraph: wer mit welcher Rolle auf welche Datei oder welchen Ordner zugreift
  • Nutzeridentitäten, Sitzungen und jedes Audit-Ereignis
  • Zugriffsmuster: wer wann was geöffnet, hochgeladen oder heruntergeladen hat
  • Geblendete Such-Token: welche Token in welcher Datei vorkommen, wie oft, und welche Dateien eine Suche getroffen hat, nie die Wörter dahinter
  • Dateiinhalte
  • Datei- und Ordnernamen
  • Notizen und Vorschauen
  • Jeden privaten Schlüssel, Dateischlüssel oder Suchschlüssel
  • Ihr Passwort

Schlüsselhierarchie

Die Kette beginnt beim einzelnen Nutzer, nicht beim Tenant. Jeder Nutzer leitet seinen eigenen Account Master Key im Browser per Argon2id aus seinem Passwort ab; er öffnet ausschließlich die RSA-4096- und ML-KEM-768-Schlüsselpaare dieses Nutzers. Jede Datei hat ihren eigenen symmetrischen Schlüssel, der zweimal für diese Schlüsselpaare verpackt wird, klassisch und post-quanten, sodass ein künftiger Bruch von RSA allein keine Inhalte offenlegt. Es gibt keinen Tenant-weiten Master Key und keinen Administrator-Schlüssel: Ein Admin ohne Freigabe für eine Datei kann sie nicht entschlüsseln.

Passwort (wird nie übertragen)
Account Master Key · pro Nutzer · Argon2id
RSA-4096-Schlüsselpaar
ML-KEM-768-Schlüsselpaar
Verpackter Dateischlüssel (hybrid, pro Datei)
AES-256-GCM-Dateichiffrat

Verschlüsselungsablauf beim Upload

  1. 01
    BereinigenContent Disarm & Reconstruction entfernt Makros, Skripte und eingebettete Objekte im Browser.
  2. 02
    Dateischlüssel erzeugenEin 256-Bit-Schlüssel und eine 96-Bit-Nonce aus dem CSPRNG der Plattform, pro Dateiversion.
  3. 03
    In Blöcken verschlüsselnAES-256-GCM über 10-MB-Blöcke, jeder mit eigener Nonce und dem Blockindex als authentifizierten Daten, der letzte größenaufgefüllt; gestreamt während der Erzeugung.
  4. 04
    Schlüssel zweifach verpackenRSA-4096-OAEP und ML-KEM-768-Kapselung, kombiniert über HKDF.
  5. 05
    Hochladen und protokollierenChiffrat geht in Ihren Bucket; der Tenant speichert den verpackten Schlüssel, den verschlüsselten Metadaten-Umschlag und einen Audit-Eintrag.

Teilen

Eine Freigabe verpackt den Dateischlüssel im Browser des Absenders neu für die öffentlichen Schlüssel des Empfängers. Die Freigabe wird mit Ed25519 signiert und an den Schlüssel-Fingerabdruck des Empfängers gebunden, ein Server, der seinen eigenen Schlüssel unterschiebt, erzeugt eine Freigabe, die der Client ablehnt.

Browser des AbsendersDateischlüssel öffnen → für Empfänger neu verpacken → Freigabe signieren (Ed25519)
signierte Freigabe
Browser des EmpfängersSignatur und gepinnten Fingerabdruck prüfen → öffnen → lokal entschlüsseln

Bedrohungsmodell

Was dieses Design verhindert und was nicht.

BedrohungGegenmaßnahmeRestrisiko
Einbruch in den SpeicherNur Chiffrat; Schlüssel nie vorhandenGering
Böswilliger Insider bei NomadVaultKein Schlüsselmaterial im Tenant; manipulationssichere Audit-KetteGering
Aufgezeichneter Verkehr, später entschlüsseltHybride ML-KEM-768-Verschlüsselung schon heuteGering
MetadatenanalyseVerschlüsselte Metadaten-Umschläge; Größen, Zeitpunkte, Freigabegraph, Zugriffsmuster und verschlüsselte Such-Token (blind indexing) bleiben sichtbarTeilweise
Kompromittiertes NutzergerätPasskeys, MFA, Sitzungsbegrenzung, GerätewiderrufAußerhalb des Modells

Betrieb und Compliance

HostingDeutschland und Finnland, Datenpfade nur in der EU
BackupsVerschlüsselt, off-site, gleiche Jurisdiktion
Verfügbarkeit99,5 % Ziel pro Tenant, veröffentlichte Statusseite
ZertifizierungDSGVO-konform; auf dem Weg zu ISO 27001 und BSI C5

Dokumente

SicherheitsüberblickPDF, 10 Seiten · für Entscheider, ohne technische DetailsAuftragsverarbeitungsvertragArt. 28 DSGVO, mit Subunternehmerliste · auf Anfrage