1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

署名保証ガイドライン:2.2 -各種署名方式の整理-

1
Last updated at Posted at 2026-04-24

概要

「署名保証ガイドライン第1.00版(JNSA SAG-1:2026)」の2.2.章では、最近使われている各種の署名方式を整理しています。これは機能や仕組みを整理して共通化しないと共通した署名保証レベルが設定できないためです。ここでは基本となるローカル署名方式と当人認証技術を利用したリモート署名方式・認証記録署名方式・事業者署名方式の合計4方式を説明しています。しかしながらこれからはブロックチェーン利用等の新たらしい署名方式も出てくることでしょう。2.2.章ではまず基本としてこの4方式を説明しています。

本人性と非改ざんの保証

1章の解説で書きましたがSAG-1:2026では「「電子署名」の定義を、署名対象である電子データに証拠としての効力を持たせる事とし、「本人の身元(Identity)」「本人の意思(Approval)」と「非改ざん(Tamper-evidence)」の3つの要件を備えるものとする。」としています。非改ざんは分かりやすいですが本人の身元と意思と言うのは少し分かりにくいですね。

一方でDS-511では「本人確認を構成する要素として「身元確認」と「当人認証」を定義する。さらに、身元確認や当人認証を他者(信頼できるIDプロバイダ)に依拠して実現する要素として「フェデレーション」を定義する。」とあります。

この2つの定義から本人性に関する要素を抜き出すと「本人の身元/身元確認」と「本人の意思/当人認証」の2つと言えます。身元確認は良いとして、何故「本人の意思」と「当人認証」が同じと言えるのでしょうか。実は厳密には同じとは言えません。DS-511の方は認証(Authentication)を指しており、SAG-1:2026では認可(Authorization)を指しています。しかし認証と認可は技術としては認証技術を使っておりほぼ同等と言えます。認証技術を使った電子署名では「署名認可」により「本人の意思」を確認していると整理しています。

こう書くとID厨から「その認可と言う使い方は違和感がある」と言われるでしょう。ID業界では認可はリソースへのアクセス認可であることが多いです。一方で署名業界では証拠を残すための操作への許可を認可と呼んでいます。紛らわしいので出来るだけ「署名認可」としています。SAG-1:2026ではそのような前提で認可と言う言葉を使っています。

それでは4つの署名方式についてこの3要素はどうなっているかを整理したものが以下となります。

署名方式 身元確認 署名認可 非改ざん(保証)
ローカル 認証局
※証明書発行時
署名鍵の利用 デジタル署名
リモート 認証局
※証明書発行時
当人認証と
署名鍵の利用
デジタル署名
認証記録 署名サービス
※登録時
当人認証 原本保管や
アクセス制御等
事業者 署名サービス
※登録時
当人認証 デジタル署名

事業者署名方式は一般には立会人型電子署名とも呼ばれていますが、実は上の表を見ると身元確認と署名認可がリモート署名とは異なります。PDFファイルを利用した場合にはどちらもデジタル署名付のPDFファイルが出てきます。リモート署名では当人の証明書による署名であり直接認証局が本人性を保証してくれますが、事業者署名方式では認証局は署名サービス事業者を保証しているだけで、署名者が誰であるかは署名サービス事業者が保証しなければなりません。ただしだから事業者署名方式の保証レベルが低いと言う話ではありません。きちんと身元確認と当人認証をおこないその記録を署名サービス事業者が保証すれば問題ありません。

実は認証記録署名方式も本人性の部分だけ見ると事業者署名方式と全く同じであり、身元確認と当人認証をおこないその記録を署名サービス事業者が保証する方式です。ただし問題となるのは身元確認と当人認証の記録をどのように保管して検証者に提示するのかの部分が標準化されておらず事業者毎に異なる点は課題と言えます。事業者署名方式と認証記録署名方式の署名サービスを利用する場合には、身元確認と当人認証がその署名サービスにおいてどのように保証されるのか確認しましょう。

各署名方式の解説

2.2.1. ローカル署名方式

図2-2 ローカル署名方式(認証局保証 鍵自己管理)image.png

2000年の電子署名法ができた時には全てがこのローカル署名方式でした。当時はまだ認証技術が成熟しておらずIDとパスワードがメインでした。このことから認証局で申請者の身元確認した後に、申請者が保有管理する署名鍵と紐付いた証明書を認証局が発効します。これで申請者は署名者に昇格します。

署名者は自身が保有する署名鍵を利用してデジタル署名を生成して当人の証明書と共に検証者に提供します。ローカル署名方式では認証技術は使っていませんが、署名鍵を利用する為に署名鍵の「所有」とPIN/パスワードによる「知識」が要求されます。マイナンバーカードのようなICカードが分かりやすいと思いますが、ICカード(署名鍵)を所有しており署名時にはPIN/パスワード等の知識を入力しますよね。最近だと指紋認証カードのように「生体」情報を利用する場合もあります。そうですこれらの署名に利用するの必要な要素とは、NIST SP 800-63Bで説明されている認証要素(Authenticator)と同じです。

検証時には認証局から有効性確認の検証情報としてCRLやOCSPを取得して利用します。また大事な点として認証局では一般にはCP/CPS(証明書ポリシー/認証業務運用規定)を公開して守っていることにより、検証者がどのような身元確認されたか等の情報を取得できることです。

ローカル署名方式はPKI前提の完成された仕組みなのですが「署名鍵との紐付け」に手間やコストがかかることや、PKI原理主義とも言える「妥協なき電子署名」を目指したことから電子署名用途では普及したとは言えないのが現状です。とは言えマイナンバーカードのように行政が署名鍵を配りスマホ連携することで新たなステージに入っているようには思えます。もっと広くみるとVC(Verifiable Credential)のIHVモデルも、署名鍵をHolderが持っており、発行するIssuerが認証局であればローカル署名方式の一種と見ることもできます。やはり電子署名の基本となる署名方式と言えます。

2.2.2. リモート署名方式

図2-3 リモート署名方式(認証局保証型 鍵預託管理モデル)image.png

リモート署名方式はローカル署名方式で課題であった「署名鍵との紐付け」を解決することが可能です。リモート環境(クラウド環境と言っても良い)に署名鍵を預かり、当人認証(署名認可)により署名鍵を利用してデジタル署名をおこないます。預かっている署名鍵の扱いに注意は必要となりますが、署名鍵の再生成や証明書の発行も全てリモート環境で可能となるので、全ての処理をオンライン完結することが可能となります。

署名時に生成されるデジタル署名と添付される当人証明書はローカル署名方式と全く同じとなります。認証局の役割も身元確認と証明書発行まではローカル署名方式と同じです。ただ認証局または別のサービスとしてオンライン上での鍵管理が必要となる点が異なります。また当人認証(署名認可)が適切に行われていることは、認証時の記録として検証者に提供されるべきです。その点はローカル署名方式よりは手間と言えますが、オンライン完結できることはクラウド自体に向いた署名方式と言えます。特にワンタイム証明書やショートターム証明書のような有効期間が短い場合に向いた署名方式です。

検証やCP/CPSはローカル署名方式と同じですが、CP/CPSに加えて鍵管理サービスの運用規定も標準化されることが期待されます。欧州では既にeIDASで要件が決まっていますが、まだ日本ではそこまでは標準化されていません。とは言え日本においてもリモート署名方式は使われるようになって来ています。今年7月から商業登記電子証明書がリモート署名対応しますし、民間の認定認証局でも対応しています。また色々課題は残っていますが、HPKIのセカンド証明書もリモート署名方式の一種と言えます。JNSAの勉強会であるリモート署名/eシールの現在と未来と言うイベントで資料公開していますのでご興味あればご覧ください。

興味深いのは欧州のウォレットであるEUDIWにおいて、VPへの署名鍵をスマホ内ではなくリモート署名を認めたことでしょう。署名鍵をローカルに置くのかリモートに置くのかはこれからも揺れ動きそうです。

2.2.3. 認証記録署名方式

図2-4 認証記録署名方式(事業者保証 認証記録)image.png

身元確認と当人認証を署名サービス事業者がおこなうのが認証記録署名方式です。実は米国ではデジタル署名は電子署名の要件ではありません。署名サービスが署名者の本人性を保証して裁判で勝てるのであれば利用が可能です。初期のDocuSignと言うサービスはこの認証記録署名方式と言えます。今はDocuSignも他の署名方式も対応していますので念のため。

認証記録方式ではPKIや認証局は不要です。署名サービスで身元確認をおこなった上で当人に紐付いた認証要素を使って当人認証(署名認可)を署名サービス自体が提供します。本人性の保証も署名サービス事業者がおこなうので、確かに当人が署名したと言うデジタル署名付の証明書を発行する場合もあります。裁判になるとどうやって身元確認された当人が署名したかを問われるのでその対応も必要です。ただデジタル・フォレンジックは後から証拠を探す技術ですが、電子署名と言うならば事前に検証手順が決まっており求めに応じて証拠(例えば当人認証のログ等)を出せる必要があるでしょう。

認証記録方式は署名鍵の配布が不要なので手軽に利用が可能ですので、特に米国では広く使われています。一方で検証については標準化された要件や仕様がなく、各署名サービス事業者毎に異なっているのが現状です。認証記録方式では署名サービス事業者を信頼することが必須のサービスと言えます。ローカル/リモート署名方式は本人性に関しては認証局を信頼することになります。

認証記録署名方式の課題は非改ざんの保証をどうするかです。原本をリモート(クラウド)上で管理する等の工夫が必要です。実は非改ざんと事業者の保証を兼ねて署名サービス事業者がデジタル署名を付けると次に説明する事業者署名方式となります。事業者署名方式は認証記録署名方式の一種と言えます。

2.2.4. 事業者署名方式(立会人型署名方式)

図2-5 事業者署名方式(事業者保証 事業者署名)image.png

先に書いたように事業者署名方式(立会人型署名方式)は、認証記録署名方式に事業者のデジタル署名を加えた方式です。デジタル署名によりまず非改ざんについては保証されます。また事業者のIDによる証明書を使うことで、その署名サービス事業者が保証する署名となります。

デジタル署名を使っているのでローカル署名等と例えば署名済PDFファイル等では一見すると差異が無いように見えます。しかしながらローカル署名方式では署名を作成付与しているが署名者自身であるのに対して、事業者署名方式では当人のデジタル署名では無い点に注意が必要です。この差異をきちんと理解して利用することが大事だと考えています。

署名者の保証は認証記録署名方式と同様にあくまで署名サービス事業者が保証します。裁判になるとどうやって身元確認された当人が署名したかを問われるのでその対応も必要です。そこの部分が、つまりは検証手順が標準化されていない点はとても気になります。これは認証記録署名方式や事業者署名方式の方式の問題ではなく、単純に技術的な課題です。電子署名として見た時に相互運用性の有無と言うのは気になる点ですので是非業界で標準化を進めて欲しいと考えています。

とは言え現在サービス提供されている事業者署名方式のサービスは利用が手軽であることから広く使われています。電子署名の業界の技術者の一人としては認証記録署名方式と事業者署名方式について検証までを含めた標準化に興味がありますし期待しています。これは次回の署名保証レベルにも関係してくる話です。

おわりに

どうでしょうか、色々な署名方式があるんだなと言うことが少しはお分かりいただけたのであれば幸いです。今回の整理によって各署名方式を「登録時」「署名時」「検証時」の動きとして分けることができました。次回はこれに「運用」を含めて整理することで、署名方式に依存しない署名保証レベルについて解説します。

署名保証ガイドライン解説シリーズ

タイトル 概要
0 リリースしました! 署名保証ガイドライン第1.00版の概要
1 電子署名(と電子認証)の要件 電子署名(電子認証)とは?
2.1 署名サービスの基本モデル 電子署名の基本モデルの定義
2.2 各種署名方式の整理 ローカル署名と認証技術を使った様々な署名
2.3 電子署名の保証レベル SxAL(SIAL/SPAL/SDAL/SOAL)の解説
3 電子署名のリスク管理(仮) リスク管理と保証レベルの選択
A 適合宣言と情報公開(仮) 信頼と情報公開
B 承認目的署名と発行元保証署名(仮) eシール的署名とは
C 電子委任(仮) 委任状モデルと問合せモデル
D トラスト設計(仮 署名と認証による設計
1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?