Das PDF-Format bietet die Möglichkeit, die Inhalte eines PDF-Dokuments zu verschlüsseln. Die jadice document platform bietet Unterstützung für die gängigen zu diesem Zweck verwendeten Verschlüsselungsverfahren. Für das Thema ›Verschlüsselung‹ ist hauptsächlich Abschnitt 7.6, ›Encryption‹ aus der PDF-Referenz [PDF 32000-1:2008], relevant. Zu dem Standard kommt das »Adobe Supplement to the ISO 32000« [PDF 32000-1:2008 ExtensionLevel 3] hinzu, aus welchem die Revision 5 Verschlüsselung unterstützt wird. Die Unterstützung von Verschlüsselungen der Revision 5 hängt von speziellen Systemanforderungen ab, die in „Erweiterte Security Handler“ beschrieben werden.
Per Definition sind verschlüsselte PDFs zusätzlich mit einem Berechtigungskonzept versehen, das dem Ersteller des Dokuments erlaubt zu definieren, welche Aktionen damit möglich sein sollen. Solche Aktionen können beispielsweise Verändern, Zusammenstellen oder Ausdrucken von Dokumenten sein. Dieses Berechtigungskonzept wird von der jadice document platform aufgenommen und umgesetzt.
Die PDF-Referenz [PDF 32000-1:2008] legt bindend fest, wie mit verschlüsselten Dokumenten umgegangen werden muss. Insbesondere wird zwingend gefordert, dass Applikationen, die PDF-Dokumente anzeigen, die darin festgelegten Berechtigungen respektieren und durchsetzen müssen. Für Integrationen der jadice document platform bedeutet dies, dass diese Verantwortung zwischen jadice und der integrierenden Applikation geteilt wird. Die Berechtigungen werden durch jadice ausgelesen, in den mitgelieferten Komponenten beachtet und dem Integrator zur Verfügung gestellt. Es ist Aufgabe und Verantwortung des Integrators, für eine korrekte Beachtung der Berechtigungen in der resultierenden Gesamtanwendung zu sorgen. Diese Anforderung geht beispielsweise aus folgender Festlegung des PDF-Standards hervor:
|
Conforming readers shall respect the intent of the document creator by restricting user access to an encrypted PDF file according to the permissions contained in the file. |
||
| —[PDF 32000-1:2008], 7.6.3.1 ›General‹ | ||
Zur Umsetzung der Verschlüsselungs-Funktionalitäten wird in PDF das Konzept eines Security Handlers definiert. Es handelt sich dabei um ein PDF-internes Verfahren, das den eigentlichen Ver-/Entschlüsselungsvorgang durchführt. Von jadice wird das üblicherweise verwendete Verfahren ›Standard Security Handler‹ unterstützt[74]. Dieser Handler fordert zum Ver- und Entschlüsseln die Angabe eines Passworts. Im Besonderen kann dieses Passwort auch ein leerer String sein, was dazu führt, dass das Dokument zwar verschlüsselt ist und über Berechtigungen verfügt, trotzdem aber ohne Angabe eines Passworts geöffnet werden kann.
Der Standard Security Handler arbeitet für jedes Dokument mit zwei unterschiedlichen Passwörtern:
- User Password
-
Ein Passwort, das für jedes Öffnen des Dokuments eingegeben werden muss. Bei korrekter Eingabe des Passworts wird dem Nutzer ermöglicht, das Dokument zu betrachten und, falls die geltenden Berechtigungen dies erlauben, weitere Aktionen damit durchzuführen.
- Owner Password
-
Ein Passwort, das unabhängig der gesetzten Berechtigungen vollen Zugriff auf das Dokument gewährt. Dies umfasst auch das Recht, die Berechtigungen selbst abzuändern.
Die jadice document platform erkennt nach Eingabe eines Passworts selbstständig, welches der beiden Passwörter verwendet wurde, und gewährt die entsprechenden Rechte.
»Adobe Supplement to the ISO 32000« [PDF 32000-1:2008 ExtensionLevel 3] erweitert den Standard Security Handler um Revision 5. Zur Entschlüsselung der Daten innerhalb dieses Verfahrens wird ein AES-basierter Algorithmus mit einer Schlüssellänge von 256 Bit verwendet[75]. Die Java Cryptography Architecture (JCA) [JCA Reference] limitiert standardmäßig aufgrund von Export-Beschränkungen die Nutzung von Schlüssellängen dieser Größenordnung:
|
Due to import control restrictions by the governments of a few countries, the jurisdiction policy files shipped with the Java SE Development Kit 6 specify that »strong« but limited cryptography may be used. An »unlimited strength« version of these files indicating no restrictions on cryptographic strengths is available for those living in eligible countries (which is most countries). But only the »strong« version can be imported into those countries whose governments mandate restrictions. The JCA framework will enforce the restrictions specified in the installed jurisdiction policy files. |
||
| —Abschnitt ›How to Make Applications "Exempt" from Cryptographic Restrictions in [JCA Reference]. | ||
Aufgrund dieser rechtlichen Gegebenheiten entstehen zur Nutzung dieser Funktion folgende zusätzliche Systemvoraussetzung: Die Java VM muss einen JCE Provider bereitstellen, der AES-basierte Algorithmen mit einer Schlüssellänge von 256 Bit erlaubt.
Oracles Standard VM Installationen erlauben nur Schlüssellängen bis 128 Bit Länge (»strong« but limited cryptography, vergleiche Zitat). Zur Bereitstellung der benötigten Schlüssellängen können beispielsweise die Unlimited Strength Jurisdiction Policy Files[76] in die Java VM eingebracht werden. Eine detaillierte Beschreibung für diesen Prozess steht im Abschnitt ›Permission Policy Files for Exempt Applications‹ in [JCA Reference] zur Verfügung.
Zur Prüfung ob eine Java VM die genannten Voraussetzungen erfüllt, steht ein Code-Beispiel unter Beispiel 7.25, „JCE Policy Check“ zur Verfügung. Sollte die Virtual Machine der Ziel-Plattform die nötigen Voraussetzungen nicht erfüllen, kann mit Hilfe der oben genannten Maßnahmen die Funktionalität sichergestellt werden.
Die Daten, die angegeben werde müssen um den Zugriff auf ein
verschlüsseltes Dokument zu ermöglichen, werden in jadice durch das Interface
CryptoMaterial repräsentiert. Es kann sich dabei um Passwörter,
Sicherheits-Tokens oder ähnliches handeln. Für den oben beschriebenen
Standard Security Handler ist ein
Passwort erforderlich. Es wird in diesem Fall die spezielle Implementation
PasswordMaterial verwendet.
Das Konzept der CryptoMaterialProvider und
CryptoMaterialReceiver
Die Legitimationsdaten, die notwendig sind um das Dokument zu
entschlüsseln, müssen durch den Integrator bereitgestellt werden. Zu diesem
Zweck muss eine Instanz einer Implementierung von CryptoMaterialProvider
erstellt und vor dem Lesevorgang bekannt gemacht werden. Im Fall des Standard Security Handlers muss ein Passwort mit
Hilfe eines PasswordMaterial Objekts zur Verfügung gestellt
werden.
Die Bekanntmachung des CryptoMaterialProviders erfolgt, indem vor dem
Lesevorgang das PDFStandardSecurityHandlerSettings Objekt angefordert
wird. Darauf muss die Provider-Instanz gesetzt werden[77].
Der gesetzte Provider wird angefragt, falls für den Lesevorgang
Legitimationsdaten benötigt werden. Um diese bereitzustellen, wird dem
Provider eine Instanz von CryptoMaterialReceiver übergeben. Der Receiver
nimmt die Daten entgegen und gibt als Antwort zurück, ob diese valide sind
um die Entschlüsselung des Dokuments durchzuführen. Falls keine Möglichkeit
besteht, für ein gegebenes Dokument valide Legitimationsdaten zur Verfügung
zu stellen, kann die Methode
CryptoMaterialReceiver.cancel() aufgerufen
werden, was nach Rückkehr aus dem Provider zum Abbruch des Ladevorgangs
führt.
Fehler die während des Entschlüsselungsvorgangs eines Dokuments auftreten,
werden durch Werfen einer PDFSecurityException dem Aufrufer mitgeteilt. Es
handelt sich bei dieser Ausnahme um eine Variante der JadiceException, die
generell während eines Lesevorgangs auftreten kann. Details zum aufgetretenen
Fehler werden über die qualifizierte ID der Exception mitgeteilt.
Im Besonderen können PDFSecurityExceptions dann entstehen, wenn die zur
Entschlüsselung eines Dokuments notwendigen Legitimationsdaten nicht zur
Verfügung gestellt werden. Eine Entschlüsselung ist dann nicht möglich und der
Ladevorgang kann daher nicht fortgeführt werden.
Das PDF-Format definiert verschiedene Berechtigungen, die Nutzern von Dokumenten eingeräumt oder verweigert werden können. Jede einzelne Berechtigung wird dadurch festgelegt, ob ein zugehöriges Bit gesetzt ist oder nicht[78].
Ein separates Konzept zur Steuerung von Berechtigungen existiert in der jadice document platform.[79] Die durch ein PDF-Dokument definierten
Berechtigungen werden während des Lesevorgangs auf entsprechende Instanzen von
PageSegmentPermission abgebildet. Diese jadice-Berechtigungen werden wiederum
auf jedem PageSegment gesetzt, das durch den Lesevorgang erzeugt wird. Die
Steuerung von Rechten innerhalb der jadice document platform erfolgt ausschließlich auf Basis
dieser Permissions.
Die aus PDF stammenden Berechtigungen werden zusätzlich
(ohne Abbildung auf jadice-Berechtigungen) in die Metadaten[80] jedes aus dem Lesevorgang resultierenden PageSegments übernommen.
Für jede Berechtigung werden die Bit-Position, ein zugehöriger
Identifikations-Key, sowie der gesetzte
Status (erlaubt/verboten) angegeben.
Der in PDF definierte und von jadice unterstützte Standard Security Handler existiert in
unterschiedlichen Revisionen, die auch unterschiedliche – wenngleich ähnliche –
Berechtigungen anbieten. Revision zwei bietet vier unterschiedliche
Berechtigungen an. Für Version drei und höher kommen vier weitere hinzu. Die
folgenden beiden Tabellen geben einen Überblick über die einzelnen
Berechtigungen mit ihrer Bit-Position, Bedeutung und dem zugehörigen Metadaten
Identifikations-Key. Zusätzlich wird die
Abbildung auf jadice Permissions angegeben und es
wird skizziert, wie das Fehlen einer Berechtigung die Arbeit mit der Applikation
beeinflusst. Es ist Aufgabe des Integrators, die gesetzten jadice-Berechtigungen
auch in eigenem Code zu beachten, sowie ein konsistentes, mit der
PDF Spezifikation konformes Verhalten der
Gesamtapplikation umzusetzen.
Tabelle 6.1. Mapping von PDF Standard Security Handler Permissions (Revision 2) auf jadice Permissions
| Bit Position | Bedeutung | Metadata Key | jadice Permission |
Auswirkung bei fehlender Berechtigung |
|---|---|---|---|---|
| 3 | Druck |
permission.print.general
|
PageSegmentPermission.ALLOW.output |
Exception bei Export-Versuch (zum Beispiel Druck, TIFF-Converter). |
| 4 | Inhalts-Modifikation (Operationen, die nicht durch Bit 6 gesteuert werden) |
permission.modify.general
|
PageSegmentPermission.ALLOW.modification |
Exception bei Export-Versuch. Es ist Aufgabe des Integrators, sicherzustellen dass keine unerlaubten Modifikationen vorgenommen werden. |
| 5 | Inhalts-Extraktion |
permission.extract.general
|
PageSegmentPermission.ALLOW.export |
Kopieren/Extrahieren von Inhalten (zum Beispiel über die Zwischenablage) wird verhindert. Mitgelieferte Commands beachten diese Berechtigung. Es ist Aufgabe des Integrators, die Berechtigung in eigenen Commands zu beachten. |
| 6 | Modifikation von Annotationen und Interactive Form Fields |
permission.modify.annos-and-fields
|
PageSegmentPermission.ALLOW.modification |
Modifikation von Annotationen und Interactive Form Fields ist aktuell keine von jadice unterstützte Funktion. |
Tabelle 6.2. Mapping von PDF Standard Security Handler Permissions (Revision 3 und größer) auf jadice Permissions
| Bit Position | Bedeutung | Metadata Key | jadice Permission |
Auswirkung bei fehlender Berechtigung |
|---|---|---|---|---|
| 3 | Druck (Qualität abhängig von Bit 12) |
permission.print.general
|
PageSegmentPermission.ALLOW.output |
Exception bei Export-Versuch (zum Beispiel Druck, TIFF-Converter). |
| 4 | Inhalts-Modifikation (Operationen, die nicht durch Bits 6, 9 und 11 gesteuert werden) |
permission.modify.general
|
PageSegmentPermission.ALLOW.modification |
Exception bei Export-Versuch. Es ist Aufgabe des Integrators, sicherzustellen dass keine unerlaubten Modifikationen vorgenommen werden. |
| 5 | Inhalts-Extraktion (Operationen, die nicht von Bit 10 gesteuert werden) |
permission.extract.general
|
PageSegmentPermission.ALLOW.export |
Kopieren/Extrahieren von Inhalten (zum Beispiel über die Zwischenablage) wird verhindert. Mitgelieferte Commands beachten diese Berechtigung. Es ist Aufgabe des Integrators, die Berechtigung in eigenen Commands zu beachten. |
| 6 | Modifikation von Annotationen und Interactive Form Fields |
permission.modify.annos-and-fields
|
PageSegmentPermission.ALLOW.modification |
Modifikation von Annotationen und Interactive Form Fields ist aktuell keine von jadice unterstützte Funktion. |
| 9 | Ausfüllen von Interactive Form Fields (auch wenn Bit 6 nicht gesetzt ist) |
permission.modify.fields-and-sig
|
PageSegmentPermission.ALLOW.modification |
Modifikation von Interactive Form Fields ist aktuell keine von jadice unterstützte Funktion. Hinzufügen von Signatur-Feldern ist nicht im Standard-Lieferumfang der jadice document platform enthalten. |
| 10 | Inhalts-Extraktion für Accessibility |
permission.extract.accessibility
|
— | Analog zu aktuellen Entwicklungen im Bereich PDF-Verarbeitung und PDF-Standard lässt jadice die Extraktion zum Zweck der Accessibility generell zu. |
| 11 | Inhalts-Zusammenstellung |
permission.modify.assemble
|
PageSegmentPermission.ALLOW.modification |
Exception bei Druck-Versuch. Es ist Aufgabe des Integrators, sicherzustellen dass keine unerlaubten Modifikationen vorgenommen werden. |
| 12 | Druck in voller Qualität |
permission.print.high
|
PageSegmentPermission.ALLOW.output |
Exception bei Export-Versuch (zum Beispiel Druck, TIFF-Converter). |
Unter „Beispiel zur Verwendung der PDF Security
API“ finden sich
Anwendungsbeispiele, die die Benutzung der PDF
Verschlüsselungs-API veranschaulichen. Eine vollständige
Integration der zur Verfügung stehenden Möglichkeiten findet sich in der
Demo-Anwendung. Passwortabfragen werden darin mit Hilfe des
PDFPasswordProviderTools an den Nutzer weitergegeben.[81]
[74] Details zum Standard Security Handler finden sich in [PDF 32000-1:2008], 7.6.3 ›Standard Security Handler‹.
[75] Siehe http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/adobe_supplement_iso32000.pdf, Abschnitt 3.5.2, zum Beispiel unter Algorithm 3.1a »Encryption of data using the AES algorithm«
[76] JCE Unlimited Strength Jurisdiction Policy Files 7 Download: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html
[77] Es wird an dieser Stelle das Konzept der ReaderControls
verwendet. Allgemeine Informationen dazu finden sich unter „Formatspezifische Einstellungen“.
[78] Die Definition und Bedeutung der einzelnen Berechtigungen wird in [PDF 32000-1:2008], 7.6.3.2 ›Standard Encryption Dictionary‹ erläutert.
[79] Details zur Struktur des Berechtigungskonzepts in jadice finden sich unter „Berechtigungskonzept“.
[80] Allgemeine Informationen zum Thema ›Metadaten‹ finden sich unter „Metadaten im jadice Dokumentenmodell“.
[81] Der Quellcode der Demo-Anwendung steht im Sinne der unter „Demo-Integrationen“ gegebenen allgemeinen Informationen zur Verfügung.
