Sicherheit
Sicherheit und Vertrauensgrenzen
Nicht „vertraut uns“, sondern: Hier liegen die Schlüssel, hier ist, wer sie besitzt, hier ist, wer keinen besitzt – und hier sind die Grenzen des Modells.
Fallinhalte werden bereits im Browser verschlüsselt. Wir besitzen kein Schlüsselmaterial, mit dem wir gespeicherte Fallinhalte entschlüsseln könnten. Wir sehen keine Fallinhalte, aber wir sehen, wer sie lesen darf.
Ein Schlüssel je Fall, ein Umschlag je Person
Wenn ein Melder auf „Absenden“ klickt, erzeugt sein Browser einen frischen Schlüssel, der nur zu diesem einen Fall gehört, und verschließt damit Text, Personenliste und Anhänge. Erst danach geht etwas über die Leitung.
steckt in Umschlägen
- Je zuständige Personöffnet nur sie
- Verwahrerfür den Notfall
- Melder selbstfür den Rückkanal
Jede Person mit Schlüsselzugriff hat einen privaten Schlüssel, der nur auf ihren Geräten liegt. Gesichert wird er mit einem Passkey, einem Hardware-Sicherheitsschlüssel oder einem Passwort mit erzwungener Mindeststärke; für selten benutzte Schlüssel empfehlen wir einen ausgedruckten Wiederherstellungscode.
Deshalb gibt es kein „Passwort vergessen“.
Anderswo setzt ein Anbieter das Passwort zurück, weil sein Server es prüft. Hier entsperrt das Passwort den Schlüssel auf Ihrem Gerät, und einen Schlüssel, der nie auf unseren Servern war, können wir weder zurücksetzen noch herausgeben.
Die öffentlichen Schlüssel, gegen die verschlüsselt wird, stammen aus einem Verzeichnis, das die zuständigen Personen des Kunden signiert haben, nicht aus einer Tabelle auf unserem Server. Ein ausgetauschter Schlüssel würde auffallen.
Was wir sehen
Damit das System Fristen rechnen, zuweisen, zählen und löschen kann, liegt ein bewusst kleiner Satz von Angaben unverschlüsselt vor. Wir nennen ihn Verfahrensmetadaten und zählen ihn auf, statt ihn zu umschreiben.
Für uns sichtbar
- dass es einen Fall gibt, unter welcher Nummer, und zu welcher Gesellschaft er gehört
- Eingangsdatum, Status, Fristtermine und der Tag der letzten Aktivität
- die grobe Kategorie (acht Einträge), Meldeweg, Sprache und ob eine Identität angegeben wurde
- welche Personen einen Fall lesen dürfen, welche Sperren gesetzt und welche Freigaben erteilt wurden
- Löschdatum und Löschsperren, und ob eine Tonaufzeichnung mit Einwilligung existiert
- das Schlüsselverzeichnis mit Rollen und öffentlichen Schlüsseln
Für uns nicht lesbar
- der Text der Meldung
- Namen
- Anhänge
- jede Nachricht im Rückkanal
- Standort und Abteilung – bewusst verschlüsselt
Aus diesen Angaben lässt sich ableiten, dass ein Unternehmen Meldungen bekommt, wie viele und wann, und welche zuständige Person ein Fall betrifft. Deshalb ist der Zugriff darauf bei uns auf wenige Personen beschränkt und wird protokolliert, und deshalb steht diese Liste so auch im Vertrag.
Die Grenzen, die wir dazusagen
Wir liefern den Code aus, der verschlüsselt.
Ein manipulierter Stand unserer Software könnte Schlüssel abziehen. Dagegen stehen strenge Regeln für den Browser, fest verdrahtete Abhängigkeiten, veröffentlichte Prüfsummen und eine offengelegte Kryptospezifikation.
Wir verteilen die öffentlichen Schlüssel.
Ohne das vom Kunden signierte Verzeichnis könnten wir künftige Fälle für uns lesbar machen. Mit ihm fällt ein Austausch auf.
Wir könnten einen Fall einfügen.
Ein Fall, den unser Server selbst anlegt, sähe für die Zuständigen aus wie jeder andere. Das System sichert die Vertraulichkeit einer Meldung, nicht ihre Herkunft.
Das Schlüsselmodell trennt, wer welchen Fall öffnen darf, und hält uns als Betreiber draußen. Es wehrt nicht ab, wer im Unternehmen selbst berechtigt ist und seine Berechtigung missbraucht: Wer das Endgerät einer zuständigen Person verwaltet oder ihr über die Schulter schaut, sieht, was sie sieht; wer ein Amt im System führt, kann die Möglichkeiten dieses Amtes ausnutzen.
Dagegen helfen Arbeitsplatzregeln, die Bestellung geeigneter Personen, das Protokoll, das jeden Schritt nachweisbar macht, und der Umstand, dass ein solcher Zugriff ein belegbarer Pflichtverstoß ist. Eine technische Sperre gegen die eigenen Zuständigen hätte den Betrieb für alle Kunden erschwert, ohne dass das Gesetz sie verlangt.
Wiederherstellung ohne Hintertür
Weil wir nicht entschlüsseln können, liegt die Vorsorge beim Kunden. Jeder Fall ist zusätzlich für einen Verwahrer verschlüsselt, den der Kunde wählt: eine Kanzlei, ein Mitglied der Geschäftsführung oder ein Ausdruck im Safe.
- Schritt 1Der Vertragsadmin gibt einzelne Fälle signiert frei
- Schritt 2Der Verwahrer wirkt mit
- ErgebnisBefristete Entschlüsselung nur der freigegebenen Fälle
Freigegeben wird eine Auswahl von Fällen, nie ein Schlüssel für alle. Im Wiederherstellungsfall erhält der Verwahrer für die freigegebenen Fälle eine befristete Entschlüsselungsmöglichkeit. Wir halten in keiner Variante einen Schlüssel und können eine Freigabe weder erteilen noch erfinden, auch nicht auf behördliche Anordnung.
Löschung und Offenlegung
Was „gelöscht“ heißt
Produktive Daten werden zum vorgesehenen Zeitpunkt gelöscht. Verbleibende verschlüsselte Sicherungskopien unterliegen einer begrenzten Aufbewahrung von etwa einem Monat und werden danach überschrieben. Wird ein älterer Stand zurückgespielt, wird die Löschung darauf nachgezogen, bevor das System wieder in Betrieb geht.
Offengelegt
Das Schlüsselmodell ist in einer eigenen Kryptospezifikation festgelegt. Spezifikation, Referenzimplementierung und Testvektoren sind offengelegt; eine zweite Implementierung kann gegen sie geprüft werden.