本人署名とは何か？電子契約における署名技術の本質

“誰が押したか分からない署名”は、署名とは呼べない

電子契約では「署名が付いている＝本人署名」と誤解されがちです。しかし実務や訴訟の場では、「誰が、どのように署名したのか」を説明できなければ、本人署名とは認められません。
本ページでは、電子契約における本人署名技術の本質を解説します。

RSS署名における同意検証アーキテクチャ

RSS署名では、署名者は単一の電子契約事業者（署名者のホストSCA）を介して、RSSPサーバに対しREST API（Request／Response）で署名要求を行います。この構成により、署名者端末が直接署名鍵やHSMに触れる必要はありません。
署名者の同意は、RSSPが管理する耐タンパ性のQSDV（HSM）内部で検証されます。具体的には、署名者端末内で生成されたDTBSに1対1で対応する暗号トークンがHSM内で検証され、その検証に成功した場合にのみ署名が実行されます。
このため、署名者の明示的な同意（トークン検証の成功）なしには、署名が成立する経路そのものが存在しません。これは、DTBSバインド型SADに基づく暗号学的同意（cryptographic consent）によって、SCAL2相当の本人単独制御を実現する構造です。

この構成が持つセキュリティ上の利点

このアーキテクチャの最大の特長は、「署名の成立条件」が技術的に非常に明確である点にあります。署名は、署名者端末で生成されたDTBSと対応する暗号トークンが、RSSPのHSM内で正しく検証された場合にのみ実行されます。そのため、電子契約事業者やRSSP自身が、署名者の同意を伴わずに署名を実行することはできません。
また、DTBSと同意情報が暗号学的に結び付けられているため、契約書本体の差し替えや、事後的な解釈変更を技術的に排除できる点も重要です。

まとめ

RSS署名では、署名者の同意がDTBSに1対1でバインドされた暗号トークンとして生成され、その正当性がHSM内で検証されることでのみ署名が成立します。この構造により、署名鍵の不正使用や代理署名を排除しつつ、SCAL2相当の本人単独制御を「トークン検証＝署名許可」という形で実装しています。