Wie sicher ist TEPHIA SECURE?
Wie Ihre Dateien verschlüsselt werden, was auf unseren Servern liegt – und was ein Angreifer bekäme, der sie vollständig übernimmt. Ohne Werbesprache, dafür transparent.
Verschlüsselt im Browser
Ihre Dateien werden verschlüsselt, bevor sie Ihren Rechner verlassen, und erst beim Empfänger wieder entschlüsselt.
Schlüssel nie beim Server
Jede Sendung hat ein eigenes Zufallspasswort mit 32 Zeichen. Unser Server bekommt es nie zu sehen.
Metadaten für den Nachweis
Lesbar sind für uns nur Angaben wie Dateiname, Adressen und Zeitpunkte. Die braucht der Zustellnachweis.
So wird verschlüsselt
- PasswortIhr Browser erzeugt ein zufälliges Passwort: 32 Zeichen, rund 190 Bit.
- SchlüsselDaraus wird mit Argon2id der Schlüssel abgeleitet. Das macht jeden Rateversuch teuer.
- VerschlüsselnAES-256-GCM verschlüsselt die Datei und erkennt jede spätere Veränderung.
- HochladenErst dann geht die Datei hinaus, über TLS 1.2 oder 1.3. Das Passwort bleibt bei Ihnen.
Das Passwort steht nicht im Link. Sie geben es auf einem zweiten Weg weiter, etwa in einer getrennten Mail oder am Telefon. Wer nur den Link abfängt, kann die Datei nicht öffnen.
Briefkasten
Wer Ihnen Unterlagen ablegt, verschlüsselt sie in seinem Browser mit demselben Verfahren. Der Server kennt nur einen Prüfwert des Passworts, mit dem sich nichts entschlüsseln lässt.
Ausnahme: Damit Sie das Passwort wiederfinden, schicken wir es Ihnen beim Anlegen per Mail. Es durchläuft dabei einmal den Server und wird nicht gespeichert.
Outlook-Add-in
Das Add-in verschlüsselt direkt in Outlook. Das Passwort geht über Ihr eigenes Mailsystem, nicht über unseren Server; die Dateien selbst gehen nicht über Ihr Mailsystem.
Zwei Wege: TEPHIA SECURE schickt jedem Empfänger einen eigenen Link, und das Passwort steht in Ihrer Mail; oder der Link steht in Ihrer Mail, und das Passwort folgt in einer zweiten. Wer Link und Passwort hat, kann abholen – wie bei jedem Versand per Mail. Beim zweiten Weg lässt sich die Abholung auf die Empfängeradressen beschränken; dann braucht es zusätzlich einen Code aus deren Postfach.
Technische Einzelheiten
- Schlüsselableitung: Argon2id mit 64 MB Speicher, 4 Durchläufen und 2 Threads, danach HKDF-SHA256
- Verschlüsselung: AES-256-GCM, je Sendung eigener Zufallswert (Salt, 32 Byte) und Startwert (IV, 12 Byte)
- Verschlüsselung in Blöcken: Die Datei wird in Blöcken zu 8 MiB verschlüsselt und hochgeladen, jeder Block mit eigener Nonce (IV XOR Blocknummer); Blocknummer und Kennzeichen des letzten Blocks als Zusatzdaten (AAD) verhindern, dass Blöcke vertauscht, weggelassen oder abgeschnitten werden. So sind Dateien bis 2 GB möglich
- Ohne WebAssembly (etwa durch eine Firmenrichtlinie gesperrt): PBKDF2-SHA512 mit einer Million Durchläufen
- Mehrere Dateien oder Ordner werden vor dem Verschlüsseln im Browser zu einem ZIP gepackt
- Transport: TLS 1.2 oder 1.3 mit Forward Secrecy, HSTS für zwei Jahre, strenge Content Security Policy
- Anmeldepasswörter: scrypt mit eigenem Salt; zweiter Faktor ist Pflicht
Was auf unserem Server liegt
Nur verschlüsselt oder gar nicht
- Inhalt Ihrer Dateien: nur verschlüsselt
- Passwort und Schlüssel einer Sendung: nie
- Passwort eines Briefkastens: nur ein Prüfwert
- Anmeldepasswörter: nur als Hash
- Anmeldung über Microsoft: nichts, das bleibt bei Microsoft
- Zahlungsdaten: nichts, die liegen bei Stripe
Lesbar, für den Nachweis
- Dateinamen und Größen, bei einem ZIP auch die Namen darin
- Bezeichnung und Nachricht
- Absender mit Name, Adresse und Organisation
- Empfängeradressen, wenn wir den Link verschicken oder die Abholung beschränkt ist
- Zeitpunkte, IP-Adresse und ungefährer Standort beim Abholen
- Prüfsummen (SHA-256) der Dateien, in Ihrem Browser berechnet
Link-Mails an Ihre Empfänger und Benachrichtigungen wie „Ihre Datei wurde abgeholt“ verschicken wir über Microsoft 365 und Hornetsecurity (Weiterleitung, Viren- und Spamprüfung). Sie nennen keine Dateinamen, nur die Bezeichnung, die Sie selbst vergeben, oder die Zahl der Dateien; das Passwort einer Sendung steht in keiner unserer Mails. Den Zustellnachweis als PDF, der die Dateinamen enthält, hängen wir nur an, wenn Sie das in Ihrem Konto einschalten.
Was wäre, wenn jemand den Server übernimmt?
Wir gehen vom schlimmsten Fall aus: Ein Angreifer hat die volle Kontrolle über Server, Datenbank und Dateispeicher.
Das bekäme er
- Verschlüsselte Dateien, die gerade auf dem Server liegen – ohne Passwort unlesbar
- Metadaten: wer an wen, wann, Dateinamen und Adressen. Ein Name wie „Scheidung_Müller.pdf“ verrät schon etwas.
Das bekäme er nicht
- Inhalte bisheriger Sendungen und Briefkästen: Die Passwörter waren nie auf dem Server, und 190 Bit lassen sich nicht durchprobieren
- Gelöschte Dateien: Sie liegen auch in keiner Sicherung
- Microsoft-Kennwörter und Zahlungsdaten
Wie wir vorbeugen
- Kurze Aufbewahrung: Dateien werden nach der Abholung gelöscht. Was nicht mehr da ist, kann niemand erbeuten.
- Code aus einer Hand: Die Webanwendung lädt ihren Code nur von unserem eigenen Server, eine strenge Content Security Policy verhindert eingeschleusten Code.
- Abgeschotteter Zugang: Wartung nur mit Schlüssel und nur aus festgelegten Netzen; Organisationen sind in der Datenbank zusätzlich voneinander getrennt.
- Meldung im Ernstfall: Bemerken wir einen Einbruch, informieren wir die betroffenen Organisationen unverzüglich (Art. 33 DSGVO).
Wie lange würde es dauern, eine abgefangene Datei zu knacken?
Selbst mit einer Milliarde Grafikkarten bräuchte ein Angreifer im Mittel rund 4 × 1037 Jahre.
Angenommen, jemand fängt eine verschlüsselte Datei ab – unterwegs oder vom Server. Ohne das Passwort bleibt ihm nur, Passwörter durchzuprobieren. So lange bräuchte er dafür im Durchschnitt:
Zum Vergleich: Das Universum ist rund 1,4 × 1010 Jahre alt. Selbst eine Milliarde Grafikkarten bräuchte etwa 1027-mal so lange.
Warum es so lange dauert
- Lange Zufallspasswörter: Jede Sendung bekommt ein eigenes Passwort mit 32 Zeichen, erzeugt in Ihrem Browser. Das sind rund 2,3 × 1057 Möglichkeiten (190 Bit).
- Jeder Versuch ist teuer: Bevor ein Passwort geprüft werden kann, muss es Argon2id durchlaufen, mit 64 MB Speicher und vier Durchläufen. Das bremst Grafikkarten und Spezialhardware gezielt aus.
- Der Schlüssel selbst (AES-256) wäre mit 2256 Möglichkeiten noch schwerer zu erraten als das Passwort.
Und Quantencomputer?
Nach heutigem Stand halbiert ein Quantencomputer beim Durchprobieren höchstens die Zahl der Bit. Aus 190 Bit würden rechnerisch 95, und jeder Versuch müsste weiterhin Argon2id durchlaufen. Auch das liegt weit außerhalb jeder absehbaren Rechenleistung.
Die Zahlen sind großzügig zugunsten des Angreifers geschätzt und auf eine Stelle gerundet. Gerechnet ist der Durchschnitt, also die Hälfte aller Möglichkeiten.
Realistische Angriffe zielen deshalb nicht auf die Verschlüsselung, sondern auf das Passwort: Wer Link und Passwort zusammen in die Hände bekommt, muss nichts knacken. Darum gehen beide immer getrennte Wege – siehe Was Sie selbst tun können.
Wo die Daten liegen und wie lange
Was Sie selbst tun können
- Passwort und Link getrennt übermitteln, nie in derselben Nachricht.
- Mit Microsoft anmelden und die Anmeldung mit Passwort abschalten, oder einen Sicherheitsschlüssel bzw. Passkey nutzen.
- Neutrale Dateinamen wählen, wenn schon der Name vertraulich ist.
- Abholung auf die Empfängeradressen beschränken: Dann reichen Link und Passwort allein nicht.
Grenzen, die wir offen nennen
- Metadaten wie Dateinamen, Adressen und Zeitpunkte sind für uns lesbar; der Nachweis braucht sie.
- Das Passwort eines Briefkastens durchläuft beim Anlegen einmal unseren Server sowie Microsoft 365 und Hornetsecurity.
- Microsoft und Hornetsecurity sehen, was in unseren Mails steht: Absender, Bezeichnung, Ihre Nachricht, den Link und Zeitpunkte – keine Dateinamen und nie das Passwort einer Sendung.
- Die Prüfung beim Senden des Outlook-Add-ins liefert Cloudflare aus, damit der Mailversand nicht von der Erreichbarkeit unseres Servers abhängt. Cloudflare sieht dabei IP-Adresse und Browserkennung, keine Inhalte.
- Die Prüfsumme jeder Datei ist für uns lesbar. Sie verrät keinen Inhalt, zeigt aber, ob eine bereits bekannte Datei übertragen wurde.
- Wie bei jeder Verschlüsselung im Browser setzt der Schutz neuer Sendungen voraus, dass der Code der Webanwendung unverändert ausgeliefert wird – deshalb schützen wir den Server selbst besonders.
Sicherheitslücke gefunden? Bitte vertraulich an die Adresse aus unserer security.txt.