Vom Upload ins IPFS: Wie ratum Dokumente signiert, versiegelt und verschlüsselt archiviert

Wer einen Vertrag online unterschreiben lässt, gibt ihn aus der Hand. Er liegt danach irgendwo auf dem Server eines Anbieters, und meistens erfährt man nicht, wer ihn dort lesen kann, wie lange er bleibt und was beim Löschen wirklich passiert. Für ein KMU, das Arbeitsverträge, Offerten und Mandate unterschreiben lässt, ist das keine Nebensache.

ratum ist unsere Antwort darauf: eine eSignature-Lösung für kleine und mittlere Unternehmen, fair bepreist, mit Daten in der EU und einem Langzeitarchiv auf IPFS. In diesem Artikel zeige ich, wie das technisch funktioniert: wie ein Dokument hochgeladen, geprüft, signiert, versiegelt und schliesslich verschlüsselt archiviert wird. Ich beschreibe den Ist-Zustand und nenne auch die Stellen, an denen ratum bewusst nicht alles verspricht.

ratum direkt ausprobieren: ratum.ch

Das Problem: Vertrauen ohne Einblick

Bei den meisten E-Signing-Diensten bleibt unklar, was nach dem Klick auf «Senden» geschieht. Dafür gibt es drei Gründe, die uns gestört haben:

• Preismodelle, die nicht zur Nutzung passen. Wer selten unterschreiben lässt, zahlt trotzdem ein Abo.
• Unklare Datenhaltung. Wo das Dokument liegt und wer es entschlüsseln kann, steht selten in verständlicher Form in der Dokumentation.
• Ein Archiv, das dem Anbieter gehört. Verschwindet der Anbieter oder ändert er seine Bedingungen, hängt der Zugriff auf alte Verträge an ihm.

ratum setzt dem ein faires Preismodell, einen Betrieb in der EU und ein Archiv entgegen, in dem der Anbieter nur Chiffrat ablegt. Den Rest dieses Artikels widmen wir der Frage, wie das gebaut ist.

Die Bausteine und die wichtigste Vertrauensgrenze

ratum ist eine klassische Webanwendung: eine React-Single-Page-App im Browser, eine FastAPI-Schnittstelle, ein Celery-Worker für die schweren Aufgaben, PostgreSQL für Metadaten, Redis als Queue und Cloudflare R2 als Zwischenspeicher. Das Archiv liegt bei Filebase, das die Dateien nach IPFS pinnt. Login übernimmt ein zentraler Identity-Provider, E-Mails verschickt unser Projekt SubscribeFlow.

Wichtiger als die Liste der Komponenten ist die Farbe in der Abbildung. Rot markiert, was Klartext sieht: API, Worker und der Zwischenspeicher. Grün markiert, was nur Chiffrat sieht: Filebase und das öffentliche IPFS-Netz. Die entscheidende Vertrauensgrenze verläuft also zwischen ratum und dem Archiv. Was dort ankommt, ist verschlüsselt, bevor es unser System verlässt.

Der Weg eines Dokuments in sieben Stationen

1. Upload in den Zwischenspeicher, Status DRAFT.
2. Virenscan; bei DOCX zusätzlich Konvertierung nach PDF.
3. Der Absender legt Signer und Felder fest und versendet das Dokument.
4. Die Signer unterschreiben nacheinander. Nach der letzten Signatur ist das Dokument SIGNED.
5. Der Worker stempelt die Signaturen ins PDF und versiegelt es (PAdES).
6. Der Worker verschlüsselt das versiegelte PDF und archiviert es bei Filebase; Status ARCHIVED.
7. Nach erfolgreichem Rücklesen werden die Klartext-Kopien gelöscht.

Die Stationen 1 bis 3 sind unspektakulär, aber sicherheitsrelevant. Die Stationen 5 bis 7 sind der Kern dieses Artikels.

Upload, Virenscan und Konvertierung

Der Browser lädt die Datei nicht über unsere API hoch, sondern direkt in den Speicher, über eine zeitlich begrenzte, signierte URL. Die API sieht beim Upload keine Datei-Bytes. Erst danach bestätigt der Browser, und die API prüft per HEAD-Anfrage, ob das Objekt existiert und die erlaubte Grösse nicht überschreitet.

Danach scannt der Worker die Datei mit ClamAV. Der Scan ist fail-closed: Ein Dokument, das nicht gescannt werden konnte, gilt nie als sauber. Bei einem Treffer wird die Datei gelöscht und das Dokument bleibt nur als Eintrag mit Status INFECTED zurück.

DOCX-Dateien wandelt LibreOffice in PDF um, und zwar gehärtet: ohne Netzwerkzugriff, mit Speicher- und CPU-Limits und in einer eigenen Prozessumgebung, die nach dem Job aufgeräumt wird. Ein Office-Parser, der fremde Dokumente verarbeitet, ist eine klassische Angriffsfläche; die Sandbox begrenzt den Schaden.

Signatur und Siegel

Die Signatur läuft sequenziell. Nur der erste Signer ist zunächst aktiv und erhält eine Einladung mit einem eindeutigen Token. In der Datenbank liegt davon nur der Hash. Jede Unterschrift erzeugt einen Audit-Eintrag mit Zeit, IP-Adresse und User-Agent. Erst danach wird der nächste Signer eingeladen.

Sobald die letzte Person unterschrieben hat, übernimmt der Worker:

1. Er stempelt Signaturbilder und Datum an die vorgesehenen Positionen.
2. Er ergänzt eine Fusszeile mit Verifikationscode und QR-Code.
3. Er versiegelt das PDF mit einem unsichtbaren PAdES-Siegel.
4. Er berechnet einen SHA-256-Hash über das versiegelte PDF und hält ihn im Audit-Trail fest.

Das Siegel belegt, dass das PDF seit dem Versiegeln nicht verändert wurde und von ratum stammt. Schon ein angehängtes Byte macht es ungültig. Es ist ein Plattform-Siegel, keine qualifizierte elektronische Signatur (QES). Das sagen wir so deutlich, weil der Unterschied rechtlich zählt. Über eine öffentliche Verifikationsseite kann jede Person ein PDF hochladen und gegen den gespeicherten Hash und das Siegel prüfen.

Das verschlüsselte Archiv

Jetzt zum Teil, der uns am meisten Kopfzerbrechen bereitet hat: Wie archiviert man Verträge langfristig auf einem öffentlichen, dezentralen Netz, ohne dass sie dort lesbar sind?

Envelope-Verschlüsselung in drei Begriffen

Wir verwenden eine zweistufige Schlüsselhierarchie:

• DEK (Data Encryption Key): ein frischer, zufälliger 256-Bit-Schlüssel pro Dokument. Er verschlüsselt genau eine Sache, mit AES-256-GCM.
• KEK (Key Encryption Key): ein einziger Schlüssel für die Plattform. Er verschlüsselt nur die DEKs («wrappen»), nie die Daten.
• AAD (Additional Authenticated Data): ein Kontext, hier die Dokument-ID, der in die Verschlüsselung eingebunden wird.

Daten und Schlüssel liegen an getrennten Orten: das Chiffrat bei Filebase, der gewrappte DEK in unserer Datenbank, der KEK ausschliesslich als Secret der Prozesse. Wer nur eines davon besitzt, kann nichts lesen. Die AAD sorgt zusätzlich dafür, dass sich Chiffrate nicht unbemerkt zwischen Dokumenten vertauschen lassen, weil das Auth-Tag dann nicht mehr passt.

Die Archivierung Schritt für Schritt

Der Ablauf folgt einer einfachen Regel: Nichts wird gelöscht, bevor das Gegenteil bewiesen ist.

• Der Worker vergibt einen pseudonymen Objekt-Key (archives/<zufällige uuid>/sealed.enc). Er enthält weder User- noch Dokument-ID.
• Er verschlüsselt das versiegelte PDF mit einem frischen DEK und wrappt diesen mit dem KEK.
• Er lädt nur das Chiffrat zu Filebase hoch. Filebase pinnt es nach IPFS und vergibt die Content-ID (CID).
• Vor dem Übernehmen der CID prüft er das ETag, damit er nicht versehentlich die CID eines parallelen Laufs übernimmt.
• Er hält CID, gewrappten DEK, Hash und Status in einer Transaktion fest.
• Zuletzt liest er das Archiv zurück, entschlüsselt es und vergleicht den SHA-256. Erst wenn das stimmt, löscht er die Klartext-Kopien im Zwischenspeicher.

Scheitert das Rücklesen, bleiben Original und versiegelte Kopie erhalten. Lieber ein Dokument zu viel behalten als eines verlieren.

Beim späteren Abruf läuft es umgekehrt: Chiffrat holen, DEK unwrappen, entschlüsseln, Hash prüfen. Weicht etwas ab, meldet das System das laut, statt still zu reparieren.

Löschen in einem Netz, das nicht vergisst

IPFS ist inhaltsadressiert und dezentral. Was einmal im Netz ist, lässt sich nicht verlässlich zurückrufen. Für das Recht auf Löschung (DSGVO Art. 17) setzen wir deshalb auf Crypto-Shredding: Beim Löschen eines Dokuments verschwindet der gewrappte DEK aus der Datenbank. Ohne ihn ist das Chiffrat dauerhaft unlesbar, auch wenn es irgendwo im Netz noch existiert.

Das ist eine ehrliche, aber keine absolute Garantie. Datenbank-Backups können den gewrappten DEK noch enthalten, und ob der Inhalt aus dem IPFS-Netz verschwindet, lässt sich bei Filebase nicht garantieren. Eine Backup-Retention-Policy ist als nächster Schritt vorgesehen, aber noch nicht umgesetzt.

Was ratum nicht verspricht

Ein Sicherheitsartikel, der nur Stärken aufzählt, ist Werbung. Deshalb die Grenzen, so wie wir sie intern dokumentieren:

• Kein Zero-Knowledge, kein Ende-zu-Ende. Der Server muss vor der Fertigstellung mit dem Klartext arbeiten: Scannen, Konvertieren, Stempeln und Siegeln gehen nicht mit verschlüsselten Bytes. ratum sieht den Klartext bis zur Archivierung und danach bei jedem Abruf im Arbeitsspeicher der API.
• Wer KEK und Datenbank hat, kann archivierte Dokumente lesen. Der KEK ist ein einziger Schlüssel für die Plattform. Ein Betreiber mit Zugriff auf beides ist im heutigen Modell nicht ausgeschlossen.
• Der Zwischenspeicher ist nicht app-seitig verschlüsselt. Der Schutz dort beruht auf Zugriffsrechten, kurzlebigen URLs und der Verschlüsselung des Anbieters.
• Das Siegel ist keine QES.
• Metadaten wie Dateiname, Signer-E-Mails und Audit-Trail liegen im Klartext in der Datenbank.

Ein Vorschlag, wie wir diese Grenze verschieben könnten, liegt als Architekturentscheid vor: ein optionaler Kundenschlüssel-Modus, bei dem der DEK nicht mit dem KEK, sondern mit einem Schlüssel des Kunden gewrappt würde. Der Status ist «vorgeschlagen», gebaut ist davon nichts. Er hätte auch Nachteile: Bei Schlüsselverlust könnten wir nichts herausgeben.

Darum sprechen wir nach aussen bewusst nicht von «Zero-Knowledge».

Wie es weitergeht

Die Grenzen oben sind kein Dauerzustand, aber auch kein Versprechen mit Datum. Das sind die Richtungen, die wir verfolgen oder prüfen:

• Mehr Vertrauen beim Siegel. Heute ist das Siegel ein Plattform-Siegel. Wir klären, wie weit wir es mit einem Zertifikat einer anerkannten Zertifizierungsstelle, einem qualifizierten Zeitstempel und PAdES-B-LT anheben und was davon die öffentliche Verifikationsseite anzeigen soll. Die Grundsatzfrage dahinter, wo ratum sich bei der qualifizierten Signatur positioniert, ist noch nicht entschieden.
• Ein gehärtetes Archiv. Dazu gehören die Rotation des KEK mit neuem Wrappen der archivierten DEKs und eine dokumentierte, geprüfte Aufbewahrung der Datenbank-Backups.
• Schlüssel näher beim Kunden. Neben dem Kundenschlüssel-Modus prüfen wir eine native Desktop-App für Windows und macOS. Sie könnte Schlüssel im Schlüsselspeicher des Geräts halten und das Problem entschärfen, dass beim Browser der Server selbst den Code ausliefert, der verschlüsseln soll. Auch damit wäre ratum nicht Zero-Knowledge: Signer arbeiten weiterhin im Browser und müssen das Dokument lesen können, und Scan und Siegel brauchen Klartext. Es wäre ein Schritt, die Schlüssel vom Betreiber wegzubewegen, kein Ersatz für die oben genannten Grenzen.

Fazit

Der Weg eines Dokuments durch ratum besteht aus vielen kleinen, einzeln prüfbaren Schritten. Die Schutzwirkung entsteht nicht durch ein einzelnes Verfahren, sondern durch das Zusammenspiel: direkter Upload, fail-closed Scan, Siegel über die ganze Datei, getrennte Ablage von Chiffrat und Schlüssel, Rücklesen vor dem Löschen und Crypto-Shredding statt der Illusion, ein dezentrales Netz leeren zu können.

Warum wir ratum gebaut haben und was es im Early Access bietet, steht im Launch-Artikel.

Probier ratum aus: ratum.ch – faires E-Signing aus der EU, mit verschlüsseltem IPFS-Archiv.