HSM ベースの署名

Spec: ISO 32000-2, §12.8Spec: FIPS 140-3

一目でわかる概要

ハードウェアセキュリティモジュール（HSM）は、署名鍵をあなたのプロセスの外に出し、要求に応じて署名するものの鍵そのものは決して返さないデバイスの内側へ置きます。このページでは、NextPDF が署名を行う PKCS#11 のシーム、鍵の境界が正確にどこにあるか、そして結果のどの部分がデバイスやあなたではなくエンジンの責任なのかを説明します。

これが重要な理由

プロセスメモリ上にある署名鍵は、そのプロセスを読み取れるあらゆるもの — ヒープダンプ、デバッガー、ロギングのミス、あるいは脆弱性を抱えた依存関係 — にさらされています。ひとたび秘密鍵がコピーされれば、それがこれまでに行ったすべての署名が疑わしくなり、二度と秘密の状態に戻すことはできません。 HSM の要点は、そもそも持ち出せるコピーが存在しないことにあります。

境界を取り違えると、目立たない形で高くつきます。ハードウェアベースに 見える ものの、署名のために鍵をメモリへ引き込むワークフローは、 HSM の運用コストとソフトウェア鍵のリスクプロファイルを併せ持ちます。この違いは完成した PDF には現れないため、当然視するのではなく、設計に織り込み、検証しなければなりません。

要点

PKCS#11 標準は、sensitive かつ non-extractable としてマークされた鍵オブジェクトを定義します。その秘密値は トークンの外部で平文として明かされることはありません。Spec: PKCS#11, v3.1 §10.9
NextPDF は PDF の署名構造と CMS コンテナを構築します。署名対象のバイトを PKCS#11 のシーム越しに渡し、署名を受け取ります。鍵がそのシームを越えることは決してありません。
このシームは安定した契約です。同じ契約が、スマートカードトークン、USB HSM、ネットワーク HSM、そしてクラウド KMS のいずれによっても満たされます。エンジンのコードはそれらの間で変わりません。
NextPDF は署名エンジンのソフトウェアです。デバイスのハードウェア保証、その検証ステータス、PIN ポリシー、そしてデプロイメントは、エンジンが証明するものでは ありません。エンジンはデバイスを利用しますが、その保証を請け合うことはありません。

NextPDF のアプローチ

シーム、正確には

NextPDF は 署名を組み立てること と 署名値を計算すること を分離します。組み立てはエンジンの仕事です。署名フィールドを配置し、ファイル内に領域を予約し、バイト範囲を計算し、署名付き属性を伴う CMS SignedData を構築します。Spec: ISO 32000-2, §12.8

署名値の計算は委譲されます。エンジンは小さな署名プロバイダー契約を定義します。すなわち、不透明なバイト列（実際には DER エンコードされた署名付き属性）を受け取り、生の署名オクテットを返す、というものです。その契約がシームです。 PDF と CMS に関する知識は一方の側にとどまり、鍵はもう一方の側にとどまります。プロバイダーはその鍵を、ローカルのソフトウェア鍵としてプロセス内に、クラウド KMS 内に、あるいは PKCS#11 を通じてハードウェアトークン上に保持できます。シームより上のエンジンコードはいずれの場合でも同一です。異なるのはその背後にあるプロバイダーだけです。

境界が実際に置かれる場所

PKCS#11 — OASIS の Cryptographic Token Interface、歴史的には「Cryptoki」と呼ばれるもの — は、ハードウェアトークンに対する標準の C インターフェースです。 NextPDF のハードウェア経路は PKCS#11 で通信します（直接、あるいはインプロセスのバインディングがトークンをロードできないエンジンまたはプロバイダーのデプロイメント向けには、OpenSSL コマンドラインブリッジを介して）。

トークン上の鍵オブジェクトは、境界を定義する 2 つの属性を伴って作成されます。鍵が sensitive とマークされる、あるいは non-extractable とマークされると、特定の秘密属性は トークンの外部で平文として明かされることはありません。 Spec: PKCS#11, v3.1 §10.9 署名操作そのものは単一のトークン呼び出し — C_SignInit に続いて C_Sign — であり、デバイスによって実行されます。Spec: PKCS#11, v3.1 §5.10 署名操作のために NextPDF が扱う平文は、署名対象のバイトです。返ってくるのは署名と証明書です。秘密鍵はどちらの経路にもありません。それが境界であり、それを強制するのはライブラリではなくトークンです。

Step 1 of 4: ISO 32000-2 §12.8 — signature dictionary, ByteRange, Contents
Step 2 of 4: RFC 5652 CMS SignedData — the signature container
Step 4 of 4: FIPS 140-3 / ISO/IEC 19790 cryptographic module assurance (device-level, deployment-dependent)

ハードウェアベースの PDF 署名がどこに根拠を置くかを、順に示します。PDF のキャリア（ISO 32000-2 §12.8）、それが保持する CMS コンテナ、NextPDF が署名を行うトークンインターフェース（PKCS#11）、そして背後にあるデバイスを — それ自体では保証しないものの — 記述するモジュール保証の標準規格。

1 回の操作、1 回の再認証

PKCS#11 は、鍵が利用のたびに再認証を要求できるようにします。 CKA_ALWAYS_AUTHENTICATE 属性が設定されていると、ユーザーはセッションごとに一度ではなく、それぞれの 暗号操作ごとに再び PIN を提示しなければなりません。Spec: PKCS#11, v3.1 §10.9 NextPDF の PKCS#11 経路はこれを前提に書かれています。PIN は機密性の高いパラメーターです。ログにも記録されず、シリアライズもされません。セッションが既存のログインを報告すると、NextPDF はそれをクリーンな状態へ戻し、次の署名で新たな PIN チェックが行われるようにします。これは、署名ごとに PIN を要求するポリシーを持つ PIV スタイルのトークンにとって重要です。これはデバイスのポリシーを尊重するエンジンの挙動であり、それを緩めることはありません。

実践的な例

以下の形は説明のためのものです。コピー&ペーストで使えるデプロイメントではなく、 シーム を示すものです。要点は、エンジンには署名者が渡されるだけで、鍵を目にすることは決してない、ということです。署名者の sign() はデバイスへの呼び出しです。

<?php

declare(strict_types=1);

use NextPDF\Contracts\HsmSignerInterface;

/**
 * Sign a PDF where the private key lives on a PKCS#11 token.
 *
 * `$hsm` is a hardware-backed signer. Its sign() delegates to the token;
 * the key never enters this process. Everything that makes the bytes a
 * valid PDF signature — field, byte range, CMS SignedData — is built by
 * the engine around the value the device returns.
 *
 * Token wiring (library path, slot, PIN, key label) is deployment
 * configuration and is intentionally out of scope here: those values are
 * operator-owned secrets, not library inputs to hardcode.
 */
function signWithToken(
    string $pdfPath,
    HsmSignerInterface $hsm,
): string {
    // The engine asks the signer only for: the certificate (to embed in
    // the CMS) and a signature over the bytes it computes. It never asks
    // for, and the contract never exposes, the private key.
    $certificateDer = $hsm->getCertificateDer();
    $chainDer       = $hsm->getCertificateChainDer();

    // Pseudocode for the engine's own assembly step: build the signature
    // dictionary + CMS SignedData, then hand the signed-attributes bytes
    // to $hsm->sign(...) and place the returned octets in /Contents.
    return nextpdf_sign_pdf(
        pdfPath: $pdfPath,
        signer: $hsm,
        certificateDer: $certificateDer,
        chainDer: $chainDer,
    );
}

この形について、正直な注記を 2 つ。インプロセスの PKCS#11 バインディングは独立した PHP 拡張であり、標準の PHP ビルドには含まれて いません。ハードウェアのデプロイメントは、それを後付けではなくプラットフォームの一部としてインストールし検証します（あるいは OpenSSL コマンドラインブリッジを使用します）。そして、デバイスに要求するアルゴリズムは、鍵が実際に実行できるものでなければなりません。エンジンは、設定されたアルゴリズムが選択されたプロバイダーに対するマッピングを持たない場合、トークン呼び出しの奥深くで失敗するのではなく、早期に拒否します。

よくある誤解

「HSM を使えば署名は FIPS 検証済みになる。」

いいえ。この 2 つを混同することが落とし穴です。HSM は鍵が存在し操作が実行される場所です。FIPS 140-3 / ISO/IEC 19790 検証は、検証プログラムによって確立され、デバイス（または特定のモジュール構成）が持ちうる性質であって — 呼び出し側のライブラリが付与するものでも、NextPDF がデバイスに代わって主張するものでもありません。NextPDF は PKCS#11 デバイスを通じた署名と 互換性があり、その署名経路はカテゴリーを代表するトークンで テスト済み です。ある特定のデプロイメントが FIPS モジュールレベル で検証されているかどうかは、ハードウェア、その証明書、そしてそれがどのように構成され運用されているかに完全に依存します。実際に手元にあるものを表す、正確な言葉を使ってください。

限界と境界

このページは、シームと、それが依拠する標準規格を説明します。デプロイメントの保証ではありません。その線引きは、はっきりと述べておく価値があります。

エンジンの責任。 署名フィールドを構築し、領域を予約し、バイト範囲を計算し、CMS SignedData を組み立て、署名プロバイダーを呼び出し、 Spec: ISO 32000-2, §12.8 に従って構造的に正しい署名を書き込むこと。NextPDF のハードウェア経路は、この目的において PKCS#11 署名インターフェースに準拠しています。
デバイスとオペレーターの責任。 ハードウェアの耐タンパー性、その FIPS 140-3 / ISO/IEC 19790 検証ステータス、鍵の生成と保管、 PIN ポリシー、スロット構成、ファームウェア、そして物理的セキュリティ。これらのいずれも、エンジンが証明するものではありません。
テスト済みは認証済みではありません。 NextPDF が代表的なトークンカテゴリー — 同じ PKCS#11 契約を通じて到達する、スマートカード、USB、ネットワーク、そしてクラウド KMS の形 — に対して 検証済みの経路 を持つことは、互換性の表明です。それは認証でも、検証済みモジュールの数でも、あなたの特定のデバイスについての主張でも ありません。以下のハードウェアカテゴリーは、 1 つの標準インターフェースを通じた統合の形です。それらは「シームが実際に試された場所」として扱い、あなた自身がテストしていないモデルに対する保証として扱うことは決してしないでください。
ポスト量子署名は実験的です。 エンジンがトークンを通じてポスト量子署名を公開する場合、それはオプトインであり、ゲートされており、ポスト量子 HSM のファームウェアではなくモックに対して検証されています。PAdES および AdES の暗号スイートカタログは、長期アーカイブ向けにそれらのスイートをまだ認めていません。本番運用可能なものとして扱わないでください。

PKCS#11 を通じた HSM ベースの署名 — edition availability
Edition	Availability
Core	このエディションにはありません。Core は署名エンジンと署名プロバイダーのシームを、ローカルのソフトウェア鍵プロバイダーとともに提供します。
Pro	クラウド鍵管理 — マネージド KMS 鍵を通じた署名 — は Pro の能力であり、挙動レベルでのみ説明されます。
Enterprise	利用可能です。PKCS#11 インターフェースを通じたハードウェアトークン署名（およびエンジン／プロバイダーのデプロイメント向けの OpenSSL コマンドラインブリッジ）は Enterprise の能力です。利用可能であることは能力の表明であり、いかなるデバイスやデプロイメントの認証でもありません。

1 つのインターフェースを通じた統合の形

これらは、PKCS#11 のシームが実際に試された形です。各列は「統合がどのように見えるか」であって、「検証済み・認証済み・数え上げられたデバイスのリスト」ではありません。

統合の形	到達方法	鍵の境界	保証は誰の性質か
スマートカード / PIV トークン	PKCS#11 モジュール、利用ごとの PIN が一般的	カード上、non-extractable	カードとそのオペレーター
USB HSM	PKCS#11 モジュール	デバイス上、non-extractable	デバイスとそのオペレーター
ネットワーク / アプライアンス HSM	ネットワークデバイスへの PKCS#11 モジュール	アプライアンス上、non-extractable	アプライアンス、その構成、オペレーター
クラウド KMS	マネージド鍵プロバイダー（Pro）	クラウドサービス内、決して返されない	クラウドプロバイダーとそのアテステーション
OpenSSL プロバイダーブリッジ	OpenSSL ブリッジを介した PKCS#11	トークン上、non-extractable	トークンとそのオペレーター

ミニ FAQ

鍵が PHP プロセスに入ることはありますか？ いいえ。non-extractable な PKCS#11 鍵では、秘密値はトークンの外部で平文として明かされることはありません。NextPDF はトークンの操作を通じて署名し、署名対象のバイトと返される署名だけを目にします。

HSM ベースの署名は PDF の内部で異なりますか？ いいえ。署名構造は、同じバイト範囲にわたる同じ CMS SignedData であり、同じ Contents エントリ内にあります。HSM が変えるのは 署名がどこで行われるか であって、ディスク上の形ではありません。

NextPDF を通じて HSM を使ったという理由で、FIPS 準拠を主張できますか？ 慎重に、という条件付きです。NextPDF はデバイスの FIPS ステータスについて何も主張しません。そのような主張はいずれも、NextPDF がそれを呼び出したという事実からではなく、デバイス自身の検証と、それがどのようにデプロイされているかから得られなければなりません。

インプロセスの PKCS#11 バインディングが利用できない場合はどうなりますか？ エンジンは、ソフトウェア鍵へ黙ってフォールバックするのではなく、ハードウェア署名が利用できないことを報告します。インプロセスのバインディングがトークンをロードできないデプロイメント向けには、OpenSSL コマンドラインブリッジの経路が存在します。

用語集

HSM（ハードウェアセキュリティモジュール） — 鍵を保持し暗号操作を実行することで、鍵素材がそこから決して離れないようにする、堅牢化されたデバイス。
PKCS#11 — OASIS の Cryptographic Token Interface 標準（歴史的には「Cryptoki」）。NextPDF がハードウェアトークンと通信するために使用する C インターフェース。
Non-extractable 鍵 — 秘密値がトークンの外部で平文として明かされることのない PKCS#11 鍵オブジェクト（CKA_SENSITIVE が true、または CKA_EXTRACTABLE が false）。
シーム — NextPDF における署名プロバイダーの境界。不透明なバイトが入り、署名オクテットが出ます。PDF と CMS の知識はその上に位置し、鍵はその背後に位置します。
CMS SignedData — 署名と証明書を PDF 内部に保持する、暗号メッセージ構文（RFC 5652）の構造。
FIPS 140-3 / ISO/IEC 19790 — 4 つの定性的レベルを定義する暗号モジュールのセキュリティ標準。呼び出し側のライブラリではなく、デバイスとその検証の性質。