Sicherheitsarchitektur
Wie die Datenschutzversprechen von PDF Pro tatsächlich funktionieren.
Alles auf dieser Seite ist in den DevTools Ihres Browsers überprüfbar. Die Grundregel: Wir sollten nicht in der Lage sein, auf Ihre Dateien zuzugreifen — selbst wenn wir wollten. Im Folgenden wird beschrieben, wie diese Regel auf Krypto-, Speicher- und Anfrage-Ebene durchgesetzt wird.
memoryClientseitiges WebAssembly & JS
lockAES-256-GCM
verifiedECDSA P-256
cloud_offClientseitig verschlüsselte Speicherung
Vier architektonische Säulen
Vier technische Entscheidungen definieren die Sicherheitsausrichtung. Sie werden durch den Code durchgesetzt, der in Ihrem Browser ausgeführt wird — nicht durch ein Richtliniendokument.
1. Lokale Verarbeitung zuerst
PDF-Anzeige, Annotation, Formularausfüllung, Komprimierung, Zusammenführung, Konvertierung und Signierung laufen vollständig über WebAssembly und JavaScript in Ihrem Browser ab. Bei diesen Werkzeugen verlassen keine Dateidaten Ihr Gerät — überprüfbar in Ihrem Netzwerk-Tab.
2. Schlüssel clientseitig generiert
Wenn Sie eine Datei teilen müssen, wird der Verschlüsselungsschlüssel von der Web Crypto API innerhalb Ihres Tabs generiert. Er existiert im Speicher, im URL-Fragment oder wird (im Passphrasen-Modus) auf dem Gerät des Empfängers via PBKDF2 abgeleitet. Der Server sieht ihn nie.
3. Clientseitig verschlüsselte Speicherung
Es wird nur AES-256-GCM-Chiffretext mitsamt einem Initialisierungsvektor gespeichert (und im Passphrasen-Modus zusätzlich ein PBKDF2-Salt). Ohne den Schlüssel sind diese Daten kryptografisch nicht von zufälligen Bytes unterscheidbar. Selbst Root-Zugriff auf die Datenbank würde uns bei der Entschlüsselung nicht helfen.
4. Ehrliche KI-Grenze
KI-Tools (Chat, Zusammenfassung, Übersetzung) benötigen lesbaren Text. Wir extrahieren Text clientseitig und senden nur diesen an den Modellanbieter — niemals die PDF-Datei selbst, niemals Bilder, niemals eingebettete Anhänge. Details siehe KI-Abschnitt unten.
Verschlüsselungsablauf (Sicherer Transfer)
Eine Byte-für-Byte-Darstellung dessen, was passiert, wenn Sie eine PDF in Sicherer Transfer ablegen und den entstehenden Link teilen. Jeder Schritt unten läuft im Browser, mit Ausnahme der Speicherung des Chiffretexts.
Sender — im Browser
// 1. generate a fresh 256-bit key
key = crypto.subtle.generateKey({name:"AES-GCM", length:256})
// 2. random 96-bit IV per file
iv = crypto.getRandomValues(new Uint8Array(12))
// 3. encrypt the PDF bytes locally
ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes)
// 4. upload ciphertext + iv — nothing else
id = await fetch("/api/transfer", {method:"PUT", body: ct, headers:{"x-iv": hex(iv)}})
// 5. build the share link with the key in the URL fragment (#)
link = `https://pdfpro.tools/s/<ID>#<KEY>`
▼
Server — speichert nur Chiffretext
ciphertext = opaque bytes // cannot be decrypted without the key
iv = 12-byte nonce
expiry = 24 h (free) / 30 d (Pro)
// the URL fragment (#...) is NEVER sent to the server by browsers
▼
Empfänger — im Browser
// 1. browser loads the page; the "#..." fragment stays client-side
rawKey = location.hash.slice(1)
// 2. fetch the ciphertext
ct = await fetch("/api/transfer/" + id)
// 3. decrypt locally using Web Crypto
pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct)
// 4. file ends up in the recipient's Downloads folder
Die Sicherheitsgarantie hängt entscheidend von Schritt 5 (Sender) und Schritt 1 (Empfänger) ab: Das URL-Fragment nach # wird von keinem konformen Browser an den Server übertragen. Genau das macht den Link selbst zum Entschlüsselungs-Credential.
Der Passphrasen-Modus ersetzt Schritt 1 (Sender) durch PBKDF2-SHA256(passphrase, salt, 310_000). Der Salt wird serverseitig gespeichert; die Passphrase wird mit dem Empfänger auf einem separaten Kanal geteilt.
Signaturablauf (ECDSA P-256)
PDF-Signierung nutzt ECDSA über die NIST-P-256-Kurve. Der private Schlüssel wird in Ihrem Browser generiert; das Dokument verlässt Ihr Gerät nie.
Erzeugung des privaten Schlüssels
Ein ECDSA-P-256-Schlüsselpaar wird in Ihrem Browser über
crypto.subtle.generateKey erzeugt. Der private Schlüssel wird in einen passwortgeschützten JSON Web Key (JWK) exportiert, den Sie lokal speichern können.SHA-256-Hash & Signatur
Die PDF-Bytes werden clientseitig mit SHA-256 gehasht. Dieser Hash wird vom privaten Schlüssel signiert. Die Signatur wird in einem CMS-Container (Profil PAdES-B-B) in die PDF eingebettet.
Offline überprüfbar
Jede Person, die über den öffentlichen Schlüssel verfügt (zusammen mit dem Dokument oder als Fingerabdruck verteilt), kann die Signatur offline überprüfen. Kein Server-Roundtrip erforderlich.
Was es nicht ist
Unsere Signaturen sind kryptografisch überprüfbar, sind jedoch keine qualifizierten elektronischen Signaturen (QES) gemäß eIDAS. Sie sind manipulationssichere Integritätsnachweise, geeignet für interne Arbeitsabläufe, nicht für rechtsverbindliche Anwendungen auf regulatorischem Niveau.
KI-Funktionen — wo wir bei der Grenze ehrlich sind
AI Chat, KI-Zusammenfassung und Übersetzung benötigen lesbaren Text. Hier sehen Sie genau, was Ihr Gerät verlässt und was nicht.
Text im Browser extrahiert
Die PDF wird lokal über pdf.js geparst. Nur der extrahierte Text (bzw. bei gescannten PDFs die OCR-Ausgabe) wird im Speicher gehalten — die Originaldatei bleibt auf Ihrem Gerät.
Nur Text an den Anbieter
Wir senden diese Textzeichenfolge an den KI-Anbieter (Anthropic / OpenAI). Die PDF selbst, eingebettete Bilder, Schriftarten und Formulardaten werden niemals an ein KI-Modell hochgeladen.
Kein Training mit Ihren Inhalten
Unsere Anbieterverträge deaktivieren das Training mit Kundendaten. Anfragen sind zustandslos — jede ist auf Ihre Sitzung beschränkt.
Wann das wichtig ist
Wenn Ihr Dokument regulierte Inhalte enthält (PHI, Verschlusssachen, Anwaltsgeheimnis), bei denen selbst die Textextraktion sensibel ist, verzichten Sie auf KI-Funktionen und nutzen Sie die lokalen Werkzeuge (Anzeigen, Annotieren, Signieren, Komprimieren, Konvertieren) — diese arbeiten zu 100 % im Browser.
Bedrohungsmodell — wogegen wir schützen, wogegen wir nicht schützen können
Klarheit über das Bedrohungsmodell ist nützlicher als Marketing. Hier ist, was die Architektur tatsächlich aufhält — und wo sie an ihre Grenzen stößt.
shieldWogegen die Architektur schützt
- PDF-Pro-Mitarbeiter, die Ihre Dateien auf unseren Servern lesen (wir halten den Schlüssel nie).
- Datenbankbasierte Kompromittierung des Transfer-Speichers (Angreifer sieht Chiffretext, keine Dateien).
- Gerichtlich angeordnete Offenlegung von Dateiinhalten (wir können Chiffretext herausgeben — das ist alles, was wir haben).
- Aufbewahrung sensibler Anhänge auf dem Mailserver (es trifft nichts auf Ihrem Mailserver ein).
- Manipulation an einer signierten PDF (die Verifizierung der ECDSA-Signatur erkennt jede Byte-Änderung).
warningWogegen kein browserbasiertes Werkzeug schützen kann
- Ein kompromittiertes Endgerät (Schadsoftware auf Ihrem Gerät) — Schlüssel liegen im Speicher eines Geräts, das vertrauenswürdig sein muss.
- Jemand, der das URL-Fragment über die Schulter mitliest — behandeln Sie den Freigabelink wie die Datei selbst.
- Eine schwache Passphrase im Passphrasen-Modus — PBKDF2 verlangsamt Brute-Force, macht eine 6-Zeichen-Passphrase aber nicht sicher.
- Ein Empfänger, der eine entschlüsselte Datei weiterleitet — Transportsicherheit endet, sobald der Empfänger die PDF speichert.
- Eine Kompromittierung des Browsers selbst oder eine bösartige Erweiterung, die Code in die Seite injiziert.
Keine Behauptungen, „unknackbar" zu sein. Ende-zu-Ende-Verschlüsselung erhöht die Kosten eines Vorfalls erheblich — sie eliminiert nicht jedes Risiko, insbesondere am Endpunkt. Kombinieren Sie für besonders sensible Fälle Sicheren Transfer mit einer separaten Passphrase und einem Schlüsselaustausch über einen vertrauenswürdigen Kanal.
Weiterführende Lektüre
Häufig gestellte Fragen
Kann PDF Pro meine Dateien entschlüsseln?
Nein. Verschlüsselungsschlüssel werden im Browser des Nutzers erzeugt und dort gehalten. Beim Sicheren Transfer speichert der Server nur AES-256-GCM-Chiffretext sowie einen Initialisierungsvektor (im Passphrasen-Modus zusätzlich ein Salt). Der Schlüssel erreicht unsere Infrastruktur nie. Selbst mit vollständigem Datenbankzugriff können unsere Mitarbeitenden Ihre Datei nicht entschlüsseln.
Was läuft genau lokal und was auf dem Server?
Anzeigen, Annotieren, Formularausfüllen, Komprimieren, Zusammenführen, Konvertieren und Signieren laufen zu 100 % über WebAssembly und JavaScript in Ihrem Browser — keine Dateidaten verlassen Ihr Gerät. KI-Funktionen (Chat, Zusammenfassung, Übersetzung) extrahieren Text lokal und senden nur diesen Text (niemals die PDF selbst) an den Modellanbieter.
Welche Algorithmen verwendet PDF Pro?
AES-256-GCM für symmetrische Verschlüsselung (Sicherer Transfer), PBKDF2-SHA256 mit 310.000 Iterationen für aus Passphrasen abgeleitete Schlüssel, ECDSA über NIST P-256 für digitale Signaturen und SHA-256 für Dokument-Hashing. All dies läuft über die native Web Crypto API des Browsers, die geprüft, standardisiert und nicht von uns implementiert ist.
Ist das eine rechtsverbindliche elektronische Signatur?
Die Signaturen von PDF Pro sind kryptografisch überprüfbar (ECDSA P-256 über einen SHA-256-Hash, Profil PAdES-B-B), sind jedoch keine qualifizierten elektronischen Signaturen (QES) gemäß eIDAS oder gleichwertigen Vorschriften. Für rechtsverbindliche QES wird ein zertifizierter Vertrauensdiensteanbieter benötigt.
Was passiert, wenn ich eine Passphrase vergesse oder einen Freigabelink verliere?
Die Datei ist dauerhaft nicht wiederherstellbar. Das ist der Kompromiss der Ende-zu-Ende-Verschlüsselung — es gibt keinen Wiederherstellungspfad, weil wir den Schlüssel nie hatten. Speichern Sie die Passphrase in einem Passwortmanager und den Link an einem dauerhaften Ort.
Führen Sie serverseitige Protokolle über Dateiaktivitäten?
Wir führen Betriebsprotokolle (Anfragezeiten, Fehlercodes, IP-Adressen zur Ratenbegrenzung), jedoch niemals Klartext-Dateiinhalte oder Verschlüsselungsschlüssel. Die Protokolle werden nach einem kurzen Zeitplan aufbewahrt — die aktuellen Aufbewahrungsfristen finden Sie in unserer Datenschutzerklärung.
Kann eine gerichtliche Anordnung Sie zwingen, meine Dateien offenzulegen?
Wir können nur das herausgeben, was wir haben: Chiffretext. Ohne den Entschlüsselungsschlüssel — der auf dem Gerät des Senders oder im URL-Fragment des Empfängers verbleibt — ist dieser Chiffretext nicht entschlüsselbar. Eine Anordnung kann keinen Schlüssel rückwirkend wiederherstellen, den wir nie gespeichert haben.
Wo kann ich die kryptografischen Aussagen selbst überprüfen?
Öffnen Sie die DevTools Ihres Browsers → Netzwerk-Tab und beobachten Sie, was die Seite während eines Sicheren-Transfer-Uploads verlässt. Sie sehen Chiffretext, der per PUT an den Server gesendet wird, nicht die Original-PDF. Der Verschlüsselungscode ruft die Web Crypto API auf, die in Ihrem Browser eingebaut ist — nicht in unserem Code — und von jedem überprüft werden kann.
Datenschutz als Architektur, nicht als Marketing.
Probieren Sie einen Sicheren Transfer aus und inspizieren Sie den Netzwerk-Tab selbst. Es werden niemals Dateien im Klartext hochgeladen.
lockSicheren Transfer ausprobieren