KAUFEN
Suchen

PDF 2.0 (ISO 32000-2): Was fehlt?

Dringender Bedarf an sicherheitsrelevanten Klarstellungen für PDF

Viele Entwickler und Benutzer haben eine Wunschliste mit Features, die sie in zukünftigen Versionen von PDF gerne sehen würden. Viele dieser Wünsche wurden in einem kollaborativen internationalen Prozess in PDF 2.0 aufgenommen. Auf dieser Seite gehen wir auf sicherheitsrelevante Themen von PDF ein, nicht jedoch auf grafische, interaktive oder technische Ergänzungen zu PDF.

PDF 2.0 erklärt erfreulicherweise eine Reihe von überholten kryptografischen Algorithmen als veraltet. Leider gibt es immer noch einige sicherheitsrelevante Mängel in PDF 2.0, was folgende Konsequenzen haben kann:

PDF-Dokumente sind unter Umständen über verschiedene Anwendungen hinweg nicht vollständig kompatibel, da PDF 2.0 einige technische Details unspezifiziert lässt. Einige der folgenden Elemente sind bereits in Acrobat umgesetzt worden (z.B. digitale Signaturen mit bestimmten elliptischen Kurven). Obwohl dies generell eine gute Entwicklung ist, führt es bereits jetzt zu einer Situation, in der der neueste PDF-2.0-Standard bestimmte, in den letzten Jahren erstellte PDF-Dokumente  unberücksichtigt lässt.

PDF-Sicherheit kann kryptografische Schwachpunkte aufweisen, da sie Fortschritte in Wissenschaft und Technologie nicht nutzt. Dabei sprechen wir hier nicht von den neuesten Krypto-Hypes, sondern von den kryptografischen Fortschritten der letzten 10-15 Jahre, die etablierte und allgemein bekannte Verbesserungen der Sicherheit mit sich gebracht haben.

Natürlich besteht ein grundlegender Konflikt zwischen einem wohldefinierten und spezifischen PDF-Format einerseits und dem Bemühen, die Sicherheitsmechanismen auf dem neuesten Stand zu halten. Allerdings lässt die PDF-2.0-Sicherheit viele wichtige Verbesserungen der letzten Jahre vermissen. Außerdem könnte ein einfacher Mechanismus eingeführt werden, der die Krypto-Anforderungen eines Dokuments identifiziert. Als Ergebnis könnten die aktuellen Acrobat-Meldungen

ungültiges Format
oder
Interner kryptografischer Fehler der Bibliothek

ersetzt werden durch die benutzerfreundlichere Meldung
Dokument verwendet eine Verschlüsselungsmethode, die in diesem Produkt nicht unterstützt wird.

Das modulare Design kryptografischer Anwendungen, Formate und Protokolle, um Sicherheitsverbesserungen zu erleichtern, ist Stand der Technik. Obwohl statische Dateiformate andere Anforderungen haben als Online-Protokolle, sollte nicht unerwähnt bleiben, dass das Aushandeln gemeinsamer kryptografischer Algorithmen zwischen Client und Server einen wichtigen Aspekt des TLS-Protokolls darstellt.

Fairerweise sollte man erwähnen, dass das ISO-Komitee für PDF 2.0 zwar einige der folgenden Themen diskutiert hat, jedoch aus Zeit- oder anderen Gründen keine entsprechenden Bestimmungen in den PDF-2.0-Standard aufgenommen hat.

Digitale Signaturen

Lange Zeit war RSA (RFC 5652) der bei Public-Key-Verfahren dominierende Algorithmus mit Schlüssellängen von bis zu 8192 Bit.

RSA-Schlüssellänge

Je nach Lebenszyklus eines Dokuments können unterschiedliche RSA-Schlüssellängen erforderlich sein. Sicherheitsrichtlinien werden regelmäßig aktualisiert, um längere RSA-Schlüssel mit ausreichenden Sicherheitsmargen zu empfehlen. In PDF 2.0 wird jedoch nicht spezifiziert, welche Schlüssellängen tatsächlich unterstützt werden. (Genauer gesagt: Nur zwei widersprüchliche ältere Hinweise aus PDF 1.5 verblieben im Text: der eine behauptet, dass PDF 1.5 Schlüssel mit bis zu 2048 Bit unterstützt und ein weiterer Hinweis erwähnt Schlüssel mit bis zu 4096 Bit Länge).

Während die maximal unterstützte Schlüssellänge in Acrobat im Laufe der Jahre erhöht wurde (Überblick über Algorithmen und Schlüssellängen), ist Acrobat DC weiterhin inkonsistent: während die Windows-Version 8192-Bit-Schlüssel unterstützt, kann Acrobat für OS X keine Schlüssel dieser Länge verarbeiten.

Encoding-Methode für RSA-Signaturen

RSA-Signaturen erfordern eine Encoding-Methode (Encoding Method for Signatures with Appendix, EMSA). Die Standard-Encoding-Methode gemäß PKCS#1 v1.5 wird in allen Acrobat-Versionen unterstützt. Allerdings wird sie in modernen Signaturanwendungen demnächst auslaufen. Eine sicherere alternative Encoding-Methode namens Probabilistic Signature Scheme (PSS) wurde 2003 in PKCS#1 v2.2 und RFC 3447 standardisiert.

EMSA-PSS ist für RSA-Signaturen Stand der Technik und in vielen Sicherheitsrichtlinien empfohlen oder zwingend erforderlich, zum Beispiel:

RFC 3447 und sein Nachfolger RFC 8017 empfehlen, für neue Anwendungen PKCS#1 v1.5 durch EMSA-PSS wegen »größerer Robustheit« zu ersetzen.

Der Algorithmenkatalog der deutschen Bundesnetzagentur erlaubt in dem 2017 veröffentlichten Entwurf das alte Schema PKCS#1 v1.5 nur noch bis Ende 2017 und empfiehlt für langfristige Anwendungen stattdessen EMSA-PSS.

ETSI TS 119 312 definiert die kryptografischen Verfahren, auf denen die PAdES-Standards basieren. Es unterstützt weiterhin PKCS#1 v1.5, empfiehlt aber EMSA-PSS. Aus diesem Grund haben europäische Anbieter von Signatursoftware bereits mit dem Umstieg auf EMSA-PSS begonnen.

Leider wurde EMSA-PSS nicht in PDF 2.0 aufgenommen. Acrobat XI und DC unterstützen die Validierung von PSS-Signaturen seit den Updates im Januar 2017. Acrobat DC 2017.012.20093 Continuous track führte die Erstellung von Signaturen mit EMSA-PSS ein. Da diese Funktion im User Interface noch nicht sichtbar ist, muss sie in der Registry aktiviert werden (siehe Anleitung).

PDFlib PLOP DS unterstützt EMSA-PSS mit der Option rsaencoding=pss.

ECDSA-Signaturen basierend auf elliptischen Kurven

Während PDF 1.7 gemäß ISO 32000-1 RSA- und DSA-Signaturen unterstützt, wurde in PDF 2.0 zusätzlich die Unterstützung von ECDSA-Signaturen aufgenommen, die auf elliptischen Kurven (Elliptic Curve Cryptography) gemäß RFC 5480 basieren (erste Veröffentlichung als FIPS 186-2 im Jahr 2000). Eine ECDSA-Signatur basiert auf einem bestimmten Typ einer elliptischen Kurve, und viele dieser Kurven stehen für Entwickler zur Verfügung. PDF 2.0 spezifiziert jedoch nicht, welche Kurven in PDF-Software unterstützt werden sollen. Angesichts der Unbestimmtheit von ISO 32000-2 ist nicht klar, ob PDF-Dokumente mit einer bestimmten ECDSA-Signatur dem Standard entsprechen. Moderne Anwendungen von Elliptic Curve Cryptography basieren oft auf einer der folgenden Kurven:

Die bekanntesten Kurven werden P-256, P-384 und P-521 genannt. Diese Kurven werden in Acrobat XI und höher unterstützt (Algorithmen-Überblick).

Die NIST-Publikation FIPS 186-2 enthält zwölf zusätzliche, vom NIST empfohlene Kurven. Diese werden in Acrobat XI und höher unterstützt, aber nur, wenn Acrobat direkt auf das Zertifikat/die digitale ID zugreift; sie werden vom Windows-Zertifikatspeicher oder OS-X-Schlüsselring nicht unterstützt.

Brainpool-Kurven sind in RFC 5639 (erste Veröffentlichung 2005) angegeben. Sie werden in vielen Anwendungen eingesetzt, darunter der neue Personalausweis in Deutschland. Brainpool-Kurven werden nicht in Acrobat DC oder früheren Acrobat-Versionen unterstützt.

In der obigen Liste wurden moderne Kurven nicht berücksichtigt, die einen anderen Signaturalgorithmus als das ECDSA-Signaturschema benötigen. Vor allem Curve25519 gemäß RFC 7748 (erste Veröffentlichung 2006) kann ein geeigneter Nachfolger für die 15 NIST-Kurven sein.

Die Wahl der elliptischen Kurven für digitale Signaturen ist nicht nur eine akademische Übung. Tatsächlich gibt es seit einigen Jahren eine Diskrepanz zwischen Signaturalgorithmen, die von verschiedenen Sicherheitsrichtlinien gefordert werden und den in Acrobat verfügbaren Algorithmen. Nur eine Teilmenge der nach EU-Richtlinien erzeugten Signaturen kann mit Acrobat validiert werden.

PDFlib PLOP DS unterstützt EC-basierte Signaturen mit NIST- und Brainpool-Kurven. Da Brainpool-Signaturen nicht Acrobat-kompatibel sind, erfordern sie die Option conformance=extended.

Kennwortschutz

Die kennwortbasierte PDF-Verschlüsselung begann mit dem RC4-Verschlüsselungsalgorithmus in den 1990er Jahren und entwickelte sich schrittweise weiter zu AES-256 (Übersicht über Verschlüsselungsalgorithmen für PDF-Kennwortschutz). In PDF 2.0 werden die meisten Algorithmen als veraltet deklariert, wobei nur die Acrobat-X-Variante der AES-256-Verschlüsselung (AESV3 in PDF) beibehalten wird. Die Fokussierung auf eine etablierte starke Verschlüsselungsmethode ist sicherlich eine gute Sache.

Allerdings sind nicht alle Betriebsarten für symmetrische Block-Verschlüsselung wie AES gleich gut geeignet. PDF erfordert die Verwendung von AES im Modus Cipher Block Chaining aus dem Jahr 1976. CBC erfordert einen nach dem Zufallsprinzip ausgewählten Initialisierungsvektor zu Beginn jedes verschlüsselten Daten-Streams sowie Padding am Ende der Daten. CBC hält den geschützten Inhalt vertraulich, schützt aber nicht vor einer versehentlichen oder vorsätzlichen Änderung der verschlüsselten Daten. Während Modifikationen mit einer zusätzlichen Signatur erkannt werden könnten, gibt es Verschlüsselungsmodi mit Authentifizierung, die sowohl Vertraulichkeit als auch Integrität in einer kombinierten Operation erlauben. Dies bezeichnet man als authentifizierte Verschlüsselung.

Ein weit verbreiteter authentifizierter Verschlüsselungsmodus nennt sich Galois Counter Mode (GCM). Er wurde 2007 als NIST 800-38D veröffentlicht und auch in ISO 19772:2009 standardisiert. GCM wird in vielen kryptografischen Protokollen wie IPSec, TLS und IEEE802-WLAN-Sicherheit verwendet.

GCM aufzunehmen wäre eine willkommene Ergänzung zur PDF-Sicherheit. Da AES-Verschlüsselung ebenfalls ein Baustein für Zertifikatsicherheit ist, bezieht sich dieser Vorschlag auch darauf.

Zertifikatsicherheit

Längerer Seed-Wert

Zertifikatsicherheit besteht aus mehreren Verschlüsselungsschritten mit asymmetrischen und symmetrischen Algorithmen (Übersicht). In einem ersten Schritt wird ein zufälliger Content Encryption Key (CEK) generiert, der auf einem zufälligen 20-Byte Seed-Wert basiert. Allerdings ist dieser 160-Bit-Wert kürzer als die Schlüssellänge von AES-256. Gemäß dem Paradigma vom schwächsten Glied lässt sich mit dem kurzen 160-Bit Seed-Wert keine volle 256-Bit-Sicherheit mehr erreichen. Stattdessen sollte ein Seed-Wert von 256 Bit verwendet werden.

RSA-basierte Zertifikatsicherheit

Zertifikatsicherheit, auch Public-Key-Sicherheit genannt, ist seit PDF 1.4 verfügbar. Lange Zeit war RSA (RFC 5652) der für öffentliche Schlüssel dominierende Algorithmus; unterstützte Schlüssellängen erreichten im Laufe der Zeit 8192 Bit (Übersicht über Public-Key-Algorithmen für PDF-Zertifikatsicherheit).

Zertifikatsicherheit umfasst einen Baustein namens Key Exchange, der einen Zufallsschlüssel generiert und ihn mit RSA verschlüsselt. RSA-Verschlüsselung erfordert eine Padding-Methode, die Daten für den RSA-Algorithmus aufbereitet. Die klassische Padding-Methode gilt als anfällig für den so genannten Bleichenbacher-Angriff (Originalartikel von 1998), auch Million Message Attack (MMA) genannt. Diese Methode wurde erfolgreich für Angriffe auf das SSL-Protokoll eingesetzt. Obwohl die Bedrohungsszenarien für Webserver und PDF-Dokumente unterschiedlich sind, sollten bekannte Sicherheitslücken wie der Bleichenbacher-Angriff jedoch behoben werden.

Eine verbesserte Padding-Methode namens Optimal Asymmetric Encryption Padding (OAEP gemäß PKCS#1 Version 2.1 in RFC 3447 von 2003) vereitelt den Bleichenbacher-Angriff.

PDF 2.0 stellt leider nicht klar, ob RSA-OAEP unterstützt wird oder nicht, da zwar RFC 5652 referenziert wird, RSA-OAEP darin jedoch optional ist.

PDFlib PLOP unterstützt RSA-OAEP mit der Option rsapadding=oaep. Da die Ausgabe nicht Acrobat-kompatibel ist, erfordert sie die Option conformance=extended.

Der obige Kommentar zu Schlüssellängen für RSA-Signaturen gilt auch für Zertifikatsicherheit: die in PDF verfügbaren Schlüssellängen sollten explizit angegeben werden.

Auf elliptischen Kurven basierende Zertifikatsicherheit

Eine Alternative zu RSA namens ECDH (Elliptic Curve Diffie-Hellman) bietet Sicherheits- und Leistungsvorteile gegenüber RSA. ECDH wird ab Acrobat XI unterstützt (Algorithmenübersicht). Die Implementierung von Adobe entspricht jedoch keinerlei veröffentlichten Standards und ist daher nicht mit Implementierungen von Drittanbietern kompatibel (in bestimmten Fällen besteht sogar eine Inkompatibilität zwischen Acrobat XI und DC). Dies führt zu der unglücklichen Situation, dass Acrobat XI/DC ECDH außerhalb jedes Standards verwendet, so dass verschlüsselte Dateien inkompatibel sind zu Implementierungen von Drittanbietern.

ISO 32000-2 verweist auf RFC 5652, der den CMS-Container (Cryptographic Message Syntax) beschreibt, der die verschlüsselten Schlüsselinformationen enthält, aber nicht festlegen kann, welche der CMS-Optionen in PDF 2.0 verfügbar sind. Da ISO 32000-2 nicht auf RFC 5753 verweist, der die Verwendung von ECDH innerhalb von CMS spezifiziert, müssen wir davon ausgehen, dass der wichtige Anwendungsfall der Zertifikatsicherheit auf Basis elliptischer Kurven in PDF 2.0 nicht unterstützt wird.

Gehen wir für einen Moment davon aus, dass PDF die Verschlüsselung mit elliptischen Kurven nach RFC 5753 unterstützen würde. In diesem Fall müsste geklärt werden, welche optionalen Funktionen von RFC 5753 in PDF verfügbar wären. Beispielsweise sind mehrere Schlüsselvereinbarungs-Algorithmen für ECDH in RFC 5753 aufgeführt, basierend auf unterschiedlichen Hash-Funktionen für die Key Derivation Function (KDF) zur Erstellung des Schlüssels. Eine bestimmte Kombination namens dhSinglePass-stdDH-sha256kdf-scheme muss von allen Implementierungen unterstützt werden, während andere wie dhSinglePass-stdDH-sha512kdf-scheme in RFC 5753 optional sind. Letztere ist jedoch nicht im Microsoft Cryptographic API verfügbar. Das bedeutet, dass Dokumente, die mit dieser Methode verschlüsselt wurden, nicht entschlüsselt werden können, wenn sich die Anmeldeinformationen im Windows-Zertifikatspeicher befinden. Während dhSinglePass-stdDH-sha512kdf-scheme in der neueren Windows-Schnittstelle CNG (Cryptography Next Generation) verfügbar ist, erfordert die Interoperabilität, dass der PDF-Standard die Unterstützung von kryptografischen Features klarstellt, die in RFC 5753 und anderen optional sind.

PDFlib PLOP unterstützt EC-basierte Zertifikatsicherheit mit NIST- und Brainpool-Kurven. Da mit Brainpool-Signaturen verschlüsselte Dokumente nicht Acrobat-kompatibel sind, erfordern sie die Option conformance=extended.

Zusammenfassung der Vorschläge

Die folgende Tabelle fasst die auf dieser Seite diskutierten Vorschläge für PDF zusammen.

Kategorie Acrobat DC PDF 2.0 (ISO 32000-2) empfohlene PDF-Erweiterung
digitale Signaturen
Encoding-Methode für RSA-Signaturen PKCS#1 v1.5-Encoding;
Acrobat XI/DC unter Windows (ab Januar 2017) auch EMSA-PSS
Encoding-Methode nicht explizit erwähnt Unterstützung von EMSA-PSS
Schlüssellänge für RSA-Signaturen bis zu 8192 Bit unter Windows; niedrigere Grenze für OS X nicht spezifiziert Angabe unterstützter RSA-Schlüssellängen
Signaturen basierend auf elliptischen Kurven ECDSA mit NIST-15-Kurven wird unterstützt Unterstützung von ECDSA, aber Kurven nicht spezifiziert Angabe der unterstützten Kurven für ECDSA
Kennwortschutz
AES-Verschlüsselung für Kennwortschutz nur CBC-Modus nur CBC-Modus Unterstützung des Galois Counter Modus (GCM)
Zertifikatsicherheit
Schlüssellänge für RSA-Zertifikatsicherheitbis zu 8192 Bit unter Windows; niedrigere Grenze für OS X nicht spezifiziert Angabe unterstützter RSA-Schlüssellängen
Padding für RSA-Zertifikatsicherheitnur PKCS#1-v1.5-Padding nur PKCS#1-v1.5-Padding Unterstützung von RSA-OAEP
Zertifikatsicherheit auf Basis elliptischer Kurven (ECDH)proprietäre Verwendung von ECDH; behoben in Acrobat DC 17.012.20093 Continuous track und Acrobat DC Classic 15.6.30352 (Updates von August 2017) ECDH-Unterstützung nicht explizit spezifiziert Unterstützung von ECDH und Angabe der unterstützten Kurven