電⼦署名 保証レベル ガイド
JNSA eSignAL Guide- 要約版 Ver 1.0 JNSA 電⼦署名WG 保証レベルTF
2022/09/08

はじめに：電子署名保証レベル

Page 2

2001年4⽉電⼦署名法が施⾏された時は 「電⼦署名」とは「公開鍵暗号を利⽤したデジタル署名と公開鍵インフラ(PKI)」 を前提としていました。
⼀⽅で電⼦認証によるクラウド利⽤のサービスが⼀般化したこともあり、電⼦
署名サービスも多様化し⾊々な電⼦署名の技術や⽅式が使われるようになりました。現在は単純に 「電⼦署名＝デジタル署名＋PKI」 とは⾔えません。
しかし技術や⽅式が異なる電⼦署名⽅式の⽐較は簡単ではありません。
「技術に関する電⼦署名の保証レベル」 を専⾨家が公平に策定し標準化を
⾏い電⼦署名利⽤者が⽬的に合った選択ができるようになることが重要です。
JNSAの電⼦署名ワーキンググループでは新たに保証レベルタスクフォースを発⾜し電⼦署名の保証レベルの策定を⾏いました。最終的にはガイドブックの公開を⽬指していますが、本資料はその要約版として公開するものです。

Page 3

１．電⼦署名の整理
最初に電⼦署名の法的要件や定義を整理して、電⼦署名の再定義を⾏います。

署名・押印と二段の推定（非電子）

Page 4

⾮電⼦における署名・押印に関して ⺠訴法第228条第4項 に以下の規定があります。
「私⽂書は、本⼈[中略]の署名⼜は押印があるときは、真正に成⽴したものと推定する」（⼆段⽬の推定）
この「推定」の前提となる「押印」の「推定」が 最⾼裁判例 昭和39.5.12⺠集18-597 にあります。
「本⼈の印鑑による印影があれば本⼈の意思による押印と推定する」（⼀段⽬の推定）「真正な成⽴」の「推定」を得る為には⼀段⽬の推定の前提の⽴証と、⼀段⽬及び⼆段⽬の推定の主張が必要となります。
これは署名・押印に関する「⼆段の推定」と呼ばれ、電⼦署名においても参照すべき考え⽅です。
参考︓「暗号技術と法律について」 JNSAメールマガジン 第38号 2014.6.27
https://www.jnsa.org/aboutus/jnsaml/ml-38.html
⽤語解説＞
印章（ハンコ）︓物理的なハンコのこと。これを「印鑑」と呼ぶ場合が多いが、本来は、印鑑は印影の⼀種であり、印鑑は物としてのハンコではない。
印影 ︓ハンコを使って押印した朱⾁による跡のこと。
印鑑 ︓実印や銀⾏印などの登録された印影のこと。印鑑証明書は印影の証明であり真偽を確認する為に利⽤される。

電子署名と二段の推定の考察

Page 5

電⼦署名法の第三条には、電⼦⽂書に関する、押印における⼆段⽬の推定と同様の規定があります。
「電磁的記録に記録された情報について本⼈（の意思）による電⼦署名が⾏われているときは、真正に成⽴したものと推定する」
この推定の前提については判例等がありません（押印の⼀段⽬の推定に相当するものがありません）ので、何らかの⽅法で「本⼈による電⼦署名が⾏われたこと」を証明する必要があります。このため、通常は、「本⼈による電⼦署名（管理された署名鍵や認証要素による署名認可の⾏使）の証拠を提⽰することにより、本⼈の意思による電⼦署名を証明する」という証明⽅法が⾏うことになりますので、本⼈性の証明のために、こうした証拠を備えることが重要です。
また、電⼦署名法の第⼆条第⼀項第⼆号において⾮改ざんの要件も必要となります。
「当該情報について、改変が⾏われていないかどうかを確認することができるものであること」
電磁的記録に関しては改変が紙媒体に⽐較して容易であることから追加されたと考えられます。
⽤語解説＞
電⼦署名︓法律上の⽤語であり（技術⽤語では無い）⾊々な署名⽅式が認められる（電⼦署名法2条1項）。
デジタル署名︓公開鍵暗号⽅式を⽤いた署名技術であり署名鍵による署名者を証明し改ざん防⽌を実現する。

電子署名の定義

Page 6

電子署名（広義）
身元確認

電子署名（狭義）（登録プロセス）（署名プロセス）

生成

電子署名証拠

署名検証（署名データ）（検証属性データ）（検証プロセス）

狭義︓電⼦署名法 第２条第１項 の電⼦署名「デジタル情報（電磁的記録に記録することができる情報）」について⾏われる「措置」であって以下のいずれにも該当するもの。
① 当該情報が、当該措置を⾏った者の作成に係るものであることを⽰すためのものであること（同項第１号）② 当該情報について、改変が⾏われていないかどうかを確認することができるものであること（同項第２号）※ 本資料では「措置」とは「プロセス」と⾔えると考えている。

広義︓本⼈確認から署名時⽣成した署名データを使い第三者が署名検証するまで

法的な定義は措置（署名プロセス）のみだが、登録プロセスの⾝元確認と署名プロセスで⽣成する電⼦署名証拠と検証プロセスまでの全体を指して広義の電⼦署名とする。本ガイド中では「電⼦署名」を広義の定義にて利⽤。
検証結果として ①本⼈性（本⼈の意思）と ②⾮改ざん性（⾮改変） が確認できることが必要となる。

電子署名の一般的手順

Page 7

手順

登録
プロセス
（IAL）

情報
確認

身元確認 （属性確認：Identity Proofing）
登録発行 （証明書発行や認証要素登録）

本人属性

提供・共有
認証

認証要素・署名鍵

認証要素（ID）
電子証明書（PKI）
署名鍵管理（PKI）

当人認証 （サービス認証：署名者確認）
署名
プロセス（SAAL）

内容確認 （署名対象の提示と理解）
署名認可 （署名意志確認の認可処理）

検証
プロセス（VDAL）

確認
署名

署名検証 （検証者が署名データ等を検証）①本人性（本人の意思） と ②非改ざん性（非改変） を
第三者が確認するプロセス。

署名対象

準備・提供

署名データ
検証属性データ

電子署名証拠（PoESign）

署名後に外部から取得する検証情報
電子証明書/CRL/OCSPやIDアサーション・ログ等

Page 8２．電⼦認証の整理
クラウドを利⽤した電⼦署名では必須となる電⼦認証の⽤語や定義も整理します。

電子認証：身元確認と当人認証

Page 9Onboarding（登録時）に Identity Proofing（⾝元確認）が必要
 Identity Proofing︓提供された属性情報の確かさを確認する。

例︓メール到達・運転免許証・マイナンバーカード等を利⽤して本⼈属性を確認。
 KYC（Know Your Customer）も本⼈確認。
サービス事業者のための、本⼈確認⼿続き（KYC）に関する調査レポート
https://www.openid.or.jp/news/oidfj_kycwg_report_20200123.pdf

 本⼈確認には継続した確認が必要でありコストもかかる（鮮度がある）。

Ongoing（利⽤時）に Authentication（当⼈認証）が必要
 Authentication︓利⽤者とID情報との紐付けを確認する。

例︓パスワード（知識）・指紋（⽣体）・ICカード（所有）等を利⽤して当⼈を確認。
 電⼦署名の場合は当⼈認証後に署名対象の内容確認を⾏ってから署名認可を⾏う。
ローカル署名は、（正当な署名データの⽣成による）署名鍵の所持の証明が、当⼈認証相当と考える。

※ オンラインで本⼈と認める為には ⾝元確認済みのID情報を使った当⼈認証 が必要。

電子認証 / Digital Identity 用語

Page 10

ID/Identifier︓１つの実体（エンティティ）に付す識別⼦となる属性情報
Identity︓実体（エンティティ）に関する属性情報の集合 ID/IdentifierとはIdentityの持つ属性情報の１つで識別/特定に利⽤する。
 １つの実体は、複数のID/Identityを持つことができる。
 ⼈は実体をIdentity（属性の集合）を通じて認識する。

Authentication/AuthN（認証）︓

端末の前にいる実体がサービス側が認識するどのIdentityと紐付いているかの確証を得るプロセス。
サービス認証︓署名サービス等の利⽤開始時にどのIdentityと紐付いた実体かを確認する。
Authenticator（認証器/認証コード）︓Credential（信⽤）情報を扱う

Authorization/AuthZ（認可）︓

端末の前にいる実体がサービス側が提供するリソースに対するアクセス権限を持っているか確認するプロセス。
署名認可︓電⼦署名付与の為に署名鍵（リソース）を利⽤する権限を持つか確認する。

Access Control（アクセス制御）＝AuthN＋AutnZ＋Audit [logging/監査ログ]

ID認証技術

Page 11

認証認可の広く使われている標準的な技術仕様には OAuth+OpenID Connect や SAML 等がある。
本資料では「電⼦認証」は「電⼦署名」に対応した⽤途全体を⽰す概念的な⾔葉として利⽤する。
本資料では「ID認証」と書いた場合には OAuth + OpenID Connect 等の具体的な技術を指す。
OAuth 2.0 +OpenID Connect(OAuth+OIDC)※ OAuth 2.0 は認可の仕様※ OIDC はID認証の仕様

OAuth 2.0 Authorization Framework （RFC 6749）
https://tools.ietf.org/html/rfc6749
https://openid-foundation-japan.github.io/rfc6749.ja.html [和訳]策定：IETF（インターネットコミュニティ）2012年発⾏の認可標準仕様
メッセージ送受信：HTTPS（RESTful）、通信プロトコル：JSONベース
OpenID Connect 1.0︓OIDC （オープンIDファウンデーション）
https://openid.net/connect/

http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html [和訳]策定︓オープンIDファウンデーションが2014年に1.0を発⾏の認証標準仕様
OAuth 2.0 プロトコルにアイデンティティ層（認証）を追加した（OAuth 2.0を参照）

SAML

SAML （Security Assertion Markup Language）※ SAMLは認証認可の仕様

策定：OASIS v2.0 を2005年発⾏の認証認可の標準仕様
メッセージ送受信：SOAP/HTTP、通信プロトコル：XMLベース
主な実装：Shibboleth（学術系で広く利⽤されている）

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

Page 12３．電⼦署名と電⼦認証の関係
電⼦署名を使った電⼦認証や、電⼦認証を使った電⼦署名もあります。
電⼦署名と電⼦認証の関係を整理します。

電子認証と電子署名の利用モデル比較

Page 13

電⼦認証︓

認証プロセス

認証コードの確認（検証） 認証プロセスで利⽤者を確認。
※ 認可はリソースへの権限を確認。
※ リアルタイム処理。

認証サーバー

電⼦署名︓

認証コード
or 署名鍵利⽤者（利⽤者の確認）※ 認証コードの検証結果を第三者が検証可能な署名データとして残せば電⼦署名にもなる。

 署名プロセスで署名データを作成。
 検証プロセスで署名データを確認。
※ 署名データを挟んで時間差あり。
時間差

署名プロセス
署名鍵 or
認証コード

署名者

署名プロセス
署名データ（誰が何に）※ 時間差無しでサーバで検証することで電⼦認証にもなる。

検証属性
データ

検証者
検証プロセス

電子認証と電子署名の整理

Page 14

 電⼦認証＝認証プロセス

 端末の前の実体（⼈）とIdentityを認証サーバー側で紐付ける認証プロセス。
 認可は認証後のリソースへのアクセス権限の確認プロセスであるが混同されがち。
•

署名認可のように認可の為に２要素認証等の認証技術を使うことがあり区分が難しい。

•

RP: Relying Party の略でサービス提供するサーバー

 認証の結果は認証サーバーが確認できればよい（RP等サーバー連携はある）。
 認証時の情報は認証サーバー内にログ等として保存されるが通常開⽰されない。

 電⼦署名＝署名プロセス＋署名データ＋検証プロセス

 署名者による署名対象の署名プロセスと検証可能な署名データの作成。
 署名プロセスでは署名者が当⼈であり（ここまで認証プロセスと同じ）、かつ当⼈が内容（署名対象）を理解し認めている必要がある。
 検証者による署名データ等から署名者と⾮改ざんを確認する検証プロセス。
 技術としてデジタル署名（PKI）とID認証のうち⽚⽅または両⽅を使っている。

※ 電⼦認証と電⼦署名のどちらも 事前の⾝元確認（Onboarding）による実体の属性チェックが必要。

デジタル署名の用途

Page 15

証拠︓Authenticity/Non-Repudiation（意思表⽰・本来の電⼦署名）

 署名対象の内容についての同意を後から否認できないように証拠を残すこと。電⼦署名法の対象。

証明︓Certification（発信者保証）

 署名対象の内容について発信者が保証する為に証拠を付けること。電⼦シール的な使い⽅。
 PKI（公開鍵基盤）では公開鍵証明書に付属するCA（認証局）の署名が発信者の証明をする。

※ 証拠と証明は⽤途では明確に分かれておらず多くの電⼦署名の使い⽅ではグラデーションのように両⽅の意味を持つ。
例︓電⼦申請やS/MIME署名は同意と証明の両⽅の意味を持つが、同意単独よりは署名認可は厳密ではない。

認証︓Authentication（当⼈確認）

 署名対象に署名することで当⼈管理の署名鍵や認証要素の所持を確認（PoP/HoK）すること。
・ PoP︓Proof-of-Possession（鍵所持の証明） ・ HoK︓Holded-of-Key（鍵の所持者）

分類
署
名

証拠
証明
認証

主⽬的

署名対象

署名データ

署名認可

利⽤例

否認防⽌

署名者の内容理解が必要

証拠として保管

署名毎に⾃然⼈が認可（⾃動不可）

電⼦契約
重要⽂書の保管

署名者が作成確認時に利⽤

ルールによるシステム⾃動の認可も可能

発⾏⽂書の保証
公開鍵基盤（PKI）

認証側が⽤意

確認後は不要認証毎に必要TLSクライアント認証（電⼦署名的）

署名者保証（電⼦シール的）

当⼈確認

例:チャレンジデータ

電⼦
申請

Page 16４．電⼦署名証拠︓PoESign
新しい概念である電⼦署名証拠（PoESign）を定義することにより、新しい電⼦署名⽅式の分類や整理が可能となります。
※ 電⼦署名証拠 PoESign は保証レベルTFから新たに提案する定義です。

電子署名証拠 PoESign （Proof of Electronic Signatures）

Page 17• 従来の電⼦署名（ローカル署名⽅式）では、本⼈管理の署名鍵によるデジタル署名とPKI
ベースの電⼦証明書を使って署名データを作成している。検証時に、認証局から発⾏される署名データと検証属性データ（CRL/OCSP）を使って本⼈性と⾮改ざんを確認している。
• デジタル署名は検証時に、署名対象＋署名データ＋検証属性データ が必要となる。
 署名データ︓署名時に作成される情報

 内包型署名データ︓署名対象に署名データを埋め込む形式。例えばPDF署名は全て内包型となる。
 分離型署名データ︓署名対象とは別に署名データを管理する形式。XML署名のDetached形式等。

 検証属性データ︓検証時に利⽤する外部情報（PKIなら電⼦証明書/OCSP/CRL等）

 ⻑期署名データ︓署名データに必要な検証属性データを埋め込み全体をタイムスタンプで守る形式。
 アサーション︓認証結果を⽰す認証サーバーがデジタル署名した情報。IDトークンと検証公開鍵等。

• 認証技術を利⽤した電⼦署名⽅式も署名データや検証属性データが証拠として必要。
• 署名データと検証属性データを組み合わせた情報群全体を、電⼦署名証拠（PoESign:
Proof of Electronic Signatures）として定義することで電⼦署名の整理を容易にする。
※ 電⼦署名証拠（PoESign）︓本⼈性（本⼈の意思）と⾮改ざん性（⾮改変）を確認できる情報群。

署名鍵証拠 PoKEY （Proof of signature KEY）

Page 18

PKI（電⼦証明書）とデジタル署名を利⽤する場合の電⼦署名証拠は標準化されている。

PKI/CA（認証局）︓X.509電⼦証明書/CRL/OCSP

 認証局の運⽤による⾝元確認と、認証局がデジタル署名したX.509電⼦証明書が、
署名鍵の所有者の本⼈性を保証する証拠となる。
 CRL（失効リスト）やOCSP（オンライン証明書ステータスプロトコル）を取得保存することにより電⼦証明書が発⾏後失効していないことの証拠となる。
 国の認定や国際的なWebTrust認定等により認証局の運⽤が保証されている。
※ 事業者型の場合には事業者の保証であり本⼈性保証の証拠にはならない。

AdES︓先進署名フォーマット（⻑期署名フォーマット） PAdES（PDF）、JAdES（Json）、XAdES（XML）、CAdES（CMS）等のISO 14533シリーズや欧州のETSI（eIDAS）で標準化された署名形式。
 ⾮改ざんに加えて、電⼦証明書の有効期間を超えた署名の保証が可能であり、署名アルゴリズムの危殆化にも対応した証拠となる。

署名認可ID証拠 PoAID （Proof of Authorization ID）

Page 19

ID認証技術を電⼦署名に利⽤する場合の電⼦署名証拠には以下２つが想定できる。

署名時の認証認可の各種ログ情報（デジタル署名無し）

 認証認可（アクセス）ログ・操作（イベント）ログ・アクセスログ等があるが、不⾜が無いように必要⼗分な情報を記録するようにする必要がある。
 ⼀般にはログ情報にデジタル署名をすることは無いが、削除や改ざんがされないような措置が必要。例えばRFC 3161形式のタイムスタンプを付与することで守る等。
 署名時の監査ログに事業者がデジタル署名した上で検証属性データとして提供してもよい。フォーマットは標準化されていないが必要な情報を全て含む必要がある。
• 署名時のイベント毎の⽇時・イベント種別・認証（実体の識別）・成否等とアクセス情報が必要。

署名時の認証認可のアサーション情報（デジタル署名済み）

 Open ID Connect の ID Token や SAML Assertion 等の、IdP等の認証サーバーでデジタル署名された認証時の情報。検証は後⽇⾏われる為に、デジタル署名を検証する公開鍵や電⼦証明書と共に保存されることが望ましい。

電子署名証拠 PoESign まとめ

Page 20

PoESign : Proof of Electronic Signatures

電⼦署名証拠（現在はPoKEYとPoAIDのどちらか１つまたは両⽅で構成される）

PoKEY : Proof of signature KEY

PoAID : Proof of Authorization ID

format: PAdES/XAdES/CAdES/JAdES...

format: assertion（JWT） /audit logs..

署名鍵証拠（デジタル署名証拠）

略称

名称

署名認可ID証拠（ID認証の証拠）

概要

PoESign

電⼦署名証拠

本⼈性と⾮改ざん性を保証する為のPoKEY・PoAID等で構成されるデータ群。
電⼦署名証拠は第三者（検証者）により検証（確認）可能である必要がある。

PoKEY

署名鍵証拠

電⼦証明書と署名鍵利⽤のデジタル署名/PKIを保証する為のデータ群。
ISO/JIS等の先進署名（AdES）フォーマット等で標準化され⾮改ざんも保証される。
署名鍵は、本⼈所有の場合（本⼈保証）と、第三者（事業者保証）の場合がある。

PoAID（デジタル署名証拠）

署名認可ID証拠（ID認証の証拠）

署名認可時のID認証認可を保証する為のデータ群。⾮改ざんの保証が別途必要。
アサーション（id_token等でIdP等の署名が必要）やアクセス/操作/監査のログ等。
アサーションの署名を後から検証可能とする為にIdP等の公開鍵も保管が必要。
IdPによる認証部以外はフォーマットが標準化されているとは⾔えず検討や策定が必要。

Page 21５．電⼦署名⽅式の分類
電⼦署名証拠（PoESign）により電⼦署名⽅式を分類します。
電⼦署名⽅式毎に求められる電⼦署名証拠の内容が異なります。
※ 各電⼦署名⽅式は保証レベルTFが独⾃に分類したものです。

電子署名証拠による電子署名方式の分類
認可ID（認証コード）

ローカル署名（当人型署名）

認証記録型署名（新定義）

リモート署名（当人型署名）不要（本人鍵管理の為）

署名者
当人

署名鍵

電子署名証拠（PoESign）
KEY

署名者
管理

PoKEY：当人署名鍵証拠（非改ざん・本人性保証）（ICカード等）※ 鍵は本人管理前提なのでPoAIDは不要

ID
未使用

PoAID：署名認可ID証拠（本人性保証）※ 非改ざんはアクセスコントロール等で保証

署名者
当人

ID

紐付け

KEY

サーバー
管理

署名者
当人

ID

保証

事業者
（自動署名）

PoKEY：当人署名鍵証拠（非改ざん・本人性保証）

PoAID：署名認可ID証拠（HSM）

事業者型署名Page 22（IDとKEYの紐付け保証・本人性保証）

KEY

PoAID：署名認可ID証拠（本人性保証）PoKEY：事業者署名鍵証拠（非改ざんと署名の第三者保証）

方式１：ローカル署名（当人型署名）
KEY

署名鍵所有（鍵管理）

Page 23

PoAIDが無くても本人性が保証可能

内容確認・署名付与

署名アプリ（ローカルPC）

PoKEY
署名者

（当人）

署名証拠

本人性・非改ざん（PKI保証） 署名鍵の管理を署名者本⼈が⾏い、ローカル環境で本⼈がデジタル署名を⾏う。
 本⼈の署名鍵を使いデジタル署名の署名鍵証拠 PoKEY（PAdESやXAdES等）を⽣成する。署名データのフォーマットや検証⼿順は標準化されている。
 本⼈の署名鍵と紐づいたPKIベースの電⼦証明書を、認証局が本⼈の⾝元確認を⾏った上で発⾏し保証することで本⼈保証を実現している。
 電⼦署名法における認定認証業務は、ポリシーや運⽤が法令に規定された厳格な⽅法に従っていることが認定されており、本⼈による電⼦署名であることの証明は容易となる。
 電⼦署名法が想定していた署名⽅式でありローカル署名の保証レベルが基本となる。

方式２：認証記録型署名
ID

ID（認証コード）所有

内容確認・署名認可
PoAID
署名者

本人性
（ID保証）（当人）

署名証拠

Page 24

非改ざん（サービス保証）記録
署名サービス

 署名者が署名サービスに当⼈認証にてログインし、ログ情報や認証アサーションを保存する⽅式。改ざん防⽌が別途必要（アクセスコントロールや改ざん不可媒体保存等）。
 電⼦署名とする為には認証要素の本⼈管理を⾏い、署名認可時の署名証拠 PoAID（認証アサーションやログ情報）を記録し検証者に提供する必要がある。
 本⼈の電⼦署名であることをPoAIDや改ざん防⽌の証拠等で⽴証する必要がある。
 認証局/PKIを利⽤した場合と⽐較して、署名者の⾝元確認の標準や認定が無い為、本⼈確認保証レベル（IAL）が低いことが多いので、確実な⾝元確認が望まれる。
 業界（例︓製薬）によっては認証記録型を「電⼦署名」として認めている場合もある。

方式３：リモート署名（当人型署名）
ID

IDに紐付けて署名鍵を所有
ID（認証コード）所有

KEY

Page 25

鍵管理

内容確認・署名認可

署名者

本人性（ID紐付保証）

PoAID

PoKEY

（当人）

（当人）

署名証拠

本人性・非改ざん（PKI保証）記録
署名サービス 本⼈の署名鍵の鍵管理を署名サービスに任せ署名鍵に紐づいたIDを使った当⼈認証の署名認可にてデジタル署名を⾏う。本⼈確認は基本的には認証局が⾏うが、署名認
可⽤の認証要素の発⾏か登録が必要。署名認可⽤の認証要素は本⼈管理が必要。
 署名データはローカル署名と同じ本⼈の署名鍵証拠 PoKEY（PAdESやXAdES等でローカル署名と同じ内容）となるが、署名鍵とIDとの紐付けを保証する為に署名認可時の署名証拠 PoAID（ログ情報や認証アサーション）も必要。
 欧州では既に標準化されており、ローカル署名と同程度の保証レベルとされている。
 同じ当⼈型のローカル署名と署名鍵証拠 PoKEY では区別が付かない課題がある。

方式４：事業者（立会人）型署名
ID

事業者が署名者IDを保証

Page 26

KEY

ID（認証コード）所有

事業者（自動署名）

内容確認・署名認可

署名者

本人性（ID保証）

PoAID

PoKEY

（当人）

（事業者）

署名証拠

記録
非改ざん
（PKI保証）

署名サービス

 署名者が署名サービスに当⼈認証にてログインし、ログ情報や認証アサーションを保存し、改ざん防⽌と署名者の保証を事業者のデジタル署名（⾃動署名）で⾏う⽅式。
 署名データとして事業者の署名鍵証拠 PoKEY（PAdESやXAdES等）も提供されるが、電⼦署名とする為には認証要素の本⼈管理を⾏い、署名認可時の署名証拠
PoAID（認証アサーションやログ情報）を記録し検証者に提供する必要がある。
 署名鍵の発⾏管理が不要であり、システムや利⽤者に対する利便性が⾼い利点がある。
 認証局/PKIを利⽤した場合と⽐較して、署名者の⾝元確認の標準や認定が無い為、本⼈確認保証レベル（IAL）が低いことが多いので、確実な⾝元確認が望まれる。

Page 27

６．電⼦認証保証レベル︓NIST SP 800-63-3
電⼦署名の保証レベルを検討する前に、⽶国NISTの電⼦認証の保証レベルを定義した NIST SP 800-63-3 を簡単に説明します。
※ NIST SP 800-63-3 を説明するドキュメントは多数ありますので詳しくはそちらを参照ください。
※ 2022年に新しい NIST PS 800-63-4 がリリースされる予定です。

「保証レベル」と言う考え方

Page 28NIST SP 800-63 シリーズと保証レベル︓• 2013年8⽉に公開された、NIST SP 800-63-2（Electronic Authentication
Guideline）において LoA（Level of Assurance）と⾔う定義がなされた。
• これは電⼦認証において1つの保証レベルを定義していたが、複数の要件のうち1つでも低いレベルがあると全体の保証レベルも下がると⾔う問題があった。
• NIST SP 800-63-3 では後述する IAL/AAL/FAL の3つの保証レベルを定義することで、それぞれ適切なレベルを選択した組み合わせを可能とした。
NIST SP 800-63 シリーズから得られる保証レベルの知⾒︓• 保証レベルではレベル毎の具体的な要件を定義する必要がある。
• ⾼い保証レベルでは必要とする要件は増えるか厳しくなり難易度も⾼くなる。
• 最⾼の保証レベルが「正解」では無く、利⽤⽬的に合致した保証レベルの選択が重要となる。例︓会議室予約システムの保証レベルは低くて良い。

電子認証保証レベル （NIST SP 800-63-3）

Page 292017年6⽉にNIST（⽶国標準技術研究所）からFinal版が公開。
⽶国政府機関向けのデジタルId実装ガイドラインで2022年にSP 800-63-4が出る予定。
https://pages.nist.gov/800-63-3/

SP 800-63-3

Digital Identity Guidelines

SP 800-63A

Enrollment and Identity Proofing「デジタルIdガイドライン」 全体の概要「登録と⾝元情報の検証」 ⾝元確認のガイドライン（登録時のレベル）

IAL（Identity Assurance Level︓⾝元確認保証レベル）の定義

SP 800-63B

Authentication and Lifecycle Management「認証とライフサイクル管理」 当⼈確認のガイドライン（利⽤時のレベル）

AAL（Authenticator Assurance Level︓当⼈確認保証レベル）の定義

SP 800-63C

Federation and Assertions「連携とアサーション」 連携時の認証/認可/属性情報のガイドライン

FAL（Federation Assurance Level︓連携情報保証レベル）の定義※ 各保証レベルは各3レベルあり組み合わせて利⽤する。レベル1が最低限で、レベル3は機密情報アクセスのレベル。

IAL（身元確認保証レベル）：SP 800-63A

Page 30

利⽤者が申請者として新規登録する際に、CSP（Credential Service Provider）が⾏う⾝元確認（Identity Proofing）の厳密さの保証レベルを⽰す。
レベル

要件概要

IAL.1

⾝元確認不要、⾃⼰申告での登録でよい。
例︓メールアドレスの到達確認。

IAL.2

サービス内容により識別に⽤いられる属性をリモートまたは対⾯で確認する必要あり。

IAL.3

識別に⽤いられる属性を対⾯で確認する必要があり、確認書類の検証担当者は有資格者の必要あり。
例︓マイナンバーカードの発⾏確認（対⾯必須）。

 ⾝元確認は電⼦署名でも必要な保証レベルであり、そのまま電⼦署名の保証レベルとして利⽤が可能。
 電⼦署名においてデジタル署名＋PKI（公開鍵基盤）の場合には、認証局CAが⾏う⾝元確認のレベルと⾔える。正確には登録時の⾝元確認（本⼈性確認）は登録局RAの役割。
 パブリック認証局のIALのレベルは⼀般的に2以上となり、具体的な⾝元確認の⽅法はCP/CPSとして認証
局が公開している。
※ CA︓Certification Authority / RA︓Registration Authority / CP︓Certificate Policy / CPS: Certification Practice Statement

AAL（当人認証保証レベル）：SP 800-63B

Page 31

登録済み利⽤者が、サービスにログインする際の認証プロセス（単要素認証、多要素認証、認証⼿段）の保証レベルを⽰す。
レベル

要件

AAL.1

単要素認証でよい。

AAL.2

2要素認証が必要、2要素⽬の認証⼿段はソフトウェアベースのものでよい。

AAL.3

2要素認証が必要、かつ2要素⽬の認証⼿段はハードウェアを⽤いたもの（ハードウェアトークン等）が必要。

※ AAL.2 以上では認証要素に Approved Cryptography（FIPS 140 Level 1 以上等）による技術やアルゴリズムが必要。

認証要素の種類︓知識

当⼈しか知り得ない情報（PIN番号・パスフレーズ 等）

所有

当⼈しか所有し得ない物に依存（ICカード・トークン 等）

⽣体

当⼈の⽣体としての情報（指紋・光彩・顔認識 等）

２要素認証︓3つの認証要素の種類のうちの2つの要素の組み合わせ（知識＋所有等）による認証。
２段階認証︓認証プロセスを２段階に分けて⾏う認証であり２要素とは限らない。

Authenticator （認証コード） の種類
No

名称

1

Page 32

要素種別

鍵所持証明

ハードウェアMemorized Secret 記憶シークレット （パスワード等）

知識

認められない認められない2

Look-up Secret ルックアップシークレット （乱数表等）

所有

認められない認められない3

Out of Band Device 経路外デバイス （SMS等、メール/VoIPは不可）所有認められない認められない4

SF（Single Factor） OTP Device 単⼀要素OTPデバイス/アプリ

所有

認められない△内容による

5

MF（Multi Factor） OTP Device 多要素OTPデバイス/アプリ

所有+知識or⽣体

認められない△内容による

所有〇認められる

認められない所有〇認められる〇認められる6

SF Cryptographic Software 単⼀要素暗号ソフトウェア（クライアント証明書等）

7

SF Cryptographic Device 単⼀要素暗号デバイス （USBドングル等）

8

MF Cryptographic Software 多要素暗号ソフトウェア

所有+知識or⽣体〇認められる

認められない9

MF Cryptographic Device 多要素暗号デバイス （FIDO/ICカード等）

所有+知識or⽣体〇認められる〇認められる※ No.5/8/9は１つだけで多要素認証を実現可能だが、他の認証コードでは多要素にする為には組合せが必要。
※ ハードウェアと認められるのは通常はNo.7/9だが、No.4/5であってもデバイス利⽤であれば認められる。

FAL（連携情報保証レベル）：SP 800-63C

Page 33

IDトークンやSAML Assertion等、Assertion（認証情報・属性・認可情報）のフォー
マットやデータやり取りの仕⽅の保証レベルを⽰す。
レベル

要件

FAL.1

Assertion（RPに送るIdPでの認証結果データ）へのデジタル署名が必要。

FAL.2

FAL.１ に加えて、対象RPのみが復号可能な暗号化が必要。つまりデジタル署名＋暗号化が必要。

FAL.3

FAL.２ に加えて、Holder-of-Key Assertionの利⽤（ユーザ毎の鍵とIdPが発⾏したAssertion
を紐づけてRPに送り、RPはユーザがそのAssertionに紐づいた鍵を持っているか（ユーザの正当性）の確認）が必要。

 FAL⾃体は電⼦認証の特有の保証レベルであり、そのまま電⼦署名の保証レベルとしては利⽤できない。
 ⼀⽅でFALをデータ仕様の保証レベルと考えると、電⼦署名において検証時に利⽤するデータ仕様の保証レベルとして⾒た場合に共通性がある。
 特に電⼦署名証拠の1つであるPoAID（ID認証の証拠）と、Assertionと⾔う意味で共通した要件が多い。これはPoAIDとは（後から）検証可能なAssertionのことであるとも⾔えるからである。
 FAL.3 では HoK を要件として求めているが、これは PoP（Proof of Possession）と考えると署名鍵の所有と⾒ることが出来る。

Page 34

７．電⼦署名保証レベル︓JNSA eSignAL
電⼦認証の保証レベルである NIST SP 800-63-3 を利⽤して、新しく定義をした電⼦署名の保証レベル eSignAL を説明します。
※ 電⼦署名保証レベル eSignAL は保証レベルTFから新たに提案する定義です。
※ NIST PS 800-63-4 がリリースされた場合には更新する可能性があります。

電子署名保証レベル eSignAL の定義

Page 35• ここまで電⼦署名と電⼦認証の整理と、電⼦署名証拠 PoESign の定義と署名⽅式の整理、及び電⼦認証の保証レベルの確認を⾏ってきた。
• これにより電⼦署名の保証レベル eSignAL（electronic Signatures
Assurance Level）を定義する準備はできた。
• 基本的な考え⽅として NIST SP 800-63-3 の保証レベルを電⼦署名に拡張する為に、新たに3つの電⼦署名⽤の保証レベルを定義した。
1. 署名認可保証レベル
︓SAAL（Signing Authorizartion Assurance Level）
2. 検証可能データ保証レベル ︓VDAL（Verifiable Data Assurasnce Level）
3. 運⽤ポリシー保証レベル
︓OPAL（Operational Policy Assurance Level）
登録時の 「⾝元確認保証レベル︓IAL」 に関しては電⼦署名保証レベルにおいてもそのまま利⽤する。

電子署名と電子認証の保証レベル
レイヤー
IDENTITY（⾝元）

PROCESS（プロセス）

電⼦署名

電⼦認証

IAL: Identity AL（Assurance Level）
本⼈確認保証レベル - NIST SP 800-63A

登録時の本⼈の⾝元確認のプロセス保証レベル（電⼦署名と電⼦認証で共通）

SAAL: Signing Authorization AL（データ）

POLICY（ポリシー）

AAL: Authenticator AL

署名認可保証レベル - JNSA eSignAL
署名時（利⽤時）のプロセス保証レベル
署名⼿順と当⼈認証（AAL）のレベル

DATA

Page 36

VDAL: Verifiable Data AL

当⼈認証保証レベル - NIST SP 800-63B
利用

認証時（利⽤時）のプロセス保証レベル
認証要素（多要素等）に依存

FAL: Federation AL

検証可能データ保証レベル - JNSA eSignAL

連携情報保証レベル - NIST SP 800-63C

検証可能なPoESign（署名証拠データ）のレベル

アサーションの署名・暗号化・HoKアサーション

検証に利⽤するデータ保証レベル

連携時のデータ保証レベル

OPAL: Operational Policy AL

運⽤ポリシー保証レベル - JNSA eSignAL
運⽤や認定・監査のポリシー保証レベル

SP 800-63-3 には無い保証レベルだが電⼦認証でも必要ではないか

SAAL（署名認可保証レベル）：eSignAL

Page 37

登録済み署名者が、署名対象の内容確認を⾏って、署名認可（署名付与）を⾏うまでのプロセスの保証レベルを⽰す。ローカル署名の場合は署名鍵の所持の保証レベルとなる。
レベル

要件

SAAL.1

署名前に署名対象の内容確認を⾏い、サービス認証（サービスへのログイン）または署名認可（署名毎の認可）に AAL.1（単要素認証）以上が必要。

SAAL.2

SAAL.1 に加えて、署名認可時（署名毎）に AAL.2（2要素認証）が必要。暗号利⽤の署名鍵を利⽤する場合は FIPS 140-2 Level 3 相当以上のハードウェア保護（HSM等）が必要。

SAAL.3

SAAL.2 に加えて、署名認可時（署名毎）に AAL.3（ハードウェア利⽤2要素認証）が必要。

※ AAL.2 以上では認証要素に Approved Cryptography（FIPS 140 Level 1 以上等）による技術やアルゴリズムが必要。

 基本的にはAALと同じではあるが、署名時に署名対象の内容確認ステップを要求している点が異なる。
 SAAL.1では署名認可だけではなく、サービス認証によるログインセッション中に複数の署名付与を実⾏することを許している。SAAL.2以上では署名毎に認可を与える必要がある。
 電⼦シール的な利⽤⽅法である⾃動署名（システムによる署名認可）に関してはスコープ外となる。
 SAAL.2以上においてデジタル署名を利⽤する場合（ローカル署名・リモート署名・事業者型署名）には認定されたHSMによる署名鍵の保護が要求される。

証明方式毎のSAAL考察
レベル

Page 38

ローカル署名

認証記録型署名

リモート署名事業者型署名SAAL.1

⾃分で内容を確認した上で、ソフト的（PKCS#12
等）に格納され管理された署名鍵（AAL.1相当）
によるデジタル署名を付与する。

署名対象を確認した上で署名認可にIDとパスワード（AAL.1）
を利⽤する。IDとパス
ワードによるサービス認証も可能。

署名対象を確認した上でサーバーに預けた署名鍵を、IDとパスワード（AAL.1）による署名認可によりデジタル署名を付与する。IDとパスワードによるサービス認証も可能。

署名対象を確認した上で署名認
可にIDとパスワード（AAL.1）を利⽤する。署名時に事業者はデ
ジタル署名を付与する。IDとパス
ワードによるサービス認証も可能。

SAAL.2

⾃分で内容を確認した上で、スマホ等に格納され管理された署名鍵（AAL.2
相当）によるデジタル署名を付与する。

署名対象を確認した上で署名認可に2要素認証（AAL.2）を利⽤する。

署名対象を確認した上でサー 署名対象を確認した上で署名認
バーのHSMに預けた署名鍵を、 可に2要素認証（AAL.2）を利
2要素認証（AAL.2）による ⽤する。署名時に事業者はHSM
署名認可によりデジタル署名を に預けた署名鍵でデジタル署名を
付与する。
付与する。

SAAL.3

⾃分で内容を確認した上署名対象を確認したで、ICカードやスマホSE等 上で署名認可にハードに格納され管理された署
利⽤の2要素認証証
名鍵（AAL.3相当）によ （AAL.3）を利用する。
るデジタル署名を付与する。

署名対象を確認した上でサー 署名対象を確認した上で署名認
バーのHSMに預けた署名鍵を、 可にハード利⽤の2要素認証証
ハード利⽤の2要素認証（AAL.3）を利用する。署名時（AAL.3）による署名認可に に事業者はHSMに預けた署名
よりデジタル署名を付与する。
鍵でデジタル署名を付与する。

 ローカル署名を除き、基本的には署名対象の確認が必要な以外はAALのレベルと同じになる。
 スマホSEとはスマホ（Android/iPhone）に搭載されているプロテクトされた Secure Element を指す。

サービス認証と署名認可

Page 39

署名サービスを利⽤する場合にはまず利⽤者のサービス認証を⾏い、署名時に署名認可を⾏う。ただしローカル署名の場合にはサービス認証は不要となる。
Sign

User
（利⽤者）

SCA
（署名サービス）

サービス認証︓ログイン
署名要求
署名内容の確認
署名認可
署名結果
複数の署名認可プロセス実⾏が可能

サービス認証︓ログアウト

署名認可プロセス

サービス認証セッション• 署名認可以外の操作（内容確認等）
はサービス認証セッションにて⾏える。
• 署名認可は都度の認証操作が必要。
• SAAL.2 以上では都度の署名認可が必須要件。

• サービス利⽤時の利⽤者の認証ログイ
ンから開始されるセッション。
• SAAL.1 ではサービス認証のみで署名認可とすることが許される。
• SAAL.1 ではログアウトするまでの間に複数の署名認可を⾏うことが出来る。

VDAL（検証可能データ保証レベル）：eSignAL

Page 40

本⼈性（本⼈の署名意思）と⾮改ざんを保証する、第三者によって検証可能なデータ（署名証拠︓PoESign）の保証レベルを⽰す。
レベル
VDAL.1

要件
サーバ保管された本⼈のID利⽤ログ等による意思確認と、アクセスコントロールや追記不可メディア保存等の運⽤による⾮改ざんに関する、第三者保証の検証可能データ（PoAID）が必要。
第三者保証の検証可能データ︓何らかの検証可能データが提供可能なレベル。
 ⾮改ざんに関してはアクセスコントロールを証明するアクセスログ等により客観的に認められれば良い。
 署名時のデジタル署名は不要だが署名証拠として外部提供する場合には事業者（保証者）のデジタル署名付与が望ましい。

VDAL.2

IAL.2 相当（プライベート認証局等）の⾝元確認と、本⼈管理の署名鍵によるデジタル署名データ（PoKEY）または検証可能な署名認可時の2要素認証（SAAL.2）のアサーション・ログ
（PoAID）と、デジタル署名等の暗号利⽤による⾮改ざんの、証拠が必要。

VDAL.3

IAL.3 相当（パブリック認証局等）の⾝元確認と、本⼈管理のハードウェア利⽤署名鍵によるデジタル
署名データ（PoKEY）または検証可能な署名認可時のハードウェア利⽤2要素認証（SAAL.3）のアサーション・ログ（PoAID）と、デジタル署名等の暗号利⽤による⾮改ざんの、証拠が必要。

※ アサーション（assertion）は認証要求者の認証結果情報に認証器（IdP等）がデジタル署名した検証可能（JWS形式等）な
データであり⼀般には Open ID Connect ID Token や SAML Assertion を指している。NIST SP 800-63C より意訳。
※ VDALはあくまでデータの保証レベルを⽰すものなのでIALとSAALのプロセスの結果の証拠としてのデータが必要となる。

VDAL説明Page 41

 VDALでは、IAL（登録時）の証拠と、AAL（署名認可時）の証拠の、2つにより本⼈の意思を保証している。
 SAALとVDALはAALを利⽤しているが、SAALはAAL認証プロセスそのものを利⽤しているのに対して、
VDALはAAL認証プロセスの結果を証拠（PoAID）としている点が異なる。
 ID認証（ID）の場合には認証サーバーがデジタル署名したIDトークン等（認証や認可の結果）でIAL/AAL相当の保証を提供する（PoAID）。
 デジタル署名（PKI）の場合には、電⼦証明書でIALの保証を⾏い、署名鍵の⾏使にてAAL相当の保証を提供する（PoKEY）。
 ⾮改ざんはデジタル署名等の暗号利⽤で保証する⽅法と、運⽤により保証する⽅法の2種類があるが、VDAL.2 以上では署名対象へのデジタル署名が必須となる。
 標準化された署名証拠（PoESign）のフォーマットは、多数の専⾨家のチェックを受けており独⾃フォー
マットよりも信頼できる。PoKEYであれば⻑期署名フォーマット（AdES）であり、PoAIDであればOIDCのIDトークンやSAMLアサーションが、標準化されたフォーマットと⾔える。
 VDAL.2 以上では標準化されたデータフォーマットの利⽤が推奨される。

証明方式毎のVDAL考察
レベル

Page 42

ローカル署名

認証記録型署名

リモート署名事業者型署名VDAL.1CP/CPS⾮公開独⾃証明書（IAL.1相当）と当⼈管理署名
鍵のデジタル署名（PoKEY）

IAL.1相当の⾝元確認と、サービス認証時か署名認可時のログ（PoAID）と、⾮改ざんの証拠または運⽤

CP/CPS⾮公開独⾃証明書（IAL.1相当）とサーバー管理
署名鍵のデジタル署名（PoKEY）と、サービス認証時
か署名認可時のログ（PoAID）

IAL.1相当の⾝元確認と、サービス認証時か署名認可時のログ（PoAID）と、CP/CPS⾮
公開独⾃証明書の事業者によるデジタル署名（PoKEY）

VDAL.2

公開プライベート認証局（IAL.2相当）証明書と当⼈管理署名
鍵のデジタル署名（PoKEY）

IAL.2相当の⾝元確認と、署名認可時の2要素認証
アサーション・ログ（AAL.2のPoAID）と、検証可能な
⾮改ざんの証拠または運⽤

公開プライベート認証局（IAL.2相当）の証明書とサーバー管理
署名鍵のデジタル署名（PoKEY）と、署名認可の2要素認証アサーション・ログ
（AAL.2のPoAID）

IAL.2相当の⾝元確認と、署名認可時の2要素認証アサーション・ログ（AAL.2の
PoAID）と、プライベート証明書の事業者によるデジタル署名（PoKEY）

VDAL.3

パブリック認証局（IAL.3相当）証明
書とICカード等の当⼈管理署名鍵のデジ
タル署名（PoKEY）

IAL.3相当の⾝元確認と、署名認可時のハードウェア
利⽤2要素認証アサーショ
ン・ログ（AAL.3の
PoAID）と、検証可能な
⾮改ざんの証拠または運⽤

パブリック認証局（IAL.3相当）の証明書とサーバーHSM管理署
名鍵のデジタル署名（PoKEY）と、署名認可のハードウェア利⽤2
要素認証アサーション・ログ
（AAL.3のPoAID）

IAL.3相当の⾝元確認と、署名認可時のハードウェア利⽤2
要素認証アサーション・ログ
（AAL.3のPoAID）と、パブリック証明書の事業者によるデジタル署名（PoKEY）

 リモート署名と事業者型署名ではPoKEYとPoAIDの両⽅が必要となる。

OPAL（運用ポリシー保証レベル）：eSignAL

Page 43

電⼦署名のサービスやプロセスに関する、運⽤ポリシー（公開・標準・認定や監査）による信頼性の保証レベルを⽰す。
レベル

要件

OPAL.1

⾮公開ポリシー準拠︓
⾮公開でも独⾃の運⽤ポリシーがあり、その運⽤ポリシーの要件に従った運⽤が必要。

OPAL.2

公開標準ポリシー準拠︓
OPAL.1 に加え、運⽤ポリシーが標準化または公的に認められており、その運⽤ポリシーの公開が必要。

OPAL.3

認定取得または定期的監査︓
OPAL.2 に加え、運⽤について公的またはデファクト標準となる認定を取得しているか、有資格者による監査を定期的に受けた運⽤が必要。

 電⼦署名プロセス（登録から署名認可まで）を信頼する為の基準となる運⽤ポリシーについてのレベルを定義する保証レベル。
 ⾮公開よりも公開が、独⾃仕様よりも標準準拠が、⾮認定よりも認定済みが、⾮監査よりも定期監査が、保証レベルが⾼い。
 電⼦認証においても運⽤ポリシー保証レベルは必要とは考えるが、ここではスコープ外とする。

証明方式毎のOPAL考察
レベル

Page 44

ローカル署名

認証記録型署名

リモート署名事業者型署名OPAL.1

⾮公開CP/CPSの順守

⾮公開サービス運⽤ポリシーの順守

⾮公開CP/CPSと⾮公開サービス
運⽤ポリシーの順守

⾮公開サービス運⽤ポリシーの順守

OPAL.2

標準準拠CP/CPSの公開と順守・RFC 3647等

標準準拠サービス運⽤ポリシーの公開と順守
・標準化運⽤ポリシー無し

標準準拠CP/CPSと標準準拠サー
ビス運⽤ポリシーの公開と順守
・欧州eIDASの運⽤ポリシー等

標準準拠サービス運⽤ポリシーの公開と順守・標準化運⽤ポリシー無し

OPAL.3

認定済み公開CP/CPSの順守
・認定認証局・WebTrust等

認定済み公開サービス運⽤ポリシーの順守
・認定制度無し

認定済み公開CP/CPSと公開サー
ビス運⽤ポリシーの順守
・欧州eIDASのTSP認定等
・⽇本には現在認定制度無し

認定済み公開サービス運⽤ポ
リシーの順守・認定制度無し※ CP/CPS = 証明書ポリシー（Certificate Policy）/認証局運⽤規定（Certification Practice Statement）。
※ ローカル署名を除いてリモート・事業者型・認証記録の署名に関する認定制度（OPAL.3）が現在の⽇本に無いことは今後の課題。

 ローカル署名はPKIを直接利⽤する為に、運⽤ポリシーに関しても⻑い標準化や認定の歴史がありOPALのレベル1〜3全てに対応が可能となっている。
 リモート署名は欧州では既に運⽤ポリシーの標準化や認定制度があるが、⽇本においての標準化はこれからであり、認定制度もこれからとなる。
 認証記録型署名と事業者型署名に関しては、運⽤ポリシーの標準化も認定制度もまだない。

おわりに：電子署名保証レベル

Page 45

本資料では電⼦署名保証レベルの説明をしましたが保証レベルは⾼いほど良いと⾔う訳ではありません。⼀般に保証レベルが⾼くなると利便性は低下します。利⽤⽬的に合った適正な保証レベルの選択が必要です。
電⼦署名保証レベルは IAL/SAAL/VDAL/OPAL で構成されますが、各要素毎に異なる保証レベルの組合せが可能です。個別に必要となる保証レベルを選択します。
また電⼦署名保証レベル検討では共通の保証レベルを策定する為に、署名⽅式を整理分類して４つの署名⽅式にまとめました。
電⼦署名保証レベルは、電⼦認証の保証レベル NIST SP-800-63-3 をベースとしています。しかし新しいバージョン SP 800-63-4 が2022年にはリリースされる予定です。この為に今後更新される可能性があります。今後も⾒直しつつ要約版ではない正式版をできるだけ早くリリースする予定です。
電⼦署名サービスの仕様検討時や、電⼦署名の利⽤者も⾃⾝が利⽤する電⼦署名の保証レベルを知る為の参考ガイドとして本資料をご利⽤ください。

Page 46

付録：参考情報

付録１：代行・代理・委任の整理

Page 47

判断

署名操作

署名鍵

補⾜

本⼈

○ 本⼈

○ 本⼈

○ 本⼈

全て本⼈が⼀般的な電⼦署名。
署名鍵があれば本⼈が管理する。

代⾏

○ 本⼈

● 代⾏⼈

○ 本⼈

署名鍵は代⾏⼈が管理して本⼈の指⽰に従って署名操作を⾏う。代⾏⼈は判断をしない。

代理/委任 ▲ 代理⼈ ▲ 代理⼈ ▲ 代理⼈

委任と代理は同じ。
例えば法⼈代表者は法⼈の代理⼈である。
 委任者＝本⼈（当⼈） / 受任者＝代理⼈
委任時に判断範囲（代理権）の制限も可能。
代理⼈が代⾏して本⼈署名鍵を利⽤する場合もありうるので署名鍵は本⼈の場合もある。

（○ 本⼈）※ 代⾏や代理/委任を⾏う場合には運⽤ポリシーを決めて遵守する必要がある。
※ 代理/委任を⾏う場合には判断の範囲や内容を決めておく必要がある。

付録２：電子シール（eシール）の整理

Page 48eIDASの電⼦シール（eシール）定義︓

 Similar in its function to the traditional business stamp. It can be applied to anelectronic document to guarantee the origin and integrity of a document.
※ business stamp = company seal : 社印と翻訳される場合が多い。

 翻訳︓従来のビジネススタンプの機能に似ている。電⼦⽂書に対して発⾏元と完全性を保証する。
意訳︓法⼈・組織（⾮⾃然⼈）電⼦証明書のデジタル署名にて発⾏元と⾮改ざんを保証する。
※ eIDASのQualified/Advancedの電⼦シールではデジタル署名とPKIを利⽤している。

⽬的︓発⾏元（発⾏組織）を保証する「証明」を重視した利⽤が主と考えられる。
※ 電⼦署名の場合には「証明」より「証拠」としての⽬的が主となる点で異なる。Page14参照。

電⼦シールプロセス︓
 通常は⾃社が発⾏する電⼦⽂書に電⼦シールを付与する。
 証明の場合は電⼦署名（本⼈の意思）と異なりシール毎に認可を⾏う必要はない。
 シール認可のルールを決めておきシステムにて⾃動シール（⾃動デジタル署名）が可能。
 保証レベル的にはIALとOPALが重要。⾃動発⾏ではSAALはさほど重要ではない。

付録３：主な略語一覧

Page 49

略語

フル名

⽇本語

説明

IAL

Identity Assurance Level

⾝元確認保証レベル

NIST SP 800-63-3A︓⾝元確認の保証レベル

AAL

Authenticator Assurance Level

当⼈認証保証レベル

NIST SP 800-63-3B︓利⽤者の認証プロセスの保証レベル

FAL

Federation Assurance Level

連携情報保証レベル

NIST SP 800-63-3C︓Assertionの保証レベル

HoK

Holder of Key

鍵の所持者

鍵所持証明の認証要素を所有している状態

PoP

Proof of Possession（鍵）所持の証明

鍵所持証明と⾔う意味でHoKとほぼ同じ意味

eSignAL

electronic Signatures Assurance Level

電⼦署名保証レベル

新定義︓IAL/AALと新定義のSAAL/VDAL/OPALを使った電⼦署名の保証レベル

SAAL

Signing Authorization Assurance Level

署名認可保証レベル

eSignAL（新）︓署名認可時のプロセスに関する保証レベルで、定義には当⼈確認
保証レベルAALを利⽤

VDAL

Verifiable Data Assurance Level

検証可能データ保証レベル

eSignAL（新）︓検証時のデータに関する保証レベルで、定義には電⼦署名証拠PoESignを利⽤

OPAL

Operational Policy Assurance Level

運⽤ポリシー保証レベル

eSignAL（新）︓運⽤ポリシーに関する保証レベルで、定義には認定や監査も利⽤

PoESign

Proof of Electronic Signatures

電⼦署名証拠新定義︓本⼈性（本⼈の意思）と⾮改ざん性（⾮改変）を確認できる情報群
署名時⽣成の署名データと署名後に取得する検証属性データで構成される

PoKEY

Proof of signature KEY

署名鍵証拠

新定義︓デジタル署名（PKI）を使った電⼦署名証拠

PoAID

Proof of Authorization ID

署名認可ID証拠

新定義︓ID認証（ID）を使った電⼦署名証拠eSignelectronic Signatures

電⼦署名

⾃然⼈によるデータに対する本⼈性（本⼈の意思）と⾮改ざん性（⾮改変）の保証

eSeal

electronic Seals

電⼦シール（eシール）

法⼈・組織によるデータに対する発⾏元証明と⾮改ざん性（⾮改変）の保証

IdP

Identity Provider

IDプロバイダ

認証サービス提供事業者。OIDCではOP（OpenID Provider）と呼ばれる。

RP

Relying Party

リライングパーティー

認証サービスを利⽤して独⾃のサービスを提供する事業者。SAMLではSP（Service
Provider）と呼ばれる。

付録４：参考リンク
本資料を理解する為にはデジタル署名＋PKIやID認証に関する知識が必要となります。
以下は参考となる資料や情報へのリンクです。
ID認証⼊⾨︓

OsSAL︓今更聞けない電⼦認証⼊⾨ 〜OAuth 2.0 / OIDC から FIDO まで〜＜改定２版＞
https://www.ossal.org/doc /LE-Auth-20200929.pdf
デジタル署名・PKI⼊⾨︓

JNSA 電⼦署名WG︓電⼦署名（PKI）ハンズオン 〜電⼦署名・タイムスタンプ超⼊⾨ ! 〜
http://eswg.jnsa.org/sandbox/handson/ESig-PKI-handson-doc-v100.pdf

JNSA 電⼦署名WG︓電⼦署名Q&A（オンラインQA集）
https://www.jnsa.org/result/e-signature/e-signature-qa/

JNSA 電⼦署名WG 署名検証TF︓デジタル署名検証ガイドライン
https://www.jnsa.org/result/e-signature/2021/

JT2A リモート署名TF：リモート署名ガイドライン
https://www.jnsa.org/result/jt2a/2020/

JT2A 真正性保証TF︓オンライン⾝元確認(eKYC)⾦融事例調査報告書
https://www.jnsa.org/result/jt2a/2021/

Page 50

作成メンバー（五十音順）

JNSA（NPO⽇本ネットワークセキュリティ協会）

標準化部会
電⼦署名ワーキンググループ

保証レベルタスクフォース
https://www.jnsa.org/
http://eswg.jnsa.org/

新井 聡
漆嶌 賢⼆
⼩川 博久
⼩久保 敏
酒巻 ⼀紀
佐藤 雅史
新宅 友也
杉崎 元
⾼丸 祐典
⽵岡 義樹
⻄窪 健太
⽇⼾ 直紘
星 尚之
政本 廣志
宮内 宏
宮崎 ⼀哉
宮地 直⼈

Page 51（NTTビジネスソリューションズ株式会社）（GMOグローバルサイン株式会社）（株式会社三菱総合研究所）（セコムトラストシステムズ株式会社）（三菱電機インフォメーションシステムズ株式会社）（セコム株式会社）（GMOグローバルサイン・ホールディングス株式会社）（三菱電機インフォメーションネットワーク株式会社）（三菱電機インフォメーションシステムズ株式会社）（アドビ株式会社）（⽇本ネットワークセキュリティ協会 電⼦署名WG）（株式会社エヌ・ティ・ティ・データ）（株式会社エヌ・ティ・ティ・データ）（⽇本ネットワークセキュリティ協会 電⼦署名WG）（弁護⼠︓宮内・⽔町IT法律事務所）（三菱電機株式会社︓電⼦署名WGリーダー）（有限会社ラング・エッジ︓保証レベルTFリーダー）