Warum sind PDF-Dokumente mit 9-Bit-AES-Schlüssel gefährdet?

Die geringe Entropie des Schlüssels führt dazu, dass der Schlüssel leicht zu erraten ist und daher der AES-256-Algorithmus nicht ausreichend sicher ist.

Welche Probleme gab es bei der Generierung des Dateikennworts in einigen PDF-Implementierungen?

Bei mindestens vier gängigen PDF-Implementierungen gab es ernsthafte Probleme mit der Generierung des Dateikennworts. Die Zufallsquelle zur Erzeugung des Kennworts entsprach nicht den grundlegenden Sicherheitsanforderungen der Kryptografie.

Hot Tracking 029 | 9-Bit-AES-Schlüssel: Die Krise der mit PDF

Q: Wie wird das Dateikennwort in PDF-Dokumenten generiert?

Das Dateikennwort wird durch das Softwareprogramm generiert und besteht aus einem 32-Bit-Dateikennwort, das mit AES verschlüsselt wird. Anschließend wird dieses Dateikennwort mit dem aus dem Benutzerpasswort abgeleiteten Kennwort verschlüsselt.

Was passiert

Beim Verschlüsseln von PDF-Dokumenten wird der Benutzerpasswort nicht direkt in den Inhalt des Dokuments verschlüsselt. Der Prozess besteht aus zwei Schritten: Das Softwareprogramm generiert zunächst einen 32-Bit-Dateikennwort, das mit AES verschlüsselt wird; anschließend wird dieses Dateikennwort mit dem aus dem Benutzerpasswort abgeleiteten Kennwort verschlüsselt und gespeichert. Wenn der Benutzer das Dokument öffnet, muss er zunächst das abgeleitete Kennwort durch das Passwort berechnen, das Dateikennwort entschlüsseln und anschließend das Dokument mit dem Dateikennwort entschlüsseln. Dieser Designansatz ist in Ordnung und ist auch eine gängige Praxis bei vielen Dokumentenscannungssoftwareprodukten. Das Problem liegt darin, dass die Qualität des Dateikennworts die Grundlage der gesamten Verschlüsselungskette ist. Wenn das Dateikennwort leicht zu erraten ist, dann ist selbst die AES-256-Algorithmus stark nicht hilfreich.

Rick de Jager, ein Forscher bei V12, stellte bei einer Überprüfung fest, dass es bei mindestens vier gängigen PDF-Implementierungen ernsthafte Probleme mit der Generierung des Dateikennworts gab. Das Problem liegt nicht darin, dass der Algorithmusname nicht laut genug ist, sondern darin, dass die Zufallsquelle zur Erzeugung des Kennworts nicht den grundlegenden Sicherheitsanforderungen der Kryptografie entspricht.

Schauen wir uns MuPDF-Versionen vorbei (<1.28.5>). Es verwendet einen drand48-Gleichungssystemgenerator, wobei das Seed ein Sekundenstarkes Unix-Timestamp ist und nur von den Bits 17-24 des Zustands abgezogen werden. Die ersten 16 Bits des Zustands sind fest auf 0x330e gesetzt, sodass nur 9 Timestamp-Bits tatsächlich Einfluss auf die Ausgabe haben. Unterschiede von 512 Sekunden können genau denselben Kennwortstrom erzeugen. Mit einem nicht optimierten Python-Programm kann man alle 512 Möglichkeiten in etwa 11 Millisekunden durchlaufen. Sobald ein Angreifer das Dokument erhält, kann er schnell das richtige Dateikennwort ermitteln. Noch wichtiger ist, dass das /ID-Feld von MuPDF ebenfalls mit demselben LCG generiert wird und als Daten gespeichert ist, was als zusätzlicher Überprüfungsgrund dient und den Suchraum weiter verkleinert.

Foxit PDF Reader 2026.1.3.36551 zeigt ein anderes Problem. Das Dateikennwort wird aus einer Hash-Wertung von „aktuelles Timestamp + 32 uninitialisierten Bytes + Konstanten“ erzeugt. Die sogenannten uninitialisierten Bytes sind in Wirklichkeit leere Zellen, was keine Zufälligkeit bedeutet. Die V12-Rust-Implementierung zeigt, dass auf einem 32-Thread Ryzen 9 7950X pro Sekunde 370-376 Millionen Timestamps getestet werden können. Ein Dokument kann vor 10 Jahren in etwa 0.84 Sekunden geknackt werden, und eine Suche seit der Unix-Epoche dauert nur etwa 4.85 Sekunden. Der /Perms-Block von Foxit enthält bekannte Daten, wobei die Überprüfung nur ein Hash-Aufruf und eine AES-Block-Dekodierung erfordert, was die Angriffskosten weiter senkt.

OpenPDF 3.0.5 und iText 9.7.1 haben ein anderes Problem. Sie ersetzen den eigentlich von einem kryptografisch sicheren Zufallsgenerator bereitgestellten Inhalt durch einen ARC4-Stream über IVGenerator. Das ARC4-Seed besteht aus Millisekunden-Timestamps und freiem JVM-Memory, während der 32-Bit-Salt in den /U- und /O-Files als Daten gespeichert ist und zur Rückrechnung des Timestamps und der Memory-Werte verwendet werden kann. Das bedeutet, dass Angreifer nicht den gesamten Schlüsselraum durchlaufen müssen, sondern nur das Seed nach den in dem Dokument offengelegten Informationen rekonstruieren müssen.

V12 weist außerdem darauf hin, dass das Problemcode-Muster bei Foxit auf die erste öffentliche Veröffentlichung von PDFium im Mai 2014 zurückgeht. Die Dateihöhe von PDFium dankt Foxit, was bedeutet, dass dieses Muster möglicherweise aus Foxit stammt und bereits seit über zehn Jahren existiert. Das heißt, das Problem ist nicht erst kürzlich eingeführt, sondern eine historische Last, die seit langem in der PDF-Ökologie vorhanden ist. Noch beunruhigender ist, dass diese Implementierungen von vielen Nachfolgeprojekten und kommerziellen Produkten abhängig sind. Ein Defekt in einem Grundmodul könnte durch Coderepleite auf eine größere Anzahl von Scenarios ausbreiten.

Hersteller und Behebung

Das Problem wurde den entsprechenden Herstellern mitgeteilt. Die aktuellen Fortschritte sind wie folgt:

MuPDF wurde behoben, betroffene Versionen sind vor 1.28.5.
Der Status der Behebung bei Foxit, OpenPDF und iText muss sich an die jeweiligen offiziellen Ankündigungen richten.
V12 hat Entschlüssler für MuPDF und Foxit veröffentlicht, was beweist, dass die Lücken tatsächlich ausgenutzt werden können.

Es ist wichtig zu betonen, dass bereits erstellte verschlüsselte PDF-Dateien nicht rückwirkend geschützt werden können. Selbst wenn das Software heute behoben wird, könnten Dateien, die in den vergangenen Versionen erstellt wurden, weiterhin knackbar sein. Dies unterscheidet sich von üblichen Lückenpatches: Patches können nur verhindern, dass neue Dateien weiterhin angegriffen werden, während die Behebung alter Dateien bedeutet, sie mit zuverlässigen Tools erneut zu verschlüsseln oder umzuwandeln.

Hier geht es auch um die Frage der Verantwortungsgrenzen. Der PDF-Entschlüsselungsstandard selbst verlangt nicht, dass Implementierungen einen sichern mathematischen Zufallszahlentyp verwenden müssen, noch fordert er, dass der Zufallszahlengenerator ein bestimmtes Entropie-Niveau erreicht. Der Standard legt nur den Algorithmusrahmen fest, während die konkrete Implementierung von den Herstellern bestimmt wird. Infolgedessen ist die Qualität der Implementierungen unterschiedlich, und es ist für Nutzer schwierig, Sicherheitsunterschiede anhand der Benutzeroberfläche oder Funktionennamen zu erkennen. Wenn in den Dokumentattributen „AES-256“ steht, gehen normale Nutzer normalerweise davon aus, dass es sicher genug ist. Diese Informationsasymmetrie führt dazu, dass zwischen der Marketing-Hypothese und der tatsächlichen Wirkung eine große Lücke entsteht.

Ein weiterer wichtiger Punkt ist, dass solche Probleme oft nicht von traditionellen Lücken-Scanning-Tools entdeckt werden. Denn der Code ruft tatsächlich AES-256 ab und speichert den Schlüssel in der Standardformatierung, nur die Zufallsquelle selbst ist unsicher. Statische Analysen und Blackbox-Tests können Schwächen wie „ungünstige Entropie des Schlüssels“ kaum erkennen, da sie spezielle Sicherheitsaudits benötigen, um diese zu enthüllen.

Aus einer anderen Perspektive betrachtet, zeigt die diesmalige Bekanntgabe auch die Risiken der Coderepleite. In der PDF-Ökologie gibt es viele gemeinsam genutzte Implementierungen und Referenzcode. Sobald ein Grundmodul die Verarbeitung von Zufallszahlen nicht sorgfältig handhabt, könnten nachfolgende Tools, die auf ihm basieren, denselben Problemen ausgesetzt sein. Für Unternehmen, die sensible Informationen durch PDF-Entschlüsselung schützen müssen, bedeutet das, dass man nicht einfach den Namen bekanter Hersteller oder etablierter Projekte vertrauen kann, sondern die konkrete Implementierung selbstständig überprüfen muss, ob sie modernen Kryptografie-Anforderungen entspricht.

Was wird in den Kommentaren gesagt

Ein häufig geteilter Kommentar auf Hacker News stammt von tptacek, der darauf hinweist, dass das eigentliche Problem nicht darin liegt, dass „der Schlüssel nur 9 Bit hat“, sondern dass der Schlüssel überhaupt kein kryptografischer Zufallszahlentyp ist. Diese Unterscheidung ist wichtig: AES-256 selbst wurde nicht geknackt, das, was geknackt wurde, war die Zufallsquelle, aus der der Schlüssel generiert wird. Die Beschreibung als „9-Bit-AES-Schlüssel“ ist eine bildliche Umschreibung, aber sie kann dazu führen, dass Leser denken, der AES-Algorithmus habe einen Fehler gemacht. Der Algorithmenname gibt nur das theoretische Maximum an, während die Implementierungsdetails das tatsächliche Minimum bestimmen.

Andere Diskussionen konzentrieren sich auf die historischen Herausforderungen der PDF-Enryption-Ökologie. Viele Menschen glauben, dass das PDF-Standard die Encryption-Design als komplex erscheinen lässt, aber lange Zeit nicht verlangt, dass sichere mathematische Zufallszahlen verwendet werden, was zu wiederholten Sicherheitslücken in den Implementierungen führt. Die PDF-Encryption-Spezifikationen entstanden aus dem Bedarf an Dokumentenschutz und nicht aus modernen Bedrohungsmodellen, daher bleiben viele Bereiche unklar.

Andere Warnungen besagen, dass gewöhnliche Nutzer automatisch sicher halten, wenn sie „AES-256-Unterstützung“ sehen. Doch wenn in irgendeiner Phase der Implementierung, wie Zufallszahlen, Schlüsselherleitung oder Salzmäntelverarbeitung, etwas schiefgeht, wird das hohe Sicherheitsniveau des Algorithmus wirkungslos bleiben. Einige Kommentare weisen darauf hin, dass die Aufdeckung solcher Lücken dazu dient, Organisationen, die PDF-Encryption verwenden, dazu zu bringen, ihre Annahmen neu zu überdenken, anstatt einfach die Schuld auf einen Hersteller zu schieben. Einige Entwickler betonen, dass viele Projekte bei der Auswahl eines Encryption-Systems nur darauf achten, ob „diese Funktion vorhanden ist“, ohne sich darum zu kümmern, ob die Implementierung auditiert wurde. Diese Einstellung selbst ist eine Quelle für Sicherheitslücken.

Einige Kommentare befassen sich mit den realen Schwierigkeiten bei der Behebung. Da PDF-Dateien nach ihrer Erstellung nicht mehr retroaktiv geschützt werden können, müssen Unternehmen viele historische Dokumente neu verschlüsseln, was eine zusätzliche Belastung für die Speicherung und Prozesse darstellt. Deshalb glauben einige, dass die Auswirkungen dieses Vorfalls nicht sofort verschwinden, sondern mehrere Monate oder sogar länger anhalten werden. Andere schlagen vor, dass bei zukünftigen Änderungen der PDF-Spezifikationen verlangt wird, dass sichere mathematische Zufallszahlen verwendet werden, sonst werden ähnliche Probleme weiterhin auftreten.

Drei Dinge, die gewöhnliche Nutzer tun können

Schauen Sie nicht nur auf das Etikett „AES-256“. Die Sicherheit der Encryption hängt von vielen Faktoren ab, wie Schlüsselgenerierung, Schlüsselherleitung und Zufallsquellen. Wenn ein Tool nur den Algorithmennamen betont und die Implementierungsdetails unklar lässt, sollten Sie wachsam sein. Für wirklich sensible Inhalte kann man über eine zusätzliche, unabhängige Encryption vor dem PDF-Encryption nachdenken, wie zum Beispiel die Verwendung von auditierten Dateienschlüsselverarbeitungstools. So werden die Implementierungsfehler des PDF-Encodings nicht direkt zum Vorschein kommen und der Inhalt der Dokumente wird nicht direkt veröffentlicht.
Überprüfen Sie, ob Sie sensible PDFs haben, die mit der veröffentlichten Version erstellt wurden. Wenn ja, empfiehlt es sich, die Datei mit einem reparierten Tool neu zu verschlüsseln oder auf andere auditierte Encryption-Methoden umzustellen, anstatt sich auf die alten PDF-Passwörter zu verlassen. Es ist besonders wichtig zu beachten, dass das Ändern der Dokumenteigenschaften oder das Wiederbeschreiben nicht gleichbedeutend mit einer Reparatur ist. Der Schlüssel muss neu generiert und der Inhalt neu verschlüsselt werden. Für Unternehmen ist es am besten, diese Schritte mit einer Dokumentversionverwaltung und einer Backup-Politik zu kombinieren, um während des Neuerstellens der Dateien Inhaltsverlust oder Kontrollverlust zu vermeiden.
Für Unternehmen sollte das PDF-Encryption in die Sicherheitsbaseline-Überprüfungen einbezogen werden. Aufmerksamkeit sollte auf die Zufallsquellen, Schlüsselherleitung und Salzmäntelverarbeitung gelegt werden, nicht nur darauf, ob „AES-256“ ausgewählt wurde. Zudem sollte eine Dokumentlebenszyklusverwaltung eingeführt werden, um festzuhalten, welche Dateien unter der bekannten Problemversion erstellt wurden. Diese Dateien sollten vorrangig neu verschlüsselt oder übertragen werden. Darüber hinaus können Sicherheitsteams regelmäßig die Sicherheitsmitteilungen der PDF-Verarbeitungstools überwachen und sofort den Einflussbereich bewerten, sobald eine Veröffentlichung erfolgt ist.

Schlussfolgerung

„9-bit AES-Schlüssel“-Vorfall zeigt erneut, dass die Sicherheit von Verschlüsselungsprodukten nicht vom Namen des Algorithmus bestimmt wird, sondern von den Umsetzungsdetails. AES-256 kann eine hohe theoretische Sicherheitsgrenze bieten, aber wenn ein 32-Bit-Schlüssel tatsächlich aus einer Zufallsquelle mit nur 9 Bit-Entropie stammt, dann beträgt seine tatsächliche Stärke nur 9 Bit. Noch problematischer ist, dass der PDF-verschlüsselungsstandard nicht verlangt, dass sichere Zufallszahlen verwendet werden, was dazu führt, dass dieses Problem in verschiedenen Umsetzungen wiederkehrt. Für normale Nutzer ist die praktischste Maßnahme nicht, andere Dokumente zu knacken, sondern zu überprüfen, ob sie immer noch alte Versionen verwenden, die fehlerhaft sind, und sensible Dokumente zu generieren, und rechtzeitig zu einer zuverlässigeren Verschlüsselungsmethode umzustellen. Technische Hotspots vergehen, aber Dokumentensicherheit wird sich nicht automatisch reparieren. Die wirkliche Verantwortung besteht darin, diese Enthüllung als Gelegenheit zu betrachten, den Zustand der Sicherheit digitaler Assets zu überprüfen. Für Organisationen, die PDF-verschlüsselung zur Schutz von Kerndaten nutzen, ist dieser Vorfall eine Warnung: Egal wie stark der Algorithmus ist, er kann das Nachlässigkeiten bei der Verwendung von Zufallszahlen nicht retten. Nur wenn „Umsetzung“ statt „Name“ als Kernkriterium zur Bewertung von Verschlüsselungsprodukten verwendet wird, kann man einem ähnlichen Risiko vorbeugen.

Referenzquellen

V12 Security Blog: The case of the 9 bit AES key (2026-10-27)
Hacker News Diskussionseintrag, objectID 50280722 (2026-10-28)