Wie fepli Teilnehmerdaten Ende-zu-Ende verschlüsselt
Ein Mandant kann die Daten seiner Teilnehmer:innen so verschlüsseln, dass nur die Browser von Team, Veranstalter:innen und Familien sie lesen. Der Server von fepli speichert und verschickt sie, ohne sie zu kennen.
Wovor die Verschlüsselung schützt
In fepli stehen Namen und Geburtsdaten von Kindern, Hinweise auf Allergien oder Medikamente und die Anschriften ihrer Familien. Ohne Verschlüsselung liegen diese Angaben lesbar in der Datenbank, in ihren Sicherungen und in jedem Archiv. Wer eins davon in die Hand bekommt, kann sie lesen.
Eine Verschlüsselung auf dem Server hilft dagegen wenig. Der Server braucht dann den Schlüssel, und wer den Server übernimmt, liest den Schlüssel mit. fepli verschlüsselt deshalb im Browser der Menschen, die mit den Daten arbeiten. Auf dem Server kommen die Angaben nur verschlüsselt an.
Die Verschlüsselung ist eine Entscheidung des Mandanten, wie der erweiterte Datenschutz bei iCloud oder FileVault auf dem Mac. Ein Mandant, der sie nicht einschaltet, arbeitet weiter wie bisher. Wer sie einschaltet, übernimmt Verantwortung: Gehen alle Schlüssel und das Notfall-Kit verloren, kann niemand die Daten wiederherstellen, auch fepli nicht.
Was sieht der Server, und was nicht?
- Pseudonym und Alter jeder Anmeldung
- E-Mail-Adressen, Telefonnummern, Vornamen der Konten
- Angebote und wer wann wo angemeldet ist
- öffentliche Schlüssel und Unterschriften
- Namen, Geburtsdaten, Wichtige Infos, Antworten
- Nachnamen der Familien und Rechnungsadressen
- den Inhalt archivierter Belege und Nachweise
- Passwörter, private Schlüssel, das Notfall-Kit
Der Browser verschlüsselt jeden Wert, bevor er ihn abschickt, und entschlüsselt ihn erst, wenn er ihn anzeigt. Dazwischen hat der Server einen Umschlag: den verschlüsselten Wert und die Schlüssel, mit denen berechtigte Browser ihn öffnen. Selbst öffnen kann er den Umschlag nicht.
Damit Listen, Sortierung und Serienbriefe etwas zu zeigen haben, speichert der Server statt des Namens ein Pseudonym, z. B. „Kind K7Q2“. Statt des Geburtsdatums behält er das Geburtsjahr und für jede Anmeldung das Alter. Schickt der Browser beim Anmelden das Datum mit, rechnet der Server damit genau und verwirft es danach. Das Geburtsjahr selbst ändert nur, wer die Teilnehmer:in bearbeiten darf.
Sichtbar bleibt dem Server, was er für seine Arbeit braucht: E-Mail-Adressen und Telefonnummern für Benachrichtigungen, die Vornamen der Konten für die Anrede, die Angebote und wer wann wo angemeldet ist. Passwörter, private Schlüssel und der Wiederherstellungsschlüssel erreichen ihn nie.
Welche Daten fepli verschlüsselt
Verschlüsselt werden Vorname, Nachname, Geburtsdatum und Wichtige Infos für die Veranstalter:innen einer Teilnehmer:in, die Antworten auf Zusatzfragen, der Nachname eines Teilnahmekontos und die Rechnungsadresse eines Belegs. Belege und Einwilligungsnachweise verschlüsselt der Server, bevor er sie im Archiv ablegt. Die vollständige Liste steht in der Referenz.
Zwei Arten von Antworten bleiben bewusst lesbar, weil der Server mit ihnen rechnet. Eine Auswahl mit Aufpreis bestimmt den Teilnahmebeitrag und steht auf dem Beleg. Eine Ja/Nein-Frage der Saison kann beim Losen über den Vorrang für Berufstätige entscheiden.
Lesbar bleiben die Namen der Konten von Admins und Veranstalter:innen. Verschlüsselt wird, was über Kinder und Familien Auskunft gibt.
Welche Schlüssel gibt es?
Jeder Datensatz hat einen eigenen, zufälligen Datensatzschlüssel. Mit ihm verschlüsselt der Browser jedes Feld mit AES-256-GCM. Das Verfahren bindet jeden verschlüsselten Wert an seinen Datensatz und sein Feld: Wer ihn in einen anderen Datensatz kopiert, erhält beim Öffnen einen Fehler statt eines Werts. Vor dem Verschlüsseln füllt der Browser kurze Werte auf, damit ihre Länge wenig verrät.
Den Datensatzschlüssel verschlüsselt der Browser für jeden, der den Datensatz lesen soll, nach dem Muster von HPKE mit X25519 und HKDF. Leser sind Gruppen und Personen. Der Team-Schlüssel des Mandanten liest alles. Jedes Veranstalter-Profil hat einen eigenen Gruppenschlüssel für die Kinder mit einer Anmeldung bei seinen Angeboten. Hat eine Familie einen eigenen Schlüssel, verschlüsselt der Browser den Datensatzschlüssel ihrer Kinder auch für sie.
Der private Teil des Team-Schlüssels liegt nirgends im Klartext. Er ist für jedes Mitglied verschlüsselt, mit dessen persönlichem Schlüssel, und zusätzlich für den Notfallschlüssel, dessen Code auf dem Notfall-Kit steht. Der persönliche Schlüssel liegt ebenfalls verschlüsselt auf dem Server; öffnen kann ihn nur der Passkey oder das Passwort der Person.
Dazu kommt der Team-Signaturschlüssel, ein Ed25519-Schlüssel. Mit ihm unterschreibt das Team, welche öffentlichen Schlüssel zum Mandanten gehören, und die Aussage, dass der Mandant verschlüsselt. Seinen Fingerabdruck zeigt die Seite Verschlüsselung, und er steht auf dem Notfall-Kit.
Anmelden und Entsperren sind zwei Schritte
Wer sich anmeldet, beweist dem Server, wer er ist. Wer entsperrt, öffnet im eigenen Browser seinen persönlichen Schlüssel. Ein Anmeldelink meldet an, entsperrt aber nichts: Bis zum Entsperren zeigt das Admin-Panel Pseudonyme, und das Schloss in der Kopfzeile bleibt zu.
Entsperrte Schlüssel hält der Browser als Objekte, die sich nicht auslesen lassen. Innerhalb einer Anmeldung öffnet der Browser die Schlüssel beim Neuladen und in weiteren Tabs selbst. Mit dem Abmelden löscht er, was er dafür behalten hat. Auch Anmelden als öffnet keine Schlüssel: Wer im Konto einer anderen Person arbeitet, sieht deren Daten als Pseudonym.
Mit Passkey
Ein Passkey kann mit der Erweiterung PRF ein Geheimnis erzeugen, das zu ihm und zu fepli gehört. Der Browser leitet daraus den Schlüssel ab, der den persönlichen Schlüssel öffnet. Das Geheimnis verlässt den Browser nicht. Nicht jeder Passkey kann das; Passkeys aus iCloud, Google oder 1Password können es.
Mit Passwort
Wo ein Mandant verschlüsselt, schickt kein Browser mehr ein Passwort an den Server. Der Browser berechnet aus Passwort, E-Mail-Adresse und einem Zufallswert des Kontos mit Argon2id einen Hauptschlüssel und leitet daraus zwei Werte ab. Den Anmeldeschlüssel schickt er an den Server, der ihn prüft wie früher das Passwort. Den Entsperrschlüssel behält er; aus dem einen lässt sich der andere nicht berechnen.
Ein Passwort, das der Server früher gesehen hat, gilt dafür nicht mehr. Wer eins hat, legt nach einem Anmeldelink oder Passkey ein neues fest. Ein vergessenes Passwort stellt nur die Anmeldung wieder her; das Konto bekommt einen neuen Schlüssel.
Auf der Website fragt die Registrierung deshalb nach keinem Passwort. Familien registrieren sich mit Passkey oder Anmeldelink und legen ein Passwort danach in ihrem Konto fest. Wer sein Konto löschen will, bestätigt das mit einem Link aus dem Postfach, denn das Passwort kann der Server nicht prüfen.
Warum das Team nur mit Passkey entsperrt
Wer eine Kopie der Datenbank hat, kann ein Passwort offline raten, Versuch für Versuch. Argon2id macht jeden Versuch teuer, ein kurzes Passwort fällt trotzdem. Bei einem Passkey gibt es nichts zu raten. Weil der Team-Schlüssel alle Daten des Mandanten öffnet, entsperren Admins nur mit Passkey.
Veranstalter:innen dürfen auch mit Passwort entsperren. Ihr Schlüssel öffnet nur die Kinder ihrer eigenen Angebote. Viele kommen selten ins Admin-Panel, und manche Geräte haben keinen geeigneten Passkey. Wer keinen Passkey hat, richtet den eigenen Schlüssel deshalb auch mit dem Passwort ein; bestätigt wird er mit demselben Emoji-Vergleich.
Warum es keinen Secret Key gibt
1Password ergänzt das Passwort um einen Secret Key, der nur auf den Geräten der Person liegt. Im Browser geht so ein Schlüssel zu oft verloren: gelöschte Browserdaten, ein neuer Rechner, ein Büro-PC, an dem viele arbeiten. Veranstalter:innen müssten dann bei fast jedem Besuch ein Kit suchen. fepli schützt deshalb den Schlüssel mit dem weitesten Zugriff, den des Teams, mit Passkeys statt mit einem zweiten Geheimnis.
Warum ein Mensch jeden neuen Schlüssel bestätigt
Ein Browser verschlüsselt nur für Schlüssel, die das Team unterschrieben hat. Sonst könnte der Server einen eigenen Schlüssel als neues Teammitglied ausgeben, und der nächste entsperrte Browser gäbe ihm den Team-Schlüssel. Deshalb entscheidet über einen neuen Schlüssel ein Mensch, der die Person kennt.
- 1Kim Beispiel, neuErstellt mit dem Passkey einen persönlichen Schlüssel. Die Anfrage erscheint beim Team.
- 2Robin Beispiel, TeamWählt bei der Anfrage Vergleichen.
- 3Kim Beispiel, neuLegt sich auf einen Einmal-Schlüssel fest, bevor sie den anderen sieht.
- 4BeideVergleichen die 7 Emojis und bestätigen.
- 5Robin Beispiel, TeamUnterschreibt den neuen Schlüssel und verschlüsselt den Gruppenschlüssel dafür.
- Schmetterling
- Schlüssel
- Fahrrad
- Pizza
- Mond
- Gitarre
- Anker
Bestätigt wird mit einem Emoji-Vergleich, wie ihn der Messenger Matrix verwendet. Die Browser der beiden Personen vereinbaren über den Server einen gemeinsamen Wert, ohne ihn dem Server zu verraten, und zeigen daraus 7 Emojis. Die beiden vergleichen sie am Telefon oder nebeneinander. Erst wenn beide bestätigen und die Prüfwerte der Browser passen, unterschreibt der Browser des Teammitglieds den neuen Schlüssel und verschlüsselt den Team-Schlüssel dafür.
Die neue Person legt sich auf ihren Teil fest, bevor sie den der anderen Seite sieht. Ein Server dazwischen hat deshalb genau einen Versuch, passende Emojis zu treffen: Die Chance liegt bei 1 zu 2⁴², rund 1 zu 4 Billionen. Mit dem Vergleich bekommt der Browser der neuen Person auch den Team-Signaturschlüssel und merkt ihn sich. Eine Aussage mit einem anderen lehnt er danach ab.
Bei Veranstalter:innen bestätigt das Team das erste Konto eines Veranstalter-Profils. Dabei erzeugt der Browser des Teammitglieds den Gruppenschlüssel des Veranstalter-Profils, unterschreibt ihn und gibt ihn dem neuen Konto; behalten wird er nicht. Jedes weitere Konto bestätigt eine Kollegin oder ein Kollege aus demselben Veranstalter-Profil.
Wie Veranstalter:innen die Daten ihrer Kinder bekommen
Der Server weiß, welches Kind bei welchem Angebot angemeldet ist, kann aber niemandem Zugang geben: Dafür muss jemand den Datensatzschlüssel öffnen. Das übernimmt der Browser eines Teammitglieds, sobald es entsperrt. Im Hintergrund verschlüsselt er die Datensatzschlüssel der angemeldeten Kinder für die Gruppe des Veranstalter-Profils, aber nur für einen Gruppenschlüssel mit der Unterschrift des Teams.
Meldet sich ein Kind ab oder wechselt ein Angebot das Veranstalter-Profil, löscht der Server den Schlüssel der Gruppe. Wegnehmen kann der Server also jederzeit, geben nie. Bis ein Teammitglied entsperrt hat, sehen Veranstalter:innen das Pseudonym.
Auf demselben Weg bekommt die Gruppe die Schlüssel der Antworten auf Zusatzfragen, die zu Anmeldungen bei ihren Angeboten gehören. Endet die Anmeldung, löscht der Server auch diese Schlüssel der Gruppe.
Was Familien sehen
Auf der Website verschlüsselt der Browser der Familie, was sie über ihre Kinder eingibt, für den Team-Schlüssel. Vorher prüft er die Unterschrift des Teams unter dem Schlüssel. Beim ersten Besuch merkt er sich den Team-Signaturschlüssel der Website; ändert er sich später, speichert er keine Namen und zeigt „Namen können nicht gespeichert werden“.
Hat das Konto der Familie einen eigenen Schlüssel, verschlüsselt der Browser den Datensatzschlüssel auch dafür. Anzeigen kann die Website die verschlüsselten Namen trotzdem nicht. An ihrer Stelle stehen der Avatar des Kindes und „Name hinterlegt“, in Sätzen „Ihr Kind“. Wer einen Namen ändern will, gibt Vor- und Nachnamen neu ein. Andere verschlüsselte Angaben wie das Geburtsdatum zeigen die Formulare der Familie gesperrt; ändern kann sie das Team.
Pseudonyme und Avatare
Das Pseudonym besteht aus „Kind“ und 4 Zeichen, die fepli aus einem Hash der Kennung des Datensatzes bildet. Geschwister lassen sich so unterscheiden, eine Person erkennt daran niemand. Die Zeichen sind kein Schlüssel und verraten nichts über das Kind.
Mit der App Avatare bekommt jede Teilnehmer:in ein gezeichnetes Gesicht, das fepli ebenfalls aus der Kennung erzeugt. Es sieht auf jeder Seite und in jeder E-Mail gleich aus. Wo der Name fehlt, erkennen Familien ihre Kinder daran.
Was sich im Alltag ändert
Der Server kann nach verschlüsselten Namen weder suchen noch sortieren; er kennt nur das Pseudonym. Exporte, die der Server erstellt, lassen verschlüsselte Spalten leer. Die Altersgrenze eines Angebots prüft er mit dem Geburtsdatum, wenn der Browser es beim Anmelden mitschickt, sonst mit dem Geburtsjahr. Das Jahr lässt zwei Alter offen; passt eins davon, nimmt das Angebot das Kind. Ist kein Alter bekannt, nimmt ein Angebot mit Altersgrenze das Kind nicht.
Eine E-Mail nennt ein Kind nur dann beim Namen, wenn eine Person mit offenem Schloss sie auslöst, etwa eine Rundmail oder die Zulassungsbescheide. Ihr Browser schickt die Vornamen mit, und der Server verwirft sie nach dem Versand. Was Benachrichtigungen von selbst verschicken, sagt „Ihr Kind“ und zeigt den Avatar. Im Postausgang stehen statt der Namen Platzhalter, die das Admin-Panel nach dem Entsperren füllt.
Belege und Einwilligungsnachweise liegen im Archiv so gesperrt, dass sie niemand löschen oder überschreiben kann. Lesen ließen sie sich bisher. Jetzt verschlüsselt der Server jede Datei mit den öffentlichen Schlüsseln von Team, Notfall-Kit und betroffenem Konto, bevor er sie ablegt. Geöffnet wird sie im Browser. Was vor dem Einschalten im Archiv lag, bleibt bis zum Ende seiner Sperre unverschlüsselt.
Über die API gibt fepli die Namen nur versiegelt heraus. Eine Integration, die sie braucht, erzeugt einen eigenen Schlüssel, und ein Super-Admin bestätigt ihn mit demselben Emoji-Vergleich wie bei Kolleg:innen. Dabei legt er fest, ob sie alle Teilnehmer:innen liest oder die Kinder eines Veranstalter-Profils. Kann eine Integration nicht selbst verschlüsseln, läuft neben ihr der API-Connector, ein Docker-Image mit ihrem Schlüssel.
Einen Gruppenschlüssel bekommt die Integration nicht. Ein Browser des Teams versiegelt ihr jeden freigegebenen Datensatzschlüssel einzeln. Deshalb nimmt der Server ihren Zugang jederzeit allein zurück, ohne dass das Team neue Schlüssel braucht. Wie eine Integration das umsetzt, beschreiben die fepli developers.
Was der Support sieht
In einer Installation mit mehreren Mandanten betreuen globale Admins alle Mandanten. Personendaten eines fremden Mandanten sehen sie maskiert, bis dessen Admins einen Datensatz befristet freigeben. Bei einem Mandanten, der verschlüsselt, reicht das nicht: Der Server hat nur das Pseudonym, und eine Freigabe allein zeigt dem Support „Kind K7Q2“.
Deshalb hat jede Person im Support einen eigenen Support-Schlüssel. Sie erzeugt ihn einmal mit ihrem Passkey; er gilt für alle Mandanten. Jeder Mandant bestätigt ihn einmal mit demselben Emoji-Vergleich wie bei Kolleg:innen und unterschreibt ihn mit dem Team-Signaturschlüssel. Erst dann verschlüsselt ein Browser des Teams etwas dafür.
Gibt ein Admin mit offenem Schloss einen Datensatz frei, verschlüsselt sein Browser den Datensatzschlüssel zusätzlich für jeden bestätigten Support-Schlüssel. Das tut er nur für den einen Datensatz, dessen Namen er im Dialog selbst entschlüsselt hat. Ein Datensatz hat genau einen Schlüssel, und der öffnet alle verschlüsselten Felder. Die Umfänge der Freigabe unterscheiden sich deshalb nur in Angaben, die ohnehin im Klartext liegen. Endet die Freigabe, löscht fepli den Schlüssel für den Support. Was der Support bis dahin gelesen hat, kann die Verschlüsselung nicht zurückholen.
Wozu das Notfall-Kit dient
Verlieren alle Admins ihre Passkeys, ist der Team-Schlüssel ohne Notfall-Kit verloren und mit ihm alle Daten. Das Kit ist ein Blatt nach dem Vorbild des Emergency Kit von 1Password: Code, QR-Code, Fingerabdruck und Platz für den Ort der Aufbewahrung. Der Browser erzeugt es; der Code wird nie hochgeladen. Jeder Mandant hat genau ein gültiges Kit.
Der Code hat ein Präfix und eine Prüfziffer, damit ein Tippfehler auffällt, bevor etwas versucht wird. Beim Einschalten gibt die Person 4 Zeichen aus dem Kit zurück; so steht fest, dass sie es heruntergeladen hat. fepli bekommt den Schlüssel nie zu sehen und verwahrt keine Kopie. Sind alle Exemplare des Kits verloren und hat kein Admin mehr Zugang, bleiben die Daten verschlossen.
Anders als bei 1Password braucht das Kit kein Passwort: Der Code allein öffnet den Notfallschlüssel. Damit ein gestohlener Ausdruck nicht reicht, verlangt die Wiederherstellung zusätzlich einen Link aus dem Postfach des Kontos, das den Code eingibt. Der Server erfährt dabei nur eine Kennung des Kits, nie den Code.
Bevor der Browser den geöffneten Team-Schlüssel mit einem neuen Passkey verbindet, bestätigt die Person, dass sein Fingerabdruck Zeichen für Zeichen mit dem auf dem Kit übereinstimmt. Erst dann merkt sich der Browser diesen Schlüssel als den des Teams.
Nach einer Wiederherstellung gilt das Kit als verbraucht. Alle Super-Admins und alle Konten mit Zugang zum Team-Schlüssel erfahren es per E-Mail; so merkt ein Team, wenn sein Kit den Tresor verlassen hat. Die Person, die wiederhergestellt hat, erstellt im selben Dialog ein neues Kit.
Ein neues Kit druckt den Fingerabdruck des Team-Schlüssels, den der Browser des Kontos kennt, nicht den, den der Server nennt. Passt beides nicht zusammen, entsteht kein Kit. Ebenso zeigt die Seite Verschlüsselung nach dem Entsperren den Fingerabdruck des Schlüssels, den das Konto kennt; davor kennzeichnet sie den angezeigten als Angabe des Servers.
Grenzen
Was fepli verlässt, schützt die Verschlüsselung nicht mehr: E-Mails im Postfach der Familie, heruntergeladene PDFs, Ausdrucke. Sichtbar bleibt dem Server auch, dass es einen Datensatz gibt, wann er sich geändert hat und zu welchem Angebot eine Anmeldung gehört. Sicherungen der Datenbank von vor dem Einschalten enthalten die Daten weiter lesbar, bis sie ablaufen.
Anwenden
- Verschlüsselung aktivieren
- Zugang zu verschlüsselten Daten einrichten
- Zugangsanfrage per Emoji-Vergleich bestätigen
- Neues Notfall-Kit erstellen
- Zugang mit dem Notfall-Kit wiederherstellen
- Integration Zugang zu verschlüsselten Daten geben
- Datensatz für den Support freigeben
- Verschlüsselung
- Warum fepli Passkeys empfiehlt