Verschlüsselung & Sicherheit

Name: TensorPM
Author: TensorPM

TensorPM verwendet Zero-Knowledge Ende-zu-Ende-Verschlüsselung (E2EE), um Projektdaten bei Cloud Sync zu schützen. Workspace-Inhalte werden auf dem Gerät verschlüsselt, bevor sie den Computer verlassen, und können nur von registrierten Geräten entschlüsselt werden. TensorPM-Server sehen die Daten niemals im Klartext.

Überblick

Beim Erstellen oder Beitreten eines Cloud-Workspace richtet TensorPM die Verschlüsselung automatisch ein:

Das Gerät erzeugt eine einzigartige kryptographische Identität (Geräte-Schlüsselpaar)

Ein symmetrischer Workspace-Schlüssel wird für die Inhaltsverschlüsselung erstellt

Der Workspace-Schlüssel wird über versiegelte Umschläge (Sealed Envelopes) sicher an jedes autorisierte Gerät verteilt

Alle sensiblen Projektdaten werden vor dem Sync-Upload verschlüsselt und nach dem Sync-Download entschlüsselt

Das ist echte Zero-Knowledge-Architektur: Unsere Server speichern ausschließlich Chiffretext. Wir können die Projektinhalte nicht lesen, selbst wenn wir dazu aufgefordert würden.

Kryptographische Algorithmen

TensorPM verwendet moderne, auditierte kryptographische Primitiven aus libsodium (NaCl):

Datenverschlüsselung: XChaCha20-Poly1305 (AEAD)

Alle Workspace-Inhalte werden mit XChaCha20-Poly1305 verschlüsselt, einer authentifizierten Verschlüsselung mit assoziierten Daten (AEAD):

256-Bit symmetrische Schlüssel, erzeugt über libsodiums Keygen

192-Bit (24-Byte) zufällige Nonce pro Verschlüsselungsvorgang, was Nonce-Eindeutigkeit sicherstellt

Poly1305-Authentifizierungstag garantiert Datenintegrität und Authentizität

Associated Authenticated Data (AAD) bindet den Chiffretext an seinen Kontext (Workspace, Tabelle, Datensatz) und verhindert kontextübergreifende Angriffe

XChaCha20-Poly1305 gilt weithin als moderne, sichere Alternative zu AES-GCM. Die erweiterte 24-Byte-Nonce macht versehentliche Nonce-Wiederverwendung praktisch unmöglich.

Schlüsselaustausch: X25519 (Elliptic Curve Diffie-Hellman)

Die Schlüsselverteilung zwischen Geräten nutzt X25519 Elliptic-Curve-Schlüsselaustausch:

Jedes Gerät erzeugt ein einzigartiges X25519-Schlüsselpaar (32-Byte öffentlicher/privater Schlüssel)

Workspace-Schlüssel werden in Sealed Boxes (crypto_box_seal) für jedes Empfängergerät verpackt

Nur der private Schlüssel des Empfängers kann den Umschlag öffnen

Geräteisolation: Die Kompromittierung eines Geräts legt nicht die privaten Schlüssel anderer Geräte offen. Allerdings sind bereits empfangene Workspace-Schlüssel auf dem kompromittierten Gerät gefährdet, was die Entschlüsselung von Daten ermöglichen könnte, die mit diesen Schlüsselversionen verschlüsselt wurden

Passwortbasierte Schlüsselableitung: Argon2id

Für die optionale passwortbasierte Wiederherstellung (Escrow) verwendet TensorPM Argon2id:

Memory-Hard-KDF, resistent gegen GPU- und ASIC-Angriffe

Parameter: Memory = 64 MB, Iterationen = 3, Parallelismus = 4

Von OWASP empfohlen für Passwort-Hashing und Schlüsselableitung

Der Server speichert nur den verschlüsselten Escrow-Blob, niemals das Passwort oder den abgeleiteten Schlüssel

Was wird verschlüsselt

TensorPM verschlüsselt alle sensiblen Workspace-Inhalte über 37+ Tabellentypen:

Verschlüsselt (Beispiele):

Projektbeschreibungen, Notizen und benutzerdefinierte Felder

Action-Item-Inhalte, Akzeptanzkriterien und Details

Meilenstein-Namen, Ziele und Beschreibungen

Stakeholder-Labels und Beschreibungen

Budget- und Aufwandsverfolgungsdaten

Zeiterfassungs-Historie

Risikobeschreibungen und Maßnahmenpläne

Anforderungen und Spezifikationen

Nicht verschlüsselt (Metadaten für Sync und Zugriffskontrolle):

Datensatz-IDs und Fremdschlüssel (für relationale Integrität benötigt)

Zeitstempel (created_at, updated_at)

Workspace-Mitgliedschaften und Rolleninformationen

Sync-Koordinations-Metadaten

Wird nie synchronisiert (nur lokal):

API-Schlüssel und Zugangsdaten (im OS Secure Storage gespeichert)

Lokale App-Einstellungen und Präferenzen

E-Mail-Entwürfe und temporäre Daten

Schlüsselverwaltung

Geräteschlüssel

Beim ersten Zugriff auf einen Cloud-Workspace erzeugt TensorPM ein einzigartiges X25519-Schlüsselpaar für das Gerät:

Lokal in einer verschlüsselten Datei gespeichert, geschützt durch den OS-Schlüsselbund (macOS Keychain, Windows DPAPI oder Linux libsecret)

Jedes Gerät hat einen eindeutigen UUID-Bezeichner, der bei TensorPM-Servern registriert ist

Der private Schlüssel verlässt niemals das Gerät

Falls OS Secure Storage nicht verfügbar ist, zeigt TensorPM eine Warnung und den Status "Keyring"

Workspace-Schlüssel

Jeder Cloud-Workspace hat seinen eigenen symmetrischen Verschlüsselungsschlüssel:

Vom Workspace-Ersteller erzeugt mittels libsodiums crypto_aead_xchacha20poly1305_ietf_keygen()

Multi-Versions-Unterstützung: Bei Schlüsselrotation werden alle historischen Versionen zum Entschlüsseln älterer Datensätze aufbewahrt

Lokal im verschlüsselten Schlüsselspeicher des Geräts gespeichert

Umschläge (Schlüsselverteilung)

Workspace-Schlüssel werden über versiegelte Umschläge (Sealed Envelopes) an autorisierte Geräte verteilt:

Der Workspace-Schlüssel wird mit dem X25519-Public-Key jedes Empfängergeräts verschlüsselt (crypto_box_seal())

Umschläge werden über den Server synchronisiert (der Server sieht nur Chiffretext)

Wenn ein neues Gerät beitritt, erstellen bestehende Geräte Umschläge für es

Wenn ein Gerät widerrufen wird, erhält es keine neuen Umschläge mehr

Verschlüsselungs-Datenfluss

Upload (Verschlüsselung vor Sync)

Lokale Datenbank (Klartext)
       |
       v
Sensible Felder werden anhand der Schema-Definition extrahiert
       |
       v
Zufällige 24-Byte-Nonce wird erzeugt
       |
       v
AAD wird konstruiert: workspace_id | table_name | primary_key
       |
       v
XChaCha20-Poly1305 verschlüsselt die sensiblen Felder
       |
       v
Verschlüsselter Blob: { Version, Workspace-Key-Version, Nonce, Chiffretext }
       |
       v
Nur der verschlüsselte Blob wird in den Sync-Sidecar geschrieben
       |
       v
Server speichert verschlüsselten Blob (kann nicht entschlüsseln)

Download (Entschlüsselung nach Sync)

Entschlüsselte Felder werden in lokale Datenbank zusammengeführt (Klartext)

Sicherheitseigenschaften

Authentifizierte Verschlüsselung (AEAD)

Jeder verschlüsselte Datensatz enthält Associated Authenticated Data (AAD), die den Chiffretext an seinen Kontext binden:

workspace_id: Verhindert das Verschieben verschlüsselter Daten zwischen Workspaces

table_name: Verhindert das Austauschen von Daten zwischen verschiedenen Tabellentypen

primary_key: Verhindert das Austauschen von Datensätzen innerhalb derselben Tabelle

Wenn einer dieser Werte manipuliert wird, schlägt die Entschlüsselung fehl. Dies verhindert eine breite Klasse von Chiffretext-Manipulationsangriffen.

Nonce-Verwaltung

Eine frische zufällige 24-Byte-Nonce wird für jede Verschlüsselungsoperation erzeugt

Mit dem 192-Bit-Nonce-Raum von XChaCha20 ist die Wahrscheinlichkeit einer zufälligen Kollision vernachlässigbar (selbst nach Milliarden von Operationen)

Die Nonce wird zusammen mit dem Chiffretext gespeichert und ist nicht geheim

Replay-Schutz

Jeder verschlüsselte Datensatz enthält einen Zeitstempel (_e2e_encrypted_at)

Bei der Entschlüsselung prüft TensorPM, ob der Verschlüsselungszeitstempel relativ zum Aktualisierungszeitstempel des Datensatzes plausibel ist

Veraltete Chiffretexte (wiedereingespielte alte Daten) werden erkannt und gemeldet

Geräteisolation und Widerruf

Jedes Gerät hat sein eigenes Schlüsselpaar, unabhängig von anderen Geräten

Das Widerrufen eines Geräts verhindert, dass es zukünftige Workspace-Schlüssel erhält

Wichtige Einschränkung: Wenn ein Gerät kompromittiert wird, kann der Angreifer auf Workspace-Schlüssel zugreifen, die dieses Gerät bereits empfangen hatte. Das bedeutet, dass historische Daten, die mit diesen Schlüsselversionen verschlüsselt wurden, entschlüsselbar sein könnten. Nach dem Widerruf eines kompromittierten Geräts stellt eine Rotation des Workspace-Schlüssels sicher, dass neue Daten mit einem Schlüssel geschützt sind, den das widerrufene Gerät nie erhalten hat

Wiederherstellung

Gerätebasierte Wiederherstellung

Wenn mindestens ein aktives Gerät vorhanden ist, kann ein neues Gerät registriert werden. Es erhält automatisch Workspace-Key-Umschläge von den bestehenden Geräten.

Passwortbasierte Escrow-Wiederherstellung

TensorPM bietet optionalen passwortbasierten Escrow als Sicherheitsnetz:

Workspace-Schlüssel werden mit einem aus dem Passwort abgeleiteten Schlüssel (Argon2id) verschlüsselt

Der verschlüsselte Escrow-Blob wird auf TensorPM-Servern gespeichert

TensorPM kann den Escrow nicht entschlüsseln (Zero-Knowledge: kein Passwort, kein Zugang)

Zur Wiederherstellung: Passwort eingeben, Argon2id leitet den Schlüssel ab, Workspace-Schlüssel werden wiederhergestellt

Wichtig: Wenn alle Geräte und Wiederherstellungsoptionen verloren gehen

Wenn alle Geräte verloren gehen und keine Escrow-Wiederherstellung eingerichtet ist, können verschlüsselte Cloud-Daten nicht wiederhergestellt werden. TensorPM kann die Daten nicht entschlüsseln. Dies ist der fundamentale Kompromiss echter Zero-Knowledge-Verschlüsselung.

Empfehlung: Immer mindestens zwei Geräte registriert halten oder die passwortbasierte Escrow-Wiederherstellung in den Kontosicherheitseinstellungen einrichten.

E2E-Statusanzeigen

In der App zeigen Cloud-Workspaces ihren Verschlüsselungsstatus:

E2E Setup... - Verschlüsselung wird für diesen Workspace initialisiert

E2E Pending - Warten auf Abschluss der Schlüsselverteilung

E2E Encrypted - Workspace ist vollständig verschlüsselt und betriebsbereit

Keyring - OS Secure Storage ist nicht verfügbar (Verschlüsselungsschlüssel können nicht sicher gespeichert werden)

Zusammenfassung

| Eigenschaft | Detail |

|-------------|--------|

| Architektur | Zero-Knowledge Ende-zu-Ende-Verschlüsselung |

| Datenverschlüsselung | XChaCha20-Poly1305 (AEAD, 256-Bit-Schlüssel) |

| Schlüsselaustausch | X25519 (Elliptic Curve Diffie-Hellman) |

| Schlüsselableitung (Escrow) | Argon2id (64 MB, 3 Iterationen, 4 Threads) |

| Kryptobibliothek | libsodium (NaCl) |

| Nonce-Größe | 192 Bit (24 Bytes), zufällig pro Operation |

| Was verschlüsselt wird | Alle sensiblen Workspace-Inhalte (37+ Tabellen) |

| Was im Klartext bleibt | Strukturelle Metadaten für Sync/Zugriffskontrolle |

| Schlüsselspeicherung | OS-Schlüsselbund (macOS Keychain / Windows DPAPI / Linux libsecret) |

| Serverzugriff auf Klartext | Keiner (Zero-Knowledge) |

| Wiederherstellungsoptionen | Multi-Gerät, passwortbasierter Escrow (Argon2id) |

| Serverstandort | Deutschland (Hetzner, Nürnberg) |

| Transportverschlüsselung | TLS 1.3 |

Dokumentation

Erste Schritte

Täglicher Workflow

KI & Guidance

Sync & Konto

Wartung