Ein PDF-Rechteflag ist kein Schloss. Es ist eine Bitte, die die Datei an alles richtet, was sie öffnet, und ein Viewer darf sie ignorieren. Diese eine Tatsache entscheidet, wie Sie über jede weitere Wahl auf dieser Seite nachdenken sollten. Echte Vertraulichkeit kommt nur von einer Stelle: AES-256-Verschlüsselung, deren Schlüssel an einem Passwort hängt, das der Leser nicht hat. Alles andere, die Kästchen „nicht drucken“ und „nicht kopieren“, ist Richtlinie, an die sich konforme Software zu halten verspricht und feindliche Software nicht. Verwechseln Sie diese beiden Schichten, und Sie liefern etwas aus, das in der Vorführung sicher wirkt und im Feld ausläuft
HotPDF ist eine native VCL-PDF-Komponente für Delphi und C++Builder und legt das Schutzmodell von ISO 32000 über eine kleine Menge von Eigenschaften offen. Die Eigenschaften sind leicht gesetzt. Der schwierige Teil ist zu wissen, welche Ihnen kryptografischen Schutz einbringt und welche nur eine höfliche Empfehlung, und die Zuweisungsreihenfolge so hinzubekommen, dass die Verschlüsselung, um die Sie gebeten haben, auch die Verschlüsselung ist, die Sie bekommen
Was die beiden Passwörter wirklich zusichern
Die PDF-Verschlüsselung kennt zwei Berechtigungsnachweise mit verschiedenen Aufgaben, und sie zu vermengen ist der häufigste Entwurfsfehler in Code für geschützte Ausgaben. Das Benutzerpasswort steuert die Entschlüsselung. Ohne es oder ohne das Besitzerpasswort kann ein konformer Leser den Dateischlüssel nicht rekonstruieren, und der Inhalt bleibt kryptografisch unlesbar. Das Besitzerpasswort steuert stattdessen die Rechteeinstellungen: Ein Leser, der das Besitzerpasswort erhält, bekommt vollen Zugriff, ganz gleich, was die Einschränkungsflags sagen
Die Rechtebits stehen auf schwächerem Grund. Drucken, Inhaltsentnahme, Formularausfüllen: Jedes ist ein Flag, das ein Viewer liest und zu achten beschließt (ISO 32000-2 §7.6.4). Die Verschlüsselung schützt die Bytes. Die Rechteflags weisen nur konforme Software an, und sie tun es im Nachhinein. Wer das Dokument mit dem Benutzerpasswort öffnet, hält den entschlüsselten Inhalt bereits im Speicher, also bedeuten „nicht kopieren“ und „nicht drucken“ einem wohlerzogenen Viewer etwas und einem entschlossenen nichts. Bauen Sie das Bedrohungsmodell um diese Linie herum. Vertraulichkeit lebt im Benutzerpasswort. Rechte formen, was gängige Viewer anbieten, und mehr tun sie nicht
Reihenfolge der Konfiguration: alles vor BeginDoc
HotPDF baut das Verschlüsselungs-Dictionary auf und leitet den Dateischlüssel in dem Moment ab, in dem BeginDoc läuft. Was die Schutzeigenschaften in diesem Augenblick enthalten, bekommt das Dokument, und sie danach zu ändern, ändert nichts. Am wichtigsten ist hier die Eigenschaft CryptKeyLength, die das Verfahren aus den Werten k40, k128, aes128 und aes256 des Typs THPDFKeyType auswählt. Weisen Sie sie nach BeginDoc zu, bekommen Sie keine Ausnahme, keine Warnung, nur eine Datei, die stillschweigend das behalten hat, womit sie begonnen hat. Diese Art von stiller Abweichung ist die übelste: Sie besteht jeden lokalen Test und taucht Monate später als Prüfbefund auf dem Schreibtisch eines Kunden auf
var
Pdf: THotPDF;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := 'statement.pdf';
Pdf.ActivateProtection := True;
Pdf.CryptKeyLength := aes256; // muss vor BeginDoc gesetzt werden
Pdf.UserPassword := 'open-secret';
Pdf.OwnerPassword := 'admin-secret';
Pdf.UseAES256R6 := False; // R=5: breiteste Viewer-Unterstützung
Pdf.BeginDoc;
Pdf.CurrentPage.SetFont('Arial', [], 11);
Pdf.CurrentPage.TextOut(50, 720, 0, 'Account statement, June 2026');
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;Passwörter sind UTF-8 und auf 127 Bytes begrenzt, was die Grenze aus ISO 32000-2 für die AES-256-Verfahren ist. Wenn Ihre Passwortrichtlinie längere Geheimnisse liefert, kürzen Sie selbst, auf Ihrer Seite, wo Sie genau bestimmen, wo der Schnitt fällt. Überlassen Sie es dem Zufall, können die Bibliothek und irgendein künftiger Viewer über die Schnittstelle uneins sein, was eine Datei ergibt, die sich bei Ihnen öffnet und dasselbe Passwort andernorts verweigert
Revision 5 oder Revision 6: ein Boolean, zwei Ökosysteme
UseAES256R6 wählt zwischen den beiden AES-256-Handshakes, und die Wahl wiegt schwerer, als ihr boolescher Typ vermuten lässt. Lassen Sie sie auf False, schreibt HotPDF Revision 5, das AES-256-Verfahren, das als Erweiterung zu PDF 1.7 kam und das Viewer aus etwa fünfzehn Jahren öffnen können. Setzen Sie sie auf True, bekommen Sie Revision 6, die gehärtete Schlüsselableitung, die ISO 32000-2 für PDF 2.0 standardisiert hat und die eine bekannte Schwäche darin schließt, wie Revision 5 das Passwort prüft
Kryptografisch ist Revision 6 also die bessere Geschichte. Sie ist auch die, die Dinge zerbricht. Eine Datei mit Revision 6 braucht einen Viewer für PDF 1.7 Extension Level 3 oder PDF 2.0, und reichlich installierte Software ist weder das eine noch das andere: Archive der Schriftgutverwaltung, eingebettete Renderer in anderen Produkten, Fachanwendungen, die seit Jahren niemand angefasst hat. Die verweigern die Datei rundheraus, und zwar auf der Maschine des Kunden, nie auf Ihrer. Die praktische Vorgabe ist daher Revision 5. Greifen Sie nur dann zu Revision 6, wenn eine Sicherheitsrichtlinie ISO 32000-2 nach Revision benennt und Sie tatsächlich bestätigt haben, dass jeder Konsument sie lesen kann. So oder so: Halten Sie fest, wofür Sie sich entschieden haben und warum, denn die nächste Person an diesem Code wird sich wundern
Die älteren Schlüsseltypen verdienen einen Satz, damit Sie sie überspringen. THPDFKeyType führt weiterhin k40, k128 und aes128, doch sie existieren, um historische Archive nachzubilden, nicht um neue zu schützen. RC4 mit 40 Bit fällt handelsüblicher Hardware zum Opfer, und die 128-Bit-Verfahren stammen aus der Zeit vor den AES-256-Revisionen, die jede aktuelle Sicherheitsprüfung erwartet. Für ein Dokument, das Sie 2026 erzeugen, lautet die eigentliche Frage nur Revision 5 gegen Revision 6; wenn Sie bei einem neuen Entwurf zu den alten Typen greifen, ist irgendwo weiter oben etwas schiefgelaufen
Rechteflags ohne Öffnungspasswort
Oft lautet die Anforderung das Gegenteil von Geheimhaltung. Jeder soll das Dokument lesen können, doch Drucken oder Entnahme sollen begrenzt sein. Das drücken Sie mit einem leeren Benutzerpasswort und einem nicht leeren Besitzerpasswort aus, was PDF den Modus mit Öffnungspasswort nennt, und Sie führen die erlaubten Vorgänge in ProtectOptions auf
Pdf.ActivateProtection := True;
Pdf.CryptKeyLength := aes256;
Pdf.UserPassword := ''; // jeder kann die Datei öffnen
Pdf.OwnerPassword := 'rotate-me-quarterly'; // schützt den Rechtesatz
Pdf.ProtectOptions := [prPrint, prPrint12bit, prExtractContent];
Pdf.BeginDoc;
// ... Seiteninhalt ...
Pdf.EndDoc;Die Menge THPDFProtectOptions bildet auf die Rechtebits der ISO ab: prPrint und prPrint12bit für den Druck in hoher Auflösung, prInformationCopy für allgemeines Kopieren und Entnehmen, prExtractContent für die Entnahme durch assistive Technik, dazu prModifyStructure, prEditAnnotations, prFillAnnotations und prAssemble. Zwei davon verdienen eine Warnung. Lassen Sie prExtractContent in nahezu jedem Profil, das Sie bauen, gesetzt. Es ist das Bit, das ein Screenreader braucht, um an den Text zu kommen, und es zu löschen verwandelt eine Rechteentscheidung still in einen Barrierefreiheitsmangel, auf den ein Mensch mit Behinderung stößt und den Sie nie sehen. Die andere Falle ist prPrint allein, ohne prPrint12bit: Mehrere Viewer antworten damit, die Druckqualität herabzusetzen, und Ihre Anwender melden das als Darstellungsfehler statt als die Rechteeinstellung, die es tatsächlich ist
Die Prüfung dauert fünf Minuten und gehört in Ihre Freigabecheckliste. Öffnen Sie ein Muster jedes Profils in Acrobat, öffnen Sie die Dokumenteigenschaften und lesen Sie die Registerkarte Sicherheit, die den Algorithmus ausschreibt („AES 256-Bit“) und die erlaubten Vorgänge einzeln auflistet. Öffnen Sie dieselbe Datei dann im ältesten Viewer, den Ihre Kunden wirklich betreiben, nicht im neuesten auf Ihrer Maschine. Dieses zweite Öffnen ist die billige Versicherung dagegen, dass eine Datei mit Revision 6 durch die Entwicklung segelt und bei einem Kunden stirbt, der nie aktualisiert hat
Schutz aus vorhandenen Dateien entfernen
Die Entschlüsselung läuft über dasselbe Eigenschaftsmodell rückwärts. Laden Sie das Dokument mit einem gültigen Nachweis, schalten Sie den Schutz ab und speichern Sie das Ergebnis ohne ihn
var
Pdf: THotPDF;
PageCount: Integer;
begin
Pdf := THotPDF.Create(nil);
try
PageCount := Pdf.LoadFromFile('encrypted.pdf', 'open-secret');
if PageCount > 0 then
begin
Pdf.ActivateProtection := False; // beim Speichern Verschlüsselung fallen lassen
Pdf.SaveLoadedDocument('plain.pdf');
end;
finally
Pdf.Free;
end;
end;Dieser Weg zerlegt das ganze Dokument in den Speicher, was für gewöhnliche Dateien in Ordnung und für riesige verschwenderisch ist. Wenn die Eingabe in die Hunderte von Megabyte geht, ist DecryptFile die günstigere Wahl: Es entschlüsselt während einer Kopie auf Dateiebene und nimmt einen direkten AES-256-Umschreibpfad, der den Aufbau des vollständigen Objektbaums überspringt, wann immer die Eingabe es erlaubt. Es gehört zur Direct File API, die der Begleitartikel zur Verarbeitung großer PDFs aus Delphi behandelt
Einschränkungen, die mit der Verschlüsselung zusammenspielen
Zwei Grenzen sollten Sie kennen, bevor Sie um die Verschlüsselung herum entwerfen, nicht danach. Die erste ist die Archivkonformität. ISO 19005 verbietet Verschlüsselung in PDF/A, also ist jeder Ablauf, der ein Dokument verschlüsselt und zugleich PDF/A-Konformität behauptet, schon vom Bau her widersprüchlich; HotPDF lässt Sie beides nicht in einer Datei haben. Wenn Sie wirklich beides brauchen, lautet die Antwort: zwei Artefakte, eine verschlüsselte Kopie für die Verteilung und eine getrennte unverschlüsselte Kopie für das Archiv
Die zweite Grenze ist härter. Die PDF-Verschlüsselung kennt keine Hinterlegung und keine Wiederherstellung. Verlieren Sie das Benutzerpasswort einer R5- oder R6-Datei, bleiben Ihnen rohe Gewalt oder Aufgeben. Behandeln Sie Besitzer- und Benutzergeheimnisse also wie jeden Produktionsnachweis. Erzeugen Sie sie, legen Sie sie in einem Tresor ab, wechseln Sie sie nach Plan. Das Einzige, was Sie nie tun dürfen, ist, sie als Konstanten in eine Unit zu schreiben, wo sie direkt in die Versionsverwaltung fahren und für immer in der Arbeitskopie jedes Entwicklers liegen
Ein letzter Reflex lohnt sich. Den Schutz einer Datei zu ändern, die Sie nicht erzeugt haben, ist dieselbe Mechanik wie die Entschlüsselung und kein eigenes Feature: mit ihrem Passwort über LoadFromFile laden, ProtectOptions oder die Passwörter an Ort und Stelle bearbeiten und mit SaveLoadedDocument zurückschreiben. Wenn Sie eine Datei entschlüsseln können, können Sie ihre Rechte neu setzen, und der Code sieht dem Beispiel oben fast gleich
Die hier gezeigten Schutzeigenschaften gehören zum Standardumfang der HotPDF Delphi Component für Delphi und C++Builder; die Produktseite führt die vollständige Referenz zur Verschlüsselung samt der kompletten Rechteaufzählung