【ITニュース解説】A PDF permission password is one integer, and the reader decides

PDFファイルは、ビジネスや日常生活で広く利用される文書形式だが、そのセキュリティ機能、特に「パーミッションパスワード」と呼ばれる機能については、誤解されている部分が多い。通常、パスワードが設定されたPDFは、開く際にパスワードの入力を求められると考える人がほとんどだろう。しかし、実際には、パスワードを求められることなく開けるにもかかわらず、ファイル自体は暗号化されているという状況が存在する。この状態は、PDFの内部構造、特に暗号化辞書に含まれる「/P」というたった一つの符号付き整数によって引き起こされる現象だ。そして、この「/P」値で設定されたアクセス制限を尊重するかどうかは、PDFを閲覧・処理する側のソフトウェア（ビューアやライブラリ）に委ねられている。

PDFのセキュリティ機能は、大きく分けて二つの種類がある。一つは「オープンパスワード」で、これはファイルを開く際に必要となるパスワードだ。もう一つが「パーミッションパスワード」であり、これはファイルが開かれた後に、内容の印刷、コピー、編集といった特定の操作を制限するためのものだ。今回の話題の中心は、オープンパスワードが設定されていないにもかかわらず、パーミッションパスワードによって暗号化されているように見えるファイルについてである。

この現象を理解するには、PDFの暗号化辞書内にある「/P」値という要素が非常に重要となる。この「/P」値は、32ビットの符号付き整数として表現され、それぞれのビットが特定の操作に対する許可・拒否を表す「ビットフラグ」として機能する。例えば、ビット3が設定されていれば印刷が許可され、ビット5が設定されていればコピーが許可されるといった具合だ。逆に、ビットが設定されていない（クリアされている）場合は、その操作が拒否される。 具体的な「/P」値の例を挙げると、「-3392」という値は、アクセシビリティ抽出という操作以外をすべて拒否する設定に対応する。これは、二進数で表現すると特定のビットのみが「1」となり、それ以外のビットが「0」となる状態だ。「-20」という値はコピー操作のみを拒否し、「-2056」は印刷と高品質印刷を拒否する。そして、「0」という値は、すべての操作を拒否するという非常に厳しい制限を意味する。このように、「/P」値の符号付き整数の各ビットが、ユーザーができる操作とできない操作を細かく定義している。

このようなパーミッションパスワードのみが設定されたファイルでも暗号化が行われる理由は、PDFのセキュリティハンドラという仕組みにある。ユーザーがファイルを開くためのパスワード（ユーザーパスワード）が設定されていない、つまり空の場合でも、PDFの内部では暗号化処理が行われる。この場合、PDFリーダーは内部で自動的に暗号化の鍵を生成し、その鍵を使ってファイルの内容を復号する。このプロセスはユーザーに意識されることなく行われるため、ファイルはパスワード入力を求めずに開くことができる。この暗号化は、PDFの内容を他者から隠すというよりは、むしろ「/P」値をファイルの一部として確実に保持し、セキュリティハンドラが機能するための「コンテナ」としての役割が大きいと解釈できる。一部のライブラリでは、このようなファイルでも暗号化辞書が存在するため、「暗号化されている」と判断するが、別のライブラリではパスワードが必要ないため「暗号化されていない」と判断することもあり、ソフトウェアによって「暗号化」という言葉の定義が異なる場合があるため注意が必要だ。

では、この「/P」値によって設定された制限は、実際にどのように強制されるのだろうか。結論から言えば、コンテンツが読み取り可能になった後、その制限に従うかどうかは、PDFファイルを処理する各ソフトウェア（PDFリーダーやビューア）の「判断」に委ねられている。例えば、WebブラウザのChromiumでパーミッションパスワードが設定されたファイルを閲覧すると、印刷やコピーといった特定の操作がブロックされる。しかし、同じファイルでもFirefoxのデフォルト設定で開くと、すべての操作が許可されてしまうこともある。Firefoxでは、特定のオプションを有効にすることで印刷や編集をブロックできる場合もあるが、ここでもコピーは可能というように、完璧に制限が適用されるわけではない。 これは、PDFの仕様上、コンテンツの暗号化解除が一度行われてしまえば、残りの制限はソフトウェアが「自発的に」守るべき指示に過ぎないためだ。PDFを読み込むためのライブラリの場合、これらのパーミッションフラグを読み取り、その情報を呼び出し元のアプリケーションに渡すのが一般的だ。つまり、ライブラリ自体は制限を強制せず、それをどう扱うかはアプリケーション側の実装に依存する。また、ファイルの暗号化方式（RC4やAESなど）が異なっても、ブラウザ上でのパーミッションの挙動に違いは見られなかった。

PDFを閲覧するだけでなく、内容を加工したり圧縮したりする「処理ツール」では、状況がさらに複雑になる。例えば、PDF圧縮ツールは、新しいファイルを作成する必要があるため、この際にパーミッションパスワードによる制限をどう扱うかという問題に直面する。ある圧縮ツールでは、暗号化やパーミッション保護が施されたPDFファイルをすべて処理拒否した。これは、たとえコピーや編集が許可されているファイルであっても同様だった。 この理由として考えられるのは、新しいファイルを書き出す際に、元の暗号化設定をそのまま引き継いで再暗号化するには、オーナーパスワードが必要となる場合が多いことだ。オーナーパスワードが手元になければ、元のセキュリティ設定を正確に再現することは困難である。また、制限を解除して平文のファイルとして出力することは、元の作成者が意図した制限を無視することになるため、問題を引き起こす可能性がある。これらの理由から、ツール開発者にとって最も安全で防御しやすい選択肢は、暗号化またはパーミッション保護が設定されたファイルはすべて拒否するという判断を下すことであると推測される。

したがって、システムエンジニアがPDFファイルを扱うアプリケーションを開発する際には、このようなPDFのパーミッションパスワードの仕組みを正確に理解しておくことが重要だ。特に、PDFから「/P」値を読み取り、そのビットフラグが示す制限内容をユーザーに明示的に伝える機能は、多くの誤解を防ぐために非常に有用だ。また、制限のないバージョンのファイルが必要な場合には、ファイルの作成者に直接連絡するようユーザーに案内することも、円滑なコミュニケーションを促す上で大切になる。PDFのセキュリティ機能は単なるパスワード入力だけでなく、その内部構造に複雑なロジックが隠されていることを認識し、適切に対応することが求められる。