EncSend EncSend
Sicherheitskonzept

EncSend-Sicherheitsmodell

Diese Seite beschreibt die aktuelle Umsetzung: welche Daten clientseitig verschlüsselt werden, wie Links und Schlüssel behandelt werden, welche Zugriffskontrollen aktiv sind und wo die Grenzen des Sicherheitsmodells liegen.

Clientseitige Kryptografie

Nachrichten werden im Browser mit Web Crypto (AES-GCM) verschüsselt. Der Server speichert nur Chiffren und Metadaten.

Schlüssel in URL-Fragmenten

Schlüessel für die Entschlüsselung werden in URL-Fragmenten wie #k oder #rk transportiert und nicht an den Server übermittelt.

Optionaler Passwortschutz

Passwortgeschützte Links verwenden serverseitige Passwort-Hashes plus zusätzliches clientseitiges Key-Wrapping mit PBKDF2-SHA-256.

Ablaufzeiten

Ablaufzeiten, Aufruf- oder Einsendelimits und Einmal-Lesen-Richtlinien begrenzen den Zugriff auf sensible Inhalte.

Datenfluss: Secrets senden

  1. Der Browser erzeugt 256-Bit-Link-Schlüsselmaterial.
  2. Die Nachricht wird mit einem zufälligen Payload-Schlüssel per AES-GCM verschlüsselt.
  3. Der Payload-Schlüssel wird mit einem per HKDF-SHA-256 aus dem Link-Schlüssel abgeleiteten Schlüssel gewrappt.
  4. Optional wird dieser gewrappte Schlüssel zusätzlich mit einer passwortbasierten Schicht (PBKDF2-SHA-256) verschlüsselt.
  5. Der Server speichert nur encrypted_payload, encrypted_key, Kryptometadaten und Felder der Zugriffspolitik.
  6. Nach erfolgreicher lokaler Entschlüsselung bestätigt der Client die Ansicht; bei Einmal-Lesen wird das Secret anschliessend als zerstört markiert.

Datenfluss: sichere Nachrichtenanfrage

  1. Der Besitzer erzeugt eine Anfrage-URL mit einem zufaelligen oeffentlichen Token.
  2. Externe Absender verschluesseln lokal im Browser mit Anfrage-Schluesselmaterial aus dem URL-Fragment.
  3. Der Server speichert Einsendungen als Chiffrat und erzwingt Einsendelimits und Ablaufzeiten.
  4. Der Besitzer liest Einsendungen per lokaler Entschluesselung; Klartext wird serverseitig nicht verarbeitet.
  5. Fuer geraeteuebergreifendes Lesen kann der Anfrage-Schluessel zusaetzlich als owner-wrapped Artefakt gespeichert werden.

Zugriffskontrolle und Missbrauchsschutz

Oeffentliche Zugriffstoken werden zufaellig erzeugt, nur als SHA-256-Hashes in der Datenbank gespeichert und per hash_equals validiert.

Link-Passwoerter werden nie im Klartext gespeichert und gegen serverseitige Hashes geprueft. Passwort-Sessions fuer oeffentliche Links sind zeitlich begrenzt und konfigurierbar.

Rate Limits sind fuer kritische Endpunkte aktiv, einschliesslich Passwortpruefungen, oeffentlicher Einsendungen, Login und Verifizierungsablaeufe.

Besitzerseitige Operationen sind durch Authentifizierung, verifizierte E-Mail-Zustaende und Berechtigungsrichtlinien geschuetzt; sensible Wiederherstellungs-Aenderungen erfordern eine aktuelle Passwortbestaetigung.

Besitzer-Wiederherstellung und Key Vault

EncSend stellt optionale verschluesselte Wiederherstellungsartefakte fuer geraeteuebergreifende Szenarien bereit:

  • Owner-Crypto-Profil: verschluesselter Master-Schluessel (AES-GCM), passphrasenbasiert mit PBKDF2-SHA-256.
  • Benutzer-Key-Vault: verschluesseltes Backup lokal gehaltener Geheimnis- und Anfrage-Schluessel.
  • Owner-wrapped Anfrage-Schluessel pro Anfrage und owner-wrapped Geheimnis-Schluessel pro Geheimnis; Rotations-Batches fuer Anfrage-Schluessel unterstuetzen Wiederholungen.

Audit und Nachvollziehbarkeit

Sicherheitsrelevante Aktionen werden protokolliert, zum Beispiel Link-Ausgabe, verweigerter Zugriff, Passwort-Challenges, Erstellung von Einsendungen und Wiederherstellungs-Aktualisierungen.

  • Zugriffsevent-Tabellen speichern Ereignistyp, Zeitstempel, User-Agent und Kontext-Metadaten.
  • Audit-Logs sind fuer Endnutzer (eigene Ereignisse) und Administratoren (globale Sicht) abfragbar.
  • Eine eigene Migration entfernt IP-Adress-Spalten aus sitzungs- und ereignisbezogenen Tabellen.

Wichtige Grenzen des Modells

  • Browser-Sicherheit bleibt kritisch: lokale Schluessel werden im Browser-Speicher zwischengespeichert und erfordern eine gehaertete Client-Umgebung.
  • JavaScript und Web Crypto sind fuer sichere Erstellung und lokale Entschluesselung zwingend erforderlich.
  • Transportsicherheit (HTTPS, Reverse-Proxy-Haertung, TLS-Richtlinien) muss auf Infrastrukturebene erzwungen werden.
  • Passwort-Hashing schuetzt die serverseitige Speicherung, ersetzt aber keine starken Passwoerter.