契約書は「署名がある」だけで、本当に安全と言えるのでしょうか
電子契約の安全性は、「電子署名が付いているかどうか」だけで判断できるものではありません。
重要なのは、誰が・何に・どの条件で同意し、その同意なく署名が成立しない構造になっているか、第三者に対して真正性を説明できるかです。
本ページでは、電子契約を安全に運用するために不可欠な本人署名」と「真正性保証」という2つの視点から、セキュリティ設計の考え方を整理します。
連携方式（Redirect / REST）と信頼境界
リモート署名の連携には、HTTPSリダイレクト方式とREST API連携方式があります。
当社は、電子契約事業者（SCA）と当社RSSPサーバをmTLSで相互認証し、REST APIで機能提供するモデルを基本とします。
- SCA ⇔ RSSPの接続主体を明確化し、なりすましや不正接続を抑止
- 監査・証跡設計（誰が/いつ/どの要求を出したか）を設計しやすい
電子契約における「本人署名」とは何を意味するのか
本人署名とは、単に「署名操作を行った人物が存在する」ことではありません。
署名の瞬間において、
・ 誰が
・ 何に（どのDTBSに）
・ どの条件で同意したのか
を、暗号学的に説明できる状態であることが求められます。
DTBSと同意を分離した設計がもたらす構造的リスク
多くの電子契約サービスでは、署名者の同意（画面確認・クリック等）と、実際に署名されるDTBSが論理的に分離されています。
この場合、条件次第でDTBSが差し替わっても、「署名は有効である」状態が技術的に成立してしまうケースが生じ得ます。
これは「署名が無効になる」問題ではなく、
そもそも何に同意したのかを説明できなくなる、という真正性の問題です。
SCAL2は重要な到達点だが、完全解ではない
SCAL2は、署名鍵の活性化制御を通じて第三者の不正介在リスクを大幅に低減する重要なモデルです。
一方で、DTBSの生成や署名要求をサービス提供側が制御できる設計では、
DTBS入替えのリスクを構造的に完全排除することは難しい場合があります。
DTBSバインド型SADによる「暗号学的同意」という考え方
図：SCA↔RSSP（mTLS/REST）連携のもと、DTBSバインドの同意トークン（SAD相当）をHSM（QSDV）内で検証し、検証OKの場合のみ署名を実行するアーキテクチャ
本方式では、署名者の同意を「操作の事実」ではなく「暗号学的に検証可能な同意」として扱います。具体的には、署名者端末でDTBSに1対1で対応する同意トークン（SAD相当）を生成し、
その正当性をRSSPが管理する耐タンパ性デバイス（QSDV／HSM）内で検証します。
この検証をパスしない限り、署名演算は実行されません。
署名者の同意なくして、署名が成立する余地そのものを排除する設計です。
なぜ本方式はリプレイ攻撃（再送）にならないのか
本方式では、同意トークンがDTBSに暗号学的にバインドされているため、
・同一DTBSへの再送：生成される署名結果（署名値）は同一となり、別内容への不正署名には
つながりません。
・別DTBSへの流用：DTBS不一致により検証に失敗し、署名は成立しません。
このため「再利用防止」は、セキュリティ要件というより、要件に応じた運用制御として整理できます。
eシールとの決定的な違い
「HSMで署名する」という点だけでは、電子署名とeシールの違いは説明できません。
決定的な違いは、署名意思（同意）を生成する主体にあります。
- 電子署名：署名意思は自然人である署名者の端末で生成されます。
- eシール：文書発行の意思は組織の業務ルールやシステムに帰属します。
本方式は、署名成立条件が「署名者端末で生成された同意トークン」である点により、eシールと区別されます。
“署名鍵の単独制御”をどう担保するのか
本方式では、署名鍵の使用可否を決定する権限そのものを、署名者の同意に1対1で対応させます。
その検証はQSDV（HSM）内で強制されるため、サービス提供者や第三者による代理署名の余地を構造的に抑止します。
各解説ページへのご案内
以下のページでは、各論点を詳しく解説しています。関心に応じてご覧ください。