Ein PDF-Berechtigungs-Flag ist kein Schloss. Es ist eine Bitte, die die Datei an das öffnende Programm stellt, und ein Betrachter kann sie ignorieren. Diese Tatsache bestimmt, wie alle anderen Entscheidungen auf dieser Seite bewertet werden sollten. Echte Vertraulichkeit kommt nur aus einer Quelle: AES-256-Verschlüsselung, geschützt durch ein Passwort, das der Leser nicht besitzt. Alles andere, die Kontrollkästchen „Kein Drucken" und „Kein Kopieren", ist eine Richtlinie, der konforme Software zustimmt und feindliche Software nicht. Wer diese beiden Ebenen verwechselt, liefert etwas aus, das in einer Demo sicher wirkt und im Einsatz leckt
HotPDF ist eine native VCL-PDF-Komponente für Delphi und C++Builder, die das ISO 32000-Schutzmodell über eine kleine Menge von Eigenschaften zugänglich macht. Die Eigenschaften sind leicht zu setzen. Das Schwierige ist zu wissen, welche kryptografischen Schutz bietet und welche nur eine höfliche Empfehlung ausspricht, und die Zuweisungsreihenfolge so hinzubekommen, dass die gewünschte Verschlüsselung tatsächlich die erhaltene ist
Was die zwei Passwörter wirklich versprechen
PDF-Verschlüsselung definiert zwei Zugangsdaten mit unterschiedlichen Aufgaben, und sie zu verwechseln ist der häufigste Entwurfsfehler bei Code für geschützte Ausgaben. Das Benutzerpasswort kontrolliert die Entschlüsselung. Ohne dieses oder das Inhaberpasswort kann ein konformer Betrachter den Dateischlüssel nicht rekonstruieren, und der Inhalt bleibt kryptografisch unlesbar. Das Inhaberpasswort kontrolliert stattdessen die Berechtigungseinstellungen: Ein Betrachter, der das Inhaberpasswort erhält, bekommt unabhängig von den Einschränkungs-Flags vollen Zugang
Die Berechtigungs-Bits stehen auf schwächerem Boden. Drucken, Inhaltsextraktion, Formularausfüllen: jedes ist ein Flag, das ein Betrachter liest und zu respektieren wählt (ISO 32000-2 §7.6.4). Verschlüsselung schützt die Bytes. Die Berechtigungs-Flags weisen nur konforme Software an, und das erst nachträglich. Jeder, der das Dokument mit dem Benutzerpasswort öffnet, hält den entschlüsselten Inhalt bereits im Speicher, sodass „Kein Kopieren" und „Kein Drucken" für einen wohlverhaltenen Betrachter etwas bedeuten und für einen entschlossenen nichts. Das Bedrohungsmodell sollte auf dieser Grundlage aufgebaut werden. Vertraulichkeit liegt im Benutzerpasswort. Berechtigungen bestimmen, was Mainstream-Betrachter anbieten, und das ist der gesamte Umfang dessen, was sie tun
Konfigurationsreihenfolge: alles vor BeginDoc
HotPDF erstellt das Verschlüsselungs-Dictionary und leitet den Dateischlüssel beim Aufruf von ab. Was die Schutzeigenschaften zu diesem Zeitpunkt enthalten, ist das, was das Dokument erhält; sie danach zu ändern, ändert nichts. Die hier am wichtigsten Eigenschaft ist , die das Schema aus den -Werten , , und auswählt. Nach zugewiesen erhält man keine Ausnahme, keine Warnung, nur eine Datei, die stillschweigend bei dem bleibt, womit sie gestartet ist. Diese Art von stillschweigender Abweichung ist die schlimmste: Sie besteht jeden lokalen Test und taucht Monate später als Compliance-Befund 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; // must be set before BeginDoc
Pdf.UserPassword := 'open-secret';
Pdf.OwnerPassword := 'admin-secret';
Pdf.UseAES256R6 := False; // R=5: widest viewer support
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 dem ISO 32000-2-Limit für AES-256-Schemata entspricht. Wenn die eigene Passwortrichtlinie längere Geheimnisse liefert, sollte die Kürzung selbst durchgeführt werden, auf der eigenen Seite, wo exakt kontrolliert wird, wo der Schnitt fällt. Dem Zufall überlassen, können die Bibliothek und ein zukünftiger Betrachter über den Kürzungspunkt uneinig sein, was eine Datei produziert, die sich für den Ersteller öffnet und das gleiche Passwort anderswo verweigert
Revision 5 oder Revision 6: ein Boolean, zwei Ökosysteme
UseAES256R6FalseTrue
Revision 6 ist also kryptografisch die bessere Wahl. Sie ist auch die, die Probleme verursacht. Eine Revision-6-Datei benötigt einen Betrachter, der für PDF 1.7 Extension Level 3 oder PDF 2.0 entwickelt wurde, und viel eingesetzte Software ist beides nicht: Archivierungssysteme für Aufzeichnungen, eingebettete Renderer in anderen Produkten, branchenspezifische Werkzeuge, die seit Jahren niemand angefasst hat. Diese werden die Datei vollständig ablehnen, und zwar auf dem Rechner des Kunden, nie auf dem eigenen. Die praktische Standardeinstellung ist daher Revision 5. Revision 6 sollte nur gewählt werden, wenn eine Sicherheitsrichtlinie ISO 32000-2 explizit nach Revision nennt und wenn tatsächlich bestätigt wurde, dass jeder Verbraucher sie lesen kann. In jedem Fall sollte aufgeschrieben werden, welche gewählt wurde und warum, denn die nächste Person, die diesen Code anfasst, wird sich fragen
Die älteren Schlüsseltypen verdienen einen Satz, damit klar ist, sie zu überspringen. listet noch , und , aber sie existieren, um historische Archive zu reproduzieren, nicht um neue zu schützen. 40-Bit-RC4 fällt handelsüblicher Hardware zum Opfer, und die 128-Bit-Schemata stammen aus der Zeit vor den AES-256-Revisionen, die jede aktuelle Sicherheitsprüfung erwartet. Für ein 2026 erstelltes Dokument lautet die eigentliche Frage nur Revision 5 versus Revision 6; wer sich bei einem neuen Entwurf nach den Legacy-Typen greift findet, bei dem ist irgendwo vorgelagert etwas schiefgelaufen
Berechtigungs-Flags ohne Öffnungspasswort
Oft ist die Anforderung das Gegenteil von Geheimhaltung. Jeder soll das Dokument lesen können, aber Drucken oder Extraktion soll eingeschränkt sein. Das wird mit einem leeren Benutzerpasswort und einem nicht leeren Inhaberpasswort ausgedrückt, was PDF als Öffnungspasswort-Modus bezeichnet, und die erlaubten Operationen werden in aufgelistet
Pdf.ActivateProtection := True;
Pdf.CryptKeyLength := aes256;
Pdf.UserPassword := ''; // anyone can open the file
Pdf.OwnerPassword := 'rotate-me-quarterly'; // guards the permission set
Pdf.ProtectOptions := [prPrint, prPrint12bit, prExtractContent];
Pdf.BeginDoc;
// ... page content ...
Pdf.EndDoc;Das -Set entspricht den ISO-Berechtigungs-Bits: und für hochauflösendes Drucken, für allgemeines Kopieren und Extraktion, für Extraktion durch Hilfstechnologien, sowie , , und . Zwei verdienen eine Warnung. sollte in fast jedem erstellten Profil aktiviert bleiben. Es ist das Bit, das ein Screenreader benötigt, um an den Text zu gelangen, und es zu deaktivieren verwandelt eine Berechtigungsentscheidung stillschweigend in einen Zugänglichkeitsfehler, der jemanden mit einer Behinderung trifft und nie gesehen wird. Die andere Falle ist allein ohne : mehrere Betrachter reagieren darauf, indem sie die Druckqualität verringern, und Benutzer melden das als Rendering-Fehler statt als die Berechtigungseinstellung, die es tatsächlich ist
Die Überprüfung dauert fünf Minuten und gehört in die Release-Checkliste. Eine Stichprobe jedes Profils in Acrobat öffnen, Dokumenteigenschaften öffnen und den Sicherheits-Tab lesen, der den Algorithmus aufschlüsselt („AES 256-Bit") und die erlaubten Operationen einzeln auflistet. Dann dieselbe Datei im ältesten Betrachter öffnen, den Kunden tatsächlich verwenden, nicht dem neuesten auf dem eigenen Rechner. Dieser zweite Öffnungsvorgang ist die günstige Versicherung gegen eine Revision-6-Datei, die die gesamte Entwicklung übersteht und bei einem Kunden stirbt, der nie aktualisiert hat
Schutz aus bestehenden Dateien entfernen
Die Entschlüsselung folgt demselben Eigenschaftsmodell rückwärts. Das Dokument mit einem gültigen Zugangsdaten laden, Schutz deaktivieren und das Ergebnis ohne ihn speichern
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; // drop encryption on save
Pdf.SaveLoadedDocument('plain.pdf');
end;
finally
Pdf.Free;
end;
end;Dieser Weg parst das gesamte Dokument in den Speicher, was für gewöhnliche Dateien in Ordnung und für sehr große verschwenderisch ist. Wenn die Eingabe Hunderte von Megabytes umfasst, ist die kostengünstigere Option: Es entschlüsselt während einer Kopie auf Dateiebene und nimmt einen direkten AES-256-Neuschreibepfad, der das Aufbauen des vollständigen Objektbaums überspringt, wo die Eingabe es erlaubt. Es ist Teil der Direct File API, die im Begleitartikel zur Verarbeitung großer PDFs aus Delphi behandelt wird
Einschränkungen, die mit Verschlüsselung interagieren
Zwei Grenzen sollten bekannt sein, bevor das Design um Verschlüsselung herum erfolgt und nicht danach. Die erste ist die Archivkonformität. ISO 19005 verbietet Verschlüsselung in , sodass jeder Workflow, der ein Dokument verschlüsselt und gleichzeitig PDF/A-Konformität beansprucht, konstruktionsbedingt widersprüchlich ist; HotPDF erlaubt es nicht, beides in einer Datei zu haben. Wenn beides tatsächlich benötigt wird, lautet die Antwort zwei Artefakte: eine verschlüsselte Kopie für die Verteilung und eine separate unverschlüsselte Kopie für das Archiv
Die zweite Grenze ist drastischer. PDF-Verschlüsselung hat kein Treuhandsystem und keine Wiederherstellung. Das Benutzerpasswort einer R5- oder R6-Datei verlieren, und die Optionen sind Brute Force oder Aufgeben. Daher sollten Inhaber- und Benutzergeheimnisse wie jedes andere Produktions-Zugangsdaten behandelt werden. Generieren, in einem Tresor speichern, nach Plan rotieren. Das Einzige, was niemals getan werden darf, ist sie als Konstanten in einem Unit hartkodieren, wo sie direkt in die Versionsverwaltung gelangen und für immer in jeder Arbeitskopie eines Entwicklers sitzen
FAQ: Schutz von PDFs aus Delphi heraus
Verhindert die Deaktivierung von prInformationCopy, dass andere Text kopieren?
Es verhindert, dass konforme Viewer Kopierbefehle bereitstellen. Jeder, der das Dokument öffnen kann, hat den Klartext bereits im Speicher, daher sollte dieses Flag als Workflow-Richtlinie und nicht als Schutz vor Datenverlust betrachtet werden
Sollte ein neues Projekt UseAES256R6 aktivieren?
Home · Suche · losLab.com
Kann ich die Berechtigungen von PDFs ändern, die ich nicht selbst erstellt habe?
Ja. Laden Sie es mit Passwort über , passen Sie oder das Passwort an und schreiben Sie das Ergebnis mit wie im obigen Entschlüsselungsbeispiel aus
Die in diesem Artikel gezeigten Schutzeigenschaften sind Teil der standardmäßigen HotPDF-Komponente für Delphi und C++Builder; die Produktseite bietet eine vollständige Verschlüsselungsreferenz einschließlich der vollständigen Berechtigungsenumeration