電子署名の技術
記録と電子文書のデジタル化システムを構築する際、私たちのチームは非常に実務的な課題に直面しました。職員がコンピュータに差し込んだUSB Tokenを使い、サーバー上に保存されている大容量PDFファイル（50MBから数百MB）に署名・承認するには、どうすればよいか？
最初は単純に聞こえますが、Web基盤での実装に着手すると、これは決して容易ではない技術的挑戦でした。
本記事では、**リモートハッシュ署名（Remote Hash-Signing）**という方法で、私たちがどのようにこの問題へ取り組み、解決したかを共有します。高速で軽量でありながら、情報セキュリティの基準にも正しく適合します。
1. 実務上の課題と3つの大きな障壁
デジタル化の工程では、スキャン文書の容量が非常に大きくなることが一般的です。利用者がコンピュータに差し込んだUSB Tokenで電子署名しようとすると、直ちに次の3つの障壁に直面します。
- WebブラウザはUSB Tokenを読み取れません： セキュリティ上の理由から、ChromeやEdgeなどのブラウザは隔離環境（Sandbox）で動作します。WebページがUSBポートに接続されたハードウェアへ自由にアクセスすることは、決して許可されません。
- 秘密鍵（Private Key）はUSB Tokenから取り出せません： 電子署名の法的価値はすべてUSB Tokenにあります。秘密鍵はハードウェアチップ内で保護されており、誰も複製したりサーバーへ送ったりすることはできません。
- 文書が重すぎてワークステーションへダウンロードできません： 署名のたびに100MB〜200MBのファイルをサーバーから利用者のコンピュータへダウンロードし、署名後に再びアップロードしなければならない場合、
- 特に多数の人が同時に署名すると、ネットワークは非常に遅くなります。
- 低スペックのコンピュータではカクつき、遅延、メモリ不足エラーが発生します。
- 個人端末へ一時保存されたファイルは、紛失や漏えいが起きやすくなります。
設定した目標： 職員はWeb上で操作するだけでよく、文書はサーバーが保持し、USB Tokenはワークステーションに差し込んだまま、署名処理はほぼ即時に完了し、絶対的なセキュリティを確保することです。
2. 解決の考え方: ファイル全体ではなく「代表コード」に署名する
幸い、暗号学では、電子署名は重い文書ファイル全体を処理することを要求しません。
100MBの文書全体に署名する代わりに、その文書のハッシュ（代表コード）を作成するだけで十分です。サイズは固定でわずか32 bytes（短いメッセージ1行程度）です。
この代表コードは「指紋」のようなものです。
- 文書が1ページでも1,000ページでも、生成される指紋コードは32 bytesのままです。
- 文書がピリオド1つでも修正されれば、この指紋コードは完全に変わります。
- この指紋コードへ署名・確認すれば、それは原本の内容全体へ署名・確認したことと同義です。
この考え方から、署名モデルは次の2つに分かれます。
- 大容量の文書： サーバー上に置いたままにします。
- ネットワーク経由で送るデータ： 利用者のコンピュータへ送る32 bytesのハッシュ列と、送り返す256 bytesの署名列のみです。
[従来の方法] [私たちの方法]
重いファイル全体をダウンロード 代表コードの文字列のみを送信
─────────────────────── ─────────────────────────
サーバー ──（100MBファイル）──► ワークステーション サーバー ──（32 bytesハッシュ）──► ワークステーション
ワークステーション ──（100MBファイル）──► サーバー ワークステーション ──（256B署名）─► サーバー
（遅く、ネットワーク障害が起きやすい） （1秒未満で完了）
3. 電子署名の処理はどのように動作するのか？
Webブラウザ、サーバー、USB Tokenを滑らかに接続するため、私たちは3つの簡単なステップからなる処理フローを構築しました。
sequenceDiagram
autonumber
actor User as 利用者
participant App as 支援アプリケーション（ワークステーション上）
participant Server as システムサーバー
participant Storage as 文書の保存先
Note over User,Server: ステップ1: サーバーの準備
User->>Server: Web上で「文書に署名」をクリック
Server->>Storage: 署名対象のPDFファイルを開く
Server->>Server: 赤い印影を描画し、PDF内に余白を確保する
Server->>Server: 代表コード（32 bytes）を計算する
Server-->>App: 32 bytesのハッシュを利用者のマシンへ送る
Note over User,App: ステップ2: USB TOKENで署名
App->>User: USB TokenのPIN入力を求める通知を表示
User->>App: PINを入力
App->>App: USB Tokenが32 bytes列に署名（秘密鍵はUSBから離れない）
App-->>Server: 署名結果（256 bytes）をサーバーへ送る
Note over Server,Storage: ステップ3: サーバーが完成させる
Server->>Server: ステップ1で確保した余白へ署名を埋め込む
Server->>Storage: 完成したPDFファイルを保存する
Server-->>User: Web画面上で署名成功を通知する！
ステップ1: サーバーが文書を準備する（Pre-Sign）
利用者が「電子署名」をクリックすると、サーバーは次を行います。
- 文書ファイルを取り出し、署名者名、所属機関、署名日時を含む赤い印影をあらかじめ描画します。
- 後で署名を置く場所として、PDFファイル内に小さな余白をあらかじめ確保します。
- 文書と署名時刻を含む代表コード（32 bytes）を計算し、この32 bytes列を利用者のマシンへ送ります。
ステップ2: 利用者のマシンでUSB Tokenにより署名する
WebブラウザはUSB Tokenを自ら読み取れないため、私たちは**コンピュータ画面の隅でバックグラウンド動作する小型アプリケーション（Local Signer）**を開発しました。
- このアプリケーションはサーバーから32 bytes列を受け取ります。
- USB Tokenを起動し、PIN入力を求めるウィンドウを表示します。
- 利用者が正しいPINを入力すると、USB Token上のチップがこの32 bytes列に署名し、短い署名列（256 bytes）を返します。
- 秘密鍵はToken内部で絶対的に安全に保持され、誰も取り出すことはできません。
ステップ3: サーバーが文書を完成させる（Post-Sign）
アプリケーションは256 bytesの署名列をサーバーへ送り返します。
- サーバーはこの署名を、ステップ1で確保した余白へ正確に配置します。
- PDFファイルは直ちに完成します。
- Adobe Acrobatなどの標準的なPDF閲覧ソフトでこのファイルを開くと、有効な緑のチェック印が表示され、文書が改変されていない完全な状態であることが確認できます。
4. 実務で得た注目すべき知見
ソリューションを実運用へ投入する過程で、私たちは3つの重要な教訓を得ました。
1. 複数人が署名する文書ではどうするか？
文書は多くの場合、複数の承認者を経ます。担当者の仮署名 ➔ 部門長の確認署名 ➔ 取締役の署名・押印。
後続の署名者が通常の方法でファイルを保存すると、ファイル構造が変わり、先に署名した人の署名が壊れます（PDFソフトは 「文書が変更されました」 とエラーを報告します）。
対処方法： **逐次追記（Incremental Update）**技術を使用します。つまり、既存の文書部分は修正せず、新しい署名をファイル末尾へ追加するだけです。これにより、文書は必要な数だけ署名を持て、すべてが有効なままになります。
2. 利用者が署名をクリックしたあと…立ち去る場合の処理
利用者がWeb上の署名ボタンをクリックし、サーバーは文書の準備を終えているのに、利用者が考えを変えて電源を切ったり、USB Tokenを抜いたりすることがあります。
対処方法： 自動取消の待ち時間を設定します（例：ちょうど5分）。5分経過してもサーバーが署名を受け取らなければ、システムは署名セッションを自動取消し、メモリを解放してサーバーの飽和を防ぎます。
3. スキャン画像や録音ファイルにはどう署名するか？
すべての文書がPDFであるわけではありません。
- 現物のスキャン画像： システムは画像上に赤い印を描画したうえで、原本画像を保護するために**別添の署名ファイル（
.p7s）**を作成します。 - 会議の録音ファイル： 音声を歪ませるものは一切挿入できません。システムは元の音声ファイルの代表コードのみを取得し、**別添の署名ファイル（
.p7s）**を作成して、音質を100%維持します。
5. 得られた成果
アプローチを変えたことで、電子署名システムは明確な効果をもたらしました。
- 極めて高速： ファイルを往復転送して数十秒から数分待つ代わりに、署名処理は1秒未満で完了します。
- 帯域を99%削減： 数百メガバイトではなく、数百bytesのデータのみをネットワーク経由で送信します。
- 絶対的な安全性： 秘密鍵が利用者のデバイスから離れることはなく、情報セキュリティ基準と法的要件を十分に満たします。
- 容易な体験： 利用者はUSB Tokenを差し込み、Webブラウザ上で直接操作するだけでよく、複雑なオフィスソフトをインストールする必要はありません。
おわりに
複雑な課題の解決策は、ときに処理すべきデータの部分を正しく選ぶことにあります。「保存すべき文書」と「署名すべき代表コード」を分離することで、私たちはネットワーク渋滞の問題を徹底的に解消しつつ、ハードウェア電子署名の安全性を完全に維持できました。
本記事が、電子文書管理および電子承認署名システムを構築されている皆様にとって、有益なヒントとなれば幸いです。
BK Hightechのエンジニアチームによる記事です。
執筆 Phan Van Tai
ソフトウェアエンジニア、BK Hightech