本ページでは、当社が提供する技術の考え方について、実装やアルゴリズムの詳細には立ち入らず、当事者署名における不正署名リスクと、その真正性検証の概念を説明します。
リモート署名の連携モデル（Redirect / REST）
電子契約事業者のWebサーバから、リモート署名機能をRSSPサーバへRequest/Responseで提供する方式としては、主に次の2つが考えられます。
- HTTPSによるリダイレクト方式（ブラウザ遷移中心）
- RESTによるAPI連携方式（サーバ間連携中心）
当社は、既存の電子契約システムと結合しやすく、業務フローの置き換えを最小化できることから、REST API連携を基本とするモデルを採用します。
当社モデル：SCAとRSSPの強固な結合（mTLS）
当社の場合、各電子契約事業者（SCA）と当社RSSPサーバが、電子証明書による相互認証（mTLS）で強固に結合されます。
- SCA ⇔ RSSP間の通信主体を明確化
- 不正な接続・なりすましを抑止
- API連携の信頼境界を明確化
DTBSにバインドされた暗号学的同意（SAD相当）
署名要求に際して、署名者端末内で、DTBSに1対1で対応する暗号トークン（暗号学的同意の証／SAD相当）を生成します。このトークンは「署名者が“このDTBSに対して”同意した」ことを暗号学的に示すための情報です。
DTBS（Data To Be Signed）とは、電子署名において署名対象となるデータおよび、署名要求の正当性を検証するために必要な関連情報を含む署名対象情報を指します。
リモート署名TSP（RSS）においては、署名鍵はTamper ResistantなHSM内で厳格に管理されます。一方で、署名鍵の安全な管理は、署名要求の真正性までを保証するものではありません。署名要求と署名鍵管理が分離された構造では、署名要求の正当性が担保されない限り、不正署名のリスクが残存します。
【SCA↔RSSP（mTLS/REST）連携のもと、DTBS/Rバインドの同意トークン（SAD相当）をHSM（QSDV）内で検証し、検証OKの場合のみ署名を実行するアーキテクチャ】
本技術では、署名対象データ（DTBS）および署名要求に付随する利用者識別情報や暗号トークンを用いて、当該署名要求が正当な当事者から生成されたものであるかを技術的に検証可能とすることを前提としています。これにより、署名要求の改ざんやなりすましといったリスクを、署名実行前に検知・排除することを可能とします。
QSDV（HSM）内検証による“署名成立条件”の強制
当社RSSP側では、耐タンパ性のQSDV（HSM）内で暗号トークンを検証します。
検証をパスしなければ署名は実行されません。
- 署名鍵はHSM内で保護されるだけでなく、
- 署名実行の可否が「DTBSにバインドされた同意トークンの検証」により強制されます。
（注）暗号トークン（SAD相当）とQSDV（HSM）内検証の実装方式は、当社保有知財（日本・米国登録済み、欧州出願中）です。
SCAL2との関係（何が規定され、どこが設計論点か）
SCAL2は、署名鍵の活性化制御（sole control）を含む重要な到達点です。
一方で、実装上の論点は「署名者の同意」と「DTBS（署名対象データ）」を、どこまで強固に結合し、第三者に説明可能な形で担保するかにあります。
当社方式は、署名者端末とQSDV（HSM）間で、DTBSにバインドされた同意トークンを検証することで、“意図しないDTBSへの署名が成立しない”方向へ設計上の確実性を高めます。
この意味で当社方式は、
「SCAL2の枠組みに整合しつつ、DTBSバインディング（暗号学的同意とHSM内検証）を強化した実装モデル」と表現するのが適切です。
SAD再送（リプレイ）と運用・監査の負荷
一般に、認証情報や承認レスポンスの再送はセキュリティ上の論点になります。
当社方式では、同意トークンがDTBSに暗号学的にバインドされているため、
- 別DTBSへの流用：DTBS不一致により検証に失敗し、署名は成立しません。
- 同一DTBSへの再送：結果が同一となるため、別内容への不正署名にはつながりません。
したがって、いわゆる「再利用防止」は、要件に応じた運用制御（回数制限・有効期限・監査設計等）として整理できます。
情報開示について
本ページでは概念と考え方の説明に留めています。
実装方式、詳細仕様、運用設計については、PoCまたは個別協議の中で開示します。
（リンク：セキュリティ設計）
（リンク：DTBS入替えの怖さ）
（リンク：比較表（技術的優位性））